Как строить юридические QA-системы, которым можно доверять

01 Подготовка корпуса

Не терять идентичность документа

• парсинг PDF с OCR как запасным слоем
• нарезка по структуре, а не по голому размеру
• сохранение заголовка документа, пути по разделам и номера страницы

02 Поиск

Сузить поиск до правильного семейства документов

• гибридный поиск: векторный плюс лексический
• агрегация по документу или семейству закона
• переранжирование уже внутри короткого списка, а не по всему корпусу

03 Ответ

Отвечать в строгом формате

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

04 Привязка и проверки

Не отпускать ответ без следа

• привязка к конкретным страницам
• телеметрия, связанная с финальным ответом
• отдельные проверки для качества ответа, привязки к источнику и задержки

1. Главная поломка здесь — неправильный источник, а не слабая проза

Когда говорят, что юридическая система «галлюцинировала», обычно смешивают сразу несколько разных сбоев:

• поднят не тот документ
• поднят правильный документ, но не тот пункт
• найдена одна опорная страница, но потеряна вторая, от которой зависел ответ
• сгенерирован абзац там, где нужен был строгий формат

Поэтому борьба с галлюцинациями в юридическом QA — это не тема одного промпта.

Ключевой вопрос архитектуры звучит так:

Умеет ли система сохранить идентичность управляющего источника от загрузки данных до финального ответа?

Если ответ нет, генератор уже не спасёт ситуацию.

2. Юридический корпус — враждебный вход

Юридические корпуса длинные, повторяющиеся и структурно похожие. Это ломает даже внешне сильные системы поиска.

На практике это означает:

Сохраняйте идентичность документа с первого дня

Нужны как минимум:

• канонический идентификатор документа
• заголовок
• тип документа
• путь по разделам
• номер страницы
• исходный текст фрагмента

Если страница и документ теряются в самом начале, потом привязку к источнику приходится восстанавливать эвристиками.

OCR должен быть запасным слоем на этапе подготовки корпуса

В юридических PDF критичный текст часто живёт внутри сканов, уведомлений в виде картинок или плохо распознанных страниц. OCR не должен сидеть в онлайн-пути, но обязан быть частью подготовки корпуса.

Нарезка должна учитывать структуру

Фиксированный размер фрагмента обычно слишком груб для юридического материала. Лучше резать по:

• границы статей и разделов для законов
• блокам reasoning, facts и holding для case law
• границы пунктов и определений в договорах

Иначе система легко разрежет определение отдельно от обязательства, которое этим определением ограничивается.

3. Поиск должен оптимизировать правильную страницу, а не самый большой контекст

Для юридического QA базовый рабочий вариант по‑прежнему гибридный:

• векторный поиск для смысловой близости
• лексический поиск для номеров законов, статей, точных формулировок и имён сторон

Но важнее то, что происходит после первой стадии. Я предпочитаю такую схему:

1. поднять достаточно широко, чтобы не потерять полноту
2. агрегировать кандидатов по семейству документов
3. проверить согласованность шорт-листа
4. переранжировать внутри шорт-листа
5. отдать генератору только минимальный набор источников, на который действительно можно опереться

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

4. Не заставляйте все юридические вопросы отвечаться одним абзацем

Разные юридические задачи хотят разные форматы ответа. Чаще всего разумно хотя бы разделить вопросы на такие классы:

• ответ да/нет — да/нет с коротким основанием
• дата — конкретная дата и подтверждение
• number — ставка, срок, порог, штраф
• имена и списки сущностей — перечисление сущностей
• свободный текст — короткое объяснение там, где абзац действительно нужен

Строгий формат ответа важен не только для UX. Он делает ответ проверяемым.

Один общий абзац

• модель сама выбирает формат ответа
• сложно сравнивать с эталоном
• легко спрятать неподтверждённое утверждение внутри текста

Строгий формат ответа

• у каждого типа вопроса есть ожидаемая форма
• проще делать оценки и проверки правил
• неподтверждённый ответ легче отклонить или сократить

В юридическом QA форма ответа — часть слоя надёжности.

5. Привязка к источнику должна быть короткой, но полной

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

Проблема здесь двусторонняя:

• можно сослаться на слишком много
• можно сослаться на слишком мало

Вторая ошибка в юридическом QA обычно опаснее.

Если ответ опирается на два факта с разных страниц, нужны обе страницы. Не одна «лучшая» страница ради аккуратности.

Хороший минимум обычно такой:

• название документа
• путь по разделам
• номер страницы
• короткий excerpt или точный фрагмент-опору

Но если ответ состоит из нескольких опорных элементов, одной ссылки на страницу уже недостаточно. Поэтому полезнее мыслить не «одной цитатой на ответ», а отдельной привязкой по элементам ответа.

Ровно в эту сторону толкают и более точные диагностические подходы вроде RAGChecker: важно понимать не только, что ответ плохой, но и где именно потерялась опора на источник.

6. Телеметрия должна объяснять юридические решения

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

Минимальная трасса должна включать:

• какие документы попали в первичный набор кандидатов
• как шорт-лист собирался по семействам документов
• что пошло в финальный контекст
• какой формат ответа был выбран
• какие ограничения и проверки сработали

Это особенно важно в среде, где один неверный ответ легко превращается в комплаенс- или судебную проблему.

7. Проверки должны разделять качество поиска и качество ответа

Слабый дизайн системы проверок часто склеивает всё в одну оценку. Для юридического QA это плохая идея.

Лучше проверять отдельно:

• подняла ли система правильное семейство документов
• не перепутала ли нужный документ с похожим соседним
• попала ли в правильную страницу или раздел
• соответствует ли формат ответа задаче
• есть ли минимально достаточная привязка к источнику
• укладывается ли онлайн-путь в бюджет по задержке

Иначе регрессия в поиске легко маскируется под «модель стала хуже рассуждать».

И ещё лучше заранее разделять:

• опорный набор для жёстких релизных решений
• более шумный набор для мониторинга дрейфа

8. Рабочая продакшен-позиция

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

Если система не может уверенно удержать идентичность управляющего источника до конца прогона, она должна отказаться от ответа быстрее, чем начнёт звучать убедительно. Остальное выглядит эффектнее. Юристам от этого не легче.

Что ещё почитать

• Большинство проблем в RAG начинаются с документов
• Как устроить проверки для LLM-систем в проде

Источники и ссылки

• Towards Reliable Retrieval in RAG Systems for Large Legal Datasets
• LegalBench-RAG: A Benchmark for Retrieval-Augmented Generation in the Legal Domain
• RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation
• OpenAI: Evaluation best practices
• Anthropic: Demystifying evals for AI agents