Раздел 10 — Промпт-инжиниринг: явные критерии, few-shot и циклы валидации

Что покрывает этот раздел

Три техники уровня промпта, которые экзамен Foundations считает ключевыми для перевода Claude-фичи из demo-качества в production-качество: явные категориальные критерии вместо размытых инструкций, 2–4 целевых few-shot примера и цикл валидации с повторными попытками с сигналами самокоррекции, встроенными в схему. Домен 4.3 (использование инструментов + JSON Schema) рассматривается в разделе 11; этот раздел закрывает семантический разрыв, который строгие схемы не закрывают.

Исходный материал (из официального руководства)

4.1 Явные критерии вместо размытых инструкций

• Явные категориальные критерии лучше размытых инструкций: “flag comments only when claimed behavior contradicts actual code behavior” превосходит “check that comments are accurate”. Общие инструкции вроде “be conservative” или “only report high-confidence findings” не повышают точность; высокая доля ложных срабатываний в одной категории подрывает доверие сразу ко всем категориям.
• Навыки: пишите конкретные правила «сообщать, когда / пропускать, когда» по каждой категории; временно отключайте категории с высокой долей ложных срабатываний на время доработки; определяйте явные критерии серьёзности с конкретными примерами кода для каждого уровня.

4.2 Few-shot prompting

• Few-shot примеры — самая эффективная техника для согласованного форматированного, действенного вывода, когда одних подробных инструкций недостаточно. Они помогают обрабатывать неоднозначные случаи (выбор инструмента, эскалация), обеспечивают обобщение на новые шаблоны и снижают галлюцинации при извлечении из документов разной структуры.
• Навыки: 2–4 целевых примера, показывающих рассуждение в пользу выбранного действия по сравнению с правдоподобными альтернативами; примеры, демонстрирующие желаемый формат вывода (расположение, проблема, серьёзность, предложенное исправление); примеры, отличающие приемлемые шаблоны от настоящих проблем; примеры, покрывающие каждый структурный вариант ввода.

4.4 Валидация, повторные попытки и циклы обратной связи

• Повторная попытка с обратной связью по ошибке: добавляйте конкретную ошибку валидации к следующему промпту, чтобы направить самокоррекцию. Повтор бесполезен, когда требуемая информация отсутствует в источнике. Различайте семантические ошибки валидации (значения не сходятся, не то поле) и синтаксические ошибки схемы (уже устранены использованием инструментов).
• Навыки: повторные запросы, включающие исходный документ + неудавшееся извлечение + конкретные ошибки; добавьте detected_pattern, чтобы делать анализ ложных срабатываний; продумайте самокоррекцию, извлекая calculated_total рядом со stated_total; добавляйте булевы поля conflict_detected для несогласованных источников.

Написание явных критериев

Размытые против конкретных — переписки «до/после»

Самый важный шаг от прототипа к продакшену — заменить нечёткие инструкции («be careful», «only report high-confidence findings», «be conservative») на категориальные критерии, определяющие поведение. Самооцениваемая уверенность плохо откалибрована: модель, ошибочно уверенная в сложных случаях, не будет спасена фразой “only report high-confidence findings” — она продолжит сообщать те же неправильные вещи.

Обратите внимание на закономерность: каждая «хорошая» версия отвечает на два вопроса — что считается положительным срабатыванием? и что считается не-проблемой, которую я обязан пропустить? Sample Question 3 в руководстве делает ту же мысль в форме агента: показатель first-contact resolution 55% растёт за счёт добавления явных критериев эскалации с few-shot примерами, а не за счёт самооцениваемой шкалы уверенности.

Определения серьёзности с примерами кода

Для любого классификатора, выдающего поле severity, определяйте каждый уровень конкретным примером кода внутри промпта. Иначе разные прогоны схлопывают различие между low и medium в шум.

<severity_definitions>
  <critical>Data loss, auth bypass, or RCE in prod.
    Example: db.query("SELECT * FROM users WHERE id=" + req.params.id)</critical>
  <high>Bug producing incorrect output for at least one realistic input.
    Example: off-by-one in pagination dropping the last page.</high>
  <medium>Resource leak or correctness issue only under load.
    Example: file handle opened in a loop without `with` / `defer close`.</medium>
  <low>Style or readability only — do NOT include unless explicitly asked.</low>
</severity_definitions>

Привязка каждого уровня к примеру вынуждает согласованную классификацию между запусками и между ревьюерами.

Отключи-и-перестрой для категорий с высокой долей ложных срабатываний

Ложные срабатывания в одной категории подрывают доверие к каждой категории. Руководство рекомендует осознанный паттерн «отключи и перестрой»: когда «точность комментариев» работает с долей ложных срабатываний 40%, лучше убрать эту категорию полностью, чем оставить её и подорвать доверие к замечаниям по безопасности, на которые разработчики реально реагируют. Дорабатывайте плохую категорию в отдельном промпте, пока точность не превысит ваш порог, затем включайте обратно.

Почему «be conservative» не работает

Калибровка. Наречия вроде «carefully» или «only when sure» не дают модели ничего, что можно механически проверить. Напротив, “do not report a finding unless you can quote the exact source line and name the rule” — это проверяемое правило, и модель может сама верифицировать его до выдачи ответа.

Глубокое погружение во few-shot prompting

Сколько примеров?

Опубликованные рекомендации Anthropic и руководство по сертификации сходятся в одном числе: 2–4 целевых примера. Меньше двух не задают шаблон; больше четырёх жгут токены ради убывающей отдачи и рискуют переобучить модель на поверхностные признаки примеров. Для промптов с extended thinking Anthropic отдельно отмечает, что multishot по-прежнему помогает, но должен показывать шаблоны рассуждения, а не просто пары ввод→вывод.

Анатомия примера

Эффективные примеры несут три поля, а не два:

1. Ввод — фрагмент, отражающий реальный production-ввод.
2. Рассуждение — почему выбранное действие верно по сравнению с правдоподобными альтернативами.
3. Вывод — ровно та форма (XML или JSON), которую вы хотите получать во время инференса.

<example>
  <input>
    User: "My order from last Tuesday hasn't arrived and I want my money back."
  </input>
  <reasoning>
    This is a delivery exception within standard policy (lost package, &lt; 30 days,
    refund value within auto-approve threshold). No policy exception is being
    requested. Resolve autonomously with refund + reship.
  </reasoning>
  <output>
    {"action": "resolve", "tool": "issue_refund", "escalate": false}
  </output>
</example>

Примеры для неоднозначных случаев, формата и снижения ложных срабатываний

• Неоднозначные случаи. Возьмите 2–4 примера из вашего eval-набора, где модель ранее ошибалась, и включите контрастную пару — пример, который выглядит похоже, но должен быть обработан противоположным образом. Контрастные пары учат обобщению, а не запоминанию.
• Согласованность формата. Если вы хотите, чтобы каждое замечание имело форму {location, issue, severity, suggested_fix}, покажите три замечания ровно в этой форме. Одни инструкции пропускают непоследовательную капитализацию, отсутствующие поля и хвостовую прозу.
• Снижение ложных срабатываний. Соедините пример «проблема» с примером «приемлемого шаблона», разделяющим поверхностные признаки. Для ревьюера SQL-инъекций покажите одну уязвимую конкатенацию и один параметризованный вызов с меткой not_a_finding — так вы прекратите помечать каждый db.query(...).
• Разные структуры документов. Для счетов с грязными строками, статей с цитатами по тексту и в библиографии или методологии, встроенной в нарратив, давайте по одному примеру на каждый структурный вариант. Без покрытия каждой формы извлечение возвращает null на ранее не виденных форматах.

Куда помещать примеры — разметка XML

Документация Anthropic по промпт-инжинирингу однозначна: оборачивайте примеры в XML-теги (<example>, <examples>, <input>, <output>) и размещайте их после инструкций задачи и критериев, но до живого ввода.

<task>...explicit criteria here...</task>
<severity_definitions>...</severity_definitions>
<examples>
  <example>...</example>
  <example>...</example>
  <example>...</example>
</examples>
<input>{{actual_document_to_process}}</input>

Валидация, повторные попытки и циклы обратной связи

Повторная попытка с обратной связью по ошибке

Шаблон таков: программно валидируйте ответ модели и при отказе шлите новый ход, содержащий исходный ввод, неудавшийся ответ и конкретную ошибку валидации. Общая «попробуй ещё раз» никогда не помогает — помогает конкретный текст ошибки.

from anthropic import Anthropic

client = Anthropic()
MODEL = "claude-opus-4-7"

def extract_with_retry(document: str, max_attempts: int = 2) -> dict:
    messages = [{"role": "user", "content": build_extraction_prompt(document)}]
    for attempt in range(max_attempts + 1):
        resp = client.messages.create(
            model=MODEL, max_tokens=2048,
            tools=[INVOICE_TOOL],
            tool_choice={"type": "tool", "name": "extract_invoice"},
            messages=messages,
        )
        extraction = next(b.input for b in resp.content if b.type == "tool_use")

        errors = validate(extraction)
        if not errors:
            return extraction
        if not is_recoverable(errors):
            raise ExtractionError(errors, extraction)

        messages.append({"role": "assistant", "content": resp.content})
        messages.append({"role": "user", "content":
            f"Your previous extraction failed validation:\n"
            f"{format_errors(errors)}\n\n"
            f"Re-examine the original document and call extract_invoice again, "
            f"correcting only the listed errors."
        })
    raise ExtractionError(errors, extraction)

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

Когда повтор НЕ поможет

Повторы исправляют ошибки формата и структуры (неправильные имена полей, перепутанные значения, строки, которые не сходятся в сумму). Они не исправляют информацию, которая в действительности отсутствует в источнике. Если PDF счёта не содержит ИНН, никакой повтор его не выдаст — а агрессивный цикл повторов может надавить на модель и заставить её галлюцинировать значение, чтобы пройти валидацию. Определяйте «отсутствует в источнике» в валидаторе и останавливайте цикл со структурированным null плюс причиной вместо повторных попыток.

Сигналы самокоррекции в схеме

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

• calculated_total рядом со stated_total — модель выдаёт оба; ваш валидатор флагует расхождения. Модель часто сама исправляется в том же ответе, потому что вычисление calculated-значения вынуждает её посмотреть на каждую позицию.
• Булевы conflict_detected — для документов, где два раздела противоречат друг другу (дата в шапке против даты в подвале, число в сводке против длины списка), просите модель выдавать булево на каждую группу конфликтов. Это превращает неоднозначность в структурированный сигнал, по которому можно маршрутизировать.

{
  "line_items": [{"desc": "Widget A", "amount": 150.00},
                 {"desc": "Widget B", "amount": 300.00}],
  "calculated_total": 450.00,
  "stated_total": 500.00,
  "total_discrepancy": true,
  "conflict_detected": false,
  "detected_pattern": "missing_tax_line"
}

detected_pattern для анализа отклонений

Добавляйте поле detected_pattern (или rule_id) к каждому замечанию. Когда разработчики отклоняют замечания в вашем UI, группируйте отклонения по detected_pattern, чтобы видеть, какие категории шумные. Без этого поля единственный ваш сигнал — агрегированная доля ложных срабатываний, которая говорит вам, что что-то не так, но не что именно править.

Семантические против синтаксических ошибок

Использование инструментов со строгой JSON Schema (домен 4.3) устраняет синтаксические ошибки — невалидный JSON, отсутствующие обязательные поля, неправильные типы. Оно не устраняет семантические ошибки — значения, которые не сходятся, даты вне диапазона документа, правдоподобный, но неверный контент. Цикл валидации с повторными попытками — это слой, обрабатывающий семантические ошибки. Частая ловушка экзамена: «мы добавили JSON-схему, почему позиции всё ещё неверны?» — потому что схемы не умеют считать арифметику.

Соберём вместе: рабочий процесс настройки точности

1. Базовая доля FP/FN по категориям. Прогоните eval-набор; сгруппируйте замечания по detected_pattern; запишите precision/recall по категориям, а не только в целом.
2. Перепишите размытые инструкции как явные критерии для топ-категорий с ложными срабатываниями — правила «сообщать, когда… / пропускать, когда…» с примерами кода с обеих сторон.
3. Добавьте 2–4 few-shot примера на каждый неоднозначный сценарий, включая хотя бы одну контрастную пару (выглядит как проблема, но не является ею) на каждую шумную категорию. Оборачивайте в XML-теги <examples>, размещённые после инструкций и до живого ввода.
4. Оберните в цикл валидации с повторными попытками. Используйте вызов инструмента для принуждения схемы; валидируйте семантические ограничения (calculated_total == stated_total, обязательная цитируемая строка источника); при отказе добавляйте конкретную ошибку и делайте один повтор.
5. Отслеживайте detected_pattern и отклонения. Сортируйте по доле ложных срабатываний еженедельно; временно отключайте любую категорию выше вашего порога, пока итерируете её.
6. Оценивайте до и после каждого изменения с помощью инструмента Evaluation в Anthropic Console или Promptfoo.

Ключевые акценты для экзамена

• Если в промпте написано «be conservative» или «only report high-confidence findings», узнавайте, что это не правильное лечение высокой доли ложных срабатываний — лечат категориальные критерии + few-shot.
• Выбирайте правильное число few-shot примеров: 2–4 целевых (не 10 и не 1).
• Помните, что few-shot примеры должны включать рассуждение (почему именно это действие, а не альтернативы), а не только ввод/вывод, особенно для неоднозначных случаев вроде эскалации или выбора инструмента.
• Определяйте, когда повтор поможет (ошибка формата/структуры, строки не сходятся в сумму), а когда нет (информация в действительности отсутствует в источнике). Не повторяйте второе.
• Различайте семантические ошибки валидации и синтаксические ошибки схемы. Использование инструментов лечит вторые; цикл валидации с повтором — первые.
• Знайте роль полей самокоррекции: calculated_total против stated_total, conflict_detected, detected_pattern.
• Для Sample Question 3 (эскалация страхового агента): правильный ответ — явные критерии эскалации + few-shot примеры, а не самооцениваемая шкала уверенности, отдельная модель-классификатор или анализ тональности.

Ссылки

• Обзор промпт-инжиниринга — Claude API docs — каноничная посадочная страница; перечисляет стек техник (be clear and direct → multishot → chain-of-thought → XML tags → system prompts → prefill → chain prompts) в порядке приоритета.
• Be clear, contextual, and specific — фундаментальные рекомендации Anthropic, стоящие за доменом 4.1.
• Use examples (multishot prompting) — официальный источник рекомендации о 2–4 примерах, анатомии примера и XML-обёртке.
• Let Claude think (chain of thought) и Use XML tags — разделяйте рассуждение и вывод и не давайте примерам, инструкциям и живому вводу перетекать друг в друга.
• Extended thinking tips — multishot всё ещё работает с extended thinking; предпочитайте инструкции высокого уровня предписывающим пошаговым.
• Increase output consistency (prefill) и Reduce hallucinations — техники, стоящие за «принудительной начальной фигурной скобкой JSON» и «требованием цитируемой строки источника».
• Evaluate prompts in the developer console и Using the Evaluation tool — Anthropic Workbench для тест-кейсов, сравнения бок о бок и человеческой оценки по 5-балльной шкале.
• Promptfoo getting started — сторонний eval-фреймворк с код-оценкой, оценкой моделью и классификационными eval’ами по 60+ провайдерам.
• Building effective agents — Anthropic Engineering — представляет промпт-инжиниринг как более простой шаг до того, как тянуться к ML-инфраструктуре (та же логика, что и за правильным ответом Sample Question 3).