TL;DR
TabReX — метод проверки таблиц, созданных LLM, который конвертирует и таблицу, и исходный текст в графы фактов (триплеты вида "субъект — свойство — значение"), выравнивает их и считает несоответствия. В отличие от большинства метрик, которые сравнивают таблицы как текст, TabReX работает без эталонной таблицы — проверяет только против исходного текста, из которого таблица должна быть построена.
Большинство метрик оценки таблиц игнорируют структуру — они считают совпадения слов или похожесть эмбеддингов, как будто таблица это абзац текста. Поэтому они не видят критических ошибок: переставленные столбцы, перепутанные единицы измерения, числа в чужих строках. LLM регулярно делают такие ошибки незаметно — таблица выглядит правильной, но факты внутри сломаны. Исследование показало: размер модели улучшает точность на уровне отдельных ячеек, но почти не помогает на уровне всей структуры таблицы. "Thinking" режимы (вроде o1) точнее, но часто пропускают данные, предпочитая осторожность полноте.
TabReX решает проблему через четырёхшаговую проверку: (1) извлечь факты из текста, (2) извлечь факты из таблицы, (3) сопоставить факты между собой, (4) посчитать штрафы за пропущенные, лишние и неправильные данные. Каждая ячейка таблицы становится фактом ("Компания А — выручка 2023 — 150 млн"), который можно точно сравнить с фактами из текста. Метод показывает где именно таблица врёт — на уровне конкретных ячеек.
Схема метода
ШАГ 1: Text2Graph
Исходный текст → список фактов (субъект, свойство, значение)
Пример: "Выручка Яндекса в 2023 году — 150 млрд"
→ ("Яндекс", "выручка_2023", "150 млрд руб")
ШАГ 2: Table2Graph
Таблица → список фактов по правилу (строка = субъект, столбец = свойство, ячейка = значение)
ШАГ 3: Graph Alignment
Сопоставить факты из текста и таблицы:
- Совпадают полностью → ОК
- Частично (число отличается) → штраф пропорционален отклонению
- Есть в таблице, нет в тексте → галлюцинация
- Есть в тексте, нет в таблице → пропуск
ШАГ 4: Property-Driven Scoring
Посчитать итоговый штраф:
- За пропущенные факты (недостаточная полнота)
- За лишние факты (галлюцинации)
- За частичные совпадения (неточные числа/единицы)
Все 4 шага можно попросить выполнить LLM в одном промпте или последовательно.
Пример применения
Задача: Ты попросил ChatGPT создать таблицу конкурентов твоего SaaS-продукта для презентации инвесторам — название, цена, число клиентов. В исходном тексте были данные из пресс-релизов и открытых источников. Нужно проверить, не напридумывала ли модель цифры.
Промпт:
Вот исходный текст с информацией о конкурентах:
[текст: "Амоначала в марте 2024 объявила о 50 тысячах клиентов.
Битрикс24 берёт от 1990₽/мес за тариф Стандарт..."]
Вот таблица, которую ты создал:
| Компания | Тариф | Цена | Клиентов |
|----------|-------|------|----------|
| Амоначала | Базовый | 990₽ | 50 000 |
| Битрикс24 | Стандарт | 1990₽ | н/д |
Задача: проверь таблицу на фактическую корректность.
ШАГ 1: Извлеки все факты из исходного текста в формате
"субъект — свойство — значение".
ШАГ 2: Извлеки все факты из таблицы в том же формате.
ШАГ 3: Сопоставь факты. Найди:
- Совпадения (всё ОК)
- Расхождения (число/название отличается)
- Галлюцинации (в таблице есть, в тексте нет)
- Пропуски (в тексте есть, в таблице нет)
ШАГ 4: Дай вердикт для каждой ячейки: ✅ корректно,
⚠️ неточно (укажи отклонение), ❌ галлюцинация.
Результат:
Модель покажет пошаговое сравнение: - Список фактов из текста (5-10 триплетов) - Список фактов из таблицы (4-6 триплетов по числу ячеек) - Сопоставление с пометками: например, "Амоначала — тариф — Базовый" не найдено в тексте → ❌ галлюцинация - Итоговую таблицу с метками корректности для каждой ячейки
Ты сразу видишь: модель выдумала название тарифа (в тексте не было "Базовый"), остальные данные совпали.
Почему это работает
LLM не держат в памяти жёсткую структуру — при генерации таблицы модель предсказывает токены по порядку, и к моменту заполнения нижних строк "забывает", какие данные куда должны попасть. Отсюда перестановки, дубли, числа из воздуха.
Сильная сторона LLM — извлечение фактов и сопоставление списков. Когда ты просишь "найди все утверждения вида X про Y", модель хорошо это делает. Факты проще таблиц — это линейный список, без координат строк-столбцов.
Метод использует эту силу для обхода слабости: разбивает двумерную таблицу на одномерный список фактов, где каждая ячейка — отдельное утверждение. Теперь проверка превращается в задачу текстового сопоставления: есть ли в исходнике факт "Компания А — выручка — 150 млн"? Модель сравнивает не позиции в сетке, а смысловые утверждения — и ошибки всплывают явно.
Рычаги управления промптом:
Гранулярность извлечения — можно попросить факты "по каждой ячейке" или "только по ключевым столбцам". Для больших таблиц второе экономит токены.
Строгость сопоставления — добавь инструкцию "числа должны совпадать точно" или "допустимо отклонение до 5%". Первое для финансов, второе для приблизительных данных.
Формат вывода — попроси "только ячейки с ошибками" вместо полного отчёта, если таблица большая и нужен быстрый чек-лист.
Вес ошибок — укажи "галлюцинации критичны, пропуски допустимы" или наоборот, в зависимости от задачи. Для презентации инвестору важнее не наврать, для чернового анализа — не пропустить данные.
Шаблон промпта
Исходный текст:
{текст_с_данными}
Таблица для проверки:
{таблица_в_markdown}
Проверь таблицу на фактическую корректность:
ШАГ 1: Извлеки все факты из исходного текста в формате
"субъект — свойство — значение".
Пример: ("Яндекс", "выручка_2023", "150 млрд руб").
ШАГ 2: Извлеки все факты из таблицы:
- субъект = строка
- свойство = столбец
- значение = ячейка
ШАГ 3: Сопоставь факты:
- ✅ Совпадение — факт из таблицы точно есть в тексте
- ⚠️ Расхождение — есть, но значение отличается (укажи разницу)
- ❌ Галлюцинация — в таблице есть, в тексте нет
- ⬜ Пропуск — в тексте есть, в таблице нет
ШАГ 4: Итоговая таблица с метками для каждой ячейки.
Плейсхолдеры:
- {текст_с_данными} — исходный текст, из которого строилась таблица (пресс-релиз, отчёт, статья)
- {таблица_в_markdown} — таблица, которую создала LLM
Для больших таблиц (>50 ячеек): Добавь после ШАГа 3:
Группируй факты по столбцам — сначала провери все ячейки столбца "Цена",
потом "Клиентов" и т.д. Это снизит ошибки сопоставления.
Ограничения
⚠️ Размер таблицы: Для таблиц >100 ячеек проверка занимает много токенов и времени — на извлечение и сопоставление фактов модель тратит 2000-5000 токенов. Для огромных таблиц (финансовая отчётность на 200 строк) лучше проверять по частям — отдельно каждый раздел.
⚠️ Неоднозначные данные: Если в исходном тексте написано "около 50 тысяч клиентов", а в таблице "50 000", модель может засчитать расхождение. Нужно явно указать в промпте: "допускай округления и приблизительные формулировки".
⚠️ Сложные вычисления: Если таблица содержит агрегаты (суммы, средние), которых нет в исходном тексте явно, метод не поможет — он проверяет только прямые факты. Для проверки формул нужна отдельная техника (попросить модель пересчитать).
⚠️ Структурные трансформации: Метод НЕ видит логические ошибки в организации таблицы — например, если столбцы "Цена" и "Валюта" должны были быть раздельными, а модель слила их в один. Факты могут совпасть ("Компания А — цена — 1000$"), но структура сломана.
Как исследовали
Исследователи из Arizona State University и Adobe создали TabReX-Bench — бенчмарк для стресс-теста метрик оценки таблиц. Взяли 710 таблиц из шести реальных датасетов: финансовая отчётность (FinQA), медицинские данные (MIMIC-IV), спортивные сводки (RotoWire), сложные многоуровневые таблицы из Википедии. Для каждой таблицы LLM-планировщик сгенерировал 12 испорченных версий — от лёгких (переставить строки, округлить числа) до жёстких (подменить данные, добавить галлюцинации). Получилось 9120 вариантов с разными видами ошибок.
Хитрость в том, что портить таблицы тоже поручили LLM — не вручную и не рандомом, а через плановый подход. Модель получала таблицу и инструкцию "сделай 12 версий: 3 лёгких неструктурных изменения, 3 средних, 3 жёстких, 3 фактических искажения". Это имитирует типичные ошибки генерации, а не абстрактный шум. Каждую испорченную таблицу оценили люди (насколько сломана) и все популярные метрики — от BLEU до TabXEval.
Результат удивил: старые метрики (BLEU, ROUGE) почти не коррелируют с экспертными оценками — корреляция Спирмена 0.3-0.4. Даже BERT-based метрики путают безобидную перестановку столбцов с фактическими ошибками. TabXEval, лучшая reference-based метрика (корреляция 0.80), часто ставит одинаковый балл разным по качеству таблицам — tie ratio 45%, то есть в половине случаев метрика не видит разницы. TabReX показал корреляцию 0.75 без эталонной таблицы, при этом различает больше градаций ошибок (tie ratio 13.6%).
Ключевой инсайт: чем сложнее таблица, тем сильнее деградируют поверхностные метрики. На графике чувствительность/специфичность почти все метрики за переход от лёгких к жёстким примерам сваливаются вниз-влево — начинают либо пропускать ошибки (sensitivity падает), либо ругаться на всё подряд (specificity падает). TabReX остался в "зелёной зоне" баланса, потому что сравнивает факты, а не токены — переставленные столбцы дают те же триплеты, реальная подмена цифр их меняет.
Финальный эксперимент: попросили четыре LLM (Gemma 4B/27B, InternVL в обычном и "думающем" режимах) сгенерировать таблицы из текстов. Эксперты ранжировали выходы по трём критериям: структура, факты, полнота. TabReX предсказал ранжировку точнее всех (корреляция Кендалла 0.30 vs 0.17-0.20 у конкурентов), причём показал почему модели ошиблись — на уровне отдельных ячеек. Выяснилось: большие модели (27B) лучше на локальной точности (цифры в ячейках), но не на глобальной структуре (логика столбцов). "Thinking" режимы осторожнее и точнее, но пропускают данные — recall ниже на 15-20%.
Адаптации и экстраполяции
🔧 Техника: Агрегатная проверка → валидация вычислений
TabReX проверяет только прямые факты — то, что явно написано в тексте. Но часто таблицы содержат вычисления: суммы, проценты, средние.
Добавь ещё один шаг после ШАГа 4:
ШАГ 5: Проверь вычисляемые столбцы.
Для каждого столбца, который выглядит как итог/процент/среднее:
- Пересчитай значение из других столбцов
- Сравни с тем, что в таблице
- Отметь расхождения >5% как ⚠️ ошибка расчёта
Пример: Таблица выручки компаний со столбцами "Q1", "Q2", "Q3", "Q4", "Год". Модель может правильно взять Q1-Q4 из текста, но ошибиться в сумме. Доп. шаг это поймает.
🔧 Техника: Двухсторонняя проверка → найти пропуски в тексте
Исходный TabReX проверяет "не наврала ли таблица". Но иногда нужно обратное: "всё ли из текста попало в таблицу"?
Перефразируй ШАГ 3:
ШАГ 3 (альтернативный): Сопоставь факты В ДРУГУЮ СТОРОНУ.
Для каждого факта из ТЕКСТА проверь:
- Есть ли он в таблице → ✅
- Нет в таблице, но должен быть → ⬜ важный пропуск
- Нет в таблице, и это нормально (не табличные данные) → игнорируем
Когда нужно: Ты даёшь LLM большой отчёт на 10 страниц и просишь "выдери все числа в таблицу". Важно, чтобы ничего не потерялось. Обычная проверка TabReX не покажет пропусков — только галлюцинации и искажения.
🔧 Техника: Замена "субъект-свойство-значение" на domain-специфичный формат
Исследование использует универсальные триплеты. Но для конкретных доменов можно упростить и ускорить.
Для финансовых таблиц:
ШАГ 1 (финансы): Извлеки факты в формате:
"Компания | Метрика | Период | Значение | Единицы"
Пример: "Яндекс | Выручка | 2023 Q4 | 150 | млрд руб"
Для таблиц продуктов:
ШАГ 1 (товары): Извлеки факты в формате:
"Продукт | Характеристика | Значение"
Пример: "iPhone 15 Pro | Цена | 89 990₽"
Специализированный формат снижает ошибки парсинга — модель лучше понимает, что искать, и создаёт более однородные списки фактов.
Ресурсы
TabReX: Tabular Referenceless eXplainable Evaluation — Tejas Anvekar, Juhna Park, Aparna Garimella, Vivek Gupta (Arizona State University, Adobe Research).
Исследование опирается на предыдущие работы по оценке структурированных данных: PARENT (Dhingra et al., 2019) для grounding evaluation, TabEval (Ramu et al., 2024) и TabXEval (Pancholi et al., 2025) для rubric-based подходов.