Gorilla: як навчання з урахуванням пошуку (Retriever-Aware Training) знижує рівень галюцинацій LLM API з 78% до 11%

Читаю статтю про Gorilla (Patil та ін., 2023, arXiv:2305.15334, NeurIPS 2024), оскільки вона стоїть на перетині двох проблем, з якими я постійно стикаюся: як змусити LLM-агента викликати правильний інструмент із правильними аргументами та як підтримувати цю здатність актуальною в міру зміни API? Відповіді тут практичні, а цифри вражаюче високі — але припущення, закладені в оцінку, заслуговують на більш ретельний аналіз, ніж зазвичай.

Стаття

Gorilla, автори Шишир Г. Патіл, Тяньцзюнь Чжан, Сінь Ван та Джозеф Е. Гонсалес з Каліфорнійського університету в Берклі, вирішує конкретну проблему: сучасні LLM галюцинують виклики API. Коли GPT-4 (станом на середину 2023 року) просять написати код, який викликає функцію певної бібліотеки, він часто генерує правдоподібні, але неправильні сигнатури функцій, неіснуючі моделі або застарілі назви аргументів. Gorilla — це модель на базі LLaMA з 7 мільярдами параметрів, спеціально налаштована для генерації точних викликів API. Вона навчена за допомогою методу, який автори називають навчання з урахуванням пошуку (Retriever-Aware Training, RAT). Ідея проста: під час навчання моделі показують знайдену документацію API разом із запитом користувача, відформатовану як "Використовуйте цю документацію API для довідки: <retrieved_API_doc_JSON>". Це вчить модель як читати документацію, так і довіряти знайденому контексту більше, ніж своїй параметричній пам'яті — властивість, яка приносить плоди під час інференсу, коли документація змінилася.

Набір даних для оцінки, APIBench, охоплює 925 API HuggingFace Model Hub, 95 API TorchHub і 696 API TensorFlow Hub, з десятьма синтетичними запитами на виконання інструкцій, згенерованими для кожного API за допомогою self-instruct. Метрикою оцінки є зіставлення піддерев AST (абстрактного синтаксичного дерева) — згенерований виклик API парситься і перевіряється на функціональну коректність — що також дозволяє вперше в таких умовах принципово виміряти рівень галюцинацій.

Ключові ідеї

• RAT робить документацію придатною для читання під час інференсу. Навчаючись на промптах, що включають знайдену документацію, Gorilla вчиться покладатися на знайдений текст, а не на згадування деталей API з ваг моделі. Це означає, що модель залишається актуальною в міру розвитку API без перенавчання.
• Точність zero-shot: Gorilla 59–84%, GPT-4 18–39%. На TorchHub Gorilla досягає 59,13% проти 38,70% у GPT-4. На HuggingFace — 71,68% проти 19,80%. На TensorFlow Hub — 83,79% проти 18,20%. Розрив найбільший там, де простір API найбільш різноманітний.
• Зниження рівня галюцинацій — головний результат. Рівень галюцинацій Gorilla становить 6,98% на TorchHub, 10,95% на HuggingFace та 5,40% на TensorFlow Hub. Показники GPT-4 на тих самих наборах даних коливаються від 36,55% до 78,65%.
• Оракул-пошук (oracle retriever) — це межа. Якщо знайдено ідеально точний документ (режим оракула), точність досягає 67–94%. Це теоретично найкращий випадок для будь-якої RAG-системи, і розрив між Gorilla zero-shot і цією межею — це простір для вдосконалення механізмів пошуку.
• Реальні системи пошуку поступаються. Перехід від оракула до GPT-Index під час оцінки знижує точність на 29,20%; BM25 знижує її на 52,27%. Стійкість моделі до шуму в пошуку реальна, але не безмежна.
• Оцінка через AST узагальнює результати. Підхід із зіставленням піддерев вимірює, чи є згенерований виклик функціонально правильним, а не просто синтаксично схожим. Це правильна метрика для будь-якого завдання, де результатом є код, який дійсно буде виконуватися.

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

Основне твердження залишається в силі: тонке налаштування на промптах, доповнених документацією, кардинально покращує точність викликів API та знижує рівень галюцинацій. Методологія оцінки AST є справді новаторською і явно кращою за порівняння рядків або оцінку людиною в масштабі. RAT — це чиста, відтворювана ідея.

Те, до чого я ставлюся скептично, — це охоплення бенчмарку. Усі три набори даних — HuggingFace, TorchHub, TensorFlow Hub — це реєстри моделей машинного навчання з дуже регулярною структурою API: ви завантажуєте модель за назвою, можливо, з кількома іменованими аргументами, і викликаєте метод типу predict. Інструкції згенеровані синтетично, що означає, що тестовий розподіл тісно пов'язаний із навчальним. Модель, налаштована на документації ML API за допомогою self-instruct і оцінена на таких самих запитах, не перевіряється на складних випадках, які виникають у реальній експлуатації: неоднозначні запити, багатокрокові робочі процеси, приведення типів аргументів, автентифікація, ліміти запитів або відновлення після помилок.

Деградація через пошук також більша, ніж стверджується у статті. Падіння точності на 52% при використанні пошуку BM25 є катастрофічним. Якщо пошукова система, яку ви розгортаєте в реальних умовах, більше схожа на BM25, ніж на оракула, переваги зникають. Автори визнають цей розрив, але не пропонують шляху для його подолання.

Нарешті, сама модель — це донавчання LLaMA 7B. Порівняння з GPT-4 zero-shot вражає, але воно не зовсім справедливе: GPT-4 не була навчена використовувати знайдену документацію. GPT-4 з підтримкою RAG і системним промптом, розробленим для читання документації API, майже напевно значно скоротив би цей розрив.

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

Патерн RAT безпосередньо застосовний до агентів зворотного запису Beancount. Агенту Beancount потрібно викликати команди CLI (bean-query, bean-report), Python API (beancount.loader, beancount.core) та сервіс FastAPI beancount-ledger — кожен зі специфічною семантикою аргументів, яка задокументована, але не обов'язково є в навчальних даних моделі. Підхід Gorilla каже: знайдіть відповідний фрагмент документації під час інференсу, вставте його в контекст і навчіть модель читати його та слідувати йому.

Показники галюцинацій є найкориснішим сигналом для фінансового контексту. 10% галюцинацій у назвах моделей ML — це неприємно. 10% галюцинацій у викликах мутації леджера — неправильні назви рахунків, помилкові коди валют, переплутані знаки дебету/кредиту — це проблема коректності. Це означає, що навіть навчений у стилі Gorilla агент потребує валідатора під час виконання перед фіксацією будь-якого запису, що узгоджується з тим, що CRITIC (LOG-012) показав щодо інтерактивної критики інструментів. Результат про деградацію пошуку підкріплює це: якщо реальний пошук знижує точність вдвічі, якість самого пошуку не може бути єдиною сіткою безпеки.

Методологія оцінки AST перекладається природним чином. Транзакції Beancount мають структуру, що піддається парсингу, і перевірка згенерованих директив за схемою за допомогою AST-зіставлення — це саме той тип легковагового валідатора, який можна запустити в pre-commit hook або в циклі агента.

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

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) — розширює проблему виклику API до 16 000 реальних REST API з багатокроковими ланцюжками використання інструментів; безпосередньо вирішує обмеження Gorilla, що оцінює лише поодинокі виклики реєстрів ML.
• The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, постер NeurIPS 2024) — пряма еволюція Gorilla у "живу" таблицю лідерів, що відстежує, як передові моделі покращують виклик функцій з часом; V3 додає багатоходові взаємодії, V4 додає агентний веб-пошук.
• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — оцінює LLM на 73 API у ширшому діапазоні доменів, включаючи фінанси та веб-сервіси, з багатоходовим використанням інструментів; корисне доповнення до більш вузького фокусу APIBench на ML.