---
title: Проверка документов
description: "Ассистент, который читает договоры, счета, заявки и ТЗ: извлечение полей, сверка с правилами, вердикт с цитатой и обязательное человеческое подтверждение."
---

## Что это за сценарий

Проверка документов — задача, где модель читает длинный текст и отвечает на конкретные вопросы: есть ли обязательные условия, совпадают ли реквизиты, какие поля заполнены, соответствует ли проект ТЗ, есть ли риск в формулировке.

Это один из немногих сценариев, где ИИ даёт быстрый и измеримый эффект: документы однотипны, критерии проверки известны, а объём работы велик. И одновременно один из самых рискованных: ошибка в договоре стоит дороже плохого ответа в чате.

## Три уровня автоматизации

| Уровень | Что делает система | Роль человека |
|---|---|---|
| **Извлечение** | Достаёт поля: сумма, срок, стороны, дата, номер | Проверяет спорные значения |
| **Проверка по правилам** | Сверяет с чек-листом: каких условий не хватает, что расходится | Разбирает найденные расхождения |
| **Вердикт** | Даёт заключение: принять, отклонить, на доработку | Подписывает решение |

Чем выше уровень, тем реже он применим. Начинать почти всегда стоит с извлечения: оно даёт ценность сразу и не требует доверия к рассуждениям модели.

## Как повысить точность

- **Схема ответа.** Требуйте структурированный вывод по полям (JSON schema), а не свободный текст. Это отсекает половину ошибок.
- **Цитаты обязательны.** Каждое извлечённое значение сопровождается фрагментом документа, откуда оно взято. Без цитаты значение нельзя проверить, а значит нельзя использовать.
- **Правила кодом, интерпретация моделью.** «Сумма договора не превышает лимит» — это сравнение чисел, а не вопрос к модели. Модель читает документ, код проверяет условие.
- **Явное «не найдено».** Отсутствие поля — валидный результат. Иначе модель заполнит его правдоподобным значением.
- **Разделение типов документов.** Договор поставки, NDA и трудовой договор проверяются разными правилами; смешанный промпт даёт среднее качество по всем.

## Почему нужен человек в цикле

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

```mermaid
flowchart LR
    D["Документ"] --> X["Извлечение<br/>полей"]
    X --> V["Проверка<br/>правилами"]
    V --> S{"Всё<br/>в порядке?"}
    S -- "да" --> A["Автопринятие<br/>по порогу"]
    S -- "нет" --> H["Ручной разбор<br/>исключения"]
```

Порог автопринятия задаётся не «на глаз»: это доля документов, на которой система стабильно точна. Всё, что ниже порога, уходит человеку — и это нормальный режим работы, а не временная мера.

## Метрики

Измерять надо по полям и по документам отдельно:

- **Точность поля** (field-level accuracy) — совпало ли значение с эталоном.
- **Полнота** — сколько обязательных полей заполнено.
- **Доля исключений** — сколько документов ушло на ручной разбор.
- **Время обработки** — на документ и на очередь.
- **Стоимость** — токены и вызовы на документ; длинные договоры дороги.
- **Ошибки с последствиями** — неверная сумма, пропущенное условие. Считаются отдельно и разбираются всегда.

## Где ломается

- **Сканы и плохой OCR.** Модель «дочитывает» неразборчивый текст; качество входа важнее модели.
- **Многостраничные таблицы.** Приложения, спецификации и графики платежей теряют структуру при парсинге.
- **Длинные документы.** Часть текста не попадает в контекст; нужен поиск по документу (см. [RAG](https://wpcraft.ru/kb/ai/rag.md)), а не «прочитай целиком».
- **Уверенность без оснований.** Модель выдаёт значение там, где поля нет.
- **Изменения в правилах.** Чек-лист обновили, промпт — нет. Правила должны жить в одном месте и версионироваться.

## Что проверять в проекте

- Есть ли **набор эталонных документов** с правильными ответами (20–50 штук достаточно для старта).
- Сопровождается ли каждое значение **цитатой**.
- Что происходит при **низкой уверенности** — и умеет ли система её выражать.
- Логируются ли **решения и правки человека**: это датасет для улучшения.
- Есть ли **право на ошибку**: кто отвечает, если автопринятие пропустило проблему.

## Связанные материалы

- [AI-ассистенты](https://wpcraft.ru/kb/ai/assistants.md) — общая архитектура.
- [Анализ данных](https://wpcraft.ru/kb/ai/assistants/data-analysis.md) — соседний сценарий: вопросы к структурированным данным.
- [Оценка качества](https://wpcraft.ru/kb/ai/agents/evaluation.md) — наборы тестов и регрессии.
- [Guardrails](https://wpcraft.ru/kb/ai/agents/guardrails.md) — ограничения на действия с документами.

## Материалы и источники

- [Anthropic: Claude и длинные документы](https://www.anthropic.com/news) — работа с большим контекстом и цитированием
- [OpenAI: structured outputs](https://platform.openai.com/docs/guides/structured-outputs) — схема ответа вместо свободного текста
- [Enterprise AI use cases (2026)](https://www.vortexwebinnovate.com/blog/enterprise-ai-use-cases) — сценарии обработки документов и метрики внедрения
- [Anthropic: Building effective agents](https://www.anthropic.com/research/building-effective-agents) — где заканчивается агент и начинается human-in-the-loop