RAG-системы для бизнеса под ключ

Fine-tuning «вшивает» знания в веса модели — это дорого (от 200 тыс. ₽ за один прогон на серьёзном корпусе), долго (дни-недели) и плохо подходит для часто обновляемых данных. Любое изменение прайса или регламента требует переобучения. RAG же оставляет LLM нетронутой и подаёт ей актуальный контекст из вашей базы прямо в промпт. Обновили документ — через 30 секунд он уже доступен в поиске. Для 95% бизнес-задач RAG правильнее и в разы дешевле. Fine-tuning имеет смысл только если нужен особый стиль ответов или работа в очень узком домене с большим объёмом примеров.

pgvector — если у вас уже есть PostgreSQL и объём до 1-2 млн чанков. Не нужно поднимать отдельный сервис, всё в одном Postgres, бэкапы и репликация из коробки. Qdrant — отдельный сервис на Rust, заметно быстрее на больших объёмах, есть payload-фильтры, гибридный поиск из коробки, удобное API. Берём для production от 1 млн чанков и QPS > 50. Milvus — для миллиардных корпусов, кластер, distributed. В SMB почти никогда не нужен. Чаще всего стартуем на pgvector и мигрируем на Qdrant если упираемся в потолок.

BGE-M3 — лучший открытый выбор для рус+англ смешанных корпусов, есть dense+sparse+colbert в одной модели, можно selfhost на CPU/GPU. multilingual-e5-large — старая рабочая лошадка, чуть слабее BGE-M3 но проще в эксплуатации. GigaChat-Embeddings — российский облачный вариант, удобно для on-cloud решений в РФ-юрисдикции, но ограниченный размер запроса и зависимость от API. OpenAI text-embedding-3-large формально лучший по бенчмаркам, но недоступен напрямую из РФ и не подходит для конфиденциальных данных.

Vector search хорошо находит семантически близкое («сломалась стиральная машина» = «не работает стиралка»), но проваливается на точных совпадениях: артикулы, аббревиатуры, имена, номера статей закона. Запрос «договор 152-ФЗ ст. 6 п.4» по чистому vector найдёт «персональные данные» вообще, а нужна именно эта статья. BM25 (классический полнотекстовый поиск) ловит точные совпадения. Гибрид BM25 + vector + reciprocal rank fusion стабильно даёт +5-15 п.п. к recall и закрывает кейс, где чистый vector ломается.

Retriever достаёт top-20 кандидатов быстро (миллисекунды), но среди них релевантность размазана. Reranker — это вторая, более тяжёлая модель (CrossEncoder), которая принимает пару (запрос, чанк) и выдаёт точный скор релевантности. Прогоняем 20 кандидатов через reranker и берём top-5 в контекст LLM. Цена: +50-200ms к latency, +10-25 п.п. к recall@5 и точности ответов. На наших проектах reranker — must-have, без него RAG проигрывает Elasticsearch по релевантности.

Fixed-size (200/500/800 токенов с overlap 50-100) — самый простой и часто достаточный вариант. Recursive по структуре документа (заголовки → параграфы → предложения) — лучше для регламентов и инструкций с чёткой иерархией. Semantic chunking (граница на смене темы по embedding-расстоянию) — для длинных монолитных текстов без структуры (транскрипты звонков, статьи). Late chunking (Jina-late-chunking, 2024) — для больших контекстов где важна связность всего документа. Подбираем под тип данных, иногда комбинируем разные стратегии для разных коллекций.

Ставим бенчмарк до запуска: 100-300 размеченных пар (вопрос → правильный документ + правильный ответ). На retrieval мерим recall@k (есть ли нужный документ в top-k) и MRR (mean reciprocal rank — где в выдаче нужный документ). На генерации мерим faithfulness (ответ цитирует контекст и не выдумывает) и answer relevance (ответ по делу). Используем RAGAS, TruLens, Ragas-Eval. После каждого изменения retrievera/reranker/chunking прогоняем бенчмарк и видим динамику в числах, а не на глаз.

Делаем 2 пайплайна: full-rebuild (раз в неделю/месяц, полная переиндексация) и incremental (по webhook/CDC на изменение файла или записи в CMS). Каждый чанк хранит hash исходного блока и метаданные (source_file, updated_at, version). При обновлении документа находим связанные чанки, переэмбеддим только их и обновляем индекс. На корпусе до 100 тыс. документов это занимает секунды, на больших — минуты. Старые версии можно держать в архивной коллекции для аудита.

Cloud (OpenAI Assistants, Yandex Search API, Gigachat + Embeddings cloud) — быстро запуститься, минимум инфры, плата по запросам. Подходит для проектов до 10к запросов в месяц и нечувствительных данных. Self-hosted (vLLM + Qdrant + BGE-M3 на ваших серверах) — выше начальная стоимость (от 200 тыс. ₽ на железо + настройка), но дешевле на больших объёмах, нет утечек, нет зависимости от внешнего провайдера. Граница окупаемости — обычно около 50-100к запросов/мес. Для регулируемых отраслей (медицина, банк, госконтракт) self-hosted безальтернативен.

Технически RAG работает уже от 50-100 документов, но смысл появляется от 500-1000 (где ручной поиск становится мучительным). Верхней границы практически нет: на pgvector комфортно работает до 1-2 млн чанков, на Qdrant — десятки миллионов, на Milvus — миллиарды. Важнее качества данных чем количество: 5000 хорошо структурированных регламентов лучше чем 50 000 свалки PDF без OCR.

Для строгого соответствия 152-ФЗ собираем on-premise или в защищённом российском облаке (Yandex Cloud КП-1/КП-2, VK Cloud, Selectel). Векторная БД, embeddings-модель и LLM — всё в РФ. Используем Qwen, Saiga, GigaChat, YandexGPT в selfhost. Для медицинских данных дополнительно — изоляция контура, аудит-логи, шифрование at-rest. Делаем это уже на нескольких клиниках и юрфирмах, есть отработанный плейбук.

Со стороны клиента: 2-3 часа на установочную встречу, 4-6 часов на сбор и передачу корпуса документов, 2-3 часа на размечание 100-200 эталонных пар «вопрос → правильный ответ» для бенчмарка. Дальше мы работаем сами, возвращаемся с MVP через 3-4 недели на тестирование. Полный запуск — 6-10 недель в зависимости от пакета.