Первоначальная RAG-система для работы с юридическими документами использовала стандартную схему: разбиение на фрагменты, эмбеддинги, векторный поиск и LLM. Однако такой подход оказался недостаточно точным при поиске конкретных реквизитов, дат или номеров договоров, где семантический поиск уступал место необходимости точного совпадения.
Для повышения качества внедрен гибридный поиск: BM25 для точных совпадений и BGE-M3 для смысловой близости, объединенные через Reciprocal Rank Fusion. На корпусе из 401 документа показатель Recall@10 составил 0,935. Попытка добавить reranker не принесла успеха: метрика снизилась до 0,806–0,871, поэтому компонент был исключен из рабочей конфигурации.
В систему добавлен слой маршрутизации, который направляет запросы к SQL-базам или RAG-конвейеру на основе детерминированных правил. Маршрутизация проходит 21 из 21 теста на наборе регрессии. Для отладки каждому запросу присваивается trace_id, что позволяет отслеживать путь прохождения данных и выявлять этапы, на которых возникают ошибки.
Архитектура разделяет извлечение фактов и принятие решений. LLM отвечает за извлечение данных и формулировку ответов, тогда как бизнес-логика и проверка критических чисел выполняются обычным кодом. Это исключает галлюцинации модели при оценке рисков и обеспечивает воспроизводимость результатов, так как правила не меняются при смене модели.
Разработчик отмечает, что сложные методы вроде reranking или агентного поиска не всегда эффективны. Новые компоненты внедряются только при наличии измеримой проблемы. Если данных недостаточно или ситуация неоднозначна, система не пытается сгенерировать уверенный ответ, а передает задачу человеку, так как в юриспруденции убедительный ответ не всегда является корректным.
