Vector store: зачем он нужен и как выбрать для внедрения в LLM-агента

vector store внедрение - тема, которая всплывает в первую неделю работы над любым RAG-ботом или агентом с базой знаний: без векторного хранилища модель физически не способна держать в контексте документацию компании, историю переписки с сотнями клиентов или каталог на пару тысяч товаров. Контекстное окно даже у топовых моделей ограничено, а вопрос пользователя может касаться документа, который туда никак не поместится. Дальше разбираю, как устроен vector store, чем отличаются популярные решения и что учитывать, когда встраиваешь его в живой проект.

Зачем vector store нужен LLM-агенту

Агент без внешней памяти помнит только то, что уместилось в промпт: системный запрос, историю диалога и данные, которые вы вручную вставили в контекст. Как только база знаний вырастает больше пары десятков страниц, вставлять её целиком в каждый запрос бессмысленно - это и дорого по токенам, и модель начинает путаться в избыточном тексте.

Vector store решает конкретную задачу: находит из большого массива документов только те фрагменты, которые релевантны текущему вопросу, и отдаёт их модели. Работает это через семантический поиск - не по совпадению слов, а по смысловой близости. Спросите бота «как вернуть товар, если он не подошёл по размеру» - и он найдёт раздел про возврат, даже если там ни разу не встречается слово «размер».

На практике я делал это для бота на aiogram с базой знаний интернет-магазина: 40 страниц документации по доставке, оплате и возврату не влезали ни в один разумный промпт, а держать их в контексте каждого сообщения означало платить за 15-20 тысяч токенов на каждый вопрос, включая банальное «привет». После внедрения vector store бот подтягивает 3-5 релевантных кусков текста объёмом 300-500 токенов каждый - расход упал примерно в 10 раз, а ответы стали точнее, потому что модель не отвлекается на нерелевантные разделы.

Как устроен vector store: эмбеддинги, индекс, поиск

Принцип простой, хотя внутри крутится линейная алгебра. Каждый фрагмент текста прогоняется через модель эмбеддингов (OpenAI text-embedding-3-small, Cohere embed, открытые e5 или bge) и превращается в вектор - массив чисел, обычно от 384 до 3072 измерений. Тексты, близкие по смыслу, оказываются рядом в этом многомерном пространстве.

Когда пользователь задаёт вопрос, его тоже переводят в вектор, а затем ищут ближайшие по косинусному расстоянию векторы среди сохранённых документов. Вот тут и появляется vector store - база данных, заточенная под быстрый поиск ближайших соседей (ANN - approximate nearest neighbors) среди миллионов векторов за миллисекунды, а не за минуты линейного перебора.

Что важно на практике при подготовке данных:

• Размер чанка - резать документ на фрагменты по 300-500 токенов с перекрытием 10-15%, иначе смысл на границе абзаца теряется
• Метаданные - к каждому вектору сохранять источник, дату, раздел, чтобы потом фильтровать поиск и показывать пользователю, откуда взят ответ
• Обновление индекса - документы меняются, и без пересчёта эмбеддингов при правках бот отвечает по устаревшим данным
• top_k - сколько фрагментов подтягивать в ответ; на моих проектах 3-5 фрагментов почти всегда достаточно, больше только размывает контекст

Обзор популярных векторных баз данных

Выбор упирается в объём данных, требования к хостингу и бюджет. Вот с чем реально приходилось работать:

Для большинства ботов и агентов, с которыми я работаю - база знаний компании, FAQ, каталог на несколько тысяч позиций - pgvector или Qdrant закрывают задачу полностью. Managed-сервисы вроде Pinecone удобны, но у них есть нюанс: данные хранятся на серверах вендора за рубежом, и если в базе знаний есть персональные данные клиентов (переписка, обращения в поддержку), это уже вопрос 152-ФЗ о локализации ПДн. В таких случаях я ставлю self-hosted Qdrant или pgvector на сервере в РФ - юридически чище и не зависит от доступности зарубежного сервиса.

Как выбрать векторное хранилище под задачу

Для пилота и MVP

Если нужно за неделю проверить гипотезу - бот отвечает по документации, чат-виджет ищет по каталогу - беру Chroma или pgvector. Оба разворачиваются за час, не требуют отдельного сервера под векторную СУБД, а объём данных на старте редко превышает пару десятков тысяч фрагментов.

Для продакшена с ростом нагрузки

Когда бот выходит на сотни обращений в день и база растёт до миллиона+ векторов, разница в задержке поиска между pgvector без правильного индекса и Qdrant становится заметной - это уже не 50 мс, а секунды на плотной нагрузке. Здесь смотрю на HNSW-индекс (есть у обоих, но у Qdrant тонкая настройка проще) и на возможность горизонтального масштабирования.

Для конфиденциальных данных

Персональные данные клиентов, внутренние документы с коммерческой тайной - только self-hosted решение на сервере в РФ. Managed зарубежные сервисы здесь не рассматриваю принципиально, вне зависимости от удобства.

Если не уверены, какой вариант подойдёт под вашу нагрузку и бюджет - это ровно тот вопрос, который проще один раз обсудить, чем потом переезжать с одной базы на другую после того, как в продакшене накопилось полмиллиона записей.

Внедрение vector store в RAG-пайплайн: пошагово

Общая схема, которую я использую почти в каждом проекте с базой знаний, вне зависимости от выбранной СУБД:

1. Сбор и очистка исходников - PDF, страницы сайта, экспорт из CRM, документы Google Docs (сами документы можно брать откуда угодно, но при работе с данными клиентов хранить итоговую базу - только на сервере в РФ)
2. Чанкинг - разбивка на фрагменты 300-500 токенов с перекрытием, желательно по смысловым границам (заголовкам, абзацам), а не механически по символам
3. Генерация эмбеддингов - прогон через модель, сохранение вектора вместе с метаданными и исходным текстом
4. Загрузка в vector store - upsert партиями по 100-500 записей, а не по одной, иначе индексация растягивается на часы
5. Настройка поиска в агенте - top_k, порог релевантности (cosine similarity выше 0.7-0.75 обычно отсекает мусорные совпадения), при необходимости - реранкинг
6. Пересборка индекса при обновлении документов - здесь у меня почти всегда стоит отдельный сценарий, который следит за изменениями в источнике

Пример минимальной настройки таблицы под pgvector, с которой обычно начинаю:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE knowledge_chunks (
  id bigserial PRIMARY KEY,
  source text NOT NULL,
  content text NOT NULL,
  embedding vector(1536),
  updated_at timestamptz DEFAULT now()
);

CREATE INDEX ON knowledge_chunks
  USING hnsw (embedding vector_cosine_ops);

Последний пункт - пересборку индекса - почти все недооценивают на старте. На одном из проектов с автоматизацией в n8n я собрал сценарий, который следит за папкой с документами: как только менеджер добавляет новый файл или правит существующий, воркфлоу сам режет текст на чанки, получает эмбеддинги через API и обновляет записи в Qdrant - без ручного перезапуска скриптов. Похожие сценарии для автоматической переиндексации я собираю не с нуля каждый раз - часть шаблонов уже оформлена в библиотеке готовых скриптов, откуда быстрее адаптировать под конкретный источник данных.

Частые ошибки при внедрении vector store

За несколько десятков RAG-проектов повторяются одни и те же грабли:

• Слишком крупные чанки - если резать документ по 2000 токенов, в топ выдачи попадает фрагмент с нужным ответом, размытым среди трёх нерелевантных абзацев, и модель путается
• Отсутствие метаданных - без привязки к источнику невозможно потом объяснить пользователю, откуда взялся ответ, и сложно чистить базу от устаревших документов
• Игнорирование порога релевантности - без фильтра по cosine similarity агент иногда подтягивает случайный фрагмент просто потому, что он оказался ближайшим из плохих вариантов, и уверенно отвечает не по делу
• Одна модель эмбеддингов на входе, другая при поиске - векторы из разных моделей несовместимы в одном пространстве, это ломает поиск полностью и не всегда заметно сразу
• Забытая переиндексация - документы обновились, а вектора остались старые; бот две недели радостно врёт по прошлогодним ценам

Отдельно про экономику: эмбеддинги стоят копейки по сравнению с самими ответами модели - прогон базы знаний на пару сотен страниц через text-embedding-3-small обходится в доли доллара. А вот количество токенов, которые агент тратит на каждый ответ, определяется именно top_k и размером чанка - тут и находится основная экономия при работе с vector store.

Частые вопросы

Чем vector store отличается от обычной базы данных?

Обычная СУБД ищет по точному совпадению или диапазону значений - SQL-запрос с WHERE или полнотекстовый поиск по ключевым словам. Vector store ищет по смысловой близости: сравнивает векторы и находит семантически похожие фрагменты, даже если в них нет ни одного общего слова с запросом. Это разные задачи, и часто оба типа хранилищ используются в одном проекте параллельно.

Сколько стоит внедрение vector store для чат-бота с базой знаний?

Зависит от объёма данных, источников и требований к инфраструктуре. Разработка чат-бота с базой знаний на RAG у меня стоит от 50 000 ₽ - в эту работу входит подготовка пайплайна чанкинга, настройка векторного хранилища и интеграция с моделью.

Можно ли обойтись без vector store и просто увеличить контекстное окно модели?

Технически да, если база знаний совсем небольшая. Но с ростом контекста растёт и цена каждого запроса - а модель хуже фокусируется на релевантной части текста, когда вокруг неё тонны нерелевантного материала. Vector store дешевле по токенам и точнее по релевантности, поэтому для баз больше 10-15 страниц он почти всегда оправдан.

Какой vector store выбрать, если данные включают персональные данные клиентов?

Только self-hosted вариант на сервере в России - pgvector поверх Postgres или Qdrant в собственной инфраструктуре. Зарубежные managed-сервисы для таких данных не подходят из-за требований 152-ФЗ о локализации персональных данных, вне зависимости от того, насколько они удобны в настройке.