Harness‑IF – как заставить LLM строго соблюдать правила, которые противоречат её «привычкам»

Что это за метод? Исследование Harness‑IF (Zining Huang et al., 2026) показало, что модели хуже выполняют инструкции, если они идут вразрез с их дефолтным поведением. Например: «не используй эмодзи» – правило противоречит привычке вставлять смайлы; «обязательно добавь CTA» – позитивное требование, которое модель часто забывает. Как это работает? 1. Определяем “против‑дефолтные” правила – те, которые меняют привычку модели (буллиты, эмодзи, форматирование и т.п.). 2. Формулируем их как обязательные условия, а не пожелания: «НЕ используй эмодзи» → «Это активный запрет». 3. Приводим пример нарушения – чтобы модель увидела, что такое правило выглядит иначе. 4. Для позитивных требований (do X) добавляем проверку перед финальным ответом: «Проверь, есть ли CTA».

Шаги применения № 1 – Составляем список правил. Что делаем: разделяем на “против‑дефолтные” и “позитивные”. № 2 – Для каждого против‑дефолтного пишем: • Обязательное условие • Пример нарушения (уточняем, что это не пожелание). № 3 – Добавляем проверку для позитивных требований (do X) в конце промпта. № 4 – Публикуем промпт в формате «шаблона» – готовый к копированию. Пример шаблона: # Инструкции для LLM 1️⃣ **Против‑дефолтные правила** (обязательные, с примером нарушения): • НЕ используй эмодзи в тексте. ❌ Неправильно: «Запустили новую фичу 🚀» ✔️ Правильно: «Запустили новую фичу. » • Не применяй буллиты к спискам. ❌ Неправильно: • Пункт 1 ✔️ Правильно: Пункт 1 2️⃣ **Позитивные требования** (должны быть выполнены, но легко забываются): • ОБЯЗАТЕЛЬНО заканчивай пост призывом к действию (одна строка). 🔍 *Проверь перед отправкой*, что CTA присутствует. 3️⃣ При конфликте между правилами из пунктов 1 и 2 – приоритет у пункта 1.

Границы применимости • Когда полезно – автоматизация копирайтинга, генерация кода с фиксированными форматами. Когда не стоит – чат‑боты без «tool/skill» описаний (тут нет прямого аналога). • Когда полезно – сценарии, где важна точность соблюдения формата. Когда не стоит – модели, которые уже обучены строго соблюдать правила без дополнительных инструкций. • Когда полезно – коммерческие сервисы с SLA по качеству ответов. Когда не стоит – небольшие задачи, где правило не критично.

Ограничения и риски Субъективность дефолта – определение «против‑дефолтного» может отличаться у разных моделей. Переобучение – слишком строгий набор правил может замедлить генерацию или вызвать “застревание”. Непредсказуемость конфликтов – если правило противоречит другому, модель всё равно может выбрать «плохой» вариант (особенно при отсутствии явной проверки).

Ключевые выводы • Против‑дефолтные правила → падение точности на 4–7 % – Что это значит для практики: формулируйте их как обязательства + пример нарушения. • “Do X” забываются в 77 % нарушений, “Don’t Y” – только 21 % – Что это значит: добавляйте проверку перед финальным ответом для позитивных требований. • Приоритет не зависит от позиции текста – Что это значит: устанавливайте явный приоритет (пункт 1 > пункт 2).

Исследование номер 2608.11727 Поддержать проект донатом: Сбер 2202 2084 9881 5282. Заранее спасибо.