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

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

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

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

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

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

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

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

Первые эксперименты с RAG. День 2–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 документов в новой архитектуре, затаили дыхание и начали тесты. И вот оно — сработало!

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

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

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

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

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

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

Проблема «галлюцинаций» была решена. Нейросеть больше не выдумывала структуру, а строго следовала шаблону. Поиск стал точным, так как работал не с трудноуловимым смыслом целого документа, а с четкими категориями, тегами и названиями. Добавили к этому юридическую оценку самого документа нейросетью и получили прекрасный конструктор документов. Как работает — можете посмотреть сами на бета версии нашего сервиса ИИ ассистентов — expai.pro.