Журнал · Rit.work

Agentic AutoRAG разбирает ошибки RAG до смены конфигурации

Agentic AutoRAG отличает сбой поиска от ошибки генерации и подбирает RAG-конвейер по качеству и стоимости API-вызовов.

Rit.work
Студия разработки
7 октября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

RAG-конвейер теперь можно настраивать по причинам неправильных ответов, а не только по общему баллу. В препринте ETH Zurich, который не проходил рецензирование и содержит замеры самих авторов, Agentic AutoRAG превзошёл лучший базовый метод на медицинском корпусе при 58% его стоимости на запрос. Подход сокращает перебор конфигураций и вместо одного победителя показывает варианты с разным соотношением качества и цены.

Как определить, сломался поиск или генерация

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

Agentic AutoRAG проверяет конфигурации на неизменном экзамене из вопросов и эталонных ответов. Для каждого вопроса система хранит дословные фрагменты корпуса, которые подтверждают ответ, а после испытания проверяет, попали ли они в найденный контекст.

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

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

Как диагноз превращается в новую конфигурацию

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

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

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

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

Когда результаты меняют план разработки

При проверке качества Agentic AutoRAG за первые 10 испытаний достиг результата, для которого случайному поиску и MO-TPE потребовался полный бюджет в 30 испытаний. На медицинском корпусе максимальная медианная точность составила 77% против 71,5% у лучшего базового метода. Тот же уровень, что у этого метода, агент нашёл примерно за 22% его стоимости на запрос.

Метод проверяли на HotpotQA, MuSiQue и MultiHop-RAG, а режим совместной оптимизации качества и цены — на 250 медицинских документах и изображениях страниц из UniDoc-Bench. Сравнением служили случайный поиск и MO-TPE с предварительными испытаниями и без них. Ответы оценивала языковая модель без проверки согласия с людьми; парсер документов оставался фиксированным, а поиск охватывал модульные RAG-конвейеры, но не графовые и агентные архитектуры.

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

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

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

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

← Ко всем материалам
Понравилось? Обсудим вашу задачу