TL;DR
LLM читает таблицу как текст — слева направо, сверху вниз. Та же таблица с теми же данными, но в другом порядке строк или столбцов — и модель даёт другой ответ. Иногда неправильный. Это не баг конкретной модели — это системная слабость всех современных LLM без исключения.
Проблема в несоответствии: таблица по природе своей не зависит от порядка — переставь строки местами, данные не изменятся. Но LLM обрабатывает таблицу как последовательность токенов, где позиция влияет на интерпретацию. Модель видит не «данные», а «текст в определённом порядке» — и этот порядок тянет ответ в сторону.
Исследователи формализовали эту уязвимость и показали: даже случайное перемешивание строк и столбцов стабильно снижает точность ответов. Практический вывод: когда вставляешь таблицу в чат, порядок данных — это часть промпта. Хочешь надёжный ответ — думай о том, как расположить данные, а не только что написать в вопросе.
Схема метода
Это не техника с шагами — это находка о поведении LLM с практическими следствиями:
ПРОБЛЕМА: Таблица → LLM → ответ зависит от порядка строк/столбцов
↓
РИСК: Случайный/неудачный порядок → неверный или нестабильный ответ
↓
ЗАЩИТА: Сортировать таблицу до вставки в чат
→ ключевой столбец на первое место
→ релевантные строки выше
→ попросить LLM сначала переупорядочить данные
Один запрос. Никаких дополнительных инструментов — только осознанный выбор структуры таблицы.
Пример применения
Задача: Ты CFO стартапа. Просишь Claude проанализировать юнит-экономику по пяти каналам привлечения и назвать лучший по LTV/CAC. В таблице — каналы в случайном порядке: Контекст, Телеграм, SEO, Партнёрки, SMM.
Проблема: Если данные расположены случайно — LLM склонна называть тот канал, у которого выгодные цифры стоят выше в таблице. Это не анализ, это позиционный эффект.
Промпт с защитой:
Перед анализом: отсортируй таблицу по столбцу LTV/CAC от большего к меньшему.
Покажи отсортированную версию, затем назови лучший канал и объясни почему.
Таблица юнит-экономики каналов:
| Канал | CAC, ₽ | LTV, ₽ | LTV/CAC |
|-------------|--------|--------|---------|
| Контекст | 2 400 | 9 600 | 4.0 |
| Телеграм | 800 | 5 600 | 7.0 |
| SEO | 400 | 3 200 | 8.0 |
| Партнёрки | 1 200 | 7 200 | 6.0 |
| SMM | 600 | 1 800 | 3.0 |
Вопрос: какой канал наиболее эффективен для масштабирования?
Результат: Модель покажет таблицу с пересортировкой — SEO и Телеграм наверху, SMM и Контекст внизу — потом сделает вывод. Такой ответ надёжнее: данные упорядочены по смыслу вопроса, а не по случайному исходному порядку.
Почему это работает
LLM не «понимает» таблицу — она читает текст. Когда таблица вставляется в чат, она превращается в последовательность символов: заголовок, строка 1, строка 2... Модель обрабатывает этот поток слева направо. Первые строки получают больший «вес» при формировании ответа — как первые абзацы в тексте.
Таблица не имеет «правильного» порядка в реальном мире. Строки с продажами за январь и февраль — равнозначны независимо от того, в каком порядке идут. Но LLM этого не знает. Для неё «Февраль в строке 1» и «Февраль в строке 5» — разный контекст с разным влиянием на финальный ответ.
Сортировка по смыслу вопроса — это принудительный приоритет. Когда самые релевантные данные стоят первыми, модель «читает» ответ ещё до того, как добирается до деталей. Это не обман LLM — это устранение шума, который мешает правильному ответу пробиться.
Рычаги управления: - Порядок строк → ставь релевантные данные выше - Порядок столбцов → ключевой столбец (тот, по которому вопрос) — первым или вторым - Инструкция к сортировке → попроси LLM переупорядочить перед анализом — она сделает это и «зафиксирует» структуру в своём контексте - Размер таблицы → меньше строк = меньше шума. Если таблица большая, отфильтруй нерелевантные строки до вставки
Шаблон промпта
Перед ответом на вопрос: отсортируй таблицу по {ключевой_столбец}
{по убыванию / по возрастанию / по релевантности к вопросу}.
Покажи отсортированную таблицу, затем дай ответ.
{таблица}
Вопрос: {вопрос}
Что подставлять:
- {ключевой_столбец} — столбец, по которому будет ответ (LTV/CAC, дата, сумма, рейтинг)
- {по убыванию / по возрастанию} — направление сортировки под вопрос
- {таблица} — таблица в любом формате: Markdown, CSV, скопированный из Excel
- {вопрос} — твой вопрос к данным
Варианты применения
💡 Если не знаешь как сортировать: дай задачу LLM целиком
Посмотри на вопрос и на таблицу. Определи,
по какому столбцу лучше отсортировать данные,
чтобы ответить на вопрос точнее. Отсортируй, покажи — потом отвечай.
{таблица}
Вопрос: {вопрос}
💡 Если таблица большая: сначала фильтруй, потом спрашивай
Из таблицы ниже оставь только строки, которые
относятся к {критерий_фильтрации}.
Остальные удали. Отсортируй оставшееся по {столбец}.
Затем ответь: {вопрос}
{таблица}
🔧 Техника: попроси объяснить на каком основании сделан вывод
Добавь в любой промпт с таблицей:
После ответа укажи: какие конкретно строки таблицы повлияли на вывод
и почему именно они, а не другие.
Это заставляет модель «показать работу» — если она опирается на позицию строки, а не на значение, это станет видно.
Ограничения
⚠️ Не спасает от больших таблиц: Если таблица очень большая (десятки строк, много столбцов), сортировка помогает, но не решает проблему полностью — слишком много данных в контексте создают собственный шум.
⚠️ Субъективные вопросы сложнее: Этот эффект сильнее всего проявляется при точных вопросах («кто первый», «сколько всего», «какой максимум»). При вопросах типа «что посоветуешь» порядок строк тоже влияет, но предсказать как — сложнее.
⚠️ Сортировка сама требует правильного ключа: Если выбрал не тот столбец для сортировки — эффект может ухудшиться. Когда неочевидно как сортировать, лучше попросить LLM определить это самостоятельно (см. вариант «если не знаешь как сортировать»).
⚠️ Защита ATP атаки — не в наших руках: Исследователи нашли «наихудшие» перестановки через градиентный алгоритм (нужен доступ к весам модели). Против такой целенаправленной атаки сортировка не спасёт — но в обычной работе с чатом это не актуально.
Как исследовали
Команда из CMU и NEC Labs поставила простой вопрос: если взять одну и ту же таблицу и просто переставить строки и столбцы местами — изменится ли ответ модели? Данные не меняются, вопрос не меняется, меняется только расположение.
Тестировали на восьми разных моделях — от маленьких (7B параметров) до более крупных (14B), включая Llama, Qwen, DeepSeek и специализированные TableLLM. Проверяли на двух датасетах с вопросами по таблицам.
Результат оказался неприятным: случайное перемешивание строк уже снижало точность у всех моделей. Ни одна не устояла. Самые «умные» модели теряли меньше — но тоже теряли.
Потом исследователи пошли дальше: создали алгоритм ATP, который ищет наихудшую перестановку — ту, которая максимально ломает ответ конкретной модели. Результат был жёстким: у некоторых моделей точность падала в два-три раза по сравнению с нормальным вводом. Интересный момент — найденные «вредоносные» перестановки работали не только на той модели, для которой их нашли, но и на других. Уязвимость системная, не индивидуальная.
Ресурсы
The Power of Order: Fooling LLMs with Adversarial Table Permutations
Авторы: Xinshuai Dong, Haifeng Chen, Xuyuan Liu, Shengyu Chen, Haoyu Wang, Shaoan Xie, Kun Zhang, Zhengzhang Chen
Организации: Carnegie Mellon University (CMU), NEC Labs America, Dartmouth College
Датасеты в исследовании: WTQ (WikiTableQuestions), TATQA