Однажды, к нам пришли наши клиенты — юристы и заявили, что наш B2C(на секундочку) агрегатор с правильным промптом обходит по эффективности их дорогие нейросетевые юридические сервисы. Но! Всегда ведь есть но. Говорят — «Ребята, продукт классный, но нам нужно больше. Научите его работать с нашими внутренними шаблонами документов, искать актуальные нормы права, подбирать свежую судебную практику».
Так родилась задача: создать ИИ ассистента — конструктора юридических документов, способного генерировать документы на основе проверенных шаблонов. Путь к ее решению оказался куда более извилистым, чем мы предполагали, и растянулся на семь дней интенсивной работы. Если кому интересен сразу результат, то вот он
Обучение модели OpenAI(Fine-Tuning). Первый день
Изначально задача казалась технически простой. У нас на руках было 2000 актуальных юридических шаблонов, предоставленных нашими клиентами-юристами. Логика подсказывала прямой путь: Fine-Tuning. То есть, «дообучить» готовую большую языковую модель (LLM) на этом массиве данных. План был прост, как молоток:
Загружаем шаблоны.
Проводим тонкую настройку модели.
Наслаждаемся результатом.
Однако искусственный интеллект быстро напомнил нам, что прямолинейность в сложных вопросах редко приводит к успеху.
Первые эксперименты с 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, как пришла ключевая мысль, настолько простая, что не понимали, как мы сразу об этом не подумали.
А что, если в векторной базе хранить только «указатели» на документы, а сами тексты держать в нетронутом виде отдельно?
Мы кардинально изменили архитектуру:
Векторная база теперь хранит только легкие, но идеально описанные метаданные и, главное, — ссылку на документ.
Сам документ в чистом виде, отформатированный в Markdown для удобства чтения нейросетью, хранится на сервере.
Да, мы теряем возможность делать поиск по всему тексту документа, но зачем оно нам? Запросы то достаточно четкие, например «Сделай акт сдачи-приемки квартиры».
Итоговая структура записи в базе:
json
{ «document_id»: «AGENT_DOGOVOR_2025_001», «metadata»: { … }, «search_tags»: [ … ], «document_name»: «Агентский договор на привлечение клиентов…», «document_url»: «https://…/Agentskiy_dogovor_2025.txt» }
День седьмой: Триумф и работающий продукт
Мы загрузили все 2000 документов в новой архитектуре, затаили дыхание и начали тесты. И вот оно — сработало!
Алгоритм стал работать безупречно:
Пользователь формулирует запрос.
Векторный поиск по метаданным и тегам находит 5 самых релевантных шаблонов.
Юрист выбирает нужный ему вариант.
Система, получив document_url, забирает с сервера полный, неизмененный текст выбранного шаблона.
DeepSeek, используя этот эталонный текст как основу, аккуратно подставляет в него данные пользователя и генерирует безупречный документ, строго соответствующий внутренним стандартам юридической фирмы.
Проблема «галлюцинаций» была решена. Нейросеть больше не выдумывала структуру, а строго следовала шаблону. Поиск стал точным, так как работал не с трудноуловимым смыслом целого документа, а с четкими категориями, тегами и названиями. Добавили к этому юридическую оценку самого документа нейросетью и получили прекрасный конструктор документов. Как работает — можете посмотреть сами на бета версии нашего сервиса ИИ ассистентов — http://expai.pro
Источник: habr.com
