Почему 100 000 документов — это уже отдельная задача

На объёме в сотни документов RAG собирается за вечер: файлы режутся на чанки, кладутся в векторную базу, сверху ставится LLM. На 100 000 документов этот подход ломается сразу по трём направлениям — индексация перестаёт укладываться в разумное время, поиск начинает выдавать мусор, а стоимость железа становится сопоставимой с бюджетом небольшого отдела. Средний корпус такого размера — это 1,5–2,5 млн чанков по 400–600 токенов, и именно от этой цифры считаются память, диски и GPU.

Слои архитектуры: от парсинга до ответа

Первое, что определяет качество, — ingestion. В российской практике корпус почти всегда гетерогенный: PDF с текстовым слоем, сканы договоров и актов с печатями, DOCX, XLSX со спецификациями, письма из Outlook, выгрузки из 1С. Сканы без текстового слоя прогоняются через OCR, и здесь важно сохранять структуру: заголовки, таблицы, нумерацию пунктов. Чанкинг делается не «по 500 символов», а по смысловым блокам с перекрытием 10–15% и привязкой метаданных — источник, дата, версия, подразделение, гриф доступа.

Второй слой — гибридный поиск. Чистый dense-поиск плохо ловит артикулы, номера ГОСТов, ФИО и аббревиатуры, поэтому параллельно идёт BM25 или SPLADE по лексическому индексу, а результаты сливаются через RRF. Далее — реранкер (кросс-энкодер вроде bge-reranker-v2-m3), который пересортировывает топ-50 кандидатов и оставляет 5–8 фрагментов в контекст. Без реранкера на больших корпусах точность падает заметно: релевантный документ есть в топ-50, но не попадает в топ-5.

Третий слой — генерация с контролем. Модель получает только отобранные фрагменты, обязана ссылаться на источник, а при низком скоровом пороге отвечает «в базе знаний нет данных». Это снимает основную часть галлюцинаций и делает систему пригодной для внутреннего аудита.

Векторный поиск: что выбрать под нагрузку

Для приватного контура реалистичны три варианта: Qdrant, Milvus и pgvector. До 5 млн векторов размерности 1024 Qdrant на одном узле держит десятки миллионов запросов в сутки при latency 20–60 мс, а pgvector удобен, если нужно жить внутри существующего PostgreSQL и не плодить сервисы. Экономия памяти достигается квантизацией: float32 → int8 даёт четырёхкратное сжатие, бинарная квантизация с rescoring — до 32 раз, что позволяет держать 2 млн чанков в 3–6 ГБ RAM вместо 8–10 ГБ.

Параметры HNSW (m=16–32, ef_construct=200–400) подбираются под recall: на 100 000 документов целевой показатель — recall@10 не ниже 0,9 на размеченном наборе из 200–300 реальных вопросов сотрудников. Этот набор делается до настройки, иначе оптимизировать нечего.

Железо: три конфигурации под разные бюджеты

Минимальная (пилот, до 300 тыс. чанков): 1× RTX 4090 24 ГБ или RTX 6000 Ada 48 ГБ, CPU 16–24 ядра, 128 ГБ RAM, 4 ТБ NVMe. Тянет embedding-модель bge-m3, реранкер и LLM 7–14B в AWQ.

Рабочая (100 000 документов, 10–30 одновременных пользователей): 2× RTX 6000 Ada 48 ГБ или 1× A100 80 ГБ, EPYC 32–48 ядер, 256–512 ГБ RAM, 8 ТБ NVMe в RAID. На GPU живут эмбеддер, реранкер и модель 32B (Qwen2.5-32B, Vikhr, GigaChat-подобные веса) под vLLM с paged attention. Индексация 2 млн чанков занимает 2–4 часа, генерация идёт на 25–40 токенов/с.

Промышленная (мультиарендность, 70B, жёсткий SLA): 2–4× H100 80 ГБ или 2× A100, 1 ТБ RAM, NVMe-массив 16 ТБ, отдельный узел под векторную БД. Здесь же появляется репликация индекса и балансировщик.

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

Практические шаги внедрения

1. Аудит корпуса: сколько сканов, какие форматы, есть ли дубликаты и документы с истёкшим сроком.
2. Разметка 200–300 эталонных вопросов с правильными источниками — база для метрик.
3. Пайплайн ingestion с OCR, дедупликацией и метаданными, включая права доступа.
4. Гибридный поиск + реранкер, замер recall@10 и faithfulness до подключения LLM.
5. Пилот на одной бизнес-функции (например, договорная работа или техподдержка), затем масштабирование.

Разворачивать всё это имеет смысл в закрытом контуре: без внешних API, с логированием запросов и разграничением доступа на уровне чанков. Тогда RAG проходит и требования 152-ФЗ, и внутренний режим коммерческой тайны.

Как мы можем помочь

Мы проектируем и разворачиваем приватные RAG-контуры под ключ: аудит корпуса, OCR и пайплайн индексации, гибридный поиск с реранкером, подбор серверного железа под ваш объём и нагрузку, интеграция с 1С и CRM. Считаем метрики качества до запуска и передаём систему с документацией и обучением команды. Обсудить проект