3,583 papers

Меню

arXiv:2605.20809 79 20 мая 2026 г. FREE

Iterative Moderation Framework: самоисправляющиеся инструкции для LLM через трёхшаговый анализ ошибок

КЛЮЧЕВАЯ СУТЬ
Если LLM раз за разом ошибается в одном месте — это не модель тупит, это инструкция неполная: там, где правило не прописано явно, модель заполняет пробел сама — по своим дефолтным паттернам, которые редко совпадают с вашими. Iterative Moderation Framework позволяет находить и закрывать такие пробелы без ручной переписки промпта: три запроса — и тип ошибки пропадает. Фишка: дай модели неверные и верные примеры рядом — она сама описывает паттерн лучше, чем вы его сформулируете. Дальше генерирует IF/THEN-правило с явным исключением и встраивает его в инструкции, не ломая то, что работало. Одни только детальные инструкции поднимают качество с F1 0.4 до 0.7 — и это стартовая точка, итеративная правка добавляет сверху.
Адаптировать под запрос
⚡

TL;DR

LLM делает одни и те же ошибки при выполнении задач с конкретными правилами — не потому что не понимает задачу, а потому что в инструкциях есть скрытые пробелы. Iterative Moderation Framework — техника, которая использует саму LLM, чтобы найти эти пробелы и закрыть их через трёхшаговый анализ: объяснение паттерна ошибки → генерация правила → встраивание правила в инструкции.

Главная находка: детальные инструкции в промпте дают резкий прирост качества — модель без гайдлайнов выдаёт F1 ~0.4, с гайдлайнами ~0.7. Это разрыв в полтора раза. Дальнейшая итеративная правка гайдлайнов добавляет ещё +0.01–0.03 F1 — небольшой, но стабильный прирост. Второй инсайт: reasoning-модели (o3, Gemini с максимальным thinking, DeepSeek Reasoner) заметно лучше следуют сложным инструкциям, чем обычные. Если задача требует строгого соблюдения правил — используй именно их.

Суть метода: когда LLM нарушает ваши правила, вы не переписываете промпт вручную — вы просите саму LLM найти паттерн ошибки, сформулировать корректирующее IF/THEN-правило и встроить его в существующие инструкции. Три шага, три отдельных запроса, цикл повторяется до тех пор, пока ошибки не прекращаются.

🔬

Схема метода

ШАГ 0 (Подготовка): Пишем базовые инструкции + собираем примеры правильных ответов

ШАГ 1 (Аннотация): Даём LLM задачу + текущие инструкции → получаем ответы
ШАГ 2 (Оценка): Сравниваем с правильными примерами → выписываем ошибки одного типа

↓ Если ошибок нет или они не уменьшаются — стоп

ШАГ 3А (Объяснение паттерна):
  Вход: неправильные примеры + правильные примеры
  Действие: LLM ищет закономерность «чем ошибочные отличаются от правильных»
  Выход: описание паттерна ошибки

ШАГ 3Б (Генерация принципа):
  Вход: паттерн из 3А + текущие инструкции
  Действие: LLM формулирует IF/THEN-правило с явными исключениями
  Выход: одно правило в структурированном виде

ШАГ 3В (Уточнение инструкций):
  Вход: правило из 3Б + текущие инструкции + примеры того, что работало правильно
  Действие: LLM встраивает правило, не ломая остальное
  Выход: обновлённые инструкции

→ Возврат к ШАГУ 1 с обновлёнными инструкциями

Все шаги — отдельные запросы в одном чате. Шаги 3А, 3Б, 3В можно делать последовательно за один сеанс.

🚀

Пример применения

Задача: Редактор маркетплейса Ozon настраивает LLM, чтобы та классифицировала отзывы покупателей по трём категориям: «Качество товара», «Логистика», «Работа продавца». Базовый промпт работает неплохо, но категорию «Работа продавца» LLM постоянно путает с «Логистикой» — когда покупатель пишет об опоздавшей доставке, которую обещал продавец.

Промпт:

Три запроса подряд:

Запрос 3А — Объяснение паттерна:

Я классифицирую отзывы покупателей по трём категориям: «Качество товара», 
«Логистика», «Работа продавца».

Ниже — примеры, где классификация НЕВЕРНА (предсказано → правильно):

НЕВЕРНЫЕ:
- «Продавец обещал доставку за 3 дня, прошло 10 дней» → [Логистика], должно быть [Работа продавца]
- «На сайте продавца написано — есть в наличии, прислали через месяц» → [Логистика], должно быть [Работа продавца]

ВЕРНЫЕ (для сравнения):
- «Курьер потерял посылку» → [Логистика] ✓
- «Продавец не отвечает на вопросы» → [Работа продавца] ✓
- «Товар пришёл помятым из-за плохой упаковки службы доставки» → [Логистика] ✓

Сравни два набора. Найди, какой паттерн отличает ошибочные случаи от верных. 
Опиши одним абзацем: что именно является признаком неверной классификации.

Запрос 3Б — Генерация принципа:

Паттерн ошибки (из предыдущего анализа): {вставить вывод из 3А}

Текущая инструкция по классификации: {вставить текущие инструкции}

Сформулируй одно корректирующее правило в формате:
ЕСЛИ [условие]
ТО [действие — к какой категории относить]
КРОМЕ КОГДА [условие-исключение]

Правило должно быть абстрактным, не привязанным к конкретным словам из примеров.

Запрос 3В — Уточнение инструкций:

Вот мои текущие инструкции для классификации отзывов:
{вставить текущие инструкции}

Новое правило, которое нужно добавить:
{вставить правило из 3Б}

Примеры, которые должны классифицироваться верно и после изменений:
{вставить несколько заведомо правильных примеров}

Добавь новое правило в инструкции так, чтобы:
1. Сохранить структуру и формулировки оригинала
2. Ни один из примеров выше не сменил категорию
3. Вывести полный текст обновлённых инструкций

Результат: После 3А модель опишет конкретный паттерн — например, «ошибочные случаи содержат обещание продавца, а не факт действий службы доставки». После 3Б получишь чёткое IF/THEN-правило с исключением. После 3В — полные обновлённые инструкции с встроенным правилом. При повторном запуске классификации с новыми инструкциями этот тип ошибки должен исчезнуть или сократиться.

🧠

Почему это работает

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

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

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

Рычаги управления: - Размер набора ошибок — 5–15 примеров достаточно. Слишком много → модель теряет фокус на одном паттерне - Тип ошибок — работайте с одним типом за итерацию. Смешивать разные паттерны → размытое правило - Примеры правильных ответов в 3В — чем больше, тем безопаснее: защищаете уже работающее от случайной поломки - Reasoning-режим — для сложных инструкций с множеством правил используй o3, Gemini с максимальным thinking или DeepSeek Reasoner: они точнее следуют многоуровневым условиям

📋

Шаблон промпта

📌

3А — Объяснение паттерна

Я выполняю задачу: {описание задачи}.

Критерии классификации/оценки: {краткое описание критериев}

Ниже — примеры НЕВЕРНЫХ результатов (что сделала LLM → что должно быть):
{список 5-10 неверных примеров с контекстом}

Ниже — примеры ВЕРНЫХ результатов (для сравнения):
{список 5-10 верных примеров}

Сравни два набора контрастно. Найди один паттерн: чем случаи, где возникает ошибка, 
отличаются от случаев, где всё верно. 
Опиши паттерн одним абзацем — конкретно, без общих слов.
📌

3Б — Генерация принципа

Паттерн ошибки: {вставить вывод из 3А}

Мои текущие инструкции: {вставить инструкции}

Сформулируй одно корректирующее правило в формате:
ЕСЛИ [условие — признак, по которому можно распознать случай]
ТО [точное действие — что делать]
КРОМЕ КОГДА [условие, при котором правило не применяется]

Требования:
— Правило должно быть абстрактным (не привязанным к словам из примеров)
— Явно укажи исключение, чтобы не создать новых ошибок
— Одно правило, не список
📌

3В — Уточнение инструкций

Мои текущие инструкции:
{вставить полные инструкции}

Новое правило для добавления:
{вставить правило из 3Б}

Контрольные примеры — они должны давать ПРАВИЛЬНЫЙ результат и до, и после правки:
{список 5-7 заведомо верных примеров с ожидаемым результатом}

Добавь новое правило в инструкции:
— Сохрани структуру, формулировки и стиль оригинала
— Ни один контрольный пример не должен изменить результат
— Выдай полный текст обновлённых инструкций без сокращений

Плейсхолдеры: - {описание задачи} — что классифицирует/анализирует LLM (отзывы, договоры, тексты) - {описание критериев} — ваши текущие категории или правила - {список примеров} — конкретные примеры с контекстом (хватит 5–10 на итерацию) - {полные инструкции} — весь текущий промпт с правилами

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

Вот шаблоны трёхшагового метода Iterative Moderation Framework для улучшения 
инструкций через анализ ошибок. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.

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

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

⚠️

Ограничения

⚠️ Задачи с субъективными критериями: Метод работает там, где есть "правильный ответ". Для задач "насколько хорош текст" или "нравится ли мне тон" — паттерн ошибки не найти, правило IF/THEN не сформулировать.

⚠️ Слабые модели: Исследование показало, что у небольших или менее мощных моделей итерации не дают стабильного улучшения — они нарушают уже работающие правила при добавлении новых. Метод лучше работает с топовыми моделями.

⚠️ Маленький прирост после первой итерации: Самый большой скачок качества — от "без инструкций" к "с инструкциями". Каждая следующая итерация правки добавляет меньше. Не ждите радикальных улучшений после 3–4 циклов.

⚠️ Нужны примеры правильных ответов: Для поиска паттерна нужны конкретные примеры "что должно получиться". Без них ни 3А, ни 3В не работают корректно.

🔗

Ресурсы

Работа: Refining and Reusing Annotation Guidelines for LLM Annotation

Авторы: Kon Woo Kim, Jin-Dong Kim, Akiko Aizawa

Университеты: The Graduate University for Advanced Studies (SOKENDAI), National Institute of Informatics (NII), National Institute of Genetics (NIG) — Япония

Код и данные: github.com/KonWooKim/llm-guideline-moderation

Датасеты: NCBI Disease, BC5CDR, BioRED (биомедицинская разметка)

📋 Дайджест исследования

Ключевая суть

Если LLM раз за разом ошибается в одном месте — это не модель тупит, это инструкция неполная: там, где правило не прописано явно, модель заполняет пробел сама — по своим дефолтным паттернам, которые редко совпадают с вашими. Iterative Moderation Framework позволяет находить и закрывать такие пробелы без ручной переписки промпта: три запроса — и тип ошибки пропадает. Фишка: дай модели неверные и верные примеры рядом — она сама описывает паттерн лучше, чем вы его сформулируете. Дальше генерирует IF/THEN-правило с явным исключением и встраивает его в инструкции, не ломая то, что работало. Одни только детальные инструкции поднимают качество с F1 0.4 до 0.7 — и это стартовая точка, итеративная правка добавляет сверху.

Принцип работы

Три шага за одну сессию. Собери 5-10 неверных и 5-10 верных примеров → попроси LLM найти, чем одни отличаются от других. Получишь не «иногда путает похожие случаи», а «путает X с Y, когда в тексте есть признак Z». Паттерн → IF/THEN-правило с явным условием «КРОМЕ КОГДА»: абстрактное, не привязанное к конкретным словам из примеров. Правило → встраивание в инструкции с обязательными контрольными примерами — они страхуют от случайной поломки уже работающего. Один тип ошибки за итерацию: смешивать разные паттерны в одном цикле — значит получить размытое правило, которое не поможет ни там, ни там.

Почему работает

LLM хорошо делает одно конкретное действие — контрастный анализ: «что есть у неверных примеров и чего нет у верных». Это именно то, что нужно для диагностики пробелов в инструкции — задача, с которой человек справляется хуже, потому что смотрит на ошибки по одной, а не рядом. Три отдельных запроса нужны потому, что поиск паттерна, абстрагирование до правила и встраивание без разрушений — разные типы рассуждений. Один запрос «найди проблему и почини» даёт размытое правило или ломает то, что работало. Для задач со сложными многоуровневыми условиями — используй reasoning-модели (o3, Gemini с максимальным thinking, DeepSeek Reasoner): исследование показало, что они заметно точнее следуют инструкциям, чем обычные.

Когда применять

Задачи с конкретными критериями «верно/неверно»: классификация отзывов, разметка данных, проверка текстов по правилам стиля, модерация контента, оценка соответствия требованиям — особенно когда один и тот же тип ошибки повторяется снова и снова. НЕ подходит для субъективных задач — «насколько хорош этот текст» или «нравится ли мне тон»: без правильного ответа паттерна ошибки не найти и правило IF/THEN не сформулировать.

Мини-рецепт

1. Собери ошибки одного типа: 5-10 примеров, где модель ошиблась — выбери один паттерн, не мешай разные. Рядом — 5-10 примеров, где всё верно.
2. Запрос на паттерн (шаг 3А): дай оба набора и попроси найти, чем неверные отличаются от верных. Получи конкретное описание — не общее, а с указанием признака.
3. Запрос на правило (шаг 3Б): паттерн + текущие инструкции → попроси сформулировать одно правило в формате «ЕСЛИ — ТО — КРОМЕ КОГДА». Абстрактное, без привязки к словам из примеров.
4. Запрос на встраивание (шаг 3В): правило + полные инструкции + 5-7 контрольных примеров (что работало верно) → обновлённые инструкции. Контрольные примеры не дадут модели сломать уже рабочее.
5. Проверь и повтори: запусти с новыми данными. Тип ошибки пропал — переходи к следующему. Нет — ещё один цикл с тем же паттерном.

Примеры

[ПЛОХО] : Мои инструкции не работают, перепиши их лучше — LLM путает категории «Логистика» и «Работа продавца»
[ХОРОШО] — три запроса подряд: Запрос 3А: Я классифицирую отзывы по категориям: «Качество товара», «Логистика», «Работа продавца». Вот примеры НЕВЕРНЫХ результатов (что дала модель → что должно быть): [5-10 примеров]. Вот ВЕРНЫЕ примеры для сравнения: [5-10 примеров]. Найди один паттерн: чем случаи из неверных отличаются от верных. Опиши конкретно, одним абзацем. Запрос 3Б: Паттерн ошибки: [вставить вывод из 3А]. Мои текущие инструкции: [вставить инструкции]. Сформулируй одно правило: ЕСЛИ [условие] — ТО [действие] — КРОМЕ КОГДА [исключение]. Абстрактное, без привязки к словам из примеров. Запрос 3В: Мои текущие инструкции: [вставить]. Новое правило: [вставить из 3Б]. Контрольные примеры — они должны давать верный результат и до, и после правки: [5-7 примеров]. Добавь правило в инструкции, сохрани структуру оригинала, выдай полный текст.
Источник: Refining and Reusing Annotation Guidelines for LLM Annotation
ArXiv ID: 2605.20809 | Сгенерировано: 2026-05-21 06:26

Проблемы LLM

ПроблемаСутьКак обойти
Правка инструкций вслепую ломает то, что работалоДобавляешь правило для новой ошибки. Старые случаи начинают ломаться. Проблема не в новом правиле — в том, что встраиваешь его без проверки. Инструкция росла, внутренние условия начали конкурировать. Итог: починил одно, сломал другоеПеред встраиванием нового правила собери 5–7 примеров, которые сейчас работают верно. Передай их модели вместе с инструкцией. Прямо скажи: "после правки эти примеры не должны изменить результат". Это защитный барьер от регрессии

Методы

МетодСуть
Трёхшаговый цикл правки инструкций через анализ ошибокКогда модель повторяет одну и ту же ошибку — не переписывай инструкцию руками. Сделай три отдельных запроса. Шаг 1 — ищешь паттерн: даёшь модели 5–10 неверных примеров рядом с верными, просишь найти чем они отличаются. Шаг 2 — формулируешь правило: берёшь паттерн из шага 1 и просишь написать одно правило строго в формате ЕСЛИ [условие] → ТО [действие] КРОМЕ КОГДА [исключение]. Шаг 3 — встраиваешь: даёшь текущие инструкции + правило из шага 2 + контрольные примеры (они не должны измениться). Просишь добавить правило, не трогая остальное. Три шага раздельно — потому что каждый требует разного типа рассуждений: поиск закономерности, абстрагирование, редактирование без разрушения. В один запрос не влезает без потерь. Когда работает: задача с чёткими критериями верно/неверно. Когда не работает: субъективные оценки ("насколько хорош текст"), слабые модели

Тезисы

ТезисКомментарий
Контрастное сравнение вытаскивает паттерн ошибки лучше описанияКогда пишешь "модель ошибается вот здесь" — модель видит только один набор данных. Не понятно что именно триггерит ошибку. Когда даёшь рядом неверные И верные примеры — модель видит разницу. Именно разница и есть паттерн. Механика: контраст изолирует признак, который появляется только в ошибочных случаях и отсутствует в верных. Применяй: всегда клади оба набора в один запрос. Без верных примеров "для сравнения" — поиск паттерна работает хуже
📖 Простыми словами

Refining and Reusing Annotation Guidelines forLLMAnnotation

arXiv: 2605.20809

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

Это как объяснять правила дорожного движения инопланетянину: ты забыл сказать, что на красный свет нужно стоять, потому что для тебя это очевидно. И вот твой гость из космоса радостно таранит грузовик, потому что в инструкции было написано только «жми на газ, когда видишь дорогу». Ты злишься, правишь промпт, но он находит новую лазейку. Метод Iterative Moderation Framework — это способ заставить саму нейросеть поработать над своими ошибками и дописать этот «кодекс правил» так, чтобы в нем не осталось слепых зон.

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

Хотя метод тестировали на разметке данных, этот принцип — универсальное спасение для любого, кто строит сложные системы на базе AI. Будь то чат-бот для поддержки, классификатор юридических документов или генератор контента — везде, где есть риск двойной трактовки, нужно использовать итерации. Вместо того чтобы бесконечно полировать промпт вручную, ты заставляешь систему самообучаться на своих же факапах. SEO для промптов уходит в прошлое, на смену приходит системная отладка логики.

Короче: хватит надеяться на «ум» модели, надейся на структуру инструкций. Если нейросеть ошибается в 20% случаев, значит, твои правила позволяют ей это делать. Используй цикличную модерацию, чтобы превратить слабые места в бетонные правила. Либо ты закроешь эти дыры системно, либо так и будешь тратить время на «удаление галлюцинаций», которые на самом деле являются просто плохим ТЗ. Кто первый внедрит итеративную правку гайдлайнов, тот получит предсказуемый AI, а не генератор случайных ответов.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с