TL;DR
TEN — метод извлечения таблиц из неструктурированного текста через три компонента: Structural Decomposition prompting (специализированный Chain-of-Thought), символьная проверка структуры и LLM-критик. Суть в том, что модель сначала находит границы таблиц в тексте, затем определяет разделители строк и колонок, и только потом генерирует структуру. После этого символьный чекер проверяет результат на типичные ошибки (слитые ячейки, несовпадение типов, несбалансированные скобки), а LLM-критик переводит технические ошибки в понятные инструкции для исправления.
Модели теряются при извлечении таблиц из копипасты или OCR-текста без разметки. Проблема в том, что LLM пытается восстановить структуру за один проход, не имея чёткого плана. Результат — два запуска на одном тексте дают разные таблицы: то 7 колонок, то 5, то данные слиты, то разделены. Модель галлюцинирует значения (21% hallucination rate), теряет данные (coverage падает до 90%), путает заголовки с данными. Типичные косяки: слитые ячейки ("Section 143, Row 2" вместо отдельных колонок), неправильные разделители (число "12,345" разваливается на "12" и "345"), несбалансированные скобки (обрезанный текст).
TEN решает это через явное разделение на этапы: сначала модель ищет где в тексте таблицы и определяет их границы (игнорируя шум), затем выбирает разделители для строк и колонок, и только после этого генерирует JSON-структуру. Если символьный чекер находит ошибки — LLM-критик анализирует фидбек и даёт конкретные инструкции: "Разделите ячейку X на две колонки", "Объедините строки Y-Z под один заголовок". Цикл продолжается до схождения или 5 итераций. Прирост точности: +10-40 пунктов Exact Match vs обычный CoT.
Схема метода
ШАГ 1: Structural Decomposition (один промпт, но с явными подзадачами)
1a. Найди границы таблиц в тексте
1b. Определи разделители строк и колонок
1c. Сгенерируй структуру таблицы в JSON
ШАГ 2: Symbolic Sanity Checker (проверка)
→ Goodness/badness score, список нарушений
ШАГ 3: Critique LLM (если есть ошибки)
→ Анализ фидбека → конкретные инструкции по исправлению
ШАГ 4: Регенерация с учётом критики
→ Повтор шагов 1-3 до схождения (макс 5 итераций)Итеративный процесс: один вызов модели даёт первую версию, затем цикл проверка-критика-исправление до готовности.
Пример применения
Задача: Ты получил по email текст с ценами на билеты на матч. Копипаста развалила структуру — всё смешалось в кучу. Нужно восстановить читаемую таблицу для сравнения вариантов.
Промпт:
У меня есть текст с информацией о билетах, но структура потерялась при копировании.
Сделай это в три этапа:
1. **Найди границы**: Определи где начинается и заканчивается каждый вариант билета
2. **Определи разделители**: Какие паттерны разделяют поля (секция, ряд, цена, площадка)
3. **Построй таблицу**: Создай структурированную таблицу в JSON
Вот текст:
Friday Night
Dugout Box (Behind card's dugout)
Section 143, Row 2, Seat 5-8, $149ea, mlb/hub
https://www.ticketmaster.com
Redbird Club (good views, dedicated bathrooms & concessions)
Section 249, Row 1, Seat 1-10 (aisle) - $58ea, mlb/hub
https://www.ticketmaster.com
Mariners Dugout
Section 150 (should look straight in), Row 1, Seat 5-8 (aisle) - $150ea, mlb
Cardinals Club
Section 7, Row 1, Seat 1-4 (aisle) - $189ea, stubhub
https://www.ticketmaster.com
После того как создашь таблицу, проверь:
- Все ли данные из текста попали в таблицу?
- Нет ли слитых ячеек (например, "Section 143, Row 2" должно быть в разных колонках)?
- Все ли скобки и кавычки парные?
- Числа не разваливаются на части из-за запятых?
Если найдёшь проблемы — исправь и покажи финальную версию.Результат:
Модель покажет три фазы работы:
- Сегментация: "Вижу 4 варианта билетов, границы: строки с Day, далее описание площадки, далее детали..."
- Определение структуры: "Разделители: название площадки (заголовок), Section/Row/Seat через запятые, цена через $, ссылка отдельно"
- JSON-таблица с колонками: Venue, Section, Row, Seats, Price, Platform, URL
Затем модель проверит себя: "Нашла слитую ячейку 'Section 143, Row 2' — разделяю на Section: 143, Row: 2". Выдаст чистую финальную таблицу где каждое поле на своём месте.
Почему это работает
Слабость LLM: Модели плохо восстанавливают структуру "в лоб" из-за отсутствия чёткого плана. Без явных инструкций модель одновременно решает: где границы таблиц, какие разделители, как выровнять колонки, куда положить каждое значение. Когнитивная перегрузка → непредсказуемый результат. Два запуска на одном тексте дают разные таблицы (см. Figure 1 в статье).
Сильная сторона LLM: Модели отлично работают пошагово и умеют следовать структурированным инструкциям. Если задача разбита на подзадачи с чёткими критериями проверки — точность резко растёт. Особенно эффективны псевдокод-подобные структуры и явные условия выхода.
Как TEN использует сильную сторону: Метод разбивает восстановление таблицы на три последовательных этапа — поиск границ, выбор разделителей, генерация структуры. Каждый этап имеет чёткий output, который становится input для следующего. Символьный чекер работает как внешний валидатор (не подвержен галлюцинациям LLM), а LLM-критик переводит технический фидбек ("badness score 0.3, merged cells detected") в понятные инструкции ("Разделите ячейку X на колонки Y и Z"). Итеративность даёт модели возможность исправить ошибки, которые она не заметила в первый проход.
Рычаги управления:
- Глубина декомпозиции — можно добавить подэтапы (например, "определи типы данных в колонках" перед генерацией)
- Строгость проверки — список правил символьного чекера (больше правил = меньше ошибок, но медленнее)
- Число итераций — 2-3 дают основной прирост, дальше diminishing returns
- Уровень детализации критики — можно просить critique LLM давать не только ЧТО исправить, но и ПОЧЕМУ ошибка возникла
Шаблон промпта
У меня есть неструктурированный текст, который содержит табличные данные. Структура потерялась при копировании/OCR.
Восстанови таблицу в три этапа:
**Этап 1 — ГРАНИЦЫ:**
Найди где начинается и заканчивается каждая таблица или блок данных.
Игнорируй шум (пустые строки, примечания, не относящиеся к данным).
Покажи границы каждого блока.
**Этап 2 — РАЗДЕЛИТЕЛИ:**
Для каждого блока определи:
- Что разделяет строки (переводы строк, пустые строки, паттерны)?
- Что разделяет колонки (запятые, пробелы, табуляция, паттерны)?
- Какие поля (колонки) ты видишь в данных?
**Этап 3 — СТРУКТУРА:**
Создай таблицу в формате {формат_вывода}.
Заполни все ячейки значениями из текста.
После построения — ПРОВЕРЬ:
1. Coverage: Все ли данные из текста попали в таблицу?
2. Слитые ячейки: Нет ли значений, которые должны быть в разных колонках, но слиты в одну?
3. Разделители: Числа с запятыми (12,345) не развалились на части?
4. Скобки: Все открывающие скобки закрыты?
5. Типы данных: Колонка с числами не содержит текст и наоборот?
Если нашёл проблемы — исправь и покажи финальную версию.
Текст:
{текст_с_данными}Плейсхолдеры:
{формат_вывода}— JSON, CSV, Markdown table, или другой удобный формат{текст_с_данными}— твой неструктурированный текст
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода TEN для восстановления таблиц из неструктурированного текста.
Адаптируй под мою задачу: [опиши свою задачу — что за текст, какой результат нужен].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]LLM спросит: какой формат вывода предпочитаешь, есть ли специфика в данных (например, многоуровневые заголовки), нужны ли дополнительные проверки — потому что для эффективной работы метода нужно понимать структуру ожидаемой таблицы и потенциальные источники ошибок. Она возьмёт паттерн трёхэтапной декомпозиции и встроенной проверки, адаптирует под твой кейс.
Ограничения
⚠️ Сложность данных: Метод лучше работает на семантически богатых данных (с контекстными подсказками, описаниями). На чисто числовых таблицах без контекста или аббревиатурах, где значение зависит от позиции, точность падает. Например, финансовые таблицы с сокращениями показали худшие результаты (21.7% Exact Match vs 81.6% на других данных).
⚠️ Размер таблиц: С ростом числа строк точность снижается — большие таблицы (20+ строк) сложнее структурировать. Широкие таблицы (10+ колонок) тоже проблематичны из-за неоднозначности выравнивания.
⚠️ Токены: Итеративный процесс (2-5 итераций) требует много токенов. Каждая итерация = полная регенерация таблицы. Для больших таблиц это дорого.
⚠️ Применение принципов вручную: Полная реализация TEN требует кода (symbolic checker, critique LLM как отдельный компонент). В чате ты применяешь принципы метода (structural decomposition, самопроверка), но без автоматической валидации результат зависит от способности модели проверить себя.
Как исследовали
Исследователи взяли 1000 таблиц из четырёх датасетов (научные статьи с OCR, финансовые отчёты, Wikipedia, кривые CSV) и протестировали шесть моделей (GPT-4, DeepSeek-R1, o3-mini, DeepSeek-V3, Phi-4, Mistral-Small) на трёх видах промптинга: базовый ("построй таблицу"), CoT ("подумай step by step"), и Structural Decomposition. Сравнивали по Exact Match (идеальное совпадение), Column Match (совпадение колонок), Cell Value Match (совпадение значений ячеек), Coverage (сколько текста попало в таблицу) и Hallucination Rate (сколько модель придумала от себя).
Главное открытие: Structural Decomposition даёт +10-40 пунктов Exact Match vs CoT и базовый промпт. Особенно сильно помогает слабым моделям — o3-mini вырос с 2.2% до 14.4% (6x), GPT-4 с 8.9% до 21.7% (2.4x). Это означает, что явная структура в промпте компенсирует слабость модели.
Удивительный результат: самые "сложные" датасеты оказались легче. BrokenCSV (намеренно искажённые данные) показал 81.6% точности, а финансовые таблицы FinTabNet — только 21.7%. Почему? BrokenCSV содержит самоописываемые данные ("Price: $50", "Date: 2024-01-15") — даже без структуры модель понимает что это. Финтаблицы полны аббревиатур и чисел, где значение зависит от позиции в таблице — без разметки смысл теряется.
Итеративность работает: Основной прирост происходит в первые 2-3 итерации, дальше diminishing returns. Symbolic checker + Critique LLM вместе дают лучший результат, чем каждый по отдельности: symbolic alone — слишком строг (false positives), LLM alone — даёт общие советы вместо конкретных фиксов.
User study (21 участник): Люди оценили таблицы TEN значимо точнее чем альтернативу (5.0 vs 4.3 по шкале 1-7, p=0.021). В 7 из 20 таблиц все три независимых рецензента выбрали TEN. Интересный нюанс: хотя TEN точнее, effort на исправление статистически не отличается — потому что TEN требует фиксить alignment, а альтернатива — добавлять missing data, оба одинаково трудозатратны.
Адаптации и экстраполяции
💡 Адаптация для извлечения расписания событий:
Structural Decomposition эффективен не только для таблиц. Попробуй для календарей, расписаний, программ мероприятий.
У меня программа конференции скопирована из PDF, всё слилось.
Восстанови структуру в три этапа:
Этап 1 — ГРАНИЦЫ: Найди где начинается каждый день/секция
Этап 2 — РАЗДЕЛИТЕЛИ: Определи паттерны времени, спикеров, тем
Этап 3 — СТРУКТУРА: Создай JSON {день, время, спикер, тема, зал}
Проверь: все ли временные слоты на месте, нет ли слитых событий,
совпадают ли имена спикеров с оригиналом.
[текст программы]Логика та же — разбиение на подзадачи + самопроверка на типичные ошибки.
🔧 Техника: Увеличить transparency → видеть процесс мышления
Базовый шаблон просит модель показать границы и разделители, но не объясняет почему она их выбрала.
Добавь в промпт после каждого этапа:
После Этапа 1: Объясни ПОЧЕМУ ты выбрал эти границы. Какие паттерны указывают на начало/конец блока?
После Этапа 2: Объясни ПОЧЕМУ эти разделители. Приведи примеры из текста.
После Этапа 3: Покажи КАКИЕ решения ты принял при неоднозначности. Если было несколько вариантов структуры — почему выбрал этот?Эффект: Больше контроля, видно где модель сомневается, проще отловить ошибки до финальной генерации. Минус — больше токенов.
🔧 Техника: Сужение scope → фокус на критичных данных
Если в тексте есть шум (примечания, футеры, disclaimers) — модель может их включить в таблицу.
Модификация Этапа 1:
Этап 1 — ГРАНИЦЫ:
Найди где начинается и заканчивается каждый блок ТАБЛИЧНЫХ данных.
Исключи:
- Примечания и сноски (обычно начинаются с "Примечание:", "Note:", "*")
- Даты публикации и номера страниц
- Disclaimers и legal text
- Пустые строки и разделители
Покажи только границы ДАННЫХ, игнорируй мета-информацию.Эффект: Меньше шума в результате, модель не пытается структурировать то, что не является данными. Особенно полезно для документов с большим количеством текста вокруг таблиц.
Ресурсы
TEN: Table Explicitization, Neurosymbolically — Nikita Mehrotra, Ayush Kumar, Sumit Gulwani, Arjun Radhakrishna, Ashish Tiwari (Microsoft Research)
Исследование опубликовано в AAAI 2026. Включает эксперименты на датасетах PubTabNet, FinTabNet, WikiTables, BrokenCSV и user study с 21 участником.