Почти любая RAG-система ломается не в модели, а на стыках загрузки знаний, извлечения контекста, оркестрации ответа и проверок безопасности.
Глава раскладывает рабочий контур на части и показывает, как загрузка знаний, ранжирование, защитные ограничения, оценивание и контроль стоимости вместе определяют, будет ли ответ действительно полезным.
Для интервью и архитектурных разговоров она полезна как способ обсуждать RAG не как быстрый прототип, а как систему с SLO, режимами отказа и эксплуатационными компромиссами.
Практическая польза главы
Практика проектирования
Переводите знания о рабочей RAG-архитектуре, качестве извлечения контекста и управлении знаниями в архитектурные решения для потоков данных, сервинга моделей и контрольных точек качества.
Качество решений
Оценивайте систему через метрики модели и платформы одновременно: precision/recall, задержки, дрейф, стоимость и операционные риски.
Аргументация на интервью
Структурируйте ответ как цепочку данные -> модель -> сервинг -> мониторинг, показывая, где возникают ограничения и как вы ими управляете.
Явные компромиссы
Явно фиксируйте компромиссы по рабочей RAG-архитектуре, качестве извлечения контекста и управлении знаниями: скорость экспериментов, качество, объяснимость, бюджет ресурсов и сложность поддержки.
Основной источник
Retrieval-Augmented Generation (2020)
Работа, которая формализовала RAG как подход, где генерация опирается на извлечение контекста из внешних источников.
GenAI/ System Architecture — это не один сервис вокруг , а связка нескольких контуров: загрузки знаний, , оркестрации ответа, и операционного оценивания качества. Пригодной к рабочей эксплуатации система становится только тогда, когда эти контуры проектируются как единый контракт по задержке, качеству и стоимости.
Дальше — практическая схема, с которой можно стартовать архитектуру корпоративного AI-ассистента, помощника по базе знаний или бота поддержки.
Референсная архитектура генерации с извлечением контекста (GenAI/RAG)
Диаграмма показывает -контур по слоям: от загрузки знаний и индекса до генерации ответа, защитных ограничений и резервного пути.
Что держать под контролем
RAG-контур полезно смотреть не только как цепочку сервисов, но и как баланс качества извлечения, задержки ответа, стоимости и безопасности выпуска.
Качество извлечения
Рабочие ограничения
Безопасный выпуск
Путь запроса: от вопроса до ответа с опорой на источники
Ниже показан синхронный путь -запроса: от первичных проверок вопроса через извлечение и сборку контекста до ответа с цитатами, ссылками на источники и финальными проверками.
Как вопрос проходит через RAG-контур
Синхронный путь от запроса до ответа с цитатами и проверками
Активный шаг
Бюджет шага: ~30-80 ms1. Вопрос и предварительные проверки
Система нормализует запрос, определяет сценарий, отсекает вопросы вне домена и запускает ранние проверки правил до извлечения контекста.
Онлайновый путь ответа с опорой на источники
- Контур жёстко ограничен задержкой.
- Качество извлечения контекста влияет на итог не меньше, чем сама модель.
- Проверки доступа и защитные ограничения работают и до генерации, и после неё.
Исследование
Chroma: Evaluating Chunking Strategies (2024)
Сравнение стратегий чанкинга на единых метриках: разница между наивной и продуманной нарезкой достигает 9% полноты (recall) на одном корпусе.
Стратегии чанкинга: нарезка корпуса задаёт потолок качества
— первое архитектурное решение платформы знаний: всё, что нарезано неудачно, не спасут ни , ни промпт. Каждая стратегия ниже разобрана по одной схеме: как работает, какой компромисс приносит и когда её выбирать.
Фиксированные окна (fixed-size)
Как работает: Текст режется на окна по 200-800 токенов с перекрытием 10-20% без оглядки на структуру документа. Реализуется одной функцией, а стоимость индексации предсказуема и легко считается заранее.
Компромисс: Граница окна попадает в середину предложения, таблицы или примера кода, и факт, разрезанный пополам, не находится ни по одной из половин. Перекрытие частично страхует границы, но раздувает индекс и плодит дубликаты в первых k результатах (top-k).
Когда выбирать: Базовый вариант для первого запуска и однородных текстов без выраженной структуры. С него стоит начинать, чтобы получить точку отсчёта для метрик, а не как финальное решение.
По структуре документа (structure-aware)
Как работает: Нарезка идёт по естественным границам: заголовкам, абзацам, спискам и таблицам. Рекурсивное деление спускается по иерархии разделителей — сначала разделы, затем абзацы, затем предложения, — пока чанк не уложится в лимит.
Компромисс: Чанки совпадают со смысловыми границами, а путь заголовков бесплатно попадает в метаданные. Цена: размер чанков скачет от пары строк до целого раздела, и под каждый формат (Markdown, HTML, PDF, wiki) нужен свой парсер.
Когда выбирать: Документация, базы знаний, регламенты и контракты, где автор уже разметил структуру. На корпусах с сильными внутренними границами выигрыш относительно наивной нарезки максимален.
Семантический чанкинг (semantic)
Как работает: Эмбеддинги соседних предложений сравниваются между собой, и граница чанка ставится там, где сходство резко падает, то есть на смене темы. Вариант с разметкой границ большой языковой моделью (LLM) ещё точнее, но и заметно дороже.
Компромисс: В отчёте Chroma (2024) семантические стратегии и разметка большой языковой моделью дали до ~92% полноты (recall) против ~88% у рекурсивной нарезки — единицы процентов выигрыша за заметно более дорогую индексацию. Границы к тому же привязаны к модели эмбеддингов: её замена меняет нарезку.
Когда выбирать: Длинные слитные тексты без явной структуры: расшифровки звонков, исследования, лонгриды. Выбирайте, когда полнота первичного поиска упирается именно в неудачные границы, а не в качество эмбеддера.
Размер чанка: точность против контекста
Маленькие чанки (~128-256 токенов) дают точечные попадания и высокую точность (precision), но отрывают факт от окружения: условие из соседнего абзаца теряется. Большие (~512-1024) чаще захватывают ответ целиком, но тянут в контекст шум и быстрее съедают окно модели. Подбирайте размер по метрикам на собственном эталонном наборе, а не по чужим дефолтам.
Перекрытие (overlap)
Перекрытие 10-20% страхует факты, попавшие на границу окна: фраза, разрезанная одним чанком, целиком живёт в соседнем. Но каждый процент перекрытия — это рост индекса и дубликаты среди соседних чанков в первых k результатах, поэтому перед сборкой контекста нужна дедупликация почти одинаковых фрагментов.
Метаданные чанка
У каждого чанка должны быть источник и версия документа, путь заголовков, дата обновления, список управления доступом (ACL) или арендатор и тип контента. Именно метаданные превращают индекс в управляемую систему: они дают фильтры до поиска, цитаты в ответе и точечную инвалидацию при переиндексации изменившегося документа.
Гибридный поиск: лексика, векторы и слияние списков
Ни один способ поиска не покрывает все запросы: поверх буквально находит точные термины, плотный поиск ловит смысл, а объединяет оба списка так, чтобы сильные стороны не усредняли друг друга.
Лексический поиск: формула BM25
Как работает: Классика полнотекстового поиска поверх инвертированного индекса: вес термина растёт с частотой в документе с насыщением и нормируется на длину документа (типовые параметры k1 = 1.2, b = 0.75). Именно формула BM25 используется по умолчанию в Lucene, Elasticsearch и OpenSearch.
Компромисс: Точные совпадения отрабатывают идеально: коды ошибок, артикулы, имена API и аббревиатуры находятся буквально. Но синонимы и перефразированные вопросы для формулы BM25 невидимы: «как удалить учётку» и «деактивация аккаунта» — разные запросы.
Когда выбирать: Запросы с точными идентификаторами и редкими терминами. В корпоративном поиске это постоянный случай: номера тикетов и договоров, коды ошибок, названия внутренних сервисов.
Плотный (dense) поиск по эмбеддингам
Как работает: Bi-encoder заранее превращает каждый чанк в вектор; запрос кодируется той же моделью, а индекс приближённого поиска соседей (обычно HNSW) находит ближайшие векторы за миллисекунды даже на миллионах чанков.
Компромисс: Ловит смысл, синонимы и перефразирования, работает между языками. Но редкие точные токены размываются: запрос с кодом «ERR-1042» вернёт чанки про похожие ошибки, а не именно эту. На внутреннем жаргоне, которого эмбеддер не видел при обучении, качество падает.
Когда выбирать: Вопросы на естественном языке, синонимия, многоязычный корпус. Основной режим для ассистентов по базе знаний — но в одиночку он проигрывает гибриду на точных терминах.
Слияние списков: Reciprocal Rank Fusion
Как работает: Каждый источник возвращает свой ранжированный список, и итоговый скор документа считается как сумма 1/(k + rank) по всем спискам (k = 60 в оригинальной работе Cormack et al., 2009). Скоры движков игнорируются — только позиции, поэтому несравнимые шкалы формулы BM25 и косинусной близости не нужно нормализовать.
Компромисс: RRF премирует консенсус: документ на десятом месте в обоих списках обойдёт лидера только одного из них. Цена — потеря информации о силе совпадения; при сильно неравных по качеству источниках простой сумме понадобятся веса.
Когда выбирать: Дефолтный способ слияния для гибридного поиска: одна формула без обучения и нормализации, встроенная в Elasticsearch, OpenSearch, Qdrant, Weaviate и большинство векторных движков.
Фильтры по метаданным: до или после поиска
Фильтрация по , арендатору и свежести — не деталь реализации, а граница безопасности: применить фильтр до обхода индекса или после — решение, от которого зависит и качество выдачи, и то, участвуют ли запрещённые документы в ранжировании вообще.
Pre-filter: маска до обхода индекса
Как работает: Фильтры по метаданным — список управления доступом (ACL), арендатор, свежесть, тип документа — строят маску допустимых чанков до векторного поиска, и обход векторного индекса рассматривает только разрешённые вершины.
Компромисс: Гарантирует, что в первые k результатов попадают только допустимые документы. Но очень селективный фильтр на классическом HNSW рвёт связность графа и ломает качество обхода — поэтому движки строят filterable-индексы, встраивающие фильтр прямо в навигацию по графу (так делает, например, Qdrant).
Когда выбирать: Права доступа и границы арендатора — всегда pre-filter: документ, который пользователю нельзя видеть, не должен даже участвовать в поиске. Это требование безопасности, а не оптимизация качества.
Post-filter: отсев после поиска
Как работает: Сначала выполняется обычный векторный поиск, затем из первых k результатов выбрасываются те, что не прошли фильтр по метаданным.
Компромисс: Не трогает индекс и прост в реализации, но при селективном фильтре выдача схлопывается: искали 10 ближайших, после фильтра осталось 1-2, и приходится перезапрашивать с большим k. Когда фильтр — это список управления доступом (ACL), появляется ещё и риск: недопустимый документ уже участвовал в ранжировании.
Когда выбирать: Слабо селективные фильтры без требований безопасности: тип контента, язык, грубая отсечка по дате — случаи, когда отфильтровывается малая доля кандидатов.
Повторное ранжирование: дорогая точность поверх дешёвого охвата
разводит две несовместимые цели по разным этапам: первичный поиск отвечает за охват и дёшев, cross-encoder отвечает за точность и дорог — поэтому его пускают только по короткому списку кандидатов.
1. Широкое извлечение: top-100 кандидатов
~30-80 msГибридный поиск собирает широкий список кандидатов. На этом этапе важна полнота (recall) — нужный документ обязан попасть в выборку, а точность порядка вторична: расширение k здесь почти бесплатно.
2. Cross-encoder: повторное ранжирование пар
~50-300 msCross-encoder читает пару «запрос + чанк» одним проходом и видит взаимодействие токенов, поэтому ранжирует точнее bi-encoder'а — но ничего нельзя предвычислить: k полных проходов модели на каждый запрос. Лёгкие модели уровня MiniLM обрабатывают ~100 пар за десятки миллисекунд на GPU; API-реранкеры дают порядка 100-400 ms вместе с сетью.
3. Отбор top-5 в контекст
~0 msВ контекст большой языковой модели уходит короткий точный список вместо длинного шумного. Меньше токенов — дешевле генерация, слабее эффект lost in the middle и ниже шанс, что модель обопрётся на нерелевантный чанк.
Цена и выигрыш
Бюджет повторного ранжирования «retrieve 100 → rerank → top 5» добавляет к ответу примерно 100-300 ms, но в типичных замерах даёт двузначный прирост доли запросов, где нужный документ попал в финальный контекст. Экономически реранкер почти всегда выгоднее альтернативы — скармливать большой языковой модели 30-50 чанков «на всякий случай»: длинный контекст дороже по токенам и хуже используется моделью.
Чего реранкер не лечит
Cross-encoder только переставляет уже найденное. Если нужного документа нет в top-100 первичного поиска, переранжированию нечего спасать — сначала чините чанкинг, эмбеддер или слияние источников. Поэтому полноту смотрят парой метрик: recall@100 для первичного поиска и recall@5 после реранкера.
Оценка качества извлечения контекста: метрики, эталоны и дрейф
— единственная часть , которую можно измерять детерминированно и дёшево, без -судьи. Поэтому контур оценки строится от -метрик: , MRR и на эталонном наборе ловят регрессии до выката, а онлайн-сигналы подтверждают их на живом трафике.
| Метрика | Что измеряет | Когда смотреть |
|---|---|---|
| recall@k | Попал ли релевантный документ в первые k результатов вообще, без учёта порядка. | Главная метрика потолка системы: чего нет в выдаче, того большая языковая модель не увидит ни при каком промпте. Смотрите при k финального контекста и при k первичного поиска. |
| MRR | Насколько высоко стоит первый релевантный результат: среднее значение 1/rank по запросам. | Сценарии с одним правильным ответом: фактологические вопросы, поиск конкретного регламента. Метрика чувствительна именно к верхушке выдачи. |
| nDCG@k | Качество всего ранжирования с учётом градаций релевантности и логарифмического дисконта позиции. | Выдачи, где релевантных документов много и они разной полезности; стандартный способ сравнивать ранжировщики между собой. |
Golden set: размеченный эталон
Основа оффлайн-оценки: реальные запросы из логов с разметкой, какие документы и факты релевантны. Синтетика (большая языковая модель генерирует вопросы по чанкам) дёшево расширяет покрытие, но требует ручной проверки выборки — иначе вы измеряете способность модели отвечать на собственные вопросы.
Ловушка: Размечайте релевантность на уровне документов и фактов, а не идентификаторов чанков: смена стратегии чанкинга или переиндексация перенумерует чанки и молча обнулит разметку.
Оффлайн-контур: регрессионный гейт
Метрики recall@k (полнота в топ-k), MRR и nDCG (нормализованный дисконтированный выигрыш) на golden set прогоняются при каждом изменении пайплайна: новой стратегии чанкинга, другой модели эмбеддингов, параметрах слияния, версии реранкера. Это превращает настройку извлечения контекста из «на глаз стало лучше» в управляемый эксперимент.
Ловушка: Оффлайн-метрики сравнимы только при зафиксированном корпусе: если индекс изменился между прогонами, разница в полноте — это смесь эффекта изменения и дрейфа данных.
Онлайн-сигналы
В проде прямых меток нет, поэтому смотрят на косвенные сигналы: долю ответов с цитатами, долю честных отказов «не нашёл», клики по источникам, повторные переформулировки одного вопроса, явный фидбек. Сегментируйте по типам запросов: средние значения прячут деградацию отдельных сценариев.
Ловушка: Онлайн-сигналы запаздывают и шумят: падение качества извлечения контекста доходит до продуктовых метрик через недели. Без оффлайн-контура вы узнаете о деградации последним.
Дрейф корпуса
Корпус живёт: документы добавляются, переименовываются и устаревают, появляются новые продукты и термины. Golden set, собранный год назад, продолжает показывать зелёные метрики — на вопросах годовалой давности, а не на сегодняшнем трафике.
Ловушка: Держите в golden set свежий срез (документы и запросы последних недель), регулярно досэмплируйте запросы из прода и мониторьте долю запросов с низким скором извлечения контекста: она растёт первой, когда корпус уезжает от индекса.
Целевой уровень сервиса (SLO) и базовые ориентиры по ёмкости
Задержка
P95 < 2.0s
Разделяйте бюджет отдельно на извлечение контекста, вывод модели и постобработку.
Качество
Доля ответов с опорой на источники > 90%
Оценивайте, насколько ответ опирается на найденный контекст, а не только насколько он гладко звучит.
Экономика
Стоимость закрытой задачи в целевом коридоре
Держите стоимость под контролем через маршрутизацию моделей, кэш и лимиты на размер контекста.
Исследование
Lost in the Middle (Liu et al., 2023)
Работа, показавшая U-образную кривую: модели заметно хуже используют факты из середины длинного контекста, чем из его начала и конца.
Режимы сбоев генерации с извлечением контекста (RAG): симптом, причина, архитектурный ответ
Большинство проблем выглядят одинаково — «модель отвечает плохо» — но лечатся в разных местах пайплайна. Полезно вести каталог сбоев в формате «симптом → причина → архитектурный ответ»: он переводит разговор от «улучшить промпт» к конкретному слою, где сломан контракт. Например, при пустом — это не проблема модели, а отсутствующая ветка отказа в оркестраторе.
Уверенные галлюцинации при пустом извлечении контекста
Симптом: Система отвечает гладко и уверенно, но без цитат или с нерелевантными источниками; на вопросы вне корпуса выдаёт выдуманные детали.
Причина: Пайплайн не отличает «нашли релевантное» от «ничего не нашли»: даже при слабых скорах первые k результатов всё равно уходят в большую языковую модель, и та достраивает ответ из параметрической памяти.
Архитектурный ответ: Порог на скор извлечения контекста с явной веткой честного отказа, обязательные цитаты в контракте ответа и проверка опоры на источники на выходе — как отдельный шаг пайплайна, а не пожелание в промпте.
Lost in the middle
Симптом: Нужный факт точно был в собранном контексте, но ответ его игнорирует; качество скачет в зависимости от позиции чанка в промпте.
Причина: U-образная кривая внимания: модели стабильно лучше используют начало и конец длинного контекста, чем середину (Liu et al., 2023). Чем больше чанков «на всякий случай», тем глубже эта середина.
Архитектурный ответ: Меньше, но точнее: повторное ранжирование до top-5 вместо top-30, самые релевантные чанки в начало и конец контекста, размер контекста как явный бюджет, а не «сколько влезет».
Устаревший индекс (stale index): ответы из прошлого
Симптом: Ассистент цитирует прошлогоднюю версию политики или удалённую страницу; пользователи жалуются, что «в документации уже не так».
Причина: Индексация батчем раз в сутки или неделю без инвалидации при изменении источника. Индекс — это кэш знаний, и без стратегии инвалидации он устаревает так же тихо, как любой кэш.
Архитектурный ответ: Событийная переиндексация изменившихся документов вместо полного пересбора, версия и дата источника в метаданных чанка с фильтром «только актуальная версия», дата документа рядом с цитатой в ответе.
Prompt overflow: переполнение контекста
Симптом: На длинных диалогах качество резко падает, ответы теряют системные инструкции, цитаты обрезаются на середине.
Причина: Контекст собирается без бюджета: история диалога, чанки извлечения контекста и инструкции складываются, пока не упрутся в окно модели, и при переполнении что-то молча отрезается.
Архитектурный ответ: Явный токен-бюджет на каждый блок (система, история, извлечение контекста, ответ), приоритетное вытеснение — сначала суммаризация старой истории, затем чанки с худшим скором — и алерт на долю запросов у потолка окна.
Словарный разрыв запроса и корпуса
Симптом: Пользователи спрашивают своими словами, и извлечение контекста стабильно промахивается на целых классах запросов, хотя ответы в корпусе есть.
Причина: Пользовательский жаргон и официальная терминология корпуса не пересекаются лексически, а модель эмбеддингов не обучалась на доменных синонимах.
Архитектурный ответ: Переписывание и расширение запроса перед поиском (query rewriting), гибридный поиск вместо чисто плотного и регулярный разбор промахов извлечения контекста как источник словаря синонимов.
Рекомендации
- Проектируйте RAG как две связанные системы: платформу знаний (загрузка и индекс) и онлайн-контур ответа (извлечение контекста и генерация).
- Делайте наблюдаемость извлечения контекста первоклассной: долю попаданий, причины промахов, задержку и качество по сегментам.
- Стабилизируйте контракты: структуру чанков, фильтры запроса, блоки контекста и формат ответа для клиентов.
- Перед поэтапным запуском новой модели прогоняйте её и на теневом трафике, и на историческом эталонном наборе задач.
Частые ошибки
- Оценивать систему только BLEU/ROUGE без продуктовых метрик и проверки опоры на источники.
- Индексировать данные «как есть» без очистки, дедупликации и контроля версий источников.
- Пытаться чинить качество только текстом запроса, игнорируя качество извлечения контекста и свежесть данных.
- Применять контроль доступа после генерации ответа, а не до извлечения контекста.
Мини-чеклист запуска
- Есть каталог источников знаний и назначенные владельцы данных.
- Для каждого сценария определены метрики качества, целевой уровень сервиса (SLO) по задержке и ограничения по стоимости.
- Включены проверки правил на входе и выходе, а также аудит логов решений.
- Настроены поэтапный и теневой запуск, а также регрессионные тесты на наборе для прогонов по историческим данным.
- Сделаны резервные сценарии для отказов извлечения контекста, повторного ранжирования и провайдера большой языковой модели.
Источники
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)
- OpenAI cookbook: File Search and RAG patterns
- LlamaIndex: Production RAG guide
- LangChain docs: Retrieval and evaluation
- NVIDIA: RAG 101 and practical trade-offs
- Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023)
- Reciprocal Rank Fusion outperforms Condorcet and individual rank learning methods (Cormack et al., SIGIR 2009)
- Chroma Research: Evaluating Chunking Strategies for Retrieval (2024)
- Qdrant: A Complete Guide to Filtering in Vector Search
- Weaviate: Evaluation Metrics for Search and Recommendation Systems
Связанные главы
- 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): требования, данные, качество ответа, безопасность и мониторинг после запуска.
- An Illustrated Guide to AI Agents (short summary) - Следующий шаг после генерации с извлечением контекста (RAG): использование инструментов, планирование и оркестрация.
- Data Governance & Compliance - Контроль персональных данных (PII), происхождение датасетов и регуляторные требования для базы знаний.