Дисклеймер. Это не «лучший выбор для всех». Это рамка решений для маркетинговых и бизнес-агентов на 1k–1M документов. Если у вас 100M записей — идите обниматься с Milvus, эта статья не про вас.
Привет, меня зовут Миронов Илья, я более 15 лет работаю в IT в области разработки ИИ, а также являюсь владельцем небольшого digital агентства. Если тебе интересно получать актуальную информацию про AI, маркетинг и мои кейсы, подписывайся на мой Telegram канал — @imironov_tech.
AI-агент — это автономный помощник, который умеет отвечать на вопросы клиентов, обрабатывать заявки, искать информацию в документах компании. Чтобы агент находил нужное (например, кейс из ваших проектов или ответ на типовой вопрос клиента), ему нужно где-то хранить эти знания. То есть нужна база данных — отдельное хранилище, в которое мы загружаем документы, регламенты, FAQ и всё, что агент должен «помнить».
В большинстве гайдов в интернете советуют сразу одно дорогое решение и быстро уходят в технические детали. На практике 80% бизнесов могут обойтись вариантом, который дешевле в 5–14 раз и работает не хуже. Разница в деньгах — это «AI-помощник за 1 500 ₽/мес» против «AI-помощник за 7 000 ₽/мес и не умеет того, что вам нужно».
В этой статье — 4 варианта, как хранить данные для AI-агента, со стоимостью в рублях и долларах в месяц, скоростью работы и ограничениями каждого. Плюс 6 типичных ошибок, которые угробят результат ещё до запуска. И одна рабочая конфигурация для маркетингового агентства на 50 000 документов и 10 пользователей.
Полезно владельцам бизнеса 5–100 человек, маркетологам и тем, кто думает внедрить AI-помощника, но не хочет начинать с дорогих сервисов и потом разочаровываться.
Какие цифры важны и где они ломаются
Возьмём типовой сценарий, ради которого и обсуждается БД для AI-агента. Маркетинговое агентство, AI-помощник для команды. База знаний — 50 000 документов: брифы, ТЗ, презентации, кейсы, отчёты, чек-листы, ответы на типовые вопросы клиентов.
Документы разной длины, в среднем 2 000 токенов на документ. Итого ~100 миллионов токенов. Запросов в день — 200 (10 человек в команде × 20 запросов). Цифра не астрономическая, но честная для среднего агентства.
Что нужно посчитать на старте:
- Эмбеддинги — 100 млн токенов × $0.13 за 1M (OpenAI text-embedding-3-large) = ~$13 одноразово. Re-embedding при изменениях — копейки сверху.
- Storage векторов — 50k × 3072 dimension × 4 байта = ~600 МБ.
- Storage текста — ~200 МБ.
- Запросы — 200/день × 30 = 6 000/мес.
С такими цифрами стоимость хостинга в месяц распределяется так:
Только prompt-context (без БД)
- Стоимость / мес: $0
- Что внутри: Передаём топ-N документов прямо в системный промпт. Работает, если данных < 200k токенов
SQLite + sqlite-vec
- Стоимость / мес: ~$5
- Что внутри: На любом VPS, всё локально, embedded в приложение
pgvector на Postgres-VPS
- Стоимость / мес: ~$20
- Что внутри: Один VPS, Postgres + расширение pgvector, hybrid search через FTS
Qdrant Cloud
- Стоимость / мес: $30–50
- Что внутри: Managed, hybrid search встроен, оплата сложнее из РФ
Pinecone Standard
- Стоимость / мес: $70+
- Что внутри: Managed, оплата из РФ — танцы с бубном
Разница между крайними — в 14 раз. И качество ответов агента, при правильной настройке, между pgvector и Pinecone — статистически неотличимо. Это не моя смелость, а типовой результат публичных бенчмарков (ANN-Benchmarks, Vector DB Bench).
За что вы переплачиваете в 14 раз? За маркетинг и за то, что не разобрались с альтернативами. Это адекватный обмен, если вы делаете GPT-обёртку для unicorn-стартапа на американском рынке. Если вы — российское агентство с 10 человеками и базой знаний компании, обмен не адекватный.
4 уровня data layer — где какой бизнес-агент находится
Перед тем как выбирать БД, надо понять — нужна ли вообще. Большинство решает «нужна» рефлексом, потому что в каждом гайде написано «vector RAG». Это не помогает.
Вот 4 уровня сложности данных для AI-агента, в порядке роста:
0 — Prompt context
- Где данные: В системном промпте
- Когда подходит: До 200k токенов, статика, редко меняется
- Сложность: Тривиально
1 — File / API / SQL / MCP
- Где данные: Агент тянет по запросу через function calling
- Когда подходит: Real-time данные, структурированные (CRM, заказы, календарь)
- Сложность: Низкая
2 — Vector RAG
- Где данные: Векторная БД
- Когда подходит: Большие неструктурированные тексты, семантический поиск
- Сложность: Средняя
3 — Hybrid (vector + BM25 + graph)
- Где данные: Мультихранилище
- Когда подходит: Высокие требования к точности, связи между сущностями
- Сложность: Высокая
Главное наблюдение: большинство бизнес-агентов (для отдела продаж, маркетинга, поддержки) живут на уровнях 0–1. Vector RAG им не нужен — они работают со структурированными данными (заказы, клиенты, кампании) и небольшой статичной базой знаний, которая помещается в промпт.
RAG — не дефолт. Это ответ на конкретную задачу: у вас 1000+ страниц текста, читать целиком в каждый запрос дорого и медленно. Если у вас FAQ из 20 страниц — RAG лишний, кладите в промпт целиком.
Сравнение vector DB на 100k документов
Если на уровень 2 действительно надо — выбираем хранилище. Сравнительная таблица семи популярных вариантов на нашем сценарии (50–100k документов, hybrid search, 6 000 запросов/мес).
pgvector
- $/мес: $20 (VPS)
- Hybrid: Да, через FTS
- Доступность из РФ: Полная
- Deployment: docker / managed
- Моя оценка: Лучший дефолт
Qdrant
- $/мес: $30–50 cloud / self-host
- Hybrid: Да, встроен
- Доступность из РФ: Cloud есть, self-host везде
- Deployment: docker
- Моя оценка: Сильная альтернатива
Chroma
- $/мес: self-host, ~$5
- Hybrid: Нет
- Доступность из РФ: Да
- Deployment: Python lib
- Моя оценка: Только для прототипа
Weaviate
- $/мес: $25+ cloud
- Hybrid: Да
- Доступность из РФ: Cloud есть
- Deployment: docker
- Моя оценка: Если нужны schemas
Milvus
- $/мес: $30+ self / $100+ cloud
- Hybrid: Да
- Доступность из РФ: Self-host да
- Deployment: сложно
- Моя оценка: От 10M документов
SQLite-vec
- $/мес: ~$5
- Hybrid: Нет
- Доступность из РФ: Полная
- Deployment: embedded
- Моя оценка: Для standalone-агентов
Pinecone
- $/мес: $70+
- Hybrid: Да
- Доступность из РФ: Сложно с оплатой
- Deployment: managed
- Моя оценка: Для unicorn-стартапов
Что выбрать в зависимости от сценария:
- Просто и дёшево, без compromise — pgvector. Если у вас уже есть Postgres — добавьте расширение, и всё. Если нет — поставьте Postgres сейчас, всё равно понадобится для остальной обвязки.
- Стартап, готовы платить за convenience — Qdrant Cloud. Hybrid search из коробки, шустрый, доступный.
- Прототип на ноутбуке — Chroma или SQLite-vec. Без сервера, без headache, для теста идеи. На прод не выкатывайте.
- Полностью embedded агент (плагин для IDE, offline-tool) — SQLite-vec, без вариантов.
- Рост до 100M+ документов — Milvus или managed Qdrant. Но если у вас столько документов — у вас уже команда инженеров, которая разберётся без моих советов.
6 ловушек, которые угробят агента до запуска
Архитектура — это 30%. Остальные 70% качества ответа лежат в чанкинге, эмбеддингах и поиске. Здесь сливают результат.
1. Чанк 512 токенов «по умолчанию»
В каждом гайде написано «делайте чанки по 512 токенов». Это значение из старых LLM с маленьким контекстом 2022 года. В 2026 у нас Claude с 200k и Gemini с 2M. Чанк 512 — выкидывает контекст и ломает смысл.
Норма 2026: 800–1200 токенов на чанк, overlap 100–200 токенов между соседями. Для FAQ-стиля — 400–600. Для регламентов и длинных ТЗ — 1500–2000. Подбирается по типу документа, не «один на всё».
2. Эмбеддинг-модель не для русского
OpenAI text-embedding-3-large — приличная, но не идеальна для русского. e5-mistral, multilingual-e5, BGE-M3 могут быть лучше при меньшей стоимости. Cohere embed-v3 — выше качество для длинных документов.
Что делать: возьмите 3 модели, прогоните на 100 question-answer парах из своей базы, сравните recall@10. Eval скажет правду быстрее, чем вы успеете дочитать reddit-тред про «лучшую embedding-модель».
3. Один чанкинг на все типы документов
FAQ ≠ регламент ≠ техническое ТЗ. Если режете все одинаково — теряете на каждом.
Делайте chunkers разной стратегии для разных типов: для FAQ — sentence-based с маленьким окном, для ТЗ — semantic-based с большим overlap, для длинных регламентов — section-based по заголовкам.
4. Нет переиндексации при изменении
Документы меняются. Если агент видит вектор от прошлой версии — отдаёт устаревшую инфу. Спорный вопрос, что хуже: не находить ответ или находить неправильный. Я считаю — второе хуже, потому что пользователь действует на ложной информации.
Решение: event-driven re-embedding. При изменении документа — пересчёт эмбеддинга только для соответствующих чанков, не всей базы. Это копеечная операция, если архитектура нормальная.
5. Нет hybrid search (vector + BM25)
Vector search хорошо находит «по смыслу», но плохо — точные совпадения. Запрос «приказ №47-БК от 15 марта» — vector выдаст что-то похожее по смыслу. BM25 — ровно тот документ, что нужен.
Hybrid search в 2026 — must, не «опция». pgvector + Postgres FTS, Qdrant встроенный hybrid, Weaviate, Milvus — все умеют. Включайте по умолчанию и не спорьте с собой.
6. Нет eval-сета
Без 100 question-answer пар вы не знаете, насколько ваш агент тупит. Меняете чанкинг наугад, надеетесь, что лучше. Это не разработка AI-агента, это лотерея.
Eval-сет — самое первое, что должно быть до выкатки RAG. 100 пар «вопрос → правильный документ из базы», скоринг по recall@10 и MRR. Без этого вы не знаете ничего о качестве — даже если агент «вроде нормально отвечает».
Рабочая конфигурация для маркетингового AI-агента
Что я бы поставил для маркетингового агентства на 50k документов и 10 пользователей. Без претензии на «единственно верное» — просто рабочая конфигурация, которая сходится по деньгам и качеству.
- Postgres + pgvector — основное хранилище. Структурированные данные (клиенты, кампании, метрики) и векторы — в одной БД. Не надо синхронизировать два хранилища.
- Postgres FTS — для hybrid search. BM25 + vector → лучшее качество поиска.
- Redis — кеш промежуточных результатов и rate limit. Не обязателен на старте, нужен на росте.
- Хостинг: Cloud.ru или Yandex Cloud — managed Postgres, всё в РФ, оплата картой РФ. Вне РФ — DigitalOcean managed Postgres.
- n8n или собственный сервис как orchestrator. Для маленьких команд n8n — норма.
- Embeddings: text-embedding-3-large через OpenAI или e5-mistral на собственном GPU-сервере, если хотите экономить и есть железо.
Цифры этой конфигурации:
- Стоимость: ~$30–50/мес для 50k документов, 10 пользователей.
- Латентность: p95 < 2 секунды от запроса до начала стрима ответа.
- Время до первого ответа агента: 1–3 секунды в зависимости от сложности запроса.
[СКРИН: схема архитектуры — Postgres+pgvector в центре, n8n как оркестратор, FTS+vector для hybrid search]
Красные флаги — что НЕ делать
- «У нас Pinecone, потому что это лучшая БД для RAG» — нет, потому что Pinecone не лучшая в этой нише.
- Чанк 512 токенов без обоснования
- Один embed-модель на все языки и все типы документов «навсегда»
- «Eval сделаем потом» — потом не будет, статистика проверена.
- Все документы в одной таблице с одинаковым подходом к чанкингу
- «У нас 1000 документов, поэтому мы строим vector RAG» — на 1000 документов хватит prompt context. Считайте токены, а не файлы.
Что усвоить
- Сначала спросите: нужна ли vector DB вообще. До 200k токенов хватает prompt context. До 5–10k документов — спокойно работает связка API + SQL + промпт. Vector RAG — не дефолт, а ответ на конкретную задачу.
- Если объём оправдан — pgvector в 80% случаев. Совмещён с уже существующим Postgres, дешёвый, hybrid search через FTS, доступен из РФ. Pinecone оправдан в редких сценариях масштаба unicorn-стартапа на западном рынке.
- Чанкинг и эмбеддинги — где сливается результат. Лучше потратить день на eval из 100 пар, чем месяц на красивую архитектуру с плохими эмбеддингами.
- Hybrid search (vector + BM25) — must, не «опция». Без него агент теряет точные совпадения и регулярно тупит на знакомых вопросах. Включается одной строкой в pgvector и Qdrant.
- Data layer ≠ результат агента. Это половина успеха. Вторая половина — промпты, eval, итерации. Без второй половины вы построили склад данных, а не агента.
Это сжатая версия. У меня есть полная архитектурная схема (Postgres + pgvector + n8n) с docker-compose файлом, скрипт миграции с Pinecone на pgvector, шаблон eval-сета на 100 пар «вопрос → правильный документ» для своей базы знаний и промпты, которыми я провожу AI-аудит баз знаний клиентов. Всё это в моём Telegram — @imironov_tech. Там же про AI-агентов в маркетинге и бизнесе без хайпа и «100× ROI на нейросетях».