Юридический RAG не начинается с векторной базы
Юридический RAG часто пытаются строить по знакомому сценарию: загрузили документы, нарезали на фрагменты, отправили в векторную базу, подключили LLM — и ждут, что система начнёт находить нужные нормы, пункты договора и практику по смыслу. В реальности для права такой подход быстро упирается в качество источников, структуру документов и ответственность за ответ.
Для нормативки и закупок важен не «поиск похожих фраз», а воспроизводимый маршрут от вопроса к точной норме, версии документа, актуальному статусу и контексту применения. Если этот маршрут не продуман, векторная база лишь ускоряет ошибку.
Что ломается, если начать с embeddings
В обычном корпоративном поиске семантическая близость часто достаточна: найти похожий регламент, письмо или инструкцию — уже полезно. В правовой задаче этого мало. Здесь один и тот же смысл может быть выражен в разных формулировках, а одно слово — менять правовой режим.
Проблема не в том, что векторный поиск бесполезен. Проблема в том, что он не знает, какой именно фрагмент является:
- действующей редакцией;
- исключением из общего правила;
- нормой прямого действия;
- приложением, которое нельзя читать отдельно;
- устаревшей редакцией, но всё ещё цитируемой в документах закупки.
Если индексировать «как есть», система начинает смешивать редакции, распылять смысл по кускам и уверенно тащить близкие, но юридически неверные фрагменты. Для пользователя это выглядит как хороший поиск с плохим выводом. Для команды — как сложный и дорогой баг.
Практический вывод простой: в юридическом RAG сначала проектируют единицу права, а уже потом способ её поиска.
С чего начинать: не с индекса, а с типа вопроса
Первый рабочий шаг — не выбрать базу, а описать, какие запросы система должна закрывать. Для нормативных документов и закупок обычно есть несколько устойчивых типов вопросов:
- «Что говорит норма по этому случаю?»;
- «Какая редакция действовала на дату события?»;
- «Какие требования обязательны, а какие рекомендательные?»;
- «Какое условие из закупочной документации ограничивает участие?»;
- «Чем отличается формулировка в проекте договора от утверждённой версии?»;
- «Какие связанные документы нужно учитывать вместе с этой нормой?»
Эти вопросы требуют разных стратегий поиска. Иногда нужен точный поиск по статье и пункту. Иногда — поиск по реквизитам версии. Иногда — семантический поиск по смыслу. Иногда — связка всех трёх.
Полезно на старте разделить запросы на четыре класса:
| Класс запроса | Что важно | Как искать |
|---|---|---|
| Точная норма | статья, пункт, подпункт, редакция | структурный и атрибутный поиск |
| Похожий смысл | близкая формулировка, синонимы | семантический поиск |
| Версия на дату | актуальность, срок действия, изменения | поиск по метаданным и временной оси |
| Связанный контекст | ссылки на приложения, исключения, отсылки | граф связей и цитат |
Если этого деления нет, команда начинает оптимизировать технологию вместо процесса ответа. Тогда спор идёт не о том, как юрист получает правильный результат, а о том, какой эмбеддинг «лучше понимает право».
Правильная единица индексации: статья, пункт, версия, связь
Для права опасно резать документы на куски только по длине. Векторный поиск любит компактные чанки, но правовой смысл живёт в структуре: глава, статья, часть, пункт, подпункт, примечание, приложение, редакция. Потеря структуры почти всегда бьёт по качеству ответа.
Практический подход такой:
- Сохранять иерархию документа.
У каждого фрагмента должны быть реквизиты: источник, дата, редакция, номер, раздел, статья, пункт, уровень вложенности. - Хранить атомарный текст и контекст.
Индексировать можно отдельный пункт, но в ответе поднимать его вместе с заголовком статьи, соседними пунктами и служебными отсылками. - Не смешивать редакции.
Если документ менялся, редакции должны быть отдельными объектами. Вопрос «что действовало 15 марта» нельзя решать по текущей версии. - Фиксировать тип связи.
Связи в правовом корпусе не одинаковы: «отсылает к», «исключает», «уточняет», «применяется вместе с», «заменяет». Это не декоративная метаинформация, а часть поиска. - Отмечать юридическую силу.
Норма, приложение, пояснение, проект, разъяснение, шаблон — это разные источники доверия. Система должна знать, что брать за основу, а что использовать только как контекст.
Именно здесь появляется первая важная инженерная мысль: векторная база не отменяет структуру, она лишь хранит её в соседстве с эмбеддингом. Если структура не извлечена заранее, эмбеддинг начинает работать на слепой текст.
Почему для права нужен гибридный поиск
Для нормативки и закупок почти всегда нужен гибрид: структурный поиск + точные фильтры + семантика + rerank. Это не избыточность, а способ снизить риск пропуска нужной нормы.
Рабочая схема обычно выглядит так:
- сначала отбираются документы по реквизитам: тип, дата, статус, источник;
- затем выполняется точный или морфологический поиск по ключевым формулировкам;
- параллельно идёт семантический поиск по смыслу;
- результаты объединяются;
- поверх них применяется rerank с учётом вопроса и правовой структуры;
- в ответ попадают только фрагменты с объяснимым происхождением.
Такая схема полезна по двум причинам. Во-первых, она уменьшает зависимость от одного метода. Во-вторых, она позволяет объяснить, почему система выбрала именно этот фрагмент. Для юридических сценариев это критично: пользователю важен не только ответ, но и основание.
Когда семантика помогает, а когда мешает
Семантический поиск хорош там, где пользователь не знает точной формулировки: «ограничение на участие по опыту», «подтверждение соответствия», «документы к заявке». Он помогает найти нужный блок по смыслу.
Но если вопрос уже содержит точный реквизит, семантика может увести в соседние нормы. Например, похожая формулировка в другой главе, схожее требование в типовом шаблоне, устаревшая редакция из архива. Поэтому семантика в правовом RAG должна быть не основным, а дополняющим механизмом.
Как строить ответ: от цитаты к выводу, а не наоборот
Для юридического RAG особенно важно не перепутать порядок мышления. Сначала система должна собрать опору, потом сформировать вывод. Не наоборот.
Надёжный рабочий шаблон ответа:
- определить тип вопроса;
- найти релевантные нормы и редакцию;
- проверить исключения и связанные документы;
- выделить прямую цитату или точную ссылку;
- сформировать краткий вывод;
- указать ограничения: «если дата другая», «если документ иной редакции», «если применяется специальная норма».
Такой ответ может казаться менее «умным», чем свободная генерация, но он полезнее в работе. В юридической практике ценится не литературная гладкость, а возможность быстро проверить вывод.
Важно и то, чего система не должна делать. Если источников недостаточно, она не должна догадываться. Лучше вернуть:
- список найденных фрагментов;
- пометку о нехватке контекста;
- запрос на уточнение даты, вида документа или предмета закупки.
Это не слабость продукта, а нормальная часть правового режима.
Что проверять до запуска: не только точность, но и режим ошибки
Юридический RAG тестируют не только на «правильных ответах». Нужны сценарии, где ошибка особенно опасна. Например:
- ответ по неверной редакции;
- смешение основного документа и приложения;
- пропуск исключения из общего правила;
- подмена обязательного требования похожей формулировкой из шаблона;
- неверное толкование закупочной документации по контексту другой процедуры;
- ответ без указания даты действия нормы.
Полезно заранее определить, какие ошибки считаются критическими. Для права это обычно:
- неверный источник;
- неверная редакция;
- неверное применимое исключение;
- отсутствие цитаты;
- ответ без оговорки о неопределённости.
Хорошая практика — заводить набор контрольных вопросов, где правильный ответ известен не потому, что он «похож», а потому, что он подтверждён конкретной нормой и конкретной версией документа. Это намного полезнее, чем абстрактная оценка recall на корпусе.
Практический чек-лист перед первым релизом
- [ ] Есть ли у каждого документа реквизиты версии и статуса?
- [ ] Разделены ли действующие и архивные редакции?
- [ ] Сохраняется ли иерархия статьи, пункта и подпункта?
- [ ] Настроены ли фильтры по дате и типу источника?
- [ ] Есть ли гибридный поиск, а не только embeddings?
- [ ] Возвращает ли система цитату и основание вывода?
- [ ] Проверены ли сценарии с исключениями и устаревшими нормами?
Практический метод для нормативки и закупок
Если свести всё к рабочему маршруту, метод выглядит так:
1. Описать вопросы бизнеса и права.
Не «сделать поиск по документам», а закрыть конкретные типы запросов: редакция на дату, обязательность требования, контекст закупки, связанные нормы.
2. Собрать корпус как правовую структуру.
Не просто PDF-файлы, а документы с реквизитами, иерархией, версиями, отсылками и статусом.
3. Выбрать атомарную единицу и контекст.
Обычно это пункт или подпункт плюс заголовок и соседние элементы.
4. Построить гибридный retrieval.
Точные фильтры, полнотекст, семантика, rerank — в одном маршруте.
5. Заставить ответ ссылаться на источник.
Без ссылки и редакции ответ не считается завершённым.
6. Проверять ошибки как юридические риски.
Не только совпадение текста, но и правильность режима применения.
Именно в таком порядке юридический RAG становится инструментом работы, а не демонстрацией технологии. Векторная база здесь важна, но она — не начало проекта. Начало проекта — в понимании того, как право устроено как объект поиска: с версиями, исключениями, иерархией и ответственностью за каждую строку ответа.
