QASU: How Data Format and Prompting Affect the Way LLMs Handle Tables

This isn't a step-by-step method but three independent principles that work together:

PRINCIPLE 1: Data format

• HTML table → better for precise answer lookups (+8.8% vs Turtle)
• Plain text with separators → better for logic and filters
• Visual separators between sections → mandatory (-16-24% without them)

PRINCIPLE 2: One-shot example

• One example answer before the question → +10-25% accuracy
• Especially critical for multi-step questions (up to +25%)

PRINCIPLE 3: Self-augmented prompting (optional)

• Step 1: "Describe the structure of this table" → the model outputs its understanding
• Step 2: Question about the data + the answer from step 1 → +3-4% accuracy

The task: You have a CSV with the results of a customer survey for an online school: 200 rows, 15 questions. You need to find everyone who rated the course 4-5 points AND plans to buy more courses.

Prompt (applying all three principles):

Here is a table with a customer survey. Each row is one person.

<table>
<tr><th>ID</th><th>Course rating</th><th>Future plans</th><th>NPS</th></tr>
<tr><td>001</td><td>5</td><td>Will buy more</td><td>9</td></tr>
<tr><td>002</td><td>3</td><td>Not sure</td><td>6</td></tr>
<!-- ... remaining rows ... -->
</table>

=== EXAMPLE QUESTION AND ANSWER ===

Question: How many people rated the course 5?
Answer: 78

=== YOUR QUESTION ===

Find everyone who rated the course 4 or 5 points AND plans to buy more courses. 
Give me a comma-separated list of IDs.

Result: The model will return an exact list of customer IDs that meet both conditions. Without the one-shot example, accuracy drops by ~15-20%; without the HTML markup, by another 5-8%.

If you need maximum accuracy, add self-augmented prompting:

Step 1: Describe the structure of this table: how many rows, which columns, what values each one holds.

[the model will describe: "200 rows, 15 columns, rating from 1 to 5, plans in 4 categories..." and so on]

Step 2: Using that description, find everyone who rated the course 4-5 AND plans to buy more.

The LLM's weakness: models process text sequentially, left to right. Tabular data is a two-dimensional structure (rows × columns) that has to be "read" correctly. If the format isn't obvious, the model mixes up where one row ends and the next begins, and which values belong to which person.

The LLM's strength: models are excellent at recognizing patterns and structural markers. HTML tags like <tr> and <td> explicitly mark cell boundaries. Visual separators like === clearly mark sections. A one-shot example provides a template for what a correct answer should look like.

How the methods exploit this:

• HTML format + separators = explicit structure, no ambiguity
• One-shot example = the model sees "this is how to answer" and copies the pattern
• Self-augmented prompting = the model first talks through the structure for itself, like "making a plan before solving", which reduces interpretation errors

Control levers:

• Data format → try HTML vs Markdown vs plain text for your specific task
• Separators → add === between sections for complex tables
• Number of examples → one is enough for simple tasks, 2-3 for complex patterns
• Self-augmented step → drop it for simple tasks (saves tokens), add it for critical ones

Basic (format + one-shot)

Here is a table: {data description}

{your_data_in_HTML_or_Markdown}

=== EXAMPLE ===

Question: {example_question}
Answer: {example_answer}

=== YOUR QUESTION ===

{your_question}

Give the answer as {answer_format: "a list of IDs", "a number", "a table", etc.}

Placeholders:

• {data description} — one sentence on what's in the table (for example: "Survey of 200 coding-bootcamp customers, 15 questions")
• {your_data_in_HTML_or_Markdown} — the table itself
• {example_question/answer} — one simple question-and-answer pair based on the same data
• {your_question} — what you want to find out
• {answer_format} — state explicitly how to deliver the result

Advanced (+ self-augmented)

Step 1: Study this table and describe its structure in 3-5 sentences: how many rows, which columns, what types of values, whether there are any patterns.

{your_data}

---

Step 2: Using the structure description from Step 1, answer the question:

{your_question}

🚀 Quick start: paste this into the chat:

Here's the QASU research on working with tables. Adapt the template to my task: 
[describe your task: what the data is, what you need to find/count].

[paste the template above]

The LLM will ask what format your data is in (CSV, Excel, Google Sheets), what exactly you want to know from the data, and whether you need maximum accuracy (self-augmented) or the basic version is enough. It will take the structure from the template and plug in your data.

⚠️ Data size: Works for tables up to ~1000-2000 rows (depends on the model's context window). For larger data, the model will ask you to sample it or split it into chunks.

⚠️ Data cleanliness: The methods assume the table has no critical gaps. If half the cells are empty, accuracy drops: the model can't tell whether that means "no answer" or "formatting error".

⚠️ Data type: Best for structured surveys/questionnaires with a fixed set of questions. Arbitrary tables with complex nesting may need extra work.

⚠️ Format VS task: HTML is top for looking up specific people's answers, but plain text may be better for conceptual aggregation. There's no universal "best format"; it depends on the type of question.

The team gathered 5 real survey datasets from different fields: hospital discharge records (Healthcare), psychological well-being (Mental-health), wearable-device usability (SUS-UTA7), the Stack Overflow developer survey, and medical-student assessments (ISBAR). They took 200-500 rows from each and mixed in different question types: multiple choice, Likert scales, open-ended answers.

The clever bit of the design: they tested the same questions in six formats: HTML, JSON, XML, Markdown, plain text, Turtle. That isolated the effect of the format from the effect of the data itself. Questions were standardized using templates (see the table in the original paper) to remove the influence of wording.

They measured exact match accuracy: either the answer matched the ground truth exactly, or it didn't. No "almost right". They tested GPT-5-mini, Gemini-2.5-Flash, Qwen3-32B, Llama3-70B and Amazon Nova Lite, spanning commercial to open-source.

The most interesting part: the gap between formats turned out to be bigger than the gap between models. HTML gave +8.8% accuracy vs Turtle on the task of finding a specific person's answer. Removing the === separators between sections cost 16-24% accuracy on counting tasks. In other words, HOW you feed in the data matters more than WHICH model you use.

One-shot vs zero-shot made a 10-25% difference in accuracy, with the biggest gap on multi-step questions (the "find everyone who is X AND Y" type). Without an example, the model simply didn't understand what format to answer in: sometimes a number, sometimes a list, sometimes prose.

Self-augmented prompting was tested in three variants: asking the model to (1) explain the table's format, (2) highlight critical values and ranges, (3) describe the structure and patterns. All three helped, but the best was "describe the structure" (+3.1% on Mental-health, +1.7% on SO-2022 for GPT-5-mini).

Practical takeaway: don't hunt for the "best model" for table work. Fix the data format and the prompt first; that pays off more.

💡 Adaptation for CRM data

The QASU principles work not just for surveys but for any tabular data: a CRM export, a Google Sheet of customers, a QuickBooks export.

Here is a quarterly customer export from HubSpot.

<table>
<tr><th>ID</th><th>Company</th><th>Deal amount</th><th>Status</th><th>Rep</th></tr>
<tr><td>1001</td><td>Northwind Industries Inc.</td><td>45000</td><td>Closed won</td><td>Miller</td></tr>
<!-- ... -->
</table>

=== EXAMPLE ===
Question: How many deals did Miller close?
Answer: 12

=== QUESTION ===
Find all customers with deals of $50k or more that are managed by Johnson. List of IDs.

The payoff: you save time on filters in Excel or your CRM and can ask questions in plain language.

🔧 Technique: drop the one-shot to save tokens → only suitable for simple questions

If the question is trivial ("how many rows are in the table?"), you can skip the one-shot. But for any filters or conditions, always include it.

🔧 Technique: state data types explicitly → more accurate for numeric operations

Column descriptions:
- Deal amount: number (US dollars)
- Close date: format MM/DD/YYYY
- Status: text (one of: "Open", "Closed won", "Closed lost")

{then the table and the question}

This cuts down confusion: the model knows that "45000" is a number, not text, so it can compare values.

QASU: Questionnaire Analysis and Structural Understanding — Duc-Hai Nguyen, Vijayakumar Nanjappan, Barry O'Sullivan, Hoang D. Nguyen (University College Cork, Ireland).

The benchmark is available on GitHub: ReML-AI/QASU.

The paper was published at Conference'17, Washington, DC, USA.