Семантический поиск vs. лексический поиск vs. полнотекстовый поиск
В цифровом мире, в котором мы живем сегодня, поисковые системы стали неотъемлемой частью нашей жизни, помогая нам быстро и легко получать доступ к информации. В основе этих поисковых систем лежат алгоритмы информационного поиска, которые определяют, как извлекается информация.
Существует несколько алгоритмов информационного поиска — от традиционных методов, таких как полнотекстовый и лексический поиск, до более продвинутых техник, таких как семантический поиск. У каждого из этих алгоритмов есть свои преимущества и недостатки; поэтому нам крайне важно выбрать лучший алгоритм информационного поиска, который подходит для нашего варианта использования.
В этой статье будут рассмотрены эти алгоритмы информационного поиска с особым акцентом на лексический, полнотекстовый и семантический поиск. Начнем с самого простого: лексического поиска.
Лексический поиск
Лексический поиск, также известный как поиск по ключевым словам, относится к поисковому алгоритму, основанному на анализе текста на уровне слов (отсюда и название). Этот алгоритм информационного поиска сопоставляет термины запроса точно так, как они встречаются в тексте. Например, если наш поисковый запрос — “run,” алгоритм вернет все вхождения термина “run” в документе.
Лексический поиск — самый базовый из доступных алгоритмов информационного поиска, поскольку он возвращает только те термины в документе, которые точно совпадают с нашим запросом. Это делает лексический поиск особенно полезным, когда требуются точность и конкретность, например при поиске документов или записей, содержащих определенную строку или слово.
Рисунок: Иллюстрация простого лексического поиска.
Однако простота лексического поиска также приводит к нескольким недостаткам. Во-первых, он не допускает опечаток в нашем запросе. Например, если мы по ошибке введем “ron” вместо “run,” мы не получим результаты, которые ищем. Во-вторых, лексический поиск не учитывает синонимы, стемминг или лемматизацию. Следовательно, поиск по “run” не сопоставит похожие слова в разных формах, такие как “ran” или “running.”
Кроме того, лексический поиск может быть не лучшим вариантом, если мы ищем наиболее релевантные записи на основе нашего запроса. Документы или записи, содержащие термин нашего запроса, не имеют какого-либо представления о порядке или ранжировании, что затрудняет оценку релевантности результатов, возвращаемых лексическим поиском.
Как видите, лексический поиск определенно имеет значительные ограничения, если учитывать требования большинства вариантов использования информационного поиска. Более того, пользователям часто требуется больше гибкости в отношении терминов, включаемых в результаты, чего лексическому поиску также не хватает. Именно здесь в игру вступает полнотекстовый поиск.
Полнотекстовый поиск
Полнотекстовый поиск работает аналогично лексическому поиску, стремясь найти записи, содержащие термины из нашего запроса. Однако полнотекстовый поиск предлагает более широкие и продвинутые возможности, чем лексический поиск, решая проблемы, связанные с лексическим поиском.
Реализация полнотекстового поиска часто включает популярные методы Natural Language Processing (NLP), такие как стемминг и лемматизация. Это означает, что когда мы ищем термин “run,” все документы или записи с похожими словами в разных формах, такими как “ran” или “running,” также будут включены в результаты.
Рисунок: Иллюстрация развития полнотекстового поиска по сравнению с традиционным лексическим поиском.
Чтобы сортировать результаты поиска на основе релевантности, мы также можем реализовать такие алгоритмы, как TF-IDF и BM25. Давайте подробнее поговорим об этих двух алгоритмах.
Основы TF-IDF и BM25
Term Frequency-Inverse Document Frequency (TF-IDF) использует простой статистический метод для определения релевантности документа или записи для заданного термина или запроса. Он состоит из двух компонентов:
Term Frequency (TF): вычисляет количество вхождений термина запроса в документе. Поэтому чем чаще термин запроса встречается в документе, тем выше оценка TF для этого документа.
Inverse Document Frequency (IDF): вычисляет долю документов во всей коллекции, которые содержат термин запроса.
Основная цель компонента IDF — штрафовать распространенные и менее значимые термины, такие как «a», «an», «the» и «and», которые, как правило, встречаются почти во всех документах. Например, если наш термин запроса — «mix and match», мы хотим, чтобы наиболее релевантные документы содержали много вхождений «mix» и «match», а не многочисленные вхождения «and». Наконец, итоговая оценка TF-IDF для документа получается путем умножения оценок TF и IDF.
Один из основных недостатков TF-IDF заключается в том, что он не учитывает длину документа при расчете релевантности. В действительности более длинные документы с большей вероятностью будут чаще содержать наш термин запроса. Например, если наш термин запроса встречается 10 раз в документе из 1 000 слов (Документ A), тогда как в документе из 50 слов (Документ B) он встречается только 5 раз, мы можем утверждать, что Документ B может быть более релевантным, несмотря на меньшее число вхождений.
BM25 устраняет это ограничение TF-IDF, вводя дополнительные члены и расширяя уравнение TF-IDF, чтобы учитывать длину документа.
Тем самым BM25 устраняет смещение в пользу более длинных документов при измерении релевантности документа для любого заданного запроса.
Концепция разреженного эмбеддинга
И TF-IDF, и BM25 могут быть представлены как разреженные эмбеддинги. Разреженный эмбеддинг — это n-мерный вектор, где размерность зависит от количества уникальных терминов в нашем корпусе или коллекции документов.
Например, допустим, у нас есть 10 документов, содержащих в общей сложности 10 000 уникальных слов. Тогда каждый документ будет преобразован в 10 000-мерный вектор, где каждое измерение представляет важность определенного термина в этом документе.
Рисунок: иллюстрация преобразования документа в разреженный эмбеддинг.
Поскольку размерность вектора определяется количеством уникальных терминов в корпусе, мы часто получаем векторы огромной размерности. Кроме того, поскольку документ обычно содержит лишь небольшую долю доступных терминов, подавляющее большинство элементов этих векторов будет равно нулю, как вы можете видеть на изображении выше. Именно поэтому такие векторы обычно называют разреженными эмбеддингами.
Теперь, когда все документы представлены как эмбеддинги, мы можем вычислить сходство между любыми двумя эмбеддингами с помощью распространенных алгоритмов, таких как косинусное сходство или евклидово расстояние. Интуиция заключается в том, что два документа с похожими терминами высокой важности будут иметь высокое сходство.
Несмотря на преимущества разреженных эмбеддингов в полнотекстовом поиске, у них есть один существенный недостаток: они не учитывают семантическое значение терминов запроса. Например, если наш запрос — “Apple device,” документы, содержащие множество упоминаний “apple” (фрукт), могут ранжироваться выше, чем технологические документы, которые более релевантны нашему запросу, но не содержат термин “Apple” (компания).
Рисунок: Примеры запросов, требующих семантического понимания и контекста.
Когда включение результатов со схожими семантическими значениями является требованием для нашего сценария использования, полнотекстовый поиск может быть не лучшим алгоритмом извлечения информации. Именно здесь в игру вступает семантический поиск.
Семантический поиск
Семантический поиск — это полезный подход, когда нам нужны результаты поиска, учитывающие семантическое значение. Используя пример, упомянутый в предыдущем разделе, когда мы вводим запрос вроде “Apple device”, мы на самом деле не ищем документы или записи, содержащие слово “apple”. Вместо этого мы ищем документы, в которых обсуждаются технологии, предпочтительно устройства Apple. В этом случае полнотекстовый поиск дал бы нежелательные результаты, поэтому семантический поиск является лучшим вариантом.
Концепция плотного эмбеддинга
Семантический поиск работает за счет использования сложных AI models для преобразования наших документов и терминов запроса в эмбеддинги. Однако эмбеддинги, создаваемые этими моделями, часто называемые плотными эмбеддингами, отличаются от разреженных эмбеддингов, обсуждавшихся ранее.
В плотных эмбеддингах значения в каждом измерении вектора редко бывают точно равны нулю, а сама размерность зависит от используемой модели. Однако размерность плотных эмбеддингов значительно ниже, чем у разреженных эмбеддингов.
Рисунок: Иллюстрация преобразования документа в плотный эмбеддинг.
Плотные эмбеддинги содержат семантически насыщенную информацию о содержимом, которое они представляют. Поэтому, чтобы определить, насколько семантически похожи два плотных эмбеддинга, мы можем просто использовать популярные алгоритмы сходства, такие как косинусное сходство или евклидово расстояние.
Роль векторных баз данных в семантическом поиске
В реальных приложениях извлечения информации мы, вероятно, будем иметь дело с миллионами или даже миллиардами плотных эмбеддингов. Поэтому непрактично хранить все эти эмбеддинги в памяти нашего компьютера; нам нужна система баз данных, способная эффективно их хранить.
Векторная база данных — это система, которая позволяет нам эффективно хранить огромные объемы плотных эмбеддингов, используя передовые методы индексирования, такие как approximate nearest neighbors (ANN) и hierarchical navigable small world (HNSW). Она также предоставляет функциональность для выполнения операций векторного поиска, чтобы находить наиболее семантически релевантные документы для нашего запроса с использованием популярных алгоритмов сходства, таких как косинусное сходство и евклидово расстояние.
Рисунок: Рабочий процесс выполнения операции векторного поиска.
Более того, популярные векторные базы данных, такие как Milvus, предлагают расширенные функции, такие как гибридный поиск, который позволяет выполнять векторный поиск, сочетая преимущества как плотных, так и разреженных эмбеддингов. Мы обсудим это подробнее в следующих разделах.
Лексический поиск vs. полнотекстовый поиск vs. семантический поиск
Теперь, когда у нас есть подробное понимание лексического, полнотекстового и семантического поиска, давайте сравним их механизмы сопоставления, сложность, примеры сценариев использования и производительность.
| Семантический поиск | Лексический поиск | Полнотекстовый поиск | |
|---|---|---|---|
| Механизм | Контекст и намерение | Точное совпадение | Ключевое слово и релевантность |
| Сложность | Высокая | Низкая | Средняя |
| Производительность | Медленнее | Быстрая | Умеренная |
| Сценарии использования | Системы на основе NLP, генерация с дополненным извлечением (RAG), приложения на базе LLM, рекомендательные системы | Простой поиск | Системы с большим количеством документов |
Таблица: Лексический поиск vs. полнотекстовый поиск vs. семантический поиск
С точки зрения механизма сопоставления, лексический поиск — самый простой из трех, поскольку он сопоставляет точные термины в запросе. Полнотекстовый поиск улучшает лексический поиск, сканируя целые документы на наличие терминов запроса, что позволяет сортировать результаты на основе их релевантности запросу. В то же время семантический поиск сопоставляет термины запроса с коллекцией документов на основе семантического значения и контекста, используя продвинутые модели глубокого обучения и методы NLP.
Что касается сложности, лексический поиск также является самым простым вариантом. Полнотекстовый поиск немного сложнее из-за внедрения алгоритмов, таких как TF-IDF или BM25, которые преобразуют тексты в разреженные эмбеддинги. Семантический поиск является самым сложным, поскольку он использует продвинутые модели глубокого обучения для преобразования текстов в плотные эмбеддинги.
Например, лексический поиск — отличный выбор, когда критически важно точное совпадение, например при поиске имени переменной в коде или идентификатора продукта в документе. Полнотекстовый поиск подходит для приложений, когда нужно находить документы со специальными терминами или понятиями из запроса, например при поиске в академических базах данных или юридических репозиториях. Семантический поиск идеально подходит для сценариев, где приоритетом является понимание контекста, таких как чат-боты поддержки клиентов, рекомендательные системы и обнаружение контента.
С точки зрения производительности, семантический и полнотекстовый поиск относительно медленнее из-за своей сложности, тогда как лексический поиск быстрее благодаря своему прямолинейному подходу.
Концепция гибридного поиска
Учитывая разнообразие, а также плюсы и минусы каждого алгоритма информационного поиска, выбрать лучший непросто, и он может не полностью соответствовать всем вашим требованиям. В практических сценариях использования нам может даже понадобиться применять более одного алгоритма, чтобы удовлетворить различные потребности нашего приложения, поскольку эффективные системы информационного поиска должны обеспечивать пользователям как семантическое понимание, так и точное сопоставление ключевых слов. Гибридный поиск — это концепция, разработанная для решения этой задачи.
Гибридный поиск позволяет объединять два разных поисковых алгоритма, чаще всего сочетая семантический поиск с полнотекстовым или лексическим поиском. Однако реализация гибридного поиска связана с трудностями из-за задействования разных систем. В частности, нам нужна векторная база данных, такая как Milvus, для хранения плотных эмбеддингов и выполнения семантического поиска, а также поисковая система, такая как Elasticsearch, для выполнения полнотекстового поиска.
Однако использование двух отдельных систем для поддержки разных алгоритмов поиска создает новые сложности. Это означает необходимость работать с отдельными конфигурациями и задачами обслуживания, что в дальнейшем может привести к проблемам интеграции. Такой подход также может удвоить наши затраты, поскольку требует хранения данных в двух инфраструктурах.
Рисунок: Elasticsearch и Milvus в гибридном поиске.
Лучшее решение — использовать единую систему, способную обеспечивать как семантический, так и полнотекстовый/лексический поиск. Milvus — идеальная open-source векторная база данных для такого случая, поскольку она поддерживает реализацию гибридного семантического и полнотекстового поиска. Кроме того, Milvus также поддерживает поиск с фильтрацией по метаданным, поиск по диапазону, и реранжирование для получения наиболее точных результатов.
С Milvus мы можем хранить все необходимые данные для различных типов поиска, включая плотные эмбеддинги, разреженные эмбеддинги и метаданные. Это позволяет выполнять гибридный поиск — например, семантический и полнотекстовый или лексический поиск. Благодаря своим продвинутым методам индексирования Milvus также высоко оптимизирован для операций векторного поиска, что значительно ускоряет процесс информационного поиска по сравнению с Elasticsearch.
Заключение
Выбор алгоритма информационного поиска играет важную роль в определении эффективности и релевантности результатов поиска в нашем приложении. Лексический поиск обеспечивает точное сопоставление терминов, что делает его идеальным для сценариев, где необходимы точные совпадения. Полнотекстовый поиск развивает лексический поиск, применяя такие методы, как стемминг, нечеткое сопоставление и ранжирование по релевантности с использованием алгоритмов вроде TF-IDF и BM25, что делает его подходящим для приложений с большим количеством документов. Между тем семантический поиск предоставляет возможности для понимания контекста и намерения, что делает его крайне полезным для сложных систем на основе NLP, таких как чат-боты для поддержки клиентов.
Однако по мере роста спроса на гибкие и эффективные поисковые системы гибридный поиск становится практичным решением, позволяющим использовать сильные стороны нескольких алгоритмов поиска. Интегрируя семантический и полнотекстовый/лексический поиск, Milvus обеспечивает гибкость и улучшенный пользовательский опыт. Ознакомьтесь с этим руководством, чтобы попробовать наши семантический и полнотекстовый поиски с Milvus.
Связанные ресурсы
Читать далее

Zilliz Cloud Delivers Better Performance and Lower Costs with Arm Neoverse-based AWS Graviton
Zilliz Cloud adopts Arm-based AWS Graviton3 CPUs to cut costs, speed up AI vector search, and power billion-scale RAG and semantic search workloads.

Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.

Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.


