Comments 9
Схема, к которой вы пришли уже стала классической схемой RAG-системы. К сожалению, она устарела уже почти на год.
В современной схеме для систем где критична точность (юр отдел, комплаенс, девелопмент) дополнительно используется:
контекстуальный чанкинг.
версионирование
дообучение самой модели под документы
дополнительные tools для модели, которые выходят за рамки комментария (diff по 2м документам и тд).
Получается система совсем другого уровня, которая не путает номера и пункты, ставки и даты, а также версии договоров.
"""Способ улучшения поиска был основан на данных, которые к тому моменту перестали соответствовать содержимому базы.""" за это студентам двойки ставят, а у юристов это такой высший пилотаж, что не стыдно такое всем показывать? Может сапоги тачать оставим сапожникам?
Ну, человек сам создавал систему для себя, сам пришел к классической (немного устаревшей) схеме, по пути набил шишек, это нормально. А то, что он этим поделился, так вообще хорошо. Насколько я понял, автор не ML-инженер, а юрист. Я видел компании-интеграторы, где ML-инженеры делали хуже, поэтому, наверное, стоит "охладить трахание".
Видел много ваших ответов сегодня, возможно вы в теме и сможете ответить - насколько реально прямо сейчас перевести отность и powerbi в плоскость тестовых запросов обычных пользователей к модели, которая на лету будет собиратьи показывать цифры?
Условно от "сколько заявок с типом Х было за год", до "сколько было заявок с типом Х, на неделе У от поставщика Z, которые были просрочены на сушки и более".
Причем перевести так, чтобы не приходилось после каждой пачки неверных ответов сажать живого аналитика и разбираться почему модель не смогла собрать данные, хотя у нее есть полное описание полей с синонимами, все формулы рассчетов и прочее? Понимаю вопрос слишком кратко задан, но всё же.
Причем перевести так, чтобы не приходилось после каждой пачки неверных ответов сажать живого аналитика и разбираться почему модель не смогла собрать данные, хотя у нее есть полное описание полей с синонимами, все формулы рассчетов и прочее? Понимаю вопрос слишком кратко задан, но всё же.
Вы вполне понятно описали проблему. Еще год назад я бы сказал, что с приемлимой точностью это не сделать, но этот год бустанул вообще все сферы применения ML и эту тоже.
Подавляющее большинство интеграторов решает эту задачу предоставляя модели прямой доступ к SQL, после чего получается ситуация подобная тому что описали вы. Я уже исправлял подобное в чужой ML-автоматизации, после того как интегаторов и след простыл.
Суть в том, что между LLM и базой данных ставится семантический слой (tools: metrics/dimensions/joins), определенный один раз заранее. Модель не пишет произвольный SQL к сырым таблицам, вместо этого она использует определенные функции (tools) , передавая туда контекст (даты, интервалы, контрагенты) как параметры вызова функций.
Получив точные данные мобель делает то для чего создана: обобщает, анализирует и предлагает выводы не придумывая цифры по различным сферам (заявки/поставщики/просрочка и тд).
При таком подходе результат детерминирован, а точность начинает осторожно щупать 100%. Но этот слой ML-инженеру нормально можно создать только в связке с самими аналитиками, делается это один раз и помогает избежать кучи граблей.
При таком подходе даже облачная фронтир модель не нужна, достаточно локальной модели размером до ~30B. Разница между ними будет не в точности, а в скорости.
Видимо слишком серьезно отношусь к юристам как спецам, умеющим работать с документами
Я имел ввиду, что он сделал решение сам для себя и ответственный в итоге он, что с ИИ что без него.
Стремление автоматизировать свою работу это признак профессионала. Ну и что, что поначалу это велосипед с квадратными колесами и без сидения, доработает со временем.
Я тоже, первые свои харнессы писал для себя сам еще до того как это стало называться харнессом и глядя из сегодняшнего дня, там абсолютно нечем гордиться.
Как устроен RAG для юридических документов и почему одной LLM оказалось недостаточно