Отлаживайте конвейер обработки данных, а не саму большую языковую модель: рабочая модель мышления для устранения сбоев в системах RAG
Когда бот RAG отвечает неверно, причиной редко бывает LLM. Проследите сбои на этапах загрузки данных, поиска информации, генерации ответа, оценки и повторного цикла, чтобы определить проблемную составляющую.
Источники: RAG Is Not Just Vector Search
Представьте бота поддержки в средней компании типа SaaS, который однажды ответил двум клиентам по-разному, когда оба спросили о сроках возврата средств.
Был открыт инцидент, и первая мысль инженера, находившегося на дежурстве, заключалась в том, что большая языковая модель генерирует ложную информацию, и требуется другая модель. Это была краткосрочная диагностика; при этом подходе технология RAG рассматривалась как «черный ящик», модель менялась в надежде, что симптомы исчезнут.
Опытный инженер начинает поиск с другой стороны и спрашивает, на каком этапе работы системы произошла ошибка. Утверждение о том, что модель генерирует ложные имена, является лишь симптомом и ничего не объясняет.
Через два дня появляется настоящая проблема. Политика возврата средств была изменена, но никто не удалил устаревший PDF из корпуса данных, поэтому обе версии продолжали появляться с схожими оценками релевантности, и модель верно обобщала противоречивые данные. Она совсем не галлюцинировала. (Это синтетический пример для иллюстрации, но подобные ситуации встречаются часто.)
Вот разница между учебной версией RAG и тем, как он работает в реальных условиях. В учебниках это обычно сводится к одной строке:
Embed → Search → Generate
Этого достаточно для демо-версии, но недостаточно для производственного использования. Настоящая система имеет несколько границ отказа. Важный инженерный вопрос заключается не только в том, может ли LLM написать хороший ответ, но и в том, правильно ли работают все слои, формирующие этот ответ.
Получение данных: качество определяется до начала поиска
Большинство операций отладки RAG начинаются с неверного этапа. Люди настраивают промпты, меняют модели эмбеддингов и корректируют параметры top-k, тогда как реальная ошибка возникала уже несколько недель назад на этапе получения данных.
Анализ по структуре
Таблицы, блоки кода, заголовки и списки передают информацию через свою структуру. Если преобразовать таблицу цен в обычный прозаический текст, связь между строкой и её заголовком может исчезнуть. Пайплайн получения данных должен сохранять эту структуру и выбирать формат представления, подходящий для поиска, а не рассматривать каждый документ как единый неразличимый блок текста.
Правильный подход зависит от содержимого. Для таблицы может потребоваться структурированный извлечение данных, сериализация текста, метаданные или сочетание лексического и семантического поиска.
Разбиение по смыслу
Простой метод предусматривает разделение на фрагменты каждые 512 токенов. Однако количество токенов и смысловая структура не всегда совпадают, поэтому один фрагмент может начинаться с вступительной части и заканчиваться на полпути к основной информации.
Семантическое разбиение на фрагменты предполагает разделение по смене тем, а не по подсчёту токенов. Это не универсальное решение, и оно требует больше ресурсов при обработке данных. В длинных документах, таких как политики, контракты и техническая документация, сохранение целостности идей часто улучшает качество результатов поиска.
Предоставьте каждому фрагменту некоторый контекст перед включением в модель
Фрагмент, взятый с 40-й страницы 60-страничного документа, может быть совершенно корректным текстом, но при нахождении вне своего исходного контекста оставаться неоднозначным. Возьмем предложение о том, что определенное ограничение действует только для клиентов категории Enterprise. Без сопутствующего раздела ничто не указывает системе, к чему именно относится это «ограничение».
Системы поиска с учетом контекста решают эту проблему, добавляя перед фрагментом информацию уровня документа: название, путь к разделу, продукт, версию или краткую аннотацию о местоположении фрагмента. Цель состоит в том, чтобы каждый фрагмент сохранял тот контекст, который в противном случае был бы утрачен в процессе его извлечения.
Приложение метаданных
Рассматривайте метаданные как функциональные данные. Для фильтрации, контроля доступа, проверки актуальности и отладки на последующих этапах требуются источник, дата, тип документа, информация об абоненте, права доступа и версия.
Это поднимает один из самых важных вопросов, связанных с процессом обработки данных: что произойдет, если завтра изменится исходный документ? Если система может лишь переиндексировать всё, даже небольшая правка контента превращается в операционную нагрузку. В идеале процесс обработки данных должен быть поэтапным и идемпотентным, чтобы обновления обнаруживались, обрабатывались и распространялись без необходимости пересоздания всего корпуса данных.
В приведенном примере старая политика возврата средств никогда не была ошибкой ИИ-модели. Проблема заключалась в том, как управлялись процесс обработки данных и сам корпус информации.
Поиск — это процесс, а не простое поиск по списку
Само понятие словом «поиск» может создать впечатление единственного шага. На самом деле поиск представляет собой цепочку решений, и порядок этих решений имеет важные последствия.
1. Переписать
Люди не пишут поисковые запросы естественным образом. Они задают вопросы вроде того, была ли отправлена вещь для возврата средств. ГЛМ может преобразовать такой вопрос в более полезный для поиска формат, возможно, включив историю разговора или разделив сложный вопрос на более конкретные. Однако переписывание не является бесплатным: плохая переработка может привести к упущению ключевых деталей или добавлению неверных предположений. Рассматривайте это как ещё один элемент для оценки, а не как волшебство.
2. Область поиска
Это один из самых важных аспектов реализации. Если система предназначена для нескольких пользователей или учитывает права доступа, пространство поиска должно соблюдать эти ограничения. Параметры, такие как пользователь, права доступа, видимость, дата и источник, следует применять в процессе поиска там, где это позволяет основная система.
Фильтрация после применения критерия top-k создаёт две проблемы. Во-первых, полезные документы могут уже быть исключены из списка top-k из-за документов, которые пользователю запрещено видеть. Во-вторых, логика авторизации оказывается опасно оторванной от процесса поиска. Проще говоря, не стоит сначала искать всё, а затем спрашивать, что может увидеть пользователь — сначала сузьте диапазон поиска.
3. Поиск двумя способами
Поиск с использованием плотных векторов хорошо справляется с определением семантической близости. Запрос о том, как отменить что-либо, может совпасть с текстом о том, что клиенты могут прекратить использование услуги в любое время, несмотря на отсутствие общих слов.
Однако эмбеддинги менее эффективны при работе с точными идентификаторами. Вспомните такие строки:
ERR_CONNECTION_RESET
SKU-48392
API-v3-beta
Для таких запросов сигналом служит буквальный токен, и именно здесь находит применение лексический поиск, такой как BM25. В реальных системах поиска часто сочетают плотный поиск для понимания смысла с лексическим поиском для точных строк.
4. Слияние
Теперь имеются два отсортированных списка: у плотного поиска есть своя иерархия, у BM25 — своя, и их первоначальные оценки не всегда сопоставимы. Метод взаимного слияния рангов (RRF) предлагает простой способ объединения этих списков с использованием позиции в ранжировании:
RRF_score(d) = Σ 1 / (k + rank_i(d))
Каждый список вносит свой вклад в зависимости от того, где находится документ в нем, что позволяет избежать необходимости калибровки распределений оценок двух несвязанных систем друг относительно друга.
5. Переупорядочивание
Метод слияния предоставляет набор кандидатов, который не обязательно является окончательным контекстом. Кросс-кодер-переупорядочиватель считывает запрос и каждого кандидата вместе и формирует оценку релевантности для конкретной пары. Это принципиально отличается от независимого включения запроса и документа в эмбеддинги и сравнения векторов.
Затраты связаны с вычислениями, поэтому кросс-кодер не применяется ко всему корпусу данных. Механизм поиска может вернуть топ-20 или топ-50 кандидатов, после чего переупорядочиватель выбирает наиболее подходящий контекст из них.
Следовательно, модель обработки данных предусматривает сначала интенсивный поиск, затем лексический поиск, затем слияние данных и, наконец, переупорядочивание. Это не просто «база данных векторов — и всё готово».
Генерация: наличие хорошего контекста всё ещё не гарантирует хорошего ответа
Найдение подходящих документов необходимо, но недостаточно. ГЛМ всё равно должен правильно ими пользоваться.
Управление окном контекста
Увеличение объёма контекста автоматически не приводит к лучшему ответу. Модели не используют длинные контексты одинаково. Исследования показали, что информация, находящаяся в середине длинного контекста, может вспоминаться менее надёжно, чем информация, расположенная в начале или в конце. Поэтому включение в запрос верхних 20 фрагментов может ухудшить качество ответа. Цель — максимально полезный контекст, а не максимальный объём контекста.
Границы запроса и указание источника
Чётко указайте в запросе, как следует использовать найденные отрывки. Модель должна рассматривать их как доказательства, которые можно цитировать, а не как инструкции, которым необходимо следовать.
Цитаты также способствуют укреплению доверия и отладке. Когда в ответе говорится, что у клиентов Enterprise есть 30 дней на отказ, необходим способ привязать это утверждение к соответствующему источнику.
Воздержание
Воздержание обозначает существенное различие между демо-версией и надежной системой. Даже если поиск не дает результата, модель все равно будет пытаться помочь, если только отказ не является допустимым исходом. Промышленная система должна иметь возможность ответить, что доказательств недостаточно. Часто это правильное решение, а не дефект.
Без воздержания каждая неудача поиска может превратиться в вымысел. LLM берет на себя вину за неправильный ответ, хотя настоящая проблема могла возникнуть на несколько уровней раньше.
Оценка предшествует любому исправлению
У RAG есть неприятная особенность: качество может снижаться, даже если код приложения остается неизменным. Новая модель встраивания, иной метод разбиения на фрагменты, добавление или удаление документов, изменение настроек поиска или редактирование запроса могут каждый по-своему изменить ответы, даже если код, развернутый вчера, полностью идентичен байт за байтом. Поэтому системы RAG в производственной среде следует оценивать на нескольких уровнях.
Качество поиска. Точность контекста показывает, насколько из найденного контекста было релевантным. Воспроизводимость контекста показывает, сколько из доступной релевантной информации фактически было найдено. Вместе они позволяют отличить ситуацию «мы его так и не нашли» от ситуации «мы его нашли, но он был среди шума».
Качество генерации. Проверка верности (также называемая обоснованностью) убеждается в том, что ответ вытекает из полученных доказательств, а проверка точности цитирования убеждается в том, что указанные источники подтверждают каждое утверждение. Хорошо написанный ответ может всё равно оставаться необоснованным.
Состояние системы. Важную роль играют также операционные показатели: задержка p95, стоимость за запрос и уровень отказов. Это не просто вопросы инфраструктуры. Если задержка удваивается из-за того, что агент начинает выполнять несколько циклов поиска, это также влияет на качество системы. Резкий рост числа отказов может означать ухудшение процесса поиска. Увеличение стоимости за запрос может свидетельствовать о том, что казалось бы незначительное изменение привело к использованию дорогостоящего пути обработки.
Разделение показателей измерений способствует более точной диагностике. Здоровое воспроизведение с снижением уровня связи с реальностью указывает на проблемы с генерацией ответов. Снижение точности указывает на проблемы с обработкой данных, фильтрацией, поиском или ранжированием. Если отслеживать только общее качество ответов, все снижения будут выглядеть одинаково, и у вас не будет оснований для действий.
От потока обработки к циклу обратной связи
Основной поток обработки остается простым:
Ingestion → Retrieval → Generation → Evaluation
Многим системам этого достаточно. Хорошо индексированная база знаний и четко сформулированные вопросы редко требуют от агента выбора следующего шага. Однако существуют и более сложные вопросы.
Возьмём, к примеру, запрос на сравнение показателей доходов за второй квартал с данными, приведёнными в презентации для совета директоров, а затем на объяснение разницы. Для ответа могут понадобиться цифры за второй квартал, презентация совета директоров, соответствующие разделы каждого документа, их сравнение, а также возможно обращение к другому источнику данных. Одного этапа поиска может оказаться недостаточно, и именно здесь пригождается агентный подход RAG. Вместо простой последовательности «поиск — генерация» можно использовать цикл:
Retrieve
↓
Evaluate
↓
Enough evidence?
↓ no
Retrieve again
↓
Generate
Такая система может сделать вывод, что имеющихся доказательств недостаточно, переформулировать запрос, провести поиск заново или передать подзадачу SQL-базе данных, графу знаний или онлайн-API. Получение информации становится итеративным процессом, а не однократной операцией.
Однако агентные системы RAG автоматически не являются лучше. Каждый дополнительный цикл увеличивает задержку, затраты на обработку токенов и риски сбоев, а также может вызывать ненужные поиски, когда у агента нет явных причин для продолжения работы. Их сложность оправдывается лишь в случаях неоднозначных вопросов, многоэтапных поисков или необходимости использования нескольких источников. Вопрос о политике возврата средств, вероятно, можно ответить за один проход с помощью хорошо спроектированной статической системы. Сравнение различных вариантов может оправдать необходимость итераций.
Важный вопрос заключается в том, есть ли у системы объективная причина для повторного поиска, а не в том, должен ли она вообще использовать агента. Итерации без четкого правила завершения лишь увеличивают задержки и затраты.
Ментальная модель производства
Начинать с LLM — самая распространённая ошибка при отладке. Плохой ответ — это лишь последний симптом, а причина может находиться гораздо выше по цепочке. Устаревшие документы напоминают галлюцинации, плохое разделение на части — неудачу при поиске, слабый поиск — сбой при генерации, а отсутствие оценки скрывает все эти проблемы до тех пор, пока клиенты не начнут жаловаться.
Поэтому не спрашивайте, какую модель использовать. Спрашивайте, какой слой выходит из строя.
INGESTION
↓
RETRIEVAL
↓
GENERATION
↓
EVALUATION
↖
└── feedback loop / Agentic RAG
Устаревшие данные означают необходимость устранения проблем с их получением. Отсутствие документа означает необходимость устранения проблем с его поиском. Найденный документ с низким рейтингом требует улучшения алгоритма ранжирования. Неправильный ответ при правильном контексте указывает на необходимость проверки процесса генерации ответов. Если невозможно определить, какая из проблем актуальна, сначала разработайте более точные методы оценки. А когда одного прохода никогда недостаточно, рассмотрите возможность использования циклической структуры с агентами.
Начните с обработочной цепочки и оставьте модель на последнем этапе.
Откуда берутся идеи
Для дальнейшего изучения в оригинальной статье Lewis и его коллег (NeurIPS 2020) о генерации с усилением с помощью поиска описывается основной подход. В отчете компании Anthropic за 2024 год о контекстуальном поиске сообщается о значительном снижении количества ошибок поиска при использовании контекстуальных эмбеддингов, контекстуального алгоритма BM25 и механизмов переранжирования, хотя это собственные измерения компании-производителя. Cormack, Clarke и Büttcher (SIGIR 2009) представили метод Reciprocal Rank Fusion. В статье «Lost in the Middle» Liu и его коллеги исследуют, как модели используют длинные контексты; статья RAGAs описывает автоматизированную оценку метода RAG, а статья Self-RAG Asai и его коллег посвящена саморефлексивному, агентному поиску.
Связанная литература
- Практические заметки: Ограничения векторного поиска в RAG — косинусное сходство и связанные аспекты — Подробное руководство по Практическим заметкам: Ограничения векторного поиска в RAG — косинусное сходство и связанные аспекты, включающее шаблоны контрактов, проверок и готового кода для команд, внедряющих эту практику.
- Значение как координаты: от эмбеддингов к векторным базам данных и RAG — Простое объяснение концепций эмбеддингов предложений, косинусного сходства, векторных баз данных и цикла RAG, с четырьмя короткими примерами предложений о собаках, кошках и Париже, демонстрирующими, как работает поиск по значению.