Вступление
Всем привет! С вами команда IDP. Сегодня расскажем о том, как мы оцениваем языковые модели для ответов на вопросы по таблицам.
Наша команда занимается интеллектуальной обработкой документов, и мы нередко сталкиваемся с документами, содержащими таблицы. Человек обычно анализирует их, опираясь на геометрию и визуал (границы ячеек, выделение заголовков, выравнивание текстов в ячейках). Таблицы — это двумерные объекты, языковые модели же работают с одномерными последовательностями токенов. Это наталкивает на вопрос: а насколько хорошо LLM справляются с анализом таблиц в документах?
Мы заинтересовались этой темой неслучайно — в одном из проектов мы работали над вопросно‑ответной системой для технической документации. Большинство вопросов относилось именно к таблицам, причем таблицы были достаточно сложными, с длинными названиями столбцов, формулами и многоуровневыми заголовками. В один момент мы уперлись в потолок по метрикам и тогда решили провести более тщательное исследование.
Выбор данных
Мы фокусируемся только на одной задаче и на одном типе вопросов. Таблица тоже подается одна, хотя на практике в документе их бывает несколько.
Для исследования мы отобрали таблицы из двух источников: энциклопедий (Википедия) и технических документаций (ГОСТы); а также синтезировали несколько дополнительных наборов таблиц, чтобы оценить влияние однородности значений и сложности текста в ячейках. Таблицы, полученные из свободных источников, прошли несколько этапов предобработки. Предварительно мы перевели их из формата HTML в markdown, поскольку он обычно используется в предобучении языковых моделей и является экономным с точки зрения количества токенов. Многоуровневые заголовки были объединены через «/» в плоские заголовки. Объединенные ячейки разбивались, а тексты в разбитых ячейках дублировались. Таблицы выбирали шириной от 2 до 16 столбцов, высотой от 1 до 64 строк.
Таблицы в подмножествах отличались по следующим признакам:
размеры таблицы (ширина и высота);
однородность значений в столбцах (можно ли без заголовка определить, какой столбец что означает);
количество текста в ячейках (чем его больше, тем сложнее для модели должна быть задача).
Примеры таблиц:
Постановка задачи
Главная задача модели в вопросах к таблицам — понимать связь между разными столбцами и строками. Чтобы проверить, насколько разные LLM справляются с этим, нам нужно было создать вопрос, который бы требовал сравнения хотя бы по паре строк или столбцов.
Мы выбрали самую естественную и частотную (что также подтверждалось статистикой по нашему проекту) структуру вопроса: «Какое значение столбце target, если в столбце query значение равно X?»
Для ответа на этот вопрос требуется не только найти в таблице два заданных столбца и , но и определить целевую строку по переданному значению , а затем извлечь ответ из ячейки в столбце.
Формализовав структуру вопроса как «Какой , если — ?», мы сгенерировали вопросы простым алгоритмом: перебирая все , , в таблице. В итоговый датасет попали только вопросы, для которых существует единственный ответ , причем его значение встречается в столбце ровно один раз — это снижает вероятность угадать ответ, выбрав самое частотное значение.
Формат промпта для LLM:
{system_prompt}
-----
{table}
-----
{question}
Системный промпт мы подобрали такой, чтобы все модели понимали инструкцию и следовали формату. В ответе мы ожидаем значение из какой‑то одной ячейки таблицы. Мы проверили, что сильные модели хорошо соблюдают формат без дополнительных пояснений. Формулировка получилась такая:
Ты — эксперт по интеллектуальной обработке документов. Тебе на вход передана таблица из документа. Ответь на вопрос, опираясь ТОЛЬКО на данные из этой таблицы.
Для оценки ответа модели использовалась метрика exact match: 1, если ответ совпал, и 0 иначе.
Методология оценки
Наиболее иллюстративными получились следующие две тепловые карты:
«ширина таблицы» «номер строки»: ;
«ширина таблицы» «взаимная удаленность столбцов»: . Читать тепловую карту нужно следующим образом. Рассмотрим ячейку в ‑й строке и ‑м столбце. Если (выше диагонали), то в ячейке находится процент правильных ответов, где ширина таблицы , а взаимная удаленность столбцов . Если же , то ширина таблицы , а взаимная удаленность столбцов . Другими словами, над диагональю собраны вопросы, где столбец с вопросом находится правее столбца с ответом, а под диагональю, наоборот, левее.
Вот как они выглядят для некоторых моделей на Синтетике-3.
Для каждой ячейки в тепловой карте было выбрано по 10 вопросов (если данных в источнике было недостаточно, то брали сколько есть). При этом расстояние мы выбирали из равномерного распределения от до .
Результаты
Результаты замеров на всех подмножествах приведены в таблице. Поскольку задача достаточно сложная, мы рассматривали только модели средних и больших размеров. Замеры мы проводили для моделей с открытыми весами 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?» Человек, если ему дать таблицу в виде одной строки без переносов строк и других визуальных подсказок, будет решать эту задачу так:
Найдет столбцы B и E. Запомнит, что между ними 3 столбца (3 символа «|» — разделителя между ячейками в markdown).
Найдет значение «123». Заметим, что в нашем сетапе все значения в синтетических таблицах уникальные, поэтому если в вопросе упоминается значение «123», то нам не нужно дополнительно проверять, в каких еще столбцах помимо E оно может находиться.
Отсчитает влево 3 символа «|». Полученное значение и будет ответом на вопрос.
Большие модели навык счета выучили хорошо. Возможно, дело в размере модели. Однако, как показывает Qwen-2.5–32B, таких же результатов возможно добиться и за счет качественных данных в обучении.
Почему же мы так уверены, что дело именно в навыке счета? Давайте посмотрим на следующую диаграмму:
На ней мы видим, что наиболее зеленые значения встречаются в трех местах:
в левом верхнем углу, где колонок не так много и таблицы более простые;
в верхней строке и левой колонке: это соответствует парам столбцов, которые находятся рядом друг с другом на расстоянии +1 либо -1;
сразу над и под диагональю: это соответствует парам столбцов, где один первый, а второй последний. Считать, как в алгоритме выше, здесь не нужно, потому что у первых и последних столбцов есть «подсказка» в виде стоящего рядом (до или после) символа конца строки «\n».
Выводы
Даже самые передовые LLM пока не могут справиться с анализом больших сложных таблиц. Возможно, они научатся это делать в ближайшем будущем, а возможно — эта задача так и останется нерешаемой для чисто текстовых моделей. Поэтому интересно будет проверить мультимодальные картиночно‑текстовые модели, в том числе наш GigaChat Vision. О том, как протестировать самые свежие версии GigaChat Pro, GigaChat MAX, а также GigaChat Vision, читайте в документации.
В дальнейшем мы планируем рассмотреть другие, более комплексные типы задач с таблицами по примеру TableBench и добавить этот бенчмарк в MERA.
Над статьей работали Даниил Водолазский, Вильдан Сабуров, Данил Сазанаков. Дизайн обложки выполнила Дарья Пономарева. Благодарим за помощь в подготовке статьи Юлию Горшкову и Григория Лелейтнера.
Комментарии (26)
rPman
08.11.2024 14:30Заливать в контекст все данные и ожидать что современный слабый ИИ сумеет это все корректно переработать - опрометчиво. Собственно любые результаты в приведенных в табличках, отличных от зеленых - уже неприемлемы.
p.s. А теперь сделайте по другому, данные нужно передавать ИИ в режиме чата построчно (если нужна информация о прошлых решениях, этого кстати нужно избегать) илилучше по одному объекту за раз (используя KV-cache), в системном промпте нужно собственно привести несколько примеров (разных но охватывающих по больше особенностей), затем задать вопрос.
Например - нам нужно найти 'совпадения по смыслу', например собираем справочники (да, знаю для этого лучше дообучить свою модель - классификатор, но обычно это дороже). Мы описываем в системном промте что то типа - На каждую приведенную строку с данными нужно определить, к какой области знаний она относится (можно указать список доступных а если нет, как то описать, до какой степени их нужно дробить, типа наука, математика, геометрия, матанализ, методы перемножения матриц), ответ давать как в следующих примерах:
данные: Химия твердых тел
ответ: химия
данные: Рассуждения о смысле жизни
ответ: философияПосле чего достаточно в виде чата слать модели данные в указанном формате и получать ответ. Строгий формат позволит уйти от проблем с поиском конца ответа и излишними рассуждениями (кстати можно РАЗРЕШИТЬ рассуждать, но требовать ответа в нужном формате все равно), чем страдают слабые модели (та же qwen хоть и лучшая из открытых, но может легко выплюнуть китайский иероглиф в ответе).
p.p.s. я понимаю, что всем хочется, что бы можно было скормить случайную pdf-ку с таблицами в любом оформлении, и модель все поняла и сделала (с этим люди то справляются не очень)
s231644 Автор
08.11.2024 14:30С утверждением про опрометчивость я согласен частично. Наши эксперименты показали, что для таблиц определенной структуры и сложности подход «заливать в контекст все данные» оказывается рабочим, чего не ожидали даже мы сами!
Построчно можно, но представьте, насколько это будет дольше. В нашей постановке делается один запрос в LLM и получается один короткий ответ. В вашем решении нужно делать до 64 вызовов, получать 64 ответа, потом еще как-то их агрегировать.
Вообще говоря, то, что для таблицы из одной строки (и заголовка) модель будет отвечать хорошо, мы уже показали. На тепловых картах все метрики близки к 90-100% для , причем это когда ответ находится в первой строке, хотя сами таблицы могут быть и больше.
Про случайную pdf-ку всё правда. Задача сложная, но тем и интересная!
rPman
08.11.2024 14:30Да, даже openai показала что одним запросом решать - тупиковый (ну пока) путь, и сделали агентную систему o1, где под капотом ИИ последовательно и параллельно обрабатывает запрос, вопрос и что то еще, собирая и добавляя промежуточные данные в контекстное окно.
Скорее всего сначала нужно проанализировать вопрос, потребовав от ИИ алгоритм решения задачи на основе которого провести серию запросов к данным, преобразование данных, возможно понадобится запрос во внешние базы и сервисы и т.п.
Надеяться ВСЕ свои задачи решать, заливая одним махом все в GPT - просто глупо, уже столько обсосали его недостатков... GPT это конвертер данных (не только между языками но и стилистически, по смыслу и наполнению), он почти не умеет в анализ (удивительно что ИНОГДА у него получается, что говорит о колоссальной избыточности), это что то типа интуиции, которая может очень быстро дать ответ, возможно правильный, но тщательная подготовка перед вопросом может увеличить точность ответа кратно.
ENick
08.11.2024 14:30Интересно принципиально иной алгоритм проверить, типа табличного RAG
s231644 Автор
08.11.2024 14:30Конкретно эту задачу можно решить и генерацией простого SQL/pandas-запроса к таблице. Через RAG она тоже решается, однако если бы вопрос стоял «Какое максимальное значение в столбце ?», то RAG был бы бессилен.
Мы специально стали решать задачу «в лоб», поскольку любой частный подход не будет универсальным, а от LLM часто ждут именно этого.
squaremirrow
> Даже самые передовые LLM пока не могут справиться с анализом больших сложных таблиц.
Но ведь вы не проанализировали ни одну из передовых LLM. Уверен, что результаты Claude 3.5 Sonnet или GPT-o1 были бы гораздо лучше
s231644 Автор
Правильнее было бы сказать «самые передовые и при этом доступные». Согласен, что от o1 и Claude 3.5 Sonnet ожидаются более высокие результаты, но в качество 100% я не верю, особенно в постановке задачи без Chain-of-Thought. Когда опубликуем бенчмарк, все желающие смогут проверить на нем и другие модели, в том числе названные вами.
squaremirrow
А в чем проблема с доступом к обеим моделям? Обе доступны по подписке за $20 в месяц. А по API ещё дешевле. Вам помочь получить бесплатные $1000 кредитов на Azure, чтобы вы могли протестировать GPT o1?
s231644 Автор
Каждое подмножество --- это 10000 уникальных таблиц, каждая из которых до 32 тысяч токенов. У нас 5 синтетических сетов.токенов. С ценой $3 за млн токенов получается 1600 баксов, и это только Claude 3.5 Sonnet без учета затрат на генерацию. o1 с их test-time compute будет еще дороже.
Но цена не главное.
Мы хотим использовать модели не только для того, чтобы выполнить замеры и впечатлить вас, но и для ряда других задач, в том числе на внутренних данных, передача которых по API в сторонние компании запрещена. Поэтому и рассматриваем только те модели, которые возможно использовать локально.
Дальше будем улучшать бенчмарк, добавлять в него новые задачи и готовить академическую статью. Вот тогда и проведем замеры на более дорогих моделях.
thethee
А когда публикация бенчмарка? Хотя бы примерно. Я бы хотел на нем погонять некоторые русскоязычные файнтюны, для задач используем не сильно большие локальные LLM и с таблицами довольно часто приходится работать.
s231644 Автор
На следующей неделе узнаю у коллег про сроки. Думаю, это будет в начале декабря. Можем с вами в частном порядке договориться насчет раннего доступа.