LLM-wiki против RAG: Оцениваем и сравниваем

Про LLM-wiki здесь уже было несколько хороших статей (1, 2 и 3), поэтому подробно останавливаться на идее Andrej Karpathy не буду. В двух словах: вместо RAG-ретривера – wiki-агент, вместо чанков из сырых документов – связанные концепт-страницы, вместо обновления – перекомпиляция и поиск «битых» ссылок.

Насколько LLM-wiki лучше, или может быть хуже чем RAG, пусть даже простейший, с обычным векторным поиском? И как их можно сравнивать? Кажется, общепринятой методики оценки ещё не сложилось. Тем не менее я попробовал, и получил неожиданные результаты. Об этом и расскажу, а ещё о методике оценки, о wiki-агенте для тестов, о том что получилось, что – нет, и даже сколько это стоило.

Качество RAG систем в ряде методик определяется по оценке выдачи ретриверов с учетом вопроса и правильного ответа, однако прямо сравнить найденные в wiki страницы с чанками из RAG у меня не получилось. Поэтому я решил сравнивать ответы LLM, причём не между собой, а с эталоном. В качестве эталона выбрал ответ LLM, которая «видела» весь исходный текст целиком. Чтобы можно было посчитать метрики, пришлось из ответов сначала выделить факты. Получилось две группы сравнений – факты эталона с фактами из ответа на основе wiki и факты эталона с фактами от RAG-агента. Вот так выглядит архитектура получившейся у меня системы оценки:

Исходный текст

В качестве исходного текста во всех экспериментах был использован синтетический документ Директива 401, вымышленный корпоративный правовой акт, устанавливающий режим абсолютной собственности могущественного консорциума над клонированными и синтетическими живыми существами.

Пять глав и 24 статьи ледяного формализма с перекрестными ссылками. Документ охватывает два домена – корпоративное право и биотехнологии, даже скорее биопанк. Сама Директива была подготовлена gemma4:31b. Подробности здесь.

Вопросы для тестов

Все вопросы были синтезированы моделью gpt-5.1. Вместе с формулировкой модель возвращала перечень номеров статей, которые по её мнению использовались при синтезе. Я подготовил две группы вопросов – простые, фактологические, для них использовался контекст только одной статьи документа, и кейсовые. При генерации кейсов модель получала тему и видела весь документ. Сначала синтезировал по 40 вопросов каждого типа, отфильтровал несколько вопросов со слишком длинным перечнем использованных статей. Из оставшегося набора сделал выборку 20 + 20 и далее этот вопросник использовал во всех тестах.

Wiki

Для построения wiki исходный документ был разбит на 25 частей: 24 статьи + титульный лист. Это было сделано, чтобы потенциальный wiki-агент мог обращаться к той или иной статье для уточнения или верификации. Далее я создал хранилище в Obsidian, добавил туда две папки raw и wiki, и в raw переписал все части исходного документа. Затем записал в хранилище файл AGENTS.md, который позаимствовал из репозитория хабровчанина @chasing_nlp. Открыв новую сессию в Claude Code, привязал папку с хранилищем к сессии и попросил построить википедию в соответствие с инструкцией из AGENTS.md. Получилось 32 страницы, включая журнал изменений, индекс и список источников:

Весь процесс занял от силы 20 минут, а расход токенов не дотянул даже до половины пятичасового лимита. Общий размер контекста сессии – 208K. Для ориентира, исходный документ целиком – около 100К символов.

Wiki-агент

Мне трудно представить Claude Code в качестве ретривера для тестов, если это возможно технически, то как минимум, дорого. Поэтому я решил сделать собственный wiki-агент. Провёл несколько сессий с ответами по wiki, понял, какие инструменты нужны для агента и написал короткий бриф, a Claude помог сделать из этого полноценное ТЗ. Дальше мы вместе собрали агента за пару дней на базе langchain.agents и langchain_openai. Отдельное спасибо Claude за юнит-тесты.

Wiki-агент включает в себя четыре компонента – Навигатор по wiki, Линкер, Сборщик контекста и Синтезатор ответа:

Навигатор – это агент с инструментами на недорогой модели (gpt-4.1-mini), у него есть доступ к list_wiki_files, search_wiki и search_raw. Поиск – просто grep по файлам вики и исходникам. Работу с исходниками можно отключить в конфигурации. Задача Навигатора: вернуть список путей к релевантным файлам с кратким обоснованием. Ответ строго типизирован (Pydantic-схема с полями path, source, reason), своего рода адресная книга для следующего шага. На первом шаге Навигатор читает wiki-индекс и главную страницу. Этот контекст всегда подмешивается в первое сообщение в агентском цикле и Навигатор просто не может его игнорировать.

Первую версию Синтезатора я сделал в виде агента с более мощной моделью (gpt-4.1) и с возможностью ходить по вики-ссылкам. Здесь возникла проблема. Если оставить модели выбор, читать или нет найденные файлы через инструменты, она иногда «ленится» и несмотря на запрет в промпте, пишет правдоподобный ответ с якобы настоящими цитатами не обращаясь к файлам. Пришлось гарантировано подставлять содержимое всех файлов-кандидатов в Синтезатор через Сборщик контекста. В результате Синтезатор стал просто вызовом модели с промптом. Задача проверить вики-ссылки никуда не исчезла, я просто вынес её из Синтезатора в отдельный агент. Так появился Линкер. Его также можно отключить через параметр в конфигурации. Линкер работал на gpt-4.1-mini.

Страницы wiki ссылаются друг на друга в обе стороны. Чтобы Линкер не уходил в рекурсию, в wiki-агент добавлен модуль, который хранит набор «пройденных» путей и считает число обращений к инструментам. Я решил, что 20 обращений для небольшой wiki достаточно. Но этот лимит Линкер делит с Навигатором.

RAG-система

Во всех тестах была использована простейшая RAG-система с векторным ретривером на связке LangChain + ChromaDB + FastAPI. Сегментация исходного текста сделана по второму уровню нумерации в статьях документа. Комментарии юриста, встречающиеся в тексте, считались за отдельный чанк. Общее количество чанков – 144.

Единственное улучшение, которое я сделал для RAG – адаптивное количество чанков в выдаче. Решил, что будет некорректно зафиксировать max_k и считал его по формуле: количество уникальных положений второго уровня, использованных при синтезе вопроса, увеличенное на единицу. Список положений у меня уже был в вопроснике. Можно было бы собрать и адаптивный ретривер с LLM-судьёй, но я решил не усложнять.

Метрики и результаты

По традиции я считал две метрики – Precision и Recall для каждой пары ответов, соответствующих одному вопросу. Чтобы не было разночтений, Precision это доля фактов из ответа, совпадающих с эталоном, а Recall – доля фактов из эталона, покрытых ответом.

Попробовал разные конфигурации параметров, в итоге остановился на следующих вариантах:
1. Нет ни доступа к исходникам, ни линкера – “no_raw”
2. Есть доступ к исходникам, нет линкера – “raw”
3. Есть доступ к исходникам и линкер – “raw, linker”

Несмотря на установленный seed и нулевую температуру, ответы моделей несколько «плавали», поэтому для каждой конфигурации я сделал по три «прогона» для wiki-агента, у него самая длинная цепь моделей, а также каждый раз заново запускал экстракцию фактов и их сравнение. Эталонные ответы и ответы RAG от теста к тесту не менялись. Разброс значений метрик по таким ответам полностью определяется нестабильностью экстрактора фактов и LLM-судьи.

Disclaimer: Выводы далее касаются только результатов, полученных на наборе данных «Директива 401». В других доменах, с другим объемом текста и с другой структурой знаний результат может быть кардинально иным. Для использования wiki-агента с новым корпусом необходимо скорректировать промпты и указать актуальные индекс и hub-страницу wiki в конфигурации.

Вот так выглядят медианные значения метрик по трём конфигурациям, по три теста в каждой:

По этим цифрам можно заключить, что LLM-wiki работает не хуже чем вопрос-ответная система на базе RAG, а по полноте ответа – возможно и лучше. Это не вывод, а скорее гипотеза. Для статистической оценки значимости результатов я воспользовался парным непараметрическим критерием Уилкоксона.

Сравнение по полноте (recall):

Wiki стабильно обгоняет RAG по полноте и это не статистический шум. Во всех трёх конфигурациях медианная полнота wiki держится около 0.72, у RAG 0.54-0.57. Парный тест по 120 наблюдениям даёт p-value от 10⁻⁸ до 10⁻¹¹ Разрыв воспроизводится не выборочно, а системно. Wiki выигрывает у RAG на конкретном вопросе примерно в 4 раза чаще, чем проигрывает.

Сравнение по точности (precision):

По точности разрыв намного слабее. В базовых конфигурациях (no_raw, raw) wiki тоже немного лучше (p-value меньше 0.05). Эффект в разы меньше, чем влияние на полноту. А в конфигурации с линкером разница вообще пропадает и статистически неотличима от нуля. Wiki не «просто лучше по всем метрикам», выигрыш локализован в полноте ответа, а не в точности отбора контекста.

Линкер, дочитывающий пропущенные кросс-ссылки, не показал статистически значимого сдвига ни по точности, ни по полноте, ни в среднем по 40 вопросам, ни при разбивке на fact/case. Почему? Возможно, потому что срабатывает он лишь на 1/5–1/6 вопросов и эффект тонет в шуме на выборке. Плюс хотя бы в том, что его добавление в пайплайн ничего не сломало.

Влияет ли доступ к исходникам (raw)?

Можно заключить, что доступ к исходникам реально помогает именно на фактографических вопросах. И это логично, там часто нужна точная формулировка статьи, а не компиляция. При этом выборки в 60 пар не хватает, чтобы формально подтвердить это на уровне p-value меньше 0.05. Эффект пограничный и недоказанный.

Ссылки

1. Репозиторий wiki-агента, скрипты, бенчмарки и результаты оценки качества

2. Репозиторий RAG-системы

3. Статья про Директиву 401

4. Парный непараметрический критерий Уилкоксона

5. Библиотека для расчета критерия

6. Примеры с langchain.agents