TL;DR
PLD — техника, которая заставляет мощную модель заранее выработать явные правила принятия решений из набора примеров — и упаковать их прямо в системный промпт для любой другой модели. Вместо того чтобы каждый раз рассуждать с нуля через цепочку шагов (Chain-of-Thought), модель получает готовую библиотеку правил и отвечает сразу.
Проблема: когда вы поручаете LLM повторяющуюся задачу — классифицировать заявки, оценивать тексты, принимать решения по похожим кейсам — она каждый раз рассуждает заново. Результаты гуляют: то учитывает один нюанс, то забывает другой. Это не ошибка — у модели просто нет зафиксированного набора правил, только общие знания.
Суть метода: собираешь примеры задачи с правильными ответами → просишь сильную модель вытащить из них явные правила → очищаешь от противоречий → кладёшь в системный промпт. Дальше любая модель работает по этим правилам без долгого рассуждения вслух.
Схема метода
ШАГ 1: Извлечение правил
Для каждого примера (вход + правильный ответ) →
учительская модель выводит абстрактное правило
(без конкретных имён, только логику)
ШАГ 2: Синтез правил
Похожие правила объединяются → удаляется дубляж →
получается чистый единый список
ШАГ 3: Разрешение конфликтов (цикл)
Тестируешь правила на примерах →
находишь ошибки →
просишь модель объяснить причину и уточнить правила →
повторяешь до сходимости
ШАГ 4: Деплой
Итоговый список правил → в системный промпт →
любая модель отвечает zero-shot без рассуждений вслух
Шаги 1–3 — подготовительная работа (один раз). Шаг 4 — постоянное использование.
Пример применения
Задача: Ты — основатель, запускаешь B2B SaaS. Каждую неделю приходит 30–50 входящих заявок от потенциальных клиентов через форму на сайте. Часть — целевые, часть — мусор. Ты уже вручную обработал 40 заявок и знаешь, кому ответил «да», кому «нет» и почему. Хочешь, чтобы следующие заявки фильтровались по твоей логике.
Промпт (Шаг 1 — извлечение правил):
Ты — опытный менеджер по продажам B2B SaaS.
Я дам тебе разобранные заявки потенциальных клиентов.
Для каждой указан текст заявки и моё решение: «целевой» / «нецелевой» / «уточнить».
Твоя задача для каждой заявки:
1. Объясни, почему принято именно это решение (Chain-of-Thought).
2. Сформулируй из этого одно абстрактное правило — без конкретных имён компаний.
Правило должно описывать логику, применимую к любым похожим заявкам.
Заявки:
{список из 20–40 примеров в формате: [текст заявки] → [решение]}
Промпт (Шаг 2 — синтез):
Вот список правил, которые ты извлёк из примеров:
{список правил из шага 1}
Теперь:
1. Объедини дублирующиеся правила в одно.
2. Убери слишком узкие правила, применимые только к одному случаю.
3. Выдай итоговый структурированный список критериев классификации.
Формат: «Целевой: [условия]», «Нецелевой: [условия]», «Уточнить: [условия]».
Промпт (Шаг 3 — разрешение конфликтов):
Вот текущие критерии:
{список из шага 2}
Я проверил их на примерах и нашёл ошибки:
{примеры, где правила дали неверный результат}
Вот примеры с правильным ответом для контекста:
{3–5 примеров с верным решением}
Проанализируй, где правила противоречат друг другу или упускают нюанс.
Уточни правила — без потери правил для редких случаев.
Результат: После 2–3 итераций шага 3 ты получишь готовый системный промпт — чёткий список критериев вместо размытых инструкций. Любая модель (включая дешёвые/быстрые варианты) будет классифицировать новые заявки по твоей логике без долгого рассуждения вслух.
Почему это работает
Слабость LLM: при повторяющихся задачах модель каждый раз формирует логику заново — из общих знаний, контекста, порядка примеров. Нет фиксированных правил — нет стабильности. Два похожих кейса могут решаться по-разному, потому что модель не помнит, как решила первый.
Сильная сторона LLM: модели хорошо следуют явным инструкциям. Если правило написано чётко — «если X и Y, то Z» — модель применяет его последовательно. Чем конкретнее инструкция, тем предсказуемее поведение.
Как PLD использует это: метод переносит всю интеллектуальную работу в подготовительный этап. Вместо того чтобы рассуждать в реальном времени, модель следует заранее скомпилированным правилам. Это как разница между человеком, который решает задачу с нуля каждый раз, и человеком, у которого есть written SOP (стандартная операционная процедура).
Рычаги управления:
- Количество примеров в шаге 1 → больше примеров → правила покрывают больше edge-кейсов; 15–20 примеров достаточно для старта
- Итерации конфликта (шаг 3) → сложные задачи требуют 2–3 итерации, простые — одной
- Уровень абстракции в правилах → слишком конкретные правила (с именами компаний) — переспроси: «убери специфику, оставь логику»
- Формат финального промпта → структурируй как нумерованный список, а не нарратив — модели лучше следуют структуре
Шаблон промпта
Шаг 1 — Извлечение правил:
Ты — эксперт в области {домен задачи}.
Проанализируй следующие размеченные примеры.
Для каждого примера:
1. Объясни пошагово, почему дан именно такой ответ.
2. Сформулируй из этого одно обобщённое правило
(без конкретных имён — только логику).
Примеры:
{список примеров в формате: [входные данные] → [правильный ответ]}
Шаг 2 — Синтез:
Вот правила, которые ты извлёк:
{правила из шага 1}
Объедини дублирующиеся. Убери слишком узкие.
Выдай итоговый список в структурированном виде.
Шаг 3 — Разрешение конфликтов (повторять до стабильности):
Текущие правила:
{правила из шага 2}
Эти примеры правила решили неверно:
{ошибочные примеры с правильными ответами}
Найди противоречия и пробелы. Обнови правила — не теряй покрытие редких случаев.
Шаг 4 — Системный промпт для финальной модели:
Ты — ассистент по {домен задачи}.
При анализе {входных данных} используй следующие правила:
{финальный список правил из шага 3}
Отвечай кратко: {вариант 1} / {вариант 2} / {вариант 3}.
Без пространных объяснений.
Плейсхолдеры:
- {домен задачи} — область (квалификация лидов, оценка заявок, модерация контента)
- {список примеров} — 15–40 пар «вход → правильный ответ»
- {ошибочные примеры} — случаи где промпт дал неверный результат
- {вариант 1/2/3} — категории классификации (например: «целевой / нецелевой / уточнить»)
🚀 Быстрый старт — вставь в чат:
Помоги мне применить технику Prompt-Level Distillation для моей задачи: {твоя задача}.
Задавай вопросы, чтобы собрать нужную информацию.
[вставить шаблон выше]
LLM спросит: какую задачу ты решаешь, сколько примеров у тебя есть и в каком формате — потому что без размеченных примеров (вход + правильный ответ) метод не запускается.
Ограничения
⚠️ Нужны размеченные примеры: Без набора задач с правильными ответами метод не работает. Минимум — 15–20 примеров. Нет данных — нет правил.
⚠️ Динамические задачи не подходят: Если задача требует цепочки вычислений в реальном времени (сложная математика, многошаговая логика со взаимозависимостями) — правила не заменят рассуждение. Метод работает для классификации и принятия решений по паттернам, не для арифметики.
⚠️ Конфликты на сложных задачах: Первая версия правил почти всегда содержит противоречия — особенно для задач с нюансами и граничными случаями. Шаг 3 обязателен, не опционален.
⚠️ Смещение в данных: Если в твоих примерах есть системная ошибка — правила закрепят её. Модель будет добросовестно следовать неверной логике.
⚠️ Рост сложности: По мере усложнения задачи список правил растёт и может начать конфликтовать сам с собой. На очень сложных доменах нужна ручная чистка.
Как исследовали
Команда из Google взяла две задачи принципиально разной сложности. Первая — StereoSet: определить домен стереотипа (пол, раса, профессия, религия) по одному предложению. Простая, почти как сортировка. Вторая — Contract-NLI: определить логическое отношение между условием договора и гипотезой (следует / противоречит / не упоминается). Это уже юридическая логика с языковыми ловушками.
Учитель — Gemini 3 Flash в режиме thinking. Ученик — Gemma-3 4B, модель в 25 раз дешевле и в 80 раз быстрее учителя. Сравнивали с zero-shot и few-shot (5 примеров) как базой.
Самый интересный результат — Gemma-3 4B после PLD сравнялась с Gemini 3 Flash по качеству. Маленькая модель с правильным системным промптом обогнала большую без него. На StereoSet: F1 скакнул с 57% до 90%. На Contract-NLI: с 67% до 83%.
Фаза разрешения конфликтов дала 2.5% прироста на Contract-NLI и почти ноль на StereoSet. Вывод понятный: чем сложнее задача и больше граничных случаев — тем важнее итерации. На простой задаче правила сошлись за 1 проход, на юридической — за 2.
Неожиданная находка: учительская модель сама выиграла от PLD. Когда Gemini 3 Flash работал по систематизированным правилам вместо zero-shot — его точность тоже выросла. То есть явные правила помогают даже мощным моделям.
Адаптации и экстраполяции
🔧 Быстрая версия без итераций:
Если у тебя нет терпения на три шага, сделай слитный запрос:
Вот {N} размеченных примеров задачи {тип задачи}:
{примеры с ответами}
Шаг 1: Для каждого примера — одна строчка с логикой решения.
Шаг 2: Синтезируй из этого список правил, по которым я смогу решать новые случаи.
Исключи дубли. Сохрани редкие случаи.
Финал: структурированный список правил, готовый для системного промпта.
Потеряешь в точности на граничных случаях, но получишь рабочий промпт за 5 минут.
🔧 PLD для редакторской политики:
Вместо бизнес-решений — применяй к контенту. Собери 20 постов/текстов с оценкой «публиковать / редактировать / отклонить». Прогони через PLD — получишь явный редакционный стиль-гайд в виде правил, а не размытое «пиши хорошо».
🔧 Комбинация с Chain-of-Thought для аудита:
После того как модель применила правила и дала ответ, добавь в промпт:
Укажи, какое именно правило из списка привело к этому ответу.
Теперь каждое решение прозрачно и проверяемо — ты видишь не только «нецелевой», но и «правило #4: нет бюджета + нет ЛПР».
Ресурсы
Статья: "Prompt-Level Distillation: A Non-Parametric Alternative to Model Fine-Tuning for Efficient Reasoning"
Авторы: Sanket Badhe, Deep Shah (Google, Mountain View)
Датасеты: Contract-NLI (Koreeda & Manning, 2021), StereoSet (Nadeem et al., 2021)
Смежные методы: Chain-of-Thought (Wei et al., 2022), Distilling Step-by-Step (Hsieh et al., 2023), OPRO (Yang et al., 2024), DSPy (Khattab et al., 2024)