4-Stage Harness Pipeline: структура промпта важнее размера модели

Все четыре этапа — в одном промпте, одном запросе к модели:

ЭТАП 1 → ПЛАН: разобрать задачу, явно перечислить ВСЕ ограничения

ЭТАП 2 → ИСПОЛНЕНИЕ: выполнить задачу по плану

ЭТАП 3 → ПРОВЕРКА: сверить результат с каждым ограничением из плана 
          → вывести [✓/✗] по каждому пункту

ЭТАП 4 → ИСПРАВЛЕНИЕ: если есть ✗ — переделать, учитывая ошибки,
          повторить проверку → вывести финальный результат

Задача: Написать рекламный пост для Telegram-канала Павла Комаровского (инвест-блогер с аудиторией 200к+). Жёсткие требования: ровно 280–320 символов, без эмодзи, без восклицательных знаков, с конкретным призывом перейти по ссылке. Тема — запуск курса по формированию личного портфеля.

Промпт:

Выполни задачу строго в 4 этапа:

**ЭТАП 1 — ПЛАН**
Разбери задачу. Явно перечисли все ограничения. 
Для каждого ограничения — как именно будешь его соблюдать.

**ЭТАП 2 — ИСПОЛНЕНИЕ**
Напиши рекламный пост для Telegram-канала об инвестициях. 
Тема: запуск курса по формированию личного портфеля. 
Требования: 280–320 символов, без эмодзи, без восклицательных 
знаков, с призывом перейти по ссылке.

**ЭТАП 3 — ПРОВЕРКА**
Проверь готовый текст против каждого ограничения из плана:
[✓/✗] символов в диапазоне 280–320 — реальное количество: ...
[✓/✗] без эмодзи
[✓/✗] без восклицательных знаков
[✓/✗] есть призыв перейти по ссылке

**ЭТАП 4 — ИСПРАВЛЕНИЕ**
Если есть ✗ — перепиши текст с учётом нарушений и повтори проверку.
Если все ✓ — выведи "ФИНАЛЬНЫЙ РЕЗУЛЬТАТ:" и покажи готовый текст.

Результат: Модель выведет все четыре этапа последовательно. В плане явно зафиксирует, что 280–320 символов — это не "примерно треть экрана", а конкретное число, которое нужно посчитать. В проверке покажет реальный счётчик по каждому пункту. Если символов окажется 340 — сама сократит в этапе исправления и перепроверит. На выходе — текст, прошедший самопроверку.

Слабость модели — она не держит ограничения "в уме" в процессе генерации. Когда просишь написать "300 символов", модель не считает посимвольно — она генерирует текст по ощущению, ориентируясь на паттерн. Итог: то 240, то 380, и каждый раз по-разному.

Сильная сторона модели — хорошо следовать явным пошаговым инструкциям и проверять конкретные правила, когда проверка вынесена в отдельный этап с чётким форматом вывода. Когда "посчитай символы" — это не часть главной задачи, а отдельный шаг, точность резко растёт.

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

Рычаги управления: - Этап плана — попроси явно написать число символов/слов рядом в плане → это усиливает якорь для исполнения - Уровень детализации проверки — добавь реальное значение: ... в каждый пункт → модель посчитает, а не угадает - Число итераций — добавь "повтори исправление до 2 раз, если ✗ остаются" → для упрямых ограничений - Убери этап плана → для простых задач без числовых ограничений, экономишь токены

Выполни задачу строго в 4 этапа:

**ЭТАП 1 — ПЛАН**
Разбери задачу. Явно перечисли все ограничения по пунктам.
Для каждого ограничения укажи, как именно будешь его соблюдать.

**ЭТАП 2 — ИСПОЛНЕНИЕ**
{задача с полным описанием всех требований}

**ЭТАП 3 — ПРОВЕРКА**
Проверь результат против каждого ограничения из плана.
Формат проверки:
[✓/✗] {ограничение 1} — фактическое значение: ...
[✓/✗] {ограничение 2} — фактическое значение: ...
[✓/✗] {ограничение N} — фактическое значение: ...

**ЭТАП 4 — ИСПРАВЛЕНИЕ**
Если есть ✗ — перепиши результат с учётом нарушений.
Повтори проверку в том же формате.
Если все ✓ — выведи "ФИНАЛЬНЫЙ РЕЗУЛЬТАТ:" и покажи готовый текст.

Плейсхолдеры: - {задача с полным описанием всех требований} — сама задача + все ограничения полным текстом (лимиты символов/слов, запрещённые элементы, обязательные элементы, тон, формат) - {ограничение 1...N} — в этапе проверки перечисли те же ограничения из задачи, но в формате чеклиста

🚀 Быстрый старт — вставь в чат:

Вот шаблон 4-этапного промпта для надёжного выполнения задач 
с жёсткими ограничениями. Адаптируй под мою задачу: {твоя задача}.
Задавай уточняющие вопросы, чтобы заполнить все поля.

[вставить шаблон выше]

LLM спросит: какие ограничения у задачи (числовые лимиты, запреты, обязательные элементы) и что считать успешным результатом — потому что этапу проверки нужны конкретные критерии, иначе чеклист будет пустым. Она возьмёт структуру из шаблона и адаптирует под твою задачу.

⚠️ Числовые лимиты — частично: Точный подсчёт символов остаётся слabым местом. Даже с полным pipeline модель может ошибиться в подсчёте при тексте более 400–500 символов. Результат улучшается, но не гарантирован.

⚠️ Избыточно для простых задач: На задачах без ограничений ("переведи текст", "объясни термин") 4 этапа — лишние токены и время. Метод раскрывается на многошаговых задачах с жёсткими требованиями.

⚠️ Полумеры опасны: Добавить только теги или только проверку без плана и исправления — хуже чем не добавлять ничего. Либо полная структура из четырёх этапов, либо обычный прямой промпт.

⚠️ Галлюцинации не лечит: Если модель придумывает факты — структура не поможет. Harness фиксирует формат и ограничения, но не фактическую точность.

Исследователи взяли три небольшие модели (Gemma4 2B, Qwen3.5 2B, LLaMA 3.2 3B), 24 задачи шести типов и прогнали через три условия: голый промпт, промпт в тегах и полный 4-этапный pipeline. Идея была проверить, можно ли маленькую модель сделать надёжной без апгрейда — только за счёт структуры.

Самый яркий результат — LLaMA 3.2 без структуры справилась только с 43% задач (9 из 21), при этом почти весь контент был правильным — просто формат разваливался. Добавили teги — результат стал 81%, добавили полный pipeline — 76%. Здесь же обнаружили нелинейный эффект: минимальная структура (только теги) стабильно хуже полного отсутствия структуры у двух моделей из трёх. Это неожиданно и важно.

Аблационный анализ показал: планирование и восстановление вносят примерно по 25% каждый от общего прироста. Причём планирование работает проактивно — оно якорит числовые ограничения ещё до генерации. Без этапа плана модель при задаче "200 символов" выдала 248; с планом — 193. Механизм восстановления работает реактивно — три задачи, которые тайм-аутились во всех других условиях, были решены через повторную попытку с описанием ошибки.

Описание трёх условий (Table I — pipeline vs. ablation):

(A) model-only: Raw prompt with task description only. No structural wrapper.

(B) minimal-shell: Task wrapped in [TASK START] / [OUTPUT] tags. 
No execution flow.

(C) 4-stage pipeline: Plan → Execute → Verify → Recover. 
Recovery re-runs (up to 2 retries) with error feedback 
on verify failure or timeout.

Ablation:
pipeline-no-plan:    Execute → Verify → Recover
pipeline-no-verify:  Plan → Execute
pipeline-no-recover: Plan → Execute → Verify (verdict only)

Контекст: Это описание трёх harness-условий, которые прогоняли через все модели и задачи. Ablation показывает вклад каждого этапа при его удалении.

Если задача содержит числовое ограничение (слова, символы, пункты, абзацы) — вынеси его в план отдельной строкой с формулой:

**ЭТАП 1 — ПЛАН**
Задача: {задача}

Числовые ограничения и как буду соблюдать:
- Лимит: {N} слов → буду считать слова после написания, 
  целевой диапазон {N-5}–{N} слов
- Запрещённые элементы: {список} → проверю каждый явно
- Обязательные элементы: {список} → включу в план исполнения

Исследование показало: без явного якоря в плане задача "200 символов" даёт 248 символов. С якорем — 193. Разница не в модели, а в том, зафиксировала ли она ограничение как рабочий критерий до генерации.

Стандартная проверка [✓/✗] не более 300 символов позволяет модели угадать. Добавь обязательное поле с реальным значением:

**ЭТАП 3 — ПРОВЕРКА**
[✓/✗] Символов не более 300 — посчитал: ... символов
[✓/✗] Нет эмодзи — нашёл: (перечисли или "не найдено")
[✓/✗] Есть призыв к действию — цитата: "..."

Когда модель вынуждена написать реальное число, а не просто поставить галочку — точность проверки резко растёт. VCR (доля пойманных ошибок) в оригинальном исследовании = 62.5%; с явными счётчиками должно быть выше.

Для сложных задач, где важно понять причину ошибки, а не просто переделать:

**ЭТАП 4 — ДИАГНОСТИКА И ИСПРАВЛЕНИЕ**
Для каждого ✗ из проверки:
- Причина нарушения: ...
- Что именно изменю: ...
- Переписанный фрагмент: ...

[Затем полный итоговый текст с исправлениями]

Это не ускоряет задачу, но даёт понять почему модель нарушила ограничение. Полезно, если одну и ту же задачу выполняешь регулярно и хочешь улучшить промпт.

Исследование обнаружило нелинейный эффект: минимальная структура стабильно хуже её полного отсутствия. Это применимо за пределами pipeline:

• Добавил роль ("ты — эксперт"), но не дал контекст и критерии → можно получить хуже, чем без роли
• Добавил "выведи в JSON", но не описал схему → модель придумает структуру сама, иногда кривую
• Добавил "думай шаг за шагом", но не указал что именно — шаги → пустые рассуждения вместо анализа

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

• Статья: "It's Not the Size: Harness Design Determines Operational Stability in Small Language Models"
• Автор: Yong-eun Cho, KailosLab, Сеул, Южная Корея (kevin@kailoslab.com)
• Ссылки из исследования: Reflexion [arXiv:2303.11366], ReAct [ICLR 2023], CRITIC [arXiv:2305.11738], Ollama [github.com/ollama/ollama]