Satel Generation: RAG, evaluation и production ownership

Базовый ответ: ingestion, chunking, embeddings, vector index, retrieval, reranking, context assembly, generation. Дальше надо объяснить, были ли domain embeddings, cross-encoder reranker, hybrid search и как это оценивалось.

Архитектура не ограничивается словом "RAG". Pipeline раскладывается на шаги: документы очищаются и чанкуются, для чанков считаются эмбеддинги, они кладутся в vector DB, на запросе делается retrieval top-k, затем возможен reranking, сбор контекста и генерация ответа.

Если система простая, это нормально сказать, но стоит добавить, что можно улучшить: hybrid BM25 + dense retrieval, domain-specific embedding model, query rewriting, metadata filters, cross-encoder reranker, дедупликация чанков и контроль длины контекста.

Для конфиденциальных данных важно проговорить self-hosted модели или private deployment, а также мониторинг качества и latency.

Chunking идет по структуре документа: раздел, статья, пункт, таблица, definition. Каждый chunk хранит metadata, parent section, overlap и ссылки на источник.

В legal RAG fixed-size chunking часто ломает смысл. Один пункт может зависеть от заголовка, определения выше по тексту или соседнего подпункта. Поэтому pipeline сначала парсит документ: заголовки, статьи, пункты, подпункты, таблицы, приложения, определения и ссылки на другие разделы.

Chunk строится вокруг смыслового блока. Если пункт короткий, к нему добавляется parent heading и соседний контекст. Если пункт длинный, он делится с overlap и сохраняет ссылку на исходный раздел. Metadata хранит документ, версию, дату, jurisdiction, раздел, номер статьи, тип блока и права доступа.

Качество chunking проверяется через retrieval tasks. Если нужный ответ часто требует два соседних чанка, нужно менять overlap или context assembly. Если retrieval возвращает огромные chunks, генератор получает лишний текст и хуже цитирует источник.

После retrieval reranker сортирует top-K, дедупликация убирает повторяющиеся chunks, context assembly собирает компактный набор с цитатами и лимитом токенов.

Dense или hybrid retriever отвечает за recall: нужные chunks должны попасть в top-K. Дальше reranker смотрит на query и chunk вместе и переставляет результаты по точной релевантности. Для legal RAG это может быть cross-encoder, learning-to-rank модель или LLM-judge на маленьком top-N, если latency позволяет.

После reranker pipeline убирает дубли, объединяет соседние chunks, сохраняет parent headings и не кладет в prompt несколько почти одинаковых фрагментов. Context assembly выбирает набор, который помещается в токен-бюджет и покрывает разные аспекты вопроса.

Метрики разделяются. Для retriever команда смотрит recall@K и hit rate. Для reranker - nDCG, MRR и precision@top. Для финального ответа - groundedness, цитаты, полнота и доля случаев, где система честно отвечает, что данных не хватает.

Нужно оценивать отдельно retrieval и generation: recall@k/MRR/nDCG для поиска, faithfulness/groundedness/context precision для ответа, плюс ручная разметка, regression set и online метрики.

Для retrieval нужны вопросы с релевантными документами или чанками. Метрики: recall@k, precision@k, MRR, nDCG, hit rate, coverage. Это показывает, принесла ли система правильный контекст.

Для generation нужны другие проверки: отвечает ли модель на вопрос, основан ли ответ на контексте, нет ли hallucination, корректны ли цитаты, насколько ответ полезен пользователю. Можно использовать ручную разметку, LLM-as-judge и инструменты вроде RAGAS, но важно валидировать judge на человеческой выборке.

В production добавляются latency, cost, fallback rate, доля "не знаю", пользовательский feedback, частота escalations и monitoring drift по типам вопросов.

API принимает вопрос, проверяет доступ, нормализует query, запускает BM25/dense retrieval, reranker, context assembly, vLLM generation, citations, fallback и logging.

Production request начинается в API. Сервис проверяет пользователя и права доступа к документам, нормализует запрос, добавляет metadata filters и запускает retrieval. Lexical/BM25 слой ловит точные юридические формулировки, Qdrant или другой vector DB возвращает semantic candidates.

Ranker service получает top-K chunks, query и metadata, затем выбирает финальный порядок. Context builder собирает prompt: короткая инструкция, выбранные chunks, ссылки на источники и правило "не отвечать без поддержки в контексте". vLLM или другой self-hosted inference отвечает, а API возвращает текст, citations, confidence/fallback reason и trace id.

MLflow хранит версии embedding model, reranker и generation config. Логи сохраняют latency по stage, top chunks, версии моделей, fallback, ошибки, стоимость и feedback. Эти данные нужны для regression, rollback и анализа качества после запуска.

Нужно зафиксировать service contract, входы/выходы, качество на regression set, latency/cost SLO, canary или shadow rollout, мониторинг данных/модели/сервиса и понятный rollback.

Production-readiness начинается с контракта системы: какие входы принимает сервис или batch job, какие выходы возвращает, какие ошибки допустимы, кто потребляет результат и какое действие продукта от него зависит. Для RAG это retrieval, reranking, context assembly, generation и citations; для moderation - score, threshold, policy layer, ручная очередь и audit logs.

Перед rollout нужны quality gates: offline regression set, проверка edge cases, data validation, совместимость feature schema или prompt/config versions, нагрузочный тест и бюджет latency/cost. Если модель меняет user-facing действие, запуск лучше делать через shadow, canary или ограниченный процент трафика с явными stop conditions.

В эксплуатации надо мониторить не только CPU и ошибки API. Нужны freshness и coverage данных, missing features, drift, качество по delayed labels или ручной выборке, fallback rate, latency по стадиям, стоимость inference, версии модели/индекса/prompt и trace id для разбора ошибок. Rollback должен быть заранее понятен: вернуть старую модель, старый индекс, старый threshold или отключить автоматическое действие.

Сервис принимает text, user/content metadata и policy context, возвращает scores по классам, action, threshold reason, model version и trace id для модераторской очереди.

Moderation pipeline лучше делать каскадом. Сначала быстрые правила и policy layer обрабатывают очевидные blocklist, allowlist, язык, пустой текст и запрещенные паттерны. Затем модель получает нормализованный текст и metadata, считает scores по классам: toxic, hate, insult, spam, sexual, clean или доменные категории.

После модели decision layer применяет thresholds. Высокая уверенность в нарушении ведет к block или hide. Средняя уверенность отправляет объект в manual review. Низкий риск пропускает контент. Ответ API должен включать action, scores, model version, threshold reason, policy version и trace id.

Для production важны latency, batching, CPU/GPU cost, fallback при недоступности модели, audit logs и возможность менять thresholds без переобучения. Модераторы должны видеть причину попадания в очередь и исходный текст без лишних догадок модели.

Данные приходят из ручной модерации, жалоб, исторических решений, open datasets и augmentation. Label taxonomy фиксирует классы, инструкции, ambiguous cases и disagreement handling.

Сначала команда фиксирует policy taxonomy: какие классы действительно нужны продукту и какие действия они запускают. Например, clean, toxic, hate, insult, spam, self-harm или доменные нарушения. Для каждого класса нужны инструкции и примеры, иначе модераторы будут размечать разные вещи под одним названием.

Источники данных: историческая ручная модерация, жалобы пользователей, выборка обычного контента, open datasets, перевод/augmentation и специально собранные hard cases. Исторические решения нельзя брать без проверки, потому что политика могла меняться, а очередь модерации уже смещена в сторону подозрительного контента.

Дисбаланс решается не только oversampling. Нужны stratified batches, class weights или focal loss, отдельный validation set по редким классам, adjudication спорных примеров и регулярное обновление данных после изменения политики.

Offline считаются precision/recall/F1 per class и confusion matrix. Online смотрят block/pass/review rates, appeals, moderator agreement, latency, queue load и safety incidents.

Offline-метрики считаются по классам, потому что ошибка toxic != ошибка spam. Для auto-block обычно важна precision: продукт не хочет блокировать нормальный контент. Для dangerous content может быть важнее recall: система не должна пропускать критичные нарушения. Поэтому thresholds выбираются отдельно под action.

Online-метрики связывают модель с workflow. Команда смотрит долю auto-pass, auto-block и manual review, acceptance rate модераторов, appeal rate, повторные жалобы, queue backlog, время обработки, latency API и долю fallback при ошибках сервиса.

После запуска нужен мониторинг drift и policy changes. Если меняется язык пользователей, спам-атака или правила модерации, старый validation set перестает отражать реальность. Тогда команда добавляет свежую audit sample, пересматривает thresholds и обновляет regression suite.