TL;DR
Когда LLM просят очистить таблицу от опечаток и битых значений напрямую через промпт, модель чаще вспоминает знакомые факты из своей обучающей выборки, чем реально анализирует структуру таблицы. Протокол CoRe (Cleaning or Recalling) доказал это, заменив реальные названия больниц, фильмов и пивоварен на вымышленные слова и слоги при полном сохранении всех типов ошибок.
Главная находка исследования: на незнакомых сущностях (а именно так для LLM выглядят любые внутренние базы вашего бизнеса) качество прямой чистки таблиц через LLM обваливается в разы, а на знакомых — модель самовольно переписывает верные данные. Стоило заменить известные названия фильмов на вымышленные слова, как точность восстановления года выпуска из готового диапазона в соседней колонке (2014 2015 2016 → 2015) у DeepSeek-V4-Pro рухнула в пять раз — хотя сами цифры года вообще не менялись. И наоборот: если в вашей таблице у известного фильма или компании намеренно указан нестандартный ответственный, модели в большинстве случаев «исправляют» правильную ячейку на факт из Википедии.
Чтобы чистить корпоративные таблицы без потерь, авторы предлагают разделять ошибки на три класса восстанавливаемости (R1, R2, R3), переключать LLM с прямой правки ячеек на генерацию скриптов очистки (подход TabClean), подавать повторяющиеся записи одной сущности в одном блоке и жестко прописывать в промпте приоритет локальных свидетельств таблицы над внешними знаниями.
Схема метода
Порядок безопасной очистки табличных данных с помощью LLM по выводам исследования CoRe:
ШАГ 1 (Аудит колонок по классификации R1 / R2 / R3):
- R1 (Локально обратимые): сбой формата внутри ячейки ("Москва, МО", "5.5%") → просить LLM написать Python/Regex-скрипт (TabClean), НЕ править ячейки вручную через JSON
- R2 (Ограниченные контекстом): выбор из кандидатов ("2014 2015 2016") или опечатка в названии → группировать строки одной сущности в один батч + дать явно правило выбора
- R3 (Неопределённые без внешнего словаря): внутренние ID, пропущенные уникальные реквизиты → запретить LLM угадывать, чинить только через JOIN со справочником
ШАГ 2 (Защита от «галлюцинации по памяти» в промпте):
Явный запрет менять значения на основе внешних знаний о мире (Table-Evidence Instruction) + проверка на вымышленных названиях-суррогатах перед запуском на всей базе
Пример применения
Задача: Вы выгрузили из CRM и 1С таблицу на 2 000 строк по региональным контрагентам и брендам (там вперемешку идут гиганты вроде «ВкусВилл», «Додо Пицца» и локальные непубличные поставщики вроде «ООО СеверПромЛогистик»). В таблице три типичные беды:
1. В колонке Город_и_регион склеены значения (Краснодар КК, Екатеринбург СО);
2. В колонке Год_договора из-за сбоя парсера записана тройка соседних лет (2023 2024 2025, где верный — всегда средний);
3. В колонке Куратор_сделки у известных брендов указаны ваши внутренние менеджеры или региональные франчайзи, которых обычная LLM пытается «исправить» на реальных основателей компаний (Федора Овчинникова или Андрея Кривенко).
Промпт:
Ты — аналитик очистки корпоративных табличных данных по протоколу CoRe.
Перед тобой фрагмент внутренней выгрузки контрагентов.
1. ЗАПРЕТ НА ВНЕШНИЕ ЗНАНИЯ (Anti-Recall Guard):
Опирайся ИСКЛЮЧИТЕЛЬНО на свидетельства и паттерны внутри самой таблицы.
Категорически запрещено исправлять ФИО, города, директоров или реквизиты известных компаний на основе твоих знаний о реальном мире. Если значение не нарушает внутреннюю согласованность строк таблицы — оставь его нетронутым.
2. РАЗДЕЛЕНИЕ ПО ТИПАМ ОШИБОК (R1 / R2 / R3):
- Тип R1 (Форматные сбои: склеенный город/регион, лишние суффиксы в процентах): извлеки точное правило преобразования и исправь по шаблону.
- Тип R2 (Ограниченные кандидаты в ячейке или опечатки при наличии дублей той же компании в блоке):
* Для диапазонов вида "ГГГГ-1 ГГГГ ГГГГ+1" в колонке Год_договора всегда выбирай центральное значение, независимо от того, знакома тебе компания или нет.
* Для опечаток вида "x" в названии сверяйся с другими строками того же ИНН/контрагента в текущем блоке.
- Тип R3 (Неопределённые данные: внутренние ID, коды договоров, пустые уникальные ячейки без дублей): НЕ пытайся угадать или сгенерировать значение. Пометь как NEEDS_EXTERNAL_LOOKUP.
Входная таблица (20 строк, сгруппированных по ИНН контрагентов):
| row_id | ИНН | Контрагент | Куратор_сделки | Город_и_регион | Год_договора | Ставка_НДС | Код_1С |
|---|---|---|---|---|---|---|---|
| 1 | 7701234567 | ВкусВилл | Сорокин И.В. | Москва МСК | 2023 2024 2025 | 20.0% | <пусто> |
| 2 | 2310987654 | ООО АгроЮгxнаб | Петрова Е.А. | Краснодар КК | 2022 2023 2024 | 10% | АЮ-991 |
| 3 | 2310987654 | ООО АгроЮгСнаб | Петрова Е.А. | Краснодар | 2023 | 10.0% | АЮ-991 |
Верни:
1. JSON-список исправлений `{row_id, column, old_value, new_value, error_class: "R1"|"R2"}` только для доказанных ошибок R1 и R2.
2. Отдельный список ячеек класса R3 (`NEEDS_EXTERNAL_LOOKUP`), которые нельзя восстановить без внешнего справочника.
Результат:
Модель не тронет Сорокин И.В. в строке «ВкусВилл» (не подменит его на основателя компании из памяти), вытащит 2024 и 2023 по явному правилу среднего года даже для неизвестного ей «ООО АгроЮгСнаб» (класс R2), восстановит опечатку АгроЮгxнаб → АгроЮгСнаб по соседней строке с тем же ИНН (R2), разделит Москва МСК и Краснодар КК (R1), а пустой Код_1С в первой строке честно отправит в NEEDS_EXTERNAL_LOOKUP (R3) вместо выдумывания фейкового кода.
Почему это работает
У языковых моделей при работе с таблицами есть две фундаментальные ловушки. Первая — зависимость от узнавания сущности: когда модель видит знакомое название («American Ultra», «Больница Каллахана»), в её весах активируются связанные знания, и она попутно аккуратно чинит даже соседние числовые колонки. Но как только на месте названия оказывается незнакомое слово или внутренний артикул компании, модель «теряется» и перестаёт применять даже элементарную логику к соседним ячейкам, где ответ лежит прямо перед глазами.
Вторая ловушка — конфликт параметрической памяти с контекстом таблицы. Если в таблице у известного объекта записано неканоническое значение (например, в учебном или рабочем датасете фильму «Заложница» назначен режиссёр Стэнли Кубрик вместо Пьера Мореля), обычный промпт «найди и исправь ошибки в таблице» заставляет коммерческие модели в 68–100% случаев стереть правильное табличное значение и вписать факт из интернета.
Разделение задач по типам восстанавливаемости (R1 / R2 / R3) и переход от поштучной правки ячеек к генерации программного кода очистки (TabClean) обходят обе ловушки:
- Для форматных ошибок (R1) и внутритабличных зависимостей (R2) сгенерированный LLM Python-скрипт одинаково надёжно чистит и известные бренды, и бессмысленные наборы слогов, потому что код опирается на регулярные выражения и группировку строк, а не на энциклопедическую память модели.
- Явная инструкция опираться только на свидетельства таблицы (Table-Evidence Instruction) снижает долю ложных перезаписей известных сущностей у коммерческих моделей с 68–100% до 0–40,4% (а у части флагманов — до полного нуля).
Рычаги управления:
- Группировка батчей по сущностям: если подавать таблицу случайными кусками по 20 разных компаний (как в базовом тесте авторов), модель не видит дублей. Если перед отправкой в LLM отсортировать таблицу по ИНН/ID клиента, ошибки класса R3 (неизвестное название с опечаткой) превращаются в решаемый класс R2.
- Генерация кода вместо JSON-правок: на больших таблицах просите LLM написать функцию очистки (pandas / re), а не возвращать исправленные ячейки текстом — в тестах авторов генератор программ TabClean почти не терял точность при полной замене всех названий на вымышленные.
- Проверка промпта на словах-суррогатах: прежде чем доверять LLM чистку боевой базы, замените в 20 тестовых строках реальные названия компаний на случайные словосочетания (Лесной Ручей, Медный Холм). Если точность промпта упала — значит, ваш промпт работал на эрудиции модели, а не на логике правил.
Шаблон промпта
Шаблон комбинирует проверенную в исследовании инструкцию опоры на свидетельства таблицы (Table-Evidence Instruction) и таксономию восстанавливаемости (R1 / R2 / R3) из протокола CoRe:
Таблица: {описание_таблицы}
Целевой стандарт оформления (Target Convention):
{правила_формата_колонок}
КРИТИЧЕСКОЕ ПРАВИЛО: Используй ТОЛЬКО свидетельства внутри переданной таблицы и правила из .
1. Не используй внешние энциклопедические знания о реальных компаниях, людях, фильмах или городах.
2. Если ячейка содержит известную тебе сущность, но её атрибуты в таблице отличаются от реального мира и НЕ противоречат другим строкам этой же таблицы — ЗАПРЕЩЕНО менять это значение.
3. Относись ко всем названиям как к незнакомым внутренним идентификаторам.
Для каждой подозрительной ячейки сначала определи класс восстанавливаемости:
- [R1: Locally Reversible] — ошибка формата внутри самой ячейки ({примеры_R1}). Восстанови по правилу формата.
- [R2: Constrained] — в ячейке есть список кандидатов ИЛИ в блоке есть другие строки той же сущности, позволяющие однозначно выбрать значение ({примеры_R2}). Восстанови с указанием строки-источника или правила.
- [R3: Underdetermined] — пропущенный уникальный код, внешний ID или опечатка без проверочной строки в таблице. НЕ УГАДЫВАЙ значение, верни статус UNRECOVERABLE_R3.
Выведи ответ в двух блоках:
1. Python-функцию (`pandas`), которая автоматически чинит все регулярные ошибки классов R1 и R2 во всей таблице.
2. JSON-отчёт по текущему фрагменту: список правок `[{"row": int, "col": str, "class": "R1"|"R2", "value": str}]` и список ячеек `UNRECOVERABLE_R3`.
Данные таблицы:
{фрагмент_таблицы}
Что подставлять в плейсхолдеры:
- {описание_таблицы} — что означает строка таблицы и какие колонки являются ключевыми (идентификационными).
- {правила_формата_колонок} — целевой стандарт (например: «телефон 10 цифр без дефисов, год — одно четырёхзначное число, процент — дробь без знака %»).
- {примеры_R1} и {примеры_R2} — 1–2 характерных примера форматных сбоев и внутритабличных подсказок для вашей базы.
- {фрагмент_таблицы} — сгруппированные по ключу сущности строки таблицы в CSV или Markdown.
🚀 Быстрый старт — вставь в чат:
Вот шаблон DataCleaningProtocol_CoRe. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие колонки есть в вашей таблице, какие значения должны подчиняться жёсткому формату (R1), а какие связываются между строками (R2) — потому что без явного описания целевого формата модель не знает, какую из двух конфликтующих конвенций считать эталоном. Она возьмёт паттерн из шаблона и адаптирует под задачу.
Ограничения
⚠️ Даже прямой запрет в промпте не всегда останавливает перезапись известных фактов: В эксперименте авторов явная инструкция опираться только на данные таблицы снизила ложную замену режиссёров известных фильмов с 68–100% до 0,0–40,4% у коммерческих флагманов, но у некоторых открытых моделей (например, Qwen2.5-14B) доля ложных перезаписей даже с жёстким запретом осталась выше 60%.
⚠️ Неопределённые ошибки (R3) невозможно починить промптом на приватных данных: Если в таблице потерян внешний идентификатор или уникальное имя, которого нет в других строках, никакая техника промптинга не восстановит его без подключения внешнего справочника.
⚠️ Эталонные датасеты и проверочные выборки сами часто содержат «мусор Excel»: Авторы обнаружили, что в популярном бенчмарке Rayyan 94% засчитанных исправлений (434 из 461 у TabClean) на самом деле угадывали ошибку автозамены Excel в эталоне (где ISSN журнала вида
0003-3022или том/выпуск превратились в датуMar-22→22-Mar), тогда как реальный правильный ISSN из базы PubMed получал 0 баллов.
Как исследовали
Команда из Центрального университета национальностей (Minzu University of China) и Народного университета Китая (Renmin University of China) решила проверить, действительно ли LLM умеют чистить таблицы, или их высокие баллы на публичных бенчмарках объясняются тем, что модели просто знают наизусть американские больницы, голливудские фильмы и крафтовые пивоварни. Они построили 21 контролируемую таблицу (по 1 000 строк в каждой, около 41 000 вымышленных значений, прошедших 506 автоматических проверок качества) на базе классических датасетов Hospital, Movies и Beers, а также проверили Rayyan, Flights и Tax. Для каждого датасета создали 4 версии:
1. O (Original) — оригинальный публичный бенчмарк;
2. F (Fresh) — свежие реальные записи за июль–сентябрь 2026 года из реестров CMS, IMDb и Wikidata;
3. W (Word-based surrogate) — те же строки и те же позиции ошибок, что в оригинале, но все названия и имена один-к-одному заменены на вымышленные английские словосочетания (Timber Hollow Regional Hospital, фильм Mill Brook);
4. S (Syllable-based surrogate) — названия заменены на бессмысленные комбинации из 24 слогов (Vasrhokel Regional Hospital, город Hepmormor).
Через эти таблицы прогнали 23 000 промптов на 8 языковых моделях — четырёх коммерческих флагманах (DeepSeek-V4-Pro, Qwen3.8-Max, GLM-5.3, GPT-6.1-Sol) и четырёх открытых (семейство Qwen2.5 Instruct от 7B до 72B), а также сравнили их с классическим ML-клинером Baran и генератором программ очистки TabClean.
Результаты разрушили сразу несколько мифов:
- Это не зазубривание таблицы, а опора на известные названия: Специальный тест на продолжение строк (continuation probe) доказал, что модели не помнят сами строки бенчмарков наизусть, а на свежих реальных записях 2026 года (F) работают не хуже, чем на старых (O). Но как только реальные имена заменили на вымышленные слова (W) и слоги (S), F1-мера чистки идентификационных колонок на Hospital у коммерческих моделей рухнула на 0,59–0,72 пункта (на 59–72 п.п.).
- Потеря названия парализует логику даже в соседних числовых колонках: В датасете Movies ошибка в колонке year выглядит как тройка лет 2014 2015 2016 (где правильный ответ почти всегда — просто взять средний год, это правило срабатывает в 167 из 190 случаев). На реальных фильмах DeepSeek-V4-Pro восстанавливал год с точностью 91% (173 из 190). Когда названия фильмов заменили на вымышленные слова (W), оставив колонку с годами абсолютно без изменений, точность DeepSeek-V4-Pro рухнула с 91% до 18% (35 из 190), а на слогах (S) — до 13% (25 из 190)!
- Генерация кода (TabClean) и учёт дублей (Baran) не боятся незнакомых имён: В отличие от прямой правки ячеек через промпт, система TabClean (где LLM пишет программу для очистки всей таблицы целиком) и контекстный алгоритм Baran сохранили высокую точность и на вымышленных словах, и на слогах везде, где в таблице есть повторяющиеся строки или форматные закономерности (датасеты Hospital и Beers).
Адаптации и экстраполяции
1. Адаптация техники:
🔧 Техника: Обязательная обфускация ключевых имён (W-тест) при отладке ETL-промпта → защита от ложного чувства качества на тесте
Когда аналитик настраивает промпт для разбора или чистки таблиц на 10–20 примерах с известными брендами («Сбер», «Яндекс», «Магнит»), модель показывает 95% точности за счёт фоновых знаний, а на тысяче мелких региональных ООО в продакшене ломается. Перед выкаткой промпта в пайплайн замените в тестовой выборке все названия компаний и городов на вымышленные слова и проверьте, не упала ли точность извлечения соседних полей.
2. Экстраполяция:
Маскирование известных брендов токенами
ENTITY_001перед подачей в LLM (Preventive De-identification): Если в вашей базе (например, в таблице тендеров или кадровых назначений) у реальных крупных компаний намеренно записаны нестандартные или внутренние значения, которые LLM пытается «починить» по памяти (даже вопреки запрету в промпте — как те самые до 40% перезаписей у коммерческих моделей и >60% у Qwen2.5-14B), перед отправкой таблицы в LLM автоматически замените словарь известных брендов на нейтральные плейсхолдерыCOMPANY_001,COMPANY_002, а после очистки верните имена обратно по словарю. Это на 100% физически исключает конфликт с параметрической памятью модели.
Ресурсы
- Работа: Cleaning or Recalling? Knowledge Dependence in LLM-based Data Cleaning [Experiment, Analysis & Benchmark] (arXiv:2611.08106, PVLDB Vol. 20, No. 1)
- Репозиторий и данные: https://github.com/hinsonver/CoRe-Benchmark
- Авторы: Jingru Yang, Honglu Zhang, Jiayi Mi, Ju Fan, Zheng Chen, Xiaoyong Du
- Университеты: Minzu University of China, Renmin University of China