Почему SGR в агентных задачах - плохая идея?

Ринат в последнее время пишет про SGR и его применение в агентных задачах. Про сам SGR подробнее можно посмотреть здесь.

TL;DR: SGR — частный случай Structured Output, где перед финальным ответом задаются «поля», которые позволяют вести LLM более контролируемо к нужной области ответа, а затем, учитывая пункты, которые она написала «выше», LLM формирует финальный ответ (или выполняет действие, которое также жёстко задано JSON-схемой).

В чём вообще отличие? Если и SGR, и Tools приводят к JSON для вызова тула?

Кажется, результат должен быть одинаковым — и в SGR мы даже можем что-то дополнительно контролировать. Звучит супер!
Как LLM пишет ответ в случае SGR (например, для тулзы)?
LLM генерирует ответ; отдельный бэкенд (например, xgrammar) выступает в роли конечного автомата: читает переданную схему, строит грамматику и «не даёт» LLM писать токены, не соответствующие схеме.

В знаменитом chat.completions() нам вернётся сообщение вида {role: 'assistant', content: '<JSON-строка>', tool_calls: []}; потом мы парсим content и подкладываем в историю сообщение вида {role: 'tool', content: '<результат тула>'}. Я намеренно опустил пару деталей для наглядности, но в общих чертах так оно и выглядит.

Не видите подвоха?
1) В chat-template поле tools пустое (если LLM поддерживает tools).
2) LLM пишет какой-то JSON, а в ответ ей прилетает следующее сообщение с ролью tool (хотя тулов у LLM «нет» — они не были явно переданы через tools).

Следствие.
LLM пишет JSON, а в ответ получает результат тула. Если посмотреть на известные бенчмарки по tool calling, такого поведения вообще не ожидается: модели обычно обучаются и оцениваются в сценариях, где доступные инструменты передаются явно, а вызов идёт через структурированное поле function/tool-calls.
Представляете, что происходит в голове у LLM, когда подобных диалогов нет ни в открытых датасетах, ни в референсных туториалах провайдеров: даже семантика вызова tools теряется. В чат-истории внезапно появляются «инструменты», хотя их не передавали через tools, и «вызов» сделан абстрактным JSON в content, а не через нативное поле tool_calls. Официальные гайды OpenAI/Anthropic учат обратному: передайте список tools в шаблон, модель выберет нужную функцию и сформирует аргументы в структурированном поле; не вызывайте того, чего нет в tools.

Как работает TOOLS?
Tools - это поле, которое подмешивается в chat-template. На этапе SFT/RL модель учится работать именно с таким протоколом: не вызывать то, чего нет, и вызывать то, что доступно. Это зафиксировано и в провайдерских практиках (OpenAI/Anthropic), и в ресерчерских наборах для оценки агентости (When2Call (NVIDIA) tool hallucination rate тому пример внутри бенча, BFCL/Gorilla включает специальную категорию Function Relevance Detection: когда ни один из переданных тулов не подходит - модель должна не делать call. Есть и Chatting Capability: вообще без переданных тулов, проверяется, что модель пишет ответ как чат-бот, не вызывая функции).
Модель не должна пользоваться тулами, если их не передали в tools. Какие tools передали — такими и пользуется.

«Но мы же теряем reasoning и отладку?»
Нет, не теряем [Пояснение к лучшей реализации находится следующим постом]. Никто не запрещает первыми аргументами (по аналогии с SGR) сделать поля в функции — «reasoning», ключевые «якоря» и т. п. За счёт этого вы получаете:

1) более нативное использование инструментов (внутри официального "протокола" tool-calling),
2) более прозрачную историю сообщений,
3) более стабильную систему.

Да, здесь reasoning идёт в аргументы функции (которых может быть много), а не в выборе нужной функции. Но даже крупные компании не рекомендуют засовывать слишком много функций в один промпт - если модель «теряется», лучше декомпозировать систему/поправить промпты, а не «эмулировать» tool-calls через SGR.

Ради эксперимента можете измерить перплексию на диалогах с параллельными вызовами тулов в форматах SGR vs Tools и посмотреть, какой формат «интуитивнее» для модели.

Чуть с более другой стороны объяснил Валера Ковальский, подробнее тут

На самом деле, обсуждая в чатике с Валерой (вступайте в чат!), была предложена следующая идея (не нова) - сделать reasoning как отдельный тул, который определяет, что делать дальше и что вызывать.

Он точно у нас должен вызываться принудительно всегда после юзерского сообщения, а достигнуть этого можно через контроль поля tool_choice, которое буквально заставит llm вызвать этот тул!

А потом следующее решение и тд -> можно спокойно дальше делать через LLM!

Так делают, например, ребята из Manus (которые сделали ставку, как почти все бигтехи РФ: разрабатываем агентов как подбор промптов и тулов, лишь бы работало)))

Управление tool_choice - не баг, а фича, это есть и в официальной доке OpenAI, и в Anthropic

И овцы целы, и волки сыты

P.S.
А в функции def reason_before_answer(), можно засунуть всеми любимый SGR!

типа она запускает reasoning_before_answer() с пустыми аргументами после юзерской реплики с помощью tool_choice, а под капотом вызывается LLM с SO, а результат -> подгружается в chat_history. Бинго!

P.P.S.
Введение в проблематику, SGR vs Tools находится тут

Hybrid: SGR + Tools - закрываем дыры, не ломая протокол

После горячих обсуждений и двух предыдущих постов (пост 1, пост 2) я решил показать рабочий гибридный паттерн и сделать вклад в опенсорс-подход к SGR (линк в конце поста).

TLDR пост1 и пост2: SGR пишет ответ через «поля» и якоря [благодаря чему, приводит к более предсказуемым и верным ответам], но в чистом виде легко размывает семантику tool-calling (если мы ее задействуем): в истории появляются вызовы инструментов, которых не было в объявленном наборе и не передались в чат-темплейт, а если неаккуратно обрабатывать вызовы - нас ждёт еще больше проблем. И всё это расходится с практиками провайдеров и публичными бенчмарками по агентости.

Что я сделал:
Я вынес рассуждение в отдельный инструмент generate_reasoning и заставляю модель вызывать его принудительно сразу после любого пользовательского сообщения с помощью управления tool_choice. Внутри reasoning используется SGR: цель, план, ограничения, проверка предпосылок, сигналы о том, нужно ли звать инструменты и какие именно. Далее "агент", опираясь на получившееся рассуждение, вызывает только те функции, которые явно объявлены в tools, строго через нативный механизм вызовов.

Ключевые свойства подхода:
1. Никакого «динамического tools из воздуха». Всё, чем пользуется модель, заранее объявлено; в истории нет инструментов, которых нет в tools. Контроль с помощью tool_choice.
2. История сообщений валидна и читаема: отдельно видно этап рассуждения и отдельно - действия и финальный ответ.
3. Совместимость с практиками провайдеров и бенчами: снижается риск tool-hallucination, корректнее проходит проверка релевантности функций.
4. Контроль внимания вместо хаоса: сначала гарантированное рассуждение, потом действия. Это делает маршрутизацию детерминированной и устойчивой. Тк много трейновых датасетов, как и в каких ситуациях вызывать тулы, мы используем очень много компьюта в свою пользу: не только будущая корректная оценка цепочек ризонинга (для метрик), но и адаптивный выбор тулов.

Почему это устойчивее, чем «SGR-only»:
- Нативные tool_calls, а не эмуляция вызовов через content (да, можно этого избежать, подкладывая вызов SGRв tool_calls, но не решается следующий пункт:
- Меньше неожиданностей для модели: нет сценария «ответил JSON -> внезапно прилетел tool», когда tools пусты.
- Проще поддерживать качество: reasoning становится обычным шагом workflow. Его вообще можно вынести на значительно более мощные модели или наоборот, более слабые. Позволяет нам давать больше контроля.

Получается стабильный и интерпретируемый паттерн: чат-темплейт согласован с историей, вызовы инструментов не идут «против шерсти», а модель ведёт себя предсказуемо.

Рекомендую попробовать гибрид SGR + Tools на своих задачках

линк на код

поддержите реакциями ❤️

Рассматривая промпт Cursor, я вижу, что у каждого тула первым аргументов в любой функции является explanation.

И кажется, Cursor работает неплохо.
Конечно, вызывают вопросы подобные сливы промптов.

Но что есть, то есть.

Кто еще так не делал - пробуем!

Еще забавные факты, которые я для себя выделил, читая данный слив промптов Cursor.

1. Модели ленятся. Если вам знакомо "Хочешь я найду это в поиске?" - они с этим борятся на уровне системного промпта. Я не одинок

2. Модели явно говорят - список тулов меняется, некоторые тулы недоступны. Это означает, что у них достаточно большой скоуп тулов. И подразумеваю, что на каждом запросе пользователя - они подгружают не только текущий контекст (файлы которые открыты, где находится курсор), но и переопределяют релевантные тулы (подразумеваю, какой-нибудь простенький ретрив по аругментам и описаниям функций)

3. Пользователю естественно нельзя сообщать, что ты хочешь "edit_file". Ты должен "редактировать файл.."

4. Диффы для кода - наше всё. Никаких создание новых файлов.

5. Отдельный XML блок про то, что когда нужно использовать тулы, а когда нет. Решается тоже системным промптом и указанием. "Если знаешь ответ - отвечай, если не знаешь - ищи в интернете / коде"

6. Сразу видны костыли. В любом великом DL-пайплайне не должно обойтись без лин.рега. Здесь то же самое. Если семантический поиск по базе не ответил на твои вопросы -> воспользуйся поиском. Когда пишешь новый файл с кодом -> не забудь про импорты. Обязательно читай содержимое перед редактированием. Все эти паттерны передаются через системным промптом. "Само" ничего не происходит.

7. Отдельный xml блок для дебага. Не сказать, что меня удивило, но выглядит прикольно, что модель не "бездумно" вносит правки, а только когда "максимально уверена". Иначе принты для дебага, звучит разумно. Такое зашивается вручную.