Понимают ли большие языковые модели данные из таблиц?

Вступление

Всем привет! С вами команда IDP. Сегодня расскажем о том, как мы оцениваем языковые модели для ответов на вопросы по таблицам.

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

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

Выбор данных

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

Для исследования мы отобрали таблицы из двух источников: энциклопедий (Википедия) и технических документаций (ГОСТы);, а также синтезировали несколько дополнительных наборов таблиц, чтобы оценить влияние однородности значений и сложности текста в ячейках. Таблицы, полученные из свободных источников, прошли несколько этапов предобработки. Предварительно мы перевели их из формата HTML в markdown, поскольку он обычно используется в предобучении языковых моделей и является экономным с точки зрения количества токенов. Многоуровневые заголовки были объединены через »/» в плоские заголовки. Объединенные ячейки разбивались, а тексты в разбитых ячейках дублировались. Таблицы выбирали шириной от 2 до 16 столбцов, высотой от 1 до 64 строк.

Таблицы в подмножествах отличались по следующим признакам:

  • размеры таблицы (ширина и высота);

  • однородность значений в столбцах (можно ли без заголовка определить, какой столбец что означает);

  • количество текста в ячейках (чем его больше, тем сложнее для модели должна быть задача).

Примеры таблиц:

Википедия (wiki)

Википедия (wiki)

ГОСТы (gost)

ГОСТы (gost)

Синтетика-1 (syn1), разнородные значения

Синтетика-1 (syn1), разнородные значения

Синтетика-2 (syn2), однородные значения, цвета RGB, столбцы — просто буквенные обозначения

Синтетика-2 (syn2), однородные значения, цвета RGB, столбцы — просто буквенные обозначения

Синтетика-3 (syn3), однородные значения, цвета RGB, шумные названия колонок

Синтетика-3 (syn3), однородные значения, цвета RGB, шумные названия колонок

Синтетика-4 (syn4), однородные значения, числа float32 (6 знаков), столбцы — просто буквенные обозначения

Синтетика-4 (syn4), однородные значения, числа float32 (6 знаков), столбцы — просто буквенные обозначения

Синтетика-5 (syn5), однородные значения, числа float32 (15 знаков), столбцы — просто буквенные обозначения

Синтетика-5 (syn5), однородные значения, числа float32 (15 знаков), столбцы — просто буквенные обозначения

Постановка задачи

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

Мы выбрали самую естественную и частотную (что также подтверждалось статистикой по нашему проекту) структуру вопроса: «Какое значение столбце target, если в столбце query значение равно X

Для ответа на этот вопрос требуется не только найти в таблице два заданных столбцаq и t, но и определить целевую строку r по переданному значению X, а затем извлечь ответ из ячейки в столбцеt.

Формализовав структуру вопроса как «Какой t, если q — r[q]?», мы сгенерировали вопросы простым алгоритмом: перебирая все t, q, r в таблице. В итоговый датасет попали только вопросы, для которых существует единственный ответ r[t], причем его значение встречается в столбце t ровно один раз — это снижает вероятность угадать ответ, выбрав самое частотное значение.

Пример. Какое покрытие, если соперница в финале — Лесли Керхов? Ответ: Хард

Пример. Какое покрытие, если соперница в финале — Лесли Керхов? Ответ: Хард

Формат промпта для LLM:

{system_prompt}

-----

{table}

-----

{question}

Системный промпт мы подобрали такой, чтобы все модели понимали инструкцию и следовали формату. В ответе мы ожидаем значение из какой‑то одной ячейки таблицы. Мы проверили, что сильные модели хорошо соблюдают формат без дополнительных пояснений. Формулировка получилась такая:

Ты — эксперт по интеллектуальной обработке документов. Тебе на вход передана таблица из документа. Ответь на вопрос, опираясь ТОЛЬКО на данные из этой таблицы.

Для оценки ответа модели использовалась метрика exact match: 1, если ответ совпал, и 0 иначе.

Методология оценки

Наиболее иллюстративными получились следующие две тепловые карты:

  1. «ширина таблицы» \times «номер строки»: W \times r;

  2. «ширина таблицы» \times «взаимная удаленность столбцов»: W \times (q - t). Читать тепловую карту нужно следующим образом. Рассмотрим ячейку в i‑й строке и j‑м столбце. Если i < j (выше диагонали), то в ячейке находится процент правильных ответов, где ширина таблицы j, а взаимная удаленность столбцов i. Если же i > j» src=«https://habrastorage.org/getpro/habr/formulas/8/82/82d/82d9ee4dc7c06fbb25042586e15b25fe.svg» />, то ширина таблицы <img alt=, а взаимная удаленность столбцов -j. Другими словами, над диагональю собраны вопросы, где столбец с вопросом находится правее столбца с ответом, а под диагональю, наоборот, левее.

Вот как они выглядят для некоторых моделей на Синтетике-3.

GigaChat-Max. Визуализация

GigaChat-Max. Визуализация W \times r

Llama-3.1-405B. Визуализация

Llama-3.1–405B. Визуализация W \times r

Qwen-2.5-32B. Визуализация

Qwen-2.5–32B. Визуализация W \times r

GigaChat-Max. Визуализация

GigaChat-Max. Визуализация W \times (q - t)

Llama-3.1-405B. Визуализация

Llama-3.1–405B. Визуализация W \times (q - t)

Qwen-2.5-32B. Визуализация

Qwen-2.5–32B. Визуализация W \times (q - t)

Для каждой ячейки в тепловой карте W \times r было выбрано по 10 вопросов (если данных в источнике было недостаточно, то брали сколько есть). При этом расстояние q - t мы выбирали из равномерного распределения от -W+1 до W-1.

Результаты

Результаты замеров на всех подмножествах приведены в таблице. Поскольку задача достаточно сложная, мы рассматривали только модели средних и больших размеров. Замеры мы проводили для моделей с открытыми весами Gemma-2–27B, Qwen-2.5–32B, Llama-3.1–70B, Qwen-2.5–72B, Mistral‑Large-123B, Llama-3.1–405B, а также коммерческих моделей Сбера GigaChat‑Pro и GigaChat‑Max. К средним мы относим модели до 34 миллиардов параметров, к большим — 70 и больше.

Model

wiki

gosts

syn1

syn2

syn3

syn4

syn5

Avg

Gemma-2–27B

63

67

79

51

33

73

43

58.4

Qwen-2.5–32B

77

80

96

78

66

95

97

84.1

GigaChat-Pro

60

57

86

45

47

99

65

65.6

Llama-3.1–70B

73

78

96

50

33

99

97

75.1

Qwen-2.5–72B

78

83

95

71

59

96

96

82.6

Mistral-Large-2–123B

69

78

87

59

46

92

83

73.4

Llama-3.1–405B

82

87

97

76

54

99

98

84.7

GigaChat-Max

79

89

97

53

48

99

97

80.3

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

Из средних моделей особенно выделяется Qwen-2.5 на фоне Gemma-2 и GigaChat‑Pro. Примечательно, что модель Qwen-2.5 с 32 миллиардами параметров даже опережает Qwen-2.5 с 72 миллиардами параметров.

Среди больших моделей в лидерах Llama-3.1–405B, Qwen-2.5–72B и GigaChat‑Max.

Синтетика-2 и Синтетика-4 схожи по количеству символов и имеют одни и те же заголовки. Тем не менее все модели на Синтетике-2 показывают относительно слабые результаты. Вероятно, здесь сыграло то, что буквы A, B, C, D, E, F встречаются как в названиях столбцов, так и в значениях ячеек. Поэтому модели сложнее отфильтровать шум в виде одинаковых токенов: например, «A» как заголовок и «A» как токен из строки »#A0FFFF». Синтетика-3 была еще сложнее из‑за того, что названия колонок шумные и не связаны семантически со значениями.

Как и ожидалось, самым простым подмножеством для моделей, особенно небольших,  была Синтетика-1. Высокие результаты всех моделей, кроме Gemma-2, на Синтетике-1 объясняются тем, что данные в столбцах разнородны и нужное значение в заданной строке можно найти по семантике значений. Если же все значения однородны, как в других синтетических подмножествах, то для успешного решения задачи необходимо «отсчитать» нужное количество столбцов вправо или влево. Это для моделей небольших размеров оказалось сложной задачей. Например, задан вопрос: «Какое B, если E равно 123?» Человек, если ему дать таблицу в виде одной строки без переносов строк и других визуальных подсказок, будет решать эту задачу так:

  1. Найдет столбцы B и E. Запомнит, что между ними 3 столбца (3 символа »|» — разделителя между ячейками в markdown).

  2. Найдет значение »123». Заметим, что в нашем сетапе все значения в синтетических таблицах уникальные, поэтому если в вопросе упоминается значение »123», то нам не нужно дополнительно проверять, в каких еще столбцах помимо E оно может находиться.

  3. Отсчитает влево 3 символа »|». Полученное значение и будет ответом на вопрос.

Большие модели навык счета выучили хорошо. Возможно, дело в размере модели. Однако, как показывает Qwen-2.5–32B, таких же результатов возможно добиться и за счет качественных данных в обучении.

Почему же мы так уверены, что дело именно в навыке счета? Давайте посмотрим на следующую диаграмму:

9ae6d0837410804e0329a7d633473dfc.png

На ней мы видим, что наиболее зеленые значения встречаются в трех местах:

  • в левом верхнем углу, где колонок не так много и таблицы более простые;

  • в верхней строке и левой колонке: это соответствует парам столбцов, которые находятся рядом друг с другом на расстоянии +1 либо -1;

  • сразу над и под диагональю: это соответствует парам столбцов, где один первый, а второй последний. Считать, как в алгоритме выше, здесь не нужно, потому что у первых и последних столбцов есть «подсказка» в виде стоящего рядом (до или после) символа конца строки »\n».

Выводы

Даже самые передовые LLM пока не могут справиться с анализом больших сложных таблиц. Возможно, они научатся это делать в ближайшем будущем, а возможно — эта задача так и останется нерешаемой для чисто текстовых моделей. Поэтому интересно будет проверить мультимодальные картиночно‑текстовые модели, в том числе наш GigaChat Vision. О том, как протестировать самые свежие версии GigaChat Pro, GigaChat MAX, а также GigaChat Vision, читайте в документации.

В дальнейшем мы планируем рассмотреть другие, более комплексные типы задач с таблицами по примеру TableBench и добавить этот бенчмарк в MERA.

Над статьей работали Даниил Водолазский, Вильдан Сабуров, Данил Сазанаков. Дизайн обложки выполнила Дарья Пономарева. Благодарим за помощь в подготовке статьи Юлию Горшкову и Григория Лелейтнера.

© Habrahabr.ru