Графы для работы с языковыми моделями
GraphRAG (графовый RAG) — очень мощный инструмент для использования с языковыми моделями, если знать, когда и как им пользоваться. Если не знать — громоздкий и бестолковый.
Если вы прочитали первый абзац и ничего не поняли, не переживайте: сейчас всё объясню.
Мы прочитаем сегодня статью «When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation» («Когда использовать графы в генерации текстов: детальный анализ генерации на графах знаний»), которая объясняет, когда GraphRAG использовать, а перед этим я коротко расскажу, что это за штука такая.
Краткое введение
Если хочется освежить в памяти, что такое GraphRAG (или познакомиться с ним впервые), загляните на graphrag.com. Там найдёте не только нормальным человеческим языком написанные объяснения, но и список основополагающих статей по теме на случай, если захочется копнуть поглубже.
Если коротко, дело обстоит так: берём языковую модель и набор проверенных источников информации и заставляем эту модель использовать источники для генерации ответов — это RAG (retrieval-augmented generation, я про него писала короткий пост с дополнительными пояснениями, можете глянуть). Он помогает снизить риск галлюцинаций, потому что даёт модели на вход конкретные факты.
Факты (и любые другие объекты) можно представить как узлы и соединить между собой — это граф. А если задать строгий набор правил для представления объектов и их связей, получится граф знаний (knowledge graph).
Существуют графовые базы данных, которые хранят информацию в виде графов, и графы знаний строятся на основе таких баз: там как раз информация представлена в удобном структурированном виде. Граф знаний можно использовать как источник информации в RAG — вот вам и GraphRAG.
Чем он хорош?
Данные организованы по заранее заданным правилам и не съедают всё контекстное окно, потому что граф — компактное представление. Удобно. Более того, модель использует как контекст не весь граф, а только наиболее подходящие под запрос фрагменты.
Контекстное окно — объём текста, который языковая модель может обработать за раз. Если текст больше окна, какой-то его кусок не будет обработан, и содержащаяся в нём информация будет потеряна. Существуют разные способы эту проблему решить, но по умолчанию дело обстоит так.
Чем он порой нехорош?
Он может извлечь больше информации, чем нужно, и ответ получится чрезмерно усложнённый, что занимает много контекстного окна. Запросы к графу для получения нужной информации тоже иногда получаются очень длинные и сложные, что, опять же, забивает контекстное окно и вдобавок снижает эффективность.
Повторюсь: это не серебряная пуля (ничто не серебряная пуля кроме, собственно, серебряной пули). И весь фокус в том, чтобы понять, подходит GraphRAG конкретно под вашу задачу или нет.
Что выяснили авторы
Во-первых, они выяснили, что большинству нынешних систем оценки эффективности GraphRAG не хватает сложных задач, требующих развёрнутого рассуждения и анализа контекста. Вот так, например, выглядит типичная тестовая задача:
«Кто основал компанию Kjaer Weis и в каком городе родился этот человек?»
Сначала надо по графу найти компанию, потом от компании найти основателя, затем информацию о нём. То есть, это простой поиск в несколько шагов. В реальной жизни пользователь скорее спросит что-то вроде:
«Почему компания Kjaer Weis провалилась на рынке X?»
Второй вопрос требует синтеза разных кусков контекста вокруг Kjaer Weis. Чтобы такие случаи точно были покрыты тестами, авторы предложили собственный подход с четырьмя категориями задач:
- поиск фактов (fact retrieval) — это как в первом примере: «Кто основал компанию и где он родился?»;
- сложное рассуждение (complex reasoning) — ближе ко второму примеру, требует объединения нескольких фактов: время выхода на рынок, другие события того же периода, законодательное регулирование и так далее;
- анализ контекста (contextual summarize — здесь именно краткий пересказ объёмного контекста имеется в виду) — следующий уровень после объединения фактов, который подразумевает синтез фрагментированной информации;
- творческая генерация (creative generation) — ещё на шаг сложнее, требует сгенерировать контент, которого в графе не было.
Ещё один вклад работы — сравнение классического (принято говорить “ванильного”; это отсылка на ванильный вкус мороженого как “базовый”) RAG и GraphRAG. Согласно их результатам, классический RAG лучше всего подходит в следующих случаях:
- вопрос простой;
- нужны более свежие данные (это, строго говоря, не про графы как таковые, но графовую базу данных обычно дольше обновлять, тогда как классический RAG может просто сходить в Интернет);
- у вас маленькое контекстное окно и нужны быстрые ответы;
- нужен концентрированный и чистый ответ, содержащий только высокорелевантный контекст.
А вот где, возможно, будет эффективнее задействовать GraphRAG:
- нужны сложное рассуждение, анализ контекста и творческая генерация, а не просто извлечение фактов;
- у вас хорошо структурированные данные, которые можно представить в виде плотного графа (где много связей и есть короткие дорожки от объекта к объекту);
- у вас много данных (я не знаю, при переходе какой границы данных становится «много», но в целом GraphRAG просто более масштабируемый подход, чем ванильный RAG).
Авторы протестировали несколько разных инструментов и оказалось, что результаты они дают очень разные. Поэтому после выбора между RAG и GraphRAG, возможно, вам придётся попробовать несколько конкретных вариантов и посмотреть, какой работает лучше.
И качество данных критично: правило «мусор на входе — мусор на выходе» работает всегда.