Поделиться
Поделиться

Заказчик просит «чат по нашим регламентам». Демо на пяти PDF проходит красиво. В production модель уверенно ссылается на устаревшую инструкцию, путает отделы и иногда выдумывает пункты, которых не было в файле. RAG (Retrieval-Augmented Generation) как раз про то, чтобы ответы опирались на ваши документы — но только если retrieval, чанкинг, права доступа и оценка качества сделаны как продуктовый контур, а не как prompt в пятницу вечером.

В OtherCode мы внедряем RAG и смежные AI-функции в духе URAP AI (документы → структура → ответы/извлечение), в контентных сценариях Content Factory, в справке и операторских подсказках для SaaS и промышленных интерфейсов. Ниже — архитектура, практика eval, когда RAG не нужен, гибрид с правилами и требования privacy/on-prem.

Что такое RAG в продуктовых терминах

RAG = найти релевантные фрагменты → подставить в контекст модели → сгенерировать ответ с опорой на них (желательно с цитатами).

[Документы заказчика]
        ↓
[Парсинг / OCR при необходимости]
        ↓
[Chunking + метаданные + ACL]
        ↓
[Индекс: dense ± BM25]
        ↓
[Запрос пользователя] → retrieval top-k
        ↓
[LLM + политики] → ответ + citations
        ↓
[Лог / eval / feedback]

Без качественного retrieval LLM либо молчит полезно, либо фантазирует убедительно. Общий каркас AI в продуктах — в статье Разработка с AI.

Когда RAG уместен — и когда нет

| Сценарий | RAG? | Почему | |----------|------|--------| | Ответы по регламентам, FAQ, договорам | Да | Нужна опора на актуальный корпус | | Извлечение полей из одного документа | Часто хватает OCR+правила / NER | Retrieval по базе не обязателен | | Жёсткий расчёт тарифа / налог | Нет как единственный путь | Нужен калькулятор и тесты | | «Поговори с пользователем дружелюбно» | Нет | Нет корпуса знаний | | Поиск по коду ошибок оборудования | Да / гибрид | База + карточка сигнала из телеметрии |

Не используем RAG, если:

  • нет корпуса или он не обновляется;
  • ошибка недопустима без детерминированного движка;
  • вопрос решается SQL/фильтром по БД;
  • документы нельзя отдавать модели даже в retrieval-контуре без юр. основания.

Иногда лучше обычный поиск + шаблон ответа, чем LLM.

Архитектура, которую мы собираем на практике

1. Подготовка документов

  • Нормализация форматов (PDF, DOCX, HTML, сканы).
  • Для сканов — OCR-пайплайн (см. OCR и распознавание документов на Python): без текста нет чанков.
  • В URAP-подобных системах сначала извлекаем структуру, потом уже строим knowledge-слой для Q&A.
  • Версия документа и дата вступления в силу — обязательные метаданные.

2. Chunking

Плохой чанкинг = хороший повод для галлюцинаций.

| Подход | Плюсы | Минусы | |--------|-------|--------| | Фиксированные 500–1000 токенов + overlap | Просто | Режет таблицы и списки | | По заголовкам / секциям | Сохраняет смысл | Нужен парсер структуры | | Мелкие чанки + parent context | Точный hit + широкий контекст | Сложнее пайплайн |

Практика: для регламентов — секционный чанкинг; для «простыней» без оглавления — окна с overlap; таблицы — отдельно, с сохранением строки заголовков.

3. Эмбеддинги и поиск

  • Dense embeddings для семантической близости.
  • Keyword/BM25 для точных артикулов, кодов ошибок, номеров ГОСТ.
  • Гибрид обычно стабильнее «только vector».
  • Rerank (лёгкая модель или cross-encoder) — когда top-20 шумные, а в контекст LLM нужно 4–6 фрагментов.

Индекс храним рядом с продуктом: PostgreSQL + расширения / отдельный vector store — выбор от объёма и ops. Для многих заказчиков проще меньше движков и один PostgreSQL, который команда уже умеет бэкапить на VPS / в Yandex Cloud.

4. Промпт и политики

  • «Отвечай только по контексту; если нет данных — скажи, чего не хватает».
  • Язык ответа = язык пользователя.
  • Запрет на советы вне домена (медицина/право — отдельные дисклеймеры и human review).
  • Обязательные citations: id чанка, название документа, якорь секции.

5. ACL

Retrieval без прав доступа — дыра. Фильтр по tenant_id, отделу, грифу до отдачи в LLM. Иначе эмбеддинг «находит» чужой договор.

Eval: как понять, что RAG не врёт

Демо ≠ качество. Собираем набор вопросов с эталонными ответами и допустимыми источниками.

| Метрика | Смысл | |---------|--------| | Retrieval hit rate | Нужный чанк в top-k | | Answer faithfulness | Утверждения подтверждены контекстом | | Citation precision | Цитаты реально использованы | | Latency p95 | UX чата / API | | % escalation | Уход к человеку / «не знаю» |

Релиз нового индекса или промпта — через GitLab CI: smoke на золотом наборе, сравнение с предыдущей версией. Образы пайплайна — Docker; деплой на staging, затем production (VPS + PM2/compose или облако). Тот же MLOps-дух, что в URAP: версия артефакта, откат, мониторинг.

Feedback оператора («ответ неверный», «не та цитата») попадает в eval и в очередь на правку корпуса — не только в чат поддержки.

Гибрид: RAG + правила + инструменты

Самые надёжные продукты не отдают всё модели.

  • Правила: если вопрос «какой статус заявки №» — tool/SQL, не RAG.
  • RAG: «как по регламенту оформить возврат».
  • Калькулятор / Modbus-карта: для Typhoon/Galvatec сначала справочник сигналов и порогов, RAG — по инструкции обслуживания.
  • Content Factory: генерация по шаблону бренда + проверка стоп-слов правилами.
  • Diom / Next.js UI: показывают источники и кнопку «создать тикет», а не только «красивый абзац».

Двухфазность на критичном: модель предлагает, человек или rule engine подтверждает запись в ERP.

Privacy и on-prem для enterprise

Для многих заказчиков документы нельзя отправлять в публичный SaaS-LLM.

Варианты, которые закладываем:

  1. On-prem / VPC — модель и индекс в контуре заказчика или в изолированном сегменте Yandex Cloud.
  2. Self-hosted LLM — ниже «магия» качества, выше контроль; нужен rightsizing GPU и FinOps.
  3. Маскирование PII до отправки в внешний API, если внешний API вообще допустим договором.
  4. Аудит: кто что спросил, какие чанки ушли в контекст, какая версия индекса.
  5. Отключение обучения на данных клиента у провайдера — юридически и технически проверить.

Synapse/Game API и промышленные шлюзы и так живут с разделением контуров; RAG для «внутренней базы знаний завода» наследует те же сетевые границы.

Типичные ошибки внедрения

  1. Залить 10 000 файлов без очистки дублей и черновиков.
  2. Чанки по 4k токенов «чтобы всё влезло».
  3. Нет версий индекса — ответы по старой политике безопасности.
  4. Один промпт на все типы вопросов без роутера intent.
  5. Игнорировать latency и стоимость токенов (контекст раздут top-20).
  6. Считать «пользователи довольны в первую неделю» за eval.

Связка со стеком OtherCode

  • Python — парсинг, OCR, индексация, workers.
  • Redis — очередь на переиндексацию и тяжёлые запросы.
  • PostgreSQL — метаданные документов, иногда векторы.
  • GitLab CI + docker runners — тесты retrieval/eval, сборка образов.
  • Production — VPS RU / Yandex Cloud, PM2 для веб/API-слоя Next.js, compose для AI-workers.
  • Фронты — Next.js и Flutter (Diom) с отображением цитат и состояний «думаю / не нашёл».

UX: как не стыдиться ответа модели

Технически верный RAG легко убить плохим интерфейсом.

  • Показываем источники сразу: название файла, дата, фрагмент.
  • Состояния: поиск → генерация → «мало контекста» → эскалация человеку.
  • Кнопка «ответ полезен / нет» — топливо для eval.
  • Для операторов Diom и веб-панелей — копирование цитаты в тикет одним жестом.
  • Никаких скрытых «уверен на 97%» без калибровки: лучше честный «нашёл 2 фрагмента, уверенность средняя».

В Content Factory UX другой: не чат, а черновик с правилами бренда и явным diff относительно шаблона. В промышленных сценариях рядом с RAG держим карточку сигнала из телеметрии — модель не должна подменять число с датчика.

Обновление корпуса без простоя знаний

Регламенты меняются. Пайплайн обновления:

  1. Загрузка новой версии документа (API или админка).
  2. OCR/парсинг при необходимости (очередь Redis).
  3. Пересчёт чанков только затронутого документа.
  4. Атомарная подмена версии в индексе (старая читается, пока строится новая).
  5. Smoke-eval на вопросах, завязанных на этот документ.
  6. Аудит: кто опубликовал версию и когда она стала отвечающей.

Без атомарности пользователи полдня получают смесь старых и новых норм — хуже, чем полный даунтайм чата.

Стоимость токенов и кэш

Раздутый контекст — главный враг бюджета. Контролируем:

  • top-k после rerank, не «все что нашли»;
  • кэш ответа на идентичный вопрос + версия индекса;
  • отдельные лимиты на tenant (особенно multi-tenant SaaS);
  • сжатие/summary длинных секций только если eval не падает.

FinOps для RAG — часть дизайна, иначе пилот на Yandex Cloud GPU/LLM съедает маржу продукта.

Роутер намерений перед retrieval

Не каждый запрос должен идти в векторный индекс.

| Intent | Путь | |--------|------| | Статус сущности по id | Tool / SQL | | Приветствие / small talk | Короткий шаблон без LLM | | Вопрос по регламенту | RAG | | Расчёт / формула | Калькулятор + пояснение | | Жалоба / эскалация | Создание тикета |

Роутер может быть правилами или лёгкой классификацией. Главное — не смешивать режимы в одном промпте «сделай всё».

Пилот на 4–6 недель: что должно получиться

Реалистичный пилот OtherCode с заказчиком:

  • 50–200 очищенных документов одного домена;
  • 30–50 золотых вопросов с эталонами;
  • UI с цитатами на Next.js или встраивание в существующую панель;
  • замер faithfulness и hit rate, а не NPS «понравился бот»;
  • решение go/no-go по SLA и privacy до масштабирования на весь архив.

Если за пилот нельзя измерить качество — это не пилот, а шоу.

Кому в команде принадлежит RAG

Без владельца система деградирует тихо: корпус устаревает, промпт «чуть подкрутили», eval никто не гоняет.

| Ответственность | Кто обычно | |-----------------|------------| | Корпус и юридическая актуальность | Заказчик / knowledge owner | | Пайплайн индекса и CI | OtherCode (Python/DevOps) | | UX цитат и escalation | Frontend (Next.js / Diom) | | Бюджет токенов и GPU | Product + FinOps | | Privacy-модель | Security / юристы заказчика + архитектура студии |

На статус-митинге раз в две недели достаточно трёх цифр: hit rate retrieval, доля «не знаю», стоимость 1k ответов. Остальное — в дашборд.

Чеклист готовности RAG к production

  • [ ] Корпус очищен, версионирован, с владельцем
  • [ ] Chunking и метаданные осмыслены под тип документов
  • [ ] Гибридный поиск или осознанный отказ от него
  • [ ] ACL на retrieval
  • [ ] Citations в API/UI
  • [ ] Золотой eval-набор и порог релиза
  • [ ] Политика «не знаю» и escalation
  • [ ] Решение по privacy (SaaS LLM / VPC / on-prem)
  • [ ] Мониторинг стоимости и p95

Итог

RAG в OtherCode — это инженерия корпуса, retrieval и оценки, а не один системный промпт. Мы собираем контуры уровня URAP: документы, цитаты, гибрид с правилами, CI и возможность on-prem для enterprise. Там, где достаточно поиска или калькулятора, не тащим LLM ради галочки.

Если нужно внедрить ответы по вашим документам без сюрпризов в production — оставьте заявку.