TL;DR
Когда вы вставляете таблицу в ChatGPT или Claude и задаёте вопрос — модель не обязательно читает ваши данные. Для простых запросов ("что стоит в этой ячейке?") модель смотрит в таблицу. Но для сложных вопросов, требующих нескольких шагов, — модель переключается на то, что знает из обучения, и игнорирует ваши данные.
Это критично когда вы работаете с нестандартными, приватными или гипотетическими данными — своими прайсами, кастомными таблицами, финансовыми расчётами. Модель молча заменяет ваши цифры теми, которые считает "правдивыми" из своих знаний. Ответ звучит уверенно и выглядит правдоподобно — но отражает не вашу таблицу, а усреднённые знания из интернета.
Чем сложнее вопрос — тем сильнее этот эффект. Простая выборка ("какая цена у товара X?") — модели следуют вашим данным надёжно. Добавляешь условие + сравнение + временной фактор — модель начинает подставлять знакомые факты вместо ваших. Исследование назвало это counterfactual gap — разрыв между точностью на реальных и искусственно изменённых данных. Чем больше разрыв, тем сильнее модель опирается на память.
Схема эффекта
УРОВЕНЬ 1: Простая выборка
"Какой город указан для страны X?"
→ Надёжно: модель читает ячейку, почти не заменяет данными из памяти
УРОВЕНЬ 2: Соединение таблиц (несколько шагов)
"В какой стране находится клуб игрока Y?"
→ Умеренно: начинаются подмены, особенно у слабых моделей
УРОВЕНЬ 3: Многошаговое рассуждение + сравнение + время
"Был ли клуб игрока Z на момент перехода в той же конфедерации, что страна его гражданства?"
→ Ненадёжно: сильные модели теряют до 18–19%, слабые — до 30–40% точности
на данных, противоречащих тому, что "знает" модель
Все шаги выполняются в рамках одного вопроса — это разные типы запросов, а не разные промпты.
Пример применения
Задача: Вы — владелец небольшого дистрибьютора, и вставили в Claude таблицу с нестандартными ценами на товары (со скидками для конкретных клиентов, которые отличаются от рыночных). Спрашиваете: "Какой клиент получил наибольшую скидку по итогам Q1 среди тех, кто совершил более трёх заказов?"
Промпт без защиты — так делают большинство:
Вот таблица заказов. Скажи, кто получил наибольшую скидку среди
клиентов с более чем тремя заказами в Q1.
[таблица]
Что происходит: Модель начинает рассуждать, сравнивать, агрегировать — и на одном из шагов подставляет "типичные" рыночные цены или усредняет данные, которые кажутся ей "странными". Вы получаете неверный ответ, поданный уверенно.
Промпт с явным якорем:
Работай ИСКЛЮЧИТЕЛЬНО с данными из таблицы ниже.
Не используй никакие внешние знания о ценах, компаниях или рынке.
Если данных недостаточно для ответа — скажи об этом напрямую,
не додумывай и не заполняй пробелы из своих знаний.
Вопрос: Кто из клиентов получил наибольшую скидку среди тех,
кто совершил более трёх заказов в Q1?
[таблица]
После ответа — укажи конкретные строки таблицы, которые подтверждают вывод.
Результат: Модель выдаст ответ со ссылками на конкретные строки таблицы. Блок "укажи конкретные строки" — это встроенная проверка: если она называет строки, которых нет или которые не подтверждают вывод, это сигнал, что модель додумала.
Почему это работает (и почему без якоря не работает)
LLM — это не база данных, а генератор правдоподобного текста. У неё нет команды "SELECT * FROM table". Она видит таблицу как текст и генерирует ответ, который кажется ей наиболее правдоподобным. Если задача простая — правдоподобнее всего взять значение из таблицы. Если задача сложная — правдоподобнее всего опереться на то, что уже хорошо знает.
Чем длиннее цепочка рассуждений — тем больше "точек выбора". На каждом шаге модель может либо держаться данных, либо соскользнуть в память. При одном шаге это происходит редко. При четырёх-пяти шагах — почти неизбежно, особенно когда ваши данные противоречат тому, что модель считает "нормальным".
Явная инструкция "используй только таблицу" — это не магия, а перекалибровка приоритетов. Модель не перестаёт знать то, что знает. Но инструкция повышает вес строгого следования контексту в генерации ответа. Запрос "укажи строки" добавляет верифицируемость — это встроенный аудит, который заставляет модель "привязаться" к конкретным ячейкам.
Рычаги управления: - Явный запрет внешних знаний → снижает подмену данными из памяти - Требование цитировать строки → делает ошибку видимой - Запрос "если данных нет — скажи" → предотвращает галлюцинации-заполнители - Разбивка на шаги ("сначала выбери клиентов с >3 заказами, потом сравни скидки") → уменьшает количество "точек соскальзывания"
Шаблон промпта
Работай ИСКЛЮЧИТЕЛЬНО с данными из {описание таблицы/данных} ниже.
Не используй внешние знания о {домен: ценах / компаниях / событиях / людях}.
Если для ответа не хватает данных — скажи об этом прямо, не додумывай.
Вопрос: {вопрос}
{таблица или данные}
После ответа — укажи конкретные {строки / записи / ячейки},
на которых основан вывод.
Плейсхолдеры:
- {описание} — "таблицы заказов", "выгрузки из CRM", "прайса поставщика"
- {домен} — чем конкретнее (не просто "теме", а "рыночных ценах на металл") — тем точнее блокировка
- {вопрос} — ваш вопрос, особенно если он многошаговый
- {строки/записи/ячейки} — адаптируй под тип данных
🚀 Быстрый старт — вставь в чат:
Вот шаблон для работы с данными, который защищает от подмены данных
памятью модели. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какие данные вы используете и в каком домене — потому что это нужно для точной формулировки запрета на внешние знания.
Ограничения
⚠️ Якорь не даёт 100% гарантии: Явная инструкция значительно снижает подмену, но не устраняет её полностью — особенно у слабых моделей и при очень сложных многошаговых запросах.
⚠️ Слабые модели теряют точность в принципе: Если модель плохо справляется с задачей "честно", якорь не поможет — у неё просто не хватает мощности на рассуждение по таблице.
⚠️ Сложные агрегации и временны́е цепочки — зона риска: Даже с якорем, вопросы типа "найди N-й по величине показатель среди объектов, которые выполнили условие X в период Y" остаются ненадёжными. Для критичных расчётов — проверяй вручную или разбивай на отдельные подзапросы.
⚠️ Работает на знакомых данных: Исследование использовало футбольные данные — область, которую модели хорошо знают. Для полностью уникальных данных (приватная база клиентов, внутренние метрики) эффект памяти меньше, но не нулевой.
Как исследовали
Исследователи из Purdue придумали элегантный тест: взяли реальную базу данных о футбольных трансферах (игроки, клубы, страны, соревнования) и создали её зеркальную версию — с теми же связями и структурой, но с намеренно изменёнными фактами. Столицы стран поменялись местами, игроки оказались гражданами других стран, клубы переехали в другие конфедерации. Структура та же — "правда" внутри другая.
Потом задали одинаковые вопросы к обеим базам: к реальной и к "перевёрнутой". Логика железная: если модель читает таблицу — она даст правильный ответ на обе версии. Если модель опирается на память — на реальной угадает, а на изменённой ошибётся. Разрыв в точности и есть мера "подмены".
Протестировали 10 моделей — от GPT-5.4-Mini и Gemini до маленьких open-source Llama и Qwen. Самый сильный результат у Gemini-3.1-Flash-Lite: на сложных вопросах разрыв всего ~5 процентных пунктов. GPT-5.4-Mini — уже ~19 пунктов на сложном уровне. Слабые модели теряли 30-40 пунктов. Любопытная деталь: при простых однотабличных вопросах сильные модели справлялись одинаково хорошо на обеих базах — память не мешала, потому что задача не требовала рассуждения.
Адаптации и экстраполяции
Адаптация 1: Гипотетические сценарии ("что если")
Тот же принцип работает для любого анализа "что если" — когда вы намеренно задаёте нереалистичные условия.
💡 Адаптация для сценарного анализа: Если вы говорите модели "представь, что цена нефти — 200 долларов" и задаёте сложный вопрос с зависимостями — модель может проигнорировать вашу цифру и вернуться к "реальной" ~80 долларов.
В рамках этого анализа используй ТОЛЬКО следующие вводные данные
и не корректируй их под свои знания о реальных показателях:
Цена нефти: {200} $/барр.
Курс доллара: {120} ₽
Маржа производителя: {15%}
Вопрос: {вопрос о финансовой модели}
Все расчёты на основе этих цифр. Укажи формулу для каждого шага.
Адаптация 2: Пошаговая декомпозиция для сложных запросов
Если вопрос многошаговый — разбей на под-запросы вместо одного большого. Это снижает количество точек, где модель может соскользнуть в память.
🔧 Техника: один сложный вопрос → цепочка простых
Вместо:
Какой менеджер принёс наибольшую выручку среди тех, кто пришёл
после марта 2023, если считать только сделки с клиентами категории B?
Делай:
Шаг 1: Из таблицы менеджеров выбери только тех, кто принят после 01.03.2023.
Покажи список с датами.
[после ответа]
Шаг 2: Из таблицы сделок отфильтруй только клиентов категории B.
Покажи список с суммами.
[после ответа]
Шаг 3: Сопоставь два списка и найди менеджера с наибольшей суммой.
Ссылайся на конкретные строки из шагов 1 и 2.
Каждый шаг — простая выборка. Простые выборки модели выполняют по таблице надёжно.
Ресурсы
Работа: "The Table Says Otherwise: Testing LLMs with Counterfactual Relational Data" — VLDB 2026 Workshop: NOVAS
Авторы: Xinzhi Wang, Chunwei Liu — Purdue University
Датасет и код: github.com/AuroraWXZ/LLM_understand_table
Связанные работы из исследования: - DisentQA — похожий подход для текстовых контекстов (Neeman et al., 2023) - CounterFact — контрфактические факты для оценки редактирования знаний в LLM (Meng et al., 2022)