Gorilla: Как обучение с учетом поиска (RAT) снижает уровень галлюцинаций LLM API с 78% до 11%

Читаю статью о Gorilla (Patil et al., 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) точность достигает 67–94%. Это теоретически лучший случай для любой RAG-системы, и разрыв между Gorilla в режиме zero-shot и этим потолком — это пространство для улучшения механизмов поиска (retriever).
• Реальные поисковики не справляются. Переход от оракула к GPT-Index во время оценки снижает точность на 29,20%; BM25 снижает ее на 52,27%. Устойчивость модели к шуму поиска реальна, но не безгранична.
• Оценка через AST универсальна. Подход с сопоставлением поддеревьев измеряет функциональную корректность вызова, а не просто синтаксическое сходство. Это правильная метрика для любой задачи, где выходным результатом является код, который действительно будет исполняться.

Что подтверждается, а что — нет

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

В чем я скептичен, так это в охвате бенчмарка. Все три набора данных — HuggingFace, TorchHub, TensorFlow Hub — представляют собой реестры ML-моделей с очень регулярной структурой API: вы загружаете модель по имени, возможно, с несколькими именованными аргументами, и вызываете метод типа predict. Инструкции генерируются синтетически, что означает близость тестового распределения к тренировочному. Модель, настроенная на документации ML API и обученная через self-instruct, оцениваемая на запросах self-instruct для тех же ML API, не проверяется на тех сложностях, которые возникают в продакшене: неоднозначные запросы, многошаговые рабочие процессы, приведение типов аргументов, аутентификация, лимиты запросов или обработка ошибок.

Деградация из-за поиска также более значительна, чем преподносится в статье. Падение точности на 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 хуке или цикле агента.

Что почитать дальше

• 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 poster) — прямое развитие Gorilla в живой лидерборд, отслеживающий, как передовые модели со временем улучшают вызов функций; V3 добавляет многоходовые взаимодействия, V4 — агентный веб-поиск.
• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — оценивает LLM на 73 API в более широком диапазоне областей, включая финансы и веб-сервисы, с многоходовым использованием инструментов; полезное дополнение к узкому ML-фокусу APIBench.