Elasticsearch был великолепен, но за векторными базами данных будущее
Этот пост был первоначально опубликован в The New Stack и перепубликуется здесь с разрешения.
На протяжении десятилетий сопоставление ключевых слов, также известное как полнотекстовый поиск, примером которого является Elasticsearch, было выбором по умолчанию для систем информационного поиска, таких как корпоративный поиск и рекомендательные системы.
По мере развития поисковых технологий на базе ИИ происходит сдвиг в сторону семантического поиска, позволяющего системам понимать как значение, так и намерение, стоящие за пользовательскими запросами. Модели эмбеддингов и векторные базы данных стали центральными элементами этого сдвига.
Семантический поиск превосходит сопоставление ключевых слов, представляя данные в виде векторных эмбеддингов, обеспечивая более тонкое понимание поискового намерения и преобразуя приложения — от генерации с дополнением извлечением (RAG) до мультимодального поиска.
На практике эффективным системам информационного поиска нужны как семантическое понимание, так и точное сопоставление ключевых слов. Например, пользователи ожидают, что результаты поиска будут показывать концепции, связанные с их поисковыми запросами, одновременно учитывая буквальный текст, использованный в запросе, такой как специальные термины и имена, и возвращая результаты с точным совпадением.
Семантический поиск на основе плотных векторов помогает понимать значение (например, знать, что ‘car’ и “automobile” — одно и то же), а традиционный полнотекстовый поиск предоставляет точные результаты, которых ожидают пользователи (например, находить точные совпадения для “Python 3.9”). В результате многие организации внедряют гибридный поисковый подход, объединяя сильные стороны обоих методов, чтобы сбалансировать гибкую семантическую релевантность с предсказуемым точным сопоставлением ключевых слов.
Проблема гибридного поиска
Распространенный способ реализовать гибридный поиск — использовать специализированную векторную базу данных, такую как open source Milvus, для эффективного и масштабируемого семантического поиска наряду с традиционными поисковыми системами, такими как Elasticsearch или OpenSearch, для полнотекстового поиска.
Хотя этот подход может давать хорошие результаты, он также добавляет новый уровень сложности. Управление двумя различными поисковыми системами означает необходимость иметь дело с разными инфраструктурами, конфигурациями и задачами обслуживания, создавая более тяжелую операционную нагрузку и повышая вероятность потенциальных проблем интеграции.
Elasticsearch против Milvus в гибридном поиске
Рисунок: Elasticsearch против Milvus в гибридном поиске
Единое решение для гибридного поиска обеспечило бы множество преимуществ:
Снижение затрат на обслуживание инфраструктуры: Управление одной системой вместо двух резко снижает операционную сложность, экономя и время, и ресурсы. Это также означает меньшее переключение контекста и меньшую умственную нагрузку при освоении двух разных наборов API.
Консолидированное управление данными: Единая структура таблицы позволяет хранить как плотные (на основе векторов), так и разреженные (на основе ключевых слов) данные вместе с общими метками метаданных. Использование двух отдельных систем потребовало бы хранить метки метаданных дважды, чтобы обе стороны могли выполнять фильтрацию по метаданным.
Оптимизированный запрос: Один запрос может выполнять как семантический, так и полнотекстовый поиск, устраняя необходимость выполнять два API-вызова к отдельным системам.
Усиленная безопасность и контроль доступа: Унифицированный подход обеспечивает более простое и надежное управление безопасностью, поскольку все механизмы контроля доступа могут централизованно администрироваться в векторной базе данных, повышая соответствие требованиям безопасности и согласованность.
Как унифицированный векторный подход упрощает гибридный поиск
В семантическом поиске модели машинного обучения «встраивают» текст в виде точек, известных как плотные векторы, в многомерном пространстве на основе его смысла. Тексты с похожей семантикой находятся ближе друг к другу в этом пространстве. Например, «apple» и «fruit» могут быть ближе в этом пространстве, чем «apple» и «car». Это позволяет нам быстро находить семантически связанный текст, просто вычисляя расстояние между каждой точкой с помощью алгоритмов approximate nearest neighbor (ANN).
Этот метод также можно применять к полнотекстовому поиску, кодируя документы и запросы как разреженные векторы. В разреженных векторах каждое измерение представляет термин, а значение показывает, насколько важен каждый термин в документе.
Термины, отсутствующие в документе, имеют значение ноль. Поскольку любой конкретный документ обычно использует лишь небольшую часть всех возможных терминов в словаре, большинство терминов не появится в документе. Это означает, что получающиеся векторы разрежены — большинство их значений равно нулю. Например, в наборе данных MS-MARCO, обычно используемом для оценки задач информационного поиска, хотя существует около 9 миллионов документов и миллион уникальных терминов, поисковая система обычно делит эту большую коллекцию на более мелкие сегменты для упрощения управления.
Даже на уровне сегмента, где в словаре есть сотни тысяч терминов, каждый документ обычно содержит менее 100 терминов, что означает, что более 99% значений каждого вектора равны нулю. Эта экстремальная разреженность имеет важные последствия для того, как мы эффективно храним и обрабатываем эти векторы.
Этот шаблон разреженности можно использовать для оптимизации производительности поиска при сохранении точности. Векторные базы данных, изначально разработанные для плотных векторов, можно адаптировать для эффективной работы с такими разреженными векторами. Например, векторная база данных с открытым исходным кодом Milvus только что выпустила нативную поддержку полнотекстового поиска с использованием Sparse-BM25 — реализации разреженных векторов для алгоритма BM25, используемого Elasticsearch и другими системами полнотекстового поиска. Sparse-BM25 открывает оптимизацию на основе приближений для полнотекстового поиска с помощью:
Эффективного алгоритма извлечения с отсечением данных: Применяя эвристическое отсечение для исключения документов с самыми низкими значениями разреженных векторов в индексе сегмента и игнорируя разреженные векторы с низкими значениями в поисковом запросе, векторная база данных может значительно уменьшить размер индекса и оптимизировать производительность с минимальной потерей качества.
Открытия дальнейших оптимизаций производительности: Представление частоты термина в виде разреженного вектора вместо обратного индекса позволяет применять дополнительные векторные оптимизации. К ним относятся:
Графовое индексирование используется для более эффективного поиска по сравнению с полным перебором.
Product quantization (PQ) / scalar quantization (SQ) для дальнейшего сокращения объема используемой памяти.
Помимо этих оптимизаций, реализация Sparse-BM25 также наследует несколько преимуществ системного уровня от высокопроизводительной векторной базы данных Milvus:
Эффективная низкоуровневая реализация и управление памятью: Базовый движок векторного индексирования в Milvus реализован на C++, обеспечивая более эффективное управление памятью, чем система на основе Java, такая как Elasticsearch. Уже одно это сокращает объем используемой памяти, экономя гигабайты по сравнению с подходом на основе JVM.
Поддержка MMap: Подобно тому, как Elasticsearch использует page-cache для хранения индексов как в памяти, так и на диске, Milvus поддерживает memory mapping (MMap), чтобы расширять объем памяти, когда индекс превышает доступную память.
Почему традиционные поисковые стеки не справляются с векторным поиском
Elasticsearch был создан для традиционных инвертированных индексов, что делает оптимизацию всей архитектуры для поиска по плотным векторам фундаментально сложной. Влияние очевидно: даже при всего 1 миллионе векторов Elasticsearch требуется 200 миллисекунд (согласно тестированию в полностью управляемом Elastic Cloud), чтобы вернуть результат поиска, по сравнению с 6 мс в Milvus (согласно тестированию в полностью управляемом Zilliz Cloud) — это разница в производительности более чем в 30 раз. Пропускная способность, измеряемая в запросах в секунду (QPS), также отличается в 3 раза: самый производительный инстанс в Zilliz Cloud работает на уровне 6000 QPS, тогда как Elastic Cloud достигает максимум 1900 QPS. Более того, Zilliz Cloud в 15 раз быстрее загружает векторные данные и строит индекс, чем Elastic Cloud. Этот разрыв в производительности увеличивается при масштабировании, когда Java/JVM-реализации Elasticsearch трудно соответствовать масштабируемости векторных баз данных на основе C++/Go. Кроме того, Elasticsearch не хватает критически важных возможностей векторного поиска, таких как дисковые индексы (DiskAnn, MMap), оптимизированная фильтрация метаданных и поиск по диапазону.
VectorDBBench Benchmarking Results.jpg
Рисунок: результаты бенчмаркинга VectorDBBench (источник)
Заключение
Векторные базы данных, примером которых является Milvus, готовы превзойти Elasticsearch в качестве единого решения для гибридного поиска. Объединяя поиск по плотным векторам с оптимизированными методами разреженных векторов, векторные базы данных обеспечивают более высокую производительность, масштабируемость и эффективность. Такой единый подход упрощает инфраструктуру, снижает потребление памяти и расширяет поисковые возможности, делая его будущим для продвинутых поисковых задач. В результате векторные базы данных предоставляют комплексное решение, которое бесшовно объединяет семантический и полнотекстовый поиск, превосходя традиционные поисковые системы, такие как Elasticsearch.
Читать далее
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.
Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.