Юридический RAG не начинается с векторной базы

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

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

Что ломается, если начать с embeddings

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

Проблема не в том, что векторный поиск бесполезен. Проблема в том, что он не знает, какой именно фрагмент является:

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

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

Практический вывод простой: в юридическом RAG сначала проектируют единицу права, а уже потом способ её поиска.

С чего начинать: не с индекса, а с типа вопроса

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

• «Что говорит норма по этому случаю?»;
• «Какая редакция действовала на дату события?»;
• «Какие требования обязательны, а какие рекомендательные?»;
• «Какое условие из закупочной документации ограничивает участие?»;
• «Чем отличается формулировка в проекте договора от утверждённой версии?»;
• «Какие связанные документы нужно учитывать вместе с этой нормой?»

Эти вопросы требуют разных стратегий поиска. Иногда нужен точный поиск по статье и пункту. Иногда — поиск по реквизитам версии. Иногда — семантический поиск по смыслу. Иногда — связка всех трёх.

Полезно на старте разделить запросы на четыре класса:

Если этого деления нет, команда начинает оптимизировать технологию вместо процесса ответа. Тогда спор идёт не о том, как юрист получает правильный результат, а о том, какой эмбеддинг «лучше понимает право».

Правильная единица индексации: статья, пункт, версия, связь

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

Практический подход такой:

1. Сохранять иерархию документа.
   У каждого фрагмента должны быть реквизиты: источник, дата, редакция, номер, раздел, статья, пункт, уровень вложенности.
2. Хранить атомарный текст и контекст.
   Индексировать можно отдельный пункт, но в ответе поднимать его вместе с заголовком статьи, соседними пунктами и служебными отсылками.
3. Не смешивать редакции.
   Если документ менялся, редакции должны быть отдельными объектами. Вопрос «что действовало 15 марта» нельзя решать по текущей версии.
4. Фиксировать тип связи.
   Связи в правовом корпусе не одинаковы: «отсылает к», «исключает», «уточняет», «применяется вместе с», «заменяет». Это не декоративная метаинформация, а часть поиска.
5. Отмечать юридическую силу.
   Норма, приложение, пояснение, проект, разъяснение, шаблон — это разные источники доверия. Система должна знать, что брать за основу, а что использовать только как контекст.

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

Почему для права нужен гибридный поиск

Для нормативки и закупок почти всегда нужен гибрид: структурный поиск + точные фильтры + семантика + rerank. Это не избыточность, а способ снизить риск пропуска нужной нормы.

Рабочая схема обычно выглядит так:

• сначала отбираются документы по реквизитам: тип, дата, статус, источник;
• затем выполняется точный или морфологический поиск по ключевым формулировкам;
• параллельно идёт семантический поиск по смыслу;
• результаты объединяются;
• поверх них применяется rerank с учётом вопроса и правовой структуры;
• в ответ попадают только фрагменты с объяснимым происхождением.

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

Когда семантика помогает, а когда мешает

Семантический поиск хорош там, где пользователь не знает точной формулировки: «ограничение на участие по опыту», «подтверждение соответствия», «документы к заявке». Он помогает найти нужный блок по смыслу.

Но если вопрос уже содержит точный реквизит, семантика может увести в соседние нормы. Например, похожая формулировка в другой главе, схожее требование в типовом шаблоне, устаревшая редакция из архива. Поэтому семантика в правовом RAG должна быть не основным, а дополняющим механизмом.

Как строить ответ: от цитаты к выводу, а не наоборот

Для юридического RAG особенно важно не перепутать порядок мышления. Сначала система должна собрать опору, потом сформировать вывод. Не наоборот.

Надёжный рабочий шаблон ответа:

1. определить тип вопроса;
2. найти релевантные нормы и редакцию;
3. проверить исключения и связанные документы;
4. выделить прямую цитату или точную ссылку;
5. сформировать краткий вывод;
6. указать ограничения: «если дата другая», «если документ иной редакции», «если применяется специальная норма».

Такой ответ может казаться менее «умным», чем свободная генерация, но он полезнее в работе. В юридической практике ценится не литературная гладкость, а возможность быстро проверить вывод.

Важно и то, чего система не должна делать. Если источников недостаточно, она не должна догадываться. Лучше вернуть:

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

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

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

Юридический RAG тестируют не только на «правильных ответах». Нужны сценарии, где ошибка особенно опасна. Например:

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

Полезно заранее определить, какие ошибки считаются критическими. Для права это обычно:

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

Хорошая практика — заводить набор контрольных вопросов, где правильный ответ известен не потому, что он «похож», а потому, что он подтверждён конкретной нормой и конкретной версией документа. Это намного полезнее, чем абстрактная оценка recall на корпусе.

Практический чек-лист перед первым релизом

• [ ] Есть ли у каждого документа реквизиты версии и статуса?
• [ ] Разделены ли действующие и архивные редакции?
• [ ] Сохраняется ли иерархия статьи, пункта и подпункта?
• [ ] Настроены ли фильтры по дате и типу источника?
• [ ] Есть ли гибридный поиск, а не только embeddings?
• [ ] Возвращает ли система цитату и основание вывода?
• [ ] Проверены ли сценарии с исключениями и устаревшими нормами?

Практический метод для нормативки и закупок

Если свести всё к рабочему маршруту, метод выглядит так:

1. Описать вопросы бизнеса и права.
Не «сделать поиск по документам», а закрыть конкретные типы запросов: редакция на дату, обязательность требования, контекст закупки, связанные нормы.

2. Собрать корпус как правовую структуру.
Не просто PDF-файлы, а документы с реквизитами, иерархией, версиями, отсылками и статусом.

3. Выбрать атомарную единицу и контекст.
Обычно это пункт или подпункт плюс заголовок и соседние элементы.

4. Построить гибридный retrieval.
Точные фильтры, полнотекст, семантика, rerank — в одном маршруте.

5. Заставить ответ ссылаться на источник.
Без ссылки и редакции ответ не считается завершённым.

6. Проверять ошибки как юридические риски.
Не только совпадение текста, но и правильность режима применения.

Именно в таком порядке юридический RAG становится инструментом работы, а не демонстрацией технологии. Векторная база здесь важна, но она — не начало проекта. Начало проекта — в понимании того, как право устроено как объект поиска: с версиями, исключениями, иерархией и ответственностью за каждую строку ответа.