TL;DR
OPT-Kraken — многоэтапная проверка и правка готовых результатов LLM (математическая модель плюс код). Сначала из условия отдельно извлекаются требования и данные. Потом идут пять направленных проверок, и каждая ищет свой тип ошибок. Правка делается по «контракту»: что можно менять, что должно получиться и что трогать нельзя. В конце независимый аудит. Если он не пройден, правка откатывается.
Главная находка: обычная просьба «проверь, исправь, сохрани правильное» ловит только половину ошибок. Более навороченные цепочки (рассуждение по шагам, диагноз, ремонт и аудит) находят больше, но начинают портить правильное: доля испорченных верных ответов вырастает с 0,3% до 8,4%. Причина в том, что модель, которой велели искать ошибки, их находит, даже когда их нет. Есть и второй неприятный факт. Код запускается и число сходится, а модель по условию верна лишь у единиц процентов результатов. «Ответ правильный» не значит «расчёт построен правильно».
Метод решает это жёсткими рамками. Проверка идёт по направлениям, а не «просто посмотри ещё раз». Правка ограничена контрактом. Аудитор судит вердикт независимо. Итог: точность выросла с 44,8% до 64,9%, а порча правильных результатов осталась около 0,6%.
Схема метода
ШАГ 1: Извлечь из условия ТРЕБОВАНИЯ (с цитатами) и ДАННЫЕ (значения, индексы, единицы) → два списка
ШАГ 2: Пять направленных проверок → находки с цитатой-доказательством
условие → модель (всё ли учтено? не перевёрнуты ли знаки?)
модель → условие (нет ли выдуманных переменных и ограничений?)
модель ↔ код (код реализует именно эту модель?)
данные → модель (значения, индексы, единицы на месте?)
данные → код (ключи, массивы, подстановка верны?)
ШАГ 3: Вердикт: CLEAN / ERROR / UNRESOLVED
CLEAN или UNRESOLVED без доказательств → ничего не трогаем
ШАГ 4: Выбор минимального масштаба правки
только код → локальная правка модели + кода → пересборка с нуля (только при доказательстве)
ШАГ 5: Контракт: что можно менять / что читать, но не править / что должно получиться / что защищено
ШАГ 6: Правка строго в рамках контракта
ШАГ 7: Независимый аудит правки → PASS: принять / FAIL: откат к исходнику
В оригинале это несколько отдельных вызовов LLM плюс программные проверки. В чате шаги 1–3 идут одним запросом, а шаги 4–6 вторым. Аудит (шаг 7) лучше делать в отдельном чате.
Пример применения
Задача: Селлер на Ozon попросил ChatGPT собрать калькулятор юнит-экономики: формулы плюс Python-скрипт. Условие: комиссия 12% от цены, логистика 85 ₽ за единицу, возвраты 7% (возвращённый товар не продаётся, логистика не возвращается), закупка 420 ₽. Модель сгенерировала расчёт, скрипт запускается и выдаёт число. Но селлер не уверен, что в формуле возвраты учтены в нужную сторону. Нужно исправить только ошибку и не переписать то, что уже верно.
Промпт (запрос 1, диагностика):
Ты аудитор расчётов. Ты НЕ переписываешь расчёт. Ты ищешь расхождения с условием и доказываешь каждое цитатой.
Селлер Ozon продаёт товар. Закупка 420 ₽/шт. Комиссия 12% от цены продажи. Логистика 85 ₽ за единицу. Доля возвратов 7%: возвращённый товар не приносит выручки, логистика за него не возвращается. Нужно найти цену, при которой маржа с проданной единицы ≥ 20%.
{формулы_модели}
{код_скрипта}
1. Извлеки ТРЕБОВАНИЯ из : каждое с id и дословной цитатой. Ничего не добавляй от себя.
2. Извлеки ДАННЫЕ: числа, единицы, к чему каждое относится.
3. Проведи пять проверок. Для каждой напиши найденные расхождения или "расхождений нет":
- A. Условие → Модель: все ли требования учтены, не перевёрнуты ли знаки и отношения?
- B. Модель → Условие: есть ли в модели что-то, чего нет в условии?
- C. Модель ↔ Код: код реализует именно эту модель?
- D. Данные → Модель: значения и единицы на своих местах?
- E. Данные → Код: подстановка в код верна?
4. Каждая находка: цитата из условия | как сейчас | как должно быть | где находится.
5. Вердикт: CLEAN (ошибок нет) / ERROR (ошибка подтверждена цитатой) / UNRESOLVED (не уверен).
Неуверенность — это UNRESOLVED, а не повод править.
Промпт (запрос 2, правка по контракту):
По найденной ошибке составь КОНТРАКТ и выполни правку.
Можно менять: {только_строки_с_ошибкой}
Читать, но не править: {зависимости_для_проверки}
Ожидаемый эффект: {что_должно_измениться}
Защищено (не трогать): всё остальное — переменные, константы, остальные формулы, структуру кода
Выбери минимальный масштаб: (1) только код, (2) локальная правка формулы и кода, (3) пересборка с нуля — только если локально исправить доказуемо нельзя.
Выдай: исправленные формулы и код + дифф «было → стало». Если дифф выходит за рамки "Можно менять" — остановись и скажи об этом.
Промпт (запрос 3, аудит, в новом чате): Передай условие, исходную версию и исправленную. Попроси проверить соответствие условию, объём правки и сохранность защищённого. Ответ должен быть PASS или FAIL.
Результат: После первого запроса придёт список требований и данных с цитатами, затем разбор по пяти направлениям и вердикт. После второго — контракт и точечная правка с диффом: изменена одна формула, остальное нетронуто. После третьего — PASS, и правку принимаешь, либо FAIL, и остаёшься на исходной версии.
Почему это работает
Слабость LLM. Общая просьба «проверь и исправь» работает плохо в обе стороны. Модель пропускает ошибки (в статье такой запрос «видит» только половину настоящих ошибок). А когда её заставляют копать глубже, она начинает «чинить» верное: любая просьба искать ошибки подталкивает найти хоть что-то. Ещё хуже, что код запускается и число выглядит правдоподобно, а проверять по условию никто не заставляет.
Сильная сторона. Модель хорошо делает узкие задачи с чёткой рамкой: сверить конкретный фрагмент с конкретной цитатой, внести правку в указанную строку, сравнить два текста по списку критериев. Ей легче работать, когда «что сверять» и «что трогать» заданы явно.
Как метод это использует. Он разбивает размытое «проверь всё» на узкие направления, у каждого своя обязанность. Находка без цитаты из условия не считается. Неуверенность не даёт права на правку. Контракт заранее фиксирует границы, а независимый аудит судит результат, а не автора правки. Поэтому ошибки находятся лучше, а верное остаётся нетронутым.
Рычаги управления: - Список направлений проверки → меняй под свою задачу (текст: «факты → источник», «тон → бриф», «цифры → таблица»). - Правило «UNRESOLVED = не трогаем» → убери, если лучше перестраховаться и пусть правит всё сомнительное. Но порча верного вырастет. - Блок «Защищено» → чем конкретнее, тем меньше лишних изменений. - Масштаб правки → ограничь вариантом «только локальные правки», если пересборка не нужна. - Аудит в отдельном чате или другой модели → независимость важнее, чем кажется.
Шаблон промпта
Ты аудитор. Ты не переписываешь работу целиком. Ты находишь расхождения с исходным заданием и доказываешь каждое цитатой.
{условие_задачи}
{формулы_логика_или_описание_решения}
{код_или_расчёт}
1. Извлеки ТРЕБОВАНИЯ из : id, дословная цитата. Ничего не добавляй.
2. Извлеки ДАННЫЕ: значения, единицы, к чему относятся.
3. Проверки (для каждой — находки или "расхождений нет"):
- A. Условие → Модель: всё ли учтено, не перевёрнуты ли знаки и отношения?
- B. Модель → Условие: нет ли выдуманного?
- C. Модель ↔ Код: код реализует именно эту модель?
- D. Данные → Модель: значения, единицы, привязки верны?
- E. Данные → Код: подстановка верна?
4. Формат находки: цитата | как сейчас | как должно быть | где.
5. Вердикт: CLEAN / ERROR / UNRESOLVED. Неуверенность = UNRESOLVED, правок не делай.
Если вердикт ERROR, во втором запросе:
Можно менять: {места_ошибки}
Читать, но не править: {зависимости}
Ожидаемый эффект: {эффект}
Защищено: {всё_остальное}
Выбери минимальный масштаб: (1) только код → (2) локальная правка модели и кода → (3) пересборка с нуля (только с доказательством, что локально нельзя).
Выдай исправленную версию и дифф «было → стало». Если правка выходит за рамки «Можно менять» — остановись.
В новом чате на третьем шаге: «Вот условие, исходная и исправленная версии. Проверь соответствие условию, объём правки и сохранность защищённого. Ответ: PASS или FAIL с причиной».
Что подставлять: {условие_задачи} — исходный текст задачи без пересказа. {формулы_...} и {код_...} — то, что выдала модель. В блок
🚀 Быстрый старт — вставь в чат:
Вот шаблон OPT-Kraken (диагностика + правка по контракту + аудит). Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что считать «условием» и «результатом», какие пять направлений проверок подходят именно тебе, что нельзя трогать при правке. Эти вопросы нужны потому, что метод работает только с чёткими рамками: без границ «защищённого» правка превращается в переписывание.
Ограничения
⚠️ Узкая область: метод проверен только на задачах оптимизации (математическая модель плюс решатель). В других областях принцип переносится, но этого авторы не проверяли.
⚠️ Часть защит в чате не воспроизвести: в оригинале проверка рамок правки, сборка контракта и проверка «изменено только разрешённое» делаются программно. В чате всё это делает сама LLM, а это слабее.
⚠️ Обычный многошаговый разбор без защит вредит: диагноз + ремонт + аудит без контрактов и запрета на правку по неуверенности портил до 8% изначально верных ответов.
⚠️ Простая просьба «исправь, сохрани верное» пропускает много: она обнаруживала ошибки примерно в половине случаев. На одной из моделей она заметно портила верное.
⚠️ Оценка по ответу: точность проверяли по значению целевой функции. Совпавший ответ ещё не значит верно построенную модель: ручной разбор показал, что настоящая верность условию была у единиц процентов исходных результатов.
⚠️ Эффект зависит от слабости генератора: на слабых «нулевых» результатах прирост огромный, у дообученных моделей скромнее (4–9 п.п.).
⚠️ Неполный текст: промпты из приложений не приведены, воспроизведён принцип, а не дословные формулировки авторов.
Как исследовали
Команда из Пекинского университета взяла шесть наборов задач оптимизации: от простых до промышленных. Результаты работы генераторов моделей заморозили и пропустили через пост-обработку. Сравнивали «до» и «после» на одних и тех же парах «условие — модель — код». Генераторов было восемь: четыре конвейера (включая ORMind, OptiMUS, SAC-Opt) и четыре дообученные модели. Чинили тремя разными LLM.
Главная идея дизайна: измерять не только точность, но и вред. Метрик три: сколько неверного спасли, сколько верного испортили, сколько ошибок вообще заметили. Основной результат: точность «нулевых» результатов выросла с 44,8% до 64,9%, спасено 36,9% ошибочных, испорчено лишь 0,6% верных. Конвейеры улучшились на 6–9 п.п., дообученные модели — на 4–9 п.п.
Затем сравнили с базовыми подходами. Простой промпт: спасено 21,3%, но замечено лишь около половины ошибок. Рассуждение по шагам: 25,6% и порча 2,8%. Многоэтапный без защит: 26,7%, но порча 8,4%. На GPT-5.6 Sol простой промпт испортил 6,6% верных, OPT-Kraken — 0%. Неожиданно: больше «умной» проверки без защит даёт больше вреда. Ручная слепая проверка 339 результатов показала, что верность условию выросла с 2,7% до 51,8%.
Адаптации и экстраполяции
🔧 Техника: убрать пересборку → меньше риска. Если не хочешь, чтобы модель переписывала решение, замени пункт (3) в запросе правки на: «Пересборка запрещена. Если локально исправить нельзя, остановись и опиши, чего не хватает». Эффект: порча верного ещё меньше, правки только точечные.
Экстраполяция: принцип контракта в файле инструкций агента. Перенос на Claude Code или Cursor (в статье такого нет):
## Правила правки кода
Перед правкой выпиши: что МОЖНО менять (файлы, функции), что НЕЛЬЗЯ, что должно измениться.
Правь минимально. Если нашёл подозрение без доказательства — сообщи, но не правь.
После правки покажи дифф. Любое изменение вне разрешённого — откати и спроси.
Ресурсы
- «Fix What's Wrong, Keep What's Right: Hallucination Repair for LLM-Based Optimization Modeling»
- Авторы: Jiageng Wu, Chao Shen, Zihan Guo, Junyan Shao, Zongyan Zhang, Jie Song, Zhong Li, Mingyang Sun
- Университеты: Peking University, Zhejiang University, Great Bay University
- Упомянутые работы: OptiMUS, ORMind, SAC-Opt, Chain-of-Experts, SelfCheckGPT, RARR, CRITIC