RescueLens: структура промпта для классификации и редактирования текста

КЛАССИФИКАЦИЯ ТЕКСТА (один промпт):
├── Контекст → кто ты, какую задачу решаешь
├── Роли → кто участники (донор, волонтёр, получатель)
├── Категории → что ищем, с определениями
├── Guidelines → детальные правила классификации
├── Notes → edge cases: когда ДА, когда НЕТ
├── Примеры → 3-8 few-shot с explanation для каждого
└── Вывод → JSON с категорией + объяснением

РЕДАКТИРОВАНИЕ ПО ФИДБЭКУ (один промпт):
├── Задача → что именно редактируем
├── CRITICAL RULES → что нельзя делать (удалять, выдумывать)
├── When to Update → конкретные триггеры для изменений
├── When NOT to Update → что игнорировать
├── Примеры → UPDATE NEEDED + NO UPDATE NEEDED
└── Вывод → JSON с флагом изменения + новый текст + explanation

Задача: Автоматически сортировать отзывы клиентов доставки еды по категориям для службы поддержки.

Промпт:

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

Роли:
- Клиент — заказывает и получает доставку
- Курьер — доставляет заказ
- Магазин — готовит заказ

Категории для классификации:

1. Проблема с товаром: товар повреждён, просрочен, не тот, испорчен при доставке.
   Пример: "Молоко протекло, пакет был порван"

2. Проблема с курьером: грубость, опоздание, не дозвонился, оставил не там.
   Пример: "Курьер положил заказ под дождь и ушёл"

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

4. Проблема с ценой/списанием: неправильная сумма, двойное списание, не применилась скидка.
   Пример: "Списали 1500, хотя заказ был на 1200"

Notes:
- Отмечай "Проблема с товаром" только если товар реально повреждён или не тот. Недовольство ассортиментом — НЕ проблема с товаром.
- Опоздание курьера — это "Проблема с курьером", даже если клиент не упоминает курьера напрямую.
- Если проблема вызвана внешними факторами (погода, пробки) без вины курьера — НЕ отмечай как проблему с курьером.
- Общие жалобы без конкретики ("Ужасный сервис!") — классифицируй как "Требует уточнения".

Примеры:

Отзыв: "Заказал 6 яиц, привезли 4, и одно разбитое"
{
  "категория": "Проблема с товаром",
  "explanation": "Неполная комплектация + повреждённый товар"
}

Отзыв: "Курьер приехал через 2 часа вместо обещанных 30 минут"
{
  "категория": "Проблема с курьером", 
  "explanation": "Значительное опоздание доставки"
}

Отзыв: "В этот раз хотелось бы побольше выбора безлактозных продуктов"
{
  "категория": "Нет проблемы",
  "explanation": "Пожелание по ассортименту, не жалоба на конкретный инцидент"
}

Теперь классифицируй этот отзыв:
"Привезли быстро, но половина продуктов была тёплой, хотя заказывал охлаждённые"

Результат: Модель выдаст JSON с категорией «Проблема с товаром» и объяснением, почему именно эта категория (нарушение температурного режима = проблема с качеством товара, а не с курьером). Структура Notes помогает разграничить edge cases.

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

Секция Notes решает эту проблему через явные правила разграничения. Вместо того чтобы модель сама решала edge cases, мы закладываем решения в промпт. Это как FAQ для классификатора: «Если видишь X, делай Y, даже если кажется что Z».

Few-shot примеры с explanation — второй ключевой элемент. Просто показать «вход → категория» недостаточно. Когда модель видит объяснение «почему именно эта категория», она понимает логику и применяет её к новым кейсам. Особенно важны негативные примеры — что НЕ является проблемой.

Ты — {роль}. Твоя задача — классифицировать {что классифицируем}.

Роли:
- {Участник 1} — {что делает}
- {Участник 2} — {что делает}

Категории:

1. {Категория 1}: {определение}
   Пример: "{типичный пример}"

2. {Категория 2}: {определение}
   Пример: "{типичный пример}"

{...добавить нужное количество категорий}

Notes:
- {Edge case 1}: {как классифицировать}
- {Edge case 2}: {как классифицировать}
- {Что НЕ является проблемой}: {объяснение}

Примеры:

{Текст примера 1}
{
  "категория": "{категория}",
  "explanation": "{почему именно эта категория}"
}

{Текст примера 2 — НЕГАТИВНЫЙ}
{
  "категория": "Нет проблемы",
  "explanation": "{почему это НЕ проблема}"
}

{3-8 примеров, покрывающих разные категории и edge cases}

Теперь классифицируй:
{текст для классификации}

Ты — {роль}. Твоя ЕДИНСТВЕННАЯ задача — определить, содержит ли фидбэк конкретные исправления для {что редактируем}.

**КРИТИЧЕСКОЕ ПРАВИЛО: Обновляй {что} ТОЛЬКО если фидбэк явно указывает на ошибку в текущей версии.**
**КРИТИЧЕСКОЕ ПРАВИЛО: НЕ удаляй ничего из оригинала — только добавляй.**

## Когда обновлять (ТОЛЬКО эти случаи):
- {Триггер 1} → {какое изменение}
- {Триггер 2} → {какое изменение}

## Когда НЕ обновлять:
- {Ситуация 1} → {почему игнорируем}
- {Ситуация 2} → {почему игнорируем}

## Формат вывода:
```json
{
  "требуется_изменение": boolean,
  "новый_текст": "строка (пусто если нет изменений)",
  "explanation": "краткое объяснение решения"
}
```

## Примеры:

### Пример 1: ТРЕБУЕТСЯ ОБНОВЛЕНИЕ
Оригинал: "{текущий текст}"
Фидбэк: "{комментарий с конкретным исправлением}"
```json
{
  "требуется_изменение": true,
  "новый_текст": "{обновлённый текст}",
  "explanation": "{почему обновили}"
}
```

### Пример 2: НЕ ТРЕБУЕТСЯ ОБНОВЛЕНИЕ  
Оригинал: "{текущий текст}"
Фидбэк: "{общая жалоба без конкретики}"
```json
{
  "требуется_изменение": false,
  "новый_текст": "",
  "explanation": "{почему НЕ обновляем}"
}
```

Теперь проанализируй:
Оригинал: {текущий текст}
Фидбэк: {комментарий пользователя}

Плейсхолдеры:

• {роль} — кто ты (аналитик, редактор, модератор)
• {что классифицируем/редактируем} — тип контента
• {категории} — 3-10 категорий с чёткими границами
• {Notes} — 3-5 edge cases с решениями
• {примеры} — 3-8 штук, включая негативные

🚀 Быстрый старт — вставь в чат:

Вот шаблон для классификации текста. Адаптируй под мою задачу: [опиши что классифицируешь и какие категории нужны].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит: какие категории нужны? какие edge cases возникают? — потому что без этих данных промпт не даст точной классификации. Она возьмёт структуру (роли → категории → Notes → примеры → JSON) и адаптирует под твой контекст.

⚠️ Требует калибровки: Без реальных примеров из твоих данных модель будет ошибаться на edge cases. Исследователи добавляли 3-8 few-shot примеров с объяснениями — это минимум для нормальной точности.

⚠️ Precision vs Recall trade-off: В исследовании осознанно оптимизировали под recall (96%) в ущерб precision (71%). Это значит: модель найдёт почти все проблемы, но ~30% будут ложными срабатываниями. Для фильтрации потока — ОК. Для автоматических действий без проверки — рискованно.

⚠️ Не работает для субъективных категорий: «Хороший отзыв» vs «Плохой отзыв» — слишком размыто. Метод работает, когда категории имеют объективные признаки (упомянут контакт → Update Contact).

Команда из Carnegie Mellon работала с реальной организацией 412 Food Rescue в Питтсбурге, которая спасла более 30 миллионов фунтов еды с 2015 года. У них было 14,439 текстовых отзывов от волонтёров за 6 лет.

Сначала провели open coding — взяли 250 случайных отзывов и итеративно выделили 7 категорий проблем. Критерий остановки: когда перестали появляться новые типы. Затем разметили 125 отзывов двумя аннотаторами (Cohen's κ = 0.73 — хорошее согласие).

Интересно сравнение моделей: GPT-4o mini показал F1 = 89.8% при стоимости $15/год, а GPT-4o — F1 = 91.4% при $250/год. Разница в 1.6% не стоит 17-кратного увеличения бюджета. При этом DeepSeek R1 неожиданно провалился (F1 = 64.9%) — reasoning-модели не всегда лучше для классификации.

Ещё одна находка: 0.5% доноров отвечают за 30%+ проблем. Это закон Парето в действии — и это практический инсайт для любого, кто анализирует обратную связь: ищи «токсичных» источников проблем, не размазывай усилия.

Контекст: Промпт для классификации категории «Inadequate Food» (недостаточно еды от донора).

Description: As an analyst for our food rescue platform, your primary task is to carefully review feedback provided by volunteer drivers, with a specific focus on identifying issues caused by inadequate food provided by the donors.

Roles Explained:
The Donor - Provides the food.
The Volunteer Driver - Transports the food.
The Recipient - Receives the food.

Guidelines for Analysis:
1. Inadequate Food: Assess whether the reported challenges or failures in the food rescue process were caused by inadequate food quantities provided by the donor. If the inadequate food is caused by issues with the donor (e.g. the donor forgot to respond), then do not mark it as inadequate food.

Notes:
1. Consider comments as inadequate food issues when they indicate "no donation", "no pick-up", "meager food", or "limited access", "few", "nothing"...
2. Only consider comments as an inadequate food issue when recipient received no food, insufficient food, or had issues with the food itself. This DOES NOT include situations where a previous rescue trip picks up the food beforehand.
3. Responses should be formatted in JSON to maintain uniformity and clarity across reports.

Example Comment Analysis:

1. For this rescue, the donor is Aldi Market; the recipient is North Long Beach Ministry Center. Comment: No donation today.

"inadequate_food": true,
"explanation": "The comment mentioned that there was no donation, which is a case of inadequate food."

2. For this rescue, the donor is Kroger; the recipient is Bethel Baptist Church. Comment: Nothing to donate. Everything they had put aside was burned.

"inadequate_food": true
"explanation": "The comment mentioned that there was nothing to donate, a case of inadequate food."

3. For this rescue, the donor is 42-La Canada; the recipient is North Long Beach Ministry Center. Comment: I was told someone picked up earlier.

"inadequate_food": false
"explanation": "The comment mentioned that someone came earlier, which explicitly SHOULD NOT be marked as inadequate food."

Обрати внимание на Note 2 — явное правило: «если кто-то забрал раньше — это НЕ inadequate food». Это именно тот edge case, который модель путала бы без инструкции.

Ты — HR-аналитик. Задача — классифицировать резюме кандидатов на позицию {позиция}.

Категории:

1. Подходит: опыт {X лет}+ в {области}, есть {ключевые навыки}
2. Рассмотреть: частичное соответствие, но есть потенциал
3. Не подходит: критическое несоответствие требованиям

Notes:
- Релокация из другого города — НЕ причина для "Не подходит" (если не указано иное)
- Перерыв в карьере до 1 года — НЕ критическое несоответствие
- Завышенные зарплатные ожидания — классифицируй как "Рассмотреть", не "Не подходит"

{few-shot примеры с explanation}

Ты — модератор комментариев. Задача — классифицировать комментарий.

Категории:
1. Нарушение — спам, оскорбления, реклама
2. Пограничный — провокация, сарказм, неоднозначность
3. Норма — допустимый комментарий

## Когда НЕ модерировать:
- Критика продукта/сервиса (даже резкая) — это НЕ нарушение
- Ирония и сарказм без прямых оскорблений — НЕ нарушение
- Упоминание конкурентов — НЕ автоматически спам

К JSON-выводу добавь поле confidence:

{
  "категория": "Проблема с курьером",
  "confidence": "высокая/средняя/низкая",
  "explanation": "..."
}

Это позволяет фильтровать: автоматически обрабатывать высокая, отправлять на ручную проверку средняя и низкая.

Работа: RescueLens: LLM-Powered Triage and Action on Volunteer Feedback for Food Rescue

Авторы: Naveen Raman, Jingwu Tang, Zhiyu Chen, Zheyuan Ryan Shi, Sean Hudson, Ameesh Kapoor, Fei Fang

Организации: Carnegie Mellon University, University of Texas at Dallas, University of Pittsburgh, 412 Food Rescue

Контекст: Система развёрнута в 412 Food Rescue с мая 2025, обработала 1,200+ отзывов