FLARE: Активна генерація з доповненням пошуком

Минулого тижня я читав основоположну статтю про RAG від Lewis та ін. — один пошук, додавання результату на початок, генерація. Це працює, але передбачає, що ви заздалегідь знаєте, що вам знадобиться. FLARE (EMNLP 2023) атакує це припущення безпосередньо: що, як найкращий час для пошуку — це середина речення, саме тоді, коли модель починає відчувати невпевненість? Це питання варто ретельно обміркувати для будь-якої системи — наприклад, агента Beancount — якій потрібно оперувати історією головної книги, що не вміщується в одне вікно контексту.

Стаття

"Active Retrieval Augmented Generation" авторів Zhengbao Jiang, Frank F. Xu, Luyu Gao, Zhiqing Sun, Qian Liu, Jane Dwivedi-Yu, Yiming Yang, Jamie Callan та Graham Neubig пропонує FLARE: Forward-Looking Active REtrieval augmented generation (Прогностична активна генерація з доповненням пошуком). Проблема, яку вони вирішують, — це галюцинації під час тривалої генерації, коли модель повинна витягувати кілька фрагментів знань протягом розгорнутої відповіді. Стандартний RAG виконує пошук один раз під час запиту і сподівається, що знайдений уривок охопить усе, що знадобиться для генерації — це прийнятно для коротких відповідей, але ненадійно для відповідей з кількох абзаців.

FLARE розбиває генерацію на кроки на рівні речень. На кожному кроці система створює кандидатне наступне речення. Якщо будь-який токен у цьому кандидаті має прогнозовану ймовірність нижче порогу θ, FLARE розглядає ці фрагменти з низькою впевненістю як сигнали для пошуку, використовує їх (або маскованими, або доповненими) для формування запиту, здійснює пошук у Вікіпедії та повторно генерує речення з отриманим контекстом. У результаті система звертається до пошуку лише тоді і приблизно там, де вона невпевнена — не завантажуючи пошук наперед контентом, який їй може ніколи не знадобитися. Усі експерименти проводилися на GPT-3.5 (text-davinci-003) без жодного донавчання.

Ключові ідеї

• Впевненість як тригер пошуку: ймовірність токена нижче θ сигналізує про те, що модель, ймовірно, буде галюцинувати; пошук запускається лише тоді, а не за замовчуванням. Автори виявили, що запуск пошуку для 40–80% речень зазвичай працює найкраще.
• Прогностичні запити (Forward-looking queries): замість того, щоб використовувати як запит лише те, що вже було згенеровано (підхід «попереднього вікна»), FLARE використовує прогнозоване наступне речення — те, що модель думає, що вона скаже — як значно точніший пошуковий запит.
• Два варіанти: FLARE-instruct маскує токени з низькою впевненістю і використовує маскований фрагмент як запит; FLARE-direct використовує все прогнозоване речення. На 2WikiMultihopQA варіант direct досягає 51.0 EM проти 42.4 у варіанта instruct.
• Переваги над одноразовим пошуком реальні, але нерівномірні: на 2WikiMultihopQA FLARE-direct досягає 51.0 EM проти 39.4 для одноразового пошуку та 28.2 без пошуку — вирішальне покращення. На ASQA розрив набагато менший (41.3 проти 40.0), а на WikiAsp (UniEval 53.4 проти 52.4) — майже нічия.
• Явні випадки невдач: автори повідомляють, що FLARE не дає переваг на Wizard of Wikipedia та ELI5, де короткі вихідні дані означають, що багатоетапний пошук додає накладних витрат без користі.
• Вартість: оскільки генерація та пошук переплітаються, кожен приклад може ініціювати кілька завершень мовної моделі та викликів пошуку. Кешування не є тривіальним.

Що працює, а що — ні

Прогностичне формулювання — це справді розумна частина. Використання прогнозованого контенту як пошукового запиту є більш інформативним, ніж лише префікс, особливо для багатоходових завдань, де проміжні висновки визначають, який факт вам знадобиться далі. Розрив 51.0 проти 39.4 EM на 2WikiMultihopQA підтверджує це.

Але сигнал впевненості FLARE повністю залежатиме від того, наскільки добре модель відкалібрована. Ймовірності токенів у базовій моделі завершення, такій як text-davinci-003, досить добре корелюють із невпевненістю. Це не стосується чат-моделей, налаштованих за допомогою інструкцій або RLHF, які часто є надмірно впевненими — вони видають високоймовірні токени навіть під час галюцинування. Наступне дослідження 2024 року, Unified Active Retrieval (UAR, arXiv:2406.12534), оцінює FLARE на ширшому наборі рішень про пошук і виявляє, що він досягає лише 56.50% точності в різних сценаріях порівняно з 85.32% для підходу UAR на основі класифікатора. Проблема калібрування — це не поодинокий випадок; це основне припущення, на якому базується метод.

Також існує питання деталізації пошуку, яке стаття не розкриває повністю. Тригери на рівні речень — це розумна евристика, але деякі факти охоплюють межі частин речень, а інші локалізовані в імені однієї сутності. Низька ймовірність числового токена (сума в доларах, дата), ймовірно, повинна запускати пошук інакше, ніж низька ймовірність сполучного слова. У статті до всіх токенів із низькою впевненістю ставляться симетрично.

Нарешті, цикл «повторної генерації у разі невпевненості» створює затримку. Автори визнають це, але не кількісно оцінюють її відносно бюджету затримки, що важливо для інтерактивних програм або програм, що працюють у режимі реального часу.

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

Агент Beancount, який підбиває підсумки багаторічної головної книги, не може отримати всі історичні записи наперед — контекст переповниться, і більша його частина буде нерелевантною для поточної відповіді. Дизайн FLARE добре відповідає цій проблемі: згенерувати першу чернетку коментаря до звірки, помітити низьку впевненість щодо поточного балансу конкретного постачальника, отримати лише відповідні транзакції, а потім повторно згенерувати це речення. Сама схема є логічною.

Проте проблема калібрування викликає серйозне занепокоєння. Промислові фінансові агенти майже повсюдно використовують чат-моделі, налаштовані за інструкціями (GPT-4, Claude, Gemini), а не базові моделі завершення. Якщо ці моделі надмірно впевнені — а це часто трапляється з числовими твердженнями — вони пропускатимуть пошук саме тоді, коли його варто було б запустити. Агент запису Beancount, який галюцинує дату транзакції з високою впевненістю і ніколи не звертається до пошуку для перевірки, гірший за непотрібного.

Практичний урок полягає в тому, щоб поєднувати прогностичну побудову запитів FLARE із тригером пошуку, який не покладається виключно на ймовірність токена. Явні маркери невпевненості (хеджувальні фрази, круглі числа, іменовані сутності, які модель не бачила нещодавно) могли б доповнити сигнал впевненості. Або скористайтеся підходом UAR: навчіть легкий класифікатор на прихованих станах моделі, який є стійкішим до неправильного калібрування, ніж необроблені логіти.

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

• IRCoT: "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions" (arXiv:2212.10509) — поєднує пошук із кроками CoT, а не з впевненістю в токенах; варто порівняти безпосередньо з FLARE у багатоходових завданнях.
• Unified Active Retrieval (UAR, arXiv:2406.12534) — пряме продовження, яке розкриває проблему калібрування у FLARE і пропонує рішення для пошуку на основі класифікатора у чотирьох сценаріях.
• "Adaptive Retrieval without Self-Knowledge? Bringing Uncertainty Back Home" (arXiv:2501.12835) — стаття 2025 року, яка переглядає можливість відновлення тригерів на основі ймовірності токенів за допомогою кращих методів калібрування.