P7: You Don’t Need a Graph DB (Probably) – Hamel’s Blog - Hamel Husain
Очередная статья из серии Hamel Husain о RAG, основанная на докладе Jo Kristian Bergum — ветерана поиска с 25-летним опытом (Yahoo, Vespa). Главный тезис: серебряной пули не существует, и графовая БД редко нужна, прежде чем исчерпаны более простые варианты. Если документов мало (например, всего 300), а запросов немного, проще загнать всё в контекстное окно — современные модели вроде Gemini держат до 1 млн токенов (около 3 МБ текста). Граф знаний — это набор триплетов (source_entity, relationship, target_entity), который можно хранить в CSV, JSON или Postgres; ранний Facebook держал свой соцграф на MySQL. Перед внедрением любого метода вроде GraphRAG нужно построить «золотой датасет» и измерять результаты метриками MRR, precision и recall. Кроме того, современный векторный поиск через алгоритм HNSW уже основан на графах, так что графоподобные стратегии извлечения можно реализовать без новой инфраструктуры.
Время от времени какая-нибудь технология захватывает внимание индустрии. Сейчас черёд графовых баз данных — их подпитывает желание получить мощный способ дополнять LLM собственными данными. Логика кажется простой: если ваши данные связаны, значит, вам нужен граф.
На протяжении всей этой серии мы доказывали, что наивный одновекторный RAG мёртв, и показывали более продвинутые подходы: более качественные оценки, рассуждение, позднее взаимодействие и множественные представления. Но продвинутость — это не то же самое, что сложность. Нет лучшего примера излишней сложности, чем хвататься за графовую базу данных, не исчерпав более простые варианты.
Именно поэтому я провёл беседу с Jo Kristian Bergum. Jo — 25-летний ветеран в области поиска и извлечения данных, с опытом работы в Yahoo и Vespa. Он один из немногих, кто публично разделяет этот скептицизм.
Jo рассказывает, когда графовые базы данных — это перебор, а когда они имеют смысл.
Ниже приведена аннотированная версия его презентации.
👉 Именно такие вещи мы разбираем в нашем курсе AI Evals. Узнать больше о курсе можно здесь. 👈
Охота за серебряной пулей
Интерес к RAG взрывообразно вырос с конца 2022 года. Над задачами поиска сейчас работает больше инженеров, чем когда-либо. Но это привело к лихорадочным поискам серебряной пули.
Сначала это была специализированная векторная база данных. Теперь, на волне популярности статьи Microsoft о «GraphRAG», маятник качнулся в сторону графовых баз данных.
Jo считает, что такое мышление ошибочно. Не существует единственного инструмента, который решит все ваши проблемы. Желание сопоставить новый приём (GraphRAG) с конкретной технологией (графовой БД) — это ловушка, в которую попадают многие инженеры.
А нужен ли вам вообще RAG?
Прежде чем перейти к графам: нужен ли вам компонент извлечения данных?
Буква «R» в RAG означает retrieval (извлечение). Классическая модель информационного поиска (IR) включает пользователя с информационной потребностью, запрос, систему извлечения и ранжированный список документов.
Когда у LLM были крошечные контекстные окна в 8k, извлечение было необходимостью. Но теперь модели вроде Gemini справляются с 1 миллионом токенов. Это около 3 мегабайт сырого текста — эквивалент старой дискеты.
Jo поделился историей о компании, которая мучилась со сложным RAG-пайплайном. Когда он спросил, сколько у них документов, ответ был — 300. Для такого масштаба он посоветовал им просто загрузить все документы в контекстное окно LLM. Это было проще, дешевле и эффективнее, чем переусложнять стек извлечения.
Если набор ваших документов достаточно мал, а объём запросов невелик, заполнение контекстного окна — вполне рабочая стратегия.
Это перекликается с исследованием Kelly Hong о «гниении контекста» (context rot) (Часть 6). Её эксперименты показали, что производительность LLM ухудшается при наличии отвлекающих факторов (документов, которые похожи, но содержат другую информацию). Когда ваши документы охватывают разные темы с малым пересечением, вы обходите эту проблему стороной. Меньше отвлекающих факторов — меньше гниения контекста.
Но большинство реальных корпусов выглядят иначе. В них есть пересекающийся контент, похожие документы, и они масштабируются за пределы того, что помещается в контекст. Вот тогда извлечение становится необходимым.
Разбираем GraphRAG по косточкам
Так что же такое этот «GraphRAG», вокруг которого столько шума? Этот приём, как описано в статье Microsoft, состоит из нескольких шагов:
Обработка корпуса: используйте LLM, чтобы прочитать всю вашу коллекцию документов. Это дорогостоящий офлайн-процесс. Построение графа знаний: попросите LLM извлечь сущности (узлы) и связи между ними (рёбра). Запрос к графу: во время запроса обходите этот граф в поисках релевантной информации.
Сложность заключается в построении и поддержании графа. Граф знаний — это набор триплетов: (source_entity, relationship, target_entity). Вы можете хранить это в CSV-файле, JSON-объекте или обычной реляционной базе данных вроде Postgres.
Самое трудное — поддерживать всё в точном состоянии. А это значит либо тратить токены на вызовы LLM, либо привлекать к помощи экспертов в предметной области.
Оценка
Как понять, улучшает ли результаты добавление графа знаний или любого другого нового приёма? Это нужно измерять.
Именно этот шаг большинство команд пропускают. Они прыгают от одного нового метода к другому без стабильного эталона. Как Nandan показал в Части 2, вам нужна система оценки прежде, чем вы сможете принимать грамотные решения о приёмах извлечения. В извлечении мы используем такие метрики, как:
Mean Reciprocal Rank (MRR): измеряет, насколько высоко в списке появляется первый релевантный документ. Precision (точность): из возвращённых вами документов сколько было релевантными? Recall (полнота): из всех возможных релевантных документов сколько вы нашли?
Чтобы использовать эти метрики, нужен датасет для оценки. Для этого берётся выборка реальных пользовательских запросов и вручную размечается, какие документы релевантны для каждого запроса. Этот «золотой датасет» — ваша эталонная истина. Он позволяет сравнивать методы извлечения и понимать, является ли изменение улучшением.
Когда стоит использовать графовую базу данных
Когда у вас есть система оценки, вы можете начать задавать правильные вопросы. Специализированная графовая база данных (вроде Neo4j) оптимизирована под быстрый обход графовых структур, обычно за счёт хранения графа в памяти.
Прежде чем добавлять её в свой стек, задайте себе вопросы:
Нужен ли мне быстрый, низколатентный обход графа? Настолько ли велик мой граф, что более простое решение (вроде Postgres или файла) работает слишком медленно? Требует ли мой сценарий использования сложных многошаговых запросов (например, поиска друзей друзей друзей)?
Если ответ на эти вопросы не однозначное «да», то вам, скорее всего, не нужна специализированная графовая БД. Операционная сложность и стоимость добавления ещё одной базы данных в стек высоки. Как отметил Jo, ранний Facebook гонял свой огромный социальный граф на MySQL. С инструментами общего назначения можно зайти на удивление далеко.
Граф, скрытый в вашем векторном поиске
Если вы используете современный векторный поиск, вы уже используете графы.
Самый распространённый алгоритм для приближённого поиска ближайших соседей (ANN) — это HNSW (Hierarchical Navigable Small World). HNSW работает, строя граф, где узлы — это ваши векторы, а рёбра соединяют векторы, близкие в пространстве эмбеддингов. Поиск ближайших соседей означает обход этого графа.
Jo упомянул «кластерную гипотезу» в информационном поиске: документы, похожие на релевантный документ, тоже, скорее всего, релевантны.
Это можно применять с любой векторной БД:
Запустите стандартный векторный поиск по запросу пользователя. Используйте LLM или реранкер, чтобы выявить наиболее релевантные результаты из этого первоначального набора. Выполните второй векторный поиск, на этот раз ища документы, похожие на только что найденные релевантные документы.
Это форма обхода графа (поиск соседей ваших лучших результатов), которая может улучшить полноту (recall). И для этого не нужна специализированная графовая база данных.
Ключевые выводы
В этой серии мы показали вам, как выйти за рамки наивного RAG: более качественные оценки, рассуждение, позднее взаимодействие, множественные представления, инженерия контекста. Но цель никогда не была в сложности ради сложности.
Доклад Jo подтверждает это. Серебряной пули не существует. Прежде чем внедрять новый метод вроде GraphRAG, постройте золотой датасет, чтобы измерить, улучшает ли он производительность (Часть 2). Особые инструменты вам не нужны. Граф знаний может жить в CSV-файле или Postgres. Ранний Facebook гонял свой социальный граф на MySQL. Алгоритмы векторного поиска вроде HNSW уже основаны на графах, так что вы можете реализовать графоподобные стратегии извлечения, не добавляя новую инфраструктуру.
👉 Именно такие вещи мы разбираем в нашем курсе AI Evals. Узнать больше о курсе можно здесь. 👈
Видео
Вот полное видео: