Локальный Tool Calling или «У нас есть BFCL-V4 дома»

В своей прошлой статье я рассказывал о компактной модели, которая по бенчмаркам смогла превзойти модели в 10 раз больше ее самой. О том, что это стало возможным благодаря особому подходу к обучения самой модели и что такую модель вполне реально запустить у себя локально.

Однако, когда дело касается локального запуска, думаю, далеко немногие из нас запускают модели в BF16 через vLLM на Nvidia H100. А значит, все эти красивые результаты по бенчмаркам на практике, вероятнее всего, очень далеки от того, что мы получим на практике.

И я решил это проверить.

1. Введение

1.1 Контекст исследования

Способность языковых моделей корректно вызывать внешние инструменты (tool calling/ function calling) становится критически важной для построения AI-агентов. Большинство существующих бенчмарков, включая Berkeley Function-Calling Leaderboard (BFCL), ориентированы на англоязычные сценарии, оставляя без внимания особенности работы моделей с другими языками. К тому же, подобные тесты определенно проводятся на изолированной системе в идеальных условиях (модель в BF16, vLLM, Nvidia H100+).

Русский язык представляет особый интерес благодаря:

• Сложной падежной системе (6 падежей)

• Свободному порядку слов

• Различиям в написании заимствованных слов (транслитерация vs оригинал)

Тестирование на потребительском желере представляет интерес благодаря:

• Возможности проверить насколько модель становится хуже после квантизации

• Действительно ли модель так хороша, как о ней заявлено на карточке в HF

• Насколько вообще стабильна модель вне идеальных условий

1.2 Цели исследования

1. Оценить качество tool calling для русскоязычных промптов

2. Выявить специфические паттерны ошибок

3. Сравнить эффективность моделей разного размера

4. Сформулировать практические рекомендации

2. Методология

2.1 Тестовый набор

Для локального тестирования я подготовил гибридный бенчмарк из 53 тестовых случаев, разделенных на две группы:

Группа 1: Кастомные тесты (28 тестов)
Разработаны специально для данного исследования с учетом особенностей русского языка.

Группа 2: BFCL-адаптированные тесты (25 тестов)
Адаптированы на основе тестов Berkeley Function-Calling Leaderboard с переводом промптов на русский язык.

Кастомные тесты распределены по 5 уровням сложности:

BFCL-тесто были сгруппированы на 4 уровня:

Для статистической значимости каждый тест выполнялся 9 раз (3 температуры x 3 прогона). Общее количество запусков: 477. Максимальное количество API вызовов за тестирование: 657.

2.2 Тестируемые модели

2.3 Условия эксперимента

• Платформа: LM Studio (v0.3.36)

• Температуры: 0.2, 0.5, 0.8

• Контекстное окно: 32 000 токенов

• Системный промпт и схемы инструментов: полностью на русском языке

• Валидация: строгое соответствие имен функций и аргументов (за исключением задач где подразумевается свободный ответ модели)

3. Результаты

3.1 Общая сводка

3.2 Парадокс масштаба

Неожиданным открытием стало то, что самая маленькая Instruct-модель (Qwen3-4B) показала лучший результат. При этом наблюдается закономерность, что с ростом размера показатели ухудшаются:

• Qwen-4B: 89.5% (лидер)

• Qwen-8B: 80.9% (-8.6 пп)

• Qwen-14B: 82.0% (-7.5 пп)

• GPT-OSS-20B: 55.8% (-33.7 пп) — абсолютный аутсайдр при наибольшем размере.

Особенно заметна разница на уровне L5 (сложные многошаговые сценарии):

• Qwen-4B: 60.0%

• Qwen-8B: 48.9%

• Qwen-14B: 28.9%

• GPT-OSS-20B: 0.0% (полный провал сложных цепочек)

3.3 Эффективность использования токенов

Nanbeige потребляет почти в 3 раза больше токенов, чем Qwen-4B, при значительно худшем результате — это следствие активного использования Chain-of-Thought рассуждений.

4. Анализ паттернов ошибок

4.1 Языковой дрейф (Language Drift)

Проблема: Модель переводит русские термины на английский при генерации аргументов.

Контекст теста L1-07 (Heavy Parameter Noise):

Этот тест проверяет способность модели фильтровать “шум” в промпте. Пользователь передает 7 значений, но инструмент принимает только 5 параметров. Модель должна:

1. Выделить 5 релевантных параметров (event_name, date, location, max_participants, category)

2. Игнорировать 2 “лишних” значения (organizer, budget)

3. Сохранить язык значений из промпта

Промпт:

Зарегистрировать конференцию 'AI Summit 2024' на 2024-09-20 в Берлине на максимум 500 участников. Организатор — Иван Смирнов, бюджет — $50000.

Результаты: Все пять моделей успешно справились со сложной частью задачи — они корректно выбрали 5 нужных параметров и отбросили “организатора” и “бюджет”. Однако четыре из пяти моделей провалились на более простой задаче — сохранении русского языка для параметра location:

Ключевой вывод: Модели демонстрируют парадоксальное поведение — они справляются с когнитивно сложной задачей (семантическая фильтрация параметров), но ошибаются в тривиальной (копирование строки на том же языке).

Причина: Модели с CoT рассуждают на английском внутри блоков thinking:

the user said "конференция", which translates to conference... location is Berlin...

Переключение на английский язык для внутренних рассуждений “заражает” генерацию аргументов.

4.2 Грамматические падежи

Проблема: Модель сохраняет падеж из исходного текста вместо приведения к начальной форме.

Пример из Qwen-8B (тест L1-07):

{
  "location": "Берлине"  // Предложный падеж вместо именительного "Берлин"
}

Анализ: Qwen-8B пытается быть “грамматически умной” — она видит в промпте “в Берлине” и сохраняет склонение. Qwen-4B просто копирует корень слова.

4.3 Перевод профессиональных терминов

Проблема: Модель переводит профессиональную терминологию на английский.

Пример из Qwen-4B (тест BFCL-3.2):

Промпт (второй ход диалога):

Назначить тикет на старшего инженера

Ответ модели:

{
  "name": "assign_ticket",
  "arguments": {
    "assignee": "Senior Engineer"  // Ожидалось: "старший инженер"
  }
}

Вывод: Даже самая точная модель допускает перевод терминов, которые воспринимаются как “технические”.

4.4 Проблема параллельных вызовов

Проблема: Модели с режимом thinking склонны к последовательной стратегии вместо параллельной.

Пример из Nanbeige-3B (тест L5-01):

Промпт:

Получить погоду в Москве, Париже и Токио, затем создать файл с отчетом

Ответ модели — только один вызов:

{
  "name": "get_weather",
  "arguments": { "city": "Москва" }
}

Анализ рассуждений (блок thinking):

Мне нужно вызвать get_weather для Москвы, Парижа и Токио… Поэтому сейчас только первый вызов: get_weather для Москвы. После получения ответа продолжу…

Модель понимает задачу, но её стратегия рассуждений полностью исключает параллельные вызовы. Это объясняет катастрофический результат Nanbeige на L5: 4.4%.

4.5 Формат ответов и CoT-блоки

Проблема: Теги thinking в ответе нарушают строгий формат.

Контекст теста BFCL-4.5 (Format Sensitivity):

Этот тест экспертного уровня специально проверяет “чистоту” вывода модели. Задача элементарная — вычислить площадь круга с радиусом 5. Но критерий успеха строгий: ответ должен содержать только вызов инструмента, без каких-либо пояснений, “вежливых фраз” или блоков рассуждений.

Промпт:

Вычислить площадь круга с радиусом 5

Ожидаемый ответ (чистый формат):

{"name": "circle_area", "arguments": {"radius": 5}}

Типичный ответ модели с CoT (провал):

<think>
Okay, the user wants to calculate the area of a circle...
The formula is pi * r^2, so I need to call circle_area with radius 5.
</think>

{"name": "circle_area", "arguments": {"radius": 5}}

Результаты по моделям:

Ключевой вывод: Все модели корректно определили нужный инструмент и параметры. Но три модели с режимом thinking (Qwen-8B, Qwen-14B, Nanbeige) провалили тест исключительно из-за формата ответа. Их блоки рассуждений помечаются валидатором как “Response contains conversational filler”. Единственная модель, имеющая рассуждения, но прошедшая этот тест – GPT-OSS-20B.

Практическое следствие: В production-сценариях, где парсер ожидает чистый JSON, модели с CoT требуют дополнительной постобработки для удаления тегов thinking.

4.6 Тесты экспертного уровня: логика и цепочки рассуждений

Два теста из экспертной группы BFCL-4.x четко разделяют модели на “рассуждающие” и “механические”.

BFCL-4.6: Reasoning & Constraints (Логика с условием OR)

Суть теста: Модель должна решить, инвестировать ли 1000$ в актив A, если выполняется условие: доходность > 10% ИЛИ риск < 5%. Дано: доходность 8%, риск 3%.

Правильный ответ: риск 3% < 5%, условие выполнено → вызвать execute_investment с параметром risk_pct=3.

Анализ провалов: Granite и GPT-OSS проявили “агентскую осторожность” — вместо принятия решения они “переложили ответственность” на вспомогательный инструмент анализа. Это указывает на неспособность к самостоятельному логическому выводу.

BFCL-4.3: Web Search Multi-Hop (3-шаговая цепочка)

Суть теста: Последовательный поиск с передачей контекста между шагами:

1. “Какая страна производит чай Da Hong Pao?” → Китай

2. “Кто самый богатый человек в [результат шага 1]?” → [имя]

3. “Расскажи подробнее о [результат шага 2]”

Ключевой вывод: Тесты экспертного уровня выявляют принципиальную разницу между моделями. Qwen и Nanbeige действительно рассуждают над условиями задачи. Granite и GPT-OSS работают более механически, что приводит к провалам в логических развилках и цепочках.

5. Анализ по моделям

5.1 Qwen3-4B-Instruct — Лидер (89.5%)

Сильные стороны:

• Точное копирование русских терминов без перевода

• Стабильность во всех температурных режимах (89-90%)

• Отсутствие лишнего текста в ответах

• Минимальное потребление токенов

Слабые стороны:

• Ограниченная логика на L4-L5

• Иногда переводит профессиональные термины

Рекомендация: Оптимальный выбор для русскоязычных агентов с простыми и средними задачами.

5.2 Qwen3-8B и Qwen3-14B — Парадокс масштаба

Общие проблемы обеих моделей:

• Активное использование английского в CoT-блоках

• Грамматическая “умность” (сохранение падежей)

• Частое нарушение строгого формата

Qwen-8B специфика:

• Лучший результат на L4 (85.9%) благодаря логике

• Чаще ошибается на L3 (многоходовые диалоги)

Qwen-14B специфика:

• Лучший результат на L2 (97.6%) — точный выбор инструмента

• Катастрофа на L5 (28.9%) — “агентская лень”, пропуск шагов

5.3 Nanbeige-3B-Thinking — Самая думающая

Особенности:

• Рекордное потребление токенов (1.1M) — в 2.8 раза больше Qwen-4B

• Детальные рассуждения на каждый шаг

• Полный провал параллелизации

Критический дефект: Стратегия “один вызов за раз” несовместима с требованиями Level 5. Модель явно осознает необходимость нескольких вызовов, но её архитектура рассуждений не позволяет их выполнить параллельно.

5.4 Granite-4.0-h-micro — Аутсайдер (63.3%)

Общая оценка: Модель демонстрирует сильнейшую зависимость от языка промпта. Сравнение с англоязычным прогоном (Success Rate 75.5%) показывает, что 12% ошибок вызваны исключительно языковым барьером.

Проблемы в русскоязычной подборке:

• Сильнейший языковой дрейф: перевод “Берлин” -> “Berlin” даже при наличии русских схем инструментов.

• Низкий L2 (67.5%): ошибки в выборе инструмента на русском языке.

Проблемы, сохраняющиеся в обоих языках (Core Logic):
Несмотря на рост точности в английской версии (L1: 100%, L2: 89%), уровни L3 и L5 остаются низкими (~53% и ~16%). Главная причина — “Агентская спешка” (Agentic Shortcut).

Пример из теста L3 (Sequential Task):

• Задача: “Прочитать файл config.json и отправить его содержимое по email”.

• Ожидаемое поведение: Ход 1 — read_file, Ход 2 — send_email.

• Поведение Granite: Модель пытается вызвать оба инструмента сразу в первом ходу. При этом она галлюцинирует содержимое файла, который еще не прочитала, чтобы вставить его в тело письма.

Вывод: Granite-4B хорошо справляется с простыми задачами на родном языке, но его логика многошагового планирования фундаментально ограничена — модель склонна к “жадному” выполнению всей цепочки сразу, что ведет к провалу в реальных сценариях.

5.5 GPT-OSS-20B — Катастрофа параллелизации (55.8%)

Особенности:

• Крупнейшая модель в тесте (20B параметров)

• Минимальное потребление токенов (358K) — быстрые ответы без рассуждений

• Хороший L1 (85.5%) — базовые вызовы работают

Критическая проблема — L4 и L5:

GPT-OSS-20B демонстрирует полную неспособность к параллельным вызовам. Из 122 ошибок на L4-L5 подавляющее большинство — “Missing parallel calls”. Модель последовательно вызывает только один инструмент, даже когда задача явно требует нескольких.

Парадокс размера: Несмотря на 20B параметров (в 5 раз больше Qwen-4B), модель показывает худший общий результат. Вероятная причина — архитектура не оптимизирована для tool calling и отсутствует обучение на параллельных вызовах.

Языковой дрейф: Как и другие крупные модели, GPT-OSS переводит “Берлин” в “Berlin” в тесте L1-07.

6. Практические выводы

6.1 Для разработчиков AI-агентов

1. Выбор модели: Для русскоязычных задач предпочтительнее использовать Qwen3-4B-Instruct, а не более крупные модели.

2. Локализация обязательна: Системный промпт и схемы инструментов должны быть полностью на русском языке — это снижает языковой дрейф.

3. Мягкая валидация: Рекомендуется допускать варианты написания (Berlin/Берлин) и падежные формы (Берлин/Берлине) для повышения робастности.

4. Избегайте CoT для tool calling: Модели без режима рассуждений показывают лучшие результаты на строгих бенчмарках.

6.2 Для исследователей

1. Парадокс масштаба требует изучения: Почему большие модели хуже справляются с форматом? Возможно, это связано с переобучением на англоязычных данных.

2. CoT vs Tool Calling: Необходимы исследования по совместимости цепочек рассуждений с параллельными вызовами.

3. Билингвальные бенчмарки: Существующие лидерборды (BFCL) не отражают реальную производительность для неанглоязычных сценариев.

6.3 Ограничения исследования

• Тестирование проводилось только на квантизованных моделях (Q4_K_M)

• Ограниченный размер тестового набора (53 теста)

• Строгая валидация может занижать реальную полезность моделей

7. Заключение

Исследование показало, что качество tool calling на русском языке зависит не столько от размера модели, сколько от её архитектуры и стратегии генерации ответов:

1. Qwen3-4B-Instruct — оптимальный выбор для русскоязычных агентов благодаря точному следованию формату и копированию терминов.

2. Модели с CoT проигрывают на строгих бенчмарках из-за языкового дрейфа и формальных нарушений, несмотря на лучшее “понимание” задачи.

3. Параллельные вызовы остаются сложной задачей для всех моделей, особенно использующих последовательные рассуждения.

4. Локализация инфраструктуры (промптов, схем) критически важна для минимизации ошибок.

Приложение

Распределение ошибок по типам

Расшифровка типов ошибок:

1. Position mismatch — Несовпадение аргументов

   • Модель вызвала правильный инструмент, но с неверными значениями параметров

   • Примеры: “Berlin” вместо “Берлин”, “Берлине” вместо “Берлин”, неверный формат даты

   • Самая частая ошибка у всех моделей

2. Missing parallel — Отсутствие параллельных вызовов

   • Задача требовала нескольких одновременных вызовов, но модель сделала только один

   • Пример: промпт “погода в Москве, Париже и Токио” требует 3 вызова get_weather, модель делает 1

   • Рекорд у GPT-OSS-20B (122 ошибки) — полная неспособность к параллелизации

3. No tool calls — Отсутствие вызовов инструментов

   • Модель ответила текстом вместо вызова инструмента

   • Пример: вместо вызова calculate() модель пишет “15 умножить на 23 равно 345”

   • Часто связано с “агентской осторожностью” — модель решает уточнить запрос

4. Format error — Ошибка формата ответа

   • Вызов инструмента корректный, но ответ содержит посторонний текст

   • Пример: блоки thinking, вежливые фразы, пояснения вне JSON

   • Исключительно проблема моделей с CoT (Qwen-8B, Qwen-14B, Nanbeige)

5. Extra calls — Лишние вызовы инструментов

   • Модель вызвала больше инструментов, чем требовалось

   • Пример: на запрос “удалить файл” модель сначала вызывает list_files, затем delete_file

   • Критическая проблема Granite (53 ошибки) — склонность к “перестраховке”

Ссылки:

Мой бенчмарк