Генерація з доповненим пошуком для завдань NLP з інтенсивним використанням знань

Стаття Льюїса та співавт. «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» (NeurIPS 2020), ймовірно, єдина наукова праця, яка найбільше вплинула на те, як сьогодні будуються архітектури виробничих систем ШІ. Через п'ять років після публікації вона залишається базовим орієнтиром, з яким порівнюють майже кожну мовну систему, що базується на документах. Я читаю її зараз, тому що все в моєму беклозі Bean Labs — від QA по реєстрах до пояснення аномалій — зрештою впирається в питання пошуку інформації, і я хочу чітко зрозуміти початкові дизайнерські рішення, перш ніж переходити до наступних розробок.

Стаття

Основна проблема, яку вирішує RAG, полягає в тому, що попередньо навчені мовні моделі «запікають» знання у ваги під час навчання, роблячи ці знання статичними, непрозорими та неможливими для оновлення без перенавчання. Льюїс та співавт. пропонують гібридну архітектуру: параметричну пам'ять (BART-large як генератор) у парі з непараметричною пам'яттю (щільний індекс FAISS понад 21 мільйоном уривків з Вікіпедії), з'єднані навченим ретрівером на основі Dense Passage Retrieval (DPR, Karpukhin et al. 2020). Під час виводу (inference) модель витягує топ-K релевантних уривків, а потім маргіналізує по них для отримання остаточного результату.

Стаття представляє два варіанти. RAG-Sequence виконує пошук один раз і використовує один і той самий набір документів для всієї згенерованої послідовності — це забезпечує більшу цілісність, але меншу адаптивність. RAG-Token дозволяє моделі звертатися до різних знайдених документів на кожному кроці генерації, що дає їй змогу синтезувати інформацію з кількох джерел прямо посеред речення. Обидва варіанти навчають ретрівер і генератор спільно під час тонкого налаштування (fine-tuning), хоча енкодер документів залишається замороженим, щоб уникнути витрат на перебудову індексу FAISS під час навчання.

Ключові ідеї

• RAG-Sequence досягає 44,5 Exact Match (точного збігу) на Natural Questions, 56,8 EM на TriviaQA та 68,0 EM на WebQuestions — що було найкращим результатом на момент публікації.
• На MS-MARCO для абстрактних відповідей на запитання RAG-Sequence отримує 40,8 ROUGE-L проти 38,2 для базової моделі BART — скромний, але стабільний приріст.
• Генерація запитань для Jeopardy: люди-оцінювачі визнали відповіді RAG більш фактичними, ніж у BART, у 42,7% випадків (BART був точнішим лише у 7,1%).
• На перевірці фактів FEVER RAG досягає 72,5% точності за трьома категоріями (на 4,3 пункти нижче спеціалізованих SOTA-рішень) без будь-якої специфічної для завдання інженерії.
• Заморожування енкодера документів під час навчання коштує лише близько 3 пунктів EM на NQ (44,0 → 41,2), що робить підхід обчислювально прийнятним ціною застарівання знань в індексі.
• Щільний пошук (dense retrieval) перевершує BM25 у всіх завданнях, крім FEVER, де запити, орієнтовані на сутності, надають перевагу перекриттю термінів — конкретний сигнал того, що розріджений пошук (sparse retrieval) не є однозначно гіршим.

Що пройшло перевірку часом, а що — ні

Фундаментальна ідея — відокремлення сховища знань від механізму міркування — збереглася чудово. Це дає вам оновлювані знання (просто переіндексуйте), атрибуцію джерел (знайдені уривки можна перевірити) і можливість узагальнення для QA у відкритому домені, генерації та перевірки фактів без специфічних архітектур. Ці властивості на практиці все ще важать більше, ніж конкретні цифри Exact Match.

Рецензенти NeurIPS мали рацію в тому, що технічна новизна обмежена. DPR та BART вже існували; RAG — це ретельна інтеграція, а не фундаментальний алгоритмічний прорив. Рішення про заморожений енкодер документів також створює тонку проблему, яку стаття дещо обходить: індекс будується один раз і стає «знімком» моменту. Будь-який факт, що змінився після побудови індексу, невидимий для моделі. Для статичних корпусів, таких як звіти SEC, це прийнятно. Для живих систем — цін у реальному часі, щоденних потоків транзакцій — це серйозне архітектурне обмеження, а не дрібниця.

Знахідка про «колапс пошуку» (retrieval collapse) заслуговує на більшу увагу, ніж вона отримує. У завданнях генерації історій модель навчилася повністю ігнорувати знайдені документи і генерувати текст із параметричної пам'яті. У статті зазначається, що це стається, коли завдання не «потребує специфічних знань», але не пояснюється механізм і не дається практикам системний спосіб це виявити. Агент, який непомітно припиняє пошук, створюючи видимість нормальної роботи — це саме той режим збою, який мене турбує у виробничих фінансових системах.

Обсяг пам'яті також не є тривіальним: лише індекс Вікіпедії потребує близько 100 ГБ оперативної пам'яті процесора. У статті це подається як перевага (непараметричну пам'ять «швидко оновлювати»), але це реальні операційні витрати, які визначили розвиток технології в наступні роки — у бік стиснутих індексів та наближеного пошуку.

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

Архітектура пошуку природно накладається на структуру проблем Beancount. Реєстр Beancount — це великий корпус документів, що працює лише на додавання (append-only), де окремі записи семантично пов'язані: витрати, що підлягають вирахуванню з податків, посилаються на категорію, категорія — на правило, правило — на фінансовий рік. Жодна параметрична модель, навчена на публічних даних, не знає специфічного плану рахунків конкретного користувача. Відокремлення міркування від знань у RAG робить його правильним структурним рішенням: налаштуйте генератор на формати бухгалтерських завдань, але обґрунтовуйте фактичні пошуки в реальному індексі реєстру користувача.

Практичне занепокоєння викликає те саме питання, яке стаття ідентифікує, але недооцінює: застарілі індекси. Якщо агент Beancount шукає в індексі, створеному вчора, він може пропустити сьогоднішні транзакції. Інкрементна індексація та тригерне переіндексування під час записів у реєстр мають бути частиною дизайну системи з самого початку, а не додаватися згодом. Інше питання — точність пошуку в структурованих даних. RAG був розроблений для прози Вікіпедії. Реєстр Beancount має діапазони дат, ієрархії рахунків та позначення валют, які ретрівери, оптимізовані для тексту, не обробляють нативно. Питання «чи можуть LLM міркувати над табличними даними», яке я досліджував раніше, безпосередньо обмежує те, що RAG може корисно знайти.

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

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — незалежно обробляє кожен знайдений уривок і об'єднує їх у декодері, досягаючи вищих показників NQ, ніж RAG, при простішій архітектурі; варто вивчити перед впровадженням підходу спільного читання RAG-Token.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — виконує пошук на вимогу під час генерації, передбачаючи, коли модель збирається галюцинувати; найбільш природне розширення ідей RAG у бік більш адаптивних агентів.
• «Fine-Tuning or Retrieval?» Ovadia et al. 2023 (arXiv:2312.05934) — систематичне порівняння методів ін'єкції знань у різних завданнях; емпіричні докази, які вам потрібні, перш ніж вирішувати, чи налаштовувати генератор під специфіку реєстрів, чи просто вдосконалювати пошук.