Как мы создали AI-юриста: архитектура RAG-системы для работы с юридическими документами

Когда заказчик пришёл с задачей создать интеллектуального юридического помощника, формулировка звучала просто:

«Нам нужен AI-юрист, который сможет искать нормы права, анализировать документы, готовить юридические тексты и отвечать на вопросы пользователей».

На бумаге — почти обычный чат-бот.

На практике — совсем другая история.

Потому что в юридической сфере есть одна маленькая особенность:

ошибка нейросети может стоить не лайка под постом, а проигранного дела.

Если обычный чат-бот придумал несуществующий факт — это неприятно.

Если юридический помощник придумал несуществующую статью закона, номер судебного дела или позицию суда — это уже проблема.

Юристу нужен не «умный собеседник».

Ему нужен помощник, который умеет сказать:

«Я не нашёл подтверждения. Давайте уточним данные».

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

Нужно было построить систему, где модель будет максимально полезной, но при этом будет ограничена реальными источниками.

Другими словами:

дать ИИ юридический мозг, но не дать ему юридическую фантазию.

Моя роль в проекте

Сразу обозначу честно: я не был тем человеком, который в одиночку написал всю архитектуру и за выходные собрал «российский Harvey AI».

Такие истории хорошо выглядят в Twitter, но обычно имеют мало общего с реальностью.

Основную инженерную часть делала команда разработчиков:

• архитектура системы;
• инфраструктура;
• пайплайны обработки данных;
• RAG-контур;
• интеграции;
• backend.

Моя зона ответственности была связана с тем, что обычно выглядит менее эффектно на презентациях, но именно там часто решается судьба AI-продукта:

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

И, как это обычно бывает с LLM-проектами, большая часть времени ушла не на «запустить модель», а на объяснение модели, почему иногда лучше промолчать, чем уверенно придумать ерунду.

---

Почему обычного ChatGPT оказалось недостаточно

Первая ошибка, которую часто делают при создании подобных решений:

«Давайте просто дадим модели юридические документы и спросим её».

Звучит логично.

Но есть проблема.

Большая языковая модель не является юридической базой данных.

Она не открывает внутренний шкаф с законами и не достаёт оттуда нужную статью.

Она прогнозирует наиболее вероятное продолжение текста.

А вероятность и юридическая достоверность — это разные вещи.

Модель может написать очень убедительный ответ:

• с правильным стилем;
• с юридическими формулировками;
• с красивыми ссылками.

И при этом половина этих ссылок может существовать только в её воображении.

Это и есть классическая проблема галлюцинаций.

Поэтому мы строили не просто LLM-приложение.

Мы строили систему с опорой на источники.

---

Архитектура системы: четыре уровня контроля

Мы разделили решение на несколько слоёв.

И это было одно из самых важных архитектурных решений.

Потому что если дать модели решать всё сразу, получится примерно как нанять одного человека одновременно быть юристом, секретарём, архивариусом и администратором базы.

Технически возможно.

Но через неделю все будут искать виноватого.

---

1. Пользовательский слой: где начинается диалог

На верхнем уровне находились пользовательские интерфейсы:

• Telegram-бот;
• внутренняя административная панель.

Telegram использовался для общения с системой.

Админ-панель была нужна для управления:

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

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

«Почему вчера он отвечал нормально, а сегодня решил, что Гражданский кодекс написан в 1998 году?»

И в этот момент нужны не молитвы, а нормальные логи.

---

2. Слой бизнес-логики: диспетчер запросов

Следующий уровень отвечал за маршрутизацию.

Главная задача:

понять, что вообще хочет пользователь.

Потому что запрос:

«Проверь мой договор»

и запрос:

«Подготовь иск по этому договору»

могут выглядеть похожими.

Но внутри это совершенно разные сценарии.

Система определяла:

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

Это был важный момент.

Хороший юридический помощник должен не только отвечать.

Иногда он должен остановиться и спросить:

«А где дата договора?»

или:

«Уточните, кто является ответчиком».

Потому что настоящий юрист тоже не пишет иск, имея половину фактов.

---

3. RAG-слой: место, где начинается настоящая инженерия

Вот здесь была самая интересная часть.

В систему загружался большой массив юридических документов:

• нормативные акты;
• судебные решения;
• договорные шаблоны;
• пользовательские документы.

Но проблема была не просто «загрузить файлы».

Юридические документы — это не обычные тексты.

В статье закона важен:

• номер статьи;
• глава;
• пункт;
• связь с другими нормами.

В судебном акте важны:

• суд;
• дата;
• номер дела;
• обстоятельства;
• мотивировочная часть;
• резолютивная часть.

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

Формально все слова будут на месте.

Смысл — потерян.

Поэтому мы уделили большое внимание подготовке данных.

---

Самая неприятная часть любого AI-проекта — данные

Есть красивая теория:

«Берём документы → индексируем → получаем умную систему».

А потом приходит реальность.

Реальность выглядит примерно так:

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

И начинается любимая игра разработчиков:

«Почему модель ошиблась?»

Ответ:

«Потому что мы дали ей прекрасный хаос».

Поэтому пришлось приводить данные к единой структуре.

Мы сделали отдельный процесс синхронизации и загрузки:

META_SYNC → MAIN_LOADER

Он отвечал за:

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

Особое внимание уделяли судебным актам.

Потому что в юридической практике часто самое важное находится не в начале документа.

А в конце.

Та самая резолютивная часть.

Где суд фактически говорит:

«Вот решение. Вот кто прав. Вот что делать дальше».

---

Поиск документов: почему одного векторного поиска мало

Внутри использовался RAG-подход.

Но важный момент:

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

Он хорошо понимает смысл.

Например:

«Ответственность за нарушение условий поставки»

и

«Последствия ненадлежащего исполнения договора поставки»

для него близкие темы.

Но когда юрист спрашивает:

«Дело № А40-123456/2025»

ему нужен не смысл.

Ему нужен конкретный номер.

Поэтому система учитывала несколько факторов:

• смысловой поиск;
• ключевые слова;
• метаданные;
• фильтрацию по типу документа.

После этого найденные фрагменты проходили дополнительную обработку и только затем попадали в контекст модели.

---

4. LLM-слой: модель, которая должна знать границы

После поиска система передавала модели:

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

Но здесь начиналась самая интересная часть.

Промпты.

---

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

Есть распространённое мнение:

«Промпт — это просто написать пару предложений для нейросети».

После нескольких месяцев работы с юридическим AI хочется немного улыбнуться.

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

В нём нужно определить:

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

Были разные сценарии:

• анализ договоров;
• подготовка исков;
• работа с судебной практикой;
• поиск норм права.

И каждый требовал своей логики.

---

Главная борьба: заставить модель не быть слишком умной

Парадокс LLM:

чем она умнее выглядит, тем опаснее её ошибки.

Модель очень хочет помочь.

Иногда слишком сильно.

Например:

Пользователь:

«Найдите судебную практику по этому вопросу».

Плохой ответ:

«Известно дело № А55-12345/2021…»

Проблема:

этого дела может не существовать.

Хороший ответ:

«В доступной базе не найдено подтверждённых судебных актов по указанному критерию».

Для человека это выглядит менее впечатляюще.

Для юридической системы — намного ценнее.

---

Двухфазный режим работы

Мы реализовали разделение работы на два этапа.

Этап 1. Анализ

Система определяет:

• достаточно ли информации;
• какие данные отсутствуют;
• какие документы нужны.

Если данных мало — задаёт вопросы.

Этап 2. Выполнение задачи

После сбора информации:

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

Такой подход оказался гораздо стабильнее.

Потому что в юридической работе правильный вопрос иногда ценнее неправильного ответа.

---

Работа с памятью: не «помнить всё подряд»

Отдельный момент — контекст.

Можно было сделать простую историю сообщений.

Но для юридической системы это опасно.

Нельзя просто хранить бесконечный чат.

Поэтому память была управляемой.

Система сохраняла:

• состояние задачи;
• ключевые факты;
• ссылки на документы;
• необходимые элементы дела.

Но не превращала каждый предыдущий разговор в огромный мешок информации.

---

Как мы проверяли систему

Тестирование было построено не по принципу:

«Ответ выглядит красиво — значит работает».

Проверялись конкретные сценарии:

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

Особое внимание уделяли негативным сценариям:

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

Потому что именно такие ситуации показывают реальное качество AI.

---

Что в итоге получилось

В результате мы получили систему, которая умеет:

✅ искать юридическую информацию в большом массиве документов;

✅ анализировать пользовательские файлы;

✅ готовить проекты юридических документов;

✅ вести диалог с сохранением контекста;

✅ объяснять ответы с опорой на источники;

✅ запрашивать дополнительные данные вместо генерации догадок.

Самое важное:

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

Это неправильная цель.

Хороший AI в юридической сфере — это не адвокат вместо адвоката.

Это инструмент, который снимает рутину:

• поиск;
• анализ больших объёмов текста;
• подготовку черновиков;
• структурирование информации.

---

Главный вывод после проекта

После таких задач начинаешь иначе смотреть на большие языковые модели.

Сначала кажется:

«Нужно просто подключить GPT».

Потом проходит неделя.

Потом месяц.

И ты понимаешь:

главная сложность не в самой модели.

Модель уже умеет говорить.

Сложность — научить её:

• где искать;
• чему доверять;
• когда молчать;
• как проверять себя.

Потому что хороший AI-помощник — это не тот, кто всегда отвечает.

Это тот, кто знает цену ошибке.

И иногда самая умная фраза, которую может сказать нейросеть:

«Мне нужны дополнительные данные, чтобы не ввести вас в заблуждение».