В эпоху LLM обычный поиск по ключевым словам уже не помогает так хорошо. Чтобы нейросети могли отвечать точно, опираясь на ваши корпоративные базы знаний, им нужно «понимать» смысл текста, а не просто искать точные совпадения букв.
Реляционные vs векторные базы данных
Начнем от известного — с традиционных (реляционных и нереляционных) баз данных. Для простоты возьмем реляционную. Концепт такой БД будет понятен тем, кто знаком с Excel-таблицами. Данные в такой базе лежат в строгой структуре и четко типизированы. Есть список таблиц, где будут столбцы (поля) и строки (объекты). Каждая ячейка содержит информацию со строгими критериями: в столбце «дата» будет лежать только формат даты, а в столбец «возраст» вы не сможете вписать имя.
Так как данные имеют очень предсказуемый вид, по ним легко проводить поиск. Для этих целей строят индексы или пишут отдельные SQL-запросы. Например: «хочу все товары дороже 1 000 рублей», «покажи всех пользователей младше 40», «выдай все машины марки Mercedes». Вы даете на вход часть данных и критерий отбора (больше, меньше, равно), после чего получаете результат в ожидаемом формате.
Реляционные БД от слова relation — связь. Таблицы в них связаны друг с другом по определенным полям. Так что вы можете искать объекты в одной таблице по фильтру колонки из связанной с ней.
Что же до векторных баз данных — помимо исходной информации, они хранят ее векторы. Векторы — это массивы чисел. Они не «человекочитаемы», но несут в себе математический отпечаток смысла занесенных данных. Близкие по смыслу тексты, близкие по величине числа, похожие по содержанию изображения — все они будут иметь схожие векторы. Для облегчения навигации к объекту также привязываются метаданные (дата создания, источник поступления) и теги.
Как получаются эти векторы? Ведь вы их не вносили. Это не простое преобразование парой формул — данные прогоняются через embedding-модель.
Embedding-модель (эмбеддинг) — специальная нейросеть, которая переводит текст, аудио или видео в математические величины и в таком виде размещает в многомерном пространстве. Семантически близкие данные получают близкие числовые значения (как GPS-координаты: у Москвы и Рязани они будут рядом, а у Москвы и Сиднея — далеко).
Размер такого вектора фиксирован. Чем длиннее этот массив чисел (типичные размерности — 768, 1 024 или 1 536), тем точнее модель улавливает нюансы смысла, но тем больше памяти требуется для хранения и тем медленнее работает поиск.
И здесь есть строгое правило: для индексации (записи в базу) и для поиска всегда должна использоваться одна и та же модель. Иначе «координаты» не совпадут. Вспомните, как трудно сориентироваться в творческом беспорядке коллеги, в котором только он умудряется быть продуктивным и находить нужные вещи — чужая модель точно так же не поймет логику вашей.
Например, вы загрузили фотографию черного кота. Модель переработает ее в векторы, содержащие семантические признаки «кот», «черный», «сидит» — вам даже не нужно добавлять ключевые слова для дальнейшего поиска.
Зачем же она это делает? Особенность начинается при поиске. Вы делаете запрос: «покажи мне все изображения домашних животных темного окраса». Запрос тоже проходит через embedding-модель, превращаясь в вектор, после чего система ищет математически ближайшие к нему векторы. К вашей фотографии не прилагалось пояснения, что кот — это домашнее животное, а черный — темный цвет. Но в выборке этого запроса вы ее получите. Модель «знает» взаимосвязи, что коты живут при домах людей и что черный явно темнее белого.
То есть ключевое различие в том, как база хранит данные и как умеет с ними в дальнейшем работать. Традиционная база хранит точные символы и умеет выполнять точные запросы (по слову«кот» она не вернет «кошку»). Векторная база «понимает» данные перед сохранением. Поэтому по запросу строки «собака» она вернет и собаку, и пса, и лабрадора, и щенка.
Зачем векторные БД нужны в эпоху LLM
Функционала привычных баз данных мало, когда речь заходит о внедрении искусственного интеллекта в бизнес-процессы.
Требуется семантический поиск. Поиска по точным совпадениям недостаточно. Например, пользователь пишет: «как сбросить пароль», а в базе знаний статья называется «Восстановление доступа к аккаунту». Реляционные БД могут поискать по ключевым словам — и не найдут. Можно прикрутить полнотекстовый поиск (например, PostgreSQL tsvector, Elasticsearch) и это повысит шансы, но в вопросе пользователя все же маловато слов. Нужен поиск по смыслу, по семантике вопроса и семантикам объектов в базе знаний. Для векторной БД «сброс пароля» и «восстановление доступа» будут лежать предельно близко.
Ограничение контекстного окна. Если в вашей базе знаний десятки тысяч текстовых файлов, вы их не уместите в лимит модели, например в 128К токенов. И давайте не забывать о рациональном использовании лимитов. Нужен какой-то механизм для ранжирования объектов по релевантности при условии, когда полнотекстовый поиск несостоятелен. Традиционная БД может ранжировать результаты по точности совпадений. Но если запрос и ответ близки только по смыслу, она вам не помощник. Векторная же «из коробки» будет понимать смысл данных. Этот смысл имеет свои векторы, которые могут быть похожи на векторы других объектов. Так получается более конкретная выборка данных, которая уже может влезать в промпт.
Мультимодальность. В скалярные БД картинку, видео или текстовый файл не засунуть. Вы можете положить туда путь до файла на диске, ссылку для скачивания или массив байтов контента файла. Что еще больше усложняет (или даже делает невозможным) поиск по смыслу, даже если вы знаете правильные ключевые слова или породу котика на снимке. Кстати, векторные БД сейчас умеют комбинировать два подхода поиска: например, «вот документ, найди похожие, но только из документов за 2024 год и с тегом legal». Мы видим и запрос на семантический поиск, и строгие ограничения по метаданным.
Гибкость форматов. Реляционные БД любят однообразие данных, как мы уже обсуждали. А векторной базе не так важен исходный формат, ведь в конечном итоге все преобразуется в универсальный тип данных — математический вектор.
Как данные готовятся и ищутся
Прежде чем переходить к выбору баз и сборке RAG-архитектуры, давайте синхронизируемся по терминам и разберемся, как именно данные укладываются в базу и по какому принципу система их потом находит.
Текст редко загружают в базу целиком. Если попытаться прогнать через модель огромный документ разом, смысл размоется, а результат может не влезть в лимит контекста нейросети. Поэтому перед векторизацией текст проходит через чанкирование (chunking) — нарезку на небольшие фрагменты. Чтобы при таком делении не разорвать мысль на середине предложения, эти куски (чанки) делаются внахлест, с небольшим перекрытием. Именно они отправляются в embedding-модель, превращаются в векторы и ложатся в базу.
Когда вы делаете запрос, системе нужно понять, какие из миллионов векторов-чанков похожи на него. Для этого система использует метрики близости. Чаще всего для текстов используют косинусное сходство, которое оценивает угол между векторами: если они «смотрят» в одном направлении, значит, их смысл совпадает. Иногда применяется евклидово расстояние (классическое расстояние по прямой между точками) или скалярное произведение — более быстрый метод, который при нормализованных векторах дает результат, аналогичный косинусному сходству.
Однако сравнивать запрос абсолютно со всеми записями в большой базе — слишком долго и дорого. Чтобы выдавать ответы за миллисекунды, векторные БД используют алгоритмы приближенного поиска. Они жертвуют мизерной долей точности ради колоссального прироста скорости.
Работает это за счет специальных поисковых индексов. Например, популярный индекс HNSW строит сеть коротких маршрутов: алгоритм не проверяет каждый вектор подряд, а быстро перемещается по крупным смысловым узлам. Это очень быстрый метод, но он требует много оперативной памяти. Если ресурсы ограничены, базы применяют другие подходы: индекс IVF предварительно разбивает векторы на кластеры (районы) и ищет совпадения только внутри нужного, а метод PQ просто сжимает сами векторы — как при сжатии фотографий, когда файл становится намного легче ценой потери мелких деталей.
Гибридный поиск и рабочий пайплайн RAG
Векторный поиск хорошо улавливает смысл, но иногда промахивается на точных названиях, артикулах, редких терминах. Например, код ошибки «ERR-4412» модель может «недопонять».
Для таких случаев используется гибридный поиск, который комбинирует семантическую близость (векторы) и совпадение ключевых слов (как в знакомом нам точном поиске).
В современных реалиях векторные базы чаще всего применяются в связке с большими языковыми моделями. Классический пайплайн RAG (Retrieval-Augmented Generation) состоит из двух основных этапов:
- подготовка данных (индексация): исходный документ → нарезка на чанки → обработка через embedding-модель → сохранение векторов в базу;
- обработка запроса: вопрос пользователя → перевод вопроса в вектор с помощью той же модели → поиск ближайших векторов-чанков в базе → передача найденных текстов и оригинального вопроса в LLM → генерация итогового ответа нейросетью.
Обзор инструментов и решений
За каждый шаг RAG обычно отвечает отдельный компонент инфраструктуры векторного поиска. Чтобы не запутаться в множестве технологий, давайте разберем имеющиеся решения как единый путь — от специализированных движков до гибридных баз и самих моделей эмбеддингов.
Специализированные векторные базы
Это системы, изначально заточенные под одну задачу — максимально быстро выполнять поиск вида «найди самое похожее». Они работают с векторами «из коробки», но различаются подходом к инфраструктуре.
Pinecone.io
Облачный сервис «под ключ», который идеально подходит для старта. Схема простая: создали аккаунт, подняли индекс, залили векторы и сразу выполняете поиск. Работы с серверами, масштабированием и поддержкой здесь минимум. Обратная сторона медали — это платно, а ваши данные физически живут у внешнего провайдера.
Qdrant
Быстрая open-source база с удобными фильтрами по метаданным (дата, теги, tenant_id). Ее можно крутить у себя или взять их облако. Qdrant часто выбирают, когда важен строгий self-hosted контроль и безопасность. Приятный бонус — встроенный механизм удобной миграции данных из других сервисов (например, из того же Pinecone).
Weaviate
Еще один представитель open-source. Сильная сторона: ориентация на гибридный поиск (когда модель учитывает смысл + ключевые слова) и готовые модули, которые сами помогают векторизовать данные.
Milvus (и облачный Zilliz)
Решение для очень больших объемов: миллионы и миллиарды векторов. Если у вас небольшой FAQ, это будет как пушка по воробьям. Но если вы строите корпоративный поиск на огромном корпусе данных, то можно рассмотреть.
Chroma
Максимально легкая и дружелюбная база для прототипов, пет-проектов и туториалов. Удобно пощупать идею за вечер. Для серьезной нагрузки обычно рано или поздно переезжают на что-то мощнее.
Векторный поиск внутри привычных баз
Не всегда нужна отдельная «векторная империя». Иногда проще добавить векторные возможности туда, где данные уже лежат.
PGVector
Знакомое многим расширение для PostgreSQL. В ту же Postgres-базу добавляете столбец с векторами и индекс для поиска похожих. Удобно стартовать: один стек, привычные JOIN-ы, транзакции. Но на очень больших объемах специализированные векторные БД обычно сильнее.
Вы можете легко запустить PostgreSQL с установленным и настроенным расширением pgvector, арендовав облачные базы данных в Selectel. Это избавит вас от необходимости администрировать сервер базы данных вручную.
После подключения расширения можно создать таблицу с векторами:
CREATE TABLE documents (
id bigserial PRIMARY KEY,
title text,
content text,
embedding vector(1536)
);
А затем искать документы, наиболее близкие к вектору запроса по смыслу:
SELECT id, title, content
FROM documents
ORDER BY embedding <=> :query_embedding
LIMIT 5;
В этом примере оператор <=> используется для поиска по cosine distance. PGVector поддерживает несколько типов расстояний и соответствующие индексы.
Elasticsearch/OpenSearch
Если в вашей инфраструктуре уже крутится мощный поисковый движок, логично задействовать его векторные возможности. В результате получается эффективный гибрид: система ищет совпадения и по точным словам, и по глубокому смыслу.
MongoDB Atlas Vector Search
Самый естественный и бесшовный путь для команд, чьи сервисы уже глубоко завязаны на экосистему MongoDB и хранят там основные документы.
Практический совет: если PostgreSQL уже работает в проде, а объем данных умеренный — начинайте с PGVector. Переходить на отдельную векторную БД стоит только тогда, когда вы реально упретесь в масштаб, скорость или специфичные требования к выборке.
Embedding-модели
Векторная база сама по себе хранит лишь наборы чисел. А вот превращают исходный текст в эти самые числа специальный класс нейросетей — embedding-модели. Здесь есть два концептуальных пути.
Облачные API
OpenAI embeddings — самый привычный путь. Отправили текст через API — получили готовый вектор. Просто, но платно и есть зависимость от внешнего сервиса;
Cohere — особенно полезен, если ваш RAG работает с большим объемом мультиязычных (неанглийских) текстов, где модель показывает высокую точность.
Собственные open-source модели
Варианты вроде BGE, E5 или других моделей из репозитория Hugging Face (через библиотеку sentence-transformers). Главный плюс — это бесплатно, а конфиденциальные данные никогда не покидают ваш закрытый контур. Минус — требуется свой сервер (желательно с GPU) и самостоятельная поддержка.
Правило RAG: модель, которой вы индексируете данные, и модель, которой вы векторизуете запрос пользователя, должны строго совпадать. Если вы решили сменить embedding-модель, вам придется полностью пересчитать всю базу.
Пример пайплайна: как выглядит типичный стек
Чтобы вся эта система работала стабильно в продакшене, одной базы данных недостаточно. Классическая архитектура корпоративного поиска с AI обычно выглядит так:
- исходные файлы (документы, PDF, изображения) лежат в S3-совместимом хранилище;
- брокер сообщений (например, Kafka или RabbitMQ) принимает обновления, чтобы система индексировала новые документы асинхронно, не нагружая основной сервис;
- отдельный микросервис забирает текст, режет его на чанки и переводит в векторы через API (OpenAI, Cohere) или локальные open-source модели (например, BGE);
- векторная БД сохраняет готовые векторы вместе с метаданными и обеспечивает быстрый поиск по ним;
- бэкенд принимает запрос от пользователя, векторизует его, запрашивает похожие чанки из базы и «склеивает» их с исходным вопросом;
- LLM генерирует итоговый, человекочитаемый ответ на основе полученного и отфильтрованного контекста;
- система логирования отслеживает скорость поиска, релевантность выдачи и расходы на API.
Где и как используются или могут использоваться векторные БД
Зная преимущества и особенности работы векторных баз данных, можно догадаться о способах использования этого инструмента. Например, собственно поиск по крупным базам знаний — по корпоративным документам, историческим данным общения с контрагентами, документации к продуктам. Можно устроить более сложный поиск по каталогу товаров — найти похожее платье по фото.
Кстати о товарах. Вспомним маркетплейсы с их рекомендательными системами. Или онлайн-кинотеатры. Вы как пользователь на основании покупок/просмотров можете быть конвертированы в текст, а значит и в вектор. Значит, ваш вектор можно сравнивать с векторами товаров и предлагать похожее.
Или же поддержка клиентов — вместо дерева FAQ сделать поиск по базе решений. Это повысит релевантность к запросу, а соответственно, и удовлетворенность клиентов.
К теме поддержки: можно облегчить работу с баг-репортами детекцией дубликатов — не захламлять базу однотипными, а объединять их. Или облегчить закупки, объединяя однотипные заказы.
Еще есть полюбившиеся разработчикам ассистенты написания или изучения кода. Ведь файлы кода — это такой же текстовый документ. Режем на чанки и поехали.
Для рационального использования токенов можно подключить векторные БД для долгосрочной памяти агентов — они будут сохранять важные факты диалога как набор векторов.
Также технология может пригодиться в детекции мошенничества, а значит, и в его предотвращении. Если история взаимодействия клиента и продукта похожа на мошеннический сценарий, его можно распознать даже при изменении скрипта мошенников.
Больше статей об устройстве баз данных:
Проблемы и подводные камни
Как с любым относительно новым инструментом, у векторных баз данных есть свои проблемы и сложности при работе.
Главное бутылочное горлышко ВБД — это качество RAG. Что и в каком виде попадет в контекст, как данные будут подготовлены, как обработаны — все это определяет корректность ответа. Если поиск по БД вернет мусор из-за некачественного флоу RAG или его частей, то этот мусор попадет в контекст модели — она будет ориентироваться на него при ответе. То есть даже при формальной корректности работы, результат будет неудовлетворительным.
Сам процесс индексации данных, перевода их в векторы — это черный ящик вашей системы. Если смысл считан неверно, будет сложно выяснить, в чем проблема. То ли данные были плохо подготовлены, то ли были неверно ранжированы моделью. Может, расчет векторов подвел. В общем, это мозголомный квест.
При обработке данных важным этапом, который потенциально может добавить проблем, является чанкование. Если выбрать одинаковый размер чанков, можно столкнуться с замусориванием отдельных разделов смыслами соседей. Если чанковать по разделам или абзацам, можно запнуться об особенности документа — если так чанковать Толстого, можно быстро забить контекст одним абзацем.
Где есть нейросеть, там будут галлюцинации. Подход RAG снижает их, но никто не совершенен. Все еще нужно ограничивать модель, совершенствуя промпты. Например, «отвечай только на основе контекста».
Помимо прочего, качество поиска и, соответственно, ответа может страдать из-за мультиязычности. Эмбеддинг-модели обучают преимущественно на английском. Если ваши данные на другом языке, модели придется сначала выполнить перевод. Это увеличит потребление ею ресурсов, а также, вероятно, привнесет некоторые смысловые потери.
В отличие от привычных скалярных БД есть еще проблема актуальности данных. Картотека будет одинаковой независимо от того, кто запросит из нее данные. Но если вы оперируете смыслами, то при смене модели-эмбеддинга (чтеца этих данных), вам нужно будет переиндексировать все данные. Иначе вектор в базе уже не будет соответствовать содержимому документа. Если объем данных велик, это может стать значительной проблемой. В частности одни только счета за работу эмбеддинг-модели на этом этапе вас не обрадуют.
Отдельной проблемой выделяют безопасность данных в multi-tenancy системах. Если вы не хотите, чтобы данные смешивались между потребителями, нужно отдельно промаркировать их в метаданных. Условно говоря, каждую единицу информации нужно «подписать». Поиск тогда будет комбинировать скалярный подход со строгим совпадением по этой подписи в метаданных и семантический поиск векторов.
Стоит упомянуть и некоторые юридические вопросы работы с ВБД. Например, проблемы хранения персональных данных — в изначальном тексте, в скалярной базе данных, вы можете подменить или удалить ФИО, номера телефонов и паспортов. В векторе же это невозможно — нормативные документы должны учитывать эти особенности.
Не нужно гнаться за технологичностью и трендами. Если у вас небольшая база знаний, вам может хватить полнотекстового поиска — инфраструктура векторных баз будет слишком тяжеловесной. Если по вашей базе ведутся в основном строгие запросы (например, по бухгалтерии), скалярная база будет справляться лучше и обходиться дешевле, да и обслуживать ее будет проще.
Заключение
Не стоит внедрять векторные БД там, где они объективно не нужны. Если у вас небольшая база знаний или поиск в приложении строится исключительно на точных запросах, классическая реляционная БД или Elasticsearch справятся с задачей лучше и дешевле.
Как в любом вопросе, выбор инструмента должен зависеть от целей и ресурсов. Но они очень помогают в работе LLM — без них чат-бот будет уверенно врать, основываясь на облаке тегов, которое смог собрать в бесконечной базе знаний. Векторная БД дает фундамент для корректного формирования контекста ответа, а значит более точной и более конкретной информации в нем.
