Как устроен RAG для юридических документов и почему одной LLM оказалось недостаточно

[ToxaBes]

Схема, к которой вы пришли уже стала классической схемой RAG-системы. К сожалению, она устарела уже почти на год.

В современной схеме для систем где критична точность (юр отдел, комплаенс, девелопмент) дополнительно используется:

1. контекстуальный чанкинг.

2. версионирование

3. дообучение самой модели под документы

4. дополнительные tools для модели, которые выходят за рамки комментария (diff по 2м документам и тд).

Получается система совсем другого уровня, которая не путает номера и пункты, ставки и даты, а также версии договоров.

[ENick]

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

[ToxaBes]

Ну, человек сам создавал систему для себя, сам пришел к классической (немного устаревшей) схеме, по пути набил шишек, это нормально. А то, что он этим поделился, так вообще хорошо. Насколько я понял, автор не ML-инженер, а юрист. Я видел компании-интеграторы, где ML-инженеры делали хуже, поэтому, наверное, стоит "охладить трахание".

[Ribera-sun]

Видел много ваших ответов сегодня, возможно вы в теме и сможете ответить - насколько реально прямо сейчас перевести отность и powerbi в плоскость тестовых запросов обычных пользователей к модели, которая на лету будет собиратьи показывать цифры?

Условно от "сколько заявок с типом Х было за год", до "сколько было заявок с типом Х, на неделе У от поставщика Z, которые были просрочены на сушки и более".

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

[ToxaBes]

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

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

Подавляющее большинство интеграторов решает эту задачу предоставляя модели прямой доступ к SQL, после чего получается ситуация подобная тому что описали вы. Я уже исправлял подобное в чужой ML-автоматизации, после того как интегаторов и след простыл.

Суть в том, что между LLM и базой данных ставится семантический слой (tools: metrics/dimensions/joins), определенный один раз заранее. Модель не пишет произвольный SQL к сырым таблицам, вместо этого она использует определенные функции (tools) , передавая туда контекст (даты, интервалы, контрагенты) как параметры вызова функций.

Получив точные данные мобель делает то для чего создана: обобщает, анализирует и предлагает выводы не придумывая цифры по различным сферам (заявки/поставщики/просрочка и тд).

При таком подходе результат детерминирован, а точность начинает осторожно щупать 100%. Но этот слой ML-инженеру нормально можно создать только в связке с самими аналитиками, делается это один раз и помогает избежать кучи граблей.

При таком подходе даже облачная фронтир модель не нужна, достаточно локальной модели размером до ~30B. Разница между ними будет не в точности, а в скорости.