Как графы знаний учат LLM меньше галлюцинировать

У больших языковых моделей есть странная суперсила: они умеют говорить так уверенно, что порой кажется — они точно знают. Проблема в том, что уверенность и знание — не одно и то же.

Когда одной памяти мало: как LLM учат искать факты не в тексте, а в графе

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

Авторы статьи о PersonalAI 2.0, или PAI-2, предлагают довольно практичный ответ на эту проблему. Они берут LLM, добавляют к ней внешнюю память в виде графа знаний и, что особенно важно, заставляют систему не просто извлекать ближайшие фрагменты, а строить план поиска, пересматривать его по ходу дела и ходить по графу итеративно. Получается не «нашли кусок текста — сгенерировали ответ», а мини-расследование: что именно нужно узнать, какие сущности важны, куда идти дальше, хватает ли уже данных или план стоит переписать.

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

Что именно предлагают авторы

В центре статьи — архитектура PAI-2, системы вопросно-ответного поиска по графу памяти. Этот граф хранит знания, извлеченные из документов: сущности, утверждения, связи и эпизодические записи. Поверх этого графа работает LLM, но не как всезнайка, а как диспетчер поиска.

Ключевая идея проста: сложный вопрос редко стоит решать одним запросом. Вместо этого PAI-2 разбивает задачу на этапы:

1. при необходимости очищает и уточняет вопрос;

2. определяет, не состоит ли он из нескольких независимых подвопросов;

3. строит начальный план поиска;

4. извлекает именованные сущности из текущего шага;

5. сопоставляет их с вершинами графа;

6. генерирует вспомогательные запросы-подсказки;

7. обходит граф от найденных точек;

8. фильтрует релевантные триплеты;

9. суммирует найденную информацию;

10. проверяет, достаточно ли ее для ответа;

11. если нет — улучшает план и идет дальше.

То есть система не просто достает «самое похожее», а ведет поиск по частям, с промежуточной проверкой: а мы вообще движемся туда?

Это и есть главное отличие от многих вариантов GraphRAG: там поиск часто остается довольно статичным. В PAI-2 он адаптивный. Если на середине маршрута выяснилось, что исходный план был слишком расплывчатым или упустил важную сущность, система может его переписать.

Почему это вообще важно

У обычных систем поиска с генерацией есть фундаментальная слабость: они хорошо работают, когда ответ лежит рядом с запросом в одном-двух фрагментах текста. Но как только нужно связать несколько документов, восстановить цепочку сущностей или уточнить промежуточный факт, качество начинает проседать. Возникают галлюцинации, обрывочные ответы или уверенное «нет данных», хотя данные в базе на самом деле есть.

Граф знаний в этом смысле удобен как внешняя память: он явно хранит связи между объектами. Но одного графа тоже мало. Если просто делать поиск по узлам, без стратегии, система может утонуть в шуме или, наоборот, пройти мимо нужного маршрута.

PAI-2 интересен тем, что сочетает два мира:

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

Как устроен поиск: не один запрос, а серия догадок

Методологически статья выглядит как инженерная работа с большим количеством практических деталей. Авторы явно не пытались придумать «новую теорию интеллекта» — они строят систему, которую можно разложить на понятные модули и протестировать по частям.

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

Затем найденные триплеты не просто скармливаются модели списком. Сначала ответы генерируются для каждого вспомогательного запроса, а потом агрегируются в единое знание для текущего шага плана. После этого LLM решает: уже можно отвечать или нужно искать дальше.

Важная деталь: авторы отдельно показывают, что механизм улучшения плана — не украшение, а реально рабочий компонент. Если его отключить, качество заметно падает. Логика понятна: многие вопросы невозможно корректно решить с первого чернового маршрута. Нужна возможность переобуться на ходу.

Что показали эксперименты

PAI-2 тестировали на шести известных наборах данных для вопросно-ответных задач: Natural Questions, TriviaQA, HotpotQA, 2WikiMultihopQA, MuSiQue и DiaASQ. В качестве соперников взяли LightRAG, RAPTOR, HippoRAG 2 и предыдущую версию системы — PAI-1.

Главная метрика — оценка через LLM-судью. Это уже довольно привычный подход в задачах, где простое совпадение строк мало что говорит о правильности ответа. Авторы отдельно проверили надежность такой оценки на человеческой разметке и получили высокую корреляцию, так что метод оценки здесь выглядит достаточно добросовестно.

Если кратко, результаты такие:

По бенчмаркам картина не совсем ровная. Лучше всего система выглядит на TriviaQA, 2WikiMultihopQA и MuSiQue — то есть как раз там, где многоскачковый поиск особенно важен. На Natural Questions у PAI-2, наоборот, есть заметный разрыв с HippoRAG 2. Авторы честно объясняют возможные причины: вопросы там часто плохо нормализованы, написаны строчными буквами, а тип ожидаемого ответа не всегда очевиден. Для системы, которая любит явные сущности и аккуратное планирование, это неприятный режим.

Самая сильная абляция: планирование действительно работает

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

Изначально система формирует шаги вроде «кто режиссер первого фильма», «кто режиссер второго фильма», «из какой страны режиссер первого фильма», «из какой страны режиссер второго фильма». Но проблема в том, что последние два шага слишком расплывчаты: без подстановки конкретных имен поиск легко промахивается.

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

Это звучит почти банально, но именно в таких мелочах часто и лежит разница между «архитектурой на слайде» и реально работающей системой. Здесь планирование — не красивое слово, а механизм уточнения запроса по мере накопления знаний.

Что еще важно: качество самой памяти

У таких систем есть два уровня качества. Первый — как хорошо агент ищет. Второй — насколько добротна сама память, по которой он ходит. Если граф строится плохо, никакой умный поиск уже не спасет.

Авторы отдельно оценивают свой конвейер построения графа на бенчмарке MINE-1, который измеряет, сколько фактической информации из исходного текста сохранилось в графе. И здесь у PAI-2 очень сильный результат: 89% сохранения информации, что заметно выше, чем у Wikontic и KGGen в приведенном сравнении.

Это, возможно, даже не менее важно, чем успехи в вопросно-ответных тестах. Потому что внешняя память для LLM умирает в двух случаях: если из нее плохо искать и если в нее плохо записывать. PAI-2, судя по статье, старается закрыть обе проблемы сразу.

Ограничения, о которых авторы не молчат

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

Во-первых, система медленная. По их замерам, PAI-2 примерно вдвое медленнее PAI-1: в среднем около 1,5 минуты на один вопрос. Для исследования это терпимо, для промышленного применения — уже вызов. Узкие места предсказуемы: инференс LLM, векторный поиск и обход графа.

Во-вторых, в текущем виде граф страдает от дубликатов на уровне смысла. Если одна и та же мысль сформулирована по-разному, могут появляться несколько похожих подграфов. Отсюда и необходимость в нескольких вспомогательных запросах на один шаг.

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

Итог

PAI-2 — это не очередная работа в духе «мы просто прикрутили граф к LLM». Ее главный тезис тоньше: для надежного ответа мало иметь память, нужно уметь по ней думать маршрутом. Разбивать вопрос, строить план, уточнять сущности, запускать несколько траекторий поиска, проверять промежуточную достаточность фактов и при необходимости переписывать стратегию.

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

Главный вывод здесь такой: структурированная память без планирования слишком тупа, а LLM без внешней памяти слишком самоуверенна. PAI-2 пытается соединить лучшее из обоих миров — и, судя по результатам, делает это весьма убедительно.