Задача: «нейросеть, которая знает наши документы»
Типовой заказ звучит так: в компании тысячи страниц — регламенты, инструкции, договоры, техническая документация, типовые ответы. Новый сотрудник ищет нужный пункт часами, опытный — «знает, где лежит», но уходит в отпуск. Поддержка копирует ответы из файлов вручную. Требуется: задавать вопросы обычным языком и получать ответ с указанием документа и раздела.
Второй типовой сценарий — работа с обращениями: классифицировать входящее, подобрать норму регламента, подготовить черновик ответа, а человеку оставить утверждение. Именно такой контур зафиксирован в нашем КП-прецеденте «LLM-обработка обращений граждан» на 2 560 000 ₽ — классификация, маршрутизация и черновики ответов по регламентам, финальное слово за человеком.
Решение: почему RAG, а не дообучение
RAG (retrieval-augmented generation) — это архитектура, при которой модель получает не «память о ваших документах», а найденные фрагменты в момент вопроса. У этого четыре практических следствия. Первое — прослеживаемость: каждый ответ содержит ссылку на источник, проверяющий не верит модели на слово. Второе — обновляемость: изменился регламент — перезагрузили файл, через минуты ассистент отвечает по-новому; дообученную модель пришлось бы переучивать. Третье — контроль доступа: фрагменты можно фильтровать по ролям пользователей. Четвёртое — цена: пилот от 480 000 ₽ против существенно более дорогих проектов собственного дообучения.
Дообучение остаётся инструментом для стиля и классификаций, но для баз знаний в 2026 году выбор рынка — RAG; сравнение подходов — в ответе «RAG или дообучение модели». Собственной модели чаще всего не нужно вообще — см. «Нужна ли компании собственная языковая модель».
Архитектура: четыре шага контура
Архитектура RAG-контура (текстовая схема)
База документов: PDF / DOCX / регламенты / договора / wiki
│ 1) парсинг и очистка, разбиение на фрагменты
▼
Векторная база (индекс фрагментов) ◄── обновление перезагрузкой документов
▲ (без дообучения модели)
Запрос пользователя ──► 2) поиск: векторный + ключевой (гибридный)
│ 3) топ-фрагменты + инструкции → контекст
▼
LLM: GigaChat API | on-premise LLM (ПДн, госсектор)
│ 4) ответ строго по фрагментам + ссылка на источник
├──► источника нет ──► «не найдено в базе» (без выдумки)
▼
Интерфейс: портал / виджет / бот / API для систем
▼
Логи: что искали, что не нашли ──► план доработки базы
Инженерно сложнее всего шаг 1 — подготовка данных: сканы требуют OCR, таблицы и схемы — отдельной разметки, противоречивые версии документов — сверки. От качества этого шага зависит большинство «плохих ответов», поэтому данные готовятся по отдельному гайду до старта пилота. Сравнение векторных хранилищ (Milivus, Qdrant) — в обзоре «Векторные БД»; их безопасность — в OWASP LLM08.
Этапы и сроки
| Этап | Что получается | Цена | Срок |
|---|---|---|---|
| Аудит базы и процессов | инвентаризация документов, карта запросов, оценка качества данных | 90 000 ₽ | 3–5 рабочих дней |
| Подготовка данных | очистка, OCR при необходимости, структура и права доступа | входит в пилот | 1–2 недели |
| Пилот RAG | изолированный контур, одна база, замеры доли точных ответов | от 480 000 ₽ | 4–6 недель |
| Полный контур | интеграции (1С/CRM/портал), роли, мониторинг качества | 0,9–1,2 млн ₽ | по ТЗ |
| Сопровождение | обновление базы, контроль деградации ответов, отчётность | от 50 000 ₽/мес | — |
Цены — прайс НЬЮ-ССТ на сентябрь 2026, «от», без НДС (УСН, п. 2 ст. 346.11 НК РФ). Рыночные якоря LLM-внедрений сентября 2026 — от 630 тыс. до 4,56 млн ₽ (выборка 236 закрытых ИТ-лотов).
Ориентир бюджета
На бюджет влияют: объём и состояние базы (сканы с OCR дороже текстовых файлов), число интерфейсов (портал, бот, API), требования контура безопасности и глубина интеграций. Для сравнения с рынком — кейс цен LLM-интеграций: пилоты сезона укладываются в 480–690 тыс. ₽, полные контуры — около миллиона. Промышленная обработка обращений с маршрутизацией — наш прецедент 2 560 000 ₽: это уже не «поиск по базе», а процессный контур с ролями и утверждениями.
Что получает заказчик: метрики качества
- Доля точных ответов — по тестовому набору реальных вопросов; целевое значение фиксируется в КП.
- Доля «не найдено в базе» — честный отказ вместо выдумки; рост показателя — сигнал доработать базу.
- Ссылочность — каждый ответ ведёт к документу и разделу; проверка занимает секунды.
- Время поиска — от «часов по папкам» до минут; замеряется на пилоте на реальных задачах сотрудников.
- Журнал ненайденного — какие вопросы база не покрыла: готовый бэклог наполнения базы знаний.
Границы и риски
RAG не чинит плохую базу: противоречивые документы дают противоречивые ответы, поэтому аудит данных обязателен. Модель без фильтров способна выдать и «галлюцинацию» — лечится запретом отвечать вне найденных фрагментов и фильтрами промпт-инъекций. Если в базе персональные данные — применяется 152-ФЗ: обезличивание или закрытый контур; для отравления данных через документы есть отдельная угроза (см. OWASP LLM04), поэтому загрузка в базу — управляемый процесс с ревью.
Об этом разборе. Это типовой проект — обезличенный контур из нашей практики проектирования и реальных ТЗ; имена заказчиков не раскрываются (NDA). Прецеденты рынка и наши КП — из открытых страниц new-sst.ru (сентябрь 2026). Метрики фиксируются в КП и на приёмке; выдуманных цифр не приводим.