Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 9
Подход правильный, но автором с ютуба он реализован с ручной разметкой, в реальном диалоге не кто не будет размечать граф заранее, у меня по похожему принципу устроен мой агент, тоже граф, тоже достает из памяти перед ходом LLM, но не как источник прямых знаний, а как подсказка для модели, в какую сторону копать.
Из ручного там только основа онтологии: определение узлов и связей между ними. Остальную работу делает LLM. Причём желательно более умная, чем та, что будет использоваться в качестве "движка" агента, который будет отвечать на вопросы. Благо делается это разово на основном объёме документов, а дальше — инкрементально по мере их обновления.
Ну тогда автор изобрел велосипед, потому что такая концепция уже давно работает Microsoft GraphRAG
GraphRAG я тестировал, когда он вышел. И на практике он себя особо не проявил.
Смысл же экспериментов, представленных здесь, заключается в минималистичной демонстрации того, почему иногда стоит потратить ресурсы на представление данных для RAG в графовой форме. У автора разница была видна только для Haiku. В моём эксперименте разница есть для всех моделей классом ниже.
Вот о том же думал, когда читал. По сути вручную же создали графы "под задачу".
Я Так понимаю, что сложность графовой базы как раз в том, чтобы
правильно составлять эти связи при создании
корректно обновлять при изменении документов
Если инструкция изменится или человека заменят - как найти документ и понять какие связи нужно обновить?
По сути вручную же создали графы "под задачу".
Не совсем так. Онтология там вполне универсальная:
Сущности:
PERSON·ROLE·POLICY·PROCESS·DOCUMENTОтношения между ними:
approved_by·held_by·delegates_to·part_of·references
Разложить в такую онтологию деятельность компании, в которой не полный бардак в процессах, должно быть не так уж и сложно.
Если инструкция изменится или человека заменят - как найти документ и понять какие связи нужно обновить?
Типовое решение: атрибуты временных интервалов для отношений.
Данный мини-эксперимент не отрицает того, что создание по сути Knowledge Graph — непростой процесс. Я помню подкаст с сотрудниками Deloitte, где ведущий под конец им задал вопрос: "Если всё так круто, то почему же все этого не делают?". На что ответом было: "Потому, что это сложно".
Акцент здесь на другом: если сместить ресурсы на подготовку данных, т.е. на тот самый Knowledge Graph, то это значительно облегчит этап интеграции с LLM. В моём примере видно, что их можно "менять как перчатки" разных размеров: от 2b до 20b.
По сути вручную же создали графы "под задачу".
Не совсем так. Онтология там вполне универсальная:
Сущности:
PERSON·ROLE·POLICY·PROCESS·DOCUMENTОтношения между ними:
approved_by·held_by·delegates_to·part_of·references
Разложить в такую онтологию деятельность компании, в которой не полный бардак в процессах, должно быть не так уж и сложно.
Если инструкция изменится или человека заменят - как найти документ и понять какие связи нужно обновить?
Типовое решение: атрибуты временных интервалов для отношений.
Данный мини-эксперимент не отрицает того, что создание по сути Knowledge Graph — непростой процесс. Я помню подкаст с сотрудниками Deloitte, где ведущий под конец им задал вопрос: "Если всё так круто, то почему же все этого не делают?". На что ответом было: "Потому, что это сложно".
Акцент здесь на другом: если сместить ресурсы на подготовку данных, т.е. на тот самый Knowledge Graph, то это значительно облегчит этап интеграции с LLM. В моём примере видно, что их можно "менять как перчатки" разных размеров: от 2b до 20b.
Тут вопрос вот какой. Агент сам "догадался" что надо посмотреть график отпусков, проверить до какой суммы имеет право подписи тот или иной сотрудник? Мы можем придумать какой то иной сценарий, и он сработает?
Я всегда думал, что графовая база нам никакой особой магии не дает. Просто избавляет от необходимости делать монстрические джойны, когда нам нужно собрать данные из кучи связанных документов.
Например я хочу проверить что участники тендера на госзаказ не имеют родственников в администрации.
С реляционной базой мне нужно было бы открыть для каждой компании таблицу учередителей. Потом для каждого человека посмотреть сведения о его родственников в другой таблице. А дальше сджойнить с таблицей сотрудников администрации. Если в базе сотни тысяч компаний - это операция может быть довольно тяжелой. В графовой базе всё это куда проще можно организовать. НО агенту всё равно же понадобится специальный инструмент, верно? Или агент способен понять структуру графа и сам определить, как найти нужную инфо?
Агент сам "догадался" что надо посмотреть график отпусков, проверить до какой суммы имеет право подписи тот или иной сотрудник?
Нет, вводные подаются ему на вход вместе с остальным контекстом. Это ключевой момент подхода.
Мы можем придумать какой то иной сценарий, и он сработает?
У автора в репозитории ещё 4 вопроса, которые работают по тому же принципу.
НО агенту всё равно же понадобится специальный инструмент, верно?
Да. Таким инструментом является запрос, который матчит ключевые слова из пользовательского вопроса на сущности из графа и рекурсивно возвращает всё, что с этими сущностями связано, в виде контекста для LLM.
Или агент способен понять структуру графа и сам определить, как найти нужную инфо?
Нет. Агент тут работает с контекстом, который ему передан посредством предыдущего механизма.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как с помощью graph RAG добиться многоходовых рассуждений от LLM с 2B весов