Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Я не юрист, но чувствую что это прям то что нужно для ведения Change Management и для выяснения причин (root cause analythis) в сложных системах с множеством изменений.
Здравствуйте! Спасибо за ваше внимание к моему материалу :) согласна, что юридическое знание хоть и с особенностями, но на высокоабстрактном уровне не уникально, и эти методы могут работать и в других доменах. Из самого близкого — сложная не юридическая регуляторика (по типу стандартов GMP) или техническая документация. Из близкого по духу приходят в голову богословские тексты :)
Structure-Aware Temporal Graph RAG (далее — SAT-Graph)
Юристы изобрели Version Control...
Предложение - перегнать всю эту историю документов в Git. Возможно, LLM-ы уже умеют со всем этим работать, обучившись на программах.
Со отслеживанием взаимосвязей - так же. Перевести все тексты документов в формально-логический язык, максимально близкий к языкам программирования по семантическому поведению (ну т.е. ссылка на что-то - это вызов функции или что-то похожее) и посмотреть, как с LLM-ы справятся не прямо с сырыми текстами, а вот с такой конверсией.
Может и можно было перенести все в Гит, если бы все эти документы были достаточно структурированы. На деле же базовая версия закона выглядит как один связный документ, а вот дальнейшие изменения уже формулируются, например, так:
п. 1 утратил силу
В п. 3 заменить слова "раз два три" словами "три четыре пять", дополнить абзацем "шесть сем восемь и девять тоже".
Не знаю решена ли проблема построения текущей версии документа из базовой версии и всех ее изменяющих документов в автоматическом режиме, но в автоматизированном видимо решена в системах типа Консультант плюс.
Мне видится польза от применения LLM во все большей автоматизации решения этой проблемы вплоть до полностью автоматического.
На деле же базовая версия закона выглядит как один связный документ, а вот дальнейшие изменения уже формулируются, например, так
Вот именно поэтому и надо перенести в Git. В виде версий со внесёнными изменениями. А все эти "В п. 3 заменить слова" размещать в описании коммита.
Мне видится польза от применения LLM во все большей автоматизации решения этой проблемы вплоть до полностью автоматического.
Что немного дурдом. У программистов решение по сравнению и построению графов изменений сделано давным давно. И работает чисто алгоритмически, без всяких интеллектов. Какая религия запрещает придумать формальный синтаксис и его использовать, а не писать diff-ы словами?
Да даже и без формального - можно каждый раз просто утверждать весь текст целиком, без этих 'diff-ов' а при публикации подсвечивать изменения.
Ну юристы действительно додумались до version control :) как CraftCoderr отметил, справочно-правовые системы отлично умеют сравнивать разные версии, подсвечивая новое и удаленное. С них могла бы начаться какая-то вменяемая работа по перегону нормативного массива в понятные машинам формы. Но есть важные нюансы, в первую очередь организационные, о которых сразу начинаешь думать, когда видишь предложение «перевести всю эту историю»: 1) типов юридических текстов очень много, это не только кодексы и законы. И они абсолютно не унифицированы, и нет никаких общих правил да и даже best practices их ведения и исправления. Даже на уровне федерального законодательства. Если вы думаете о том, что в каждом нормативном акте реально есть логика сопоставимая с синтаксисом языков программирования — увы :) ; 2) есть локально-корпоративный уровень, компаниям хочется собирать документацию в RAGи, но у подавляющего большинства в ней бардак, даже если ее пытаются как-то системно хранить; 3) на то, чтобы заниматься этой работой хоть сколько-нибудь централизованно и по единой методике нужны нечеловеческие организационные усилия и политическая воля (это я и про «общие» нормативные акты, и про уровень отдельных компаний. Мысли о региональном нормативном уровне, особенно каким-нибудь правилам землепользования и застройки вводят в экзистенциальный кризис).
Справедливости ради скажу, что это применимо и к вашей идее, и к этому самому SAT-Graph RAG. Бразильцев вот только на Конституцию пока хватило (а она структурно вообще не очень сложная и, как правило, не претерпевает регулярных изменений).
Ну юристы действительно додумались до version control :)
Нет. Не додумались. Или не хотят использовать. Потому что берем (что тут рядом пробегало). Там же ужас
в подпункте «б» слова «в подпункте «а» настоящего пункта» заменить словами «в подпунктах «а» и «в» настоящего пункта»;
Понять, какой итоговый текст будет и где - это и естественному интеллекту cложно.
Сравним, например, что будет, если пользоваться нормальными инструментами.
Сразу видно что менялось, где, как было до, как стало после. Если использоваться инструментами Code Review - еще и правки можно буквально построчно обсуждать. Видно кто какую правку внес и так далее.
Если вы думаете о том, что в каждом нормативном акте реально есть логика сопоставимая с синтаксисом языков программирования — увы :)
Да. Нет. Но частично применимо. И вот ее надо вычленить (вот тут LLM-ы в помощь), оформить более-менее формальном синтаксисе и в таком виде использовать. А не пытаться сразу по сырым текстам работать.
Вообще, это моя давняя любимая мозоль - юристам уже лет... много пора перестать притворяться, что они на человеческом языке пишут и изобрести формализацию.
А то это выглядит как написание формул словами, как делали до внедрения математической нотации. Только усложняет все.
Спасибо за статью. Сэкономили время на объяснении минусов плоского RAG. Только проектирую внедрение на своей работе, но уже очевидно, что MLR в силу структуры домена (не юридический) лучше ложится.
Скажите, а вы не смотрели в сторону использования fine-tuning (pre-training) подхода или это далеко за пределами использования в виде чат-бота?
Спасибо за добрые слова! А вы в каком домене внедряете?
Я не смотрела. Скажу честно, до вашего комментария я думала, что файнтьюнят только опенсорсные модели (а у меня бот на gemini api работает) :) сейчас просветилась, что это необязательно так. Буду знать! Но вообще для той цели и задач, которые ставятся боту, gemini 2.5 pro справляется великолепно. И нужен боту именно RAG, так как его ценность для пользователей именно в том, чтобы он подыскивал подходящую практику регулятора.
Домен авиабукинга. RAG планирую не для чат-бота, а для, возможно, для агента и файтюн модели, которая сможет автоматизировать часть рутинной работы за счет "понимания" домена. Т.е. если сейчас скормить агенту логи, он по сути механически пересказывает их, не обладая необходимым контекстом такой степени, чтобы это превращалось в бизнес-язык, который позволит решить проблему максимально эффективно и быстро. RAG потому что я с трудом представляют каким еще образом "подложить" модели весь наш корпус документации за несколько лет.
Очень интересная задача! И кажется к ней действительно хорошо подходит rag, особенно если документация хорошо структурирована. Я для своего канала писала еще о таком методе, такая дешево-сердитая альтернатива иерархическим системам.
Спасибо за интересный пост!
Спасибо за статью🙏 очень интересно и познавательно🔥
Вижу, что токены вы экономите, но если важнее качество, то можно рассмотреть AdvancedRAG.
Может ML специалисты меня заклюют, но своё мнение высказал)
А как юристы это всё до LLM искали и обрабатывали? Я тут смотрю на RAG-подход (пытаться найти сразу всё нужное по тексту), и агентный (дать инструменты поиска и анализа через MCP - и пусть сама ищет). И во многих случаях второе работает лучше, хоть и жрет больше токенов.
Т.е. может лучше давать ей поиск, инструмент чтобы доставать историю с дельтами, ходить по ссылкам, доставать выжимки документов? Ну т.е. API от того же UI юридической какой-то БД, и пусть оно само ковыряется?
В Cursor том же именно так делают, а они вроде фишку секут.
всегда до этого юристы пользовались и пользуются сейчас справочно-правовыми системами (гарант, консультант+) и собираемыми по крупицам собственными знаниями по интересующей их сфере (отслеживаешь изменения, новости, мониторишь сайты проектов нормативных актов и регуляторов, ходишь на конференции и курсы и т.п.). в основном обычный поиск по ключевым словам / фильтрам + гугление, подписки на новости. обработка -- руками, мозгами, младшими юристами и стажерами)) у юр.функций крупных компаний есть специальные люди, занимающиеся только мониторингом и аналитикой. по поиску судебной практики сложились определенные техники.
но нужно сказать, что ЛЛМ жизнь не упростили в этом плане, напротив даже, отвратили многих моих коллег: "да она мне придумала суд.практику и постановление правительства!" (been there done that года полтора назад). учиться правильно промптить и знать о возможностях КАК МИНИМУМ включить поиск в интернете хотят далекооо не все.
поисковые агенты в юридических задач принесут всякой ерунды с сайтов типа 9111 или каких-нибудь сео-статей юристов, разводящих бабушек на договоры на пересмотр пенсии. наше знание не в Интернете лежит преимущественно. хотя коллеги, пробовавшие самый дорогой тариф чат жпт говорят, что тот справляется с поиском все лучше и лучше. кто-то осваивает браузер комет активно для таких дел -- но пул задач по-прежнему невелик.
Так я и предлагаю не к интернету прикручивать, а к тому же Консультанту. Дать ей тот же API для поиска, и пусть ищет себе по ключевым, векторным, или историю изменений смотрит.
Мысль тут в том, что вместо того, чтобы делать убер-поиск по векторам, дать те же инструменты что человеку. Оно нормально этим умеет пользоваться. И что удобно человеку - ей тоже норм.
Я, в целом, думаю что всем, кто делает LLM-based продукты, надо присмотреться к Cursor, и как им пользуются. Там же типа «собери инфу про то-то, сложи в файлик», «теперь вот эти файлики посмотри и сделай то-то», «теперь проанализируй что мы делали - и сделай себе инструкцию на будущее». Т.е. там нет попытки сделать магию - чтобы один промпт пишешь и оно само. Там дают инструмент, чтобы вести ее по шагам, и каждый шаг контроллировать.
Мне думается, что с LLM только этот путь более-менее и работает - когда ты командуешь, разбиваешь на подзадачи, и проверяешь каждый шаг. Да, он требует научиться этим пользоваться. Но, видимо, придется всем учиться.
В К+ не дают api, в рынок так точно, и даже не в рынок, а по прямым контактам, говорят, что цена заградительная. Они свои продукты двигать хотят, им это невыгодно) хотя коллеги пытаются заряжать браузер Comet на агентский поиск, но качеством не очень довольны + долго.
Вообще есть мнение, что агенты убьют RAG в зародыше. Но я думаю, что юридическое знание довольно специфическое, чтобы им пользоваться, действительно нужны фундаментальные знания и мышление, которые закладывают юристам в вузах. Там особая логика, на которую еще накладывается практика, иногда регион-специфичная, иногда надо принимать во внимание чуть ли не вебинары, которые регулятор где-то проводит, иногда надо анализировать и предстоящие изменения. Промптить на такое агента... можно, но сложно. Будто даже проще создать библиотеки RAG-баз, и делать грамотные агентские системы, которые будут по ним бегать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rise of RAG: от плоских векторов к темпоральным графам в юридическом домене