TL;DR
Исследование показало: LLM не умеют автоматически замечать и исправлять ошибки в структуре таблиц — когда данные присутствуют, но столбцы съехали, заголовки перепутаны или строки сдвинулись. Человек видит такую таблицу и понимает "что-то не так", модель — нет. Только явная инструкция "проверь таблицу на ошибки перед анализом" частично активирует проверку, но не гарантирует исправление.
Главная находка: Даже топовые модели (GPT-5.2) теряют минимум 22% точности на искажённых таблицах. Причина — LLM обучены сканировать заголовки и первые строки, извлекая смысл, но игнорируют глобальную структуру. Вертикальные сдвиги столбцов (когда данные в колонке начинаются не с первой строки) — критичный провал: даже с явным предупреждением модели правильно отвечают только в 45% случаев. Модели воспринимают битую таблицу как грязные данные (удалить пустые ячейки), а не как структурную проблему (восстановить выравнивание).
Два типа искажений изучали исследователи: (1) Семантические — логически неверные данные (столбцы "систолическое" и "диастолическое давление" поменяны местами, но структура цела); (2) Структурные — геометрия сломана (столбец сдвинут на 3 строки вниз, данные не совпадают с заголовками). Второй тип — катастрофичен для LLM.
Схема проблемы
КАНОНИЧНА ТАБЛИЦА:
| Состояние | Систолическое | Диастолическое |
| Гипертония | 136 | 86 |
| Боль в спине | 145 | 82 |
СЕМАНТИЧЕСКОЕ ИСКАЖЕНИЕ (столбцы перепутаны):
| Состояние | Диастолическое | Систолическое | ← названия не соответствуют данным
| Гипертония | 136 | 86 |
| Боль в спине | 145 | 82 |
СТРУКТУРНОЕ ИСКАЖЕНИЕ (вертикальный сдвиг):
| Состояние | Col2 | Диастолическое |
| Гипертония | Систолическое | 86 | ← заголовок попал в данные
| Боль в спине | 136 | 82 | ← данные сдвинуты
| ... | 145 | ... |
Запрос: "Какое медианное систолическое давление по группам пациентов?"
БЕЗ ЯВНОЙ ИНСТРУКЦИИ:
→ Модель берёт данные "как есть" → неверный ответ
С ИНСТРУКЦИЕЙ "проверь таблицу":
→ Модель частично исправляет → но не всегда
Пример применения
⚠️ Сильная зона: Работа с реальными таблицами из внешних источников (экспорт, парсинг, конвертация форматов), где высок риск структурных сбоев.
Задача: Ты выгрузил отчёт по продажам из CRM в Excel, открыл в Google Sheets, скопировал и вставил в чат для анализа. При копировании съехали столбцы — в колонке "Выручка, ₽" оказались даты, а суммы сдвинулись. Визуально это заметно, но если просто попросить "посчитай медианную выручку по менеджерам", модель возьмёт те данные что видит.
Промпт:
ПЕРЕД анализом проверь таблицу на структурные и семантические ошибки:
1. Соответствуют ли данные в столбцах их заголовкам?
2. Есть ли сдвиги строк/столбцов (пустые ячейки не на своих местах)?
3. Логичны ли значения (например, возраст не может быть 120/80)?
Если найдёшь ошибки — опиши и исправь структуру ПЕРЕД расчётами.
Затем посчитай медианную выручку по менеджерам за март.
[вставить таблицу]
Результат:
Модель сначала опишет найденные проблемы: "Столбец 'Выручка, ₽' содержит даты формата DD.MM, а числовые значения находятся в столбце 'Дата сделки'". Затем предложит исправленную структуру (либо словами, либо кодом для переименования/перестановки столбцов). После этого — корректный расчёт медианы.
Внимание: Даже с этим промптом модель может пропустить вертикальные сдвиги (когда данные в столбце начинаются не с первой строки). В таких случаях лучше попросить: "Выведи первые 10 строк таблицы как ты её поняла" — и проверить визуально.
Почему это работает (частично)
Слабость LLM: Модели обучены быстро сканировать таблицы — смотреть на заголовки и несколько первых строк, извлекая семантику. Это эффективно для правильных таблиц, но создаёт слепую зону для глобальной структуры. Если столбец сдвинут вертикально на 5 строк вниз, модель не "читает всю таблицу целиком", чтобы это заметить. Она видит заголовок, видит первые данные, строит гипотезу "всё ОК" — и работает с ошибкой.
Сильная сторона LLM: Модели отлично проверяют логические инварианты, если их попросить. "Систолическое давление всегда выше диастолического" — такое правило модель знает (world knowledge). "Выручка измеряется в рублях, а не в днях" — тоже понятно. Но без явного запроса модель не включает режим критической проверки, она доверяет входным данным.
Как метод использует это: Явная инструкция "проверь таблицу на ошибки" переключает режим с "обработай данные" на "сначала валидируй, потом обрабатывай". Модель начинает сопоставлять заголовки с содержимым, искать аномалии (пустые ячейки не в конце, числа вместо текста). Но это не абсолютное решение — вертикальные сдвиги всё равно часто пропускаются, потому что требуют анализа всей структуры, а не точечной проверки.
Рычаги управления:
- Уровень детализации проверки: Можешь попросить "опиши структуру таблицы (сколько столбцов, какие типы данных, есть ли пустые ячейки)" ПЕРЕД анализом — это заставит модель "прочитать целиком".
- Специфичные правила: Если знаешь домен данных, добавь: "Столбец 'Возраст' должен быть 18-100, 'Вес' в кг (50-150)" — модель будет проверять на соответствие.
- Запрос промежуточного вывода: "Покажи как ты поняла таблицу (первые 5 строк)" перед расчётами — ты увидишь ошибку раньше, чем модель даст неверный результат.
Шаблон промпта
Перед анализом таблицы выполни проверку на искажения:
1. СТРУКТУРНАЯ ПРОВЕРКА:
- Все ли данные выровнены под своими заголовками?
- Есть ли смещённые строки/столбцы (данные начинаются не с первой строки)?
- Присутствуют ли заголовки внутри данных или данные в заголовках?
2. СЕМАНТИЧЕСКАЯ ПРОВЕРКА:
- Соответствуют ли типы данных в столбцах их названиям?
- Логичны ли значения? (например: {примеры логических правил для твоих данных})
- Нет ли перепутанных столбцов? (например: {известные инварианты в твоём домене})
Если найдёшь проблемы:
- Опиши каждую найденную ошибку
- Предложи исправленную структуру
- Спроси подтверждение перед продолжением
Затем выполни задачу: {твоя задача по анализу таблицы}
[вставить таблицу]
Плейсхолдеры:
- {примеры логических правил для твоих данных} — "возраст 18-100, цена >0, дата не в будущем"
- {известные инварианты в твоём домене} — "систолическое > диастолического, выручка >= себестоимость"
- {твоя задача по анализу таблицы} — "посчитай среднюю выручку по менеджерам"
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки таблиц перед анализом. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы про специфику данных (какие столбцы, какие логические правила, что должно быть проверено).
[вставить шаблон выше]
LLM спросит про твой домен данных (финансы, медицина, продажи?) и какие правила валидации применимы — потому что для корректной проверки нужно знать "что нормально, а что — ошибка" в твоих данных. Она возьмёт паттерн проверки из шаблона и заполнит специфичными правилами для твоей таблицы.
Ограничения
⚠️ Вертикальные сдвиги — провал даже с инструкцией: Если столбец данных начинается не с первой строки (например, заголовок "попал" в ячейку данных, а сами данные сдвинуты вниз), модель исправляет это только в 45% случаев, даже когда явно предупреждена. LLM не "читают таблицу целиком построчно" — они сканируют паттерны, и глобальные структурные аномалии часто остаются незамеченными.
⚠️ Модель удаляет, а не восстанавливает: При структурных ошибках LLM часто воспринимает битую таблицу как "грязные данные" и пытается удалить "лишние" столбцы или пустые ячейки, вместо того чтобы понять "это смещение, надо выровнять". Это может привести к потере важных данных.
⚠️ Не работает для сложных искажений: Исследование тестировало одношаговые искажения (один столбец сдвинут, два заголовка перепутаны). Реальные "битые" таблицы часто имеют наслоённые ошибки (и столбцы съехали, и заголовки дублируются, и часть ячеек слиты). В таких случаях даже distortion-aware промпт не гарантирует восстановления.
⚠️ Требует знания домена для семантических проверок: Чтобы модель поняла "систолическое и диастолическое давление перепутаны", нужно либо дать ей правило явно, либо надеяться на world knowledge. Для узкоспециальных данных (внутренние коды компании, отраслевая специфика) модель не сможет проверить семантику без твоих подсказок.
Ресурсы
An Empirical Investigation of Robustness in Large Language Models under Tabular Distortions
Датасет: github.com/AIML-Researcher/table-distortion
Avik Dutta, Harshit Nigam, Hosein Hasanbeig, Arjun Radhakrishna, Sumit Gulwani (Microsoft Corp.)