хорошо ... это обширная тема.На самом деле эластичный поиск был сделан именно для этого.Но гугл тоже.От упругого поиска до поиска в Google существует технологический разрыв.
Если вы продолжите свою личную реализацию, это все еще возможно ... но есть еще много работы, которая будет такой же эффективной, как и поиск в Интернете.Быстрый ответ: используйте эластичный поиск.
Вам может быть любопытно или по какой-то причине вам может понадобиться написать это самостоятельно.Итак, как это работает:
TFIDF и косинусное расстояние
Как вы указали сначала, вы токенизируете, затем представите токенизированный текст как вектор, а затем измерите угловое расстояние междутекст и слово для поиска.
представьте, что на вашем языке только 3 слова "foo, bar, bird", поэтому текст с "птицей foo bar" может быть представлен вектором3 [1,1,1]текст с
A)"foo foo foo foo bird" будет [4,0,1] другим
B)"foobar "[1,1,0]
, если вы ищете" bar ", который представлен [0,1,0], вы будете искать текст с минимальным угловым расстоянием, и если вы вычисляетеугловое расстояние между вашим поиском и BI, по-моему, составляет 90 °, что меньше A.
На самом деле язык - это более 3 слов, поэтому вы вычислите расстояние в векторе еще многих измерений, потому что 1 мир= 1 измерение:)
TFIDF обозначает частоту обратного частоты документа.это оценивает частоту слова в документе обратно пропорционально частоте этого слова во всем документе.Что он делает, так это указывает на важное слово в документе.
Позвольте объяснить, что:
- слово «что в» и т. Д. Везде, поэтому они не важны
- во всех ваших текстах слово "корпус" имеет частоту, я не знаю, 0,0001%
- , в конкретном тексте оно цитируется 5 раз, частота руки составляет 0,1% * 1036.*
- тогда это довольно редко в корпусе, но довольно важно в вашем тексте для сравнения
- , поэтому, когда вы будете искать "корпус", вам нужно сначала получить текст, где он появляется 4 раза.
- поэтому вместо вектора числа вхождений у вас будет вектор относительной частоты вхождений для примера [0.2,1,0.0005]
https://en.wikipedia.org/wiki/Tf%E2%80%93idf
В конце у меня есть небольшой сюрприз для вас: это то, что стоит за оценкой в эластичном поиске https://www.elastic.co/guide/en/elasticsearch/guide/current/scoring-theory.html
Кроме того, эластичный поиск предоставит вам масштабируемость репликации, распределение и все, о чем вы могли мечтать.
Есть спока причина не использовать эластичный поиск:
- цель исследования
- вы на самом деле пишете другую поисковую систему, например, duckduck go (почему бы и нет)
- вам любопытно
часть о масштабировании и распределении
Прочитайте о lucene до https://en.wikipedia.org/wiki/Apache_Lucene
, это сильно зависит от объема индексируемого текста ислово.
Если он представляет 1M текста, вам не нужно его распространять.вам понадобится распределенный инвертированный индекс, если вы индексируете что-то большое, например, википедию (в википедии для поиска используется индекс эластичного поиска)
foo находится в тексте A, B, C, R , поэтому я разделю свойindex
Я буду использовать распределенный кеш со словом для ключей и списком указателей на векторы в качестве значений.Я хотел бы сохранить значения в файле сопоставленной памяти.Поисковая система - это то, что должно быть быстрым, поэтому, если вы сделаете это самостоятельно, вы уменьшите количество внешних библиотек.Вы будете использовать c ++
. В Google они заканчивают ситуацией, когда векторы занимают так много места, что им нужно хранить их на нескольких машинах, поэтому они изобрели GFS, это распределенная файловая система.
вычисление косинусного расстояния между многомерными векторами отнимает много времени, поэтому я остановлюсь на вычислении в графическом процессоре, поскольку графические процессоры эффективны для операций с плавающей запятой над матрицей и векторами.
На самом деле, это немного сбой, чтобы переопределить все, что ожидает, что у вас есть веская причина для этого, например, очень хорошая бизнес-модель:)
Я, вероятно, буду использовать докер kubernetes и mesos для виртуализации всего моего компонента. Я буду искать что-то похожее на GFS, если потребуется большой объем.
https://en.wikipedia.org/wiki/Comparison_of_distributed_file_systems
Вам нужно будет вернуть текст обратно, поэтому я буду использовать любой веб-сервер NIO, который масштабируется на любом языке. Я буду использовать nginx для обслуживания статических страниц и что-то вроде netty или vertx для поиска, затем построю ответ с ссылкой на текст (это зависит от того, сколько пользователей вы хотите обслуживать за одну секунду)
Все это, если я планирую индексировать что-то большее, чем википедия. И если я планирую изобрести что-то лучше, чемasticsearch (трудная задача, удачи)
для примерной Википедии это меньше 1Т текста.
наконец
Если вы сделаете это сasticsearch в течение одной недели, у вас может быть 2 недели и в производстве. Если вы делаете это самостоятельно, вам понадобится как минимум 1 старший разработчик и специалист по датам, архитектор, и примерно один год или более в зависимости от объема текста, который вы хотите проиндексировать. Я не могу перестать спрашивать себя «для чего это нужно».
На самом деле, если вы прочитаете исходный код lucene, вы точно будете знать, что вам нужно. Они сделали это, lucene - двигатель упругого поиска.
Twitter использует Lucene для поиска в реальном времени