«Промпт-інженерія» має серед розробників погану репутацію: звучить як підбір магічних фраз. У продакшені це щось буденніше — написання чітких інструкцій, які можна тестувати, для компонента, поведінку якого неможливо повністю описати кодом. Добрий продакшен-промпт ближчий до якісної специфікації, ніж до хитрого трюку. У гайді — техніки, що стабільно мають значення, як структурувати промпти як код і як змінювати їх, не ламаючи того, що вже працює.

Що змінилося з сучасними моделями

Ранні поради з промптів були повні трюків: «глибоко вдихни», погрози, чайові, капслок. Сучасні моделі, навчені виконувати інструкції, добре слухаються простих і конкретних вказівок, а гайди самих вендорів сходяться на тих самих основах (огляд промпт-інженерії від Anthropic; гайд OpenAI). Великий огляд технік промптингу каталогізував десятки методів, але більшість продакшен-виграшу дають кілька з них (Schulhoff et al., The Prompt Report, 2024).

Зміна для розробників: перестаньте сприймати промпти як заклинання і почніть сприймати їх як інтерфейси — вхідні дані, поведінка, вихідні дані, випадки помилок.

Анатомія продакшен-промпту

Надійна структура системного промпту:

  1. Роль і контекст. Ким виступає модель, хто користувач, що за продукт.
  2. Задача. Що зробити — одним-двома реченнями.
  3. Правила й обмеження. Що робити завжди й чого ніколи, з поясненням причин.
  4. Опис вхідних даних. Які дані отримає модель і як вони розмежовані.
  5. Специфікація виводу. Формат, довжина, мова, схема.
  6. Приклади. Кілька пар «вхід–вихід» для типових і складних випадків.
  7. Граничні випадки. Що робити, коли інформації бракує, вона неоднозначна чи поза межами задачі.
You are a support assistant for Acme Accounting, a SaaS for small businesses
in Ukraine. Users are accountants; answer as a knowledgeable colleague.

Task: answer the user's question using only the documentation in <docs>.

Rules:
- If the docs do not contain the answer, say so and suggest contacting
  support@acme.ua. Do not guess — wrong tax advice causes real harm.
- Answer in the user's language (Ukrainian or English).
- Keep answers under 150 words unless the user asks for detail.
- Never mention internal ticket numbers or employee names from the docs.

<docs>
{{retrieved_documents}}
</docs>

Output: a direct answer first, then a "Sources:" line listing doc titles.

Зверніть увагу на причину після «Do not guess». Пояснення, чому існує правило, допомагає моделі узагальнити його на випадки, які ви не перелічили, — гайд Anthropic прямо на це вказує.

Техніки, що стабільно допомагають

Конкретно описуйте, чого хочете

Розмито: «Підсумуй цей документ». Конкретно: «Підсумуй цей договір для менеджера з продажу у п'яти пунктах: сторони, строк, ціна, умови розірвання, незвичні пункти. Цитуй номери пунктів». Конкретна версія довша і значно надійніша. Тест: чи зробив би новий колега-людина те, що вам потрібно, прочитавши лише цей промпт?

Відокремлюйте інструкції від даних тегами

Коли промпт містить документи, ввід користувача чи результати інструментів, чітко їх розмежовуйте. Теги в стилі XML добре працюють з різними моделями: <docs>, <user_question>, <previous_answer>. Теги допомагають моделі відрізнити ваші інструкції від вмісту, а вам — розбирати вивід. Вони також трохи допомагають проти prompt injection, хоча межею безпеки не є; див. безпека AI-агентів.

Використовуйте приклади свідомо

Few-shot приклади — найпотужніший спосіб показати формат і тон (Brown et al., 2020). Правила добрих прикладів:

  • 3–5 прикладів, достатньо різноманітних, щоб модель не копіювала поверхові ознаки.
  • Щонайменше один граничний випадок (бракує інформації, відмова).
  • Обгортайте їх у теги <example>, щоб їх не плутали з реальним вводом.
  • Тримайте приклади узгодженими з правилами — суперечності між прикладами й інструкціями збивають модель.

Дайте моделі подумати, коли задача цього вимагає

Для багатокрокових міркувань — обчислення, класифікація за багатьма критеріями, планування — прохання поміркувати перед відповіддю підвищує точність (Wei et al., 2022). Сучасні моделі часто мають вбудовані режими розширеного мислення, що роблять це без підказок; вмикайте їх для складних задач і не вмикайте для простого видобування, де міркування лише додають затримку й вартість. Якщо міркування потрібні окремо від відповіді, просіть їх у блоці <thinking>, а відповідь — у <answer>, і розбирайте лише останній.

Точно специфікуйте вивід

Кажіть, який формат, довжина й структура потрібні і що опустити («без вступу», «без markdown-заголовків»). Для машинозчитуваного виводу використовуйте structured outputs або виклик інструментів зі схемою JSON, а не ввічливе прохання повернути JSON; див. структурований вивід.

Довгі документи — на початок, запитання — в кінець

Для промптів із довгим контекстом розміщення документів зверху, а запитання й інструкцій наприкінці зазвичай покращує відповіді. Також моделі нерівномірно звертають увагу на різні частини дуже довгого контексту — це явище задокументоване в роботі Lost in the Middle. Менше, але релевантнішого контексту зазвичай краще, ніж більше, — це головна тема контекстної інженерії.

Промпти — це код: структуруйте їх як код

У продакшені промпти мають жити в репозиторії, а не в дашборді, який хтось редагує в п'ятницю ввечері.

prompts/
  support_answer/
    system.md          # шаблон системного промпту
    examples.yaml      # few-shot приклади
    schema.json        # схема виводу
    CHANGELOG.md       # що змінилося і чому
  ticket_classifier/
    ...

from pathlib import Path
from string import Template

PROMPT_DIR = Path(__file__).parent / "prompts"

def render(name: str, **vars) -> str:
    text = (PROMPT_DIR / name / "system.md").read_text()
    return Template(text).substitute(**vars)  # падає, якщо бракує змінних

system = render("support_answer", product="Acme Accounting")

Практики, що вберігають від болю:

  • Версіонуйте промпти разом із кодом, що їх викликає. Зміна промпту — це зміна коду, і вона проходить рев'ю.
  • Логуйте версію промпту з кожним запитом, щоб пов'язувати зміни якості зі змінами промптів; див. спостережуваність LLM.
  • Падайте на відсутніх змінних шаблону, а не надсилайте моделі мовчки {{customer_name}}.
  • Динамічний вміст — наприкінці, стабільні інструкції — на початку; це також максимізує влучання в кеш промптів.

Як безпечно змінювати промпти

Кожна зміна промпту може виправити один випадок і зламати три інші. Єдиний надійний спосіб дізнатися — запускати оцінювання:

  1. Підтримуйте еталонний набір із 50–200 реальних вхідних даних з очікуваними властивостями.
  2. Запустіть поточний і новий промпт на всьому наборі.
  3. Порівнюйте оцінки за категоріями, а не лише загальну.
  4. Перед релізом прочитайте вибірку змінених відповідей.

Повна методика — у статті як оцінювати LLM-застосунки. Без evals промпт-інженерія справді є вгадуванням.

Оновлення моделі — теж зміна промпту

Коли переходите на новішу модель, перезапускайте evals. Новіші моделі часто виконують інструкції буквальніше — промпт, що покладався на те, що стара модель «додумає», тепер може давати вужчий результат. Типові виправлення: явно вказати бажаний рівень деталізації, прибрати емоційні маркери («CRITICAL», «MUST»), які нові моделі застосовують надмірно, і переперевірити приклади. Саме тому вендори публікують нотатки щодо міграції — читайте їх.

Антипатерни

  • Промпт-суп. Системний промпт на 3000 слів, що накопичувався місяцями, із суперечливими правилами, які ніхто не наважується видалити. Рефакторте промпти як код; видаляйте правила, непотрібність яких показують evals.
  • Лише заборони. «Не використовуй markdown» працює менш надійно, ніж «Пиши звичайними абзацами прози».
  • Приховані вимоги. Бізнес-правила, що існують лише в промпті й ніде в коді чи документації. Важливі обмеження дублюйте ще й у коді валідації.
  • Тестування на п'яти прикладах. Здається продуктивним, нічого не доводить.
  • Просити модель рахувати чи робити точний пошук, що може зробити код. Обчислюйте в коді, а моделі передавайте результати.

Чек-лист перед випуском промпту

  • Роль, задача, правила, вхід, вихід і граничні випадки описані явно
  • Дані розмежовані тегами; ввід користувача не сплутати з інструкціями
  • 3–5 прикладів покривають типові й граничні випадки та узгоджені з правилами
  • Для машинозчитуваного виводу формат забезпечують structured outputs
  • Промпт лежить у репозиторії, версіонований і пройшов рев'ю
  • Evals проходять на еталонному наборі з оцінками за категоріями
  • Версія промпту логується з кожним запитом

FAQ

Чи писати промпти англійською, якщо користувачі пишуть українською? Інструкції англійською добре працюють з основними моделями, а моделі можна вказати відповідати мовою користувача. Для доменних термінів додайте приклади цільовою мовою.

Якої довжини має бути системний промпт? Такої, як потрібно, і не довшої. Багато продакшен-промптів мають 300–1500 слів. Довжина — нормально; суперечності й «вода» — ні.

Чи потрібна промпт-інженерія з агентами? Більше, ніж будь-коли, але її межі розширюються на описи інструментів, відбір контексту й пам'ять — див. контекстна інженерія і проєктування інструментів для агентів.

Чи може LLM покращувати наші промпти? Так — моделі добре критикують і переписують промпти. Сприймайте їхні пропозиції як кандидатів і приймайте лише тоді, коли покращуються evals.

Джерела

  1. Anthropic. Prompt engineering overview.
  2. OpenAI. Prompt engineering guide.
  3. Schulhoff et al. (2024). The Prompt Report: A Systematic Survey of Prompting Techniques.
  4. Brown et al. (2020). Language Models are Few-Shot Learners.
  5. Wei et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.
  6. Liu et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.