Исследование помогло понять границы применимости LLM для таблиц: когда они решают задачу, а когда нет. И дальше следует вопрос: а если не решают, то почему? И можно ли добиться того, чтобы решали? Поможет ли SFT на таких данных? А претрейн? А архитектура модели? И т. д.
Каждое подмножество --- это 10000 уникальных таблиц, каждая из которых до 32 тысяч токенов. У нас 5 синтетических сетов.токенов. С ценой $3 за млн токенов получается 1600 баксов, и это только Claude 3.5 Sonnet без учета затрат на генерацию. o1 с их test-time compute будет еще дороже.
Но цена не главное.
Мы хотим использовать модели не только для того, чтобы выполнить замеры и впечатлить вас, но и для ряда других задач, в том числе на внутренних данных, передача которых по API в сторонние компании запрещена. Поэтому и рассматриваем только те модели, которые возможно использовать локально.
Дальше будем улучшать бенчмарк, добавлять в него новые задачи и готовить академическую статью. Вот тогда и проведем замеры на более дорогих моделях.
Запросы SQL хорошо подходят, если таблицы имеют «правильную» структуру. Мы в основном проекте тоже так пробовали, показывали заголовок и превью таблицы, но подход имел ряд ограничений. Например, в таблицах в документах (подчеркиваю, в документах, неструктурированных!) часто бывают сноски. Мы ищем значение, равное "1234", а в ячейке на самом деле стоит "1234*" --- получаем не тот ответ, на который рассчитывали.
Работать будет, но такой системный промпт настраивает модель отвечать коротко, четко и по делу. Если писать «ты — креативный автор...», результат, очевидно, будет другой.
«Пожалуйста, верни валидный JSON! Не галлюцинируй. От твоего ответа зависит моя карьера». )
Вывод как раз верный. Если модели плохо отвечают по таблицам из 64 строк, то вряд ли они смогут ответить и по более сложным.
Что касается подачи картинки, то мы явно прописали, что оценивали только текстовые модели (LLM), а мультимодальные картиночно-текстовые (LVLM) оставили как future work. Это написано следующим предложением после «неверного» вывода.
Вашу идею можно еще развить. Например, в модель можно подавать одновременно и скриншот, и текст таблицы.
Или вы утверждаете, что ChatGPT как текстовая модель умеет понимать base64? Может быть, вы тоже? Потому что я нет.
Когда выложим бенчмарк, ждем от вас самбита и SOTA-метрик. И, конечно, верных выводов!
С утверждением про опрометчивость я согласен частично. Наши эксперименты показали, что для таблиц определенной структуры и сложности подход «заливать в контекст все данные» оказывается рабочим, чего не ожидали даже мы сами!
Построчно можно, но представьте, насколько это будет дольше. В нашей постановке делается один запрос в LLM и получается один короткий ответ. В вашем решении нужно делать до 64 вызовов, получать 64 ответа, потом еще как-то их агрегировать.
Вообще говоря, то, что для таблицы из одной строки (и заголовка) модель будет отвечать хорошо, мы уже показали. На тепловых картах все метрики близки к 90-100% для , причем это когда ответ находится в первой строке, хотя сами таблицы могут быть и больше.
Про случайную pdf-ку всё правда. Задача сложная, но тем и интересная!
Конкретно эту задачу можно решить и генерацией простого SQL/pandas-запроса к таблице. Через RAG она тоже решается, однако если бы вопрос стоял «Какое максимальное значение в столбце ?», то RAG был бы бессилен.
Мы специально стали решать задачу «в лоб», поскольку любой частный подход не будет универсальным, а от LLM часто ждут именно этого.
Правильнее было бы сказать «самые передовые и при этом доступные». Согласен, что от o1 и Claude 3.5 Sonnet ожидаются более высокие результаты, но в качество 100% я не верю, особенно в постановке задачи без Chain-of-Thought. Когда опубликуем бенчмарк, все желающие смогут проверить на нем и другие модели, в том числе названные вами.
На следующей неделе узнаю у коллег про сроки. Думаю, это будет в начале декабря. Можем с вами в частном порядке договориться насчет раннего доступа.
Исследование помогло понять границы применимости LLM для таблиц: когда они решают задачу, а когда нет. И дальше следует вопрос: а если не решают, то почему? И можно ли добиться того, чтобы решали? Поможет ли SFT на таких данных? А претрейн? А архитектура модели? И т. д.
Каждое подмножество --- это 10000 уникальных таблиц, каждая из которых до 32 тысяч токенов. У нас 5 синтетических сетов.
токенов. С ценой $3 за млн токенов получается 1600 баксов, и это только Claude 3.5 Sonnet без учета затрат на генерацию. o1 с их test-time compute будет еще дороже.
Но цена не главное.
Мы хотим использовать модели не только для того, чтобы выполнить замеры и впечатлить вас, но и для ряда других задач, в том числе на внутренних данных, передача которых по API в сторонние компании запрещена. Поэтому и рассматриваем только те модели, которые возможно использовать локально.
Дальше будем улучшать бенчмарк, добавлять в него новые задачи и готовить академическую статью. Вот тогда и проведем замеры на более дорогих моделях.
Запросы SQL хорошо подходят, если таблицы имеют «правильную» структуру. Мы в основном проекте тоже так пробовали, показывали заголовок и превью таблицы, но подход имел ряд ограничений. Например, в таблицах в документах (подчеркиваю, в документах, неструктурированных!) часто бывают сноски. Мы ищем значение, равное "1234", а в ячейке на самом деле стоит "1234*" --- получаем не тот ответ, на который рассчитывали.
Работать будет, но такой системный промпт настраивает модель отвечать коротко, четко и по делу. Если писать «ты — креативный автор...», результат, очевидно, будет другой.
«Пожалуйста, верни валидный JSON! Не галлюцинируй. От твоего ответа зависит моя карьера». )
За агентами будущее.
Вывод как раз верный. Если модели плохо отвечают по таблицам из 64 строк, то вряд ли они смогут ответить и по более сложным.
Что касается подачи картинки, то мы явно прописали, что оценивали только текстовые модели (LLM), а мультимодальные картиночно-текстовые (LVLM) оставили как future work. Это написано следующим предложением после «неверного» вывода.
Вашу идею можно еще развить. Например, в модель можно подавать одновременно и скриншот, и текст таблицы.
Или вы утверждаете, что ChatGPT как текстовая модель умеет понимать base64? Может быть, вы тоже? Потому что я нет.
Когда выложим бенчмарк, ждем от вас самбита и SOTA-метрик. И, конечно, верных выводов!
С утверждением про опрометчивость я согласен частично. Наши эксперименты показали, что для таблиц определенной структуры и сложности подход «заливать в контекст все данные» оказывается рабочим, чего не ожидали даже мы сами!
Построчно можно, но представьте, насколько это будет дольше. В нашей постановке делается один запрос в LLM и получается один короткий ответ. В вашем решении нужно делать до 64 вызовов, получать 64 ответа, потом еще как-то их агрегировать.
Вообще говоря, то, что для таблицы из одной строки (и заголовка) модель будет отвечать хорошо, мы уже показали. На тепловых картах все метрики близки к 90-100% для
, причем это когда ответ находится в первой строке, хотя сами таблицы могут быть и больше.
Про случайную pdf-ку всё правда. Задача сложная, но тем и интересная!
Конкретно эту задачу можно решить и генерацией простого SQL/pandas-запроса к таблице. Через RAG она тоже решается, однако если бы вопрос стоял «Какое максимальное значение в столбце
?», то RAG был бы бессилен.
Мы специально стали решать задачу «в лоб», поскольку любой частный подход не будет универсальным, а от LLM часто ждут именно этого.
Правильнее было бы сказать «самые передовые и при этом доступные». Согласен, что от o1 и Claude 3.5 Sonnet ожидаются более высокие результаты, но в качество 100% я не верю, особенно в постановке задачи без Chain-of-Thought. Когда опубликуем бенчмарк, все желающие смогут проверить на нем и другие модели, в том числе названные вами.