Векторные базы данных: зачем они агентам и как выбрать

Как только вы даёте LLM-агенту доступ к вашим документам, счетам или базе знаний компании, вы упираетесь в один вопрос: где хранить эти данные и как быстро находить нужный фрагмент по смыслу запроса, а не по точному совпадению слов. Ответ индустрии — векторная база данных. За последние два года она превратилась из нишевого инструмента ML-инженеров в базовый слой почти любой RAG-системы* и агента, который должен помнить больше, чем помещается в контекстное окно модели.

Что такое векторная база и зачем она агенту

Языковая модель не работает с текстом напрямую — она работает с числами. Эмбеддинг превращает фразу, абзац или картинку в вектор из сотен или тысяч чисел так, что близкие по смыслу тексты оказываются рядом в этом многомерном пространстве. Векторная база хранит такие векторы и умеет за миллисекунды находить ближайшие к вектору вашего запроса — это и есть поиск по смыслу.

Агенту это нужно по прозаичной причине: контекстное окно** конечно. Даже модели с окном в 1 миллион токенов не могут держать в голове всю корпоративную вики или переписку за три года, и держать это дорого — вы платите за каждый токен на входе. Схема с векторной базой обходит проблему: агент получает запрос, ищет в базе несколько релевантных фрагментов и подкладывает в промпт только их.

Векторная база не делает агента умнее. Она делает его памятливым — а для рабочих сценариев это часто важнее.

Где это работает на практике

• чат-бот поддержки, который отвечает по актуальной документации, а не по тому, что модель запомнила на обучении;
• агент-ассистент, который помнит прошлые диалоги с пользователем между сессиями;
• внутренний поиск по регламентам, договорам и тикетам;
• рекомендательные сценарии — «похожие товары», «связанные обращения».

Чем отличаются популярные решения

Рынок делится на два лагеря. Первый — расширения к обычным СУБД: pgvector для PostgreSQL. Второй — специализированные векторные движки: Pinecone, Qdrant, Weaviate, Milvus, Chroma. Первый лагерь удобен тем, что вектор лежит рядом с остальными данными и вы не тащите в стек новый сервис. Второй быстрее и гибче на больших объёмах и специфических типах поиска.

Разброс по возможностям и ценам большой, а тарифы облачных сервисов пересматриваются регулярно — актуальную стоимость Pinecone, облачного Qdrant или Weaviate смотрите на их официальных страницах, а не в статьях полугодовой давности. Open-source-решения бесплатны в лицензии, но вы платите инфраструктурой и временем инженеров.

Гибридный поиск — почему про него говорят всё чаще

Чистый векторный поиск проваливается на точных совпадениях: артикулах, кодах, именах, аббревиатурах. Запрос «ошибка E-402» векторно похож на кучу текстов про ошибки, но вам нужна именно E-402. Гибридный поиск сочетает векторную близость с классическим полнотекстовым (BM25), и это заметно поднимает качество на реальных корпусах. Weaviate и Qdrant поддерживают гибрид из коробки, для pgvector его собирают из pgvector плюс полнотекстовый индекс Postgres.

Кому это пригодится, а кому нет

Векторная база — не обязательный элемент любого проекта с LLM. Есть сценарии, где она лишняя.

Пригодится, если:

• у вас база знаний от тысяч документов и она регулярно обновляется — переобучать модель под каждое изменение бессмысленно, а RAG подхватывает свежие данные сразу;
• агент должен помнить историю взаимодействия с пользователем между сессиями;
• нужен семантический поиск по разнородному контенту — текст, транскрипты, описания;
• важна прослеживаемость: вы хотите показать пользователю, из какого именно документа взят ответ.

Скорее не нужна, если:

• весь ваш контент помещается в контекстное окно и меняется редко — иногда проще подложить документ целиком;
• задача — точный поиск по структурированным полям, где обычный SQL или Elasticsearch справятся лучше и дешевле;
• вы делаете разовый прототип и оверинжиниринг только замедлит запуск — начните с Chroma в памяти или даже со списка в коде;
• объём данных мал, а требования к латентности жёсткие — лишний сетевой вызов к базе может стоить дороже, чем экономит.

Что чаще всего ломается

Векторная база сама по себе не гарантирует хорошие ответы. Слабое звено обычно не она, а то, что вокруг:

1. Разбивка на чанки. Если резать документ на слишком большие или слишком мелкие куски, поиск начнёт возвращать либо мусор, либо обрывки. Это подбирается экспериментально под ваш контент.
2. Модель эмбеддингов. Качество поиска упирается в неё. Универсальная модель может плохо работать на узкой доменной лексике — юридической, медицинской, технической.
3. Фильтрация по метаданным. Без неё агент найдёт релевантный, но не тот документ — например, из чужого проекта или устаревшую версию регламента.
4. Обновление индекса. Данные меняются, а векторы остаются старыми. Нужен процесс переиндексации, иначе агент уверенно цитирует то, чего уже нет.

* RAG (Retrieval-Augmented Generation) — подход, при котором модель перед генерацией ответа подтягивает релевантные фрагменты из внешнего хранилища и опирается на них, а не только на знания, полученные при обучении.

** Контекстное окно — максимальный объём текста в токенах, который модель может учитывать за один запрос, включая и промпт, и ответ.