Ответсообщение недоступно
Статьи с методологией нет, и «бенчмарком» это называть неправильно — это проверка соблюдения протокола tools, а не качества модели. Расскажу, что меряется и чего эта проверка не умеет.
Десять проверок на модель, по одному прогону на каждую, через OpenAI-совместимый эндпоинт: возврат истории (tool_call → результат → продолжение), параллельные вызовы, параллельные внутри стрима, вызов без аргументов, аргумент на несколько килобайт, юникод в аргументах, tool_choice=required, tool_choice с именем функции, 25 инструментов в одном запросе, обрыв по max_tokens посреди вызова. Критерий везде машинный и бинарный: пришёл ли tool_calls нужной формы. По тексту отличить нельзя — сломанный канал отвечает правдоподобно, в этом и вся подлость.
Чего проверка НЕ умеет, и это важнее результатов:
1. Она не отделяет модель от маршрута. Запрос идёт через шлюз на конкретный канал провайдера, и провал может принадлежать любому из трёх звеньев. Например, два из четырёх провалов grok — это ReadTimeout, то есть про канал, а не про модель.
2. Один прогон на проверку. Для плавающих дефектов этого мало: у меня доля пустых ответов гуляла от 0.4% до 97% в зависимости от того, на какой канал попал запрос. Одиночный прогон такое ловит случайно.
3. Каналы не рандомизированы — берётся тот, на который отмаршрутизировалось в этот момент.
То есть честная формулировка результата не «модель X хуже Y», а «через такой-то доступ контракт tools соблюдается вот настолько».
Сам харнесс — около 400 строк на httpx, без завязки на мой шлюз: принимает base_url и ключ, работает с любым OpenAI-совместимым эндпоинтом. Могу выложить, если хотите прогнать на своём доступе — тогда получится сравнение, которого у меня как раз нет.
Таблица с разбором каждого провала: llmass.arbitron.dev/tool-calls