Анатомия contract-review агента: PDF → пункты → риск

Чему вы научитесь

• Описывать каждый шаг конвейера contract-review агента от PDF-файла до финального отчёта
• Понимать, зачем нужна классификация типов пунктов и как она влияет на качество скоринга
• Читать уровни риска (low / medium / high / critical) и знать, по каким признакам агент их присваивает
• Разграничивать задачи, которые агент решает автоматически, и задачи, где нужен живой юрист
• Применять RF-оговорку: почему UK-бенчмарки не подходят для договоров по российскому праву

Зачем разбирать агента на части

Большинство команд, впервые сталкивающихся с AI-разбором договоров, воспринимают его как единое действие: загрузили PDF — получили замечания. На практике между загрузкой и отчётом стоит конвейер из пяти-шести отдельных шагов, и каждый из них может ошибиться по-своему.

Если агент пропустил ключевой пункт об ответственности, причина почти всегда кроется в одном конкретном шаге, а не в «плохой модели» вообще. Зная архитектуру, вы сможете диагностировать сбой, выбрать правильный инструмент для исправления и объяснить результат клиенту или коллеге без магических оговорок.

В качестве ориентира этого урока используется открытый проект Contract Review Agent (zahirnik/legal-agent, лицензия MIT). Он реализует полный цикл: PDF → парсинг → классификация → скоринг → отчёт. Стек: Python 3.11, Streamlit, pdfplumber, ChromaDB, Neo4j Aura.

Конвейер: шаг за шагом

flowchart TD
    A[PDF договора] --> B[Парсинг текста\npdfplumber]
    B --> C[Разбивка на пункты\nclause-aware chunking]
    C --> D[Классификация типа пункта\n21+ категория]
    D --> E[Скоринг риска\nlow / medium / high / critical]
    E --> F[Детект red flags\nrisk_rules.yaml]
    F --> G[Сравнение с бенчмарком\nNeo4j Aura]
    G --> H[Детект недостающих пунктов]
    H --> I[Семантический поиск\nChromaDB]
    I --> J[PDF-отчёт]

Разберём каждый блок подробнее.

Шаг 1 — Парсинг PDF

Инструмент pdfplumber извлекает текст постранично, сохраняя координаты блоков. Это важно: скан-PDF без слоя текста (отсканированные документы) требует дополнительного OCR — pdfplumber такой файл не прочитает. Если договор пришёл как скан, первый шаг — предобработка через Tesseract или аналоги.

На выходе парсера — сырой текст с разметкой страниц. Нумерация разделов и заголовки пунктов сохраняются, если в исходном PDF они были в виде текста, а не в виде изображения.

Шаг 2 — Разбивка на пункты

Сырой текст нарезается на смысловые единицы по номерам статей и пунктов, а не по числу токенов. Этот подход называется clause-aware chunking и подробно разобран в следующем уроке. Главное сейчас: если нарезать текст договора по токенам, один пункт легко распадётся на несколько кусков, и классификатор получит неполный контекст.

Шаг 3 — Классификация типа пункта

Каждый пункт передаётся языковой модели (в исходном проекте — GPT-4o-mini или Claude, переключаемо; для актуальных задач подходят Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) с запросом определить тип. Проект поддерживает более 21 категории.

Точность классификации зависит от качества промпта и модели. Для юридического регистра на русском языке дополнительно стоит сравнивать GigaChat и YandexGPT — они обучены на русскоязычных текстах, что может давать преимущество на специфичной терминологии.

Шаг 4 — Скоринг риска

После классификации каждый пункт получает оценку риска на основе правил из файла risk_rules.yaml. Шкала: low / medium / high / critical.

Шаг 5 — Red flags

Red flags — это конкретные паттерны, заданные в risk_rules.yaml, при обнаружении которых агент выделяет пункт отдельно, независимо от общего уровня риска. Примеры: «индемнити в одну сторону», «нет кэпа ответственности», «форс-мажор не включает эпидемии».

Шаг 6 — Сравнение с рыночным бенчмарком

Каждый классифицированный пункт сравнивается с тем, что считается «рыночным стандартом» для данного типа договора. Бенчмарки хранятся в графовой базе Neo4j Aura.

Критически важная оговорка для работы в РФ. Бенчмарки в исходном проекте задокументированы как market-standard benchmarks for UK jurisdiction. Применять их к договорам по российскому праву нельзя без переработки: иные нормы об ответственности, неустойке, свободе договора (ст. 421 ГК РФ), специальные требования отраслевых законов. Подробно — в уроке 3.

Шаг 7 — Детект недостающих пунктов

Агент сверяет набор классифицированных пунктов с шаблонным перечнем обязательных условий для данного типа договора. Если раздела нет — это отдельный сигнал в отчёте. Например, в договоре подряда отсутствие раздела о гарантийных обязательствах — значимый пропуск.

Шаг 8 — Семантический поиск

ChromaDB хранит эмбеддинги всех пунктов договора. Пользователь может задать вопрос в свободной форме («какие условия расторжения предусматривает договор»), и агент найдёт релевантные пункты через векторный поиск, а не через ключевые слова. Этому посвящён урок 2.

Шаг 9 — Отчёт

На выходе — PDF-отчёт с перечнем пунктов, их типами, уровнями риска, red flags и рекомендациями. Фронтенд сделан на Streamlit — веб-интерфейс для загрузки договора и просмотра результата.

Что отдать агенту, что оставить юристу

Понимание конвейера помогает провести честную границу между автоматическим анализом и профессиональной работой.

Агент ускоряет первичный просмотр и помогает расставить приоритеты. Итоговое решение, переговорная позиция и профессиональная ответственность остаются за юристом.

Модели для разбора договоров

Исходный проект работает на GPT-4o-mini и Claude (переключаемо). Для современных задач:

• Claude Opus 4.7 — сильный reasoning на длинных документах, хорошо следует сложным инструкциям по классификации
• GPT-5.5 — высокая точность на структурированных задачах, удобен при интеграции через API
• Gemini 3.1 Pro — большое контекстное окно, полезно для длинных договоров целиком
• GigaChat / YandexGPT — российские альтернативы без вопросов трансграничной передачи данных; особенно актуальны при работе с реальными договорами в российском правовом контуре

Выбор модели влияет на точность классификации. Рекомендуется тестировать на представительной выборке из своей практики, а не ориентироваться только на общие бенчмарки.