ИИ для юристов: Как мы неделю учили нейросеть работать с юридическими шаблонами

Однажды, к нам пришли наши клиенты — юристы и заявили, что наш агрегатор обходит по эффективности их дорогие нейросетевые юридические сервисы. Но! Всегда ведь есть но. Говорят – «Ребята, продукт классный, но нам нужно больше. Научите его работать с нашими внутренними шаблонами документов, искать актуальные нормы права, подбирать свежую судебную практику».

Так родилась задача: создать ИИ ассистента – конструктора юридических документов ^[1], способного генерировать документы на основе проверенных шаблонов. Путь к ее решению оказался куда более извилистым, чем мы предполагали, и растянулся на семь дней интенсивной работы. Если кому интересен сразу результат, то вот он

Обучение модели OpenAI(Fine-Tuning). Первый день

Изначально задача казалась технически простой. У нас на руках было 2000 актуальных юридических шаблонов, предоставленных нашими клиентами-юристами. Логика ^[2] подсказывала прямой путь: Fine-Tuning. То есть, «дообучить» готовую большую языковую модель (LLM) на этом массиве данных. План был прост, как молоток:

1. Загружаем шаблоны.

2. Проводим тонкую настройку модели.

3. Наслаждаемся результатом.

Однако искусственный интеллект ^[3] быстро напомнил нам, что прямолинейность в сложных вопросах редко приводит к успеху.

Первые эксперименты с RAG. День 2-4

Первый же эксперимент обнажил главную проблему. Юридические документы, особенно в рамках одной категории, структурно очень похожи. При обработке тысячи шаблонов модель начала путаться. Текст из одного договора незаметно «перетекал» в другой, реквизиты и условия смешивались, создавая юридическую кашу и галлюцинации. Сгенерированный документ мог быть безупречным с точки зрения ^[4] грамматики, но абсолютно непригодным с позиции права. Попробовали вылечить промптами, но безуспешно.

Вторая проблема упиралась в технологические ограничения. Эффективно дообучить можно было лишь устаревшие модели OpenAI, такие как GPT-3.5, или небольшие локальные LLM. А мы привыкли работать с DeepSeek — моделью, которая, как показала практика, справляется с русским языком и юридическими нюансами лучше продуктов от OpenAI и, при этом, за адекватные деньги. Менять его на менее мощный инструмент не хотелось.

День четвертый: Новый подход — RAG-архитектура

Стало ясно, что заталкивать все знания разом в модель — тупиковый путь. Мы обратились к более изящному решению — RAG (Retrieval-Augmented Generation). Его философия в том, чтобы не переучивать модель, а давать ей нужные знания в момент запроса.

Первый блин вышел комом. Мы поступили по учебнику:

• Пропустили все документы через модель для создания эмбеддингов (векторных представлений текста).

• Сохранили эти вектора в специальную базу данных.

• При запросе пользователя система искала в базе наиболее релевантные фрагменты текста и подставляла их в промпт для DeepSeek.

Стало лучше? Несомненно. DeepSeek в силу своей изначальной мощности выдавал более качественные результаты. Но старые проблемы никуда не делись: система по-прежнему находила неполные фрагменты документов, поиск был неточным, и нейросеть могла «склеивать» информацию из разных источников. С другой стороны, а чего мы ожидали? Fine-Tune примерно так и работает. То-есть, мы сделали тоже самое, но ожидали другого результата. Кто не ошибается, тот ничего не делает.

Развитие мысли с RAG. Пятый день

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

Чтобы не тратить недели на рутинную работу, мы снова призвали на помощь API DeepSeek. Модель помогла нам создать 50 тестовых JSON-файлов, где каждый документ был аккуратно разобран и описан.

Пример нашей разметки:

json

{
  "document_id": "AGENT_DOGOVOR_2025_001",
  "metadata": {
    "document_type": "Агентский договор на привлечение клиентов",
    "primary_category": "Гражданско-правовые договоры",
    "legal_area": "гражданское"
  },
  "search_tags": [
    "агентский договор",
    "привлечение клиентов",
    "вознаграждение агента",
    "ответственность сторон"
  ],
  "document_text": "Тут текст документа"
}

Результат превзошел все ожидания! На тестовой выборке все работало безупречно. Документы находились быстро и точно, нейросеть, получая четко структурированную информацию, генерировала идеальные проекты. Воодушевленные, мы прогнали через DeepSeek оставшиеся 1950 документов.

И снова — кошмар. При масштабировании до полного объема данных старые «болезни» вернулись. Векторный поиск по метаданным и тексту снова начал давать сбои, документы перемешивались. Мы были на правильном пути, но финальный барьер оставался непокоренным.

Очевидная гибридная модель. Дни с 6 по 7

Мы уже готовились к сложной битве с использованием LangChain и построением многоуровневых workflow, как пришла ключевая мысль, настолько простая, что не понимали, как мы сразу об этом не подумали.

А что, если в векторной базе хранить только «указатели» на документы, а сами тексты держать в нетронутом виде отдельно?

Мы кардинально изменили архитектуру:

1. Векторная база теперь хранит только легкие, но идеально описанные метаданные и, главное, — ссылку на документ.

2. Сам документ в чистом виде, отформатированный в Markdown для удобства чтения нейросетью, хранится на сервере.

Да, мы теряем возможность делать поиск по всему тексту документа, но зачем оно нам? Запросы то достаточно четкие, например “Сделай акт сдачи-приемки квартиры”.

Итоговая структура записи в базе:

json

{
  "document_id": "AGENT_DOGOVOR_2025_001",
  "metadata": { ... },
  "search_tags": [ ... ],
  "document_name": "Агентский договор на привлечение клиентов...",
  "document_url": "https://.../Agentskiy_dogovor_2025.txt"
}

День седьмой: Триумф и работающий продукт

Мы загрузили все 2000 документов в новой архитектуре, затаили дыхание ^[5] и начали тесты. И вот оно — сработало!

Алгоритм стал работать безупречно:

1. Пользователь формулирует запрос.

2. Векторный поиск по метаданным и тегам находит 5 самых релевантных шаблонов.

3. Юрист выбирает нужный ему вариант.

4. Система, получив document_url, забирает с сервера полный, неизмененный текст выбранного шаблона.

5. DeepSeek, используя этот эталонный текст как основу, аккуратно подставляет в него данные пользователя и генерирует безупречный документ, строго соответствующий внутренним стандартам юридической фирмы.

Проблема «галлюцинаций» была решена. Нейросеть больше не выдумывала структуру, а строго следовала шаблону. Поиск стал точным, так как работал не с трудноуловимым смыслом целого документа, а с четкими категориями, тегами и названиями. Добавили к этому юридическую оценку самого документа нейросетью и получили прекрасный конструктор документов. Как работает – можете посмотреть сами на бета версии нашего сервиса ИИ ассистентов ^[6] – http://expai.pro ^[7]