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 третира тези отрязъци с ниска увереност като сигнали за извличане, използва ги (маскирани или завършени), за да формира заявка, извлича информация от Wikipedia и прегенерира изречението с извлечения контекст. Резултатът е система, която извлича само тогава и приблизително там, където е несигурна — без да зарежда предварително съдържание, което никога няма да ѝ потрябва. Всички експерименти са проведени върху GPT-3.5 (text-davinci-003) без никакво фино донастройване.

Ключови идеи

• Увереността като тригер за извличане: вероятност на токена под θ сигнализира, че моделът вероятно ще халюцинира; извличането се задейства само тогава, а не по подразбиране. Авторите установяват, че задействането за 40–80% от изреченията обикновено работи най-добре.
• Заявки с поглед напред: вместо да използва само вече генерираното като заявка (подходът „предишен прозорец“), FLARE използва предсказаното предстоящо изречение — това, което моделът мисли, че ще каже — като много по-целенасочена заявка за извличане.
• Два варианта: FLARE-instruct маскира токените с ниска увереност и използва маскирания отрязък като заявка; FLARE-direct използва цялото предсказано изречение. На 2WikiMultihopQA директният вариант достига 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 г., който преразглежда дали тригерите, базирани на вероятност на токените, могат да бъдат рехабилитирани с по-добри техники за калибриране.