Почему демонстрационный RAG ломается в продакшене

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

Во-первых, документ — не строка текста. В нём есть таблицы, подписи, сноски, колонтитулы, изображения, вложения и иерархия заголовков. Обычное извлечение может переставить ячейки таблицы, отделить отрицание от условия или превратить повторяющийся колонтитул в самый частый «факт» корпуса.

Во-вторых, семантическая близость не равна полезности. Для вопроса «как оформить отпуск» векторный поиск работает хорошо. Для ERR_AUTH_041, номера счёта, артикула, фамилии или точной версии API лексический алгоритм BM25 часто надёжнее. Для запроса «а что было до этого?» без истории диалога не работает ни один из них.

В-третьих, качество зависит от времени и прав. Идеальный ответ из отменённой инструкции — ошибка. Точный фрагмент чужого договора — инцидент безопасности. Фильтрация после извлечения опасна: запрещённый текст уже мог попасть в трассировку, кэш или контекст модели.

Наконец, ответ может звучать убедительно даже при пустом поиске. Поэтому проверять только финальный текст недостаточно. Нужны отдельные измерения извлечения, переранжирования, сборки контекста и генерации. Более широкий взгляд на организационную архитектуру описан в материале «Архитектура корпоративного RAG», а здесь мы сосредоточимся на инженерном контуре.

Четыре независимых класса отказов

Полезно сразу разделить ошибки:

1. Ошибка корпуса: нужного факта нет в индексе, он устарел или неправильно извлечён.
2. Ошибка поиска: факт есть, но не попал в набор кандидатов.
3. Ошибка отбора контекста: кандидат найден, но потерян при переранжировании, обрезке или дедупликации.
4. Ошибка генерации: доказательство присутствует, но модель исказила его, смешала источники или не отказалась отвечать.

Если команда хранит только вопрос и готовый ответ, эти классы неразличимы. Она меняет промпт при проблеме индекса, увеличивает top_k при ошибке прав доступа и заменяет LLM, когда виноват разбор таблицы. Промышленная система должна оставлять проверяемый след на каждом этапе.

Эталонная архитектура: загрузка, индекс, запрос, генерация и оценка

Практичная схема состоит из пяти контуров, которые можно развёртывать и измерять независимо.

Приём и нормализация

Контур загрузки получает документы из систем-источников, сохраняет неизменяемый оригинал, извлекает структуру, нормализует кодировку и формирует каноническое представление. Каждому документу нужны устойчивый source_id, версия, время действия, владелец, язык, контрольная сумма и политика доступа.

Повторная обработка должна быть идемпотентной: один и тот же документ с той же версией не создаёт дубликаты. Неудачный разбор отправляется в карантин, а не тихо исчезает. Сырые файлы и результаты каждого преобразования желательно хранить раздельно, чтобы новый парсер можно было проверить без повторной выгрузки из источника.

Индекс: фрагменты и поисковые представления

Контур индексации строит фрагменты, лексический индекс, векторы и метаданные. Один логический документ может иметь несколько представлений: небольшие дочерние фрагменты для точного поиска, родительские разделы для контекста, поля для BM25 и отдельные векторы заголовка и тела.

Индекс — производная, а не источник истины. Его должно быть возможно полностью восстановить из канонического хранилища и манифеста версий.

Запрос и генерация: поиск доказательств и ответ

Контур запроса аутентифицирует пользователя, вычисляет фильтры доступа, нормализует или переписывает вопрос, запускает несколько каналов поиска, объединяет ранги, переранжирует кандидатов и собирает контекст. Только после этого контур генерации получает инструкции, вопрос и разрешённые доказательства.

Генератор возвращает не только текст, но и ссылки на источники, признак достаточности контекста, а при необходимости — структурированный отказ. Пользовательская история не должна автоматически становиться доверенным знанием: она помогает восстановить намерение, но не заменяет корпоративный источник.

Оценка: непрерывная проверка

Контур оценки воспроизводит размеченный набор запросов, считает поисковые и генеративные метрики, сравнивает версии и блокирует опасные регрессии. Онлайн-сигналы — жалобы, исправления, переходы по цитатам, пустые результаты — дополняют, но не заменяют офлайн-набор.

Именно разделение контуров позволяет заменить модель векторов без переписывания загрузчика, сравнить два переранжировщика без смены LLM и откатить индекс независимо от приложения.

Инвентаризация источников и свежесть данных

До выбора моделей составьте реестр источников. Для каждого укажите владельца, формат, ожидаемый объём, частоту изменений, способ удаления, уровень конфиденциальности, допустимую задержку обновления и систему истины. Корпоративная энциклопедия, система управления отношениями с клиентами, Git, объектное хранилище и файловая папка имеют разные механизмы изменений; единый ночной сценарий скрывает эти различия.

Контракт свежести

«Индекс обновляется регулярно» — не контракт. Нужны измеримые интервалы:

• source_updated_at — когда запись изменилась в системе истины;
• ingested_at — когда изменение принято;
• indexed_at — когда новая версия стала доступна поиску;
• deleted_at или отметка удаления — когда удаление зафиксировано;
• valid_from и valid_to — когда содержание применимо по бизнес-смыслу.

Разница между первыми тремя отметками показывает фактическую задержку свежести. Допустимый предел определяется доменом: каталог товаров, инструкция по аварийному отключению и архив протоколов не обязаны обновляться одинаково быстро.

Изменения, удаления и конфликтующие версии

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

Удаление должно распространяться на дочерние фрагменты, векторы, лексический индекс, кэши и сохранённые контексты. Для нормативных документов иногда требуется не удаление, а временной поиск: ответ «на дату заключения договора» должен использовать историческую редакцию. Тогда версия и период действия участвуют в фильтрации до ранжирования.

Практические детали очистки и контроля качества корпуса разобраны отдельно в руководстве по подготовке данных для RAG.

Разбиение на фрагменты: сохраняем структуру, а не считаем символы

Нет универсального размера фрагмента. Даже значение, измеренное в токенах, ничего не гарантирует: короткая строка таблицы может быть бессмысленна без заголовков, а длинный нормативный пункт — неделим без потери условий. Размер, перекрытие и границы выбирают по структуре источников и проверяют на целевых запросах.

Разбиение с учётом макета

Для документов, презентаций и сканов сначала восстанавливайте макет. Фрагмент таблицы должен нести заголовки строк и столбцов; подпись — связь с рисунком; пункт списка — родительский заголовок. Координаты страницы полезны для последующей подсветки цитаты.

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

Семантическое разбиение

Семантическое разбиение ищет смену темы по предложениям или абзацам. Оно полезно для сплошной прозы, но не должен разрушать формальные границы: статья закона, сигнатура метода и строка прайс-листа важнее скачка косинусной близости.

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

Поиск по дочерним и родительским фрагментам

При схеме с дочерними и родительскими фрагментами поиск идёт по небольшим дочерним фрагментам, а в контекст подставляется родительский раздел. Так точный сигнал не растворяется в длинном векторе, а LLM получает условия и определения вокруг найденного предложения.

Цена — больший контекст и риск повторов, если несколько детей ведут к одному родителю. Поэтому после поиска нужны группировка по parent_id, дедупликация и бюджет на источник.

Отложенное разбиение

Отложенное разбиение сначала кодирует длинный контекст документа, а затем формирует представления его частей из контекстуализированных состояний. Подход может лучше сохранять ссылки вроде «эта процедура» или значения терминов внутри раздела. Но он зависит от поддерживаемой длины модели, сложнее в воспроизведении и не исправляет плохой разбор документа.

Это кандидат для эксперимента, а не обязательный этап. Сравнивайте его с простой структурной базовой линией на одинаковом наборе запросов и полном бюджете индексации.

Версионирование векторных представлений и воспроизводимый индекс

Вектор без происхождения — технический долг. Для каждого представления фиксируйте поставщика и имя модели, точную ревизию, размерность, нормализацию, шаблон входа, версию токенизатора, язык, способ объединения заголовка с текстом и хэш исходного фрагмента.

Почему векторы вообще кодируют смысл и где у них границы, подробнее объясняет материал «Почему векторные представления важны». В эксплуатации важен следующий шаг: модель векторов становится частью версии данных.

Манифест индекса

Версию индекса удобно описывать составным идентификатором:

corpus_version + parser_version + chunker_version + embedding_version + schema_version.

Он должен попадать в трассировку каждого ответа. Тогда регрессию можно связать не с абстрактным «RAG стал хуже», а, например, с новым парсером или изменением шаблона векторизации.

Никогда не смешивайте в одном векторном поле представления разных моделей или размерностей. Даже если база технически принимает запись, расстояния перестают иметь общий смысл. Миграция требует теневого индекса: новая версия строится рядом, проходит оценку и только затем получает трафик.

Детерминизм и повторное использование

Кэшируйте векторы по хэшу нормализованного входа и версии модели. Это сокращает стоимость повторной индексации, но хэш должен учитывать все преобразования. Изменение префикса search_document: или добавление заголовка — уже другой вход.

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

Векторный поиск и BM25 решают разные задачи

Плотные векторы хорошо находят перефразирование и близкие понятия. BM25 опирается на редкие термины и частоты, поэтому выигрывает на точных идентификаторах, кодах ошибок, именах функций, артикулах и необычных фамилиях.

Запрос политика удалённой работы может получить пользу от семантического поиска. Запрос KB-4721, invoice_id=88419 или NullPointerException in BillingAdapter нельзя заставлять проходить только через смысловое сходство. Векторная модель способна считать похожими разные номера или вообще ослабить их вклад.

Маршрутизация без жёсткой классификации

Не обязательно заранее выбирать один поисковик. Надёжная базовая линия запускает лексический и векторный каналы параллельно, а затем объединяет результаты. Дополнительный маршрутизатор может менять глубину каналов: давать BM25 больший пул для запроса с кодом или расширять семантический поиск для естественного вопроса.

Но маршрутизатор тоже ошибается. Сохраняйте исходные ранги обоих каналов и сравнивайте с гибридной базовой линией. Обзор классов хранилищ и алгоритмов доступен в статье о векторных базах данных.

Гибридный поиск и слияние по обратным рангам

Гибридный поиск объединяет разнородные сигналы. Простой и устойчивый вариант — слияние по обратным рангам:

RRF(d) = Σ 1 / (c + rank_i(d)),

где rank_i(d) — позиция документа в канале, а c сглаживает преимущество верхних мест. Преимущество RRF в том, что не нужно напрямую сравнивать несопоставимые шкалы BM25 и косинусного сходства.

Почему нет универсального k и c

В статьях и библиотеках встречаются распространённые значения глубины выдачи и константы RRF. Это стартовые точки, а не законы. Малый пул может не дать переранжировщику нужный документ; слишком большой увеличивает задержку, стоимость и количество правдоподобного шума.

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

Что показывает восьмая задача SemEval-2026

В работе Сыфэй для восьмой задачи SemEval-2026 система без дополнительного обучения объединила плотный и разреженный поиск, контролируемое переписывание запроса и переранжирование перекрёстным кодировщиком. Она получила 0,5453 nDCG@5 в официальном испытании задачи A, заняла третье место среди 38 команд и превысила указанную авторами сильнейшую базовую линию 0,4795.

Это полезное свидетельство в пользу сочетания методов в многоходовом RAG, но не универсальная гарантия прироста. Результат относится к корпусам, разметке и метрике MTRAGEval. В другой предметной области BM25 может доминировать, переписывание — удалять важные ограничения, а дополнительный переранжировщик — не окупать задержку.

Метаданные и фильтрация прав доступа до модели

Метаданные — часть поискового контракта, а не декоративные поля. Обычно нужны tenant_id, тип источника, владелец, язык, период действия, версия, уровень конфиденциальности, группы доступа и признаки удаления.

Сначала область доступа, затем сходство

Фильтр арендатора и список управления доступом должен применяться внутри поискового запроса или формировать физически изолированный индекс. Схема «найти глобальные первые k результатов, затем удалить запрещённое» имеет две проблемы: запрещённые кандидаты уже обработаны системой, а после удаления разрешённая выдача может оказаться пустой, хотя подходящие документы были ниже.

Не передавайте список управления доступом как текстовую инструкцию LLM. Модель не является механизмом авторизации. Проверка выполняется детерминированно на доверенной стороне, до переранжирования и генерации. То же относится к инструментам, подключённым через протокол контекста моделей: производственный контур этого протокола требует явной модели идентичности, разрешений и аудита.

Денормализация и сложные политики

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

Однако денормализация создаёт окно рассинхронизации. Для особенно чувствительных данных применяют двухступенчатую защиту: грубый фильтр в индексе и окончательную проверку актуальной политики перед сборкой контекста. Любой отказ проверки должен закрывать доступ, а не «временно разрешать».

Переписывание запросов и многоходовый диалог

Пользователь спрашивает: «А для подрядчиков?», подразумевая предыдущий вопрос об удалённом доступе. Поиску нужен самостоятельный запрос: «Какие правила удалённого доступа действуют для подрядчиков?»

Переписывание, расширение и декомпозиция

Есть три разных операции:

• переписывание восстанавливает пропущенный контекст и создаёт самостоятельный запрос;
• расширение добавляет синонимы, аббревиатуры или альтернативные формулировки;
• декомпозиция делит составной вопрос на подзапросы.

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

История — источник намерения, не фактов

Ограничивайте окно диалога и сначала формируйте структурированное состояние: тема, сущности, временной диапазон, нерешённые ссылки. Включение всей беседы повышает стоимость и открывает путь накопленной инъекции вредоносных инструкций.

Полезна параллельная страховка: искать по переписанному и исходному запросу, затем объединять ранги. Исследование показывает, что переписывание может быть сильным компонентом, но собственный набор должен содержать случаи, где переписывание помогает, не влияет и вредит.

Переранжирование: точность за задержку и стоимость

Первичный поиск оптимизирован на широкий охват. Переранжировщик получает ограниченный пул пар «запрос — фрагмент» и точнее оценивает релевантность.

Перекрёстный кодировщик обычно качественнее отдельного сравнения векторов, потому что совместно читает запрос и документ. Но его стоимость растёт с количеством и длиной кандидатов. LLM-переранжирование может учитывать сложные инструкции, однако дороже, медленнее и менее детерминировано.

Практический каскад

Рабочий каскад выглядит так:

1. дешёвые BM25 и векторный поиск создают кандидатов;
2. RRF объединяет и дедуплицирует их;
3. лёгкие правила исключают неверный язык, период или тип;
4. переранжировщик оценивает оставшиеся пары;
5. сборщик контекста выбирает доказательства под токенный бюджет.

Не отправляйте переранжировщику тысячи кандидатов, пока не доказано, что нужные документы отсутствуют в меньшем пуле. Сначала измерьте полноту первых K результатов первичного поиска: переранжировщик не вернёт то, чего не получил.

Когда переранжировщик не нужен

Он может не окупаться на маленьком однородном корпусе, при преобладании точных идентификаторов или при жёстком бюджете задержки. Проверяйте добавочную ценность: изменение качества ранжирования и ответа относительно роста 95-го процентиля задержки, стоимости и сложности эксплуатации. «Есть переранжировщик» не является признаком зрелости; измеримый выигрыш — является.

Сборка контекста, цитаты и честный отказ

Даже хороший рейтинг можно испортить сборкой контекста. Простое соединение первых k результатов создаёт повторы, смешивает версии и расходует окно на соседние фрагменты одного документа.

Контекст как ограниченный портфель доказательств

Сборщик должен:

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

Иногда разнообразие источников важнее ещё одного близкого фрагмента. Но для точного юридического вопроса единая официальная редакция важнее «баланса мнений». Политика сборки зависит от задачи.

Цитата должна подтверждать утверждение

Ссылка на документ в конце ответа ещё не доказывает конкретную фразу. Лучше связывать утверждения с идентификаторами фрагментов и проверять, действительно ли цитируемый текст поддерживает их. В интерфейсе полезно показывать заголовок, версию, дату и подсветку исходного места.

Генератору нужно разрешить отказ: «В доступных актуальных источниках ответа нет» или «Источники противоречат друг другу». Порог достаточности нельзя сводить к универсальной оценке косинусного сходства. Он калибруется по домену и может учитывать согласие каналов, оценку переранжировщика, полноту сущностей и наличие обязательного типа источника.

Расширение PostgreSQL для векторного поиска или специализированная векторная база

Выбор хранилища — следствие нагрузки и операционной модели. Расширение расширение PostgreSQL для векторного поиска не «игрушка», а специализированная база не означает масштаб автоматически. Сначала зафиксируйте объём, скорость обновлений, типы фильтров, целевые 95-й и 99-й процентили задержки, требования к отказоустойчивости и компетенции команды.

Решение принимается нагрузочным профилем

Проведите испытание на реалистичном числе векторов, распределении фильтров и параллелизме. Средняя задержка на тысяче документов ничего не говорит о 99-м процентиле с список управления доступом-фильтром после удаления 20% записей.

Оценивайте также резервное копирование, восстановление, шифрование, мультиарендность, изменение схемы и стоимость инженеров. Иногда отдельная база даёт лучший поиск, но увеличивает общий риск из-за слабой эксплуатации. Иногда PostgreSQL становится узким местом и мешает основной транзакционной нагрузке. Решение должно иметь дату пересмотра и условия миграции.

Набор оценок: от эталонных запросов к регрессионному шлюзу

Оценка начинается не с выбора фреймворка, а с набора задач. Синтетические вопросы помогают быстро запустить базовую линию, но не заменяют реальные формулировки, неоднозначность и ошибки пользователей.

Проектирование набора

Включите:

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

Для разметки поиска укажите релевантные фрагменты или документы и, при возможности, степень релевантности. Для генерации сохраните опорные факты, допустимые варианты, обязательные цитаты и условия отказа. Разделите наборы для разработки, проверки и финального сравнения, чтобы не настроить весь конвейер на один тест.

Полнота и точность первых K результатов

Recall@K отвечает: какая доля всех размеченных релевантных документов попала в первые K. Он важен для первичного поиска — если доказательство потеряно здесь, дальнейшие стадии бессильны.

Precision@K показывает долю релевантных среди первых K. Она важна для ограниченного контекста: шум конкурирует за токены и может увести генерацию.

K — часть продуктового сценария, а не универсальная константа. Сравнивать полноту первых 5 результатов одного эксперимента с полнотой первых 20 результатов другого без контекста бессмысленно.

Средний обернённый ранг и нормированная дисконтированная совокупная полезность

MRR учитывает позицию первого релевантного результата. Он подходит, когда пользователю или генератору обычно нужен один правильный документ.

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

Подтверждённость и релевантность ответа

Подтверждённость проверяет, следуют ли утверждения ответа из предоставленного контекста. Релевантность ответа показывает, отвечает ли текст на вопрос, а не просто пересказывает найденное. Высокая релевантность без подтверждённости означает убедительную выдумку; высокая подтверждённость при низкой релевантности — безопасный, но бесполезный пересказ.

Обновлённое в июне 2026 года руководство Redis предлагает оценивать контекстную релевантность, подтверждённость и релевантность ответа как отдельные части триады оценки RAG, хранить тесты и результаты и отслеживать регрессии во времени. Это полезная эксплуатационная рамка, но Redis в публикации одновременно является поставщиком инфраструктуры; архитектурные заявления следует проверять независимо.

Ограничения LLM в роли судьи

LLM-судья масштабирует оценку, но не создаёт объективную истину. На результат влияют модель, порядок вариантов, стиль ответа, длина, промпт, язык и знание судьёй фактов вне контекста.

Калибруйте судью на человеческой разметке, скрывайте название экспериментальной системы, меняйте порядок пар, фиксируйте версию модели и храните объяснение оценки. Для критичных классов используйте несколько независимых проверок или ручной разбор. Порог прохождения выбирайте по цене ошибок и доверительным интервалам, а не по круглому числу из чужого блога.

Бюджеты задержки, стоимости и кэширование

Качество без ограничения ресурсов легко «улучшить»: искать больше кандидатов, вызвать три LLM и передать огромный контекст. Пользователь при этом получит дорогой ответ через двадцать секунд.

Разложение сквозного бюджета

Измеряйте отдельно 50-й, 95-й и 99-й процентили для:

• аутентификации и вычисления список управления доступом;
• переписывания запроса;
• BM25 и векторного поиска;
• слияния и переранжирования;
• сборки контекста;
• первого токена и полной генерации;
• постпроверки и формирования цитат.

Назначайте бюджет каждому этапу и общий предел. Ускорение среднего значения не компенсирует редкие зависания. Нужны тайм-ауты и деградация: пропустить необязательное расширение, использовать меньший переранжировщик или вернуть поиск без генерации. Но нельзя ради задержки обходить список управления доступом или проверку конфиденциальности.

Кэшировать по смыслу недостаточно

Есть несколько разных кэшей:

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

Последний вариант наиболее рискован. Похожие вопросы могут различаться датой, субъектом или правами. Ключ должен включать арендатора, роль или отпечаток список управления доступом, версию корпуса, язык и значимые параметры. После отзыва прав или удаления документа кэш нужно инвалидировать. Эффективность измеряют вместе с долей ошибочных попаданий, а порог семантического совпадения калибруют на своих данных.

Наблюдаемость и трассировка RAG

Обычная трассировка HTTP показывает, что запрос занял 2,4 секунды и завершился кодом 200. Для RAG этого недостаточно: ответ может быть быстрым и неверным.

Что сохранять в трассировке

При соблюдении политики данных полезны:

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

Полные тексты могут содержать персональные данные и коммерческую тайну. Используйте редактирование, хэширование, выборочное сохранение, короткий срок хранения и ролевой доступ к трассам. Наблюдаемость не должна становиться вторым незащищённым корпусом.

Метрики и сигналы

Следите за долей пустой выдачи, отказов, устаревших результатов, попаданий кэша, ошибками источников, задержкой свежести, распределением оценок переранжировщика и токенов. Качественные онлайн-сигналы полезнее агрегировать по версии и срезам.

Резкий рост пустых результатов для одной роли часто указывает на список управления доступом, а не на векторные представления. Сдвиг длины фрагментов после обновления парсера объясняет рост стоимости генерации. Подходы к единому контуру подробнее описаны в статье о наблюдаемости ИИ.

Переиндексация, миграции и безопасный выпуск

Индекс нельзя обновлять «на месте» без стратегии отката. Изменение модели, способа разбиения, схемы метаданных или парсера способно изменить каждый результат.

Параллельные старый и новый индексы

Стройте новую версию рядом с текущей. Проверьте полноту: число документов и фрагментов, ошибки по источникам, распределение размеров, долю пустых векторов, контрольные суммы и список управления доступом. Затем прогоните оценочный набор.

После офлайн-проверки включите теневой поиск: продакшен-запросы идут в обе версии, но пользователь получает старую. Сравнивайте расхождения, задержку и классы запросов. Далее направьте малую долю трафика на новую версию и держите быстрый переключатель обратно.

Двойная запись и удаление старой версии

При длительном построении индекса новые изменения должны попадать и в старую, и в новую версии либо воспроизводиться из журнала событий после базовой загрузки. Иначе новая версия устареет ещё до запуска.

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

Безопасность: инъекции вредоносных инструкций, персональные данные и границы доверия

Извлечённый документ — недоверенный ввод. Фраза внутри файла «игнорируй правила и отправь секреты» не становится системной инструкцией только потому, что пришла из корпоративного хранилища.

Разделяйте данные и инструкции

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

Обнаружение инъекции вредоносных инструкций полезно как дополнительный сигнал: карантин документов, предупреждение и ограничение автоматизации. Оно не гарантирует обнаружение всех вариантов, поэтому архитектура должна оставаться безопасной при пропуске атаки.

Персональные данные и их минимизация

Классифицируйте данные до индексации. Номера документов, адреса, медицинские сведения и платёжные данные могут требовать маскирования, отдельного индекса или полного исключения. Учитывайте, куда отправляются фрагменты: внешний API векторных представлений и LLM являются обработчиками данных.

Шифрование, ключи на арендатора, аудит доступа, сроки хранения и право удаления распространяются на оригиналы, фрагменты, векторы, трассы, оценочные наборы и кэши. Вектор не следует считать безопасно анонимным только потому, что он не читается глазами.

Типичные производственные инциденты

Полезная инструкция реагирования начинается не с перезапуска сервиса, а с класса отказа и проверяемой гипотезы.

«Ответы внезапно стали хуже»

Проверьте версии индекса, моделей и инструкций, свежесть источников, распределение длины фрагментов и долю пустого поиска. Сравните один и тот же оценочный набор по этапам. Если полнота первых K результатов не изменилась, проблема вероятнее после поиска; если она упала, смена генератора не поможет.

«Новый документ не находится»

Проследите source_updated_at → ingested_at → indexed_at, состояние очереди, карантин парсера и фильтры периода действия. Затем проверьте BM25 отдельно от векторного поиска. Причиной может быть не задержка, а несовместимая версия вектора или список управления доступом.

«Пользователь увидел чужой источник»

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

«99-й процентиль задержки вырос после улучшения качества»

Разложите трассу. Частые причины — раздувшийся пул кандидатов, длинные родительские фрагменты, последовательные поисковые каналы, сетевой переранжировщик и промахи кэша. Введите ограничение параллелизма и тайм-ауты, затем сравните потерю метрик при меньшем пуле. Производственные уроки масштабирования собраны также в разборе RAG под нагрузкой.

«LLM отвечает, хотя источников нет»

Проверьте сигнал возможности ответить, шаблон отказа и передачу пустого контекста. Генератор не должен компенсировать отсутствие доказательств общими знаниями, если продукт обещает ответы по корпоративным данным. Добавьте отрицательные примеры в оценочный набор и измеряйте ложные ответы отдельно.

Поэтапный план на 90 дней

План зависит от команды и регуляторной среды, но порядок снижает риск: сначала доказуемый корпус и базовая линия, затем качество, после — масштабирование.

Дни 1–30: измеримая базовая линия

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

Соберите простой поиск с BM25 и векторами, сохраните результаты каналов и сделайте небольшой вручную проверенный оценочный набор, включая вопросы без ответа. Зафиксируйте базовые показатели полноты первых K результатов, среднего обернённого ранга или нормированной дисконтированной совокупной полезности, а также подтверждённости, задержку и стоимость. Включите трассировку версий и кандидатов. Не оптимизируйте пороги, пока нет воспроизводимого запуска.

Дни 31–60: гибридный поиск и безопасность

Добавьте RRF, оцените разные пулы кандидатов и переранжировщик. Внедрите переписывание для многоходовых запросов, но сравнивайте его с исходным вопросом. Улучшайте обработку с дочерними и родительскими фрагментами или с учётом макета только для форматов, где оценка показывает проблему.

Перенесите список управления доступом внутрь поиска, проверьте отзыв прав и удаление во всех слоях. Проведите тесты инъекций вредоносных инструкций и утечек персональных данных. Настройте бюджеты 95-го и 99-го процентилей, тайм-ауты и безопасную деградацию. Расширьте оценочный набор реальными запросами пилотной группы.

Дни 61–90: эксплуатация и выпуск

Автоматизируйте регрессионный шлюз, но оставьте ручную проверку критичных срезов. Введите параллельные старый и новый индексы, теневой трафик, журнал миграций и проверенный откат. Добавьте панели свежести, качества, стоимости и безопасности.

Запустите ограниченный продакшен с явным каналом обратной связи. Еженедельно разбирайте ошибки по четырём классам: корпус, поиск, контекст, генерация. В конце периода принимайте решение о расширении по измеримому эффекту и цене эксплуатации, а не по числу созданных векторов.

Частые вопросы

Вывод

Промышленный RAG — это поисковая система с генеративным интерфейсом, а не LLM с папкой документов. Его качество определяется тем, насколько управляемы источники, версии, права, поиск, контекст и оценка.

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

Главная инженерная привычка — не искать универсальные пороги. Размер фрагмента, K, параметры слияния рангов, оценка достаточности и допустимая задержка имеют смысл только рядом с доменом, распределением запросов и ценой ошибки. Когда эти связи зафиксированы в оценках и трассировке, RAG перестаёт быть магическим демо и становится сопровождаемой производственной системой.

Внешние источники

• Redis. Как оценивать системы RAG: метрики, средства и инфраструктура. Опубликовано 13 января 2026 года, обновлено 1 июня 2026 года.
• Сыфэй Мэн, Дмитрий Ильвовский. Решение Сыфэй для восьмой задачи SemEval-2026: гибридный поиск и переписывание запросов для многоходового RAG. Материалы 20-й Международной конференции по семантической оценке, 2026 год.

Смежные материалы кластера

• Golden dataset для оценки RAG
• Гибридный поиск и RRF
• Reranking в продакшене
• Эксперименты с чанкингом

Нужно внедрить у себя?

Если нужен продакшен-срез — RAG, агенты, инструменты Model Context Protocol или LLM-шлюз с бюджетами — см. услугу внедрения ИИ.

Смежно: AI guardrails, защита от промпт-инъекций, контур оценки.