TL;DR
LLM плохо исправляет себя в пустоте — если просто попросить "проверь и улучши", модель обычно соглашается с собственным текстом. Работает другое: дать ей источник и попросить найти расхождения по категориям. ODR — это трёхшаговая петля самокоррекции, где модель сначала сравнивает свой вывод с исходным документом (Observe), потом анализирует причины каждого расхождения (Diagnose), потом точечно исправляет (Repair).
Главная находка исследования: без внешнего сигнала (то есть без источника для сравнения) LLM не может надёжно самокорректироваться — она просто переформулирует те же ошибки. Это происходит потому что у модели нет "счётчика истины": она оценивает свой текст тем же аппаратом, которым его генерировала. Когда модель теряет иерархию в длинном документе или галлюцинирует детали — она этого не замечает без внешней точки опоры.
Метод решает проблему через явное сравнение с источником на каждом шаге: модель получает и свой результат, и оригинал, и инструкцию "найди расхождения, классифицируй по типу и серьёзности, определи причину, исправь точечно". Цикл повторяется максимум 3 раза или до тех пор, пока одни и те же ошибки не начнут повторяться.
Схема метода
Выполняется последовательными запросами. Можно в одном чате.
ШАГ 1: ИЗВЛЕЧЕНИЕ
Задай исходный запрос → получи первичный результат
ШАГ 2-OBSERVE: НАБЛЮДЕНИЕ (отдельный запрос)
Дай модели: [оригинальный документ] + [результат из шага 1]
Попроси: "Найди расхождения между результатом и источником.
Для каждого укажи тип ошибки и серьёзность (критическая/некритическая)"
→ Список расхождений с классификацией
ШАГ 3-DIAGNOSE: ДИАГНОЗ (в том же запросе или отдельно)
Попроси: "Для каждого расхождения определи причину —
что именно пошло не так при извлечении?"
→ Разбор причин
ШАГ 4-REPAIR: ИСПРАВЛЕНИЕ (отдельный запрос)
Попроси: "Исправь результат, устраняя только выявленные причины —
не переписывай всё заново"
→ Исправленный результат
[Повтори OBSERVE → DIAGNOSE → REPAIR:
• Пока есть критические расхождения
• Но не больше 3 раз
• Стоп — если те же ошибки повторяются второй раз подряд]
Пример применения
Задача: Тебе нужно структурировать требования из большого ТЗ (технического задания) на разработку сайта — 12 страниц, вложенные условия, ссылки на другие пункты, таблицы со штрафами.
Промпт — Шаг 1 (Извлечение):
Вот техническое задание на разработку интернет-магазина.
[вставить текст ТЗ]
Извлеки все требования в структурированный список.
Для каждого требования укажи:
— номер/идентификатор
— тип (функциональное / нефункциональное / дизайн)
— обязательность (обязательное / условное)
— числовые параметры, если есть (сроки, метрики, лимиты)
Промпт — Шаг 2–3 (Observe + Diagnose):
Вот оригинальное ТЗ и вот извлечённый список требований.
[ТЗ оригинал]
[список из шага 1]
Сравни список с оригиналом. Найди все расхождения:
— что пропущено
— что неверно классифицировано
— где потеряна иерархия или связь между пунктами
— где неточно извлечены числа/условия
Для каждого расхождения укажи:
1. Что именно расходится
2. Серьёзность: критическое (влияет на смысл) или некритическое
3. Причина: почему при извлечении произошла ошибка
Промпт — Шаг 4 (Repair):
На основе диагноза исправь список требований.
Исправляй точечно — только выявленные проблемы,
не переписывай то, что уже верно.
Результат: Модель выдаст отчёт о расхождениях с классификацией по серьёзности, затем исправленный структурированный список. Если в ТЗ есть ссылки типа "согласно п. 3.2" — модель их обнаружит как расхождения и либо разрешит, либо отметит как требующие внимания. Типичные ошибки первого прохода — потеря условий ("если клиент..."), неточные числа, слияние двух требований в одно — всё это исправится во втором проходе.
Почему это работает
Слабость LLM при самопроверке. Когда просишь модель "проверь себя" без источника, она оценивает текст тем же способом, которым его породила. Если при генерации она упустила вложенное условие — при самопроверке она его снова не заметит. Это не баг, это структурное свойство: у неё нет внешней точки опоры, только токены в контексте.
Сильная сторона LLM — сравнение. Модель хорошо умеет находить различия между двумя текстами, когда оба явно присутствуют в контексте. Это другая задача — не генерация по памяти, а сравнение двух параллельных потоков. Именно поэтому работает: дай ей оба документа и чёткий вопрос "что расходится?"
Как метод использует это. ODR переключает задачу с "оцени свой вывод" на "найди разницу между двумя текстами". Разбивка на три шага добавляет важное: диагноз причин не даёт модели просто переформулировать ошибку — она должна объяснить почему она возникла, что само по себе направляет исправление точечно, а не пересборкой с нуля.
Рычаги управления: - Количество итераций (3 в оригинале) → уменьши до 1 для простых задач, сэкономишь токены - Классификация серьёзности (критическое/некритическое) → добавь свои категории под задачу: "требует уточнения у клиента", "можно проигнорировать" - Условие остановки (консенсус или повторяющиеся ошибки) → замени на своё: "стоп если нет критических расхождений" - Детализация диагноза → убери шаг Diagnose для простых задач, оставь только Observe + Repair
Шаблон промпта
Шаблон — Шаг 1: Извлечение
Вот {тип документа}: {название или описание}.
{текст документа}
Извлеки {что извлечь} в структурированный формат.
Для каждого элемента укажи: {поля 1}, {поле 2}, {поле 3}.
Шаблон — Шаг 2–3: Observe + Diagnose
Вот оригинальный {тип документа} и вот извлечённый результат.
ОРИГИНАЛ:
{текст документа}
РЕЗУЛЬТАТ:
{вывод из шага 1}
Сравни результат с оригиналом. Найди все расхождения:
— что пропущено или добавлено лишнее
— что неверно классифицировано или структурировано
— где потеряны связи или иерархия между элементами
— где неточно извлечены {числа / условия / ключевые детали}
Для каждого расхождения укажи:
1. Что именно расходится (с цитатой из оригинала)
2. Серьёзность: критическое (меняет смысл) или некритическое
3. Причина: почему при извлечении произошла ошибка
Шаблон — Шаг 4: Repair
На основе диагноза выше исправь результат.
Правило: исправляй точечно — только выявленные проблемы.
Не переписывай то, что уже верно.
Покажи итоговый исправленный {тип результата}.
Что подставлять:
- {тип документа} — договор, ТЗ, регламент, инструкция, отчёт
- {что извлечь} — требования, условия, обязательства, KPI, риски
- {поля} — тип, серьёзность, исполнитель, срок, числовые параметры
- {числа / условия / ключевые детали} — уточни под свою задачу
🚀 Быстрый старт — вставь в чат:
Вот шаблон ODR-петли (Observe–Diagnose–Repair) для извлечения
информации из документов с самокоррекцией.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблоны выше — все три шага]
LLM спросит у тебя тип документа, что именно извлекать и в каком формате нужен результат — потому что ODR-петля работает только когда оригинал и результат сравниваются по одним и тем же критериям. Она возьмёт структуру трёх шагов и адаптирует под твою задачу.
Ограничения
⚠️ Длина контекста: Шаг Observe требует передавать в один запрос и оригинал, и результат одновременно. Для документов длиннее ~15–20 тысяч знаков это может упираться в лимиты контекста — придётся разбивать на секции и делать ODR по кускам.
⚠️ Не серебряная пуля для галлюцинаций в фактах: ODR хорошо ловит структурные ошибки (потеря иерархии, неверная классификация, пропущенные элементы). Для проверки фактической точности числовых данных из памяти модели — слабее, нужна явная цитата из источника.
⚠️ Исходный домен: Исследование проводилось на юридических и регуляторных документах — самых сложных по структуре (глубокая вложенность, перекрёстные ссылки). Для более простых документов польза от полного ODR-цикла будет меньше — одного прохода может хватить.
⚠️ Три итерации — не гарантия: Если модель систематически ошибается в одном типе задачи (например, неправильно интерпретирует условный синтаксис), ODR будет повторять одну и ту же ошибку — метод это предусматривает (условие остановки при повторе), но без ручного вмешательства проблему не решит.
Ресурсы
Название: REGREACT: Self-Correcting Multi-Agent Pipelines for Structured Regulatory Information Extraction
Авторы: Mohammed Ali, Abdelrahman Abdallah, Adam Jatowt — University of Innsbruck, Austria
Ключевые опоры в работе: - Self-Refine (Madaan et al., 2023) — итеративное улучшение через самогенерируемую обратную связь - Reflexion (Shinn et al., 2023) — итеративное исправление через рефлексию - Huang et al., 2023 — "LLM не может самокорректироваться без внешнего сигнала" - ReAct (Yao et al., 2022) — Reasoning + Acting в агентных системах - CRITIC (Gou et al., 2023) — внешняя верификация для самокоррекции