Почти любая RAG-система ломается не в модели, а на стыках загрузки знаний, извлечения контекста, оркестрации ответа и проверок безопасности.
Глава раскладывает рабочий контур на части и показывает, как загрузка знаний, ранжирование, защитные ограничения, оценивание и контроль стоимости вместе определяют, будет ли ответ действительно полезным.
Для интервью и архитектурных разговоров она полезна как способ обсуждать RAG не как быстрый прототип, а как систему с SLO, режимами отказа и эксплуатационными компромиссами.
Практическая польза главы
Практика проектирования
Переводите знания о рабочей RAG-архитектуре, качестве извлечения контекста и управлении знаниями в архитектурные решения для потоков данных, сервинга моделей и контрольных точек качества.
Качество решений
Оценивайте систему через метрики модели и платформы одновременно: precision/recall, задержки, дрейф, стоимость и операционные риски.
Аргументация на интервью
Структурируйте ответ как цепочку данные -> модель -> сервинг -> мониторинг, показывая, где возникают ограничения и как вы ими управляете.
Явные компромиссы
Явно фиксируйте компромиссы по рабочей RAG-архитектуре, качестве извлечения контекста и управлении знаниями: скорость экспериментов, качество, объяснимость, бюджет ресурсов и сложность поддержки.
Основной источник
Базовая статья о RAG (2020)
Работа, которая формализовала RAG как подход к генерации с опорой на найденный контекст.
GenAI/RAG System Architecture - это не один сервис вокруг LLM, а связка нескольких контуров: загрузки знаний, , оркестрации ответа, и операционного оценивания качества. Пригодной к рабочей эксплуатации система становится только тогда, когда эти контуры проектируются как единый контракт по задержке, качеству и стоимости.
Ниже - практическая схема, которую можно использовать как стартовую архитектуру для корпоративного AI-ассистента, помощника по базе знаний или бота поддержки.
Референсная архитектура GenAI/RAG
Диаграмма показывает RAG-контур по слоям: от загрузки знаний и индекса до генерации ответа, защитных ограничений и резервного пути.
Что держать под контролем
RAG-контур полезно смотреть не только как цепочку сервисов, но и как баланс качества извлечения, задержки ответа, стоимости и безопасности выпуска.
Качество извлечения
Рабочие ограничения
Безопасный выпуск
Путь запроса: от вопроса до ответа с опорой на источники
Ниже показан синхронный путь RAG-запроса: от первичных проверок вопроса через извлечение и сборку контекста до ответа с цитатами, ссылками на источники и финальными проверками.
Как вопрос проходит через RAG-контур
Синхронный путь от запроса до ответа с цитатами и проверками
Активный шаг
Бюджет шага: ~30-80 ms1. Вопрос и предварительные проверки
Система нормализует запрос, определяет сценарий, отсекает вопросы вне домена и запускает ранние проверки правил до извлечения контекста.
Онлайновый путь ответа с опорой на источники
- Контур жёстко ограничен задержкой.
- Качество извлечения контекста влияет на итог не меньше, чем сама модель.
- Проверки доступа и защитные ограничения работают и до генерации, и после неё.
SLO и базовые ориентиры по ёмкости
Задержка
P95 < 2.0s
Разделяйте бюджет отдельно на извлечение контекста, вывод модели и постобработку.
Качество
Доля ответов с опорой на источники > 90%
Оценивайте, насколько ответ опирается на найденный контекст, а не только насколько он гладко звучит.
Экономика
Стоимость закрытой задачи в целевом коридоре
Держите стоимость под контролем через маршрутизацию моделей, кэш и лимиты на размер контекста.
Рекомендации
- Проектируйте RAG как две связанные системы: платформу знаний (загрузка и индекс) и онлайн-контур ответа (извлечение контекста и генерация).
- Делайте наблюдаемость извлечения контекста первоклассной: долю попаданий, причины промахов, задержку и качество по сегментам.
- Стабилизируйте контракты: структуру чанков, фильтры запроса, блоки контекста и формат ответа для клиентов.
- Перед поэтапным запуском новой модели прогоняйте её и на теневом трафике, и на историческом эталонном наборе задач.
Частые ошибки
- Оценивать систему только BLEU/ROUGE без продуктовых метрик и проверки опоры на источники.
- Индексировать данные «как есть» без очистки, дедупликации и контроля версий источников.
- Пытаться чинить качество только текстом запроса, игнорируя качество извлечения контекста и свежесть данных.
- Применять контроль доступа после генерации ответа, а не до извлечения контекста.
Мини-чеклист запуска
- Есть каталог источников знаний и назначенные владельцы данных.
- Для каждого сценария определены метрики качества, SLO по задержке и ограничения по стоимости.
- Включены проверки правил на входе и выходе, а также аудит логов решений.
- Настроены поэтапный и теневой запуск, а также регрессионные тесты на наборе для прогонов по историческим данным.
- Сделаны резервные сценарии для отказов извлечения контекста, повторного ранжирования и LLM-провайдера.
Источники
Связанные главы
- AI Engineering (short summary) - Инженерная рамка для AI-приложений: оценивание, выпуск изменений и рабочая эксплуатация.
- Hands-On Large Language Models (short summary) - Базовый материал по эмбеддингам, извлечению контекста и устройству LLM-систем.
- Prompt Engineering for LLMs (short summary) - Контракт запроса и практики проектирования контекста для RAG.
- Enterprise AI Copilot - Прикладной GenAI-кейс с извлечением контекста с учётом ACL, ссылками на источники, защитными ограничениями и изоляцией арендаторов.
- Оценивание и наблюдаемость для AI-систем - Как измерять опору на источники, качество извлечения контекста и поведение системы после запуска.
- Generative AI System Design Interview (short summary) - Даёт интервью-контекст для RAG: требования, данные, качество ответа, safety и мониторинг после запуска.
- An Illustrated Guide to AI Agents (short summary) - Следующий шаг после RAG: использование инструментов, планирование и оркестрация.
- Data Governance & Compliance - Контроль PII, происхождение датасетов и регуляторные требования для базы знаний.