Самый быстрый способ выпустить опасного legal assistant — начать оптимизировать гладкий текст раньше, чем дисциплину работы с источниками. В legal QA основная работа не в том, чтобы модель звучала убедительно. С этим она и сама обычно справляется. Работа в том, чтобы ответ был привязан к правильному документу, правильной странице и минимальному набору фактов, который ещё можно защищать.
1. Главный failure mode — неправильный источник, а не слабая проза
Когда говорят, что legal system hallucinated, обычно смешивают сразу несколько разных сбоев:
- поднят не тот документ
- поднят правильный документ, но не та clause
- найдена одна supporting page, но потеряна вторая, от которой зависел ответ
- сгенерирован абзац там, где нужен был строгий формат
Поэтому борьба с галлюцинациями в legal QA — это не тема одного prompt.
Ключевой вопрос архитектуры звучит так:
Умеет ли система сохранить идентичность управляющего источника от ingestion до финального ответа?
Если ответ нет, генератор уже не спасёт ситуацию.
2. Legal corpus — враждебный вход
Юридические корпуса длинные, повторяющиеся и структурно похожие. Это ломает даже внешне сильные retrievers.
На практике это означает:
Сохраняйте идентичность документа с первого дня
Нужны как минимум:
- canonical document ID
- title
- document type
- section path
- page number
- raw chunk text
Если страница и документ теряются в самом начале, потом provenance приходится восстанавливать эвристиками.
OCR должен быть fallback на этапе ingestion
В legal PDFs критичный текст часто живёт внутри scans, image-based notices или плохо распознанных страниц. OCR не должен сидеть в online path, но обязан быть частью ingestion.
Нарезка должна учитывать структуру
Фиксированный размер chunk обычно слишком тупой для legal material. Лучше резать по:
- границы статей и разделов для законов
- блоки reasoning, facts и holding для case law
- границы clause и definition для contracts
Иначе система легко разрежет определение отдельно от обязательства, которое этим определением ограничивается.
3. Поиск должен оптимизировать правильную страницу, а не самый большой context window
Для legal QA разумный default по‑прежнему гибридный:
- векторный поиск для смысловой близости
- лексический поиск для номеров законов, статей, точных формулировок и имён сторон
Но важнее то, что происходит после первой стадии. Я предпочитаю такую схему:
- поднять достаточно широко, чтобы не потерять recall
- агрегировать кандидатов по семейству документов
- проверить согласованность shortlist
- переранжировать внутри shortlist
- отдать генератору только минимальный набор источников, на который действительно можно опереться
Именно здесь системы часто ломаются тихо: правильная страница есть в top set, но пропадает на этапе shaping shortlist, потому что похожий cousin document кажется достаточно близким.
4. Не заставляйте все legal questions отвечаться одним paragraph style
Разные legal tasks хотят разные форматы ответа. Чаще всего разумно хотя бы разделить вопросы на такие классы:
- boolean — да/нет с коротким основанием
- date — конкретная дата и подтверждение
- number — ставка, срок, порог, штраф
- name(s) — перечисление сущностей
- free_text — короткое объяснение там, где абзац действительно нужен
Строгий формат ответа важен не только для UX. Он делает ответ проверяемым.
Один общий абзац
- модель сама выбирает формат ответа
- сложно сравнивать с эталоном
- легко спрятать неподтверждённое утверждение внутри текста
Строгий формат ответа
- у каждого типа вопроса есть ожидаемая форма
- проще делать evals и policy checks
- неподтверждённый ответ легче отклонить или сократить
В legal QA форма ответа — часть слоя надёжности.
5. Привязка к источнику должна быть покороче, но достаточной
Полезная provenance в legal systems не должна быть ни слишком широкой, ни слишком бедной.
Хороший минимум:
- название документа
- путь по разделам
- номер страницы
- короткий excerpt или pinpoint support
Плохо работают и крайность с огромными dumps, и крайность с одной расплывчатой ссылкой без страницы.
6. Телеметрия должна объяснять юридические решения
Когда incident происходит в legal QA, инженеру важно понять не только, что ответ был неверный, но и как система к нему пришла.
Минимальный trace должен включать:
- какие документы были в candidate set
- как shortlist собирался по семействам документов
- что пошло в final context
- какой формат ответа был выбран
- какие guardrails и checks сработали
Это особенно важно в среде, где один неверный ответ легко превращается в compliance или litigation problem.
7. Evals должны разделять качество поиска и качество ответа
Слабый eval design часто склеивает всё в один score. Для legal QA это плохая идея.
Лучше проверять отдельно:
- подняла ли система правильное семейство документов
- попала ли в правильную страницу или раздел
- соответствует ли формат ответа задаче
- есть ли минимально достаточная привязка к источнику
- укладывается ли online path в latency budget
Иначе регрессия в поиске легко маскируется под "модель стала хуже рассуждать".
8. Production posture
Надёжная legal QA-система в 2026 — это не очень умный генератор абзацев. Это машина для работы с доказательствами, у которой есть узкий формат ответа и дисциплинированный путь до источника.
Если система не может уверенно удержать идентичность управляющего источника до конца run, она должна отказаться от ответа быстрее, чем начнёт звучать убедительно. Остальное выглядит эффектнее. Юристам от этого не легче.