KG-LLM-Bench: Масштабируемая база для оценки рассуждений LLM на текстуализированных графах знаний

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

Ключевой результат: Формат Structured JSON в большинстве случаев является наиболее эффективным для анализа данных, поскольку он делает связанные факты "соседями" в тексте, что облегчает их обработку моделью.

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

Представьте, что вы даете LLM информацию о сотрудниках и проектах.

• Плохой подход (информация разбросана):

  • Анна работает в отделе Маркетинга.
  • Иван работает в отделе IT.
  • Проект "Альфа" ведет отдел Маркетинга.
  • Анна отвечает за SMM.
  • Проект "Бета" ведет отдел IT.

• Хороший подход (информация сгруппирована):

  • Сотрудник: Анна
    • Отдел: Маркетинг
    • Роль: SMM
    • Ведет проект: "Альфа"
  • Сотрудник: Иван
    • Отдел: IT
    • Ведет проект: "Бета"

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

Методика для пользователя: 1. Определите главные сущности в ваших данных (например, "Продукт", "Сотрудник", "Рецепт"). 2. Для каждой сущности соберите все связанные с ней факты и свойства. 3. Представьте эти данные в промпте в виде вложенной структуры, используя маркеры, отступы или, что лучше всего, формат JSON или YAML. 4. Сформулируйте свой вопрос после этого структурированного блока данных.

Это превращает ваш промпт из простого вопроса в мини-отчет с данными, который LLM может эффективно проанализировать.

*Прямая применимость:

* Пользователи могут немедленно начать форматировать любые табличные или списочные данные (характеристики товаров, списки клиентов, планы проектов) в `JSON` или `YAML` перед отправкой в LLM. Это можно сделать в любом текстовом редакторе. Например, вместо того чтобы вставлять скопированную из Excel таблицу как есть, ее стоит преобразовать в JSON-массив объектов.

• Концептуальная ценность:

  • Раскрывается ключевая идея: LLM — это не база данных, это процессор последовательного текста. Структура и порядок токенов имеют огромное значение. Группировка информации помогает модели формировать более сильные "внимания" (attention) между связанными понятиями. Это помогает понять, почему LLM иногда "тупит" на простых вопросах, если данные поданы хаотично.

• Потенциал для адаптации:

  • Метод легко адаптируется для любой предметной области.
  • Механизм адаптации:
    1. Посмотрите на свою задачу. Вам нужно посчитать что-то или найти взаимосвязи внутри одного объекта (например, "сколько стоит товар X с учетом всех его опций?")? Используйте JSON или YAML, где все опции товара будут сгруппированы под ним.
    2. Вам нужно найти простой факт или проследить цепочку из двух-трех шагов (например, "в каком отделе работает начальник Ивана?")? Простой формат (субъект, отношение, объект) может быть достаточным и более экономным по токенам.

Представим, что менеджер по туризму хочет быстро проанализировать несколько турпакетов с помощью LLM.

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

`json
[
 {
 "название_тура": "Пляжный рай на Бали",
 "страна": "Индонезия",
 "длительность_дней": 10,
 "цена_usd": 1500,
 "тип_отдыха": ["пляжный", "релакс", "экскурсии"],
 "включено": ["перелет", "отель 5*", "завтраки"]
 },
 {
 "название_тура": "Альпийские приключения",
 "страна": "Швейцария",
 "длительность_дней": 7,
 "цена_usd": 1800,
 "тип_отдыха": ["активный", "горы", "хайкинг"],
 "включено": ["отель 4*", "завтраки", "ски-пасс"]
 },
 {
 "название_тура": "Сокровища Киото",
 "страна": "Япония",
 "длительность_дней": 8,
 "цена_usd": 2200,
 "тип_отдыха": ["культурный", "экскурсии", "гастрономия"],
 "включено": ["перелет", "отель 4*", "экскурсовод"]
 },
 {
 "название_тура": "Отдых в горах Швейцарии",
 "страна": "Швейцария",
 "длительность_дней": 9,
 "цена_usd": 1950,
 "тип_отдыха": ["горы", "релакс", "спа"],
 "включено": ["отель 5*", "завтраки и ужины", "спа-процедуры"]
 }
]`

### Вопрос:

Какой самый дорогой тур в Швейцарию? Перечисли все его характеристики и что в него включено.

Этот промпт эффективен благодаря нескольким механикам, подтвержденным в исследовании:

1. Структурирование через JSON: Вся информация по каждому туру сгруппирована в единый объект {...}. Когда LLM ищет туры в "Швейцарию", она находит два объекта. Затем, в рамках каждого из этих объектов, она легко находит поле "цена_usd", сравнивает их и определяет самый дорогой. Ей не нужно скакать по всему тексту, чтобы сопоставить страну и цену.
2. Информационная локальность: Все характеристики тура ("длительность", "цена", "тип_отдыха") находятся в "непосредственной близости" от его названия. Это позволяет модели легко извлечь все детали по запросу "Перечисли все его характеристики".
3. Четкое разделение контекста и задачи: Использование заголовков ### Контекст и ### Вопрос помогает модели понять, где находятся данные для анализа, а где — сама задача.

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

Ты — HR-аналитик и ассистент руководителя. Проанализируй данные о загрузке команды, представленные ниже в формате YAML. Отвечай на вопросы, используя только предоставленные данные.
### Контекст: Загрузка команды

`yaml
- сотрудник:
 имя: "Елена Петрова"
 должность: "Старший дизайнер"
 проекты:
 - название: "Редизайн сайта"
 роль: "Ведущий дизайнер"
 срок_сдачи: "2024-09-15"
 - название: "Мобильное приложение"
 роль: "Консультант"
 срок_сдачи: "2024-10-01"
- сотрудник:
 имя: "Иван Сидоров"
 должность: "Младший разработчик"
 проекты:
 - название: "Мобильное приложение"
 роль: "Разработчик"
 срок_сдачи: "2024-10-01"
- сотрудник:
 имя: "Ольга Новикова"
 должность: "Менеджер проектов"
 проекты:
 - название: "Редизайн сайта"
 роль: "Менеджер"
 срок_сдачи: "2024-09-15"
 - название: "Мобильное приложение"
 роль: "Менеджер"
 срок_сдачи: "2024-10-01"
 - название: "Внутренний портал"
 роль: "Ответственный"
 срок_сдачи: "2024-11-20"`

### Вопрос:

1. Кто из сотрудников задействован в наибольшем количестве проектов?
2. Кто работает над проектом "Редизайн сайта"? Перечисли их имена и роли в этом проекте.

Механизм эффективности этого промпта аналогичен предыдущему, но с использованием формата YAML, который также отлично справляется с задачей структурирования:

1. Группировка по сущности: Главной сущностью здесь является "сотрудник". Вся информация, включая список проектов, сгруппирована под каждым сотрудником.
2. Легкость агрегации: Чтобы ответить на вопрос "Кто задействован в наибольшем количестве проектов?", модели достаточно посчитать количество элементов в списке "проекты" у каждого сотрудника. Благодаря структуре YAML (или JSON), эти списки четко определены и легко поддаются "подсчету" моделью.
3. Вложенность для точного поиска: Для ответа на второй вопрос модель сканирует список проектов каждого сотрудника. Найдя проект с названием "Редизайн сайта", она легко извлекает имя родительской сущности ("Ольга Новикова" или "Елена Петрова") и роль из того же блока. Это гораздо надежнее, чем если бы факты "Ольга - менеджер" и "Редизайн сайта ведет менеджер" были в разных частях промпта.

• A. Релевантность техникам промптинга: Высокая. Исследование напрямую сравнивает эффективность различных форматов структурирования данных в промпте (List of Edges, JSON, YAML), что является ключевой техникой промптинга при работе с данными.
• B. Улучшение качества диалоговых ответов: Высокая. Основная цель работы — измерить и показать, как выбор формата данных в контексте промпта напрямую влияет на точность и правильность ответов LLM на конкретные вопросы.
• C. Прямая практическая применимость: Очень высокая. Пользователь может немедленно применить выводы, просто отформатировав свои данные (например, список продуктов, сотрудников, проектов) в JSON или YAML и вставив их в промпт. Никакого кода или специальных инструментов не требуется.
• D. Концептуальная ценность: Очень высокая. Исследование дает фундаментальное понимание того, что LLM не "понимает" структуру JSON магическим образом, а обрабатывает ее как последовательность токенов. Оно наглядно демонстрирует, почему группировка связанной информации (например, все свойства одного объекта в одном блоке JSON) помогает модели лучше находить связи и агрегировать данные.

• E. Новая полезная практика (кластеризация): Работа попадает сразу в несколько ключевых кластеров:

  • Кластер 3 (Оптимизация структуры промптов): Это ядро исследования. Сравнение JSON, YAML, List of Edges — это и есть оптимизация структуры.
  • Кластер 5 (Извлечение и структурирование): Вся работа посвящена тому, как лучше подать структурированные данные для последующего извлечения из них информации.
  • Кластер 2 (Поведенческие закономерности LLM): Раскрывает важнейшую закономерность: модели гораздо легче агрегируют "исходящие" связи (которые в структурированных форматах находятся рядом с родительским объектом), чем "входящие". Это блестящий практический инсайт.
  • Кластер 6 (Контекст и память): По сути, это исследование лучших практик для пользовательского RAG (Retrieval-Augmented Generation), где пользователь сам предоставляет контекст в виде структурированных данных.

• Чек-лист практичности (+15 баллов): ДА. Работа дает готовые структуры (JSON, YAML), показывает, как структурировать сложные запросы (путем форматирования данных), раскрывает неочевидные особенности LLM (проблема "входящих" связей) и предлагает способы улучшить точность (выбрать правильный формат для задачи).

Аргументы в пользу высокой оценки (95/100):

1. Прямая применимость: Это не теоретические рассуждения, а прямое руководство к действию. Если вам нужно, чтобы LLM проанализировала набор данных, отформатируйте их в Structured JSON или YAML. Это просто, не требует навыков программирования и дает немедленный результат.
2. Фундаментальный инсайт: Главный вывод — "локальность информации имеет значение". Группировка связанных фактов в одном месте текста (что делают JSON и YAML) значительно облегчает модели их обработку. Это объясняет, почему простыня несвязанных фактов работает хуже, чем структурированный документ.
3. Универсальность: Выводы проверены на 7 разных моделях и 5 разных задачах, что делает их очень надежными и применимыми к большинству современных LLM, с которыми сталкивается пользователь (GPT, Claude, Llama).

Контраргументы (почему оценка могла бы быть ниже):

1. Академический язык: Термины вроде "текстуализация графа знаний" или "агрегация свойств соседей" могут отпугнуть обычного пользователя. Ему придется сделать небольшой мысленный скачок, чтобы понять, что "граф знаний" — это просто его список контактов или каталог товаров, а "агрегация" — это подсчет чего-либо.
2. Нет "серебряной пули": Исследование показывает, что лучший формат зависит от задачи. Structured JSON хорош для агрегации, но простой List of Edges может быть эффективнее для других задач. Это требует от пользователя некоторого анализа своей задачи, а не слепого применения одного правила.

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