Мой блог
Выбор функций и отказ от вызова в ELM: сравнение с классической генерацией через LLM
Подключение внешних инструментов к языковым моделям ставит перед разработчиками две противоположные задачи: корректно собрать параметры вызова, когда инструмент действительно нужен, и вовремя воздержаться от действий, если ни одна функция не подходит под запрос пользователя. Разработчик экспериментального проекта ELM представил результаты тестирования альтернативного подхода к function calling: вместо свободной текстовой генерации вызова нейросеть лишь ранжирует заранее подготовленные кандидаты.
В опубликованном эксперименте автор сопоставил работу своей архитектуры и локальной нейросети Bonsai-2-27B. В то время как классический подход показал серьезное преимущество в точном конструировании сложных аргументов, экспериментальный метод выбора кандидатов продемонстрировал многократное превосходство в сценариях, требующих корректного отказа от выполнения неподходящей команды.
Архитектура ELM: разделение выбора функций и формирования аргументов
В архитектуре экспериментальной системы ELM генерация текста вызова полностью исключена из задач нейросети. Процесс разделен на программную подготовку данных и последующую экспертную оценку. На первом этапе код извлекает из пользовательского запроса возможные фрагменты строк, которые могут служить значениями аргументов функций. Затем языковая модель TypeSafe Jev выступает в роли так называемого судьи: она не пишет код или JSON, а лишь рассчитывает вероятности для предложенных вариантов в рамках жестко заданного формата.
Среди доступных вариантов судье всегда предоставляется опция «ни одна функция не подходит». Если выбор сделан в пользу конкретного инструмента и его параметров, итоговую синтаксическую структуру вызова формирует программный код. Подобное разделение создает фундаментальное ограничение: если необходимого значения аргумента изначально не было в исходном тексте запроса, система не сможет его придумать или сконструировать простым срезом подстрок.
На ранних этапах отладки автор запускал бенчмарк Berkeley Function Calling Leaderboard (BFCL) v3 через собственный тестовый скрипт, используя выборки по 60 задач на категорию. Система показала 50,0% точности на категории simple, 50,0% на multiple и 86,7% на irrelevance, где правильным поведением был именно отказ. Примечательно, что в базовых тестах само имя функции определялось верно в 100% случаев, а все ошибки происходили исключительно из-за неверного подбора параметров.
Попытка внедрить предварительные нормализаторы дат, времени и физических единиц измерения дала скромный прирост: точность выросла до 51,7% и 53,3%, прибавив лишь по одной-две решенные задачи. Стало очевидно, что программное расширение списка кандидатов и обучение классификатора корректному выбору новых типов данных требуют независимой доработки.
Интеграция с официальным раннером BFCL v4
Чтобы исключить неточности самодельного чекера и обеспечить воспроизводимость, проект был переведен на официальный пакет bfcl-eval версии 2026.3.23 с тестовыми наборами BFCL v4, проверяющими синтаксическое дерево (AST) вызовов по строгим правилам.
Первые пробные прогоны по десяти записям выявили технический сбой: категории с параллельными вызовами (parallel и parallel_multiple) завершились с нулевым результатом. Причина заключалась в том, что обработчик возвращал одиночный вызов, тогда как спецификация теста требовала массив вызовов в едином ответе. После доработки кода запросы стали разбиваться на подзапросы: судья сначала определяет необходимое число вызовов, а затем последовательно подбирает функцию и аргументы для каждого из них. На короткой выборке это подняло результат до 4 из 10 в parallel и 2 из 10 в parallel_multiple.
В процессе интеграции также была решена проблема сохранения метрик. При отсутствии переменной окружения BFCL_PROJECT_ROOT официальный пакет записывал данные прямо в каталог site-packages окружения Python за пределами репозитория. Явное указание рабочего каталога до импорта библиотек позволило фиксировать артефакты и контрольные суммы непосредственно рядом с кодовой базой.
Результаты прямого сравнения с Bonsai-2-27B
Полноценное сравнение проводилось на 1240 однотуровых записях для Python, разбитых на пять категорий. В качестве контрольной модели выступала локальная сеть Bonsai-2-27B, формировавшая вызовы самостоятельно через OpenAI-совместимый интерфейс. Обе системы тестировались на одной машине в рамках официального фреймворка.
| Категория | Число записей | Точность ELM | Точность Bonsai-2-27B |
|---|---|---|---|
| simple_python | 400 | 53,0% | 89,5% |
| multiple | 200 | 56,0% | 89,5% |
| parallel | 200 | 36,0% | 89,0% |
| parallel_multiple | 200 | 7,0% | 80,5% |
| irrelevance | 240 | 88,3% | 15,4% |
| Все 5 категорий | 1240 | 50,2% | 73,6% |
В общем зачете Bonsai-2-27B дала 913 правильных ответов против 622 у ELM. Однако итоговая усредненная метрика маскирует диаметрально противоположное поведение систем на разных типах задач. В сборке сложных параллельных инструкций классическая генерация оказалась на порядок надежнее, но в сценариях с нерелевантными запросами модель Bonsai справилась лишь в 37 случаях из 240 (15,4%), в то время как ELM корректно проигнорировала неподходящие инструменты в 212 случаях из 240 (88,3%).
Структура ошибок классификатора ELM
Детальный анализ 276 ошибок ELM в категориях simple_python и multiple показал, что имя функции было определено ошибочно всего один раз. Основная масса сбоев распределилась следующим образом:
- 77,2% — неверное значение аргумента или несоответствие типа данных;
- 16,7% — пропуск обязательного параметра из-за отсутствия подходящего кандидата в тексте;
- 5,8% — ошибка в определении числа необходимых вызовов.
В параллельных категориях ключевым фактором неудач (58,6% из 314 ошибок) стало именно неверное предсказание требуемого количества вызовов функции на один сложный запрос.
Анализ вычислительных затрат и скорости
По замерам времени на одну запись ELM отработал быстрее: 1,15 секунды против 2,98 секунды у Bonsai-2-27B. Расчетная стоимость на 1000 запросов составила $0,0716 для ELM (исходя из 2 114 484 обработанных входных токенов классификатора по тарифу $0,042 за 1 млн токенов) против условных $0,5051 у Bonsai (по исторической базовой ставке $0,80 за 1 млн токенов для моделей класса 27B).
Автор подчеркивает, что прямое сопоставление потребления памяти здесь некорректно: для Bonsai зафиксирован объем весов в оперативной памяти (10 695 МБ), тогда как для ELM доступна лишь нижняя граница RSS локальных дочерних процессов (от 307,9 МБ), без учета аппаратных ресурсов внешнего сервиса, исполняющего роль судьи.
Границы исследования и дальнейшие шаги
Полученные результаты строго ограничены пятью однотуровыми Python-наборами. Тесты для языков Java и JavaScript, а также многотуровые сценарии multi_turn в бенчмарк не включались, так как последние требуют сохранения состояния между итерациями диалога и исполнения функций в рантайме. Кроме того, текущий механизм нарезки подстрок не поддерживает конструирование сложных составных структур — словарей и вложенных списков.
Анализ набора live показал, что от 83% до 100% реальных запросов технически укладываются в синтаксические рамки ELM, однако точность на них еще предстоит измерить. Ключевой практический вывод автора заключается в перспективности гибридного пайплайна: использование быстрого классификатора для валидации применимости инструментов с последующей передачей запроса генеративной LLM только в тех случаях, когда вызов действительно необходим.
