Structuring Data for LLMs: How Input Format Cuts Errors by 65%

STEP 1: Structure the data Unstructured data → a table/JSON with atomic fields (one fact = one field)

STEP 2: Use hierarchy for relationships Nest related data (an event contains the player, action, result)

STEP 3: Feed it to the LLM with a prompt Point out the structure: "here's a table with columns X, Y, Z" or "here's JSON where..."

All in one request. You can ask the LLM itself to structure the data first, then work with the structured version.

Task: You're analyzing sales for a US online store, a file with a month of transaction data. You need a report by region: where sales are growing, where they're tanking, which products are selling. The data arrived as a mess, with every line looking like "12/05/2024 Chicago Sneakers Nike Air $129.99 paid by card shipped via UPS".

Prompt:

Convert this transaction data into JSON with these fields:
- date (date)
- region (region)
- product_category (product category)
- product_name (name)
- price (price)
- payment_method (payment method)
- delivery_service (shipping carrier)

Then analyze: which regions show sales growth, which categories lead, and whether there are patterns by payment method.

[transaction data]

Result:

The model will first show structured JSON with clear fields for every transaction. Then it gives an analysis with no mix-ups: exact figures by region (it won't confuse Chicago with the Chicago suburbs), correct product counts by category (it won't lump Nike in with Adidas), and the right leaders. Without structuring, the model might misparse "$129.99" (taking it for a SKU), assign a product to the wrong region, or confuse the payment method with the shipping method.

LLMs process sequences of tokens: to them, "12/05/2024 Chicago Sneakers Nike Air $129.99" is just a string of words with no explicit structure. The model has to infer on its own that "12/05/2024" is a date, "Chicago" is a region, and "$129.99" is a price. Ambiguities pile up: does "Air" belong to the product or to the shipping? Is "129.99" a price or a SKU? The more complex the data (450+ rows in a basketball game, thousands of transactions on a marketplace), the more contextual dependencies there are: the model "remembers" the score was 123, but 50 tokens later it may forget and write 130.

LLMs work well with explicit structure: tables, JSON, and XML provide boundary markers. Here's the "price" field, here's the "region" field, here's the nested "event.player.name" field. The model doesn't guess; it reads from a specific spot. Atomic fields stop things from blending: one field holds only the player's name, another only the shot type, so there's no need to parse "LeBron James makes 3-pt jump shot" and pull out the pieces. JSON's hierarchy creates semantic links: an event contains players, play_details, and score, so the model understands WHAT belongs to WHAT.

Control knobs: If the data is simple (10-20 rows), a table is enough. If there are complex relationships (player → team → action → result → score), JSON is more effective. If the data is already in JSON, don't flatten it into text; feed it as is. If you got unstructured text, ask the LLM to structure it first, then work with the structure.

Basic (for tabular data):

Here's a table of data: {table_description}

Columns: {list_column_names_and_what_they_contain}

{analysis_task}

Be precise with the facts — use only the data from the table, don't fill in gaps.

For JSON (hierarchical data):

Here's the data in JSON format:

{your_JSON}

Structure: {briefly_describe_the_hierarchy}

{analysis_task}

Rely strictly on the fields provided. Don't infer information that isn't in the data.

Two-step (if the data is unstructured):

STEP 1: Convert this unstructured data into a {table/JSON} with these fields:
- {field_1}: {what_it_contains}
- {field_2}: {what_it_contains}
...

{data}

STEP 2: Using the structured data, {analysis_task}

Placeholder notes:

• {table_description} — what the data is (sales, games, orders)
• {list_column_names_and_what_they_contain} — "date, region, product, price, status"
• {analysis_task} — what you need back (report, summary, insights)
• {your_JSON} — paste the full JSON
• {briefly_describe_the_hierarchy} — "each event contains a player, action, result"
• {field_N} — field names for structuring

🚀 Quick start — paste into your chat:

I have some unstructured data. Help me structure it in the best way for accurate analysis. Ask me questions about the data and the task, then suggest a format (a table or JSON with fields).

[describe your data and what you need to do with it]

The LLM will ask which fields there are, how the data is related, whether you need a hierarchy, and what kind of analysis you're planning, because the best structure depends on that. It'll suggest a concrete format for your task.

⚠️ An extra step: You have to structure the data first. If there's a lot of it and it's complex, that can take time or require the LLM's help.

⚠️ Not everything structures easily: For qualitative data (reviews, comments, articles), structuring can lose important nuances. The method is for factual data where accuracy is critical.

⚠️ Format know-how: Even though an LLM can help with structuring, a basic understanding of JSON/tables is useful for checking the result.

⚠️ Tokens: Structured data takes up more space. In the study, JSON weighed in at 70-80k tokens vs 13k for unstructured text, so for large datasets you may hit context limits.

The University of Aberdeen team took 30 NBA games from December 2024 – January 2025 (to avoid data contamination: the models hadn't seen these games in training). They picked games stratified by score margin: 7-8 games from each range (≤3 points, 4-9, 10-19, ≥20), so there were both nail-biters and blowouts.

They took raw play-by-play logs from Basketball Reference and turned them into three formats: (1) the original text — "L. James makes 3-pt jump shot from 25 ft", (2) a table with columns: time, period, team, player, action, event type, outcome, distance, score, (3) hierarchical JSON where each event is nested: {time: {...}, team: "Lakers", play_details: {event: {...}, players: {...}}, score: {...}}.

They ran these through Llama-3.1-70B and Qwen2.5-72B (both predating the 2024-25 season) with the same prompt, asking for a 450-word game summary. That gave 180 texts (30 games × 2 models × 3 formats). Then they hand-annotated every error — 3,312 of them! They grouped them into categories: numerical (score, counts), names (players, teams), objective wording (confusing a "shot" with a "dunk"), subjective phrases ("the decisive moment"), and contextual (mentioning a player who wasn't in that game).

Why did the results come out this way? A two-way ANOVA (input format × model) showed that format explains 80%+ of the variation in errors, which is huge! So it's not the model's fault (though Llama is slightly more accurate with JSON and Qwen slightly more careful with names); it's HOW you feed the data. Post-hoc tests (Tukey HSD) confirmed that each step down (JSON → table → text) significantly hurts accuracy (all p < 0.05).

The surprise: Even a simple table cuts errors in half versus text. JSON adds another 30%, but the gap between JSON and a table is smaller than between a table and text. Practical takeaway: you don't have to build elaborate JSON; even a basic table structure already helps a lot. If the data isn't deeply nested, a table will do.

An interesting detail: Llama made more numerical errors (it tried to tally runs and add up points, and got them wrong), while Qwen made more name errors (with unstructured input it sometimes hallucinated players from a different game entirely, like "Christian Wood," who didn't play that season at all). The errors aren't random; they're systematic and tied to how models handle sparse information in text.

Prompt from the experiment:

You are a professional basketball reporter hired by my company to cover NBA games. You are provided with a hierarchical JSON play-by-play dataset, which includes structured team information and a chronological list of plays. Each play entry contains key details such as time remaining, the team involved, play description, event type, player names, and score updates.

Your task is to analyse the data and identify the four most significant moments in each quarter, key scoring plays, momentum shifts, lead changes, game ties, and clutch performances. Prioritise impactful events such as three-pointers, layups, dunks, free throws, and possessions immediately following turnovers or rebounds. Ignore minor plays that do not significantly influence the game's flow.

Write a fluent, engaging, and objective game summary of exactly 450 words, structured around these defining moments. The narrative should clearly convey why these moments were significant, seamlessly integrating them into the game's overall storyline. It should flow naturally from start to finish, capturing the game's pace and intensity.

Mention the final score and quarter-ending scores for context, but do not rigidly structure the summary by time. Discuss key players in relation to the game-defining plays, without calculating total points. Maintain a smooth, journalistic writing style. Do not write in bullet points, lists, or unnecessary formatting. The summary must be factually accurate, strictly based on the provided data, and completely free from external assumptions, while maintaining a compelling and professional tone.

Quarter-End Context: Mention the total score contextually within the narrative as each quarter concludes. DO NOT list the quarter scores separately at the very end of the summary.

Context: The researchers used this prompt for every generation, swapping the "hierarchical JSON" wording for each format (row-structured table, unstructured text). Note the instructions: (1) "exactly 450 words" to normalize length for error counting, (2) "without calculating total points" to avoid arithmetic, (3) "strictly based on the provided data" as an attempt to reduce hallucinations.

💡 Adaptation for financial data:

The principle works for any factual data. For example, analyzing bank transactions:

Convert the statement into JSON:
{
  "date": "2025-01-15",
  "transaction": {
    "type": "payment",
    "category": "groceries",
    "merchant": "Trader Joe's",
    "amount": 42.50,
    "payment_method": "card_ending_4321"
  },
  "balance": {
    "before": 1250.00,
    "after": 1207.50
  }
}

Analyze spending by category for the month. Be precise with the amounts.

💡 Adaptation for medical records:

Symptom journal → structured log:

Structure these wellness notes into JSON:
{
  "date": "2025-01-03",
  "symptoms": [
    {"name": "headache", "severity": 7, "duration_hours": 3},
    {"name": "fatigue", "severity": 5, "duration_hours": null}
  ],
  "triggers": ["not enough sleep", "stress at work"],
  "relief_actions": ["ibuprofen 400mg", "2 hours of rest"]
}

Find patterns: which triggers most often lead to symptoms, and what helps.

💡 Adaptation for event logs:

Server/app logs → structured analysis:

Convert the error logs into a table:

| timestamp | error_type | service | user_id | error_message | resolved |
|-----------|-----------|---------|---------|---------------|----------|

Determine: which errors are most frequent, in which services, and whether there are time-based patterns.

🔧 Technique: progressive drill-down → token savings

If there's a LOT of data (thousands of rows), use a two-level structure:

STEP 1: Aggregate the data into a summary table
[large dataset]

STEP 2: Work with the summary for the overall analysis

STEP 3: If you need details for a specific period/category,
request a structured slice of the source data

This lets you: (1) stay within the context limit, (2) get both an overview and details on demand, (3) keep accuracy, since aggregation happens explicitly, not "in the model's head."

Input Matters: Evaluating Input Structure's Impact on LLM Summaries of Sports Play-by-Play
Barkavi Sundararajan, Somayajulu Sripada, Ehud Reiter
Department of Computing Science, University of Aberdeen
Datasets (row-structured and JSON NBA play-by-play): https://github.com/BarkaviSJ/nba-input-matters