Создание RAG системы: архитектура пилота, данные и eval

Раздел

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

Сложность

средняя

Обновлено

2026-05-22

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

Создание RAG системы начинается с пилота, а не с “загрузим всю базу знаний”. Сначала выберите один домен, соберите проверенный корпус, примените права до retrieval, добавьте citations, сделайте eval-набор и только потом решайте, расширять ли систему.

Рабочий первый релиз: 50-200 документов, один владелец корпуса, 80-150 тестовых вопросов, negative cases, журнал ошибок, rollback индекса и понятные stop rules. Модель, vector store и framework важны, но они не спасают пилот, если данные устарели, права применяются после факта, а качество никто не измеряет.

Эта страница продолжает общий хаб RAG система, но не дублирует RAG базу знаний и оценку качества RAG. Здесь фокус уже на архитектуре пилота: что собрать за первые две недели, как проверить retrieval и когда остановиться.

Краткий brief

Архитектура пилота

Пилот должен отвечать на один рабочий вопрос: может ли система давать проверяемые ответы по конкретному корпусу лучше, чем текущий поиск или ручной разбор. Если цель звучит как “сделать AI по всем документам”, scope слишком широкий.

Минимальная схема:

approved sources
  -> ingestion and cleanup
  -> chunks with metadata and access groups
  -> retrieval with filters
  -> answer generation with citations
  -> eval, logs and owner feedback

AWS в RAG overview описывает базовые компоненты production RAG: connectors, data processing, embeddings, vector database, retriever, foundation model, guardrails, orchestrator, user experience and identity management. Практический вывод для пилота простой: не надо спорить о модели, пока не описаны источники, права, retrieval и проверки.

Для первого домена выберите одну из задач:

Данные и ownership

RAG пилот почти всегда ломается на данных. Нужен source inventory, где видно, какие документы входят в корпус, кто владелец, как часто они меняются и какие права у пользователя.

rag_pilot_source:
  id: support_runbooks_v1
  owner: support_ops
  status: approved
  access_groups: [support_l1, support_l2]
  freshness_sla_hours: 24
  included_formats: [markdown, html]
  excluded:
    - drafts
    - archived_pages
    - personal_notes
    - incident_logs_with_customer_data

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

Проверки перед ingestion:

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

Retrieval design

Retrieval должен быть проще, чем презентация о нем. Для пилота обычно достаточно hybrid search, metadata filters, reranking только при необходимости и жесткого требования: ответ должен показывать источник или отказываться.

Microsoft в документации Azure AI Search разделяет classic RAG и agentic retrieval. Там же описаны security trimming, query-time filters, citations and execution metadata. Значит, в архитектуре надо заранее решить, какой режим нужен:

Не включайте agentic retrieval только потому, что это звучит современно. Если пользователь спрашивает “где инструкция по возврату”, обычный поиск с citation часто надежнее. Если он спрашивает “можно ли закрыть инцидент после трех неудачных попыток связи, если клиент enterprise”, агентный retrieval может сначала найти SLA, потом exception policy, потом шаблон handoff.

Eval before tuning

Eval нужен до tuning и до расширения корпуса. Иначе команда будет улучшать систему на ощущениях.

Минимальный тестовый пример:

{
  "question": "можно ли закрыть инцидент без подтверждения клиента",
  "user_group": "support_l1",
  "expected_source": "support_runbooks/incident-close",
  "expected_behavior": "answer_with_citation_or_escalate",
  "must_not_use": ["drafts/old-incident-policy"],
  "critical_errors": ["uses_deprecated_source", "no_citation", "allows_auto_close"]
}

RAGAS и похожие frameworks помогают автоматизировать часть оценки, но владелец знаний все равно нужен. Автоматическая метрика не знает, какой пункт договора юридически критичен, а какой устарел после последнего согласования.

Разделите eval на четыре слоя:

План пилота на 14 дней

В пилоте не нужен “идеальный AI”. Нужен понятный ответ: какие вопросы система закрывает, где честно отказывается и какие ошибки нельзя выпускать за пределы пилотной группы.

Stop rules

Stop rules надо написать до запуска. Иначе плохой RAG будет расширяться, потому что “уже много сделали”.

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

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

Если сработал stop rule, не меняйте только prompt. Сначала смотрите corpus, access filters, chunking, metadata, retrieval thresholds и список документов.

Чеклист

• У пилота один домен и один владелец результата.
• Source inventory содержит owner, status, date, access group и freshness SLA.
• Draft, archive, personal notes и sensitive logs исключены.
• Права применяются до retrieval.
• Chunking сохраняет заголовки, таблицы, версии и исключения.
• В каждом ответе есть citation или отказ.
• Eval-набор содержит реальные вопросы, вопросы без ответа и проверки прав.
• Retrieval и generation оцениваются отдельно.
• Есть журнал ошибок и владелец исправлений.
• Есть rollback индекса.
• Есть stop rules до расширения корпуса.
• Внутренние ссылки ведут в RAG hub, RAG базу знаний, eval и локальный RAG.

FAQ

С чего начать создание RAG системы?

С одного домена и source inventory. Если команда не может назвать владельца документов и правила доступа, начинать с vector store рано.

Нужен ли локальный RAG для пилота?

Не всегда. Локальный контур нужен при жестких требованиях к данным, сети или регуляторике. Если документы можно обрабатывать в управляемом облаке с нужными правами, облачный пилот быстрее и дешевле для проверки гипотезы.

Чем RAG пилот отличается от поиска по документам?

Поиск возвращает источники. RAG добавляет ответ на основе этих источников. Поэтому RAG требует более строгих citations, refusal rules и eval, чем обычная строка поиска.

Сколько документов нужно для первого релиза?

Чаще достаточно 50-200 хороших документов. Тысячи страниц без owner и статуса ухудшают качество, потому что retrieval начинает находить похожий шум.

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

Для общей карты откройте RAG систему, для корпуса - RAG базу знаний, для проверки - оценку качества RAG, для размещения - локальный RAG.