AI-порталAI-портал

Chain-of-Verification (CoVe)

[object Object]

Chain-of-Verification (CoVe) — это техника, в которой модель сначала даёт ответ, затем выделяет проверяемые claims, формулирует к ним проверочные вопросы, отдельно перепроверяет их и только после этого выпускает исправленную финальную версию. В 2026 CoVe удобнее всего воспринимать как self-fact-check loop для factual и claim-heavy задач.

Вместо общей просьбы «проверь себя» модель сначала сама определяет, что именно в её ответе выглядит как факт и что надо проверить отдельно.

Суть в двух словах

CoVe особенно полезен там, где ответ состоит из утверждений, которые можно перепроверить:

  • factual QA;
  • enterprise search;
  • summary документов;
  • аналитические ответы с числами, датами, функциями, правилами;
  • ответы по тарифам, policy и product docs.
ПромптGPT-5 mini
Шаг 1: ответь.
Шаг 2: выдели 3 claims, которые стоит проверить.
Шаг 3: проверь каждый claim отдельно.
Шаг 4: перепиши финальный ответ.

Вопрос: какие enterprise-функции входят в тариф?
Ответ модели

Claims for verification: SSO, audit logs, SCIM. Проверка: SSO — подтверждено, audit logs — подтверждено, SCIM — не подтверждено. Финальный ответ: тариф включает SSO и audit logs; SCIM в доступном контексте не подтверждён.

CoVe сильнее обычной просьбы "проверь ответ", потому что делает объект проверки явным.

Почему CoVe полезнее простого «перепроверь ответ»

Общая инструкция "проверь себя" часто даёт слабый эффект, потому что модель не знает, что именно проверять и по какому критерию. CoVe делает проверку явной:

  1. Сначала появляется draft answer.
  2. Затем из него извлекаются потенциально рискованные claims.
  3. Каждый claim проверяется отдельно.
  4. Только потом создаётся revised answer.

Эта декомпозиция делает self-check более дисциплинированным.

На практике CoVe не столько "заставляет модель сомневаться", сколько организует второй проход как отдельный pipeline с понятными шагами.

Какие claims стоит проверять в первую очередь

Обычно CoVe особенно полезен для:

  • чисел;
  • дат;
  • имён функций и тарифов;
  • причинно-следственных утверждений;
  • категоричных statements вроде "всегда", "входит", "поддерживается", "запрещено".

Самые опасные claims — те, которые:

  • звучат уверенно;
  • легко звучат правдоподобно;
  • критичны для downstream decision;
  • трудно заметить вручную в длинном ответе.

Где техника особенно сильна

Плюсы

  • Снижает hallucination в factual tasks
  • Превращает самопроверку в понятный pipeline
  • Хорошо сочетается с retrieval и citations
  • Удобна для enterprise docs и policy QA

Минусы

  • Увеличивает latency и токены
  • Если модель не заметила слабый claim, она его не проверит
  • Не заменяет внешний фактчекинг
  • Хуже работает на очень свободных креативных задачах

Сильные сценарии:

  • support copilots;
  • enterprise search assistants;
  • product/policy Q&A;
  • RAG summaries;
  • legal/compliance-style documentation assistants.

Слабые сценарии:

  • purely creative tasks;
  • open-ended brainstorming;
  • задачи, где ключевая проблема не factuality, а planning or reasoning path.

CoVe и retrieval

Техника особенно хорошо раскрывается в grounded workflows:

  • retrieved context уже есть;
  • модель отвечает по контексту;
  • затем проверяет, действительно ли её claims поддержаны найденными документами.

Если retrieval плохой, CoVe не исправит фундаментальную проблему, но хотя бы чаще доведёт модель до честного "не подтверждено".

Если revised answer после CoVe часто ослабляет или удаляет claims, это не обязательно плохо. Это признак, что self-check действительно работает, а не просто повторяет исходный ответ.

Когда CoVe чаще всего не срабатывает

У CoVe есть важное слабое место: он проверяет только те claims, которые сам заметил. Если модель не выделила рискованное утверждение на этапе claim extraction, дальше этот участок просто не попадёт в verification loop.

Типовые провалы:

  • заметные factual claims проверяются, а скрытая причинная интерпретация остаётся без проверки;
  • модель подтверждает себя тем же стилем рассуждения, что и в draft;
  • verification questions формулируются слишком общо и не привязаны к evidence.

Поэтому CoVe лучше всего работает там, где claims можно сделать явными и привязать к конкретному контексту, документу или tool result.

Практический production-паттерн

Этот паттерн особенно полезен в:

  • policy assistants;
  • support copilots;
  • product documentation bots;
  • compliance QA.

Что делать с unsupported claims

У CoVe есть важный разворот мышления: неподтверждённый claim не обязательно надо "переформулировать красиво". Иногда правильный ход:

  • удалить его;
  • ослабить формулировку;
  • заменить на "не подтверждено доступным контекстом";
  • запросить дополнительные данные.

Это особенно важно для enterprise и regulated сценариев, где false confidence хуже, чем осторожный ответ.

Примеры

Product docs QA

ПромптClaude Sonnet 4.6
Ответь по документации. Затем выдели claims и проверь, какие из них прямо подтверждены retrieved context.
Ответ модели

После проверки модель убрала claim про SCIM provisioning и оставила только SSO и audit logs, потому что SCIM не был найден в доступных docs.

Аналитический ответ с числами

ПромптGPT-5
Сначала дай ответ. Потом выдели все числа, даты и причинные claims. Проверь каждый и перепиши финальный вариант.
Ответ модели

После проверки дата релиза была исправлена, а причинная формулировка про падение ARPU ослаблена до гипотезы.

Техническая реализация

draft = answer_model(question)
claims = verifier_model(
    f"Выдели проверяемые claims из ответа:\n{draft}"
)
evidence_checks = verifier_model(
    f"Проверь каждый claim отдельно и верни verdict + evidence:\n{claims}"
)
final = answer_model(
    f"Перепиши ответ, сохранив только подтверждённые claims:\n{evidence_checks}"
)

Полезные улучшения

  • просить supported / unsupported / unclear вместо бинарного true / false;
  • требовать evidence span;
  • добавлять правило если claim не подтверждён, ослабь формулировку или убери его;
  • логировать mismatch между draft и final.

Verdict schema

verdict = {
    "claim": "SCIM is included in enterprise plan",
    "status": "supported | unsupported | unclear",
    "evidence": "doc snippet or tool result",
    "action": "keep | soften | remove"
}

Такой формат делает CoVe удобным не только для ответа пользователю, но и для наблюдаемости внутри системы.

Tool-backed checks

def verify_claim(claim, retrieve):
    evidence = retrieve(claim)
    return judge_claim_against_evidence(claim, evidence)

В реальных системах второй шаг CoVe часто лучше делать не тем же голым LLM, а через retrieval, search или docs lookup.

Частая ошибка

Если верификация идёт тем же расплывчатым стилем, что и исходный ответ, CoVe превращается в декоративный дополнительный шаг. Проверочные вопросы и verdict должны быть максимально конкретными.

Другие ошибки:

  • проверять слишком мало claims;
  • не отличать unsupported от unclear;
  • считать revised answer всегда более истинным;
  • не хранить evidence в traces;
  • использовать CoVe как замену retrieval quality.

Что полезно мерить в production

  • долю claims, которые были ослаблены или удалены после проверки;
  • unsupported rate по типам claims: числа, даты, policy statements;
  • disagreement между draft verdict и evidence-backed verdict;
  • долю ответов, где CoVe перевёл систему в не подтверждено.

Такие метрики помогают понять, CoVe реально снижает ложную уверенность или лишь декоративно переписывает финальный текст.

Проверьте себя

Проверьте себя

1. Что делает CoVe главным образом?

2. Где CoVe особенно полезен?

3. Что CoVe не гарантирует?

Предыдущая
Chain-of-Thought Decoding
Следующая
Chameleon