TL;DR
При работе с табличными данными формат загрузки и промпт влияют на точность LLM больше, чем может показаться. QASU — исследование, которое проверило как GPT, Gemini и другие модели обрабатывают CSV-файлы опросов, анкет и таблиц в шести разных форматах (HTML, JSON, XML, Markdown, plain text, Turtle). Измерили точность на шести типовых задачах: найти ответ конкретного человека, посчитать респондентов, найти всех кто ответил определённым образом, логические фильтры.
Главная находка: выбор формата данных меняет точность до 8.8%. HTML-разметка работает лучше всего для поиска ответов, plain text хорош для логических операций. Убрать визуальные разделители между секциями — потеря 16-24% точности. Модели "видят" структуру по-разному в зависимости от того, как вы представили таблицу — с тегами, отступами, разделителями или просто текстом.
Два ключевых принципа улучшают результат: (1) One-shot промптинг — один пример ответа повышает точность на 10-25% по сравнению с "холодным" вопросом; (2) Self-augmented промптинг — сначала попросить модель описать структуру таблицы своими словами, потом задать вопрос по данным. Это даёт ещё +3-4% точности, особенно когда нужно найти людей по критериям или агрегировать концепции.
Схема принципов
Это не пошаговый метод, а три независимых принципа, которые работают вместе:
ПРИНЦИП 1: Формат данных
- HTML-таблица → лучше для точного поиска ответов (+8.8% vs Turtle)
- Plain text с разделителями → лучше для логики и фильтров
- Визуальные разделители между секциями → обязательны (-16-24% без них)
ПРИНЦИП 2: One-shot пример
- Один пример ответа перед вопросом → +10-25% точности
- Особенно критично для многошаговых вопросов (до +25%)
ПРИНЦИП 3: Self-augmented промптинг (опционально)
- Шаг 1: "Опиши структуру этой таблицы" → модель выдаёт своё понимание
- Шаг 2: Вопрос по данным + ответ из шага 1 → +3-4% точности
Пример применения
Задача: У тебя CSV с результатами опроса клиентов онлайн-школы — 200 строк, 15 вопросов. Нужно найти всех кто оценил курс на 4-5 баллов И планирует покупать ещё курсы.
Промпт (с применением трёх принципов):
Вот таблица с опросом клиентов. Каждая строка — один человек.
<table>
<tr><th>ID<th>Оценка курса<th>Планы на будущее<th>NPS
<tr><td>001<td>5<td>Куплю ещё<td>9
<tr><td>002<td>3<td>Не уверен<td>6
=== ПРИМЕР ВОПРОСА-ОТВЕТА ===
Вопрос: Сколько человек оценили курс на 5?
Ответ: 78
=== ТВОЙ ВОПРОС ===
Найди всех кто оценил курс на 4 или 5 баллов И планирует покупать ещё курсы.
Выдай список ID через запятую.Результат: Модель выдаст точный список ID клиентов, которые удовлетворяют обоим условиям. Без one-shot примера точность падает на ~15-20%, без HTML-разметки — ещё на 5-8%.
Если нужна максимальная точность — добавь self-augmented промптинг:
Шаг 1: Опиши структуру этой таблицы — сколько строк, какие столбцы, какие значения в каждом.
[модель опишет: "200 строк, 15 столбцов, оценка от 1 до 5, планы — 4 категории..." и т.д.]
Шаг 2: Используя это описание, найди всех кто оценил курс на 4-5 И планирует покупать ещё.Почему это работает
Слабость LLM: модели обрабатывают текст последовательно, слева направо. Табличные данные — это двумерная структура (строки × столбцы), которую нужно "прочитать" правильно. Если формат неочевиден, модель путает где заканчивается одна строка и начинается другая, какие значения относятся к какому человеку.
Сильная сторона LLM: модели отлично распознают паттерны и структурные маркеры. HTML-теги <tr>, <td> явно показывают границы ячеек. Визуальные разделители === чётко отмечают секции. One-shot пример даёт шаблон как должен выглядеть правильный ответ.
Как методы используют это:
- HTML-формат + разделители = явная структура, нет двусмысленности
- One-shot пример = модель видит "так надо отвечать" и копирует паттерн
- Self-augmented промптинг = модель сначала проговаривает структуру для себя, это как "составить план перед решением" — снижает ошибки интерпретации
Рычаги управления:
- Формат данных → попробуй HTML vs Markdown vs plain text под свою задачу
- Разделители → добавь
===между секциями для сложных таблиц - Количество примеров → один enough для простых задач, 2-3 для сложных паттернов
- Self-augmented шаг → убери для простых задач (экономия токенов), добавь для критичных
Шаблон промпта
Базовый (формат + one-shot)
Вот таблица: {описание данных}
{твои_данные_в_HTML_или_Markdown}
=== ПРИМЕР ===
Вопрос: {пример_вопроса}
Ответ: {пример_ответа}
=== ТВОЙ ВОПРОС ===
{твой_вопрос}
Ответ выдай {формат_ответа: "списком ID", "числом", "таблицей" и т.д.}Плейсхолдеры:
{описание данных}— одно предложение что в таблице (например: "Опрос 200 клиентов школы программирования, 15 вопросов"){твои_данные_в_HTML_или_Markdown}— сама таблица{пример_вопроса/ответа}— один простой вопрос-ответ по этим же данным{твой_вопрос}— что хочешь узнать{формат_ответа}— явно укажи как выдать результат
Продвинутый (+ self-augmented)
Шаг 1: Изучи эту таблицу и опиши её структуру в 3-5 предложениях: сколько строк, какие столбцы, какие типы значений, есть ли паттерны.
{твои_данные}
---
Шаг 2: Используя описание структуры из Шага 1, ответь на вопрос:
{твой_вопрос}🚀 Быстрый старт — вставь в чат:
Вот исследование QASU про работу с таблицами. Адаптируй шаблон под мою задачу:
[опиши свою задачу — что за данные, что нужно найти/посчитать].
[вставить шаблон выше]LLM спросит какой формат данных у тебя (CSV, Excel, Google Sheets), какой именно вопрос по данным, нужна ли максимальная точность (self-augmented) или достаточно базового варианта. Она возьмёт структуру из шаблона и подставит твои данные.
Ограничения
⚠️ Размер данных: Работает для таблиц до ~1000-2000 строк (зависит от context window модели). Для больших данных модель попросит сэмплировать или разбить на части.
⚠️ Чистота данных: Методы предполагают что в таблице нет критичных пропусков. Если половина ячеек пустые, точность падает — модель не понимает это "нет ответа" или "ошибка формата".
⚠️ Тип данных: Лучше всего для структурированных опросов/анкет с фиксированным набором вопросов. Для произвольных таблиц со сложной вложенностью может потребоваться доработка.
⚠️ Формат VS задача: HTML топ для поиска ответов конкретных людей, но plain text может быть лучше для концептуальной агрегации. Нет универсального "лучшего формата" — зависит от типа вопроса.
Как исследовали
Команда собрала 5 реальных датасетов опросов из разных областей: выписки из больниц (Healthcare), психологическое благополучие (Mental-health), юзабилити носимых устройств (SUS-UTA7), опрос разработчиков Stack Overflow, оценка студентов-медиков (ISBAR). Взяли по 200-500 строк из каждого, смешали разные типы вопросов — множественный выбор, шкалы Лайкерта, открытые ответы.
Главная фишка дизайна: проверили одни и те же вопросы в шести форматах — HTML, JSON, XML, Markdown, plain text, Turtle. Это позволило изолировать эффект формата от эффекта самих данных. Вопросы стандартизировали по шаблонам (см. таблицу в оригинале), чтобы убрать влияние формулировки.
Замеряли exact match accuracy — ответ либо точно совпал с истиной, либо нет. Никаких "почти правильно". Тестировали GPT-5-mini, Gemini-2.5-Flash, Qwen3-32B, Llama3-70B, Amazon Nova Lite — от коммерческих до open-source.
Самое интересное: разница между форматами оказалась больше, чем между моделями. HTML давал +8.8% точности vs Turtle на задаче поиска ответа конкретного человека. Убрать разделители === между секциями — минус 16-24% точности на задачах подсчёта. Это означает что КАК ты подаёшь данные важнее ЧТО за модель используешь.
One-shot vs zero-shot дал разницу 10-25% точности, причём самый большой gap на многошаговых вопросах (тип "найди всех кто X И Y"). Модель без примера просто не понимала в каком формате выдавать ответ — то числом, то списком, то текстом.
Self-augmented промптинг протестировали в трёх вариантах: попросить модель (1) объяснить формат таблицы, (2) выделить критичные значения и диапазоны, (3) описать структуру и паттерны. Все три дали прирост, но лучше всего сработало "опиши структуру" (+3.1% на Mental-health, +1.7% на SO-2022 для GPT-5-mini).
Инсайт для практики: не нужно искать "лучшую модель" для работы с таблицами. Сначала поправь формат данных и промпт — это даст больше профита.
Адаптации и экстраполяции
💡 Адаптация для CRM-данных
Принципы QASU работают не только для опросов, но и для любых табличных данных — экспорт из CRM, Google Sheets с клиентами, выгрузка из 1С.
Вот экспорт клиентов из amoCRM за квартал.
<table>
<tr><th>ID<th>Название<th>Сумма сделки<th>Статус<th>Менеджер
<tr><td>1001<td>ООО "Техпром"<td>450000<td>Закрыто успешно<td>Иванов
=== ПРИМЕР ===
Вопрос: Сколько сделок закрыл Иванов?
Ответ: 12
=== ВОПРОС ===
Найди всех клиентов со сделками от 500к, которых ведёт Петрова. Список ID.Профит: экономия времени на фильтрах в Excel/CRM, можно задавать вопросы на естественном языке.
🔧 Техника: убрать one-shot для экономии токенов → годится только для простых вопросов
Если вопрос тривиальный ("сколько строк в таблице?"), one-shot можно опустить. Но для любых фильтров/условий — обязательно включай.
🔧 Техника: добавить явное указание типов данных → точнее для числовых операций
Описание столбцов:
- Сумма сделки: число (рубли)
- Дата закрытия: формат ДД.ММ.ГГГГ
- Статус: текст (одно из: "Открыто", "Закрыто успешно", "Отказ")
{далее таблица и вопрос}Это уменьшает путаницу — модель знает что "450000" это число, не текст, можно сравнивать.
Ресурсы
QASU: Questionnaire Analysis and Structural Understanding — Duc-Hai Nguyen, Vijayakumar Nanjappan, Barry O'Sullivan, Hoang D. Nguyen (University College Cork, Ireland).
Бенчмарк доступен на GitHub: ReML-AI/QASU.
Статья опубликована на Conference'17, Washington, DC, USA.