Промпт-инжиниринг для своих моделей: базовые приёмы

MAATRIX

Гайды по промпт-инжинирингу почти всегда пишут про GPT-4 или Claude — модели с десятками миллиардов параметров, которые прощают расплывчатые формулировки и сами достраивают недосказанное. Если вы подняли у себя Llama, Mistral или Qwen на 7–14B, часть этих советов работает хуже или не работает вовсе: маленькая модель не держит длинную цепочку условий, теряет инструкцию к середине ответа, путает формат. Разберём приёмы, которые реально помогают именно с открытыми моделями на своём сервере — и честно скажем, где нужно проверять на конкретной модели, а не верить на слово.

Почему приёмы для топовых моделей не переносятся напрямую

Топовые облачные модели обучены на порядки большем объёме данных и умеют держать в голове сложную многошаговую инструкцию: «сначала сделай так, потом учти вот это исключение, а в конце оформи в такую структуру» — GPT-4 или Claude справятся, даже если условия разбросаны по абзацу. Модель на 7–14B параметров физически меньше и хуже удерживает контекст инструкции: чем длиннее и запутаннее промпт, тем выше шанс, что она выполнит только часть требований, перепутает порядок шагов или вовсе проигнорирует условие, упомянутое в середине.

Это не значит, что маленькие модели бесполезны для сложных задач — значит, что с ними нужен другой стиль постановки задачи. Практика показывает: то, что для облачной модели избыточная перестраховка, для локальной — необходимый минимум. Разница особенно заметна на моделях до 8B; версии на 32B и выше уже ближе по поведению к топовым, хотя и не догоняют их полностью.

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

Короче и конкретнее: одна задача — один промпт

Главное практическое следствие: не пытайтесь впихнуть в один промпт пять требований сразу. Вместо

Проанализируй этот текст, выдели ключевые тезисы, оцени тональность,
предложи три заголовка и сократи до 100 слов, сохранив стиль автора.

разбейте на последовательные запросы или явно пронумеруйте и упростите каждый пункт. Маленькая модель гораздо надёжнее выполняет:

Сократи текст ниже до 100 слов. Сохрани смысл и стиль автора.
Не добавляй ничего от себя, не давай пояснений — только сокращённый текст.

Текст: {текст}

Конкретность работает в обе стороны: не только «что сделать», но и «чего не делать». Явный запрет («не добавляй вступление», «не объясняй решение», «отвечай только на русском») снижает количество лишнего текста в ответе заметно надёжнее, чем расчёт на то, что модель сама поймёт формат по контексту. Если задача действительно многошаговая, лучше вызвать модель несколько раз подряд, передавая результат предыдущего шага как вход следующего, чем надеяться на одну длинную инструкцию — цепочка простых промптов почти всегда даёт более стабильный результат, чем один сложный.

Ещё один рабочий приём — вынести формат ответа в отдельное явное предложение в конце промпта, а не смешивать с содержательной частью. Модели последовательно лучше замечают инструкцию, стоящую последней перед началом генерации.

System-промпт: роль и формат, а не философия

System-промпт (или его аналог — начальный блок инструкции, если интерфейс не разделяет роли явно) — это место, где стоит задавать роль и формат ответа, а не пытаться уместить туда всю бизнес-логику. Рабочая структура:

Ты — технический ассистент поддержки. Отвечай кратко, по делу,
на русском языке. Формат ответа: не больше 3 предложений,
без списков, без markdown-разметки. Если не знаешь ответа —
так и скажи, не придумывай.

С маленькими моделями важно держать system-промпт коротким и однозначным — длинный список правил в system-части работает хуже, чем два-три чётких предложения. Если через Ollama или совместимый API вы задаёте system-сообщение отдельным полем, проверьте, что оно действительно передаётся в каждый запрос, а не только в первое сообщение диалога: в некоторых интеграциях (особенно самописных обёртках поверх API) system-промпт незаметно теряется после первого хода, и модель через пару реплик «забывает» роль.

Полезно явно закладывать в system-промпт поведение на случай, если модель не уверена в ответе — «если не знаешь, скажи, что не знаешь» снижает количество уверенно звучащих, но выдуманных ответов (модели любого размера подвержены этому, но маленькие — заметнее).

Few-shot: примеры прямо в промпте

Для маленьких моделей few-shot — один из самых надёжных приёмов вообще. Показать один-два примера желаемого формата ответа часто работает лучше, чем длинное текстовое объяснение того же самого. Модель копирует структуру примера гораздо охотнее, чем интерпретирует абстрактное правило.

Извлеки из отзыва оценку тональности и главную причину.
Отвечай строго в формате примеров ниже, без пояснений.

Отзыв: "Доставили на день позже обещанного, но товар в порядке."
Ответ: тональность: нейтральная; причина: задержка доставки

Отзыв: "Ужасное качество, деньги на ветер."
Ответ: тональность: негативная; причина: низкое качество товара

Отзыв: "{новый отзыв}"
Ответ:

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

Практический нюанс: примеры съедают контекстное окно, а у многих открытых моделей оно скромнее, чем у топовых облачных (например, 4–8K токенов у части квантованных сборок против 128K+ у топовых). Двух примеров почти всегда достаточно — три-четыре уже редко дают заметный прирост качества, зато заметно увеличивают промпт и время генерации. Если модель путает формат даже с примерами — это чаще сигнал, что модель слишком мала для задачи, а не что нужно больше примеров.

Структурные якоря и формат вывода

Когда нужен машиночитаемый ответ — JSON, таблица, список с фиксированными полями, — маленькие модели выигрывают от явных структурных подсказок в конце промпта, а не только от описания формата. Разница между «ответь в формате JSON с полями name и price» и явным каркасом ответа бывает заметной:

Верни ответ строго в этом формате JSON, без текста до или после:
{"name": "...", "price": ...}

Ещё надёжнее — начать генерацию за модель, подставив открывающую скобку или первое слово ответа как часть промпта (если API это позволяет через параметр continuation/prefix): модель продолжает начатую структуру, а не решает заново, с чего начать. Это снижает число ответов, где вместо JSON модель вставляет вводную фразу «Конечно, вот результат:».

Отдельно стоит проверять валидность вывода программно — маленькие модели чаще ошибаются с закрывающими скобками, кавычками, экранированием в JSON, чем топовые. На проде вокруг генерации стоит парсер с обработкой ошибок и, при необходимости, повторным запросом с уточнением («предыдущий ответ был невалидным JSON, вот ошибка: …, попробуй снова»).

Типичные ошибки и как их отлаживать

Если модель ведёт себя нестабильно — сначала проверьте параметры генерации, а не только промпт. Низкая temperature (0.1–0.3) для задач с чётким правильным ответом (классификация, извлечение данных, следование формату) заметно повышает предсказуемость по сравнению со значениями по умолчанию 0.7–0.8, которые уместнее для творческих задач. Параметр repeat_penalty в Ollama помогает, если модель зацикливается на повторе одной фразы — это чаще встречается у моделей меньшего размера при длинной генерации.

Второй частый источник проблем — превышение контекстного окна: если системный промпт, история диалога и few-shot-примеры вместе выходят за лимит модели, она может «забыть» инструкцию из начала промпта, даже не показав явной ошибки. Проверьте фактический размер контекста у своей сборки (num_ctx в Ollama часто занижен по умолчанию и его стоит увеличить явно под задачу) и держите совокупный объём system-промпта, примеров и истории с запасом от лимита.

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

Как проверять приёмы эмпирически

Здесь честность важнее красивых рекомендаций: не все приёмы, которые хорошо работают на топовых облачных моделях, одинаково переносятся на маленькие открытые. Иногда работает наоборот — то, что топовой модели не нужно (жёсткие структурные каркасы, продублированные инструкции), маленькой критически необходимо, а тонкости вроде chain-of-thought рассуждений вслух («думай пошагово») на некоторых мелких моделях помогают меньше, чем на крупных, и иногда даже ухудшают формат ответа, потому что модель путает рассуждение с финальным ответом.

Рабочий подход — собрать 10–20 реальных примеров входных данных из вашей задачи, прогнать через два-три варианта промпта и сравнить результат вручную или простым скриптом с проверкой на соответствие формату. Это не требует стенда — достаточно цикла bash-скрипта с curl к локальному API:

for prompt_file in prompts/*.txt; do
  curl -s http://localhost:11434/api/generate \
    -d "{\"model\":\"llama3.1\",\"prompt\":\"$(cat $prompt_file)\",\"stream\":false}" \
    >> results.jsonl
done

Дальше — читаете results.jsonl и смотрите, какой вариант промпта чаще даёт нужный формат и меньше «отсебятины». Двадцати примеров достаточно, чтобы увидеть закономерность: если 15 из 20 ответов правильные — приём работает, если 8 из 20 — не работает, и не нужен масштабный бенчмарк, чтобы это понять. Держите эти тестовые промпты в репозитории рядом с проектом — при смене модели (например, при переходе на новую версию Llama или Qwen) прогоняете тот же набор заново и сразу видите, что сломалось.

Если после экспериментов конкретный приём стабильно не работает на вашей модели — не пытайтесь его "продавить" усложнением промпта. Часто это сигнал, что задача просто на грани возможностей модели этого размера, и разумнее либо взять модель покрупнее (если позволяет видеопамять сервера), либо разбить задачу на более простые шаги.

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