Взгляд на лучшие практики, проблемы и уроки проектирования GraphRAG
Делиться
GraphRAG вызывает большой интерес с момента его появления в начале 2024 года. Хотя большая часть онлайн-контента посвящена технической реализации, с точки зрения практика было бы полезно изучить, когда преимущество GraphRAG по сравнению с простым RAG оправдывает дополнительную архитектурную сложность и инвестиции. Поэтому здесь я попытаюсь ответить на следующие вопросы, критически важные для масштабируемой и надежной архитектуры GraphRAG:
- Когда нужен GraphRAG? Какие факторы помогут вам принять решение?
- Если вы решите внедрить GraphRAG, какие принципы проектирования следует учитывать, чтобы сбалансировать сложность и ценность?
- Сможете ли вы после внедрения GraphRAG с одинаковой точностью отвечать на любые вопросы о вашем хранилище документов? Или же существуют ограничения, о которых следует знать и применять методы их преодоления везде, где это возможно?
GraphRAG против Naïve RAG Pipeline
В этой статье все рисунки нарисованы мной, изображения сгенерированы с помощью Copilot, а документы (для графиков) сгенерированы с помощью ChatGPT.
Типичный наивный конвейер RAG будет выглядеть следующим образом:
В отличие от этого, конвейер встраивания GraphRAG будет выглядеть следующим образом. Этапы извлечения и генерации ответа будут рассмотрены в следующем разделе.
Хотя существуют различия в том, как построен конвейер GraphRAG и выполняется ли поиск контекста для генерации ответа, основные отличия от наивного RAG можно свести к следующему:
- В процессе подготовки данных документы анализируются для извлечения сущностей и связей, а затем сохраняются в виде графика.
- Необязательно, но предпочтительно, встроить значения узлов и отношения, используя модель встраивания и сохранить для семантического сопоставления.
- Наконец, документы группируются, внедряются и индексируются для поиска сходства. Этот этап характерен для наивного RAG.
Когда необходим GraphRAG?
Рассмотрим случай помощника по поиску в правоохранительных органах. Материалы расследования представляют собой обширные отчёты о расследованиях, собранные за годы. Каждый отчёт имеет свой идентификатор, указанный в верхней части первой страницы. Далее в документе описываются участвовавшие лица и их роли (обвиняемые, потерпевшие, свидетели, сотрудники правоохранительных органов и т.д.), действующие правовые нормы, описание инцидента, показания свидетелей, изъятые активы и т.д.
Хотя здесь я сосредоточусь на принципе проектирования, для технической реализации я использовал Neo4j в качестве графовой базы данных, GPT-4o для извлечения сущностей и отношений, рассуждений и ответов, а также text-embedding-3-small для встраиваний.
При принятии решения о необходимости использования GraphRAG следует учитывать следующие факторы:
Длинные документы
Наивный RAG-анализатор терял бы контекст или связи между точками данных из-за процесса разбиения на фрагменты. Поэтому запрос типа «Какой идентификатор отчёта, где был замешан автомобиль с номером PYT1234?» вряд ли даст правильный ответ, если номер автомобиля не находится в том же фрагменте, что и идентификатор отчёта, а в этом случае идентификатор отчёта будет находиться в первом фрагменте. Поэтому, если у вас есть длинные документы с большим количеством сущностей (люди, места, учреждения, идентификаторы активов и т. д.), разбросанных по страницам, и вы хотите запросить связи между ними, рассмотрите GraphRAG.
Междокументный контекст
Наивный RAG не может связать информацию из нескольких документов. Если ваши запросы требуют перекрестных связей между сущностями документов или агрегации по всему корпусу, вам понадобится GraphRAG. Например, такие запросы:
«Сколько сообщений о кражах со взломом поступает из Мумбаи?»
«Есть ли люди, обвиняемые по нескольким делам? Каковы соответствующие идентификаторы отчётов?»
«Расскажите мне подробности дел, связанных с банком ABC»
Подобные аналитические запросы ожидаемы в корпусе связанных документов и позволяют выявлять закономерности в несвязанных событиях. Другим примером может служить система управления больницей, где при наличии набора симптомов приложение должно предоставить информацию о похожих предыдущих случаях заболевания и выбранных методах лечения.
Учитывая, что большинству реальных приложений эта возможность необходима, существуют ли приложения, для которых GraphRAG будет излишним, а простой RAG окажется достаточно хорош? Возможно, например, для наборов данных, таких как кадровые политики компаний, где каждый документ посвящен отдельной теме (отпуск, зарплата, медицинская страховка и т. д.), а структура контента такова, что сущности и их связи, а также междокументные связи обычно не являются объектом запросов.
Оптимизация пространства поиска
Хотя вышеперечисленные возможности GraphRAG общеизвестны, менее очевидно, что он является отличным фильтром , позволяющим сузить область поиска по запросу до наиболее релевантных документов. Это чрезвычайно важно для больших корпусов, состоящих из тысяч или миллионов документов. Поиск по векторному косинусному сходству просто теряет гранулярность по мере увеличения количества фрагментов, что приводит к снижению качества фрагментов, выбранных для контекста запроса.
Это несложно визуализировать, поскольку с геометрической точки зрения нормализованный единичный вектор, представляющий фрагмент, — это всего лишь точка на поверхности N-мерной сферы (N — число измерений, генерируемых моделью внедрения), и по мере того, как все больше точек упаковывается в область, они перекрываются друг с другом и становятся плотными до такой степени, что становится трудно отличить одну точку от ее соседей, когда для заданного запроса вычисляется соответствие косинуса.
Объяснимость
Это следствие плотного пространства поиска с встраиванием. Нелегко объяснить, почему определённые фрагменты соответствуют запросу, а другие — нет, поскольку точность семантического сопоставления с использованием косинусного сходства достигает порогового значения, за пределами которого такие методы, как быстрое обогащение запроса перед сопоставлением, перестают улучшать качество фрагментов, извлекаемых для контекста.
Принципы проектирования GraphRAG
Для практического решения, сочетающего сложность, усилия и стоимость, при проектировании графика следует учитывать следующие принципы:
Какие узлы и связи следует извлечь?
Возникает соблазн отправить весь документ в LLM и попросить его извлечь все сущности и их связи. Действительно, он попытается сделать это, если вы вызовете «LLMGraphTransformer» Neo4j без специального запроса. Однако для большого документа (более 10 страниц) этот запрос займёт очень много времени, а результат будет неоптимальным из-за сложности задачи. А когда вам нужно обработать тысячи документов, такой подход не сработает. Вместо этого сосредоточьтесь на наиболее важных сущностях и связях, которые будут часто использоваться в запросах. И создайте звёздчатый граф, соединяющий все эти сущности с центральным узлом (который является идентификатором отчёта в базе данных о преступлениях, может быть идентификатором пациента в приложении больницы и т. д.).
Например, для данных о преступлениях важна степень родства человека с идентификатором сообщения (обвиняемый, свидетель и т. д.), тогда как принадлежность двух людей к одной семье, возможно, менее важна. Однако для генеалогического поиска именно родственная связь является основной причиной создания приложения.
С математической точки зрения легко понять, почему звёздный граф является лучшим подходом. Документ с K сущностями может потенциально иметь K C2- отношений, предполагая, что между двумя сущностями существует только один тип отношений. Для документа с 20 сущностями это будет означать 190 отношений. С другой стороны, звёздный граф, соединяющий 19 узлов с одним ключевым узлом, будет означать 19 отношений, что на 90% снижает сложность.
Используя этот подход, я извлек только данные о лицах, местах, номерах транспортных средств, суммах и названиях учреждений (но не идентификаторы юридических отделов или арестованных активов) и связал их с идентификатором отчёта. График из 10 отчётов по делам выглядит следующим образом и создаётся всего за пару минут.
Принимайте сложность итеративно
На первом этапе (или MVP) проекта сосредоточьтесь на самых важных и частых запросах. И постройте граф для сущностей и связей в них. Этого должно хватить примерно на 70–80 % от требований к поиску. Для оставшихся вы можете улучшить граф в последующих итерациях, найти дополнительные узлы и связи и объединить их с существующим кластером графа. Важно отметить, что по мере появления новых данных (новых случаев, новых пациентов и т. д.) эти документы должны быть проанализированы на наличие всех сущностей и связей за один раз. Например, в кластере графа из 20 сущностей минимальный звездный кластер имеет 19 связей и 1 ключевой узел. И предположим, что на следующей итерации вы добавляете изъятые активы и создаете 5 дополнительных узлов и, скажем, еще 15 связей. Однако, если бы этот документ был новым документом, вам потребовалось бы создать 25 сущностей и 34 связи между ними в одном задании по извлечению.
Используйте график для классификации и контекста, а не для прямых ответов пользователей.
Конвейер поиска и дополнения может иметь несколько вариаций в зависимости от того, используете ли вы семантическое сопоставление узлов и элементов графа и каким образом это делается. После некоторых экспериментов я разработал следующее:
Шаги следующие:
- Пользовательский запрос используется для извлечения соответствующих узлов и связей из графа. Это происходит в два этапа. Сначала LLM составляет запрос Neo4j на основе заданного пользовательского запроса. Если запрос выполнен успешно, мы получаем точное совпадение с критериями, указанными в пользовательском запросе. Например: в созданном мной графе запрос типа «Сколько отчётов из Мумбаи?» даст точное совпадение, поскольку в моих данных Мумбаи связан с несколькими кластерами отчётов.
- Если шифр не даёт ни одной записи, запрос возвращается к семантическому сопоставлению значений узлов графа и связей и находит наиболее похожие совпадения. Это полезно, если запрос выглядит так: «Сколько отчётов из Бомбея?». В результате будут получены идентификаторы отчётов, относящиеся к Мумбаи, что и является правильным результатом. Однако семантическое сопоставление требует тщательного контроля и может приводить к ложным срабатываниям, о которых я подробнее расскажу в следующем разделе.
- Обратите внимание, что в обоих вышеописанных методах мы пытаемся извлечь полный кластер вокруг идентификатора отчёта, связанного с узлом запроса, чтобы обеспечить максимально точный контекст для этапа извлечения фрагмента. Логика следующая:
- Если запрос пользователя касается отчёта с его идентификатором (например, «расскажите мне подробности об отчёте SYN-REP-1234»), мы получаем сущности, связанные с этим идентификатором (люди, лица, организации и т. д.). Таким образом, хотя сам по себе этот запрос редко получает нужные фрагменты (поскольку LLM не придают никакого значения буквенно-цифровым строкам, таким как идентификатор отчёта), с дополнительным контекстом «люди, лица», прикреплённым к нему, и идентификатором отчёта мы можем получить точные фрагменты документа, в которых они встречаются.
- Если запрос пользователя выглядит так: «Расскажите мне об инциденте, в котором участвовал автомобиль с номером PYT1234?», мы получаем идентификатор(ы) отчета из графа, к которому этот номер автомобиля прикреплен первым, затем для этого идентификатора отчета мы получаем все сущности в этом кластере, снова предоставляя полный контекст для извлечения фрагмента.
- Результат графа, полученный на шагах 1 или 2, затем предоставляется LLM в качестве контекста вместе с пользовательским запросом для формулировки ответа на естественном языке, а не в формате JSON, сгенерированном запросом шифра или в формате «узел -> отношение -> узел» семантического соответствия. В случаях, когда пользовательский запрос запрашивает только агрегированные метрики или связанные сущности (например, идентификаторы отчётов, связанные с автомобилем), вывод LLM обычно является достаточно хорошим ответом на пользовательский запрос на этом этапе. Однако мы сохраняем его в качестве промежуточного результата, называемого контекстом графа.
- Затем контекст Graph вместе с пользовательским запросом используется для запроса внедрений фрагментов и извлекаются наиболее близкие фрагменты.
- Мы объединяем контекст графа с извлеченными фрагментами для получения полного комбинированного контекста, который мы предоставляем LLM для синтеза окончательного ответа на запрос пользователя.
Обратите внимание, что в описанном выше подходе мы используем граф в качестве классификатора , чтобы сузить область поиска для пользовательского запроса и быстро найти релевантные кластеры документов, а затем использовать их в качестве контекста для извлечения фрагментов. Это обеспечивает эффективный и точный извлечение из большого корпуса, одновременно предоставляя возможности межсущностного и междокументного связывания, присущие базе данных графа.
Проблемы и ограничения
Как и в любой архитектуре, существуют ограничения, которые становятся очевидны при практическом применении. Некоторые из них обсуждались выше, например, проектирование графа с учётом баланса сложности и стоимости. Вот ещё несколько, о которых следует знать:
- Как упоминалось в предыдущем разделе, семантическое извлечение узлов и связей графа иногда может приводить к непредсказуемым результатам. Рассмотрим случай, когда вы запрашиваете сущность, не извлечённую в кластеры графа. Сначала точное совпадение шифра не удаётся, что ожидаемо, однако резервное семантическое совпадение всё равно вернёт то, что, по его мнению, является похожим совпадением, хотя оно и не имеет отношения к вашему запросу. Это приводит к неожиданному эффекту: создаётся неверный контекст графа, извлекаются неверные фрагменты документа и фактически неверный ответ. Такое поведение хуже, чем ответ RAG «Я не знаю», и должно строго контролироваться подробными отрицательными подсказками LLM при генерации контекста графа, чтобы в таких случаях LLM выдавал «Нет записи».
- Извлечение всех сущностей и связей за один проход из всего документа при построении графа с помощью LLM обычно приводит к пропуску некоторых из них из-за потери внимания, даже при детальной настройке подсказок. Это связано с тем, что LLM теряют память при превышении определённой длины документа. Чтобы снизить этот эффект, лучше всего использовать стратегию извлечения сущностей на основе фрагментации следующим образом:
- Сначала извлеките идентификатор отчета один раз.
- Затем разделите документ на части.
- Извлекайте сущности из фрагмента за фрагментом, и поскольку мы создаем звездный граф, прикрепляйте извлеченные сущности к идентификатору отчета.
Это еще одна причина, по которой звездный график является хорошей отправной точкой для построения графика.
- Дедупликация и нормализация : важно дедуплицировать имена перед вставкой в граф, чтобы корректно создать общие связи между сущностями в нескольких кластерах отчёта. Например, «Офицер Джонсон» и «Инспектор Джонсон» следует нормализовать до «Джонсон» перед вставкой в граф.
- Ещё важнее нормализация сумм, если вы хотите выполнять запросы типа «Сколько сообщений о мошенничестве на суммы от 100 000 до 1 миллиона?». Для этого LLM корректно создаст шифр вида (сумма > 100 000 и сумма < 1000 000). Однако сущности, извлечённые из документа в кластер графа, обычно представляют собой строки типа «5 миллионов», если они присутствуют в документе именно в таком виде. Поэтому перед вставкой их необходимо нормализовать до числовых значений.
- Узлы должны иметь имя документа в качестве свойства, чтобы в результате можно было предоставить базовую информацию.
- Графовые базы данных, такие как Neo4j, предоставляют элегантный способ создания, внедрения и извлечения информации из графа с минимальным написанием кода. Однако существуют случаи, когда поведение данных оказывается странным и необъяснимым. Например, при выполнении некоторых типов запросов, где ожидается получение нескольких кластеров отчётов, LLM формирует идеально сформированный шифр-запрос. Этот шифр извлекает несколько кластеров записей при корректном запуске в браузере Neo4j, однако при запуске в конвейере извлекается только один.
Заключение
В конечном счёте, создание и поддержка графа, точно и подробно представляющего каждую сущность и все взаимосвязи в документе, способного с одинаковой точностью отвечать на любые запросы пользователя, вероятно, потребует слишком больших затрат. Правильный баланс между сложностью, временем и стоимостью станет важнейшим фактором успеха проекта GraphRAG.
Следует также учитывать, что, хотя RAG предназначен для извлечения информации из неструктурированного текста, полный профиль сущности обычно также распределён по структурированным (реляционным) базам данных. Например, адрес, номер телефона и другие данные человека могут присутствовать в корпоративной базе данных или даже в ERP-системе. Для получения полного, подробного профиля события может потребоваться привлечение LLM для запроса таких баз данных с помощью агентов MCP и объединения этой информации с RAG. Но это тема для другой статьи.
Что дальше?
Хотя в этой статье я сосредоточился на архитектуре и дизайне GraphRAG, в следующей статье я планирую рассмотреть техническую реализацию. Она будет включать подсказки, ключевые фрагменты кода и иллюстрации работы конвейера, результатов и упомянутых ограничений.
Стоит подумать о расширении конвейера GraphRAG, включив в него мультимодальную информацию (изображения, таблицы, рисунки) для обеспечения полного пользовательского опыта. Подробнее о создании настоящего мультимодального RAG, возвращающего изображения и текст, читайте в моей статье.
Свяжитесь со мной и поделитесь своими комментариями на www.linkedin.com/in/partha-sarkar-lets-talk-AI
Источник: towardsdatascience.com
