Привет, Хабр! Мы — Даниил Березин и Роман Авдеев, магистранты кафедры банковских информационных технологий в МФТИ (СберТех).

В рамках дипломной работы под руководством кандидата технических наук, научного сотрудника группы «Прикладное NLP» AIRI Олега Сомова мы участвовали в соревновании Text‑To‑SPARQL Challenge на конференции ESWC 2025 (Порторож, Словения).

Среди 9 команд из ведущих европейских исследовательских центров мы заняли:

? 3-е место в треке DBPedia

? 5-е место в треке с корпоративным графом знаний

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

О соревновании

Text‑To‑SPARQL Challenge — это конкурс, который организовала AKSW (Agile Knowledge Engineering and Semantic Web) — исследовательская группа, занимающаяся семантическими технологиями, связанными с данными и искусственным интеллектом. Соревнование проходило онлайн в период с апреля (дедлайн регистрации) по июнь (защита решений и публикация результатов).

Задача участников заключалась в разработке модели, способной преобразовывать текстовые запросы на естественном языке в SPARQL‑запросы — формальный язык для работы с графами знаний, например Wikidata и DBpedia.

Немного про SPARQL

SPARQL — это язык запросов к RDF‑графам (Resource Description Framework), где данные представлены в виде триплетов «субъект‑предикат‑объект».

Как это работает?

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

Москва — столица России
Эйфелева башня находится в Париже
Лев Николаевич Толстой родился в 1828 году

В RDF каждое такое утверждение разбивается на три части:

• О чём говорим? (Субъект)

  Москва
  Эйфелева башня
  Лев Николаевич Толстой

• Что говорим? (Предикат)

  является столицей
  находится в
  год рождения

• Какое значение? (Объект)

  России
  Париже
  1828

SPARQL

Допустим, у нас есть данные о книгах:

"Война и мир" автор "Лев Николаевич Толстой"
"Анна Каренина" автор "Лев Николаевич Толстой"
"Преступление и наказание" автор "Федор Михайлович Достоевский"

SPARQL‑запрос для поиска всех книг Льва Толстого будет выглядеть так:

SELECT ?книга
WHERE {
  ?книга автор "Лев Николаевич Толстой".
}

Результат его выполнения:

книга
---------
"Война и мир"
"Анна Каренина"

Вот пример из датасета, на котором оценивалось наше решение:

question: How many people study at universities in California?
query:
        PREFIX dbo: <http://dbpedia.org/ontology/>
        PREFIX dbr: <http://dbpedia.org/resource/>
        PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
        SELECT SUM(?numStudents) WHERE {
          ?university rdf:type dbo:University .
          ?university dbo:state dbr:California .
          ?university dbo:numberOfStudents ?numStudents .
        }

Text-To-SQL и Text-To-SPARQL

Обращение к базам данных на естественном языке — известная область NLP, которая называется Natural language interface for databases (NLIDB). Самыми популярными задачами в ней сегодня являются Text‑to‑SQL и Text‑to‑SPARQL — первая более популярна, чем вторая, так как реляционные базы данных используются чаще. Хотя обе задачи нацелены на генерацию запросов, особенности структуры базы имеют сильное влияние на метод решения этих задач.

Text‑To‑SQL

Обычно работает с реляционными базами данных (SQL), которые организованы в таблицы с фиксированными схемами, где запросы требуют точного соответствия полям таблиц и их типам данных, а также опираются на строгую структуру, где данные представлены в виде строк и столбцов. Каждая таблица имеет четко определенные поля, и отношения между таблицами задаются через ключи. Как следствие, решение задачи Text‑to‑SQL, помимо генерации самого запроса, включает ещё и сопоставление схемы (Schema Linking), то есть определение соответствующих запросу элементов схемы, которые должны быть в нём.

Text‑To‑SPARQL

Использует графовые базы данных, основанные на RDF. Данные представлены в виде триплетов («субъект‑предикат‑объект»), что позволяет более гибко моделировать отношения между сущностями. Это делает структуру данных менее строгой, более семантически богатой, но усложняет процесс генерации запросов. Подход сильнее ориентирован на извлечение информации из связанных данных, что требует более глубокого понимания контекста запроса.

Важно, что графы знаний — это обширные базы данных, где хранится большое количество сущностей и предикатов. Например, в графе Wikidata более 80 млн сущностей. Поэтому для задачи Text‑to‑SPARQL релевантны задачи сопоставления сущностей и предикатов (Schema/Predicate linking) из множества подходящих элементов графа.

Данные

Организаторы предоставили только тестовые датасеты. Соревнование проходило на двух графах знаний:

• DBpedia — общедоступная энциклопедия знаний, извлеченная из Wikipedia;

• Корпоративный граф — внутренняя база данных компании.

Первая попытка решения 

Изначально мы использовали концепцию text2query, в которой задача разбивается на последовательные этапы:

1. Распознавание сущностей;

2. Связывание сущностей с их ссылками;

3. Генерация SPARQL.

Все этапы решения мы реализовывали при помощи запросов с промптами и few‑shot примерами в GPT-4. Однако такое решение имело ряд существенных проблем:

1. В аналогичных решениях для SQL мы передаем в качестве промпта схему баз данных, которые требуются в запросе. В нашем случае база данных одна — DBpedia, и она очень большая, чтобы передать ее целиком в контекст языковой модели.

2. Проблема с разными языками: модель плохо выделяла сущности не на английском, а также при сопоставлении сущности и ссылки использовала имя сущности на оригинальном языке. Например, запросом на русском языке происходило такое:

   Question: Кто является художником картины "Буря на Галилейском море"?
   Generated: SELECT DISTINCT ?uri WHERE {
     <http://dbpedia.org/resource/Буря_на_Галилейском_море> <http://dbpedia.org/ontology/artist> ?uri .
     FILTER EXISTS { ?uri a <http://dbpedia.org/ontology/Artist> . }
   }
   GOLD: PREFIX res: <http://dbpedia.org/resource/> PREFIX dbp: <http://dbpedia.org/property/> SELECT DISTINCT ?uri WHERE { res:The_Storm_on_the_Sea_of_Galilee dbo:author ?uri }

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

4. Сами SPARQL‑запросы генерировались не всегда хорошо.

Дорабатываем решение для DBpedia 

Первое решение показало результат 0.24 по метрике exec match на тестовом датасете QALD-9+. Этого, конечно, было недостаточно, и мы последовательно стали решать каждую из проблем Baseline‑решения.

1. Мультиязычная обработка

   Мы решали проблему выделения сущностей на других языках переводом. Перебрав несколько вариантов, остановились на переводе с использованием GPT.

2. Устранение неоднозначностей

   Представьте, что мы спрашиваем "What country's capital is Washington?", имея в виду город, а модель думает, что мы говорим об одноимённом штате. Это типичный пример неоднозначности в запросе, и её можно побороть, переформулировав запрос.

   Query Rewriting — это важный этап предобработки естественно‑языкового вопроса не только в рамках нашего решения, но и глобально в задачах генерации запросов и задаче информационного поиска. При переформировании необходимо учитывать контекст запроса и семантику. Это может включать в себя использование онтологий, синонимов и других семантических ресурсов, чтобы обеспечить более точное соответствие между текстовым запросом и структурированными данными (в нашем случае, возвращаемыми ссылками на DBPedia).

   В нашей реализации мы использовали дополнительный запрос к GPT, в результате которого он обогащает входной вопрос данными из базы, устраняя неоднозначности. В примере выше мы заменяем "Washington" на "Washington, D.C.".

3. Сопоставление сущностей (Entity Linking)

   Задача сопоставления сущностей определяет какие субъекты и объекты вопроса должны быть указаны в финальном запросе. Для этого мы использовали DBpedia Spotlight инструмент, который умеет это делать из коробки для графа DBPedia. Также мы сделали фолбэк в ChatGPT для сложных случаев нераспознавания сущности вопроса. В таких случаях GPT обычно просто приводила сущность в нормализованный формат DBPedia, попутно конкретизируя сущностью как в примере с Вашингтоном.

4. Поиск ближайших соседей в графе

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

5. Адаптивный промпт

   Для повышения качества конечной генерации мы использовали RAG‑систему, построенную на основе пар: вопрос на английском — запрос SPARQL из существующих датасетов LCQuad 2.0, QALD-9+. Мы находим 5 вопросов, наиболее близких по косинуcному расстоянию к исходному, и добавляем соответствующие пары в few‑shot. Таким образом, если входной вопрос подразумевает запрос типа ASK (проверка утверждения в языке SPARQL), адаптивный промпт будет содержать только те примеры, в которых запрос имеет структуру ASK.

   Её, например, будет иметь вопрос «Существуют ли города с населением больше 10 миллионов?»:

   ASK WHERE {
     ?city a <http://schema.org/City> ;
           <http://schema.org/population> ?population .
     FILTER (?population > 10000000)
   }

6. Соединяем все вместе

В результате, в финальном варианте решения запрос генерируется на основе следующих составляющих:

• Исходного вопроса;

• Сущностей, содержащихся в вопросе, и соответствующих им ссылок в DBpedia;

• Ближайших соседей (теперь наши предсказания основываются не только на внутренних знаниях LLM);

• Адаптивного промпта содержащего примеры из открытых датасетов по DBpedia.

После генерации мы добавили проверку запроса на исполнимость (обращаемся к DBpedia через API и смотрим чтобы не было ошибок, и пришел не пустой ответ). Если запрос невалиден, то весь промпт и описание ошибки отправляются в GPT на исправление.

А что с корпоративным графом? 

В Baseline‑решении нет ничего про корпоративный граф знаний (Knowledge Graph, KG). Изначально мы предполагали, что для него алгоритм будет аналогичным DBpedia, однако аналога Spotlight для корпоративного графа просто не существует в готовом виде. Query Rewriting также не актуален, так как у модели нет знаний о домене компании, чтобы корректно его сделать.

Придя к этим выводам, мы решили реализовать отдельный пайплайн для корпоративного графа. Вместо поиска ближайших соседей использовали RAG‑систему, построенную на аннотации локального графа (он достаточно небольшой, так что работает быстро). На основе входного вопроса мы искали ближайшие сущности и добавляли в промпт top-10 по косинусному расстоянию. Генерация самого SPARQL‑запрос происходила аналогично Dbpedia.

Оба пайплайна представлены на схеме ниже:

Анализ результатов 

Наша команда представила гибридное pipeline‑решение для преобразования естественно‑языковых вопросов в SPARQL‑запросы, заняв:

• 3-е место на DBpedia (испанский подтрек)

• 5-е место на корпоративном графе

Общей номинации по DBpedia нет, вместо этого она делится на английский и испанский трек — в последнем мы и заняли третье место. Но если бы такая номинация была, мы бы там тоже были третьими — это организаторы отметили отдельно.

В качестве сильных сторон нашего решения можно отметить:

1. Модульность и адаптивность:

   • Раздельные пайплайны для DBpedia и корпоративного графов позволили учесть их различия (мультиязычность vs доменная специфика);

   • DBpedia: Использование ближайших соседей и адаптивного промта улучшили точность генерации запросов;

   • Корпоративный граф: RAG снизил вычислительные затраты.

2. Гибридный подход:

   • GPT для перевода, устранения неоднозначностей и генерации SPARQL;

   • DBpedia Spotlight для точного связывания с графом;

   • Автоисправление запросов на основе ошибок выполнения.

3. Работа с мультиязычными данными:

   • Перевод вопросов на английский с сохранением сущностей.

Но также стоит выделить проблемы:

1. Зависимость от pipeline‑архитектуры:

   • Ошибки на ранних этапах (например, некорректное связывание сущностей) каскадно влияют на конечный результат;

   • Агентные системы конкурентов оказались устойчивее к таким ошибкам.

2. Слабая адаптация к новым графам:

   • Решение показало низкую обобщаемость на корпоративном графе из‑за жесткой настройки под DBpedia.

3. Ранжирование результатов:

   • Плохая поддержка ORDER BY снизила нам оценку по метрике NDCG, оценивающая корректность порядка ответов.

Решение лидеров

А какое же решение победило? Его подготовила команда под названием WSE, и стоит отметить, что оно в чём‑то похоже на наше.

Авторы разделяют свой пайплайн на оффлайн и онлайн‑части.

Онлайн‑часть

На этом этапе авторы сначала просят агента составить план генерации запроса. Когда план готов, следующий LLM‑агент на основе GPT-4о выполняет полученные инструкции, дополнительно используя NEL Tool (Elasticsearch), который сопоставляет сущности с их URI. WSE протестировали этот пайплайн на benchmark‑датасетах и собрали статистику верных и неверных сгенерированных ответов.

Оффлайн‑часть

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

Схема их решения представлена ниже:

Основные отличия от нашего решения:

1. Генерация плана: step‑by‑step‑план создаётся агентом, а не вручную, как в нашем случае.

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

Выводы

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

Что можно сделать лучше? Кажется, что интеграция гибких агентных компонентов, способных адаптивно исследовать граф, будет сочетать преимущества pipeline (например, предсказуемость) с динамичностью агентов. Скажем, можно добавить этап предварительной «разведки» структуры графа для уточнения контекста или расширить RAG‑модуль, включив в него примеры запросов с ранжированием.

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

Спасибо, что прочитали! Надеемся, наш опыт окажется вам полезен!