TL;DR
Coverage Certificate — техника, которая заставляет модель перед выводом «точно нет» проговорить вслух две вещи: что именно охватывает вопрос и что именно охватывают предоставленные данные. Только после сравнения этих двух охватов модель выдаёт финальный вердикт — «точно нет» или «не знаю».
Модели почти всегда слишком уверенно говорят «нет», если не нашли что-то в списке или документе — даже когда этот список неполный. Причина проста: модель молча решает «я не нашёл → значит, этого нет», не проверяя, показали ли ей весь нужный материал. Особенно плохо это работает, когда неполнота данных не сказана прямо, а должна быть понята из контекста — тут модель чаще всего сваливается в ложную уверенность.
Метод переводит эту скрытую (implicit) оценку полноты в явную: модель отдельно называет охват вопроса, отдельно — охват данных, и только затем сравнивает их и решает. Это разбивает один смутный вывод на три чётких текстовых поля.
Схема метода
ШАГ 1: Определить охват вопроса → текстовое описание (весь период? вся коллекция? все разделы?)
ШАГ 2: Определить охват данных → текстовое описание + пометка: полный / частичный
ШАГ 3: Сравнить → покрывают ли данные весь охват вопроса? (да/нет)
ШАГ 4: Финальный вывод → «Точно нет» (если да) / «Не знаю» (если нет)
Все четыре шага выполняются в одном промпте — модель выдаёт структурированный ответ целиком.
Пример применения
Задача: Предприниматель получил от контрагента договор поставки на 12 страниц и хочет проверить, нет ли в нём пункта о праве поставщика в одностороннем порядке менять цену.
Промпт:
Вот текст договора:
{вставить текст договора}
Вопрос: есть ли в этом договоре условие, дающее поставщику право
в одностороннем порядке изменять цену поставки?
Прежде чем ответить, сделай три шага явно:
1. Охват вопроса: определи, что именно я спрашиваю — весь документ
целиком, включая приложения и допсоглашения, или только основной текст?
2. Охват переданных данных: оцени, что именно тебе передано.
Это весь документ или только часть (например, без приложений,
без спецификаций, без допсоглашений)? Отметь: полный охват или частичный.
3. Сравнение: покрывает ли переданный тебе текст весь охват вопроса?
Дай финальный ответ в формате:
- Охват вопроса: ...
- Охват данных: ...
- Вывод: [Такого условия точно нет / Не могу утверждать — данных недостаточно]
Результат: модель выдаст три текстовых поля вместо простого «нет, такого пункта нет». Если в промпт не попали приложения или допсоглашения к договору, модель явно укажет это в поле «Охват данных» и честно ответит «не могу утверждать», а не сделает поспешный вывод об отсутствии условия.
Почему это работает
Модель по умолчанию не проверяет явно, показали ли ей весь материал — она принимает это решение «в фоне» и часто скатывается к упрощённой логике «не нашёл = нет». Это и есть слабость: скрытая оценка полноты легко ошибается, особенно когда неполнота не подписана прямыми словами вроде «это неполный список».
Сильная сторона LLM — она хорошо раскладывает задачу на явные текстовые категории, если её прямо об этом попросить. Она умеет описать словами «что охватывает вопрос» и «что охватывают данные» отдельно, если дать структуру для этого.
Метод использует эту способность: вместо одного смутного решения — три явных текстовых поля, которые заставляют модель сначала описать полноту, а потом уже решить.
Рычаги управления: - Добавь рассуждение (CoT) перед сертификатом — в исследовании комбинация «сертификат + пошаговое рассуждение» давала лучший результат. - Замени финальный вариант «не знаю» на «недостаточно данных, нужен полный документ» — практичнее для реальной работы с документами. - Убери требование «без объяснений» — так видно, где модель ошиблась: в определении охвата вопроса или охвата данных.
Шаблон промпта
Вот данные: {документ_или_список}
Вопрос: {есть ли X в этих данных}
Прежде чем ответить, сделай три шага явно:
1. Охват вопроса: определи, что именно спрашивается — весь период,
вся коллекция, все разделы или только часть?
2. Охват данных: оцени, что тебе передано целиком или частично.
Отметь явно: полный охват или частичный (и почему).
3. Сравнение: покрывают ли данные весь охват вопроса?
Финальный ответ дай в формате:
- Охват вопроса: ...
- Охват данных: ...
- Вывод: [Точно отсутствует / Не могу утверждать — данных недостаточно]
Подставь в {документ_или_список} — текст, файл или список, который проверяешь. В {есть ли X в этих данных} — конкретный факт, наличие которого проверяешь (пункт договора, упоминание в реестре, условие в списке исключений).
🚀 Быстрый старт — вставь в чат:
Вот шаблон Coverage Certificate для проверки отсутствия факта в документе.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой именно документ и какой факт проверяем — потому что без этого она не сможет корректно заполнить поля «охват вопроса» и «охват данных». Она возьмёт структуру шаблона и адаптирует под твой случай.
Ограничения
⚠️ Проблема не исчезает, а смещается: явные промпты и структурированные сертификаты снижают ложную уверенность в «нет», но одновременно повышают лишние «не знаю». Идеального промпта, убирающего обе ошибки одновременно, не существует.
⚠️ Скрытая неполнота — слабое место метода: когда данные неполны, но это не сказано прямыми словами (а видно только по контексту), модель путается чаще всего — даже с сертификатом.
⚠️ Не для критичных решений без проверки человеком: для юридических, медицинских и финансовых выводов метод снижает риск, но не гарантирует правильность — нужна дополнительная проверка.
Как исследовали
Команда собрала бенчмарк CROWN-QA из двух частей. Первая — синтетические пары вопросов, где вопрос и наблюдаемые факты зафиксированы, а меняется только одно: насколько предоставленные данные покрывают запрошенный охват. Вторая — контрастные наборы на реальных документах: индексы конференций ACL Anthology и инструкции к лекарствам DailyMed.
Проверили три модели (Qwen, Gemma, Claude Haiku) на семи разных стратегиях промптинга — от простого вопроса до явных правил, рассуждений и структурированных сертификатов. Измеряли долю ложных «нет» (over-closure) и долю лишних «не знаю» (under-closure).
Главный неожиданный результат: модели без специальных инструкций почти всегда склонны говорить «нет» слишком уверенно — а не наоборот. И даже лучшие промпты не убирают проблему полностью, а просто перераспределяют ошибки между двумя типами. Структурированный сертификат помог диагностировать: чаще всего модель ошибается уже на этапе описания «насколько полны данные», а не на финальном решении.