TL;DR
PARCEL — это бенчмарк (набор тестов) для проверки утверждений по документу. Модели дают документ целиком и одно утверждение (в юридическом стиле: «суд постановил, что…»). Она должна выбрать одну из трёх меток: подтверждено, опровергнуто или в документе этого нет. Так авторы выясняют, можно ли доверять модели в роли «проверяющего».
Главная находка: модели хорошо ловят прямое противоречие («суд отменил» вместо «суд оставил в силе»), но заметно чаще пропускают отсутствие опоры. Если утверждение звучит правдоподобно и вписано в тему документа, модель отвечает «подтверждено», хотя в тексте этого нет. Опаснее всего выдуманная, но уместная ссылка: на дело или норму, которых в документе нет. Высокая общая точность это скрывает. Одна модель набрала около 80% точности, но «подтвердила» почти половину утверждений, которых в документе нет.
Суть практического вывода: проверка «есть ли в документе опора» — отдельная, более слабая операция, чем «не противоречит ли документ». Оценивать проверяющего нужно по доле ложных «подтверждено», а не по средней точности. И обязательно давать модели честный третий вариант ответа — «в документе нет».
Схема метода
ШАГ 1: Берём полный текст документа (премиса) + ОДНО утверждение (гипотеза)
ШАГ 2: Короткая инструкция: задача + три метки
SUPPORTED / REFUTED / NOT_FOUND
ШАГ 3: Модель выбирает одну метку (один запрос на одно утверждение)
ШАГ 4: Оценка: считаем не только точность,
а долю ложных «подтверждено» отдельно:
— на опровергнутых утверждениях
— на утверждениях, которых в документе нет
Всё это один запрос на утверждение, без цепочек.
Пример применения
Задача: Юрист небольшой компании арендует площадь в торговом центре. Стажёр прислал справку из четырёх тезисов с отсылками к пунктам договора аренды. Юрист хочет быстро понять, какие тезисы не подкреплены договором, до того как пойдёт с ними на переговоры с арендодателем. Тезис вроде «п. 7.4 ограничивает индексацию арендной платы пятью процентами в год» легко звучит правдоподобно, а в договоре такого пункта может не быть.
Промпт:
<Задача>
Проверь утверждение по тексту договора. Опирайся ТОЛЬКО на текст договора ниже.
Не используй общие знания о том, как обычно пишут такие договоры.
<Документ>
[полный текст договора аренды]
<Утверждение>
Пункт 7.4 ограничивает ежегодную индексацию арендной платы пятью процентами.
<Метки>
SUPPORTED — текст договора содержит достаточно оснований, чтобы утверждение было верным.
REFUTED — текст договора прямо противоречит утверждению.
NOT_FOUND — в тексте договора недостаточно информации, чтобы подтвердить или опровергнуть утверждение.
Выбери ровно одну метку. Затем одной строкой объясни выбор.
Проверяй каждое из четырёх утверждений отдельным ответом.
Результат: Модель выдаст по каждому утверждению одну метку и короткое пояснение. Утверждения с неверным исходом или подменённым условием модель с большей вероятностью поймает как REFUTED. Утверждения, которых в договоре просто нет, — зона риска: часть может получить SUPPORTED. Поэтому всё, что получило SUPPORTED, юрист всё равно сверяет по тексту договора.
Почему это работает
Слабость модели. Она читает документ и утверждение вместе и оценивает, насколько они «сходятся по смыслу». Если утверждение написано в стиле документа, использует его лексику и похоже на то, что там могло быть, сходство высокое. Отсутствие факта оставляет «пустое место», а пустое место заметить труднее, чем явное расхождение. К тому же модели склонны соглашаться и достраивать картину. Поэтому «подтверждено» на отсутствующем утверждении встречается чаще, чем «подтверждено» на опровергнутом.
Сильная сторона. Прямые противоречия модель находит уверенно: когда в тексте написано одно, а в утверждении другое, сверка получается чёткой. Лучшие модели справляются почти идеально и с третьей меткой. Это значит, что при хорошей постановке задачи и сильной модели проверка работает.
Что даёт метод. Три явные метки с определением NOT_FOUND превращают расплывчатое «проверь» в выбор из конкретных вариантов. Отдельный подсчёт ложных «подтверждено» показывает слабое место, которое не видно в средней точности. Рычаги: - Определение NOT_FOUND: чем жёстче («достаточно оснований» против «хоть что-то похожее»), тем меньше ложных подтверждений. В статье это не проверялось. - «Опирайся только на документ»: в статье отмечено, что внутренние знания модели могут перебить строгое следование тексту, поэтому запрет на общие знания разумен. - Одно утверждение на запрос: так сделано в бенчмарке. Пачка утверждений в одном запросе в статье не тестировалась.
Шаблон промпта
Точный текст промпта в доступной части статьи не приведён. Авторы описывают его как минимальный системный промпт с задачей и метками. Ниже реконструкция по этому описанию.
<Задача>
Определи, как документ соотносится с утверждением.
Опирайся только на текст документа.
<Документ>
{документ}
<Утверждение>
{утверждение}
<Метки>
SUPPORTED — документ содержит достаточно оснований для утверждения.
REFUTED — документ прямо противоречит утверждению.
NOT_FOUND — в документе недостаточно информации, чтобы подтвердить или опровергнуть.
Выбери ровно одну метку.
Подставляй:
- {документ} — полный текст источника (договор, решение суда, регламент, отчёт);
- {утверждение} — один проверяемый тезис.
Ограничения
⚠️ Текст статьи неполный: в доступной версии нет таблиц с разбивкой по стратегиям подмены и разбора «трудных» утверждений. Вывод про выдуманные цитаты как самую тяжёлую категорию взят из аннотации.
⚠️ Лечение не проверено: авторы измеряют проблему, но не тестируют промпты, которые её уменьшают (цитата-доказательство, самопроверка, несколько проходов). Всё, что в разделе «Адаптации» ниже, — гипотеза.
⚠️ Юридический домен и синтетические утверждения: все подмены генерировала LLM по заданным стратегиям. Реальные ошибки живых людей и моделей могут выглядеть иначе.
⚠️ Документ целиком в контексте: проверялся короткий и средний текст, поданный полностью. Для огромных корпусов, где ещё нужно найти нужный фрагмент, вывод не доказан.
⚠️ Слабые модели: одна из семи моделей показала тяжёлый перекос в сторону «подтверждено» и пропустила почти половину отсутствующих утверждений. Для менее мощных моделей риск выше.
Как исследовали
Авторы взяли 85 свежих решений апелляционного суда штата Нью-Йорк за 2024–2025 годы. Сначала они собрали у реальных юристов около 700 пояснений в скобках к ссылкам (в юридическом тексте так кратко пересказывают суть дела) и отобрали 180 «содержательных» как образцы стиля. Затем по каждому решению сгенерировали утверждения трёх типов: подтверждённые (849), опровергнутые (1698) и «в документе этого нет» (849). Всего получилось 3396. Опровергнутые делали четырьмя способами: подмена сущности, переворот исхода, снятие условия, приписывание решения не тому судье. «Отсутствующие» тоже делали тремя способами: фантомная ссылка, «суд не рассматривал довод» и выдуманная деталь. Ключевая деталь дизайна: подмены генерировали, видя весь текст решения, поэтому они звучат в стиле судьи и тематически уместны.
Затем семь моделей решали задачу без примеров и без хитрых промптов. Лучшая модель дала около 97% точности, почти все остальные выше 90%, а Llama-3.3-70B только 81%. Но авторы ввели отдельную метрику — долю ложных «подтверждено» (FER). Разрыв оказался устойчивым: у GLM-4.7 ложные подтверждения на опровергнутых утверждениях составили 1,18%, а на отсутствующих 9,55%. У Llama доля ложных подтверждений на отсутствующих — 48,76%. По всем моделям вместе 15,4% отсутствующих утверждений были приняты за подтверждённые, а среди опровергнутых — 4,3%.
Удивило, что порядок моделей по точности и по безопасности не совпадает: Kimi чуть точнее GLM, но у GLM меньше ложных подтверждений. Вывод для практики: средняя точность проверяющего скрывает самую дорогую ошибку, поэтому нужно мерить её отдельно.
Адаптации и экстраполяции
🔧 Техника: требовать цитату для SUPPORTED → труднее «подтвердить» воздухом
Добавь в конец шаблона:
Если выбираешь SUPPORTED или REFUTED — приведи дословную цитату из документа, на которой основан вывод.
Если дословной цитаты нет — выбери NOT_FOUND.
Это гипотеза, не из статьи: она не измерена, но направлена именно на найденное слабое место.
Экстраполяция: мини-тест своего проверяющего. Прежде чем доверять промпту-проверяющему на реальной работе, подготовь 15–20 утверждений по одному своему документу. Среди них должны быть и выдуманные, по приёмам авторов.
Вот документ: {документ}.
Составь 18 утверждений для проверки проверяющего:
— 6 верных (разные типы: итог, довод, факт, ссылка на другой акт);
— 6 опровергнутых (подмена стороны, переворот исхода, снятие условия «если», приписывание не тому участнику);
— 6 «в документе этого нет» (несуществующая ссылка на норму, «суд не рассматривал довод X», правдоподобная деталь, которой нет в тексте).
Все должны быть в стиле документа. Выдай список с пометкой верного ответа.
Затем прогони утверждения через свой проверяющий промпт и посчитай, сколько из «нет в документе» получили SUPPORTED. Это и есть мини-версия метрики авторов.
Ресурсы
- Работа: When Citations Mislead? A Claim-Level Benchmark for Legal Hallucination Detection (ICAIL 2026)
- Авторы: M. Mikail Demir, M. Abdullah Canbaz — University at Albany, SUNY
- Датасет: https://github.com/mmikaildemir/PARCEL
- Трекеры судебных галлюцинаций: AI Law Tracker (Polaris Lab), подборка Damien Charlotin
- Связанные работы: Dahl et al. (галлюцинации в юридических LLM), LegalBench, LexGLUE