Почему ваш LLM-сервис ведёт себя как хочет, а не как вы просите

[Vindicar]

Format-Forcing через промпт - разве не костыль? Есть же Structured Output, когда подавляются токены, которые не должны появляться в этом месте ожидаемого документа.

Также я встречал утверждение Structured Output можно при желании использовать для описания хода рассуждений (Structured Reasoning). Просим модель заполнить структуру данных, где каждое промежуточное поле - требуемый промежуточный результат, а последние поля описывают итог.

[obulygin]

Да, для тех api, где есть structured output - это костыль. Я в тексте отметил это. Но не у всех просто он есть, особенно когда речь про собственные решения, либо не топовых игроков.

В общем случае это более универсальное (и менее удобное) решение.

[gavexe]

Откуда столько плюсов? Кто в здравом уме в продакшне для кодинга использует бесплатные llm? Это как писать статью о проблемах закупки продуктов для ресторанов, где в качестве примера берутся решения по принципу “что сегодня раздали даром".

[obulygin]

Эм. Код и подходы не специфичны для конкретной модели. Я показываю примеры на бесплатной только для того, чтобы каждый мог легко попробовать и воспроизвести код.

Модель можно взять любую, поменяется одна строка кода. Статья не про конкретную модель, а про подходы, которые актуальны для многих llm.

[gavexe]

Так я ровно об этом и говорю. Если вы берёте бесплатную модель только ради воспроизводимости примеров, то у вас автоматически смещается сама оптика статьи: вы начинаете подробно разбирать проблемы класса “что бывает у бесплатных или слабых моделей”. Но для топовых coding-моделей уровня Opus 4.7 или GPT-5.4 значительная часть этих проблем уже просто не является сколько-нибудь актуальной. Поэтому получается не очень честное обобщение: читателю сначала показывают ограничения дешёвого инструмента, а потом подают их как общие закономерности LLM для кодинга вообще.

[obulygin]

Готов поспорить буквально с каждой фразой в вашем комментарии.

1) Промпт-инъекции, каскадные ошибки в логике и галлюцинации - это не баги "дешевых" моделей. Это фундаментальные ограничения авторегрессионной архитектуры трансформеров. Даже самые актуальные флагманы точно так же подвержены этим проблемам. Да, в меньшей степени, но указанные техники улучшают результат, что доказано исследованиями на разных моделях, в т.ч. на флагманах. Даже в самой статье есть ссылка на официальные рекомендации Antropic (по тем же xml-тегам, например), которые касаются любых их моделей, а не каких-то устаревших. Перейдите по ссылочке в статье, там речь про Opus 4.7. Аналогично по ролям (их эффективность и неэффективность доказана на разных моделях) и другим техникам.

2) Вы пишите: Кто в здравом уме в продакшне использует бесплатные LLM? Внезапно, почти все используют не флагманы. Потому что бизнес умеет считать деньги. И для большинства задач дорогие флагманы не нужны / не стоят того. В продакшене применяются в основном не топовые модели, а минимально достаточные для требуемого результата. Чтобы было дешевле/быстрее/приватно.

Никакого смещения оптики тут нет, если исходить не из позиции "пишу никому не нужные запросы в чатботе на бесплатном тарифе для себя", а из каких-то хотя бы чуть более серьезных задач, где важна надежность, минимизация ошибок, рост качества при имеющихся ограничениях.
Хотя я даже для себя просто в чатботах некоторые из этих техник применяю, т.к. работают :)

[simon_logic]

Если говорить в контексте XML + NC + Format Forcing, я правильно понял, что такие паттерны также не дают 100% результата, а минимизируют вероятность "сбоев"?

[obulygin]

Все верно. И достичь исключительно через промпт 100% надежности пока невозможно.