Рефлексируй, затем учись: активное промптирование для извлечения информации, управляемое интроспективной путаницей

Исследование показывает, что качество примеров в промпте (few-shot) важнее их количества. Авторы предлагают метод APIE, который автоматически находит самые "сложные" и "поучительные" примеры для LLM, заставляя модель несколько раз решить задачу и анализируя её "неуверенность". Эта неуверенность делится на два типа: неспособность сгенерировать ответ в правильном формате (например, сломанный JSON) и противоречия в извлекаемом содержании.

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

Представьте, что вы хотите научить LLM извлекать данные из текста в формате JSON. Вместо того чтобы давать случайные примеры, метод APIE предлагает "прощупать" модель. Он берет большой набор текстов и для каждого просит модель несколько раз извлечь из него данные. Затем он анализирует результаты и ищет два типа "замешательства" модели:

1. Неуверенность в Формате (Format Uncertainty): Модель не может выдать синтаксически правильный ответ. Например, в одном случае она генерирует корректный JSON, в другом — JSON с пропущенной скобкой, а в третьем — вообще простой текст. Это сигнал, что модель не поняла, как нужно оформлять результат.

2. Неуверенность в Содержании (Content Uncertainty): Модель выдает ответы в правильном формате, но их содержание каждый раз разное. Например, из фразы "встреча с Анной и её коллегой Иваном" модель в одном случае извлекает ["Анна", "Иван"], а в другом — только ["Анна"]. Это сигнал, что модель не уверена, что именно считать нужной информацией.

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

• Прямая применимость: Низкая. Пользователь не будет писать скрипты для многократных запросов к LLM и вычисления метрик неопределенности. Это инструмент для разработчиков.

• Концептуальная ценность: Очень высокая. Главный вывод для пользователя — при составлении промптов с примерами (few-shot) нужно думать о двух вещах:

  1. Ясность формата: Дали ли вы пример, который четко показывает желаемую структуру вывода, особенно для сложных случаев (например, вложенные списки, опциональные поля)?
  2. Ясность содержания: Дали ли вы пример, который помогает модели разрешить смысловую неоднозначность (например, отличить имя человека от названия компании, если они похожи)? Эта концепция помогает диагностировать, почему промпт не работает, и целенаправленно его улучшать.

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

  1. Один простой, "базовый" пример.
  2. Один пример, демонстрирующий сложную структуру вывода (адресуем "неуверенность в формате").
  3. Один пример, демонстрирующий сложный для интерпретации смысл (адресуем "неуверенность в содержании"). Такой "ручной" подбор примеров будет имитировать логику сложного алгоритма APIE и значительно повысит качество ответов.

Представим, что вы хотите создать ассистента, который анализирует отзывы на товары и извлекает из них плюсы, минусы и упоминаемые характеристики.

Ты — внимательный ассистент-аналитик. Твоя задача — извлекать из текста отзыва на товар его ключевые аспекты: плюсы, минусы и упомянутые характеристики. Ответ должен быть представлен в формате JSON.

Вот несколько примеров, как это делать:

**Пример 1 (простой, базовый):**
*Текст:* "Телефон просто супер! Камера отличная, и батарея держит долго."
*Результат:*

{ "pluses": ["отличная камера", "долго держит батарея"], "minuses": [], "features": ["камера", "батарея"] }

**Пример 2 (адресует "неуверенность в содержании" - семантическая сложность):**
*Текст:* "В целом неплохо, экран яркий. Но звук как из бочки, хотя в наушниках все нормально."
*Результат:*
```json
{
  "pluses": ["яркий экран", "хороший звук в наушниках"],
  "minuses": ["плохой звук из динамиков"],
  "features": ["экран", "звук", "динамики", "наушники"]
}

Пример 3 (адресует "неуверенность в формате" - структурная сложность): Текст: "Купил жене в подарок. Она в восторге от дизайна. Я же не заметил ничего особенного, кроме того, что он греется при зарядке." Результат:

{
  "pluses": ["красивый дизайн (по мнению жены)"],
  "minuses": ["греется при зарядке"],
  "features": ["дизайн", "нагрев", "зарядка"]
}

Теперь проанализируй следующий отзыв и верни результат в таком же JSON формате:

Текст для анализа: "Ноутбук мощный, все игры летают. Но система охлаждения шумит как пылесос, а корпус маркий, все отпечатки видно. Зато клавиатура с подсветкой очень удобная."

# 5.2 Почему это работает:
Этот промпт работает, потому что он не просто дает случайные примеры, а целенаправленно "обучает" модель на сложных случаях, выявленных в исследовании:

1.  **Пример 2** решает **"неуверенность в содержании"**. Фраза "звук как из бочки, хотя в наушниках все нормально" семантически сложна. Модель может растеряться, куда отнести "звук" — к плюсам или минусам. Пример четко показывает, как разделить одну характеристику ("звук") на два разных аспекта (плохой из динамиков, хороший в наушниках), разрешая смысловую неоднозначность.

2.  **Пример 3** решает **"неуверенность в формате"** и **содержании**. Он показывает, как обрабатывать субъективные мнения ("по мнению жены") и как извлекать информацию, когда в одном предложении есть и нейтральная, и негативная оценка. Это учит модель более тонкой обработке и сохранению структуры вывода даже при смешанных сигналах.

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

---
# 6.1 Другой пример практического применения
Задача: извлечь детали встречи из неформального сообщения в мессенджере.

<div class="example-block markdown-block">
<button class="copy-btn" onclick="copyCode(this)">Копировать</button>
<pre><code class="language-markdown">Ты — умный секретарь. Твоя задача — извлекать из текстовых сообщений информацию о предстоящих событиях и представлять ее в виде структурированного JSON объекта. Обязательные поля: `event_name`, `date`, `time`, `location`. Поле `participants` — опциональное.

Вот примеры:

**Пример 1 (простой, базовый):**
*Текст:* "Давай встретимся завтра в 15:00 в кафе 'Центральное' обсудить проект."
*Результат:*</code></pre>
</div>json
{
  "event_name": "обсуждение проекта",
  "date": "завтра",
  "time": "15:00",
  "location": "кафе 'Центральное'",
  "participants": []
}

Пример 2 (адресует "неуверенность в содержании" - семантическая сложность): Текст: "Коллеги, общий сбор по квартальному отчету в пятницу. Начало в десять утра. Буду я, Анна из маркетинга и Петр. Переговорка 'Альфа'." Результат:

{
  "event_name": "сбор по квартальному отчету",
  "date": "пятница",
  "time": "10:00",
  "location": "переговорка 'Альфа'",
  "participants": ["Анна", "Петр"]
}

Пример 3 (адресует "неуверенность в формате" - структурная сложность): Текст: "Насчет дня рождения Олега. Собираемся послезавтра вечером, часов в 7-8, у него дома. Точного адреса пока нет." Результат:

{
  "event_name": "день рождения Олега",
  "date": "послезавтра",
  "time": "19:00-20:00",
  "location": "дом Олега (адрес не указан)",
  "participants": ["Олег"]
}

Теперь проанализируй следующее сообщение и верни результат в таком же JSON формате:

Текст для анализа: "Привет! По поводу запуска нового сайта. Предлагаю созвон в четверг, где-то в обед, часа в 2. Место — наш обычный Zoom. Позови еще дизайнера." ```

Этот промпт эффективен благодаря целенаправленному подбору примеров, которые устраняют потенциальное "замешательство" LLM:

1. Пример 2 решает "неуверенность в содержании". В тексте перечисляются участники, включая говорящего ("Буду я"). Модель могла бы растеряться, нужно ли включать "я" в список. Пример показывает, что нужно извлекать только имена других участников ("Анна", "Петр"), тем самым разрешая семантическую неоднозначность и обучая правилам извлечения сущностей.

2. Пример 3 решает "неуверенность в формате". В тексте указан диапазон времени ("часов в 7-8") и отсутствует точный адрес. Это структурно сложный случай. Модель могла бы выдать ошибку, выбрать только одно значение или оставить поле пустым. Пример показывает, как правильно форматировать диапазон ("19:00-20:00") и как обрабатывать отсутствующую информацию, добавляя пояснение в поле ("дом Олега (адрес не указан)"). Это учит модель гибкости при сохранении заданной структуры.

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

• A. Релевантность техникам промтинга: Высокая. Исследование напрямую посвящено оптимизации few-shot промптинга — выбору наилучших примеров для включения в контекст.
• B. Улучшение качества диалоговых ответов: Высокая. Метод нацелен на повышение точности и стабильности извлечения структурированных данных, что является ключевым для многих чат-сценариев.
• C. Прямая практическая применимость: Низкая. Предложенный метод (APIE) требует программной реализации: многократных вызовов API, вычисления метрик (расстояние Левенштейна, индекс Жаккара), ранжирования и аннотирования данных. Обычный пользователь не сможет применить его "из коробки".
• D. Концептуальная ценность: Очень высокая. Исследование вводит критически важное для пользователя различие между "неуверенностью в формате" (когда модель не знает, как структурировать ответ) и "неуверенностью в содержании" (когда модель не уверена, что именно извлекать). Это дает мощную ментальную модель для диагностики проблем с промптами.
• E. Новая полезная практика: Работа попадает в кластеры 1 (Техники формулирования), 2 (Поведенческие закономерности), 5 (Извлечение и структурирование) и 7 (Надежность и стабильность).
• Чек-лист практичности: Дает +15 баллов, так как раскрывает неочевидные особенности поведения LLM (двойная неуверенность), показывает, как улучшить точность, и помогает в структурировании сложных запросов через подбор правильных примеров.

Оценка 68 отражает сильный разрыв между огромной концептуальной ценностью и низкой прямой применимостью. Метод APIE как алгоритм слишком сложен для рядового пользователя. Однако ключевая идея — разделение "неуверенности" модели на форматную и содержательную — является мощнейшим инсайтом, который можно адаптировать для ручного составления промптов. Пользователь не сможет запустить сам алгоритм, но сможет "думать как алгоритм", подбирая примеры, которые решают оба типа неопределенности.

Контраргументы (почему оценка могла быть ниже): * Практическая реализация метода недоступна без навыков программирования. Пользователь не может просто скопировать и вставить какую-то фразу. Это требует осмысления и адаптации, что снижает прямую пользу.

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