RAG для юридических документов: поиск и резюме с экспертной проверкой

RAG-ассистент для юридических документов может помочь команде найти актуальную оговорку, политику, заметку по прецеденту или документ дела и подготовить резюме с цитатами для квалифицированного специалиста. Он не должен определять юридический смысл, одобрять договор, давать совет клиенту или выдавать найденный фрагмент за вывод. Безопасный результат — evidence packet: запрос, разрешённые источники, точные locator, uncertainty и маршрут к ответственному эксперту.

В статье описан LEGAL-EVIDENCE-9 — ограниченный engineering-контракт для контролируемого поиска по юридическим документам. Это не юридическая, compliance-, privacy- или профессиональная консультация. Реальные требования зависят от организации, дела, юрисдикции и профессиональных обязанностей. За широкой архитектурой retrieval-системы переходите к услуге RAG-систем, а за evidence и границами delivery — к кейсам.

Начните с юридического процесса, а не с выгрузки документов

«Искать по всем юридическим документам» — не scope пилота. Рабочий scope называет пользователя, разрешённый корпус, тип вопроса, reviewer и условие остановки. Например: помочь внутренней команде найти последнюю утверждённую оговорку в шаблоне поставщика и подготовить comparison draft с citations. Но не решать, подходит ли эта оговорка для конкретной сделки.

Граница делает систему полезной, но не маскирует беглость модели под профессиональное суждение. Reviewer может открыть источник, проверить revision и увидеть, чего система не нашла.

Отраслевой процесс: intake, evidence, review и record

Юридическая работа часто начинается с неполного запроса: бизнес-владелец спрашивает, что значит условие, применим ли шаблон или что изменилось между версиями. Документы могут относиться к конкретному делу, быть привилегированными, конфиденциальными, версионированными, подписанными, сканированными или связанными с retention rule. Поэтому retrieval нужен процесс до ranking.

LEGAL-EVIDENCE-9 проходит девять этапов:

1. Receive — принять запрос с authenticated actor, делом или workspace, целью, пометкой юрисдикции при необходимости и требуемым типом документа.
2. Scope — определить разрешённый корпус по server-trusted роли, membership дела, ethical-wall или confidentiality policy и retention state.
3. Register — зарегистрировать источники с immutable ID, owner, version, effective period, status, access class и стабильным page/clause locator.
4. Retrieve — вернуть только eligible passages и сохранить source identity и revision, не копируя неподтверждённый контекст в prompt.
5. Compose — собрать bounded evidence packet, разделив quote или summary, uncertainty и missing sources.
6. Check — проверить citation coverage, конфликты, superseded versions, access state и переход запроса к юридическому выводу.
7. Route — передать packet назначенному квалифицированному reviewer либо вернуть no-answer / access-denied / conflict route.
8. Record — сохранить минимальный review receipt: источники, policy version, решение reviewer и unresolved questions.
9. Reconcile — обработать изменение, отзыв, удаление источника и evaluation failure до повторного использования.

request + trusted matter scope
  -> permitted source registry
  -> versioned retrieval with locators
  -> cited evidence packet
  -> legal-review / no-answer / denied route
  -> minimal review receipt and lifecycle reconciliation

Реестр источников — основной control. Одного имени документа недостаточно: у двух файлов с одинаковым названием шаблона могут отличаться effective date, owner, audience или replacement state. Почему удаление в source system должно стать наблюдаемым изменением в retrieval, разобрано в статье Обновление индекса RAG: ingestion, версии и удаление данных.

Где RAG может помочь в процессе работы с юридическими документами

Начинайте с задач, где создаётся проверяемая подготовительная работа. Семь use case ниже — примеры для приоритизации вместе с командой, которая владеет документами и юридическим риском; это не утверждение, что их нужно внедрять в любой организации.

Первый пилот обычно должен выбрать одну линию, одно семейство документов и небольшую группу reviewers. Широкий поиск по всем договорам, email-вложениям и папкам дел сразу делает access, lifecycle и evaluation слишком сложными для доказательства.

Контракты данных и интеграций

Техническому дизайну нужны четыре явных контракта.

1. Identity и matter scope. Браузер не выбирает tenant, дело или privilege flag. Trusted server определяет actor, role, workspace, membership дела и policy boundary до retrieval. Модель никогда не authorise собственный context.
2. Source lineage. Каждый candidate хранит source ID, content revision или hash, owner, lifecycle state, document type, access class, effective dates и stable locator. Индекс оставляет достаточно данных, чтобы воспроизвести, какая версия дала passage.
3. Evidence packet. Output отделяет citations от сгенерированного текста, маркирует direct extract, paraphrase, unresolved conflict и missing evidence. Автоматической destination write в нём нет.
4. Review receipt. Приложение сохраняет review decision и policy/source version в контролируемом system of record. Не нужно хранить полный чувствительный prompt transcript только потому, что это удобно для debugging.

Для персональных и конфиденциальных данных до ingestion определите purpose, разрешённые поля, retention, deletion и vendor boundary. Data minimisation и appropriate security — юридические и организационные вопросы, а не свойства, которые vector store даёт автоматически. NIST AI RMF — добровольный reference по risk management; его Govern guidance полезен для определения ролей human oversight и auditability, но не заменяет правовую оценку.

Пример входа и выхода

ВХОД
Actor: authenticated in-house procurement counsel
Matter: supplier-renewal-2026 (определено сервером)
Вопрос: что изменилось между approved DPA template rev. 18 и rev. 19?
Допустимый результат: comparison draft с page locator; без рекомендации об approval

OUTPUT EVIDENCE PACKET
Sources: DPA-TPL-018 p.4-7; DPA-TPL-019 p.4-8; policy PRIV-12 rev.6
Наблюдаемые изменения: три цитируемых текстовых различия со ссылкой на страницу
Uncertainty: не найден approved negotiation note для этого поставщика
Route: review назначенного counsel до внешней коммуникации или redline

В примере нет вывода, что новые условия безопасны; решения подписать; утверждения об обязанностях контрагента; или сообщения, отправленного ему автоматически. Если источники конфликтуют, locator сломан, документ superseded или у запроса нет scope, правильный результат — не более гладкое резюме. Это review, no-answer или fail-closed route.

Риски и ограничения должны быть частью дизайна

Главный риск — не только hallucination. Даже точно процитированный passage может не подходить делу, быть устаревшим, недоступным пользователю, неполным по контексту или подчиняться границе, которую система не смоделировала. Проектируйте под эти failure modes:

• Неверная версия: старый template остаётся в индексе после замены. Храните lifecycle state и тестируйте retrieval после revoke.
• Неверный scope: пользователь видит документ другого дела или restricted workspace. Применяйте server-trusted access filter до ranking и отдельно тестируйте denied retrieval.
• Потерянный context: оговорка summarise без definitions, schedule или exception. Давайте document/clause locator и путь к окружающему контексту.
• Ошибка OCR или ingestion: неверно прочитаны страницы, таблицы или подписи. Quarantine low-quality extraction и показывайте source image reviewer, а не выдавайте parsed text за authoritative.
• Privilege или confidentiality boundary: скопированный export пересекает policy line. До ingestion делайте corpus allowlist и data path проверяемыми.
• Излишнее доверие: reviewer считает draft выводом, потому что он звучит уверенно. В интерфейсе должны быть uncertainty, citations и named review route.
• Тихий lifecycle drift: source удалён или policy изменилась после draft. Перед reuse или external action повторно проверяйте source state.

Эти controls не сертифицируют compliance или юридическую точность. Они превращают риски в тестируемое поведение системы и помогают legal, privacy и security owners организации определить реальную границу.

Простая ROI-модель пилота без выдуманных обещаний

Используйте прозрачную оценку, а не обещание. Пусть N — число reviewed requests в месяц, M — median минут, которые сейчас тратятся на поиск разрешённых документов, m — median минут после evidence packet, а R — ежемесячная стоимость review, maintenance и evaluation. Оценка изменения capacity:

estimated_minutes_released = N × max(0, M - m)
pilot_value_question = estimated_minutes_released - R_in_minutes_equivalent

Считайте это только на определённом пилоте и не смешивайте с юридическим качеством. Более быстрый draft, который вызывает больше rework, wrong-scope retrieval или недоверие reviewer, не является полезным выигрышем. Отслеживайте reviewer acceptance, cited-claim coverage, качество no-answer, denied-access tests, stale-source findings и время исправления source issue.

Acceptance criteria перед расширением

До расширения корпуса проверьте known-answer и no-answer requests, документы с revoked access, superseded templates, boundaries дела, conflicting versions, scanned documents и reviewer override.

NIST AI RMF Playbook рассматривает governance, documentation и evaluation как постоянную деятельность. Для engineering это полезный принцип: review и monitoring — часть эксплуатации, а не финальный checkbox.

Выберите один контролируемый пилот

Выберите процесс, где квалифицированный owner уже проверяет output, initial source set можно явно утвердить, а no-answer допустим. Создайте source registry, matter-scope rule, дизайн evidence packet, evaluation set, reviewer matrix, failure log и rollback plan. Новые семейства документов и integrations добавляйте только после того, как команда докажет правильный scope, актуальные citations и полезное взаимодействие reviewer.

Если нужно выбрать один контролируемый процесс для AI retrieval pilot, подготовьте проектный бриф. Для обсуждения широкой технической архитектуры см. RAG-системы. Цель — не универсальный legal chatbot, а проверяемый information workflow, который помогает экспертам находить evidence и сохраняет их полномочия.