Комментарии 8
почему вы используете ngram если по описанию вам нужен тип "
Completion?
Я не автор, но осмелюсь предлоложить, что из-за упоминаемой статьи на гитлабе. Как фанат n-грам, я бы тоже при поиске по коду бы прибегнул к ним.
А ещё лучше (в контексте описываемой задачи) я бы рабивал бы код на набор признаков и искал бы по ним. "Есть цикл", "Есть автоответ бота", "Есть работа с файлами", "Есть you-name-it", такая функция, сякая функцияю. После классифицировал бы признаки. И уже поверх этого голые исходники. Без всяких n-Грам, то есть искать не просто по голому тексту, а по пережеванным данным.
Честно говоря не до конца понял Ваш пример. Можете описать его более подробно?
Если я правлиьно понял, то таким образом если пользователь ввел например while, то мы бы могли быстро найти необходимый кусок текста, но если бы он ввел whi, то ведь уже нет?
И если бы в наших признаках не было бы например for, а пользователь ввел в поиск for и в коде это есть, то мы бы тоже ничего не нашли?
Если я правлиьно понял, то таким образом если пользователь ввел например while, то мы бы могли быстро найти необходимый кусок текста, но если бы он ввел whi, то ведь уже нет?
Верно, это минус такого подхода. Но можно разбить на две части — простая, оффлайн даже делает whi->while, а сложная уже ищёт по слову и, в теории в дальнейшем по его окружению.
Опять таки от кейса зависит, если мы хотим найти всё что связано с заказами, то по запросу order нам надо найти OrderPayment и UserOrders, тут без wildcard-ов никуда вообще, особенно если кода много, и мы хотим себя вести как обычная IDE.
Но повторюсь, я бы разбивал OrderPayment на [«order», «payment»], и по запросу «orde» не мог бы найти OrderPayment. Но! Зато можно делать выкрутасы, вроде по запросу «orders foreach» находить foreach (ThisYearHistory as order). С фильтром в GUI вроде «циклы», «функции» и так далее. Не с целью запилить поиск в IDEшке, это больше поиска по примерам, когда ты учишься новому для себя DSL, но тебе сложно найти, потому что ошибаешься в синтаксисе, и поиск тебе помогает как раз синонимами.
Условно я ищу strtoupper (потому что я новичок в этом DSL), а мне находится capitalize. Зато не могу найти kapitalize (т.к. триграммы уже ушли).
Возможно, у вас бизнес-задача (ценность) другая, и я неверно понял её из текста статьи.
Он похож, на то, что нужно на первый взгляд, но мы хотели получить не подсказку, что идет следом, а целую строку, в которой находится вхождение.
Если я ничего не путаю, Completion это скорее аналог edge ngram, а не просто ngram.
Разница в том, что он ищит только то, что начинается с поисковой строки, которую передали, поэтому в середине текста с его помощью ничего найти не получится. Для этого нужно было бы разбивать строку на этапе предобработке тем самым руками делая те же ngram'ы.
Интересный пример использования. :)
Все эти советы про "не использовать нестед" вытекают из того факта, что "под капотом" никакого "нестед" нету, и по сути если у вас один документ с сотней "объектов" в нестед - внутри вы просто получите 101 документ. При переходе от хранения в виде вложенных объектов к хранению по документу на строку вы, по сути, получили ровно ту же картинку внутри. Ну, родительские документы убрались.
В таких условиях серьёзный выигрыш по производительности индексации может получиться только за счёт того, что наиболее частый тип изменений - это всё же изменение одной строки, и вы только её и переиндексируете вместо всего документа.
Но что у вас происходит когда, например, в большой документ вставляется новая строка в начало? Или аналогично удаляется?
Ещё нестед даёт консистентное обновление документа в индексе, а вы от него избавились. Т.е. конкретно сейчас при высокой нагрузке и большом объёме изменений в одном документе вы можете получить ситуацию, что в поисковом индексе у вас половина строк старые а половина - новые. Вы что-то планируете с этим делать, или для вас это не критично?
У нас обновляется весь документ, но отдельно по строкам, одна строка отдельный паралелльный запрос на индексацию, все верно.
Консистетность нестеда была причиной очень долгой индексации, что вызывало проблемы. И да, в нашем случаи не страшно лишиться этой консистентности, потому что следом быстро придет другой запрос на индексацию, который исправит проблемы, если они возникли.
Случаев с расхождением еще не было и если это станет или стало бы частым явлением, то вариантом исправления было бы линеаризация или объединенине в батчи, но пока данных подход показываем тебя хорошо.
Как мы индекс в Elasticsearch строили