Prompt engineering для русского: токены, инструкции, few-shot примеры

Prompt engineering для русского — это написать инструкцию так, чтобы модель не переключилась на английский, правильно токенизировала кириллицу и выдала форматирование по российскому стандарту. Три слоя сложности — токенизатор, language drift, форматы — решаются конкретными шаблонами; этот текст разбирает каждый из них.

Почему русский — отдельная задача

Большинство open-source моделей (Llama, Qwen, DeepSeek) тренировались на корпусе, где русский занимает 1-3% токенов. Это значит:

Инструкции на английском часто работают лучше, даже если ответ нужен на русском — модель «понимает» команды надёжнее.
Switch back to English — типичная болячка: задаёшь вопрос на русском, в ответе вдруг проскакивают целые фразы на английском или китайском (особенно у Qwen).
Форматы по умолчанию западные — даты в формате MM/DD/YYYY, числа 1,000.00, валюта $. Без явного указания — будет калька с тренировочного корпуса.
Цитирование текста — модель путает русские кавычки («ёлочки») и "программистские" — стабильно требуется уточнение, если важно.

Подробнее про токенизацию — отдельный текст про кириллицу в LLM. Здесь — что делать на уровне промпта.

Шаблон системного промпта для русского

Минимальный рабочий каркас, который мы переиспользуем в AGmind:

Ты — корпоративный AI-ассистент, отвечаешь на русском языке.

ЯЗЫК ОТВЕТА:
- Только русский язык. Английские термины — только если нет общепринятого
  русского аналога (API, SLA, RAG).
- Не переключайся на английский даже если в исходном тексте есть английские
  фрагменты — пересказывай их на русском.

ФОРМАТ:
- Даты: ДД.ММ.ГГГГ.
- Числа: пробел как разделитель тысяч (10 000), запятая для десятичных (3,14).
- Валюта: ₽ после числа (10 000 ₽).
- Кавычки: «ёлочки» для основной речи, „лапки" для вложенных.

СТИЛЬ:
- Деловой, без фамильярности.
- Без эмодзи и markdown-разметки в ответе, если не запрошено явно.

ОГРАНИЧЕНИЯ:
- Не выдумывай факты. Если в контексте нет ответа — пиши:
  «В предоставленных документах ответа нет».
- Цитируй источники в формате [Документ N], если работаешь с RAG.

Эта структура решает 80% типовых проблем: язык, формат, фабрикация. Дальше — узкие настройки под задачу.

Few-shot для русского: что важно

Few-shot (несколько примеров «вопрос — ответ» в промпте) на русском работает лучше, чем zero-shot. Особенно для:

Структурированного вывода (JSON, таблица, список).
Стилевых ограничений (юридический язык vs. дружелюбный support).
Нестандартных задач (классификация по 12 категориям, специфичная разметка).

Минимум — 2-3 примера. Оптимум — 5-7. Больше — даёт diminishing returns и съедает контекст.

Важно: примеры должны быть полностью на русском. Смешивать английские примеры с русскими ответами — модель регулярно ломается на langauge switch.

Пример для классификации обращений:

Классифицируй обращение в одну из категорий:
- ОПЛАТА — вопросы по счетам, оплате, возврату.
- ДОСТУП — проблемы с входом в систему, паролями.
- ОБУЧЕНИЕ — вопросы по работе с продуктом.
- ДРУГОЕ — всё остальное.

Примеры:

Обращение: Не могу зайти в личный кабинет, забыл пароль.
Категория: ДОСТУП

Обращение: Когда придёт акт за март?
Категория: ОПЛАТА

Обращение: Подскажите, как настроить выгрузку в Excel.
Категория: ОБУЧЕНИЕ

Теперь классифицируй:

Обращение: {USER_INPUT}
Категория:

Топ-5 типовых промпт-задач и шаблоны

1. Резюмирование документа

Боль: модель пытается «художественно пересказать», теряет цифры и сроки.

Сделай краткое резюме документа ниже.

ТРЕБОВАНИЯ:
- 5-7 пунктов, каждый — одно предложение.
- Сохрани все суммы, даты, процентные ставки и сроки.
- Не добавляй информацию, которой нет в исходном тексте.

ДОКУМЕНТ:
{TEXT}

РЕЗЮМЕ:

2. Извлечение структурированных данных

Боль: модель отдаёт markdown-таблицу вместо JSON, или JSON ломается на спецсимволах.

Извлеки данные из документа в формате JSON.

СХЕМА:
{
  "номер_договора": "string",
  "дата_заключения": "ДД.ММ.ГГГГ",
  "стороны": ["string"],
  "сумма_рублей": "number",
  "срок_действия_месяцев": "number"
}

ПРАВИЛА:
- Если поле не найдено — null.
- Сумму возвращай числом без пробелов и валюты.
- Только JSON, без комментариев и markdown-обёрток.

ДОКУМЕНТ:
{TEXT}

Низкая temperature (0.0-0.2) обязательна — иначе JSON ломается случайным образом.

3. Классификация без обучения

Боль: модель додумывает категории, которых нет в списке.

Определи тип обращения. Допустимы ТОЛЬКО следующие значения:
БАГ, ФИЧА, ВОПРОС, ЖАЛОБА.

Если обращение не подходит ни под одну категорию — верни ВОПРОС.
Не используй другие слова. Только одно из четырёх значений.

ОБРАЩЕНИЕ:
{TEXT}

ТИП:

Помогает повторение допустимых значений в конце — модель не забывает их за длинным контекстом.

4. Генерация ответа клиенту

Боль: модель выдаёт корпоративный канцелярит «доводим до Вашего сведения».

Сгенерируй ответ клиенту на обращение ниже.

СТИЛЬ:
- Дружелюбный, на «вы» с маленькой буквы.
- Без канцеляризмов («доводим до сведения», «осуществляется»).
- Глаголы в активном залоге («мы починим», не «будет произведён ремонт»).
- 2-4 коротких абзаца, не больше.

ОТВЕТ ДОЛЖЕН СОДЕРЖАТЬ:
1. Подтверждение что вы поняли проблему.
2. Что конкретно делается.
3. Когда ждать решения.

ОБРАЩЕНИЕ КЛИЕНТА:
{TEXT}

5. RAG-промпт с цитированием

Ответь на вопрос пользователя на основе предоставленных документов.

ПРАВИЛА:
- Используй ТОЛЬКО информацию из документов ниже.
- Если ответа нет — напиши «В документах ответа нет».
- В конце каждого утверждения указывай источник в формате [Документ N].
- Не объединяй несколько документов в одно утверждение без указания всех.

ДОКУМЕНТЫ:
[Документ 1] {chunk_1}
[Документ 2] {chunk_2}
...

ВОПРОС:
{QUESTION}

ОТВЕТ:

Подробнее про RAG-архитектуру — тут и тут.

Что НЕ работает на русском (и почему)

1. «Думай шаг за шагом» (chain-of-thought через инструкцию). Работает хуже английского Let's think step by step. На русском помогает явное указание «Сначала разбери задачу на пункты, потом ответь».

2. Эмоциональные манипуляции типа «это очень важно». Дают эффект на инструкт-моделях, тренированных на западных датасетах (Llama, Qwen). На русифицированных файнтюнах (Saiga, Vikhr) — работают слабее или нейтрально.

3. Длинные многоуровневые ролевые промпты. «Ты — старший юрист с 20-летним стажем, работающий в международной компании, специализирующийся на…» — на русском часто шумит сильнее, чем помогает. Лучше короткое: «Ты — корпоративный юрист, отвечаешь по российскому праву».

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

Грабли, которые видим регулярно

Проблема 1: модель скатывается в английский

Симптом: в ответе вдруг появляются целые предложения или термины на английском.

Причины:

В контексте есть большой английский фрагмент (документация, лог).
Системный промпт — на английском.
Используется не файнтюненная под русский модель.

Решение:

Системный промпт на русском.
Явная инструкция «отвечай только на русском, даже если в контексте есть английский».
Для критических задач — модель с русским файнтюном (Saiga, Vikhr — см. обзор).

Проблема 2: галлюцинации в RAG

Симптом: ответ красивый, но в документах такого нет.

Решение:

Жёсткая инструкция «только из документов» + «если нет — пиши В документах ответа нет».
Низкая temperature (0.0-0.3).
Цитирование [Документ N] после каждого утверждения — модель «вспоминает», что должна опираться на источники.
Reranker перед LLM — отсекает мусор. См. реранкеры.

Проблема 3: формат ломается на длинных входах

Симптом: для коротких документов JSON чистый, для длинных — спецсимволы ломают парсинг.

Решение:

Constrained decoding (Outlines, Guidance, llama.cpp grammar) — заставляет модель генерировать только валидный JSON.
На vLLM есть guided_json параметр — тот же эффект.
Если constrained decoding нет — temperature=0 и валидация на стороне приложения с retry.

Проблема 4: неконсистентный стиль

Симптом: модель то «вы», то «Вы», то «ты» в разных ответах.

Решение: стиль закрепить в системном промпте + один-два примера few-shot — этого хватает.

Параметры sampling: что трогать

Для production-промптов на русском:

Параметр	Дефолт	Когда менять
`temperature`	0.0-0.3 для structured / classification, 0.7 для генерации	Выше 0.7 — почти всегда вредно
`top_p`	0.9	Можно оставить дефолт
`top_k`	40	Можно оставить дефолт
`repetition_penalty`	1.0-1.1	Поднимать если модель зацикливается
`max_tokens`	по задаче	Жёстко лимитировать — иначе модель растягивает

Главное правило: для всего, что валидируется (JSON, классификация, извлечение данных) — temperature=0. Для всего, где нужен «живой» текст — 0.5-0.7.

Тестирование промптов

Без регрессионного тестирования промпты деградируют. Базовый процесс:

Собрать 30-100 примеров входов с эталонными ответами.
Прогнать промпт по всем — записать ответы.
При изменении промпта — прогнать снова, сравнить.
Метрики:
- Exact match — для классификации и JSON.
- BERTScore / Cosine similarity — для генерации (приближённо).
- LLM-as-judge — другая модель оценивает по критериям. Не идеально, но работает на масштабе.

Минимум — eval-сет с 20 примерами, прогоняемый перед каждым изменением. На больших проектах — DeepEval, promptfoo, langsmith.

Чек-лист перед production

Системный промпт на русском.
Явное указание языка ответа.
Формат дат, чисел, валюты прописан.
Few-shot примеры на русском, 3-7 штук.
Жёсткая инструкция «не выдумывай / не выходи за документы».
temperature низкая для structured, средняя для creative.
Eval-сет минимум на 20 примеров.
Constrained decoding для JSON-выхода.
Логирование промптов и ответов в production — для разбора инцидентов.

Итог

Русский в LLM — управляемая боль. Системный промпт на русском, few-shot примеры, явный формат, низкая temperature для structured-задач — этого достаточно для 80% корпоративных кейсов. На остальные 20% накладываются файнтюненные под русский модели, constrained decoding, и регулярное тестирование промптов.

В AGmind мы держим библиотеку проверенных шаблонов под типовые задачи — резюме, извлечение из документов, классификация, RAG. Это часть пакета внедрения: не приходится изобретать промпты с нуля.

Связанные тексты: кириллица в LLM, файнтюн под русский, RAG простыми словами, топ-7 ошибок внедрения.