В блоге beeline cloud на хабре и в нашем технологическом медиа мы разбираем ключевые технологии и принципы работы отрасли. На этот раз мы решили затронуть стремительно растущий рынок машинного обучения, который «тянет» за собой сегмент векторных БД.
С одной стороны, технология выглядит многообещающей, с другой — имеет набор ограничений, которые еще предстоит преодолеть. Рассмотрим различные точки зрения и предложим несколько книг разного уровня для желающих глубже погрузиться в тему.
Почему векторные БД
В отличие от реляционных, векторные БД в некоторой степени эффективнее работают с многомерными и неструктурированными данными (текстом, голосом, изображениями). Например, работа с языковыми моделями подразумевает оперативную обработку объемных датасетов — векторные БД позволяют решать эту задачу за счет эмбеддингов (векторных представлений). Эмбеддинг — это вектор, представленный в виде массива чисел. Векторы расположены в многомерном пространстве на определенном расстоянии друг от друга — например, чем выше смысловое сходство объектов (допустим, документов), тем выше будет косинусное сходство их векторов.
Такой подход помогает улучшить качество поиска и релевантность результатов. Когда интеллектуальным системам не хватает контекста, они склонны галлюцинировать, то есть выдавать ложную информацию за достоверную. Предоставить этот контекст сложно, но если взять за основу достаточный набор документов и представить его в виде векторов, можно семантический поиск позволить извлекать более релевантные результаты.
Неудивительно, что крупные вендоры, развивающие СУБД и поисковые серверы, предлагают инструментарий для работы с векторами. Например, Elastic, официально покинувший российский рынок, уже длительное время поддерживает работу с word2vec. В то же время новые векторные БД появляются как грибы после дождя. Например, недавно вышел open source проект Epsilla с функцией мультимодального поиска по базе. Среди других профильных решений можно выделить Weaviate, Qdrant, Chroma, Vespa, Vald и Pinecone. Векторных баз данных настолько много, что эксперты считают рынок перенасыщенным и даже предостерегают от запуска аналогичных продуктов.
Несмотря на возросший интерес к векторным базам данных, предстоит решить ряд проблем, связанных с их работой. Сложность заключается в том, что поиск близких векторов для семантически похожих документов — может быть ресурсоемким процессом. Необходимо преобразовать запрос в вектор, определить его положение по отношению к другим векторам и отобрать наиболее близкие. Чем сложнее запрос, тем больше ресурсов необходимо задействовать. Другую сложность специалисты связывают с необходимостью разработки интеграций векторных решений и популярных фреймворков машинного обучения вроде TensorFlow, PyTorch, Scikit-learn [PDF, стр. 9]. Так, перед разработчиками таких БД стоит задача спроектировать API, которые позволили бы бесшовно взаимодействовать с различными библиотеками.
Какие прогнозы
Существуют разные точки зрения касательно перспектив векторных баз данных. Особый интерес у специалистов вызывает скорость внедрения соответствующей функциональности крупными игроками и вендорами СУБД. Профессор Эндрю Павло из Университета Карнеги — Меллона отмечает, что некоторые вендоры внедрили расширения для векторного поиска менее чем через год после нашумевшего релиза ChatGPT. Этот факт серьезно контрастирует, например, со скоростью интеграции поддержки JSON. Так, NoSQL системы, позволяющие нативно хранить файлы такого типа, стали появляться в конце нулевых (например, MongoDB, CouchDB). Но прошло еще несколько лет, прежде чем крупные игроки добавили аналогичную функциональность в реляционные базы данных — в частности, PostgreSQL, Oracle и MySQL внедрили поддержку JSON в 2012, 2014 и 2015 соответственно.
Профессор Павло видит две причины, почему векторный поиск быстрее обрел популярность. Первая — очевидная востребованность семантического поиска и эмбеддингов в сфере машинного обучения и анализа текстовых данных, а также желание компаний-разработчиков занять эту нишу. Вторая — относительно невысокие инженерные усилия для реализации соответствующей функциональности. Большинство вендоров не разрабатывали решения с нуля, а адаптировали существующие open source разработки вроде DiskANN и Faiss. С учетом достаточно быстрого темпа развития проектов в этой нише новые игроки на рынке специализированных векторных решений рискуют не выдержать конкуренции со стороны существующих вендоров. В каком-то смысле эту точку зрения разделяют некоторые резиденты Hacker News. Также они считают, что ажиотаж вокруг векторных СУБД преувеличен, а при грамотной настройке с похожими задачами могут справиться и реляционные СУБД.
Дополнительное чтение
В продолжение темы мы подобрали издания, посвященные векторным базам и не только. Авторы излагают теорию, делятся инсайтами и рассказывают, как эффективнее применять инструменты. Подборка для тех, кто хочет с нуля погрузиться в тему.
Vector Databases and AI Applications For Dummies. Краткое пособие для начинающих знакомство с векторными базами данных от компании SingleStore. Как и другие похожие издания из серии «для чайников», книга написана простым языком. Первые главы знакомят с векторными базами данных, их архитектурой и принципами хранения и извлечения информации. Примеры снабжены сниппетами кода и материалами в репозитории на GitHub. Книгу можно скачать бесплатно, но придется заполнить форму.
Foundations of Vector Retrieval. Монография Себастьяна Бруха, главного научного сотрудника в компании, развивающей векторную СУБД Pinecone (само по себе это решение проприетарное, но в контексте повествования этот факт не критичен). Цель книги — систематизировать и закрепить наиболее важные достижения в изучении векторного поиска, чтобы сделать область доступнее для исследователей. Издание фокусируется на теоретических аспектах дисциплины, поэтому в тексте много математики. В целом материал не для легкого чтения, однако в конце каждой главы представлен список референсов, которые помогут дополнительно разобраться в материале.
Vector Search for Practitioners with Elastic. Практическое пособие по разработке моделей машинного обучения с помощью Elastic. Компания официально ушла с российского рынка, однако их продукты по-прежнему доступны под лицензиями Elastic License и SSPL. Книга знакомит с различными методами настройки LLM, включая масштабирование узлов, установку конфигурации и нагрузочное тестирование с помощью Rally и Python. Авторы предупреждают, что стоит знать основы Elasticsearch и Python.
A Gentle Introduction to OpenSearch. Компактная книга, которая знакомит с различными технологиями хранения данных, включая OpenSearch и S3. Повествование ведется с точки зрения милых лесных зверюшек. Семья лис ищет новые способы добывать еду, чтобы угодить меняющимся вкусовым привычкам. Несмотря на внешнюю несерьезность и красочные иллюстрации, книга подойдет и для специалистов не из ИТ, желающих познакомиться с технологиями и базовыми концепциями открытого OpenSearch.
Deep Learning for Search. Автор — член Apache Software Foundation и разработчик нескольких open source проектов в сфере обработки естественного языка, машинного перевода (OpenNLP, Joshua, UIMA) и информационного поиска (Lucene и Solr). Книга фокусируется на глубоком обучении, но в ней присутствует раздел, посвященный word2vec. Автор рассказывает, как с его помощью можно расширить базу синонимов в контексте LLM. Он также демонстрирует возможности библиотеки Deeplearning4j для обучения модели word2vec. Читатели говорят, что книга написана простым языком и является хорошим источником идей для специалистов в области анализа данных.
Learn Python Generative AI. Авторы рассказывают о развитии генеративных ИИ-моделей и делятся опытом их применения. Книга содержит руководство по разработке приложений с помощью Pinecone. В заключительных главах собран опыт ее использования в здравоохранении (диагностика) и розничной торговле (работа с клиентами).
beeline cloud— secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
SUNsung
Не встречал пока адекватной векторной базы даных, функционал которой не можно было легко повтороить в релиационной базе.
И я подразумеваю именно простоту "копирования". Понятное дело что при желании можно и дум на буханке хлеба запустить
Сейчас все "векторные" базы это по сути огромное хранилище ключ-значение плюс куча алгоритмов поиска и сопоставления для формирования вектора.
.
По работе проводили исследования по теме лучшей реализации веток коментариев и вектора "знакомств".
Самый лучший результат был у простых связных таблицах с простейшим алгоритмом выборки (сначала копируем нужный чанк с первичным совпадением во временную таблицу а потом уже из временной таблицы удаляем все "лишнее" по вторичным условиям)
Все новомодные "векторные DB" тем хуже отдавали, чем длиннее (или разветвленнее) становился вектор
.
В целом идея векторной базы очень крутая и практичная. Не только для машинного бучения. Но как по мне к этой проблемме нужно подходить с другой стороны. Сколько лет уже идеи, а мы до сих пор имеем просто обмазаную условиями связность таблиц
ivankudryavtsev
Думаю, что Вам стоит изучить устройства алгоритма поиска в векторном пространстве на примере, например, hnswlib. Сможете пересмотреть свое мнение о:
Ну и это, давайте, повторяйте алгоритм в студию. Да так, чтобы в сотне миллионов векторов f32x1024 поиск был быстрым.
Ну и заголовок в духе вашего комментария. Люди просто не понимают разницу.
SUNsung
И то что вы привели в пример либа работы с векторами с возможностью сохранить в файл.
"Сохранить в файл" и "база данных" разные сущности, второе не может без первого, но первое не означает второе. Вы же cvs или json файл не назовете базой данных?
.
Так то разных либ хватает, вопрос именно в том что бы не изобретать свой велосипед, а работать с существующим. По опыту компания не может себе позволить поддерживать отделный продукт который используется не повсеместно. А если програмист "сделал как лучше" и поддерживал в свободное так сказать время, то уход програмиста может плохо кончится.
ivankudryavtsev
Вы, похоже, не вполне понимаете…
Myclass
А мне кажется, что векторные базы - это ни что иное как специально построенные данные в памяти + алгоритм(ы), чтобы быстро с этими данными работать. При этом вероятность изменения этих данных должна стремится к нулю. Иначе будут нужны доп. затраты на реоргаризацию этих данных в памяти, что будет стоит времени. Этим не имею в ввиду вообще отсутствие изменений, но по сравнению с трансакциями в релатионных базах - эти изменения на момент анализа несущественны.
Исходя из этого прихожу к мнению, что векторные базы в своей сути конечно-же есть нечто другое, чем релатионные базы. Но релатионные базы легко использовать для векторных, как это делается и в OLAP. Когда агрегация датамартов происходит например в памяти и для этого все данные легче закачать в память, ну а потом алгоритм аггрегации. Поэтому ваш опонент как-бы и прав. Что вы скажите на это?
ivankudryavtsev
Я скажу на это то, что репрезентации вектора в рамках реляционной базы нет (подходящей для векторного поиска), потому что на векторных базах основная операция - top K по метрике. А метрика считается не брутфорсом, с расчетом метрики (Euclide, consine) всех со всеми. Попробуйте сделать это на классике RDBMS эффективно - успехов вам.
А так-то, конечно, и для RDBMS есть модули/плагины, поддерживающие векторный поиск. Таким образом, знаете, можно все что угодно к RDBMS отнести. Да и теоремы, насколько я помню есть соответствующие о возможности полноты моделирования на RDBMS.
ivankudryavtsev
Что-то мне кажется, что вы про графовую БД...
windsurfer69
Если не секрет, что за работа, на которой приходилось заниматься векторами? Просто интересно, кто уже реально этой технологией пользовался для работы, а не для тестирования.