RAEC: двухэтапная проверка с референсными примерами из прошлого

ЭТАП 0 (подготовка): 
Создай структурированный чек-лист типичных ошибок для твоей задачи
→ 5 доменов, 20-60 конкретных типов ошибок

ЭТАП 1 (первый промпт):
Входные данные: новый текст + 3-5 референсных примеров из прошлого + чек-лист ошибок
→ Binary check: "Есть ли проблемы? Да/Нет + краткое объяснение"

ЭТАП 2 (второй промпт, если проблемы найдены):
→ Классификация: конкретные коды ошибок из чек-листа + обоснование

Этапы 1-2 можно объединить в один промпт для простоты, если задача не слишком сложная.

Задача: Ты руководитель отдела продаж в B2B. Проверяешь коммерческое предложение менеджера перед отправкой крупному клиенту. Нужно убедиться что КП соответствует стандартам компании и не содержит типичных ошибок.

Промпт:

Ты опытный B2B-эксперт. Проверь коммерческое предложение на типичные ошибки.

=== РЕФЕРЕНСНЫЕ ПРИМЕРЫ (успешные КП из прошлого) ===

[ПРИМЕР 1: КП для Х5 Retail Group]
Тема: Автоматизация складского учёта...
[текст КП, которое привело к сделке]

[ПРИМЕР 2: КП для Яндекс] 
Тема: Интеграция CRM-системы...
[текст КП, которое привело к сделке]

[ПРИМЕР 3: КП для СБЕР]
Тема: Внедрение аналитической платформы...
[текст КП, которое привело к сделке]

=== ЧЕК-ЛИСТ ТИПИЧНЫХ ОШИБОК ===

**Клинические ошибки (адаптировано для B2B):**
- Неполный ответ на запрос клиента
- Упущенные критические детали из брифа
- Некорректная трактовка потребности

**Коммуникация и читаемость:**
- Канцелярит и штампы
- Неясные/противоречивые инструкции
- Слишком короткое КП без деталей
- Отсутствие эмпатии к боли клиента

**Workflow и процессы:**
- Нарушение внутренних стандартов оформления
- Отсутствие важных разделов (сроки, гарантии)
- Неправильное имя клиента в обращении

=== НОВОЕ КП НА ПРОВЕРКУ ===

Тема: Разработка мобильного приложения для ВкусВилл
[текст нового КП от менеджера]

=== ЗАДАЧА ===

**ШАГ 1:** Есть ли в новом КП отклонения от стандартов, видимых в референсных примерах? 
Да/Нет + краткое объяснение (2-3 предложения)

**ШАГ 2 (если Да):** Классифицируй ошибки по чек-листу: 
- Код ошибки 
- Обоснование (зачем это важно исправить)
- Уровень критичности (высокий/средний/низкий)

Результат:

Модель покажет двухэтапную проверку. Сначала binary judgment: "Да, есть отклонения — КП не содержит конкретных сроков реализации, в отличие от всех трёх референсов". Потом детальная классификация: перечислит конкретные коды ошибок (например, "отсутствие критических деталей" + "упущенный раздел 'Гарантии'"), для каждой даст обоснование и критичность. Финальный вывод — список конкретных правок перед отправкой клиенту.

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

Референсные примеры дают модели точку отсчёта: "вот как пишут в ЭТОЙ компании", "вот что работает у ЭТИХ клиентов". Модель видит паттерны — структура КП, типичные формулировки, обязательные разделы, tone of voice — и сравнивает новый текст с ними. Вместо "улучшите структуру" → "в КП отсутствует раздел 'Сроки реализации', который присутствует во всех трёх успешных примерах".

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

Структурированная таксономия ошибок убирает субъективность. Вместо "текст какой-то странный" → конкретные метки: "канцелярит", "упущена критическая деталь из брифа", "некорректное имя клиента". Модель не придумывает новые типы ошибок каждый раз — работает по единому стандарту, что делает проверку предсказуемой и воспроизводимой.

• Количество референсов (3-5 примеров): больше → шире покрытие паттернов, но дороже токены
• Детализация чек-листа (20-60 кодов): подробнее → точнее классификация, но сложнее создавать
• Один или два промпта: объединённый → проще workflow, раздельный → лучше для сложных случаев
• Критичность ошибок (высокая/средняя/низкая): добавь в чек-лист чтобы фильтровать шум

Промпт 1 — Binary Check:

Ты эксперт в {область}. Проверь {тип текста} на отклонения от стандартов.

=== РЕФЕРЕНСНЫЕ ПРИМЕРЫ ===
{3-5 успешных примеров из прошлого — полный текст}

=== НОВЫЙ ТЕКСТ НА ПРОВЕРКУ ===
{текст для оценки}

**Вопрос:** Есть ли в новом тексте отклонения от стандартов, видимых в референсах?

Ответ: Да/Нет + объяснение (2-3 предложения)

Промпт 2 — Классификация ошибок (если на этапе 1 ответ "Да"):

Классифицируй найденные проблемы по чек-листу:

=== ЧЕК-ЛИСТ ТИПИЧНЫХ ОШИБОК ===
{структурированный список: домены → поддомены → конкретные коды}

Для каждой найденной ошибки укажи:
- Код ошибки из чек-листа
- Обоснование (почему это важно исправить)
- Критичность (высокая/средняя/низкая)

Ты эксперт в {область}. Проверь {тип текста} по двухэтапной схеме.

=== РЕФЕРЕНСНЫЕ ПРИМЕРЫ ===
{3-5 успешных примеров из прошлого}

=== ЧЕК-ЛИСТ ТИПИЧНЫХ ОШИБОК ===
{домены → поддомены → коды}

=== НОВЫЙ ТЕКСТ ===
{текст для проверки}

**ШАГ 1:** Есть ли отклонения от стандартов? (Да/Нет + краткое объяснение)

**ШАГ 2:** Если Да → классифицируй ошибки:
- Код ошибки
- Обоснование
- Критичность

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

• {область} — твоя сфера (B2B-продажи, контент-маркетинг, техподдержка)
• {тип текста} — что проверяешь (коммерческое предложение, статья, email-рассылка)
• {3-5 примеров} — успешные кейсы из твоего архива (полный текст или ключевые фрагменты)
• {чек-лист} — структурированная таксономия ошибок для твоей задачи

Как создать чек-лист ошибок: Попроси модель проанализировать 10-20 типичных ошибок в твоей области, затем вручную отредактируй и структурируй их в 3-5 доменов с конкретными кодами.

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

Вот метод двухэтапной проверки с референсами. Адаптируй под мою задачу: {опиши что проверяешь и зачем}. 
Задавай вопросы чтобы создать:
1. Чек-лист типичных ошибок для моей области
2. Рабочий промпт с плейсхолдерами

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

Модель спросит про специфику твоей области, примеры типичных ошибок, формат референсов. Она возьмёт структуру из шаблона (двухэтапность, референсы, чек-лист) и адаптирует под твою задачу.

⚠️ Нужна база примеров: Метод работает только если у тебя есть 5-10+ успешных кейсов из прошлого. Если база маленькая или примеры низкого качества — модель научится плохим паттернам.

⚠️ Специфика важнее универсальности: Референсы должны быть похожими на проверяемый текст (тот же тип клиента, задачи, формат). Если подсунуть КП для ритейла при проверке КП для банка — контекст не поможет.

⚠️ Субъективные критерии хуже: В исследовании модель лучше ловила объективные ошибки (упущенные разделы, некорректные данные), но хуже — субъективные (tone of voice, эмпатия). Для креатива и стиля метод менее точен.

⚠️ Токены: 3-5 референсов + новый текст + чек-лист = много токенов. Для коротких задач (email на 200 слов) это ОК, для длинных документов (отчёт на 20 страниц) может быть дорого.

Команда из Stanford Medicine взяла 220,739 сообщений пациент-врач из портала электронных медкарт (3 месяца, 11 специальностей) и построила систему проверки AI-генерированных черновиков ответов. Процесс в три этапа:

Этап 1 — Создание таксономии ошибок. Врачи начали с seed-списка типичных косяков в ответах (6 доменов, 37 кодов). Потом o3-mini модель проанализировала 1000 случайных диалогов в режиме индуктивного кодирования: для каждого помечала ошибки по текущей таксономии и предлагала новые коды если существующих не хватало. Врачи вручную проверяли предложенные коды, убирали дубли, объединяли близкие. Финал: 5 доменов, 24 поддомена, 59 конкретных типов ошибок — от "некорректное имя пациента" до "упущены инструкции на случай ухудшения".

Этап 2 — Сравнение Baseline vs Enhanced. Взяли 1570 новых диалогов и прогнали через две версии системы:

• Baseline — просто промпт "проверь черновик на ошибки" + таксономия
• Enhanced (RAEC) — то же самое + 5 похожих диалогов из архива (ищут через embeddings по семантической близости)

Результат удивил: Enhanced показал +50% concordance с оценками врачей (50% vs 33%) и в 2 раза лучше F1-score на уровне конкретных кодов ошибок (0.500 vs 0.256). Самый большой скачок — точность выявления workflow violations (когда AI упускает внутренние процедуры клиники) и clinical completeness (неполные ответы на запрос пациента).

Этап 3 — Валидация врачами. Чтобы проверить что Enhanced реально лучше, а не просто по-другому, врач вручную разметил 100 случайных диалогов. Критическая находка: Enhanced не просто больше ошибок нашёл — он меньше false positives дал. Baseline часто флагал сообщения как "ambiguous or conflicting instructions" (28% случаев), когда для врача они были нормальными. Enhanced снизил это до 22.7% — референсы научили модель не придираться к мелочам, характерным для этой клиники.

Почему сработало: Исследователи показали что локальный контекст важнее универсальных правил. LLM без референсов оценивает по общим медицинским стандартам из обучения, но каждая клиника имеет свои workflow, стиль общения, приоритеты. Например, в одной клинике норма давать короткий ответ "приезжайте на приём" без деталей, в другой — обязательно расписывать план. Референсы из архива калибруют модель под локальную практику.

Неожиданность: Enhanced лучше находил errors of omission (что AI упустил), но хуже — communication style issues (как AI написал). Врачи чаще флагали клинические недочёты, LLM — стилистические. Это говорит что модель пока лучше сравнивает structure/completeness, чем субъективный tone/empathy.

Retrieval-Augmented Guardrails for AI-Drafted Patient-Portal Messages: Error Taxonomy Construction and Large-Scale Evaluation

Wenyuan Chen, Fateme Nateghi Haredasht, Kameron C Black, François Grolleau, Emily Alsentzer, Jonathan H Chen, Stephen P Ma

Stanford University, Stanford Center for Biomedical Informatics Research

https://doi.org/10.48550/arXiv (публикация 2025)

DSPy — фреймворк для создания модульных LLM-пайплайнов

https://github.com/stanfordnlp/dspy

SentenceTransformers — библиотека для создания embeddings

https://www.sbert.net

💡 Адаптация для проверки контента перед публикацией:

Редактор медиа проверяет статью перед выходом. Вместо абстрактного "хороший ли текст?" — даёт модели 3-5 прошлых статей с высоким engagement + новый черновик. Модель сравнивает: есть ли hook в первом абзаце (как в референсах), достаточно ли конкретики (цифры, кейсы), соответствует ли tone корпоративному стилю.

=== РЕФЕРЕНСЫ (прошлые статьи с >10K просмотров) ===
[Статья 1: про AI в образовании]
[Статья 2: про удалённую работу] 
[Статья 3: про no-code инструменты]

=== НОВАЯ СТАТЬЯ ===
[черновик про промптинг]

**ШАГ 1:** Отклонения от паттернов успешных статей? (Да/Нет + объяснение)
**ШАГ 2:** Конкретные проблемы:
- Слабый hook в первом абзаце (vs яркие примеры в референсах)
- Мало конкретики (нет цифр/кейсов, которые есть во всех 3 примерах)
- Канцелярит в стиле (референсы все пишут разговорно)

🔧 Техника: добавление уровня критичности → фильтрация шума

В оригинале все ошибки равны. Добавь градацию важности чтобы фокусироваться на критичном:

Для каждой ошибки укажи:
- Код ошибки
- Критичность: 
 * ВЫСОКАЯ (блокирует отправку клиенту — факт. ошибки, некорректные данные)
 * СРЕДНЯЯ (желательно исправить — tone, completeness)
 * НИЗКАЯ (косметика — мелкие стилистические недочёты)
- Обоснование

Сфокусируйся на ошибках ВЫСОКОЙ критичности.

🔧 Техника: пошаговый разбор референсов → явное обучение паттернам

Вместо "вот 5 примеров, сравни" — попроси модель СНАЧАЛА извлечь паттерны из референсов, ПОТОМ сравнить:

**ШАГ 1:** Проанализируй референсные примеры. Какие общие паттерны видишь?
- Структура (обязательные разделы)
- Tone of voice (формальный/разговорный)
- Ключевые элементы (всегда есть цифры/кейсы/etc)

**ШАГ 2:** Сравни новый текст с выявленными паттернами. Что не совпадает?

Это усиливает "обучающий" эффект референсов — модель не просто сравнивает текст, а осознанно извлекает стандарт.

💡 Экстраполяция: self-review через historical context

Применяй метод для собственного редактирования. Попроси модель создать черновик, потом сама же его проверь по референсам:

**Задача:** Напиши коммерческое предложение для {клиент}.

[модель пишет черновик]

**Теперь проверь:** Вот 3 моих успешных КП из прошлого. Сравни свой черновик с ними:
[референсы]

Есть ли отклонения? Что нужно исправить чтобы соответствовать моему стандарту?

[модель редактирует сама себя]

Это двухпроходная генерация: сначала draft без ограничений, потом refinement через призму конкретных примеров. Работает лучше чем "сразу пиши как в примере" — модель сначала думает свободно, потом калибрует.