Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LadderRAG научили связывать факты из далёких глав книги, меняя устройство поиска после разбора неудачных ответов. В препринте BRAC University, который не рецензировали и где все числа получили сами авторы, полнота поиска по ошибочным вопросам выросла с 0,36 до 0,79. Для команд, которые строят RAG по длинным документам, работа предлагает практический цикл: отдельно измерять поиск и ответ, разбирать ошибки и только затем менять архитектуру.
Как разложили книгу и вопрос
Обычный RAG — генерация ответа с поиском по источникам — хорошо находит фрагмент, похожий на формулировку вопроса. Но он часто возвращает несколько соседних отрывков и пропускает вторую сцену, если доказательства разделяют десятки глав.
LadderRAG индексирует книгу на нескольких уровнях. Нижний хранит исходные отрывки, средний — краткие содержания разделов, верхний — карточки со структурой книги, персонажами, терминами, хронологией и повторяющимися темами. Все уровни попадают в общий индекс, где семантический поиск объединяется с BM25 — поиском по совпадениям слов.
При вопросе система сначала составляет план: выделяет части вопроса, имена и слова для поиска. Затем она ищет доказательства для каждой части, ограничивает число отрывков из одной главы и добавляет краткие содержания с карточками книги. Такой порядок мешает одному хорошо совпавшему эпизоду занять весь контекст.
Для проверки команда собрала CrossChapterQA: 1 853 вопроса по 14 англоязычным книгам из общественного достояния. Каждый вопрос требует связать от двух до шести разделов и содержит разметку нужных глав, поэтому качество поиска можно отделить от качества итогового рассуждения. Типы связей включают повторяющийся мотив, раннюю деталь с поздним продолжением, развитие персонажа и цепочку событий.
Почему лучший поиск не гарантировал лучший ответ
Первую версию LadderRAG чаще подводил поиск: похожие отрывки из одной главы вытесняли другие части истории. Модель-оценщик сравнивала ответы с эталонами и отмечала те, где система говорила о другом событии или персонаже. Авторы затем вручную разбирали часть ошибок и меняли код следующей версии.
Во второй версии появился планировщик отдельных поисковых запросов и ограничение на отрывки из одной главы. Третья версия добавила больше правил, проверку найденных фрагментов и поиск редких слов. Она находила нужные главы чаще, но отвечала хуже: проверяющий компонент отбрасывал подходящие доказательства, а дополнительные ограничения усложняли сборку ответа.
Следующий редизайн вернул буквальные опоры из вопроса, закрепил места для каждой его части и добавил проверочный список перед ответом. Однако без общего контекста система хуже справлялась с интерпретацией, местоимениями и сменой имён персонажа. Финальная версия поэтому снова подключила карточки и краткие содержания.
Индекс одной книги стоил в среднем $0,41, а ответ финальной версии — около $0,005. На вопросах, где первая версия ошиблась, десять читателей оценили итоговые ответы в среднем на 6,5 из 10. Это результат уровня «в целом верно, но с заметными пропусками», а не основание считать задачу решённой.
Что менять в планах разработки RAG
Главный переносимый результат — не конкретная схема карточек, а способ развивать систему. Метрика итогового ответа скрывает источник ошибки: документ мог не попасть в контекст, модель могла неверно связать найденные факты или проверяющий шаг мог удалить нужный фрагмент. Размеченные источники ответа позволяют увидеть эти случаи отдельно.
Модель-оценщик здесь не обучает веса и не выбирает лучший ответ для пользователя. Она служит дешёвым фильтром, после которого человек изучает характерные сбои и формулирует изменение архитектуры. Каждая версия остаётся обычным программным релизом: её можно проверить, откатить и сравнить с предыдущей.
Для продукта с регламентами, договорами или длинной базой знаний это означает, что к набору проверочных вопросов стоит добавлять ссылки на обязательные разделы. Тогда команда сможет измерять полноту поиска, а не судить о системе только по убедительности текста. Полезно также сохранять неудачные изменения: работа показывает, что рост поисковой метрики способен сопровождаться ухудшением ответа.
Границы проверки существенны. Вопросы и эталонные ответы создавали модели; разработку вели на Black Beauty, а перенос проверяли на остальных книгах. Финальную версию запускали только на вопросах, где ошиблась первая, и напрямую не сравнивали с GraphRAG, другими структурированными системами или моделями с длинным контекстом. Поэтому работа поддерживает цикл архитектурного редизайна, но не доказывает, что LadderRAG следует выбрать вместо этих подходов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
