Что я сделал не так? Количественная оценка чувствительности и согласованности LLM к инженерии промптов

Исследование изучает, почему LLM ведут себя нестабильно и выдают разные результаты в ответ на незначительные изменения в формулировке промпта. Авторы вводят две метрики: "чувствительность" (насколько сильно меняется ответ при перефразировании промпта) и "консистентность" (насколько одинаково модель обрабатывает разные, но однотипные запросы).

Ключевой результат: Анализируя самые "чувствительные" и "неконсистентные" примеры, можно выявить слабые места и неявные двусмысленности в промпте, а затем устранить их, добавив конкретные уточняющие инструкции.

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

Методика для пользователя выглядит так:

1. Тест на чувствительность (ручная проверка). Возьмите свой промпт и задачу. Слегка перефразируйте инструкцию 3-4 раза, сохраняя общий смысл. Например, измените "Напиши краткое содержание" на "Сделай короткую выжимку", "Суммаризируй текст", "Изложи основную суть". Если результаты сильно отличаются по качеству или формату — ваш промпт "чувствительный" и ненадежный.

2. Поиск "проблемных зон". Посмотрите, на каких именно задачах или типах входных данных модель ошибается чаще всего при перефразировании. Например, вы просите классифицировать отзывы клиентов, и модель постоянно путается в отзывах, где клиент задает вопрос, но на самом деле выражает недовольство (например, "Почему доставка такая долгая?").

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

Этот подход превращает отладку промпта из гадания в системный процесс, повышая предсказуемость и надежность ответов LLM. Вы учите модель, как поступать в спорных ситуациях, которые вы выявили.

• Прямая применимость: Пользователь может немедленно начать применять этот подход. Для этого не нужен код или специальные инструменты. Достаточно взять свой рабочий промпт, придумать 2-3 его синонимичные версии и сравнить результаты на нескольких реальных задачах. Обнаружив расхождения, можно добавить в исходный промпт уточняющие инструкции, как показано в примерах из статьи.

• Концептуальная ценность: Огромна. Исследование дает пользователю новую "ментальную модель". Вместо того чтобы считать LLM "черным ящиком", пользователь начинает понимать, что у промптов есть свойство "хрупкости" или "чувствительности". Хороший промпт — это не тот, который сработал один раз, а тот, который стабильно работает в разных условиях и при небольших изменениях. Это учит проактивно искать и устранять двусмысленности в своих инструкциях.

• Потенциал для адаптации: Хотя исследование сфокусировано на классификации, метод легко адаптируется для любых задач.

  • Для генерации текста: Если вы просите написать пост в блог и разные формулировки ("Напиши пост", "Создай статью", "Подготовь материал") дают разный стиль, добавьте правило: "Стиль текста: деловой, но с юмором, для аудитории IT-специалистов".
  • Для извлечения данных: Если модель по-разному извлекает даты из текста, добавьте правило: "Даты всегда извлекай в формате ДД.ММ.ГГГГ". Механизм адаптации прост: найти нестабильность → выявить её причину (неоднозначность) → устранить неоднозначность явным правилом.

Ты — опытный SMM-менеджер. Твоя задача — проанализировать отзывы клиентов о нашем новом мобильном приложении и классифицировать их по четырем категориям: "Позитив", "Негатив", "Вопрос", "Предложение".

Твои ответы должны быть ТОЛЬКО в формате JSON.

**## Инструкции по классификации:**
1.  **Позитив:** Явное выражение радости, благодарности, похвала функционала.
2.  **Негатив:** Жалобы на ошибки, баги, медленную работу, неудобный интерфейс.
3.  **Вопрос:** Запросы на помощь, уточнение по функциям, вопросы о работе приложения.
4.  **Предложение:** Идеи по улучшению, просьбы добавить новые функции.

**## Правила для сложных случаев (ВАЖНО):**
*   **Правило 1:** Вопросы, которые на самом деле являются жалобой (например, "Почему приложение постоянно вылетает?", "Когда вы уже исправите поиск?"), классифицируй как **"Негатив"**, а не "Вопрос".
*   **Правило 2:** Если отзыв содержит и негатив, и предложение (например, "Ужасный интерфейс, сделайте кнопки больше"), приоритет у категории **"Негатив"**.

**## Отзыв для анализа:**
"Почему нельзя отсортировать товары по цене? Это же базовая функция! Приложение почти бесполезно без этого."

**## Твой результат в формате JSON:**

Этот промпт работает за счет прямого применения методологии из исследования.

1. Выявлена проблемная зона: Мы заранее предположили (или обнаружили на практике), что модель будет путаться между категориями "Вопрос" и "Негатив". Отзыв "Почему нельзя отсортировать товары по цене?" формально является вопросом, но по сути — это жалоба.
2. Добавлено явное правило: Конструкция ## Правила для сложных случаев и конкретно "Правило 1" устраняют эту двусмысленность. Мы не оставляем модели пространства для интерпретации, а даем четкую инструкцию, как поступать в этой пограничной ситуации.
3. Снижение чувствительности: Теперь, как бы пользователь ни сформулировал свой запрос на классификацию ("Классифицируй отзыв", "Определи категорию", "Разбери фидбэк"), наличие этого жесткого правила делает результат гораздо более стабильным и предсказуемым. Промпт становится менее "чувствительным" к формулировкам и более надежным.

Ты — ассистент по планированию путешествий. Твоя задача — составить краткий план поездки в Рим на 3 дня для пары, которая едет туда впервые.

**## Основные требования:**
*   **Стиль:** План должен быть вдохновляющим, но практичным.
*   **Темп:** Умеренный, без спешки. 2-3 ключевых места в день.
*   **Интересы:** История, вкусная еда, красивые виды.

**## Уточнение правил и ограничений (ВАЖНО):**
*   **Правило 1 (Бюджет):** Под "бюджетными ресторанами" я понимаю места со средним чеком **не более 30 евро на человека** за ужин без алкоголя. Не предлагай рестораны из гида Мишлен.
*   **Правило 2 (Транспорт):** Основной способ передвижения — пешком. Предлагай использовать общественный транспорт только если расстояние между точками больше 3 км.

**## Твой результат:**
Представь план в виде таблицы с колонками: "День", "Утро", "День", "Вечер (ужин)".

Этот пример работает, потому что он убирает двусмысленность из субъективных понятий, что является прямым следствием идей "чувствительности" из исследования.

1. Выявлена проблемная зона: Такие термины, как "бюджетный", "недорогой", "умеренный темп" крайне субъективны. Один пользователь под "бюджетным" ужином понимает 20 евро, другой — 100 евро. Если просто написать "найди бюджетные рестораны", LLM будет выдавать нестабильные результаты, чувствительные к малейшим изменениям в других частях промпта или просто к случайности генерации.
2. Добавлено явное правило: Конструкция ## Уточнение правил и ограничений и конкретно "Правило 1" заменяют абстрактное понятие "бюджетный" на конкретный, измеримый критерий: "не более 30 евро на человека". То же самое делает "Правило 2" для понятия "передвижение пешком".
3. Снижение чувствительности и повышение консистентности: Теперь модель не будет "гадать", что мы имели в виду. Она получила четкие ограничения. Это делает промпт более надежным. Если мы попросим составить такой же план для Парижа, модель будет использовать те же критерии, что повышает консистентность ее ответов для однотипных задач.