Графы знаний в юридическом домене: как не потерять сложность при построении RAG-системы

[itGuevara]

1. В KGDB данные встраиваются в топологию графа и хранятся явно, например, в виде RDF-триплетов (атомарные смысловые сущностей вида "субъект – предикат – объект"), которые позволяют представить множество связей между парами сущностей в обрабатываемом текстовом фрагменте (у каждой сущности есть свои наименование, тип и атрибуты).

Это понятно, а есть примеры реализации в корпоративных системах (не semantic web)?

[Sergey_Slepukhin]

Спасибо за вопрос!

RDF-триплеты в начале статьи упомянуты, скорее, как понятный пример и концептуальная модель («субъект → предикат → объект»), а не как технический стандарт W3C. В production-системах, как правило, используется другая, более гибкая модель — property graph (https://en.wikipedia.org/wiki/Property_graph). Такая модель является, конечно, более гибкой по сравнению с жесткой формальной семантикой RDF с URI, SPARQL-запросами и проч. (как в semantic web).

Например, эта модель хранения данных используется в популярной KGDB - Neo4j. Запросы в СУБД пишутся на языке Cypher, который позволяет гибко описывать паттерны обхода графа. Например, запрос - " найти все законы, регулирующие право собственности", может выглядеть как-то так:

MATCH (закон)-[:РЕГУЛИРУЕТ]->(n {name: "право собственности"})
RETURN закон

В общем, подключив такую графовую СУБД к популярным фреймворкам автоматического построения графов (GraphRAG, LightRAG и др.), получаем полноценную production-систему с масштабируемым хранилищем.

Интересный кейс в тему построения системы в корп конуре - GraphRAG AI-ассистент, который понимает Жилищный кодекс РФ, опубликован автором сравнительно недавно.

При этом, GraphRAG, по умолчанию, хранит граф в виде Parquet- и CSV-файлов, без графовой СУБД как таковой, хотя "прикрутить" ту же Neo4j возможно.

А вот в LightRAG Neo4j нативно поддерживается через конфиг. Кстати, если вам не нужно масштабирование KGDB на миллионах узлов, можно использовать NetworkX, простая Python-библиотека для работы с графами, которая держит всё в оперативной памяти (для прототипирования точно подойдет).

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

[itGuevara]

А вот в LightRAG Neo4j нативно поддерживается через конфиг. Кстати, если вам не нужно масштабирование KGDB на миллионах узлов, можно использовать NetworkX, простая Python-библиотека для работы с графами, которая держит всё в оперативной памяти (для прототипирования точно подойдет).

Мне ближе js (не python) и linked data. Вот пример реализации (прототип) semantic BPM на популярных js-lib для LD.
Надеюсь, что появится в этом ключе что-то из semantic DWH. А с LLM\RAG - или без, это уже не столь принципиально. При "семантизации" (онтология + LD-формализм) предприятия рычаги LLM\RAG усилят эффект, но на мой взгляд семантизация первична.