Prompt Engineering

Промпт — это инструкции и контекст, передаваемые модели для конкретной задачи. Промпт-инжиниринг — практика разработки, настройки и оптимизации промптов. Ключевая идея из материала: «промпт = контракт» (роль, ограничения, чёткая цель, формат вывода), а не «просто спросить».

Суть

Расплывчатый запрос → неоднозначный ответ и галлюцинации. Хороший промпт фиксирует: роль системы, ограничения, чёткую цель и формат (JSON/XML). Это инженерная дисциплина, а не «магические слова».

Зачем это нужно

Это самый дешёвый рычаг качества: без дообучения модели (см. LLM Training Stages) можно сильно поднять результат, правильно поставив задачу. На промптинге держится и агент: системный промпт задаёт поведение «мозга».

Как работает

  • Промпт как контракт: роль + ограничения + цель + формат. Структурированный вывод (JSON) удобно парсить и валидировать.
  • AUTOMAT — фреймворк-чеклист структуры промпта: Act as, User persona, Targeted action, Output, Mode/tone, Atypical cases, Topic (систематизирует «контракт»).
  • Итеративный процесс (как в реальном кейсе разметки): подбор первичного промпта → тест и тюнинг → замер качества автометриками → итеративно улучшаем.
  • Базовые техники-усилители: примеры (Few Shot Prompting) и принуждение к рассуждению (Chain of Thought).
  • Анатомия промпта (Anthropic): рекомендуемый порядок блоков — задача/роль → контекст и данные → детальные инструкции → few-shot примеры → финальное напоминание ключевого.
  • XML-теги: оборачивай части промпта (<context>, <instructions>, <example>, <report>) — Claude «любит структуру», и в инструкции можно ссылаться на блоки; для разметки данных надёжнее markdown. Заодно отделяет инструкции от данных (защита от prompt-injection, см. Guardrails).
  • Системный промпт для статики: неизменное (структура документа, правила, примеры) → в системный промпт; это включает Prompt Caching.
  • Pre-filling: задать начало ответа модели ({ для JSON, <verdict>) → жёстко направляет формат вывода.
  • Контракт сильнее инструкции: «промпт = контракт» — это всё ещё просьба, которую модель может нарушить. Когда формат критичен, его выносят из промпта в схему типов: Field(description=...) переносит описание формата в JSON Schema, а constrained decoding делает нарушение невозможным (см. Structured Output). Промпт остаётся для смысла задачи, формат гарантирует схема.
  • Итеративный пример (кейс разбора ДТП, V1→V5): V1 голая инструкция → галлюцинация; V2 +роль/тон → верный контекст; V3 +структура формы в system → точность чтения чекбоксов; V4 +пошаговый CoT → обоснованный вывод; V5 +XML-вывод → готовый структурированный результат.

Пример

[роль]     Ты — классификатор тональности отзывов.
[цель]     Определи тональность: positive | neutral | negative.
[формат]   Верни строго JSON: {"label": "...", "confidence": 0..1}
[ограничения] Если текст не отзыв — верни {"label":"n/a"}.

Связано с

  • Few Shot Prompting — примеры в промпте как техника
  • Chain of Thought — заставить модель рассуждать перед ответом
  • LLM Training Stages — почему промптинг работает «без обучения» (in-context)
  • Prompt Caching — статику в системный промпт → кэш префикса
  • Guardrails — XML-теги отделяют инструкции от данных (anti-injection)
  • Structured Output — когда формат критичен, его гарантирует схема, а не промпт

Открытые вопросы

  • когда промпта уже мало и нужен RAG/fine-tune
  • как собрать набор автометрик под задачу промптинга → метод см. Agent Evals (ждёт курс: лекция #25 Testing & Evals, 2026-07-27)