Привет, Хабр! Меня зовут Алла, я работаю младшим исследователем в команде Memory‑Augmented models в составе лаборатории Cognitive AI Systems AIRI и занимаюсь ресерчем на пересечений графов знаний и языковых моделей. Потребность в таких изысканиях понятна любому, кто пытался добиться от ChatGPT точного ответа на конкретный вопрос: подобрать литературу для курсовой, вспомнить название фильма по описанию и тому подобное. Очень часто модель начинает галлюцинировать и выдумывать факты, которых не существует.

Один из способов решения этой проблемы — связать LLM с графом знаний, но сами графы тоже должен кто‑то наполнять. Мы с коллегами доказали, что эту задачу можно автоматизировать с помощью LLM и предложили своё решение, названное Prompt Me One More Time (фанаты Бритни тут?), о котором мне бы и хотелось сегодня здесь рассказать. За подробностями же можно обратиться к статье, представлена нами на воркшопе TextGraphs-17 конференции ACL-2024, недавно прошедшей в Тайланде.

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

Графы знаний (Knowledge Graphs, KGs) — это направленные реляционные графы, в которых сущности представлены в качестве вершин, а отношения между сущностями представлены как ребра в графе. Для описания графов знаний используется набор триплетов, представленных как (субъект, отношение, объект) или (s, r, o). Такие графы обеспечивают структурированное представление фактов как об объектах реального мира, так и об абстрактных понятиях.

Однако для поддержания графов знаний в актуальном состоянии требуется значительное количество ручного труда. Так, например, один из крупнейших open‑source графов знаний WikiData содержит более 1,54 миллиарда элементов и поддерживается совместными усилиями волонтеров.

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

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

И хотя основные методы извлечения информации из текста полагаются на обучение языковых моделей, недавние исследования предполагают, что извлечение триплетов графа может быть реализовано с помощью LLM путем внутриконтекстного обучения (in‑context learning) и следованию инструкциям (instruction following). Использование этих методов может быть более выгодным, поскольку теперь не нужно обучать модели и, как следствие, собирать для них большие аннотированные датасеты.

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

Пайплайн и данные

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

Первый этап — извлечение триплетов‑кандидатов. Кандидаты в триплеты могут включать имена сущностей и отношений, которые не соответствуют форматам, используемым в KG WikiData. Поэтому на втором этапе эти кандидаты корректируются на основе похожих сущностей и отношений, которые уже присутствуют в KG. На выходе мы проверяем нормализованные триплеты и отсеиваем те, которые не соответствуют онтологии KG. Этот шаг включает в себя проверку ограничений отношений и обеспечение совместимости типов сущностей с ними. Для всех шагов, кроме последнего, мы использовали модель OpenAI gpt-3.5-turbo1. Полученный подход получил название Prompt Me One More Time.

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

Рассмотрим каждый шаг поподробнее.

Шаг 1: извлечение кандидатов из текста

На первом этапе LLM извлекает кандидатов в триплеты из входного текста. В запросе к LLM мы описывали суть задачи и использовали для демонстрации три примера из тренировочного сплита набора данных Wiki‑cIE Code:

На этом этапе, например, один из триплетов, извлеченных LLM из текста

“Tahiti Honey” is a film written by Frederik Kohnner

будет: ( «Tahiti Honey», «written by»,«Frederik Kohnner» ).

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

Шаг 2: нормализация триплетов

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

На основе топ-5 полученных точных имен сущностей и отношений, схожих с теми, что были извлечены на первом этапе, в запросе к LLM описывается задача выбора имен, которые соответствуют контексту текста и самого триплета:

Например, для вышеупомянутого триплета на втором шаге будет найдено 5 канонических имен, ранжированных по сходству для каждого извлеченного субъекта, объекта и отношения соответственно:

“written by" : ["lyrics by", "adapted by", "produced by", "screenwriter", "author"],
"Tahiti Honey" : ["Tahiti Honey", "Honey", "Honey Chile", "Celtic Honey", "Tahitipresse"],
"Frederik Kohnner" : ["Frederick Kohner", "Paul Kohner", "Adolf Kohner", "Susan Kohner", "Henry Rohner"].

И в итоге, исправленный с помощью LLM на втором шаге триплет выглядит как
("Tahiti Honey" , "screenwriter" , "Frederick Kohner" ).

Шаг 3: обеспечение логического соответствия извлеченных триплетов 

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

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

Далее классы субъекта и объекта из сгенерированного триплета были извлечены из сервиса запросов Wikidata путем запроса «instance of» (P31) и «subclass of» (P279) свойств субъекта и объекта вплоть до начала иерархии их подклассов:

Триплет считается валидным, если типы субъекта и объекта совпадают с типами, указанными в правилах отношения из этого триплета.

Таким образом, обеспечивалась достоверность логической структуры извлеченной информации. Пример процесса верификации схематично описан на рисунке:

Эксперименты

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

Какие выводы мы сделали исходя из такой проверки:

• Наиболее важной частью метода является предоставление LLM репрезентативных примеров триплетов. Использование двухшагового метода с демонстрацией примеров и проверкой триплетов дает в пять раз лучший результат метрики F1 по сравнению с тем же методом без демонстрации примеров.

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

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

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

Далее мы сравнили наш метод с существующей SOTA. В левой части из таблицы ниже показаны результаты работы метода, основанного на пошаговых запросов к LLM, по сравнению с SynthIE T5-large, лучшей моделью, обученной на наборе данных SynthIE от всё тех же Йосифоски с коллегами.

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

Просматривая синтетический набор данных вручную, мы заметили частые несоответствия между текстами и триплетами в разметке. Чтобы продемонстрировать недостатки синтетического набора данных, мы выбрали 100 случайных примеров из WikicIE‑test‑small. С помощью референсных сущностей, использованных для генерации каждого текста в оригинальной статье, мы вручную добавили похожие тексты на естественном языке об этих сущностях из параграфов Википедии. Таким образом, мы получили набор текстов на естественном языке, ссылающихся на сущности KG из исходного набора данных.

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

Мы видим, что теперь метод на основе LLM значительно превосходит SynthIE T5-large по точности, оцененной человеком. Предварительно обученная модель склонна генерировать триплеты, которые не соответствуют контексту текста, используя выученные триплеты вместо того, чтобы извлекать релевантные из контекста.

Кроме того, корректные триплеты, предсказанные обоими методами, заметно отличаются друг от друга. Измеренная метрика intersection over union (IoU) или расстояние Жаккара показывает, что только 8% корректных триплетов предсказаны обоими методами. Это говорит о том, что каждая модель имеет свою специализацию, демонстрируя преимущества в различных аспектах извлечения информации. Следовательно, их предсказания могут быть скомбинированы, что приведет к дальнейшему улучшению производительности системы.

И что дальше?

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

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