Ограничения в промпте работают только через проверку кода после
Когда люди пишут «не используй сложные слова» или «объём не более трёх абзацев», они часто рассчитывают на то, что модель их услышит и подчинится. На деле модель обрабатывает эти ограничения как предпочтения, а не как жёсткие правила. Ответ может выйти за рамки, потому что модель скорее следует логике содержания, чем протоколу запроса.
Код помогает там, где слова бессильны. Если нужен ответ не длиннее трёх абзацев, проверку длины должна делать программа, а не поведение модели. Если нужны только определённые поля в ответе, парсер после генерации выявит и отсечёт лишнее.
Стратегия с проверкой
Правильная схема: модель работает с мягкими указаниями в промпте, но выход проходит через валидацию. Если ограничение критично для задачи, оно закодировано в проверке, а не в надежде на дисциплину генератора. Это особенно важно для интеграций, где погрешности складываются.
Пример: вместо «не используй маркированные списки» в промпте нужна функция, которая проверяет результат и переформатирует его, если список появился. Вместо надежды, что модель напишет ровно пять пунктов, в коде считаются пункты и, если их не пять, либо запрос повторяется, либо результат отклоняется.
Грань между указанием и гарантией проста: если ограничение должно соблюдаться всегда, оно — в коде проверки. Если это рекомендация, она в промпте. На практике критичные ограничения никогда не оставляют на волю моделей.