Юридический RAG: почему поиск по законам начинается с карты документов
Юридический RAG часто начинают с технического вопроса: какую векторную базу взять и как нарезать документы на фрагменты. Для обычной справочной базы это может быть рабочим стартом. Для права этого мало. Нормативный документ важен не только текстом, но и типом акта, датой, редакцией, юрисдикцией, связью с другими документами, основанием применения и тем, можно ли цитировать найденный фрагмент как действующий.
Поэтому юридический RAG лучше начинать не с векторов, а с карты документов. Сначала нужно понять, какие объекты есть в базе: закон, постановление, контракт, положение, письмо, судебный акт, приложение, редакция, пункт, статья, требование. Потом нужно описать связи между ними. И только после этого выбирать, как искать: по смысловой близости, по ключевым словам, по реквизитам, по фильтрам или через несколько этапов.
Векторная база здесь остается полезной. Например, Qdrant поддерживает payload и фильтры, а также гибридные запросы. Но сама возможность фильтрации не заменяет модель предметной области. Если в payload нет нормальных полей, фильтровать нечего. Если документы не разбиты по юридически значимым границам, похожий фрагмент может выглядеть убедительно, но вести к ошибочному выводу.
Что здесь меняется
Обычный RAG отвечает на вопрос: какой фрагмент похож на запрос. Юридический RAG должен отвечать осторожнее: какой фрагмент относится к нужному типу документа, действует в нужной ситуации, связан с правильной редакцией и может быть показан как источник ответа.
Если этого слоя нет, система начинает смешивать похожие, но разные вещи. Например, находит старую редакцию вместо новой, общий обзор вместо нормы, похожий договор вместо применимого документа или комментарий вместо первичного источника. Для пользователя ответ может звучать уверенно, но юридическая опора будет слабой.
Главное:Юридический RAG начинается не с вопроса "куда положить embeddings", а с вопроса "какие правовые объекты мы ищем и как проверяем, что ответ опирается на правильный документ". Векторная база нужна, но она должна работать поверх карты документов, метаданных, фильтров и проверки цитат.
Практическая схема
| Слой | Что нужно описать | Зачем это нужно |
|---|---|---|
| Документ | тип, дата, редакция, источник, статус | не смешивать разные юридические объекты |
| Фрагмент | статья, пункт, приложение, абзац | цитировать точное место, а не весь файл |
| Метаданные | юрисдикция, тема, участник, период | применять фильтры до смыслового поиска |
| Связи | изменяет, отменяет, уточняет, ссылается | не терять контекст нормы |
| Проверка | цитата, действующая редакция, confidence | отделять ответ от догадки модели |
В инженерном контуре это превращается в простой порядок работ. Сначала собираем словарь типов документов. Потом описываем поля, которые должны попадать в индекс. Затем решаем, где нужен точный фильтр, а где смысловой поиск. После этого добавляем оценку качества: насколько найденные фрагменты релевантны запросу, не противоречит ли ответ источникам, достаточно ли цитат для проверки.
Метрики из RAGAS полезны именно как язык проверки. Context precision помогает смотреть, сколько полезных фрагментов попало в найденный контекст. Faithfulness помогает оценивать, опирается ли ответ на переданный контекст, а не на фантазию модели. Для юридического RAG это не академическая тонкость, а рабочая страховка.
Какой навык из этого собрать
Рабочий навык для человека и агента звучит так: перед тем как строить юридический поиск, нарисовать карту документа. Не красивую схему для презентации, а операционную карту: какие объекты есть, какие поля у них обязательны, какие связи важны, какие фильтры должны применяться раньше смыслового поиска, какой источник считается первичным.
Для Codex это можно превратить в повторяемую задачу. Дать агенту папку документов, попросить не писать код сразу, а сначала собрать document_map.yaml: типы документов, поля, связи, риски, тестовые вопросы. Потом уже строить прототип индекса и проверять его на запросах.
Где граница
Эта статья не советует одну конкретную базу данных для всех юридических задач. Qdrant, Elasticsearch, PostgreSQL с расширениями или другой стек могут быть уместны в разных условиях. Главный выбор не в названии инструмента, а в качестве модели документов.
Если база маленькая и задача простая, иногда достаточно аккуратного поиска с фильтрами. Если документов много, появляются версии, права доступа, разные источники и ответственность за ответ, нужен полноценный контур: ingest, нормализация, индексация, retrieval, проверка, журналирование и ручная приемка.
