Apply to my task
arXiv:2507.23336 ★ 72 Jul 31, 2025

Context engineering: a structured data map instead of a raw dump + queries without hidden traps

Key result

The request 'Name the top 3 countries with a stable birth rate' hides a trap. The model reasons: if they're asking, such countries must exist. And it confidently names ones that don't. Context engineering lets you give the model a structured 'map' of the data instead of a raw dump, and strip hidden assumptions out of your queries. The trick: instead of 'name the top 3', ask 'find the ones that fit, then pick the top 3 from them': the first version assumes the objects already exist, the second checks. Accuracy goes up, hallucinations go down.

DSBC : Data Science task Benchmarking with Contextengineering

Key Aspects of the Research:

The study introduces and tests "Context Engineering", a method where, instead of a huge mass of raw data, the model is given a structured description of it (metadata). The authors compare how different LLMs perform on data analysis tasks using this approach, and also analyze how hidden assumptions in prompt wording affect accuracy.

Key Result: giving the model a structured "map" of the data and setting clear, sequential tasks without hidden assumptions significantly improves the accuracy and reliability of answers.


The Method in a Nutshell:

Imagine you need an assistant to analyze a huge 500-page annual report. You have two options: 1. Bad approach: Drop the report on the assistant's desk and say, "Find me the three main problems and suggest solutions". The assistant will burn a ton of time reading everything, may miss what matters and get confused. 2. Good approach (the essence of the method): Give the assistant the same report, but attach a one-page brief: "This is the 2023 annual report. It has 5 sections: Finance, Sales, Marketing, HR, Logistics. The key figures are in Finance. Supply problems are described in Logistics. Here are the first 5 rows of the sales table". Then give a clear task: "1. Study the Sales section and find the months with the lowest revenue. 2. Match them against the problems in the Logistics section. 3. Propose 3 solutions".

"Context Engineering" is exactly the act of creating that short, structured "brief" for the LLM. Instead of "force-feeding" the model the whole mass of information (which may not fit into the context window or may be full of noise), you give it a metadata description: number of items, their types, key categories, time ranges, a few representative examples and so on. That helps the model quickly get its bearings in the "territory" of your data.

The second important finding concerns "clean" queries. The study shows that a question like "Name the top 3 countries with the most stable birth rate" works worse than a two-step request: "1. Find the countries with a stable birth rate. 2. From those, output the top 3". The first version implicitly assumes such countries exist at all, which can lead to an error or a hallucination. The second is logically safer and gives a more reliable result.


Practical Applicability:

  • Direct applicability:

    • Building "context blocks": Before any complex task involving information analysis (an article, reviews, a document), the user can add a [CONTEXT] block to the prompt that describes the key characteristics of that information as a list or as "key: value" pairs.
    • Query decomposition: Instead of asking one complex question with a hidden assumption ("What are the three cheapest options..."), you can split it into two steps: "1. Find all available options and their prices. 2. Sort them by price and show the three cheapest".
  • Conceptual value:

    • The study clearly demonstrates that an LLM is a tool, not a wizard. The quality of the result depends directly on the quality and structure of the data and instructions you provide.
    • It builds a useful habit of "thinking for the model": "What's the minimum information I need to provide so the model understands the task and doesn't hallucinate?". That shifts the paradigm from "ask a question" to "set a task with context".
  • Potential for adaptation:

    • The method adapts easily to any task. Instead of a JSON structure for the data, as in the paper, an everyday user can use Markdown: headings, lists, bold text. For example, when analyzing product reviews, the context block might include: **Product:**, **Review source:**, **Count:**, **Main topics:**. The structuring principle stays the same.

A Practical Example:

Say you're a product manager and need to analyze user reviews of a new meditation app.

You are an experienced product analyst. Your job is to analyze user reviews and give recommendations for improving the product.

[CONTEXT]
**Product:** The "Quiet Mind" mobile app.
**Data source:** 150 App Store reviews from the past month.
**Data structure:** Each review has a rating (1-5 stars) and a text comment.
**Key app features mentioned in reviews:**
- Meditation library (100+ practices)
- Breathing exercises
- AI-powered personal recommendations
- Paid "Quiet Mind+" subscription
**Sample reviews (first 5):**
1. "5 stars: Great app! I especially love the breathing exercises."
2. "2 stars: Good idea, but the AI keeps suggesting the same thing. And the subscription is pricey."
3. "4 stars: Huge library, but it's hard to find the meditation you want."
4. "1 star: Keeps crashing on my old phone."
5. "5 stars: I use it every night before bed, thank you!"

[TASK]
Follow these steps:
1.  Analyze all the reviews and determine whether there are any recurring themes (positive or negative).
2.  If such themes exist, group them into categories (for example: "Price", "Technical issues", "Content", "UX/UI").
3.  For each category, give 2-3 quotes from the reviews.
4.  Based on this analysis, define 3 top priorities for the development team for next quarter. Present the answer as a bulleted list.

Why It Works:

This prompt is effective because it applies the study's findings directly:

  1. Context engineering: The [CONTEXT] block works as the structured "data map" from the paper. It gives the model all the background it needs: what the product is, where the data comes from, what its key features are. That spares the model from guessing and lets it focus on the task right away, matching review text against the app features it now knows about.
  2. Structure and examples: Providing Sample reviews (the equivalent of Sample rows in the paper) helps the model understand the format and tone of the data it'll be working with.
  3. A "clean", step-by-step query: The task is split into 4 sequential steps. Instead of a generic "What should we improve?", we use safe wording: "determine whether there are any recurring themes", "If such themes exist...". This is the equivalent of a "clean query": it makes no assumptions and leads the model along a logical chain, which, as the study showed, significantly improves accuracy.

Another Practical Example

Task: Build a content plan for a personal finance expert's blog.

You are an experienced content marketer. Your job is to help a personal finance expert develop a content plan for their blog.

[CONTEXT]
**Expert:** Mark Miller, financial advisor.
**Target audience:** Young professionals aged 25-35 who want to start investing but have limited knowledge and budget.
**Core message of the blog:** "Investing is simple and accessible to everyone".
**Key topics the expert is strong in:**
- Budgeting and saving
- Stock market basics (stocks, bonds)
- Tax-advantaged accounts for investors (Roth IRA, 401(k))
- The psychology of money
**Content format:** Blog articles (1000-1500 words) and short posts for the newsletter.

[TASK]
Work step by step:
1.  Analyze the interests and pain points of the target audience based on the context provided.
2.  Suggest 5 specific blog article topics that address those pain points and fit the blog's core message.
3.  For each of the 5 topics, write a short outline (3-4 points).
4.  Suggest 3 ideas for short newsletter posts that could tease one of these articles or complement it.

Why This Example Works

This prompt follows the same winning logic as the previous one, adapting the study's principles to a creative task:

  1. Context engineering: The [CONTEXT] block clearly marks out the "playing field" for the LLM. The model knows who it's writing for (Target audience), what core message it has to get across (Core message) and which of the expert's strengths it can lean on (Key topics). That prevents generic, irrelevant ideas and channels the model's creativity in the right direction.
  2. Breaking down a complex task: Instead of an abstract "Come up with a content plan", the task is split into logical stages: audience analysis -> article topic generation -> topic outlines -> ideas for another format. This "multi-step" approach, whose effectiveness the study demonstrated, makes the model reason sequentially, which leads to a more thoughtful and comprehensive result. Each next step flows logically from the previous one, improving the overall coherence of the answer.

Usefulness Score: 85

02

Main Evaluation Criteria

  • A. Relevance to prompting techniques: Very high. The study introduces and tests the concept of "Context Engineering": structured delivery of metadata instead of "raw" data. It also analyzes how prompt wording (raw vs. clean queries) affects results, which is squarely prompt engineering.
  • B. Better conversational answers: High. Although the study focuses on generating code for data analysis, its findings are universal. The principles of structured context and removing ambiguity/hidden assumptions ("data leakage") lead directly to more accurate and relevant answers in any task.
  • C. Direct practical applicability: High. A user can apply "Context Engineering" right away without any tools, simply by structuring the important information at the start of the prompt. The "clean queries" technique also works immediately, just by rewording the question.
  • D. Conceptual value: Very high. The study gives the user a powerful mental model: an LLM isn't an all-knowing oracle but a powerful, yet literal, information processor. It needs help: a "map" of the data (context) and clear, sequential instructions. It vividly shows why structure and precision in a prompt matter.
  • E. New useful practice (clustering): The work falls into several key clusters at once:

    • #1 Prompt phrasing techniques: The analysis of "raw vs. clean" queries and multi-step approaches.
    • #2 LLM behavioral patterns: Demonstrates sensitivity to "data leakage" (hidden assumptions in the prompt).
    • #3 Prompt structure optimization: "Context Engineering" is essentially an advanced method for structuring input.
    • #6 Context and memory: Offers an effective strategy for working with context when the data itself is too big for the model's window.
    • #7 Reliability and stability: Shows how more precise wording reduces errors.
  • Practicality checklist (+15 points): Yes, the study provides ready-made constructions (structured context, "clean" queries), explains how to present important information and how to structure complex requests, and reveals non-obvious aspects of LLM behavior. +15 points on top of the base score (70) = 85.

03

Numeric Usefulness Score

Arguments for a score of 85: The study introduces and proves the effectiveness of two extremely useful practices for any LLM user: 1. "Context engineering": A formalization of, and a name for, what experienced users do intuitively: preparing a short, structured summary of the topic for the LLM before setting the task. The work gives a clear structure for how to do it (see Table 3). 2. Fighting "data leakage" in the prompt: The raw vs. clean query example ("Among those who died..." vs "Were there any deaths...") is a brilliant illustration of how our unconscious assumptions in a question can throw the model off. It teaches users to phrase requests more cleanly and with more logical consistency.

These two findings have huge practical value and can be applied right away in any field, from writing reports to planning trips, which makes the study extremely useful for a broad audience.

Counterarguments (why the score could be lower): * Narrow specialization: All experiments are in data science and Python code generation. An inexperienced user may find it hard to look past pandas and matplotlib and see how universal these principles are. * Academic focus: The paper's main goal is building a benchmark to evaluate LLM agents, not writing a prompting guide. The practical takeaways are more a byproduct of the analysis than its main goal.


Research digest

Key result

The request 'Name the top 3 countries with a stable birth rate' hides a trap. The model reasons: if they're asking, such countries must exist. And it confidently names ones that don't. Context engineering lets you give the model a structured 'map' of the data instead of a raw dump, and strip hidden assumptions out of your queries. The trick: instead of 'name the top 3', ask 'find the ones that fit, then pick the top 3 from them': the first version assumes the objects already exist, the second checks. Accuracy goes up, hallucinations go down.

Principle

The standard approach: throw the whole dataset at the model plus one complex question. The result: the model drowns in noise and confirms whatever the user expects to hear. Context engineering works differently. First comes a [CONTEXT] block: a structured description of the data (what the data is, how many records, which fields, 5 sample rows). Then a [TASK] block with a step-by-step breakdown and no hidden assumptions. Each step is one action. Each next step flows logically from the previous one. The model doesn't guess what it's looking at: it understands the 'territory' right away and follows a clear route.

Why it works

A model is like a navigator without a map: it doesn't know where you are and plots a route to who knows where. Structured context is the map. The model stops guessing the data structure and stops wasting effort getting its bearings in the noise. The key discovery: hidden assumptions in queries are one of the main sources of hallucinations in data analysis. Ask for the 'top 3' and the model is sure they exist and will make them up. Ask it to 'find them if they exist, then pick the top 3' and the model checks first, then answers. To be honest, the study gives no specific improvement numbers, but the point about hidden assumptions is a genuine insight that explains a lot of familiar problems.

When to apply

Analyzing structured data: tables, reviews, reports, databases, especially when the task involves sorting, filtering or finding the top N in a large set. Works well for tasks like review analysis, audience-based content planning and financial data breakdowns. NOT a fit for simple questions with no data: there the context block just bloats the prompt for nothing.

Mini recipe

1. Create a [CONTEXT] block: Describe the data in a structured way. What the data is, where it comes from, how many records, which fields or categories, 3-5 sample rows. Don't dump everything, just the map. 2. Create a [TASK] block: Break the complex question into steps. Each step is one concrete action. Each next step flows logically from the previous one. 3. Remove hidden assumptions: Replace 'Name the top 3 X' with 'Find all X. If there are any, pick the top 3.' Replace 'What problems are there?' with 'Are there recurring themes? If so, group them.' 4. Check before sending: Reread the task. Are there words that assume the answer already exists? Remove them or add 'if any exist'.

Examples

[BAD]: `Here are 200 app reviews. Name the three main problems and what to improve.` [GOOD]: `[CONTEXT] 200 App Store reviews from March. Ratings 1-5. Key topics mentioned: speed, design, price, customer support. Sample reviews: 1. '5 stars: runs really fast', 2. '2 stars: the subscription is pricey', 3. '1 star: crashes on my old phone'. [TASK] 1. Find recurring themes in the reviews, if there are any. 2. If themes are found, group them into categories and give 2 quotes for each. 3. If there are several problem themes, suggest 3 priorities for the development team.`

In plain words

Here's the point: today's LLMs aren't just text calculators, they're context processors. The DSBC study proves it: the model produces results based not on its "knowledge" but on how you packaged the input. Toss in a pile of reviews and say "analyze this", and the model spits out platitudes. But apply context engineering, and it starts seeing structure where there used to be chaos. It's a fundamental shift from simple prompting to data architecture inside the request.

It's like walking up to a seasoned analyst and dumping a heap of crumpled receipts, napkin scraps and screenshots on their desk. Technically the data is there, but the poor soul will burn hours just figuring out which is the date and which is the amount. The DSBC method is when you bring the same data already sorted into folders, with colored sticky notes and a clear brief. In the first case you get an irritated "well, sales seem to be growing"; in the second, a detailed segment-by-segment report, because you took the cognitive load off the person doing the work.

The paper pinpoints a specific mechanism: structuring the task through context. When you analyze reviews of a meditation app, you don't just ask it to "find problems". You set a role (product manager), define the scope of analysis (only technical bugs, or usability) and, most importantly, use entity markup. That makes the model stop guessing what matters and focus on the specific patterns you flagged in advance. As a result, the accuracy of the conclusions jumps, because you've literally hard-wired the solution logic into the request itself.

Although the study ran on data science tasks, the principle is universal. It works everywhere: from legal contract audits to writing marketing strategies. If you understand how to structure a raw stream of information, you can get ChatGPT or Claude to do solid mid-level work. It's no longer just "chatting with a bot", it's programming in natural language, with context acting as a rigid frame for the logic.

Bottom line: forget one-line prompts, they lead nowhere. The future belongs to serious context engineering, where you lay out the path for the model's thinking in advance. The DSBC study confirms it: the better you set the "stage" for the model, the lower the odds it starts hallucinating or padding. Either you learn to manage context, or you keep getting useless junk you'd be embarrassed to show your boss.

AI lab assistant

Apply this study to your task

Describe what you're working on. AI takes the method and the measured results from this paper and adapts them to your case, or writes a ready prompt built on them.

Based on Context engineering: a structured data map instead of a raw dump + queries without hidden traps arXiv:2507.23336

Sign in to apply this study New accounts get 50 free credits.

Get the week’s best papers by email

One email on Sundays with the highest-rated new techniques. Unsubscribe with one click.