Глава 52. Контентный pipeline с проверкой фактов

Редактор получил гладкую статью о новой функции продукта. В тексте были правильные кнопки, но функция ещё не вышла. Модель нашла название в черновике релиз-нота и превратила будущее время в настоящее. Грамматически это одна морфема, коммерчески — обещание клиентам того, чего нет.

Проверяют утверждения, а не впечатление

Генерацию отделяют от проверки. Сначала система собирает разрешённые источники и делает черновик с ссылками. Затем извлекает атомарные проверяемые утверждения. Для каждого ищет подтверждение, фиксирует статус и только после этого собирает публикацию.

class Claim(BaseModel):
    text: str
    source_ids: list[str]
    status: Literal["supported", "contradicted", "missing"]
 
async def fact_check(draft, corpus):
    claims = await extract_claims(draft)
    checked = []
    for claim in claims:
        evidence = await retrieve(claim.text, corpus=corpus)
        checked.append(await judge_claim(claim, evidence))
    return checked

Judge не получает задачу «оцени статью». Он сравнивает одно утверждение с конкретными фрагментами. Ссылки валидируются сервером, даты источников учитываются. Числа, цитаты, юридические обещания и статус доступности требуют редактора даже при найденном подтверждении.

brief -> approved corpus -> outline -> draft with citations
      -> claim extraction -> evidence check -> editorial review
      -> publish immutable revision -> monitor corrections

Failure modes

Два сайта перепечатали одну ошибку, и количество ссылок выглядит как независимое подтверждение. Источник устарел. Модель приписала вывод источнику, который сообщает только исходные числа. После фактчека редактор изменил абзац, но проверку повторно не запустил. Поэтому проверяем именно финальный hash публикации и храним происхождение источников.

Корпус решает больше, чем промпт

Половина ошибок фактчекинга приходит не из модели, а из того, что попало в разрешённые источники. Черновик релиз-нота, лежащий рядом с опубликованной документацией, — это мина, которую заложили при настройке доступа.

Минимальные правила корпуса для контента:

• Только опубликованное. Черновики, внутренние обсуждения и планы в корпус не входят. Если нужны — с явным статусом draft, который блокирует их использование как подтверждения.
• Дата и версия у каждого источника. Подтверждение из документа, устаревшего год назад, — не подтверждение.
• Независимость источников. Две перепечатки одной новости не образуют двух подтверждений; храните происхождение и умейте их схлопывать.
• Владелец. У каждого источника есть человек, отвечающий за актуальность (глава 23).

Правило главы

Опубликованным считается текст конкретной ревизии, где каждое существенное утверждение имеет проверяемый статус и владельца решения.

Чеклист главы

• Генерация и проверка разделены; черновик собирается только из разрешённого корпуса.
• Из текста извлекаются атомарные утверждения; статус проставляется каждому.
• Judge сравнивает одно утверждение с конкретными фрагментами, а не оценивает статью целиком.
• Ссылки валидируются сервером; даты и версии источников учитываются.
• Черновики и неопубликованные материалы не могут служить подтверждением.
• Перепечатки одного источника не считаются независимыми подтверждениями.
• Числа, цитаты, юридические обещания и статус доступности требуют редактора даже при найденном подтверждении.
• Публикуется неизменяемая ревизия; проверка привязана к её хешу.
• Любая правка после проверки аннулирует approval и запускает повторный фактчек.
• Ведётся мониторинг исправлений после публикации: что пришлось править и почему.

Практикум

Задача 52.1 — фактчек, привязанный к ревизии. ⭑⭑⭑

Возьмите статью с двадцатью фактами и постройте pipeline проверки утверждений.

Критерии приёмки:

• Размечены атомарные claims и допустимые источники для каждого.
• Публикация блокируется при статусе contradicted; missing уходит редактору.
• После успешной проверки изменено одно число, и прежний approval перестал действовать.
• Проверка привязана к хешу финальной ревизии, а не к «статье вообще».
• Измерено, сколько утверждений в исходном черновике оказались неподтверждёнными.

Подсказки:

1. Атомарность утверждения проверяется просто: если для подтверждения нужны два разных источника, утверждение надо разбить.
2. Самый частый источник ошибок — предложение, где к правильному факту приклеен вывод, которого в источнике нет.

Задача 52.2 — ловушки корпуса. ⭑⭑

Проверьте, что ваш корпус источников не создаёт ложных подтверждений.

Критерии приёмки:

• В корпус подложены черновик и устаревшая версия документа; система не использует их как подтверждение.
• Добавлены две перепечатки одной новости; система не засчитывает их как независимые подтверждения.
• У каждого источника есть дата, версия и владелец; документы без них не участвуют в проверке.
• Показан случай, где вывод приписан источнику, который сообщает только исходные числа, и он отловлен.
• Составлен список правил корпуса и передан тем, кто наполняет базу источников.

Подсказки:

1. Схлопывание перепечаток проще делать по канонической ссылке и хешу текста, чем по домену.
2. Правила корпуса имеет смысл писать как чек-лист для редакции: инженерная защита без этого превращается в бесконечную очередь missing.