Моё хобби — менять названия полей в тулах и смотреть, как это влияет на качество заполнения тулов данными, когда модель эти тулы вызывает. Потому что влияние там действительно есть))

Поначалу это влияние может быть незаметным, но на масштабе в сотни тестовых вызовов оно становится ощутимым — можно увидеть, как в 5-10% случаев нейронка пропускает какое-нибудь поле, заполняет его не тем, чем нужно, или не вызывает тул вообще (у DeepSeek такое часто происходит — он больше всех любит переспрашивать перед тем, как тул вызвать).

И если, например, ваша модель периодически пропускает какое-то одно поле, то дело может быть не только в описании поля, но и в его названии. Поэтому я люблю проводить эксперименты с названиями таких полей, стараюсь давать им как можно более конкретные и узкие наименования. Например, username вместо простого name или более конкретное product_page вместо широкого url.

Один из участников JS x AI Conf предложил проверить, что будет, если названия полей и тулов будут не на латинице, а на кириллице — ведь русские названия полей действительно должны быть максимально близки по смыслу к тому, что потенциально будет обсуждать русскоговорящий пользователь в чате с таким ассистентом. Соответственно, и работать это должно лучше. Да и JSON останется валидным, если вместо "username" я напишу "имя_пользователя".

Короче, я не мог не проверить эту гипотезу))

Перевёл все названия полей на русский язык, подключил GigaChat-2-Max, новую GigaChat-3-Ultra и DeepSeek-V4-Pro, и прогнал несколько ранов по одному из своих инструментов (1200 вызовов на каждую модель, 5 вызовов на каждый элемент в датасете). Затем сравнил результаты с одним из своих старых прогонов, где все поля и инструменты были на английском.

Результаты сравнивал по p95 latency и по точности заполнения полей. Получилось следующее:

DeepSeek-V4-Pro: количество ошибок заполнения полей снизилось с 6,9% до 6,7%, но зато p95 latency вырос с 12 до 18 секунд.

GigaChat-3-Ultra: ошибки в моих схемах выросли с 15,5 до 18,4%, зато p95 latency снизился с 6,6с до 3,9с!

Но самый интересный результат показал GigaChat-2-Max: p95 latency снизился с 6,19с до 4.67c, общее количество ошибок снизилось по моему датасету с 39,8% до 23,4%. Хотя по одному из полей ошибки выросли с 0,01% до 55,6% кейсов, содержащих данное поле. Так что, кажется, можно ещё подкрутить описание и выйти вообще в ноль)

Да, понимаю, это не те бенчмарки, по которым обычно сравнивают модели между собой. Не претендую на научную ценность исследования, но некоторая прикладная картина всё же вырисовывается — сразу видны слабые места в описаниях конкретно моих полей и инструментов. Чужие сухие бенчи такого никогда не покажут. Но всё-таки на кириллицу в JSONах я бы переходить не стал. Но если вдруг захочется заминмаксить latency ответа гиги на какой-нибудь простой задаче — кто знает, может быть и воспользуюсь таким лайфхаком)