TL;DR
Модель может дать правильный ответ, но обосновать его неправильными причинами — и обычная проверка "верно/неверно" это не заметит. Исследователи разделили оценку на два слоя: правильность ответа и обоснованность объяснения — и показали, что это разные вещи, которые не совпадают даже у сильных моделей.
Главная находка: когда модели дали инфракрасное изображение, треть правильных ответов держалась на слабых доказательствах — модель ссылалась на форму объекта или отражения света, а не на тепловой сигнал, хотя вопрос был именно про тепло. Хуже: если убрать оригинальное инфракрасное изображение и подсунуть модели "перевод" в обычную картинку, точность ответов почти не падает, а вот обоснованность рушится — модель начинает объяснять ответ visible-light-подсказками вместо тепловых. Причём чем умнее модель, тем сильнее она "переключается" на подмену источника — и это происходит только тогда, когда оригинал недоступен.
Решение — Thermal-Grounded Feedback (TGF): цикл из нескольких ролей-агентов, которые проверяют и переписывают только объяснение, не трогая уже данный ответ. Судья диагностирует дефект по нескольким осям, четыре специализированных агента дают точечный фидбек, ревизор переписывает текст, селектор выбирает лучшую версию.
Схема метода
ШАГ 1 (Judge-агент, один запрос): оценить существующий ответ+объяснение
→ диагноз по 5 осям: тепловая обоснованность, привязка доказательств к региону/объекту,
использование "чужих" визуальных подсказок, калибровка уверенности, итоговая оценка
ШАГ 2 (4 Feedback-агента, параллельно в том же запросе): каждый агент даёт узкую правку
→ Агент-1 (тепло): "добавь тепловое доказательство"
→ Агент-2 (привязка): "укажи конкретный объект, регион, тепловой признак"
→ Агент-3 (карантин): "убери визуальные подсказки, не относящиеся к теплу"
→ Агент-4 (уверенность): "снизь уверенность, если тепловых доказательств мало"
ШАГ 3 (Reviser, тот же или следующий запрос): переписать объяснение с учётом всех 4 правок
→ ответ остаётся ТЕМ ЖЕ, меняется только текст объяснения
ШАГ 4 (Selector): сравнить новую версию со старой по иерархии критериев,
выбрать лучшую, повторить цикл если критерии не пройдены
Все шаги можно выполнить в одном длинном промпте — модель симулирует роли последовательно внутри одного ответа.
Пример применения
Задача: Вы просите Claude или ChatGPT оценить питч-дек стартапа для инвестора — стоит вкладываться или нет. Модель отвечает "не инвестировать", но вам важно понять: обоснование реальное (плохая unit-экономика, нет повторных покупок) или общие фразы ("рынок конкурентный", "команда неопытная" — которые можно приклеить к любому стартапу).
Промпт:
Вот мой предыдущий ответ на вопрос "Стоит ли инвестировать в этот стартап?":
Ответ: Не инвестировать
Обоснование: [вставь текст обоснования, которое дала модель ранее]
Теперь разбери это обоснование как многоагентная проверка:
1. СУДЬЯ: оцени обоснование по 4 параметрам (0-3 балла каждый):
- Опирается ли вывод на конкретные цифры из питч-дека (LTV, CAC, retention),
а не на общие фразы?
- Указан ли конкретный раздел презентации, на который ссылается вывод?
- Есть ли в обосновании "общие штампы", которые не привязаны к данным этого стартапа?
- Калибрована ли уверенность — не завышена ли она при слабых данных?
2. ЧЕТЫРЕ АГЕНТА ПРАВЯТ обоснование, каждый со своей задачей:
- Агент "Цифры": добавь конкретные метрики из презентации в поддержку вывода
- Агент "Привязка": укажи точный слайд/раздел, откуда взят каждый аргумент
- Агент "Карантин штампов": убери общие фразы, не подтверждённые данными
- Агент "Уверенность": скорректируй уверенность вывода под реальную силу доказательств
3. РЕВИЗОР: перепиши обоснование с учётом правок всех агентов. Вывод (инвестировать/нет) НЕ МЕНЯЙ — только обоснование.
4. Покажи финальную версию обоснования.
Результат: Модель выдаст пошаговый разбор — сначала оценку старого обоснования по 4 параметрам, потом реплики каждого из 4 "агентов", затем переписанный текст обоснования, где общие фразы заменены на конкретные цифры и ссылки на разделы презентации. Вывод (инвестировать/не инвестировать) останется прежним — изменится только то, ЧЕМ он подтверждён.
Почему это работает
Модели любят давать красиво звучащее объяснение, даже если оно не связано с реальными фактами задачи. Это происходит потому что модель хорошо предсказывает "как звучит уверенный ответ", но не всегда проверяет, действительно ли она опиралась на нужный источник — особенно если есть более простой, привычный источник-заменитель (визуальная картинка вместо теплового сигнала, общие бизнес-штампы вместо цифр из документа).
Сильная сторона LLM — она умеет критиковать текст по конкретному чек-листу, если этот чек-лист явно прописан. Одна общая инструкция "объясни лучше" смешивает разные типы ошибок и модель чинит что-то одно, забывая остальное.
Метод разбивает критику на узкие роли — каждая ловит свой тип дефекта (нехватка доказательств, неправильная привязка, подмена источника, лишняя уверенность). Это заставляет модель проверять каждый аспект отдельно, а не одной размытой попыткой.
Рычаги управления: - Число feedback-агентов — можно урезать до 2 (например, "точность данных" + "калибровка уверенности"), если задача проще - Критерий отбора у Selector — замени иерархию критериев ("сначала точность, потом привязка...") на свой порядок приоритетов - "Ответ не меняй" — можно убрать это условие, если хочешь, чтобы модель пересмотрела и сам вывод, а не только обоснование
Шаблон промпта
Вот мой предыдущий ответ на задачу: {задача}
Ответ: {итоговый_вывод}
Обоснование: {текст_обоснования}
Разбери это как многоагентную проверку обоснования (сам вывод не трогай):
1. СУДЬЯ: оцени обоснование по параметрам (0-3 балла):
- {критерий_1, например: опирается на конкретные факты, не на общие фразы}
- {критерий_2, например: указан точный источник/раздел}
- {критерий_3, например: нет ли подмены источника доказательств}
- {критерий_4, например: адекватна ли уверенность вывода}
2. АГЕНТЫ правят обоснование, каждый со своей задачей:
- Агент "{название_1}": {что исправляет}
- Агент "{название_2}": {что исправляет}
- Агент "{название_3}": {что исправляет}
- Агент "{название_4}": {что исправляет}
3. РЕВИЗОР: перепиши обоснование с учётом правок. Вывод "{итоговый_вывод}" НЕ МЕНЯЙ.
4. Покажи финальную версию.
Что подставлять: {задача} — исходный вопрос, {итоговый_вывод} и {текст_обоснования} — то, что модель ответила раньше, {критерий_N} и агенты — под конкретный тип ошибок, которые вас волнуют (фактчекинг, привязка к источнику, штампы, уверенность).
🚀 Быстрый старт — вставь в чат:
Вот шаблон многоагентной проверки обоснования ответа. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие именно критерии обоснованности важны для вашей задачи и какие типы ошибок (общие фразы, подмена источника, завышенная уверенность) вы хотите ловить — потому что без этого агенты будут проверять что-то абстрактное, а не вашу конкретную боль.
Ограничения
⚠️ Метод не меняет сам вывод: если ответ модели неправильный по существу, TGF это не исправит — он чинит только обоснование при уже зафиксированном ответе.
⚠️ Нужен эталон "правильного" источника доказательств: метод работает, когда есть чёткое понятие "какой источник валиден" (тепловой сигнал, а не картинка). Если у вашей задачи нет такого чёткого разделения источников — критерии судьи будет сложно сформулировать.
⚠️ Требует несколько раундов диалога: в оригинале это цикл с повторными проверками, что означает несколько обменов с моделью, а не один ответ с первого раза.
Как исследовали
Исследователи взяли 680 вопросов по инфракрасным изображениям и прогнали через 11 мультимодальных моделей (от Gemini и GPT до маленьких открытых моделей), под 5 разными вариантами входных данных — от "только инфракрасное изображение" до "только перевод в обычную картинку без оригинала". Оценивали не только правильность ответа, но и отдельно — обоснованность объяснения, для чего создали "судью" из двух LLM (GPT и Gemini), чью работу дополнительно проверили на 48 примерах, размеченных людьми — совпадение оказалось высоким.
Главный неожиданный результат: чем умнее модель, тем сильнее она "предаёт" тепловые данные, если оригинал недоступен — сильные модели охотнее подменяют доказательства на visible-light-подсказки. Но если оригинал остаётся доступен рядом с переводом — эффект исчезает полностью. Это значит, что дело не в самой RGB-подсказке, а именно в подмене источника данных.
Для проверки метода TGF взяли локальную выборку из 200 примеров на 4 моделях — метод поднял долю "правильный ответ + обоснованное объяснение" (F@C) заметно, при этом точность ответов не изменилась, а количество ошибок парсинга упало почти втрое.