Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Yuxiang Wang, Junhao Gan и Jianzhong Qi из The University of Melbourne представили TabScope для ответов на вопросы по таблицам; работа опубликована как препринт, который не проходил рецензирования. По замерам авторов, выбор области таблицы повысил точность до 4,3 процентного пункта по сравнению с обязательной локализацией. Результат важен командам, которые строят поиск и аналитику по длинным таблицам поверх LLM и сейчас всегда передают модели либо всю таблицу, либо заранее сокращённый фрагмент.
Что сделали
TabScope выбирает область данных отдельно для каждого вопроса. Сначала LLM относит вопрос к заранее определённому типу: например, поиск записи, подсчёт, сравнение или ранжирование. Затем фиксированное правило решает, следует ли оставить исходную таблицу или выделить из неё строки и столбцы, необходимые для ответа. Правило учитывает не только тип вопроса, но и размер таблицы.
Локализация построена вокруг требуемой операции, а не только вокруг совпадений слов. Для вопроса о количестве команд из определённой страны с результатом выше порога системе нужны страна, результат и идентификатор команды. Если выбирать ячейки только по словам из вопроса, часть этих доказательств можно потерять.
Декомпоновщик делает несколько вариантов выборки строк и столбцов, объединяет повторяющиеся результаты и учитывает уверенность модели, если она доступна. Кандидаты оцениваются одновременно по поддержке среди выборок и по компактности. После этого проверяющая модель сопоставляет полученный фрагмент с полной таблицей и добавляет пропущенные данные. Если классификатор выбрал полный контекст, эти этапы пропускаются.
Для проверки промежуточного результата авторы также собрали WTQ-SubTab — набор эталонных фрагментов для вопросов WikiTQ. Эти фрагменты названы «серебряными»: их создала LLM, после чего другая модель проверила полноту и отсутствие лишних строк и столбцов. Отдельно авторы подготовили SLQA на основе реальных длинных таблиц из Spider, заменив исходные задания новыми вопросами и ответами.
Что показали
Основная метрика — точное совпадение ответа с эталоном. На WikiTQ адаптивный TabScope получил в среднем 82,2% против 80,3% у рассуждения по полной таблице. На SLQA результат составил 68,1% против 67,3%. Средние значения рассчитаны по GPT-5-mini и LLaMA-3.3-70B.
По замерам авторов, локализация чаще помогала при поиске сущности, ранжировании, поиске минимального или максимального значения и рассуждении по небольшой группе записей. Полная таблица чаще оказывалась полезна, когда требовалось посчитать все подходящие строки или сравнить несколько групп. Поэтому единая стратегия — всегда сокращать либо всегда сохранять таблицу — уступила маршрутизации по типу вопроса во всех показанных авторами сочетаниях набора данных и модели.
Проверка на WTQ-SubTab связывает итоговую точность с качеством выбранных данных: TabScope чаще находил полный набор нужных строк, столбцов и ячеек, чем рассмотренные методы декомпозиции. Это важно для диагностики системы, поскольку правильный ответ сам по себе не показывает, была ли найдена достаточная доказательная область.
Ограничения
Авторы проверяли подход только на англоязычных WikiTQ и SLQA и только с GPT-5-mini и LLaMA-3.3-70B. В SLQA таблица содержала в среднем около 9,8 тысячи токенов, причём все таблицы превышали порог 4096 токенов; вопросы для этого набора генерировались автоматически и затем проверялись вручную. Поэтому работа не показывает переносимость результатов на другие языки, предметные области, форматы таблиц и семейства моделей.
WTQ-SubTab использует не полностью ручную разметку, а «серебряные» фрагменты, созданные и исправленные моделями. Политика выбора области выведена из результатов на проверочной части наборов и опирается на фиксированную классификацию вопросов. В работе нет сравнения с маршрутизатором, который обучается выбирать область без такой классификации, а также нет оценки задержки и стоимости дополнительных обращений к LLM для выборки, объединения и проверки фрагмента.
Что это значит
Работа меняет архитектурный план, если продукт отвечает на разнородные вопросы по длинным таблицам и сейчас использует фиксированную предварительную обработку. Локализацию стоит рассматривать не как обязательный этап, а как ветку маршрутизации: запросы с компактной доказательной областью направлять в сокращённый контекст, а запросы с подсчётами и широкими сравнениями — в полный.
При этом результаты не обосновывают немедленную замену действующего конвейера на TabScope. Выигрыш на длинных таблицах относительно полного контекста в замерах авторов невелик, а эксплуатационная цена многошаговой локализации не измерена. Практический следующий шаг — проверить на собственных вопросах три режима: полный контекст, обязательное сокращение и адаптивный выбор, отдельно измеряя точность, задержку и стоимость.
Для новой системы полезно сразу сохранять решение маршрутизатора и выбранные строки и столбцы. Это позволит отличать ошибку ответа от ошибки локализации и менять правила выбора области без перестройки всей цепочки.
Источники
Иллюстрация: рисунок из статьи «TabScope: Question-Adaptive Scope Selection for Table Question Answering», Yuxiang Wang, Junhao Gan, Jianzhong Qi, CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
