TL;DR
InsClaimBench — это тест, который разбирает профессиональное решение (выплатить страховку или нет и сколько) на четыре уровня: мелкие правила «да/нет» → блоки решения (договор, причина, покрытие) → вердикт → сумма. Оценивается каждый уровень отдельно, а потом проверяется, согласуются ли они между собой. Ещё в тесте есть пары дел, где изменён ровно один факт. Так видно, обновляет ли модель выводы после изменения.
Главная находка: модель хорошо отвечает на мелкие вопросы, но сбивается, когда их надо собрать в цепочку. Один факт она оценивает почти без ошибок, но полностью верно разобрать всё дело удаётся лишь в малой доле случаев. Вердикт «выплатить / не выплатить» выглядит надёжнее, чем есть. Сумма добавляет ещё ошибок. А верный итог нередко получается при неверных промежуточных выводах: модель «угадала» правильно, а рассуждение сломано. Когда в деле меняется один факт, модель часто не обновляет средний уровень (блоки решения) или обновляет его, но не пересчитывает сумму.
Практический вывод для вас: итоговому ответу в многошаговом решении нельзя доверять без проверки промежуточных шагов. Важно и то, что самая частая ошибка не обязательно самая опасная. Чаще всего модель путалась в причинно-следственной цепочке события, а вердикт портили чаще другие блоки: проверка условий договора и покрытие. Метод оценки из статьи можно повторить вручную: разложить решение на правила, сравнить уровни и подменить один факт.
Схема метода
ШАГ 1: Каждое мелкое правило — отдельным запросом (дело целиком + текст одного правила) → Да/Нет
ШАГ 2: Каждый блок решения — отдельным запросом (дело целиком, без правил и без ответов шага 1) → Да/Нет
ШАГ 3: Вердикт «платить / не платить» — отдельным запросом (дело целиком) → Да/Нет
ШАГ 4: Если «платить» — отдельный запрос на сумму → число
ШАГ 5: Контрфактуальная пара — то же дело, где изменён ОДИН факт → повторить шаги 1–4
ШАГ 6: Сравнить уровни: что должно было измениться, что должно было остаться, что реально изменилось
Каждый шаг идёт в отдельном запросе. Модель не видит собственных ответов предыдущих уровней, поэтому уровни не подгоняются друг под друга.
Пример применения
Сильная зона находок — решения из цепочки зависимых проверок, где итог можно разобрать на правила. Слабая зона: оценка в целом, мнение, креатив.
Задача: Вы руководите отделом урегулирования убытков в страховой, которая продаёт КАСКО. Вы внедряете LLM-помощника, который готовит черновик решения по заявлению: платим или отказываем, и какую сумму. Прежде чем пускать его в работу, надо проверить, не врёт ли он в середине цепочки, пока вердикт выглядит правильным. Ниже проверка на одном деле: застрахованный «Хавал Ф7» поцарапан на парковке ТЦ в Казани, у клиента франшиза 30 000 ₽.
Промпт (шаг 2, блок «Причина события»; отдельный запрос, правила и прошлые ответы не прикладываются):
Ты — эксперт по урегулированию убытков КАСКО.
Ниже полное дело. Оцени только один блок решения: «Событие и причинно-следственная связь».
Определи: что произошло, что стало причиной ущерба, есть ли причинная связь
между событием и заявленными повреждениями.
Ответь строго:
БЛОК: Событие и причинность
ВЫВОД: Да / Нет (событие и причина подтверждают страховой случай)
ЦЕПОЧКА: 3–5 коротких шагов от события к повреждениям
<дело>
Полис КАСКО №К-7721, срок действия до 12.03.2026, франшиза 30 000 ₽.
Заявление от 04.02.2026: повреждение переднего бампера и крыла на парковке ТЦ «Кольцо» в Казани.
Схема парковки и видео с камер приложены: на видео другой автомобиль задевает бампер при выезде и уезжает.
Номер скрывшегося автомобиля установлен, ГИБДД оформила справку.
Заключение оценщика: ремонт 118 000 ₽, часть повреждений крыла старые, до страхового случая.
Результат: Модель выдаст короткий вывод Да/Нет по блоку и цепочку из нескольких шагов. Затем вы повторяете запрос для блоков «Договор и право на заявление» и «Покрытие и исключения», вердикта и суммы. Каждый раз запрос отдельный, без ответов предыдущих шагов. Потом делаете копию дела с одним изменённым фактом (например, «срок полиса истёк 01.02.2026») и снова прогоняете цепочку. Сверяете: изменился ли блок «Договор», остались ли без изменений блоки «Причина» и «Покрытие», обнулилась ли сумма. Если вердикт сменился на «отказ», но промежуточные блоки не изменились, это та самая скрытая ошибка. Если вердикт остался верным, а в цепочке блока есть неверный шаг, это ошибка, скрытая верным итогом.
Почему это работает
Слабость: модель не складывает проверки в строгую систему. Когда решение состоит из десятков мелких условий, достаточно ошибиться в одном — и всё дело разваливается. Именно поэтому точность по отдельным правилам высокая, а разобрать всё дело без ошибок удаётся редко. К тому же итог бинарный («платить/не платить»), и модель может угадать его, не пройдя рассуждение честно. Верный ответ скрывает неверную логику.
Сильная сторона: на одном узком вопросе с понятным критерием модель работает хорошо. Если дать ей одно правило и одно дело, ошибок мало.
Как метод это использует: он проверяет модель на её сильной стороне (мелкие вопросы), а потом отдельно проверяет слабую (сборка цепочки). Разделение на уровни показывает, где именно ломается решение. Контрфактуальная пара отвечает на вопрос, который итоговая точность не раскрывает: понимает ли модель, какие выводы должны измениться, а какие остаться.
Рычаги управления: - Число правил и блоков → меньше для простых решений, больше для высокорисковых. - Что скрыто от модели на каждом шаге → если показать ей ответы прошлого уровня, она подстроится и вы не увидите настоящих расхождений. - Какой факт меняете в паре → меняйте по одному, иначе не поймёте, откуда сбой. - Что сравниваете → вердикт и сумму можно проверять только на ключевых уровнях, если нужно сэкономить время.
Шаблон промпта
Это обобщение протокола оценки из статьи. Работает в отдельных сообщениях или отдельных чатах, по одному запросу на каждый уровень.
ЗАПРОС 1 — ПРАВИЛО (повторить для каждого правила)
Ты — эксперт по {область}.
Ниже полное дело и одно правило. Определи, выполняется ли правило.
Ответь строго: ПРАВИЛО: {текст_правила} / ВЫВОД: Да или Нет / ОСНОВАНИЕ: одно предложение с цитатой из дела.
<дело>{текст_дела}
ЗАПРОС 2 — БЛОК РЕШЕНИЯ (повторить для каждого блока; правила и ответы запроса 1 НЕ прикладывать)
Ты — эксперт по {область}.
Оцени только блок «{название_блока}»: {что_проверяет_блок}.
Ответь строго: БЛОК / ВЫВОД: Да или Нет / ЦЕПОЧКА: 3–5 коротких шагов.
<дело>{текст_дела}
ЗАПРОС 3 — РЕШЕНИЕ (без правил и без ответов запросов 1–2)
Ты — эксперт по {область}.
Прими решение: {вопрос_решения}.
Ответь строго: РЕШЕНИЕ: Да или Нет / ОСНОВАНИЕ: до 5 предложений.
<дело>{текст_дела}
ЗАПРОС 4 — СУММА (только если в запросе 3 ответ «Да»)
Ты — эксперт по {область}.
Дело и решение ниже. Рассчитай {что_считаем}.
Ответь строго: СУММА: число / РАСЧЁТ: формула с подстановкой.
<дело>{текст_дела}
<решение>{ответ_запроса_3}
ЗАПРОС 5 — ПАРА (повторить запросы 1–4 на деле с одним изменённым фактом)
<дело>{дело_с_одним_изменённым_фактом}
Что подставлять: {область} — например «урегулирование убытков КАСКО» или «проверка возвратов на маркетплейсе». {название_блока} и {что_проверяет_блок} — 3–4 логических блока вашего решения. Правила берите из своего регламента. {текст_дела} — полное описание, без пересказа. Изменённый факт должен менять один конкретный пункт.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки цепочки решения по методу InsClaimBench. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, из каких проверок состоит ваше решение, какие блоки можно выделить и какой факт логично менять. Это нужно, чтобы разложить решение на уровни и построить пару дел, где меняется ровно одно условие. Она возьмёт структуру из шаблона и подстроит под вашу область.
Ограничения
⚠️ Нет проверенного способа исправления: статья измеряет, где модели ошибаются. Она не проверяет, поможет ли разбиение на шаги или пошаговый запрос. Это уже ваша гипотеза, а не вывод авторов.
⚠️ Дела синтетические: их писала LLM по правилам экспертов, а не взяли из реальных архивов. Эксперты проверили лишь около десятой части и совпали с эталоном не на сто процентов. Реальные дела могут быть запутаннее.
⚠️ Домен и формат: страхование, только текст. Цифры по конкретным моделям нельзя переносить на ваши задачи. Переносится закономерность: мелкие проверки лучше, чем сборка, и итог скрывает ошибки.
⚠️ Ресурсоёмко: полный протокол — это десятки запросов на одно дело. Для массовой проверки нужна автоматизация. Вручную реально проверить выборку.
⚠️ Самая частая ошибка ≠ самая опасная: модель чаще всего путалась в причинной цепочке события, но вердикт ломался чаще из-за ошибок в блоках «Договор» и «Покрытие». Не чините то, что видно чаще всего, не проверив, что влияет на итог.
Как исследовали
Исследователи собрали 3780 страховых дел в 375 семействах: автомобили, имущество и здоровье. В каждом семействе — базовое дело и несколько вариантов, где изменён один факт, так что эталонный ответ меняется предсказуемо. Всего 86 656 мелких «да/нет»-суждений. Эталон строился сверху вниз: эксперты задали правила, по которым мелкие суждения собираются в блоки решения, затем в вердикт и сумму. Дела писала LLM, четыре эксперта независимо проверили около 10% выборки, и совпадение с эталоном оказалось высоким.
Шесть моделей прошли четыре уровня: правила → блоки → вердикт → сумма. Каждый уровень шёл отдельным запросом, без подсказок с прошлого уровня. Дальше сравнивали, как уровни связаны и как меняются ответы на парах «до/после».
Результаты неожиданные. Точность на одном правиле до 95%, но все правила дела верны лишь в 15–37% случаев. Вердикт верен в 74–80%, а вместе с суммой — в 48–73%. Среди дел с верным вердиктом от 48% до 67% содержат хотя бы одну ошибку в правилах, то есть правильный итог получен при неправильной логике. Обратное тоже бывает, но реже. Блок причинной связи события ошибается чаще всего, но вердикт ломается чаще от других блоков. После изменения факта модель не обновила нужный блок в 29–40% случаев, хотя до изменения блок был верен. Даже при верных правилах сумма оказывалась неверной в 9–19% пар.
Практический инсайт: одной метрики итога недостаточно. Нужно смотреть цепочку и проверять модель на парах дел с изменением одного факта.
Ресурсы
- Статья: InsClaimBench: Benchmarking Insurance Claim Adjudication Across the Decision Chain
- Авторы: Linqi Zhang, Chong Qi, Yan Cheng, Wanqing Cao, Yu Liu, Chenwei Lin, Xian Xu
- Организации: Школа компьютерных наук и технологий, Школа экономики (Фуданьский университет); Школа интегральных схем (Нанкинский университет)