Все ли они хороши? Оценка качества CoT в генерации кода на основе LLM

Исследование анализирует, почему у языковых моделей не получается генерировать корректный код, даже когда они используют технику пошагового рассуждения (Chain-of-Thought). Авторы выяснили, что более половины ошибок (53%) происходят из-за "внешних факторов" — нечетких или неполных инструкций в самом промпте пользователя. Остальные ошибки — "внутренние", связанные с собственной логикой модели, например, с непониманием неявных требований задачи.

Ключевой результат: Качество промпта (полнота контекста и ясность требований) является главной причиной неудач LLM, а сами рассуждения модели не всегда соответствуют итоговому результату, что требует от пользователя проверки и того, и другого.

Суть исследования не в предложении нового метода, а в создании системы диагностики ошибок в ответах LLM, которую любой пользователь может адаптировать для своих нужд. Авторы разделили все причины неудач на две большие группы:

1. Внешние факторы (Проблема в вашем промпте):

   • Нечеткие детали (Unclear Implementation Details): Вы просите "краткое резюме", но не уточняете, должно ли оно быть в виде списка, абзаца или таблицы. Вы просите "агрессивный тон", но не даете примера.
   • Отсутствие контекста (Missing Contextual Information): Вы просите написать письмо, но не указываете, кто вы, кто получатель, какова предыстория и цель письма. Модель вынуждена додумывать, и часто ошибается.

2. Внутренние факторы (Проблема в "мозгах" LLM):

   • Непонимание явных требований (Misunderstanding Explicit Requirements): Вы пишете "не использовать клише", а модель их использует. Она видит инструкцию, но игнорирует ее.
   • Непонимание неявных требований (Incomprehension of Implicit Requirements): Это "провал здравого смысла". Вы просите составить план поездки в Париж, а модель не учитывает, что в понедельник Лувр закрыт, или что перемещение между двумя точками занимает время.
   • Неправильное планирование (Incorrect Planning): Логика рассуждений модели нарушена. Например, она решает сначала купить билеты, а потом проверить, открыт ли музей в этот день.

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

• Прямая применимость: Низкая. Методы и примеры из статьи напрямую неприменимы для не-программистов.
• Концептуальная ценность: Очень высокая. Исследование дает пользователю "карту" возможных ошибок. Когда LLM выдает плохой ответ, пользователь может не просто пробовать переформулировать запрос наугад, а целенаправленно искать причину: "Ага, это похоже на 'непонимание неявных требований', мне нужно было явно указать, что..." Это превращает метод проб и ошибок в системный процесс отладки промпта.
• Потенциал для адаптации: Высокий. Механизм адаптации — это аналогия. Пользователь должен научиться переводить специфические проблемы из мира кода в свою предметную область.
  • "Отсутствие зависимостей" → "Отсутствие информации о предыдущих шагах проекта".
  • "Обработка граничных случаев" → "Учет крайних сценариев в бизнес-плане (например, нулевые продажи)".
  • "Неверный порядок вызовов функций" → "Нелогичная последовательность шагов в инструкции".

Представим, что пользователь хочет получить от LLM маркетинговую стратегию для нового мобильного приложения.

# Запрос на разработку маркетинговой стратегии

## 1. Роль
Выступи в роли опытного маркетолога с 10-летним стажем в продвижении мобильных приложений в сегменте "Здоровье и Фитнес".

## 2. Контекст (предотвращаем "Missing Contextual Information")
*   **Продукт:** Мобильное приложение "ZenMind", которое предлагает 5-минутные медитации для снятия стресса у офисных работников.
*   **Целевая аудитория:** Мужчины и женщины 25-45 лет, работающие в крупных городах, проводящие >8 часов в офисе, активные пользователи соцсетей.
*   **Бюджет:** Очень ограниченный, до $5000 на первые 3 месяца.
*   **Конкуренты:** Headspace, Calm (но мы отличаемся фокусом на коротких сессиях).
*   **Цель:** Достичь 10 000 установок за первые 3 месяца.

## 3. Задача и Явные Требования (предотвращаем "Unclear Details" и "Misunderstanding")
Разработай пошаговую маркетинговую стратегию на 3 месяца.

**Структура ответа:**
1.  **Ключевые каналы продвижения (выбери 3 самых эффективных с учетом бюджета).**
2.  **Контент-план (какие темы и форматы использовать).**
3.  **Пошаговый план действий (что делать в 1-й, 2-й и 3-й месяц).**

## 4. Неявные Требования, сделанные Явными (предотвращаем "Incomprehension of Implicit Requirements")
*   **ВАЖНО:** Все предложенные активности должны быть реалистичны в рамках указанного бюджета. Не предлагай дорогую видео-рекламу или сотрудничество с топ-блогерами.
*   Учитывай, что у нас нет штатного дизайнера, поэтому предлагай решения, которые не требуют сложных визуальных материалов.
*   План должен быть сфокусирован исключительно на онлайн-продвижении.

## 5. Проверка рассуждений (адресуем проблему несоответствия CoT и результата)
Прежде чем дать финальный ответ, продумай шаги и убедись, что твоя стратегия напрямую ведет к цели (10 000 установок) и строго соответствует бюджетным ограничениям.

Этот промпт работает, потому что он системно предотвращает ошибки, классифицированные в исследовании: * Раздел "Контекст" напрямую борется с "Missing Contextual Information" (MCI), давая модели всю необходимую фоновую информацию. * Разделы "Задача" и "Структура ответа" устраняют "Unclear Implementation Details" (UID), четко определяя, что, как и в каком формате нужно сделать. * Раздел "Неявные Требования" — это прямое применение главного вывода исследования. Мы не надеемся на "здравый смысл" модели, а прописываем очевидные для человека, но не для машины, ограничения (бюджет, ресурсы). Это борется с "Incomprehension of Implicit Requirements" (IIR). * Пункт 5 заставляет модель провести самопроверку, снижая риск "Incorrect Planning" (ICP) и расхождения между рассуждениями и финальным ответом.

Задача: составить план путешествия.

# Запрос на составление плана путешествия по Италии

## 1. Роль
Ты — опытный гид и планировщик путешествий, специализирующийся на бюджетных поездках по Италии для семей с детьми.

## 2. Контекст (предотвращаем MCI)
*   **Путешественники:** Семья из 3 человек: 2 взрослых (35 лет, любят историю и еду) и 1 ребенок (7 лет, быстро устает, любит парки и мороженое).
*   **Даты:** 1-10 июня.
*   **Бюджет:** Средний, около 150 евро в день на семью (без учета жилья).
*   **Маршрут:** Прилетаем в Рим, улетаем из Рима. Хотим посетить Рим и Флоренцию.
*   **Интересы:** История, искусство, вкусная еда, парки, неспешные прогулки.

## 3. Задача и Явные Требования (предотвращаем UID)
Составь подробный по дням план путешествия с 1 по 10 июня.

**Структура для каждого дня:**
*   **Утро (9:00 - 13:00):** Основная активность.
*   **Обед (13:00 - 14:00):** Рекомендация типа заведения (например, "пиццерия", "траттория").
*   **День (14:00 - 18:00):** Вторая, менее утомительная активность.
*   **Вечер:** Свободное время.

## 4. Неявные Требования, сделанные Явными (предотвращаем IIR)
*   **ВАЖНО:** План должен быть сбалансированным и не перегруженным. Не более ОДНОГО крупного музея или исторического объекта в день.
*   **Учитывай логистику:** Включи в план примерное время на дорогу между локациями пешком или на общественном транспорте.
*   **Проверяй часы работы:** Убедись, что все предложенные музеи и парки открыты в указанные дни (обрати внимание на выходные и понедельники).
*   Обязательно включай в план ежедневную "паузу на мороженое" для ребенка.

Этот промпт эффективен, так как он применяет ту же логику "предотвращения ошибок", что и первый пример: * Контекст (профиль семьи, бюджет, даты) не дает модели генерировать универсальный, но бесполезный план. Это борется с MCI. * Четкая структура по часам и задачам на день устраняет двусмысленность и не дает модели "налить воды". Это борется с UID. * Самый важный раздел — "Неявные Требования". Он заставляет модель учесть "здравый смысл": дети устают (один музей в день), перемещение требует времени (учитывай логистику), у мест есть график работы (проверяй часы), у ребенка есть свои желания (пауза на мороженое). Это прямая атака на IIR, самую частую причину провала сложных планов, генерируемых LLM.

• A. Релевантность техникам промтинга: Средняя. Исследование анализирует Chain-of-Thought (CoT), но в узкоспециализированном контексте генерации кода. Прямых новых техник для общего пользования не предлагает, но глубоко анализирует причины сбоев существующих.
• B. Улучшение качества диалоговых ответов: Низкое. Фокус на корректности кода, а не на качестве диалога, креативности или связности текста в общих задачах.
• C. Прямая практическая применимость: Низкая. Выводы и примеры полностью посвящены программированию. Пользователь не может напрямую применить знание о "пропущенных зависимостях в Python" для написания эссе или маркетингового плана. Требуется серьезная адаптация и переосмысление.
• D. Концептуальная ценность: Высокая. Исследование дает чрезвычайно ценную ментальную модель для понимания сбоев LLM. Классификация ошибок на "внешние" (проблема в промпте) и "внутренние" (проблема в логике модели) универсальна. Вывод о том, что рассуждения (CoT) и итоговый ответ могут быть не связаны, — ключевой инсайт для любого продвинутого пользователя.
• E. Новая полезная практика (кластеры): Работа попадает в кластеры #2 (Поведенческие закономерности LLM), #6 (Контекст и память) и #7 (Надежность и стабильность).
• Чек-лист практичности (+15 баллов): Да, исследование раскрывает неочевидные особенности поведения LLM (рассуждения могут быть неверны, даже если ответ правильный, и наоборот) и предлагает способы улучшить точность ответов (через предоставление исчерпывающего контекста и четких требований).

Аргументы за оценку 65: Оценка отражает баланс между низкой прямой применимостью и высокой концептуальной ценностью. Исследование не дает готовых "копипаст" решений для обычного пользователя, но вооружает его мощной системой для анализа ошибок и улучшения своих промптов. Оно учит пользователя думать как "дебаггер" своих запросов, разделяя проблемы на те, что в "коде" (промпте) и те, что в "компиляторе" (модели). Это знание требует осмысления, но способно качественно изменить подход к промптингу.

Контраргументы: * Почему оценка могла быть выше (70-75)? Потому что концептуальные выводы — универсальны. Понимание того, что 53% ошибок вызваны "внешними факторами" (т.е. качеством промпта), — это прямое руководство к действию для любого пользователя: "Сначала исправь свой промпт, он, скорее всего, плохой". Это фундаментальный принцип, который сам по себе стоит многого. * Почему оценка могла быть ниже (40-50)? Потому что вся терминология и примеры (CoderEval, Django, os.sep) создают высокий порог входа. Обычный пользователь, увидев это, скорее всего, закроет статью, решив, что она не для него. Требуется значительное умственное усилие, чтобы "перевести" выводы с языка программирования на язык повседневных задач.