Крупные языковые модели раскрывают ход рассуждений в структурированных выводах, несмотря на явные инструкции.

Проблема: просачивание рассуждений при валидации LLM

Разработчик, создающий инструмент для параллельных API-вызовов к Claude и парсинга структурированного вывода для каждого вызова, столкнулся с периодической проблемой. Каждый вызов возвращает контент внутри специальных маркеров, таких как [COVER], [SLIDE 1], [CAPTION] и т.д. Второй проход LLM проверяет вывод на соответствие правилам и переписывает всё, что не проходит проверку.

Промпт валидации явно указывает: "возвращайте ТОЛЬКО исправленный текст в точном том же формате. Без комментариев. Без рассуждений. Без списков нарушений."

Несмотря на это, модель валидации иногда выводит свои рассуждения перед исправленным контентом. Примеры включают: "Мне нужно проверить этот текст на нарушения... Эти предложения образуют нагромождённую драматическую пару, используемую исключительно для эффекта. Вот переписанный вариант:" с последующим фактическим исправленным текстом.

Последствия для последующих этапов

Этот текст с рассуждениями передаётся напрямую парсеру. Парсер ожидает контент, начинающийся с [COVER], но вместо этого получает метакомментарии. Это вызывает смещение полей на последующих этапах. В одном случае текст рассуждений валидатора оказался внутри поля подписи к изображению, потому что парсер воспринял рассуждения как содержимое тела, сдвинув всё на несколько строк вниз.

Одно лишь ужесточение промптов не решило проблему. Делая инструкции более явными, добавляя "ваш вывод ДОЛЖЕН начинаться с первого маркера контента" и "никогда не включайте рассуждения" — снизило частоту возникновения, но не устранило её полностью. Модель иногда игнорирует инструкции, особенно когда находит нарушения для исправления — она хочет показать свою работу.

Решение: двухуровневая защита

Решение, которое сработало, включало два уровня:

• Уровень 1: Ужесточение промптов. Всё ещё стоит делать, потому что это снижает частоту возникновения проблемы.
• Уровень 2: Защитная функция очистки, которая запускается для каждого вывода валидации до любого парсинга. Для структурированных форматов она привязывается к первому распознанному маркеру и отбрасывает всё, что перед ним. Для простых текстовых форматов она удаляет строки, соответствующие известным шаблонам комментариев валидатора (таким как "Позвольте мне проверить этот текст" или "Это нарушает ограничение").

Порядок "очистка-перед-парсингом" является ключевым. Каждый последующий парсер работает с уже очищенным выводом. Это позволяет избежать поддержки логики очистки для каждого поля или игры в "испорченный телефон" с новыми форматами рассуждений.

Соображения по реализации

Для шаблонов очистки простого текста требуется тщательное проектирование. Регулярное выражение, которое ловит "Это нарушение", может также поймать "Это распространённая ошибка" в легитимном контенте. Шаблоны следует ужесточать, чтобы они соответствовали только специфическому языку валидатора, например "Это нарушает правило/ограничение", а не широким совпадениям на "Это есть" или "Это использует". Каждый шаблон требует проверки на реальном контенте перед развёртыванием.

Если вы парсите структурированный вывод LLM, относитесь к инструкциям промпта как к наилучшему усилию первого прохода и всегда имейте защиту на уровне кода перед парсером. Модель будет соблюдать инструкции в 95% случаев, но 5%, когда она этого не делает, нарушат логику последующих этапов способами, которые трудно воспроизвести, потому что они возникают периодически.