Промпт-инжиниринг для LLM: основы, которые работают с любой моделью

Промпт-инжиниринг для LLM звучит громко, но по сути это умение сформулировать задачу так, чтобы модели не пришлось угадывать. Часто плохой ответ объясняется не слабой моделью, а недосказанным запросом: не указан формат, не дан контекст, не обозначены границы. Ниже шесть частей хорошего промпта, пример до и после и расчёт того, как структура влияет на цену. Цены даны на 18 октября 2026.

Что такое промпт-инжиниринг и что он не делает

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

Также он не отменяет проверку. Даже идеальный промпт не гарантирует правильных фактов, поэтому ответы нужно проверять. О системной части запроса подробнее в статье Как писать системные промпты↗. Основы можно освоить за вечер, но настраивать промпт под конкретную модель и задачу придётся итерациями.

Шесть частей структуры

Не все части нужны в каждом промпте, но чек-лист удобно держать перед глазами.

1. Роль. Одной строкой: кто отвечает и для кого. «Ты оператор поддержки интернет-магазина, пишешь клиентам». Роль задаёт лексику и уровень детализации.
2. Задача. Что именно сделать, одним глаголом. «Подготовь ответ на письмо». Одна задача на запрос; сложную разбейте на шаги.
3. Контекст. Факты, которых нет у модели: политика компании, детали заказа, терминология. Всё, что нужно для ответа, должно быть в запросе: модель не знает ваших внутренних правил.
4. Формат. Длина, структура, язык, обращение, поля JSON. «Письмо до 80 слов, на „вы“, в конце следующий шаг и срок».
5. Примеры. Один-три образца желаемого результата работают лучше длинных описаний. Подробнее — в статье про few-shot промптинг↗.
6. Ограничения. Чего не делать: «не обещай того, чего нет в политике», «не выдумывай номера и даты», «если данных не хватает, напиши, каких именно».

Отдельно про разметку. Данные пользователя (письмо, документ, код) отделяйте от инструкций разделителями, например тегами <письмо>...</письмо>. Так модель не примет текст письма за указания, а вам проще подставлять данные программно.

Пример: промпт до и после

Условный магазин. Клиент пишет: «Заказ 4521 не пришёл, верните деньги».

Версия 1: короткий запрос.

Ответь клиенту на письмо: Заказ 4521 не пришёл, верните деньги

Модель вынуждена гадать. Скорее всего, вы получите длинное письмо с общими извинениями, обещаниями вернуть деньги в неизвестный срок и просьбой «уточнить детали», а возможно, и выдуманные условия возврата.

Версия 2: структурированный запрос.

Роль: ты оператор поддержки интернет-магазина.
Задача: подготовь ответ на письмо клиента.
Контекст: возврат денег делаем в течение 5 рабочих дней после подтверждения
недоставки. Заказ 4521 отправлен 3 октября, трек не обновляется 10 дней.
Формат: письмо до 80 слов, обращение на «вы», одно извинение, в конце следующий
шаг и срок.
Ограничения: не обещай того, чего нет в политике. Не выдумывай номера и даты.
Если данных не хватает, напиши, каких именно.

<письмо>
Заказ 4521 не пришёл, верните деньги
</письмо>

Теперь у модели есть факты, границы и формат. Ответ становится короче, предсказуемее и пригоден к отправке после беглой проверки. Версию 2 удобно хранить как шаблон, подставляя письмо и факты кодом.

Как это выглядит в коде

Через OpenAI-формат (pip install openai):

from openai import OpenAI

client = OpenAI(base_url="https://api.zukko.pro/v1", api_key="fetch_ваш_ключ")

SYSTEM = """Роль: ты оператор поддержки интернет-магазина.
Формат: письмо до 80 слов, обращение на «вы», одно извинение, в конце следующий шаг и срок.
Ограничения: не обещай того, чего нет в политике. Не выдумывай номера и даты.
Если данных не хватает, напиши, каких именно."""

def reply(letter, facts):
    user = f"Подготовь ответ на письмо.\nКонтекст: {facts}\n\n<письмо>\n{letter}\n</письмо>"
    r = client.chat.completions.create(
        model="gpt-6.1-sol",
        messages=[

Через Anthropic-формат системная инструкция передаётся отдельным параметром system (адрес без /v1):

import anthropic

a = anthropic.Anthropic(base_url="https://api.zukko.pro", api_key="fetch_ваш_ключ")

m = a.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=300,
    system=SYSTEM,
    messages=[{"role": "user", "content": "Подготовь ответ на письмо.\n\n<письмо>\nЗаказ 4521 не пришёл, верните деньги\n</письмо>"}],
)
print(m.content[0].text)

Обратите внимание на max_tokens=300: в Anthropic-формате параметр обязателен, и он же ограничивает длину ответа.

Как структура влияет на цену

Выходные токены стоят дороже входных: у claude-sonnet-5-5 вход 0.4, выход 2 доллара за 1M токенов, то есть выход в пять раз дороже. Поэтому лишние слова в ответе обходятся дороже лишних слов в запросе.

Допущения для расчёта (не замеры, ориентир): версия 1 — 30 токенов запроса и 600 токенов ответа; версия 2 — 300 токенов запроса и 150 токенов ответа.

• Версия 1: 30 × 0.4 / 1M + 600 × 2 / 1M = 0.000012 + 0.0012 = $0.001212.
• Версия 2: 300 × 0.4 / 1M + 150 × 2 / 1M = 0.00012 + 0.0003 = $0.00042.

На 10 000 писем: версия 1 даёт 10 000 × 0.001212 = $12.12, версия 2 — 10 000 × 0.00042 = $4.20. Запрос стал в десять раз длиннее, а стоимость ниже, потому что ответ сократился. Реальные числа у вас будут другими, поэтому измеряйте поле usage на своих данных. Если системная часть длинная и не меняется, её стоит ставить в начало запроса: так срабатывает кэш (см. как считаются чтение и запись кэша↗). Актуальные цены — GET https://api.zukko.pro/v1/models.

Итерации и проверка

Промпт редко получается с первой попытки. Рабочий цикл:

1. Соберите 10–20 реальных примеров входов, включая неудобные.
2. Запускайте промпт на всех сразу, смотрите ответы целиком.
3. Меняйте одну вещь за раз и сравнивайте. Меняя три параметра сразу, вы не узнаете, что помогло.
4. Зафиксируйте проверки кодом: длина, наличие обязательных слов, валидный JSON.
5. После смены модели прогоните набор заново: один и тот же промпт может вести себя иначе.

Как автоматизировать такой прогон, показано в статье Как тестировать промпты↗. Начать можно, создав ключ в кабинете↗; оплата из России — СБП (платёжная страница добавляет 8,5% сверху), карта MasterCard или криптовалюта.

Частые вопросы

Что такое промпт-инжиниринг простыми словами?

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

Нужно ли писать длинные промпты?

Не обязательно длинные, но достаточно конкретные. Лишние слова вредят так же, как нехватка фактов. Ориентир: в запросе есть всё, что нужно для ответа, и нет ничего, что не влияет на результат.

Один промпт подойдёт для всех моделей?

Базовые принципы общие, но поведение моделей отличается, и точные формулировки лучше проверять на выбранной модели. После смены модели повторите прогон на своих примерах.

Как сократить расход токенов на промптах?

Просите конкретный формат и длину ответа, ограничивайте max_tokens, не повторяйте длинный контекст без нужды, а неизменную часть ставьте в начало запроса, чтобы работал кэш.