Разработка RAG систем: ТЗ, приемка и контроль качества

Раздел

RAG и базы знаний

Сложность

средняя

Обновлено

2026-05-22

Короткий ответ

Разработка RAG систем должна начинаться с ТЗ на знания, права и приемку, а не с выбора vector database. Заказчик должен описать корпус документов, владельцев источников, правила доступа, типовые вопросы, критичные ошибки, eval-набор, SLA обновления и условия остановки пилота.

Хорошее ТЗ отвечает на три вопроса: какие источники считаются правдой, как система доказывает ответ ссылками и кто отвечает за качество после запуска. Если подрядчик обещает “RAG по всем документам” без source inventory, security trimming, acceptance tests и журнала ошибок, это не проект, а демо.

Эта статья закрывает запрос разработка rag систем и дополняет практический материал Создание RAG системы. Там фокус на архитектуре пилота, здесь - на заказе, приемке, контроле качества и ownership. Для общей карты откройте RAG систему, для тестов - оценку качества RAG, для бюджета - стоимость LLM API.

Краткий brief

Что должно быть в ТЗ

ТЗ для RAG - это не “подключить документы к нейросети”. Минимальный состав:

AWS в RAG overview выделяет production-компоненты: connectors, data processing, embeddings, vector database, retriever, foundation model, guardrails, orchestrator, UX and identity management. Для ТЗ это значит: нельзя принять только чат-интерфейс. Нужно принять весь контур от источника до доступа пользователя.

Source inventory

Без списка источников RAG быстро превращается в поиск по случайному архиву. Source inventory должен быть частью поставки.

source:
  id: support_contracts_v1
  owner: legal_ops
  status: approved
  freshness_sla_days: 30
  access_groups: [support_l2, legal]
  canonical_url: https://intranet.example/contracts/support
  excluded:
    - drafts
    - personal_notes
    - archived_versions

Проверьте:

• у каждого документа есть владелец и статус;
• черновики, архивы и личные заметки исключены;
• пользовательские права применяются до поиска, а не после ответа;
• citation ведет к конкретному разделу или документу;
• есть процедура удаления устаревшего источника из индекса;
• владелец источника отвечает за исправление найденных ошибок.

Документ без owner лучше не индексировать. Его можно отправить в cleanup, но нельзя делать authoritative source для ответа пользователю.

Acceptance tests

Приемка RAG должна проверять retrieval и generation отдельно. Иначе команда видит красивый ответ, но не понимает, нашла ли система правильный источник.

Пример acceptance case:

{
  "question": "можно ли вернуть оплату после частичного оказания услуги",
  "user_group": "support_l2",
  "expected_sources": ["contracts/refund-policy", "support/runbook-refunds"],
  "expected_behavior": "answer_with_citations_and_escalation_note",
  "critical_errors": [
    "uses_archived_policy",
    "no_citation",
    "promises_refund_without_legal_review"
  ]
}

Матрица приемки:

Microsoft в Azure AI Search RAG overview отдельно выделяет challenges вокруг query understanding, multi-source data access, token constraints, response time, security and governance. Используйте это как чек-лист приемки: RAG должен быть не только точным, но и управляемым по доступам, latency и источникам.

Eval и метрики качества

Eval для RAG не должен сводиться к “понравился ответ”. Нужны разные уровни:

Ragas описывает метрики для RAG вроде context precision, context recall, noise sensitivity, response relevancy и faithfulness. Эти метрики полезны как инструмент, но финальную приемку все равно должен подписывать владелец предметной области: автоматическая оценка не знает, какой пункт договора юридически критичен.

Минимальный eval-набор:

• 50-80 типовых вопросов;
• 20-40 сложных вопросов с несколькими источниками;
• 20 negative cases, где ответ должен быть отказом или escalation;
• 10-20 регрессионных кейсов после каждой смены модели, prompt или индекса;
• отдельные проверки прав доступа для закрытых документов.

Ownership и эксплуатация

RAG система деградирует, когда меняются документы, продукты, цены, правила поддержки и права. Поэтому в ТЗ должен быть не только launch, но и эксплуатация.

NIST AI RMF полезен как общий язык риска: качество AI-системы зависит не только от модели, но и от контекста применения, управления, измерения и сопровождения. В RAG это особенно заметно: старый документ, плохие права или отсутствующий owner могут быть опаснее слабой модели.

Поставка подрядчика

Принимайте не “чат с документами”, а набор артефактов.

Обязательные deliverables:

• source inventory;
• схема ingestion и обновления индекса;
• правила chunking и metadata;
• описание access control и forbidden sources;
• список prompt, tools и retrieval parameters;
• eval dataset и результаты прогонов;
• acceptance matrix с pass/fail;
• журнал известных ограничений;
• runbook обновления, мониторинга и rollback;
• cost model: embeddings, storage, retrieval, model calls, retries, review.

Если подрядчик не передает eval-набор и runbook, заказчик не сможет безопасно поддерживать систему после релиза. Это особенно важно, если RAG обрабатывает договоры, поддержку, внутренние регламенты или персональные данные.

Stop rules

Stop rules нужно записать до пилота. Иначе слабую систему будут расширять, потому что уже потрачен бюджет.

Останавливайте пилот, если:

• закрытый документ попал в ответ неавторизованному пользователю;
• система отвечает без citation, когда источник обязателен;
• устаревший источник регулярно побеждает актуальный;
• владельцы знаний не исправляют найденные ошибки;
• negative cases получают уверенный ответ;
• стоимость успешного ответа растет быстрее качества;
• невозможно объяснить, почему выбран конкретный источник;
• откат индекса не проверен.

После сработавшего stop rule не начинайте с переписывания prompt. Сначала проверьте corpus, права, chunking, metadata, retrieval thresholds и source inventory.

Чеклист приемки

• ТЗ описывает один домен, а не “все документы компании”.
• Source inventory содержит owner, status, freshness и access groups.
• Draft, archive и personal notes исключены из индекса.
• Права применяются до retrieval.
• Каждый ответ содержит citation или честный отказ.
• Retrieval и generation проверяются отдельно.
• Eval-набор содержит типовые, сложные, negative и regression cases.
• Есть acceptance matrix с критичными ошибками.
• Есть журнал ошибок и владелец исправлений.
• Есть runbook обновления индекса.
• Есть cost model и лимиты.
• Есть rollback индекса и stop rules.

FAQ

Чем разработка RAG систем отличается от создания RAG системы?

Создание RAG системы - это практическая архитектура и сборка пилота. Разработка RAG систем как заказ - это ТЗ, приемка, права, eval, эксплуатация и ответственность после запуска.

Можно ли принять RAG по демо?

Нет. Демо показывает, что интерфейс работает на нескольких вопросах. Приемка должна проверять источники, права, refusal, stale documents, negative cases и регрессии.

Кто должен готовить eval-набор?

Подрядчик может помочь с форматом, но вопросы и критичные ошибки должен утверждать владелец предметной области. Иначе eval будет проверять техническую красивость, а не рабочий риск.

Сколько вопросов нужно для первого acceptance?

Для первого домена обычно достаточно 80-150 вопросов, если в них есть типовые, сложные, negative и regression cases. Объем меньше важен, чем качество покрытия.

Что читать дальше?

Для архитектуры пилота откройте Создание RAG системы, для базы знаний - RAG база знаний, для измерения - Оценка качества RAG, для стоимости - Стоимость LLM API. Если команда выбирает между RAG и обучением модели, смотрите RAG или fine-tuning.