Форматирование таблиц в ИИ-суммаризаторах: почему нейросети искажают цифры

Модель не пыталась вас обмануть. Она просто неверно прочитала таблицу.

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

Исследователи команды TabFaith разбирали именно такие сбои. Их работа помогает понять, почему форматирование таблиц в ИИ-суммаризаторах влияет на результат и почему обычная оценка качества текста не всегда замечает ошибку в цифрах.

Как языковые модели считывают табличную структуру и почему возникают системные сбои

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

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

В работе Table Meets LLM ответы заметно зависели от того, как именно была оформлена одна и та же таблица: от порядка данных, разделителей и подсказок. Это не означает, что всякая смена формата обязательно приводит к ошибке. Результат показывает другое: способ представления данных может влиять на выполнение табличной задачи, даже если исходная информация не изменилась.

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

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

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

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

Пять главных типов структурных искажений при суммаризации данных

Команда TabFaith составила бенчмарк из 2400 троек: таблица, резюме и разметка ошибки. В него вошли данные из ToTTo, где представлены открытые таблицы из Википедии, и TabSum-Ent, охватывающего финансовые отчёты, клинические записи и операционные панели. Такой набор позволяет изучать разные виды таблиц, хотя результаты конкретного бенчмарка сами по себе не описывают все возможные документы и рабочие сценарии.

Исследователи выделили пять типов структурных ошибок. В доступном описании четыре из них раскрыты достаточно подробно:

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

2. Неверная привязка к строке или столбцу. Значение из строки одной компании или категории приписывается другой. Особенно легко это представить в таблице с похожими названиями и несколькими показателями.

3. Выдуманное сравнительное ранжирование. Модель объявляет один показатель лидирующим или делает вывод о разрыве между участниками, хотя такой вывод не следует из данных или не задан способом сравнения.

4. Смешение временных периодов. Квартальное значение описывается как годовое или показатели разных периодов сводятся в одно утверждение.

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

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

Суммаризатору проще удержать отдельное число, чем одновременно сохранить все его связи: кто или что измеряется, к какому периоду относится значение и с чем его допустимо сравнивать. Поэтому при проверке полезно читать утверждение целиком, а не выхватывать из него одну цифру. Вопрос звучит так: могу ли я показать в исходнике не только это значение, но и его подпись, период и основание для сравнения?

Почему традиционные метрики оценки текста не работают для табличных сводок

Качество обычных текстовых резюме часто оценивают метриками вроде BLEU, PARENT и BERTScore. Они сравнивают сгенерированный текст с эталоном по совпадению слов, фраз, содержательных элементов или смысловой близости. Для многих задач такие показатели дают полезную информацию о сходстве текстов. Но табличная достоверность требует отдельного вопроса: верно ли модель связала каждое утверждение с конкретными ячейками?

В работе TabFaith приводятся корреляции этих метрик с человеческой оценкой достоверности. В описанной оценке BLEU показал корреляцию 0,24, PARENT — 0,60, а BERTScore — до 0,60. Эти результаты говорят о связи показателей с человеческой оценкой в рамках исследования. Они не означают, что метрика вообще не может быть полезна или что любая система, использующая её, не умеет проверять факты другими способами.

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

Поэтому результат BLEU или BERTScore нельзя автоматически читать как оценку того, насколько верно сохранена структура таблицы. Если сервис сообщает о качестве саммари по одной из этих метрик, стоит выяснить, какие ещё проверки он использует. По названию показателя нельзя заключить, что система проверила или не проверила связь чисел с исходными ячейками.

Таблица с результатами конкретной оценки выглядит так:

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

Метрика STAF и метод CAVE как способ верификации числовых значений

В TabFaith предложена метрика STAF, ориентированная на структурную достоверность. В общих чертах она проверяет, можно ли подтвердить утверждения резюме соответствующими элементами исходной таблицы. Такой подход ближе к вопросу, который волнует редактора или аналитика: на какие именно данные опирается фраза?

В описанной оценке корреляция STAF с человеческой оценкой достоверности составила 0,94. Это сильный результат для этой выборки и постановки задачи. Но высокая корреляция не превращает оценку отдельного резюме в гарантию точности. Она не означает, что любой документ, получивший хорошую оценку STAF, можно публиковать без проверки. Исследование показывает перспективность метрики в заданных условиях, а не безошибочность инструмента во всех случаях.

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

CAVE в этой работе описан как метод проверки и редактирования: утверждения сопоставляются с ячейками, а неподтверждённые фрагменты исправляются. В среднем по пяти моделям STAF после применения CAVE вырос на 0,14, а для утверждений, связанных с числами, на 0,17. Это результат сравнения в рамках исследования. Он показывает улучшение оценки STAF после обработки, но не доказывает, что в ежедневных сводках стало меньше ошибок или что такой же эффект возникнет при использовании других данных и систем.

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

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

Альтернативные форматы подачи данных и роль JSON в обработке отчётов

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

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

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

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

Отдельный арифметический модуль полезен для вычислений, которые можно сформулировать как конкретную операцию: например, проверить сумму или пересчитать процент. Такой модуль помогает отделить счёт от генерации текста. Но он не решит задачу, если модель неверно выбрала исходные ячейки: корректно выполненное сложение неправильных значений всё равно даст неверный вывод.

В ежедневной работе можно придерживаться простого порядка:

• Передавайте таблицу в структурированном виде, если сервис его поддерживает, и проверяйте, сохранились ли заголовки, единицы измерения и периоды.
• Просите отделять факты из таблицы от выводов, которые модель делает на их основе. Так легче увидеть, где заканчивается пересказ и начинается интерпретация.
• Для сумм, процентов и средних используйте отдельную проверку вычислений, если эти значения важны для решения.
• Сверяйте утверждения, в которых есть крупные цифры, сравнения и данные за разные периоды. Начните с тех фрагментов, где ошибка сильнее всего изменит смысл отчёта.
• Если сервис показывает метрику качества, уточните, что именно она проверяет. BLEU и BERTScore сами по себе не отвечают на вопрос, к какой ячейке относится число.

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

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

Отказываться от ИИ-суммаризаторов из-за этого не нужно. Полезнее понимать, где именно они могут ошибиться, и выбирать формат, который сохраняет структуру данных. Если в сводке есть значимые числа, загляните в исходную таблицу и проверьте не только значение, но и его строку, столбец и период. Гладкость пересказа помогает читать. Достоверность подтверждают данные.