Wikontic: строим графы из текстов, используя онтологию и LLM

Привет, Хабр! Это Алла, я работаю исследователем в команде «Модели с памятью» Лаборатории когнитивных систем искусственного интеллекта Института AIRI и занимаюсь исследованиями на стыке графов знаний и языковых моделей. Ранее я уже писала на Хабре статью про построение графов знаний из текстов по мотивам одной из наших публикаций.
Мы активно продолжаем работать дальше и создали Wikontic — полноценный пайплайн для этой задачи. Недавно мы представляли его на интерактивной демо‑сессии на AAAI 2026 в Сингапуре — про это несколько дней назад вышел хабр от моего коллеги Айдара. Здесь я расскажу подробнее о том, как устроен новый пайплайн, и какие идеи пришли к нам в голову при его создании.

Графы знаний как структура для более качественного поиска

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

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

Одним из решений этой проблемы стали подходы RAG (Retrieval‑Augmented Generation). Идея проста: вместо того чтобы полностью полагаться на знания модели, мы дополняем её контекст релевантными текстами, найденными по запросу. Так модель может «подтягивать» свежие факты и точную информацию из внешних источников. Но и тут есть нюансы.

• RAG‑системы обычно разбивают тексты на фрагменты, теряя при этом структуру и взаимосвязь между ними.

• Стандартные методы, основанные на семантической близости текстов, не всегда гарантируют, что найденные документы действительно содержат точную фактологическую информацию.

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

Графы знаний представляют информацию в явном виде триплетов «субъект‑отношение‑объект». Такая форма позволяет выполнять на графе проверяемые запросы, итеративные обновления и многошаговые размышления (например, при ответе на сложносоставные вопросы, multi‑hop QA), что делает KG надежным дополнением как к LLM, так и к RAG.

Впоследнее время появились методы, позволяющих использовать структуру графов для более эффективного поиска по текстам. Например, GraphRAG извлекает из текстов сущности и отношения между ними для формирования графа. Далее GraphRAG формирует иерархические саммари для кластеров в полученном графе и использует полученную структуру для эффективного поиска релевантной информации по запросу. Другой метод, HippoRAG, извлекает из текстов сущности‑фразы и отношения между ними с помощью LLM. Затем из текста‑запроса извлекаются сущности, которые используются как стартовые при запуске алгоритма Personalized PageRank для поиска ответа на построенном до этого графе.
Но такие методы используют графы знаний в качестве вспомогательных структур для поиска по текстам, а не рассматривают их в качестве самостоятельных источников фактов. Отсутствие фокуса на качестве графа приводит к тому, что триплеты в таких графах часто содержат разнородные сущности и отношения, на самом деле являющиеся синонимами. Например, “NYC, located in, USA” и “New York City, is in, United States”. Это фрагментирует графы на избыточные и/или несогласованные представления. Синонимия и вариации триплетов накапливаются с увеличением масштаба, нивелируя сильные стороны, которые в первую очередь мотивировали использование графов: точность, интерпретируемость и логическая согласованность.

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

Что такое онтология?

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

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

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

Wikontic

Wikontic — это пайплайн для построения высококачественных, онтологически согласованных графов знаний непосредственно из неструктурированного текста.

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

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

1. Извлечение кандидатов триплетов уточняющими метаданными для сохранения контекста,

2. Корректировка триплетов с учетом онтологии,

3. Нормализация и дедупликация сущностей.

Эти этапы обеспечивают структурную согласованность и уменьшают избыточность графа. Так мы получаем более четкую и логичную структуру, способную заменить исходные тексты для надёжного поиска, reasoning‑задач и использования в RAG‑сценариях.

Теперь давайте рассмотрим компоненты и этапы Wikontic.

Схема онтологии и текущий граф

Wikontic хранит схему онтологии, полученную из Wikidata, для использования правил при верификации и корректировании извлеченных LLM фактов. Для хранения этих правил используется база данных, включающая отношения (predicates в Wikidata) и совместимые с ними типы сущностей. Отношения, необходимые для ссылок на внешние данные (например, мультимедиа файлы или индентификаторы баз данных), не использовались. Таким образом, Wikontic суммарно включает информацию о 2464 отношениях.

Для каждого отношения хранятся подходящие им типы данных (если быть точнее, WikibaseItem, Quantity, Point in time) и ограничения типов субъекта и объекта из Wikidata (например, Q21503250 для субъекта, Q21510865 для объекта).

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

Для поддержки обобщения правил мы рекурсивно расширяли типы сущностей, используя отношения “instance of” (P31) и “subclass of” (P279), создавая полные таксономии от каждого типа сущности до корня его родительской иерархии. Это важно, так как ограничения использования отношений определяются на разных уровнях абстракции. Например, отношение может допускать связи между сущностями более широкого класса “audiovisual work”, даже если тип сущности определен более конкретно как “film”. Распространяя допустимые отношения каждого родительского типа вниз к его дочерним типам сущностей, мы гарантируем, что сущности по‑прежнему могут быть сопоставлены с допустимыми отношениями, когда ограничение применяется к их родительскому классу. Пример проиллюстрирован на картинке ниже:

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

Векторные индексы, используемые в обеих базах данных, были построены с использованием эмбеддингов Contriever и векторного поиска Atlas MongoDB. Гибридная поддержка структурированных запросов в MongoDB обеспечивает одновременно эффективный поиск по графам и семантический поиск.

Этап 1. Извлечение триплетов-кандидатов

На этом шаге LLM получает in‑context инструкции и примеры для извлечения триплетов. LLM проинструктирована извлекать триплеты в форме «субъект‑отношение‑объект» вместе с типами сущностей и дополнительными метаданными (как qualifiers в Wikidata). Эти метаданные отражают дополнительную информацию, такую ​​как время, местоположение или условия. Хотя такие детали обычно не могут быть представлены в виде отдельных фактов, они важны для обеспечения точности и достоверности фактов в процессе их извлечения.

Этап 2. Корректировка фактов с учетом онтологии

На этом шаге каждый триплет‑кандидат валидируется и при необходимости корректируется с использованием схемы ограничений онтологии Wikidata.

Типизация сущностей. Для типов субъекта и объекта в триплете мы извлекаем 10 наиболее вероятных типов‑кандидатов из векторного индекса онтологической базы. Затем LLM выбирает наиболее правдоподобный тип субъекта/объекта, используя контекст в виде исходного триплета и текста. После этого, как было описано выше, мы добавляем супертипы из таксономии, чтобы обеспечить обобщаемость при определении ограничений на более высоких уровнях абстракции.

Проверка отношений. Используя ограничения Wikidata, мы определяем все отношения, которые могут связывать выбранные типы субъекта и объекта и их родительские классы, включая обратные комбинации типов субъекта и объекта (например, “directed” vs “director”). Эти отношения‑кандидаты ранжируются по косинусному сходству с исходным извлеченным отношением.

Корректировка триплета‑кандидата. Текст, исходный триплет и комбинации допустимых отношений и типов субъектов и объектов передаются в LLM, проинструктированную выбирать наиболее правдоподобную конфигурацию триплета, соответствующую онтологии. В итоге на этом шаге получается уточнённая основа триплета: типы сущностей и выбранное отношение между ними.

Этап 3. Нормализация и дедупликация

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

Для каждого скорректированного триплета Wikontic связывает имена субъекта и объекта с существующими сущностями в графе знаний, которые имеют тот же тип или общий родительский тип из таксономии. Используя предварительно вычисленные векторные представления алиасов сущностей из графа знаний, мы извлекаем 10 наиболее вероятных кандидатов имен сущностей и ранжируем их по косинусному сходству с извлечёнными наименованиями сущностей. Кандидаты вместе с их типами, исходным триплетом и текстом передаются в LLM для определения того, является ли извлечённая сущность синонимом одной из существующих. При совпадении мы заменяем сущность в триплете её каноническим именем из графа знаний и сохраняем извлечённое упоминание в тексте в качества алиаса; в противном случае мы сохраняем новую сущность в графе как каноническое имя.

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

Как можно использовать KG-RAG

Структурированная форма хранения информации позволяет использовать KG‑RAG подходы для задач Open‑domain QA и Multi‑hop QA. Часто в таких задачах LLM сталкиваются со сложностями в обработке длинного контекста из большого числа документов. В классическом же RAG разбиение текстов на фрагменты приводит к потере фактологической связности и нарушению логики между сущностями, что сказывается на качества ответов и повышению риска галлюцинаций. Однако в связке с графами знаний языковые модели способны естественным образом строить многошаговые цепочки рассуждений, поддерживать связи между фактами и выдавать более точные ответы.

Кроме того, KG‑RAG подходы применимы и к суммаризации. Например, GraphRAG использует алгоритмы community detection для выявления компонент связности в графе. Авторы предлагают строить иерархическую структуру этих компонент, что позволяет суммаризировать содержимое графа на разных уровнях: от локальных связей между сущностями до глобальной структуры знаний. Такая структура также снижает риск галлюцинаций и точность генерации, так как суммаризация строится на взаимосвязанных фактах, а не на разрозненных текстовых фрагментах.

Для тестирования Wikontic мы использовали задачу multi‑hop QA как прокси для оценки качества графа. Возможность строить цепочки рассуждений в виде триплетов и корректно отвечать на вопросы отражает точность и полноту информации, извлечённой из текста и сохранённой в графе. При этом графовая структура снижает риск галлюцинаций, обеспечивая достоверный контекст, на который модель может опереться при формированииответа.

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

Для заданного вопроса LLM сначала формулирует первый подвопрос. Для каждого подвопроса модель делает следующее:

1. Находит сущности, явно упомянутые или потенциально важные для ответа;

2. Связывает эти сущности с вершинами в графе и выбирает наиболее релевантные для текущего подвопроса;

3. Формирует подграф вокруг выбранных сущностей и на его основе генерирует ответ на подвопрос;

4. Использует полученный ответ, чтобы сформулировать следующий подвопрос.

Этот процесс повторяется до пяти подвопросов, после чего модель выдаёт окончательный ответ.

Оценка качества извлеченного графа

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

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

1. Сохранение информации из текста в графе — полнота и точность извлеченных фактов в виде триплетов;

2. Структурная компактность — отсутствие избыточных и дублированных триплетов, связность фактов;

3. Качество рассуждений на графе — способность модели выполнять multi‑hop QA, используя только построенный граф знаний, без доступа к исходным текстам.

Такой подход позволяет точно определить вклад графа в ответы модели. В отличие от методов, дополненных retrieval (например, HippoRAG, AriGraph или Holmes), где LLM опирается на исходные тексты, наша постановка задачи делает граф единственным источником фактов, позволяя напрямую оценить его качество.

Результаты: сохранение и потеря информации в графе

Для оценки доли информации, сохраняемой в графе, мы протестировали Wikontic на бенчмарке MINE‑1. Этот бенчмарк измеряет, какая часть фактической информации из исходного текста сохраняется в построенных графах знаний, используя протокол LLM‑as‑a-judge, предложенный авторами MINE‑1.

В среднем Wikontic сохраняет 84% исходных фактов, что существенно превосходит GraphRAG (47,8%) и KGGen (66%), использованных в качестве бейзлайнов самими авторами бенчмарка. Wikontic эффективно сохраняет фактическую информацию при построении графов знаний, обеспечивая надёжный и достоверный контекст для последующих reasoning‑задач.

Результаты: плотность графов

Напомню, мы хотели оценить структуру графов, сохранение информации в том числе для использования downstream‑задачах. Учитывая ограниченное число подходов, позволяющих напрямую измерять качество графов знаний, мы применили альтернативный подход, основанный на наборе multi‑hop вопросов из датасета MuSiQue, чтобы понять, насколько эффективно знания представлены в построенных по тексту графах.

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

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

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

Результаты: качество ответов на multi-hop QA задаче

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

Несмотря на это ограничение, используя графы знаний, построенные Wikontic, GPT‑4.1 показывает высокое качество. Проверку проводили на уже упомянутом датасете MuSiQue, а также на HotpotQA:

• HotpotQA: 64,5% точного совпадения ответов (Exact Match, EM) и 76,0% по метрике F1;

• MuSiQue: 46,8% точного совпадения и 59,8% F1.

Таким образом, Wikontic превосходит ReadAgent и GraphReader, и сопоставим по качеству с более ресурсоёмкими системами вроде AriGraph и HOLMES, которые отвечают на вопросы по исходным текстам.

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

Важность компонент Wikontic’a

Для оценки вклада отдельных шагов в Wikontic мы провели абляции на датасете MuSiQue:

• Отсутствие метаданных в триплетах приводит к значительному снижению качества (–15,9 EM, –15,7 F1), что подчёркивает важность сохранения контекстуальной информации для уточнения фактов.

• Удаление механизма сохранения алиасов (этап 3) снижает производительность, подтверждая, что этот механизм улучшает сопоставление сущностей при ответах на вопросы.

• Исключение интеграции онтологии (этап 2) приводит к падению как EM, так и F1, демонстрируя, что ограничения типов сущностей и схемы необходимы для согласованного построения графа.

• Одновременное удаление онтологии и нормализации сущностей (этапы 2 и 3) вызывает наибольшее падение производительности, показывая, совместное использование данных механизмов обеспечивает максимальный вклад в качество построенного графа.

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

Эффективность построения графов

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

По этому критерию Wikontic оказывается более эффективным: он использует в три раза меньше выходных токенов, чем AriGraph, и примерно в двадцать раз меньше, чем GraphRAG. При этом Wikontic достигает сопоставимого качества на QA задачах, используя значительно меньше вычислительных ресурсов.

Wikontic + Langchain

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

pip install wikontic

Мы постарались упростить использование WIkontic для интеграции в пайплайны LLM-агентов:

model = ChatOpenAI( model="gpt-4o", base_url=base_url, api_key=api_key, http_client=http_client ) langchain_agent = create_agent( model, tools=[ inferer.extract_triplets_with_ontology_filtering_and_add_to_db_tool, inferer.retrieve_similar_entity_names_tool, inferer.get_1_hop_supporting_triplets_tool, inferer.answer_question_with_llm_tool, ], ) langchain_agent.invoke( { "messages": [ { "role": "user", "content": text_2, } ] } ) langchain_agent.invoke( { "messages": [ { "role": "user", "content": "What are the companies Jobs founded?", } ] } )

Ноутбук с полным туториалом вы можете найти здесь.

Что дальше?

Потенциал Wikontic позволит создавать аннотированные данные, на которых в будущем можно будет дообучать компактные модели для конкретных задач. Такие модели будут работать быстрее и экономичнее, требуя меньше вычислительных ресурсов. Кроме того, Wikontic гибок и адаптируем: его можно применять и к любому другому домену и онтологии, при соблюдении формата ограничений триплетов и типов сущностей. Также в будущем мы планируем дополнять возможности Wikontic‑а для построения временны́х (temporal) графов знаний, которые учитывают эволюцию информации во времени. Такой подход особенно важен для динамичных областей, где факты часто меняются, например, новости, исследования или социальные медиа. Временные графы позволят LLM внедрять изменения и корректно использовать новые данные, сохраняя согласованность и достоверность информации.

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

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

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

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

Больше информации вы можете найти в статье про Wikontic. Код открыт и выложен на GitHub. Будем рады вашим звёздочкам!