IRCoT: чергування пошуку та ланцюжка міркувань для багатоетапних запитань

Я читав про варіанти RAG в останніх кількох дописах і хотів розібратися в IRCoT — статті Тріведі, Баласубраманіана, Кхота та Сабхарвала (ACL 2023), яка чергує пошук із ланцюжком міркувань замість виконання одного етапу пошуку на самому початку. FLARE підійшов до цієї проблеми, прогнозуючи, коли саме виконувати пошук; IRCoT обирає простіший механічний підхід і ставить конкретніше питання: а що, якщо кожне речення ланцюжка міркувань саме по собі є пошуковим запитом?

Стаття

Існуючі конвеєри «спочатку пошук, потім читання» (retrieve-then-read) знаходять документи один раз на основі початкового запитання, а потім передають усе в LLM. Для однокрокових запитань цього часто достатньо. Для багатоетапних запитань — «Хто був композитором фільму, режисер якого народився в тому ж місті, що й Бах?» — релевантні документи для другого кроку можна визначити лише після того, як ви частково відповіли на перший крок. Автори називають це проблемою залежності знань і стверджують, що однокроковий пошук структурно не здатний її вирішити.

IRCoT вирішує це за допомогою циклу: генерується наступне речення ланцюжка міркувань, це речення використовується як запит BM25 для пошуку додаткових абзаців, знайдені абзаци додаються до контексту промпту, генерується наступне речення міркування і так далі. Цикл виконується до восьми кроків, обмежуючи загальний контекст п'ятнадцятьма абзацами. Навчання не потрібне — метод повністю базується на промптах і оцінювався в режимі zero-shot на GPT-3 (code-davinci-002) та few-shot на Flan-T5.

Ключові ідеї

• На HotpotQA IRCoT покращує повноту пошуку (recall) на +11,3 пункту порівняно з однокроковим пошуком із GPT-3, а F1 у відповідях на запитання — на +7,1 пункту (60,7 проти 53,6).
• Приріст ще більший на складніших датасетах: +22,6 пункту повноти та +13,2 пункту F1 на 2WikiMultihopQA з GPT-3.
• Flan-T5-XXL (11B) з IRCoT досягає +15,3 F1 на 2WikiMultihopQA порівняно з однокроковим пошуком, що є найбільшим приростом для одного датасету в статті.
• Flan-T5-XL (3B) з IRCoT перевершує GPT-3 (175B) з однокроковим пошуком — розрив у параметрах у 58 разів подолано лише за рахунок стратегії пошуку.
• IRCoT зменшує кількість фактичних помилок у згенерованих CoT на 50% на HotpotQA та на 40% на 2WikiMultihopQA відносно однокрокового пошуку (ручна анотація 40 запитань на датасет).
• Метод добре узагальнюється поза межами розподілу (out-of-distribution): використання прикладів (demonstrations) з одного датасету для оцінки іншого показує аналогічний приріст, підтверджуючи, що підхід не просто підлаштовується під шаблони всередині розподілу.

Що підтверджується, а що ні

Основне твердження — про те, що багатоетапні міркування потребують багатоетапного пошуку — є переконливим, а експерименти чистими. Використання чотирьох дійсно складних багатоходових бенчмарків із різними структурами знань (ланцюгові, порівняльні, дискретно-логічні) робить цей висновок ґрунтовним. Абляційне дослідження, яке показує, що окремий виділений «читач» (а не вилучення відповіді безпосередньо з фази CoT) стабільно допомагає, є корисним практичним результатом.

Що мені здається менш переконливим: бюджет пошуку фіксований на рівні п'ятнадцяти абзаців незалежно від складності запитання, а критерієм зупинки є жорсткий ліміт кроків, а не сигнал моделі «у мене достатньо інформації». Тригер на основі невизначеності у FLARE є більш обґрунтованим у цьому плані, хоча він і потребує каліброваних імовірностей токенів. Основа BM25 в IRCoT навмисно проста — щільний пошук (dense retrieval), майже напевно, ще більше покращив би результати, але автори його не тестують; вони стверджують, що простота робить внесок ланцюжка міркувань чіткішим, що є справедливим. Обчислювальні витрати є реальними: кожне згенероване речення викликає запит на пошук, тому затримка зростає лінійно з глибиною міркувань. Недавні роботи 2025 року (LevelRAG, GlobalRAG) повідомляють, що такий жорсткий конвеєр «одне речення — один пошук» обмежує продуктивність у завданнях, що потребують паралельного збору інформації, а не послідовних ланцюжкових міркувань; GlobalRAG демонструє покращення F1 на 6,54 пункту порівняно з IRCoT на своєму бенчмарку.

Аналіз галюцинацій також менш глибокий, ніж хотілося б: 40 запитань на датасет — це замало для впевнених тверджень, а «фактична помилка» анотувалася вручну без зазначення узгодженості між анотаторами.

Чому це важливо для фінансового ШІ

Проблема залежності, яку вирішує IRCoT, безпосередньо відображає те, як агент Beancount відстежує багатоетапні фінансові питання. На запитання «Яким був чистий ефект усіх транзакцій, що стосуються рахунку X між датами Y та Z, після врахування конвертації валют, зазначених у полях memo?» неможливо відповісти за допомогою одного векторного пошуку — вам потрібно знайти відповідні транзакції, потім отримати згадані курси обміну, а потім, можливо, знайти кореспондуючі рахунки (contra accounts). Кожен крок пошуку залежить від того, що було знайдено на попередньому.

Практичний урок для проектування — це цикл «пошук-міркування»: замість того, щоб заштовхувати в контекст увесь багаторічний гроссбух або виконувати один семантичний пошук, агент у стилі IRCoT використовував би кожне проміжне речення міркування — «загальний дебет витрат на food у першому кварталі склав $1 240» — як запит для наступного кроку пошуку. Це дозволяє зберігати вікно контексту компактним, а знайдені докази — специфічними для конкретної мети. Висновок про те, що модель 3B з хорошим пошуком перемагає модель 175B з поганим пошуком, особливо актуальний з огляду на витрати на запуск агентів для особистих книг або бухгалтерії малого бізнесу. Правильна організація пошуку може важити більше за розмір моделі.

Обмеження, про яке варто пам'ятати: жорстка структура IRCoT «один пошук на речення» матиме труднощі із запитами до бухгалтерських книг, які потребують агрегування з багатьох паралельних потоків даних одночасно — наприклад, обчислення відхилення бюджету за дванадцятьма субрахунками витрат одночасно. Саме тут підхід із попереднім плануванням (як-от LATS або структурована декомпозиція запитів) доповнював би IRCoT, а не конкурував із ним.

Що читати далі

• У самій статті IRCoT DecomP (Decomposed Prompting, Khot et al. 2022, arXiv:2210.06726) цитується як ключовий базовий рівень — варто прочитати, щоб зрозуміти альтернативну стратегію декомпозиції запитань на підзапитання перед пошуком замість чергування.
• LevelRAG (arXiv:2502.18139) базується на ітеративному пошуку в стилі IRCoT, додаючи планувальник високого рівня, який переписує запити для кількох пошукових систем; це сучасніший погляд на ту саму проблему, що усуває жорсткість IRCoT.
• «Chain-of-Retrieval Augmented Generation» (CoRAG, arXiv:2501.14342) — це подальше дослідження 2025 року, яке структурує багатоетапний пошук як ланцюжок, роблячи цикл IRCoT явним і додаючи сигнал для навчання — природне продовження після цієї статті.