Сравнение Graph RAG и SQL RAG

В ходе эксперимента данные были загружены как в графовую базу данных, так и в реляционную базу данных на основе SQL, после чего различные большие языковые модели (LLM) применялись для ответа на вопросы по этим данным с использованием подхода retrieval-augmented generation (RAG). Применение одного и того же набора данных и вопросов к обеим системам позволило оценить, какой парадигма баз данных обеспечивает более точные и информативные результаты.

Retrieval-Augmented Generation (RAG) представляет собой фреймворк искусственного интеллекта, который улучшает большие языковые модели (LLM), позволяя им извлекать релевантную внешнюю информацию перед формированием ответа. Вместо опоры исключительно на знания, полученные в процессе обучения, RAG динамически запрашивает источник знаний (в данной статье это база данных SQL или графовая база) и интегрирует полученные результаты в свой ответ. Введение в RAG доступно в соответствующих материалах.

Базы данных SQL организуют информацию в таблицах, состоящих из строк и столбцов. Каждая строка обозначает запись, а каждый столбец — атрибут. Связи между таблицами определяются с помощью ключей и соединений, при этом все данные соответствуют фиксированной схеме. Такие базы идеально подходят для структурированных транзакционных данных, где важны согласованность и точность — например, в финансах, учете запасов или медицинских записях пациентов.

Графовые базы данных хранят информацию в виде узлов (сущностей) и ребер (связей) с возможными свойствами, прикрепленными к ним. Вместо соединения таблиц они напрямую отображают связи, что обеспечивает быстрый обход связанных данных. Графовые базы оптимальны для моделирования сетей и отношений — таких как социальные графы, графы знаний или карты молекулярных взаимодействий, — где связи не менее важны, чем сами сущности.

Данные

Набор данных, примененный для сравнения эффективности RAG, включает результаты Формулы-1 с 1950 по 2024 год. Он охватывает подробные итоги гонок для пилотов и конструкторов (команд), включая квалификацию, спринтерские заезды, основные гонки, а также времена кругов и пит-стопов. Кроме того, присутствуют таблицы лидеров чемпионатов пилотов и конструкторов после каждой гонки.

Схема SQL

Этот набор данных уже организован в таблицы с ключами, что упрощает настройку базы данных SQL. Ниже представлена схема базы данных:

Таблица Races является центральной и связана со всеми типами результатов, а также с дополнительной информацией, такой как сезоны и трассы. Таблицы результатов также соединяются с таблицами Drivers и Constructors для фиксации их итогов на каждой гонке. Позиции в чемпионатах после каждой гонки хранятся в таблицах Driver_standings и Constructor_standings.

Схема графа

Схема графовой базы данных изображена ниже:

Поскольку графовые базы могут хранить информацию в узлах и связях, для этого требуется всего шесть узлов в сравнении с 14 таблицами в SQL. Узел Car выступает промежуточным, чтобы моделировать, что пилот вел машину конструктора на конкретной гонке. Поскольку пары пилот-конструктор меняются со временем, эта связь определяется для каждой гонки. Результаты гонок фиксируются в связях, например, :RACED между Car и Race. Связи :STOOD_AFTER содержат позиции в чемпионатах пилотов и конструкторов после каждой гонки.

Запросы к базе данных

Для создания цепочки RAG для обоих типов баз данных использовался LangChain, который генерирует запрос на основе вопроса пользователя, выполняет его и преобразует результат в ответ. Код доступен в этом репозитории. Был определен общий системный промпт, подходящий для генерации запросов к любой базе данных SQL или графовой. Единственная специфическая для данных информация включалась путем вставки автоматически сгенерированной схемы базы в промпт. Системные промпты можно найти здесь.

Вот пример инициализации цепочки модели и постановки вопроса: «Какой пилот выиграл Гран-при Бельгии в 1992 году?»

from langchain_community.utilities import SQLDatabase
from langchain_openai import ChatOpenAI
from qa_chain import GraphQAChain
from config import DATABASE_PATH

# connect to database
connection_string = f"sqlite:///{DATABASE_PATH}"
db = SQLDatabase.from_uri(connection_string)

# initialize LLM
llm = ChatOpenAI(temperature=0, model="gpt-5")

# initialize qa chain
chain = GraphQAChain(llm, db, db_type='SQL', verbose=True)

# ask a question
chain.invoke("What driver won the 92 Grand Prix in Belgium?")

Что возвращает:

{'write_query': {'query': "SELECT d.forename, d.surname FROM results r JOIN races ra ON ra.raceId = r.raceId JOIN drivers d ON d.driverId = r.driverId WHERE ra.year = 1992 AND ra.name = 'Belgian Grand Prix' AND r.positionOrder = 1 LIMIT 10;"}}
{'execute_query': {'result': "[('Michael', 'Schumacher')]"}}
{'generate_answer': {'answer': 'Michael Schumacher'}}

SQL-запрос соединяет таблицы Results, Races и Drivers, выбирает гонку на Гран-при Бельгии 1992 года и пилота, финишировавшего первым. LLM преобразовала год 92 в 1992 и название гонки из «Grand Prix in Belgium» в «Belgian Grand Prix». Эти преобразования были выведены из схемы базы данных, которая включала три примера строк для каждой таблицы. Результат запроса — «Michael Schumacher», который LLM вернула как ответ.

Оценка

Теперь основной вопрос заключается в том, лучше ли LLM справляются с запросами к SQL или графовой базе данных. Были определены три уровня сложности (простой, средний и сложный), где простые вопросы решались запросом к данным из одной таблицы или узла, средние требовали одного или двух соединений между таблицами или узлами, а сложные — большего числа соединений или подзапросов. Для каждого уровня сложности подготовлено по пять вопросов. Дополнительно определены пять вопросов, на которые данные базы не позволяют ответить.

Каждый вопрос был решен с помощью трех моделей LLM (GPT-5, GPT-4 и GPT-3.5-turbo), чтобы проанализировать, требуются ли самые передовые модели или более старые и дешевые варианты тоже дают приемлемые результаты. Если модель дала правильный ответ, она получала 1 балл; если указала, что не может ответить, — 0 баллов; за неправильный ответ — -1 балл. Все вопросы и ответы перечислены здесь. Ниже приведены баллы всех моделей и типов баз данных:

Заметно, как более продвинутые модели превосходят простые: GPT-3.5-turbo ошиблась примерно в половине вопросов, GPT-4 допустила 2–3 ошибки, но не смогла ответить на 6–7 вопросов, а GPT-5 правильно решила все, кроме одного. Простые модели лучше работают с SQL, чем с графовой базой, в то время как GPT-5 достигла одинаковых результатов с обеими базами.

Единственный вопрос, на который GPT-5 ошиблась при использовании SQL-базы, — «Какой пилот выиграл больше всего чемпионатов мира?». Ответ «Льюис Хэмилтон, с 7 чемпионатами мира» неверен, поскольку Льюис Хэмилтон и Михаэль Шумахер выиграли по 7 титулов. Сгенерированный SQL-запрос агрегировал количество чемпионатов по пилотам, отсортировал в убывающем порядке и выбрал только первую строку, хотя вторая строка имела то же число титулов.

При использовании графовой базы единственная ошибка GPT-5 — на вопрос «Кто выиграл чемпионат Формулы-2 в 2017 году?», где ответили «Льюис Хэмилтон» (Хэмилтон выиграл Формулу-1, но не Формулу-2 в том году). Это хитрый вопрос, поскольку база содержит только данные Формулы-1, но не Формулы-2. Ожидаемый ответ — указать, что вопрос не может быть решен на основе предоставленных данных. Однако, учитывая отсутствие в системном промпте конкретной информации о наборе данных, такая ошибка понятна.

Интересно, что с SQL-базой GPT-5 дала правильный ответ «Шарль Леклер». Сгенерированный SQL-запрос просто искал в таблице пилотов имя «Шарль Леклер». Здесь LLM, вероятно, осознала отсутствие данных по Формуле-2 и ответила из общих знаний. Хотя это привело к верному ответу в данном случае, такая практика может быть рискованной, когда LLM не использует предоставленные данные. Один из способов снизить риск — явно указать в системном промпте, что база данных должна быть единственным источником для ответов.

Заключение

Это сравнение производительности RAG на наборе данных результатов Формулы-1 демонстрирует, что новейшие LLM работают выдающимся образом, генерируя высоко точные и контекстно осмысленные ответы без дополнительной настройки промптов. В то время как простые модели испытывают трудности, более новые, такие как GPT-5, справляются со сложными запросами почти безупречно. Важно, что между подходами с графовой и SQL-базой данных не наблюдается существенной разницы в производительности — пользователи могут выбирать парадигму, наиболее подходящую для структуры их данных.

Приведенный здесь набор данных служит лишь иллюстративным примером; результаты могут варьироваться при использовании других наборов, особенно тех, что требуют специализированных знаний в области или доступа к непубличным источникам. В целом эти выводы подчеркивают, насколько далеко продвинулись retrieval-augmented LLM в интеграции структурированных данных с рассуждениями на естественном языке.