RAG или граф знаний? 2 160 оцененных ответов и влияние модели

Зачем вообще проводить измерения

Дискуссии о корпоративном техническом ассистенте обычно заходят в тупик. Одна сторона выступает за использование RAG, другая — за граф знаний; у обеих есть веские аргументы, но ни у кого нет цифр. Контролируемый эксперимент может их предоставить: два подхода, три семейства моделей, три повторения и 120 вопросов с эталонными ответами, что даёт 2 160 оценённых ответов. Каждый ответ оценивался с помощью детерминистической метрики и группой из трёх судей.

Результаты менее удовлетворительны, чем хотелось бы кому-либо. Абсолютного победителя нет, направление эффекта меняется в зависимости от модели, а переменная с наибольшим влиянием — это не та или иная стратегия, а выбор модели, работающей в системе.

Для краткого ознакомления:

• Граф превзошёл RAG с статистически значимым преимуществом лишь в одной из трёх моделей.
• Комиссия судей отдала предпочтение RAG во всех трех случаях.
• Замена модели улучшила качество больше, чем замена стратегии.
• Набор данных является синтетическим, а ключи ответов были составлены экспериментатором, что ограничивает возможности переноса полученных результатов.

Сначала рассматриваются ограничения, поскольку именно они определяют, стоит ли читать остальное.

Что охватывает и чего не охватывает исследование

В нем измеряется, какая стратегия поиска данных даёт более точные, полные и легко отслеживаемые ответы об экосистеме микросервисов, причём модель генерации остаётся неизменной при каждом сравнении.

В нём не измеряется практическая полезность для реальных разработчиков, затраты на техническое обслуживание со временем, качество с точки зрения специалистов в данной области, а также поведение системы при работе с реальной документацией, содержащей несоответствия и пробелы.

Он также не учитывает ограничения, связанные с верхней границей графа. Приведённый здесь граф намеренно прост: он включает соседние узлы на расстоянии одного шага и размытое сопоставление сущностей. Граф, способный обрабатывать запросы на несколько шагов и выполнять глобальную агрегацию, мог бы отвечать на вопросы, на которые не может ответить этот граф, поэтому часть недостатков графа, указанных в таблицах, связана с реализацией, а не с самой парадигмой.

Проблема

Компания перешла на микросервисы. Там, где раньше вся кодовая база помещалась в одном модуле, теперь существует десятки сервисов, контрактов, событий и баз данных. Знания разбросаны по документам README, внутреннем каталогу, панели управления операциями и у трех человек, которые знают их наизусть. Ежедневные вопросы кажутся простыми, но они дорогостоящи: в каком приложении хранятся личные данные, от чего зависит сервис X, существует ли уже решение и можно ли его повторно использовать? Сегодня ответ на такие вопросы — спросить у кого-то или прочитать документацию, которая может быть устаревшей, причем настоящая стоимость заключается не во времени поиска, а в техническом решении, принятом на основе устаревшей информации.

Беседующий ассистент мог бы решить проблемы с доступом, если бы он был специализирован на данной области, и в литературе предлагаются два пути решения.

Неструктурированный поиск (RAG) разбивает документацию на фрагменты, индексирует их в векторном хранилище, извлекает отрывки, наиболее похожие на вопрос, и включает их в запрос. Термин был введён Льюисом и его коллегами в 2020 году, а Гао и его сотрудники рассмотрели последние достижения в этой области. Его сложно поддерживать, но он позволяет адаптироваться к изменениям без переобучения; однако он неэффективен, когда для ответа требуется логическое обоснование на основе явных связей.

Структурированный поиск (граф знаний) моделирует экосистему в виде узлов и рёбер с указанием типов: сервис, команда, событие, база данных, зависимость. Запросы в такой системе детерминированы и поддаются отслеживанию, хотя создание и управление графом сопряжены с высокими затратами. Обзор графов знаний, представленный Хоганом и его коллегами, является стандартным источником информации.

Эти два подхода сливаются в технологии GraphRAG, и именно к этому указывают результаты данного эксперимента.

Дизайн

Самое важное решение принимается ещё до написания кода: меняться может только уровень знаний. Без этого правила сравниваются две реализации, а не две стратегии. Любые отличия в формате запроса или результата влияют на итог таким образом, что их невозможно позже разделить, и именно поэтому многие неформальные тесты RAG в итоге оценивают навыки того, кто составил запрос.

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

Для тестирования требовалась реалистичная, публикуемая и воспроизводимая среда, и использование реальной среды работодателя было невозможно. Поэтому для тестов была создана вымышленная компания CreditXPTO — финтех-компания, занимающаяся личными кредитами, которой на самом деле не существует:

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

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

В части RAG используются фрагменты длиной 512 токенов с перекрытием 50 токенов и параметром top-k равным 5. Эмбеддинги генерируются с помощью модели BAAI/bge-small-en-v1.5, запущенной локально, причем в качестве хранилища векторов используется Qdrant. Метод плотного поиска основан на схеме, предложенной Карпухиным и его коллегами (DPR); эмбеддинги предложений взяты из Sentence-BERT, а семейство моделей BGE описано в документе C-Pack.

В части, связанной с графами, используется библиотека NetworkX в памяти; графы создаются непосредственно из исходных файлов, поэтому они всегда совпадают с данными. Сопоставление сущностей осуществляется фаззи-методом с порогом 70/100, причем поиск производится в пределах одного шага от текущей сущности.

Оценка

Оценка осуществляется на двух уровнях. Первый уровень является эвристическим: он учитывает лексическое сходство, наличие ключевых сущностей и степень охвата исходного текста. Этот метод дешев, детерминирован и воспроизводим, но при этом поверхностен, поскольку наказывает парафразирование. Это известный недостаток метрик на основе перекрытия n-грамм, и именно поэтому существуют семантические альтернативы, такие как BERTScore.

Второй уровень предполагает участие трех судей-ИИ из разных семейств моделей, которые оценивают точность, полноту, обоснованность и ясность от 0 до 3 баллов. Парадигма использования ИИ в качестве судьи была утверждена Чжэнгом и его коллегами с помощью MT-Bench.

Важен один момент: основная метрика рассчитывается между разными семействами моделей. При оценке каждого ответа судья из собственного семейства генератора исключается из расчетов. Модели распознают собственный текст и ставят ему более высокую оценку; Panickssery и его коллеги (2024) связывают такую предпочтительность с самораспознаванием. Единственный способ нейтрализовать это явление — структурные меры, а не просьбы о беспристрастии в запросе.

Значимость выводится с помощью парного теста Макнемара, поскольку обе стратегии отвечают на одни и те же вопросы. Для определения интервалов используется метод бутстрапа с 5 000 переотборов данных, а степень согласия судей оценивается с помощью коэффициента Каппы Коэна.

Результаты

В первой таблице приводится точность в строгом смысле, при которой учитываются только полностью правильные ответы; в каждой ячейке n = 360:

Важны два показателя.

Во-первых, результаты зависят от выбранной модели. Метод RAG демонстрирует преимущество при использовании двух генераторов, а графовый подход — при использовании третьего; значимой является именно эта разница. Проведение эксперимента с одной моделью, как это делается в большинстве тестов, привело бы к уверенному, но ошибочному выводу вместе с диапазоном доверия; в результатах не было бы никаких намеков на это.

Во-вторых, разница между моделями превышает разницу между подходами. Переход с claude-sonnet-4-6 на gpt-5.5 приносит большую пользу, чем смена стратегии внутри одной и той же модели. Это ставит вопрос «RAG или графовый подход?» на второй план, и это является общим выводом исследования.

Повторение теста с более широким определением, при котором начисляются полные и частичные баллы, а наказание применяется только за явные ошибки, меняет ситуацию. Теперь RAG значительно превосходит первые два модели, а преимущество графовой модели у третьей уже не становится значительным. Точное толкование заключается в том, что сила RAG заключается не в том, чтобы чаще быть правым, а в том, чтобы при ошибках они были менее серьезными. Когда извлечение информации происходит частично, модель дает неполные ответы. Когда сопоставление сущностей не удается, графовая модель дает неверные ответы, но делает это уверенно. Для внутреннего ассистента это различие имеет решающее значение: разработчик может дополнить неполный ответ, но неверный ответ с указанием источника может быть использован на собрании.

Результаты оценки жюри будут показаны далее:

Комиссия отдает предпочтение технологии RAG для всех трех моделей, включая ту, в которой геуэристика присвоила графу значительное преимущество. Это эффект инструмента, а не противоречие. В одном конкретном случае вопрос получил показатель лексического сходства 0,25 и был признан неверным согласно геуэристике, однако комиссия поставила ему оценку 2,88 из 3. Ответ был правильным, просто сформулированным иначе. Метрики N-gram измеряют словарный состав, а инструменты оценки LLM — воспринимаемую правильность с субъективным искажением. Ни один из них в одиночку не может дать ответа на вопрос, и когда они расходятся, это указывает на необходимость дальнейшего анализа.

Комиссии следует честно отметить: согласованность между судьями была лишь умеренной, с показателем Каппы Коэна от 0,09 до 0,56. Комиссия из судей LLM — это не инструмент для измерения точности. Это структурированное второе мнение, и именно потому, что оценка генерации с использованием улучшенного поиска остается открытой проблемой, существуют такие инструменты, как RAGAS.

Что касается задержки, RAG работал на 12–20% быстрее на всех трёх моделях. Контекст графа более компактен, но запрос требует дополнительного шага. Стоимость варьируется в зависимости от модели: граф оказался дешевле при использовании двух генераторов и дороже — при использовании одного. Соотношение входных и выходных токенов сильно различается у разных поставщиков, что влияет на итоговую стоимость. Это наблюдение, а не вывод, поскольку состав токенов не проверялся формально.

Почему каждый подход неэффективен

Это самая полезная часть, которая отсутствует в таблицах.

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

RAG несостоятелен из-за неполноты. Он правильно определяет, что сервис использует Redis, но ограничивается только найденным сервисом, когда вопрос требует общей картины.

Оба подхода ошибочны, но по-разному. Недостатки взаимодополняют друг друга, и именно поэтому очевидным решением является гибридный подход с маршрутизацией в зависимости от типа вопроса.

Рекомендации

• Сначала выберите модель. Это переменная с наибольшим влиянием. Рассматривать её как деталь реализации и тратить недели на настройку размера фрагментов означает оптимизацию параметра второго порядка.
• Начните с RAG. У него более надёжные характеристики и дешевле обслуживание, к тому же способ его сбоя является приемлемым.
• Добавляйте структуру постепенно, для обеспечения взаимозависимостей, определения владельцев и обработки событий. Не пытайтесь моделировать весь экосистему до того, как что-либо представите.
• Не полагайтесь на один показатель. Используйте детерминистические гедонистические методы и наборы из разных категорий. Когда они противоречат друг другу, это означает наличие интересного случая, а не бага.
• Используйте парные тесты. Обе стратегии отвечают на одни и те же вопросы, но сравнение средних значений без метода Макнемара не даёт той уверенности, которая требуется.

Ограничения

• Набор данных является синтетическим, а ключ ответов составлен самим исследователем. Его не проверяли реальные пользователи. Это обеспечивает контроль и воспроизводимость, но снижает внешнюю валидность.
• Реализация графика преднамеренно проста, поэтому некоторые слабости при агрегации могут быть связаны с самой реализацией, а не с принципами подхода.
• Практическая полезность и возможность обслуживания не измерялись. Они входили в число целей, но оставались качественными показателями.
• Эвристика не проверялась по сравнению с человеческим суждением. Группа экспертов смягчает эту проблему, но не решает её полностью.
• Одиннадцать из 2 160 ответов (0,51%) были связаны с ошибками сети поставщика, а не с ошибками системы.

Вывод

Изначально предполагалось закончить с формулировками вроде «использовать граф» или «использовать RAG». Однако оказалось, что ни один из этих вариантов невозможен до тех пор, пока не будет решена проблема выбора модели, причем переменная, рассматриваемая как фоновая, оказывала наибольшее влияние. Это менее удовлетворительно, но более практично. Этот подход также применим в других случаях: критерий оценки с скрытой переменной не дает явных ошибок, а указывает на них с помощью диапазона доверия. Прежде чем выбрать архитектуру на основе чисел, необходимо выяснить, что именно было сохранено в эксперименте и действительно ли это должно было оставаться неизменным.

Связанные материалы

• Расширенные технологии RAG в производственных условиях: архитектура, инструменты и компромиссы — Обзор реализации RAG в производстве: входные данные, парсинг, разбиение на фрагменты, генерация эмбеддингов, хранилища векторов, гибридные методы поиска, переранжирование результатов, оценка эффективности и меры безопасности, а также компромиссы, связанные с каждым из этих аспектов.
• GraphRAG против Vector RAG: почему векторный поиск терпит неудачу при масштабировании и как помогает GraphRAG — Vector RAG сталкивается с проблемами при изоляции фрагментов, обработке информации из нескольких документов и масштабировании. Рассматривается, как GraphRAG решает эти проблемы с помощью формирования структурированных сообществ и кратких обзоров, а также когда следует выбирать тот или иной подход.

ROE против TechRAG: GraphRAG на Docker и Qdrant или на SQLite и LanceDB — Два подхода к одной концепции GraphRAG: Qdrant, MongoDB и модель объемом 120 млрд параметров против LanceDB, SQLite и модели qwen2.5 объемом 7 млрд параметров, с сравнением логики поиска и извлечения информации и извлечением уроков.