Resolving Ambiguity Before It Reaches the Model

Ambiguity is waste: quantifying the cost

An ambiguous prompt wastes tokens, time, and money. The model generates an answer to the wrong question, or an answer that does not fit your use case, forcing you to regenerate and iterate.

Example of ambiguous prompt:

Write a summary of renewable energy.

The model could interpret this as:

• Solar and wind technology overview (technical deep-dive)
• Impact on the economy (financial analysis)
• History of the renewable energy movement (historical narrative)
• One paragraph vs. a 10-page essay
• For experts vs. general audience vs. children

The model picks one interpretation and generates. You read it and realize it is not what you needed. You iterate. Maybe 2–3 regenerations before you get it right.

Cost of ambiguity:

• Generation 1: Wrong interpretation (500 tokens wasted).
• Generation 2: Still not right (500 tokens wasted).
• Generation 3: Finally correct (500 tokens, correct).
• Total cost: 1,500 tokens + human review time.

Example of clarified prompt:

Write a 200-word summary of renewable energy technologies (solar, wind, geothermal)
targeted at high school students (ages 14–18, basic science knowledge).

INCLUDE:
- How each technology works (one sentence per technology)
- One major advantage for each
- Current usage / adoption rate (illustrative estimate)

TONE: Educational, accessible. Explain using analogies to everyday objects.
Avoid jargon; if you use a technical term, define it in parentheses.

FORMAT: Exactly 200 words. Short paragraphs (2–3 sentences each).

Now the model has crystal-clear targets: length, audience, scope, format, tone. One generation likely hits the mark.

Cost of clarity:

• Generation 1: Correct first time (500 tokens, correct).
• Total cost: 500 tokens + no rework.

Savings: 1,000 tokens (~$0.0001 per query) + human rework time (5–10 minutes).

The principle: Clarity is faster and cheaper than ambiguity. For a large-volume system (1 million queries/day), clarity saves $100/day in tokens alone, plus significant human time.

Proactive clarification: before generation

Resolve ambiguity in the prompt itself. This costs zero extra API calls—the clarification is part of your initial instruction.

Technique 1: Specify the output format

Ambiguous:

List the pros and cons of working from home.

Unclear output format. The model might use bullet points, a table, prose, or nested lists.

Clarified:

List the pros and cons of working from home in a two-column table.
Column 1: Pro, Column 2: Con. Include 5 rows.

Now the format is locked in.

Technique 2: Define the audience and context

Ambiguous:

Explain photosynthesis.

Unclear for whom. An explanation for a six-year-old is very different from one for a biology student.

Clarified:

Explain photosynthesis in 2 sentences as if talking to a 10-year-old who has never heard of it.

Or:

Explain photosynthesis at a graduate-level biology course. Assume familiarity with cellular respiration and electron transport chains.

Technique 3: Specify constraints and units

Ambiguous:

How long should a sales email be?

Long in what units? Words? Sentences? Reading time?

Clarified:

Write a sales email of no more than 150 words that can be read in under 30 seconds on a mobile phone.

Technique 4: Provide examples of the desired output

Ambiguous:

Classify customer feedback as positive, negative, or neutral.

What counts as neutral? Are mildly positive reviews positive or neutral?

Clarified:

Classify customer feedback as positive, negative, or neutral.

EXAMPLES:
- "This product is amazing!" → Positive
- "Does what it says, nothing special." → Neutral
- "Broke after two days. Waste of money." → Negative
- "Good quality but shipping was slow." → Positive (overall intent is favorable)

The examples disambiguate edge cases.

Technique 5: Specify the scope and constraints

Ambiguous:

List improvements we could make to our website.

Improvements in what domain? Visual design? Performance? Content? Budget is unlimited or limited?

Clarified:

List 5 improvements to our website's user onboarding flow that we could implement with a budget of $10K and within 4 weeks. Focus on reducing the time to first successful user action from signup to export. Do not redesign the entire page layout.

Reactive clarification: asking clarifying questions

Sometimes you cannot anticipate all ambiguities upfront. Instead of guessing, let the model ask clarifying questions before generating. This is a valid strategy in certain scenarios.

This is useful when:

• The user input is inherently ambiguous (multiple valid interpretations).
• Asking clarification is cheaper than regenerating a wrong answer (e.g., high rework cost).
• The interaction is conversational (user can respond to questions).
• Context is too complex to encode in a single prompt.

How to prompt for clarification

SYSTEM:
You are a helpful assistant. If a user request is ambiguous, ask clarifying questions before answering.
Do not guess or assume; ask up to 3–5 key questions.
Once you have answers, provide the response.

USER:
Can you write a summary of the company's performance?

ASSISTANT:
I'd like to clarify a few things to give you the most useful summary:

1. **Which company?** (Your organization, a specific company you follow, or a public company?)
2. **What time period?** (Last quarter, last year, since founding?)
3. **What aspects matter most?** (Financial results, product launches, team growth, market share, customer satisfaction?)
4. **Who is the audience?** (Board of directors, investors, employees, customers?)
5. **Preferred length?** (1 paragraph, 1 page, executive summary format?)

Please answer these, and I'll write a targeted summary for you.

Pros:

• User gets exactly what they need; zero wasted generation if they respond.
• Model can reason through ambiguities rather than guessing.
• Builds better rapport ("assistant is asking smart questions").

Cons:

• Adds 1–2 round-trip delays (user must respond).
• Not suitable for async or batch contexts (high latency tolerance required).
• User might drop out if asked too many questions.
• Increases token usage if user doesn't respond clearly.

When to ask vs. when to resolve upfront

| Scenario | Strategy | Rationale | |---|---|---| | Conversational chat with engaged user | Ask questions | Real-time feedback loop; user expects interaction. | | Batch processing (1,000 documents) | Resolve in prompt | No user available for questions; must specify assumptions. | | High-stakes decision (legal, medical, financial) | Ask (or manual intake) | Error cost is too high; clarify before risking wrong output. | | Creative brainstorming | Resolve (or stay ambiguous) | Ambiguity can drive unexpected ideas; over-specifying kills creativity. | | API endpoint (millions of calls/day) | Resolve completely | Determinism required; no user available to clarify. | | Internal tool with moderate latency tolerance | Ask for hard cases | If Layers 1–2 detect ambiguity, escalate to user for clarification. |

Hybrid approach: ask only when needed

def should_ask_clarifying_questions(user_input: str) -> bool:
    """Heuristic: decide if asking clarification is worth the latency."""

    # Ambiguity signals
    ambiguity_indicators = [
        r'\bsummary|overview|report',  # Vague output type
        r'\ball|everything|comprehensive',  # Over-ambitious scope
        r'\banybody can|anyone|universal',  # Vague audience
        r'\bas needed|relevant|appropriate',  # Vague scope
    ]

    ambiguity_score = sum(
        1 for pattern in ambiguity_indicators
        if re.search(pattern, user_input, re.IGNORECASE)
    )

    # If high ambiguity + conversational context, ask
    # If low ambiguity, just proceed
    return ambiguity_score >= 2

# Usage
if should_ask_clarifying_questions(user_input):
    clarification = model.generate(user_input, system=CLARIFICATION_SYSTEM_PROMPT)
    # User responds
    refined_input = user.respond()
    # Now generate with the refined input
    output = model.generate(refined_input, system=MAIN_SYSTEM_PROMPT)
else:
    # Low ambiguity; proceed directly
    output = model.generate(user_input, system=MAIN_SYSTEM_PROMPT)

Worked example: clarifying a content request

Scenario: A marketing manager asks you to write a product announcement.

Ambiguous version:

Write an announcement about our new feature.

This could be:

• Email to customers vs. blog post vs. social media
• Technical deep-dive vs. high-level benefit
• 50 words vs. 1,000 words
• Tone: formal, playful, urgent, casual?

Clarified version (proactive):

Write a product announcement for our new "Analytics Dashboard" feature.

FORMAT: Single paragraph (100–150 words), suitable for email to existing customers.

AUDIENCE: Existing customers who use our product for marketing analytics. Assume they know our product basics.

TONE: Professional but warm. Emphasize how this saves them time, not technical details.

STRUCTURE:
1. What: brief description of what the new feature does
2. Why: one main benefit (what problem does it solve?)
3. Call-to-action: direct them to a tutorial or documentation link

REQUIRED: Include the phrase "available now" and a link to our help documentation.

Result: One generation is likely to hit the mark. No back-and-forth needed.

Alternative (reactive): If you cannot anticipate all needs, ask:

I can help write the announcement. Let me clarify:

1. Where will this go? (Email, blog, Twitter, in-app notification, etc.)
2. How long? (Tweet-length, one paragraph, one page?)
3. Who's the main audience? (Existing users, new prospects, internal team?)
4. What's the main message? (It's new, it's fast, it's cheaper, it solves X problem?)
5. Any required phrases or links to include?

Once I understand these, I'll write it.

Resolving ambiguity in constraints: tone, formality, and style

Constraints like "professional," "concise," or "friendly" are subjective. Be specific.

Example 1: Tone ambiguity

Ambiguous:

Keep the tone professional.

What counts as professional? Law firm formal? Tech startup casual? Investment banking stuffy?

Clarified with specifics:

TONE: Professional corporate style
- Use formal address: "Dear Dr. Smith" (not "Hi" or "Hey")
- Complete sentences, no abbreviations (use "cannot" not "can't")
- Avoid slang or colloquialisms
- Style: Corporate email to a C-level executive

Better: clarified with examples:

TONE: Professional corporate style

GOOD EXAMPLE:
"We appreciate your feedback and are committed to addressing your concerns.
Please allow us 2 business days to investigate this matter."

BAD EXAMPLE:
"Thanks for the message! We'll look into it asap lol. Hang tight!"

KEY DIFFERENCES:
- Formal opening ("We appreciate") not casual ("Thanks")
- No slang or abbreviations ("asap", "lol")
- Specifics on timeline ("2 business days") not vague ("soon")

Example 2: Formality spectrum

Rather than "formal," specify where on the spectrum you want to be:

FORMALITY LEVEL: Professional-but-warm (like a financial advisor talking to a new client)

NOT professional-distant (like legal document language)
NOT casual-friendly (like texting a friend)
NOT formal-stuffy (like a Victorian letter)

Examples:
- Good: "I'm happy to help you find the right plan for your situation."
- Bad (too stuffy): "It is our professional obligation to ascertain your pecuniary requirements."
- Bad (too casual): "Hey! Let's figure out what works for you, no stress!"

Example 3: Conciseness constraints

Ambiguous:

Keep responses concise.

How concise? 50 words? 500 words?

Clarified:

CONCISENESS: 3–5 sentences per response.
If more detail is needed, offer to expand in a follow-up.

MAX LENGTH: 150 words.
TARGET: 75–100 words.

Comparison table: specific vs. vague constraints

| Vague Constraint | Specific Constraint | Why specific is better | |---|---|---| | "Be professional" | "Corporate email tone: formal address, complete sentences, no slang" | Model can follow exact rules; no guessing. | | "Keep it concise" | "Exactly 3 sentences, max 100 words" | Measurable target; no ambiguity. | | "Sound friendly" | "Warm and approachable like a helpful neighbor; use 'we' language" | Clear mental model; examples help. | | "Avoid jargon" | "Explain using words a high school student knows. Define any technical term in parentheses." | Actionable rule; model knows what to do. | | "Be creative" | "Use metaphors or analogies to explain concepts. Avoid clichés (overused phrases)." | Defines creativity narrowly; helps model focus. |

Common mistakes and how to avoid them

Mistake 1: Over-constraining (analysis paralysis)

You provide so many clarifications that the prompt becomes a wall of contradictory text and the model gets confused.

Bad example (too much):

Write a summary of the report. The summary should be 500 words but also concise.
It should cover all key points but focus on the top 3. It should be formal but
also conversational. It should be written for executives but also be
understandable to non-technical readers. Include a recommendation but only if
you're confident. Avoid jargon but use domain-specific terminology where needed.

Problems:

• Contradictions: "500 words but also concise"—which is it?
• Ambiguity: "top 3" vs. "all key points"—pick one.
• Conflicting tones: "formal" vs. "conversational" are opposites.
• Too many qualifiers: "but only if," "unless," "if needed"—adds confusion.

The model doesn't know which constraint takes priority.

Better (focused):

Write a 200-word executive summary of the report.

MUST include:
- Top 3 findings (prioritize impact over comprehensiveness)
- One recommended action
- Your confidence level (high/medium/low)

Tone: Professional and clear. No jargon; define technical terms in one sentence if needed.

Audience: Board members (average 10 years industry experience, not domain experts).

Why better:

• Word count is concrete (200 words).
• Scope is clear (top 3, not all).
• Tone is consistent (professional, not formal-and-conversational).
• Constraints are in priority order (board summary first, then tone).

Rule of thumb: If your clarification exceeds three sentences and uses words like "but," "however," "unless," or "if," it is probably over-constrained. Simplify.

Mistake 2: Leaving ambiguities unsaid

You assume the model will infer context, and it doesn't.

Example:

Summarize this article for Twitter.

What counts as "summary" for Twitter? A headline (280 chars)? A thread (10 tweets)? A retweet-baiting clip?

The model guesses. It picks wrong. You rework.

Better:

Write a Twitter post (max 280 characters) that captures the article's main takeaway.
Goal: Make someone curious enough to click and read the full article.
Tone: Engaging, not clickbait.

Now the model knows: one post, exactly 280 chars, engagement-focused, authentic tone.

Mistake 3: Asking clarifying questions when you could specify upfront

Every clarifying question adds latency and requires user response. If you can anticipate the ambiguity, specify upfront.

Bad (asks questions):

I need help with a content strategy. Can you ask me some questions so you understand what I need?

This triggers a round-trip (user responds), then another generation (you create the strategy).

Better (specify upfront):

I need a 6-month content strategy for a B2B SaaS product targeting IT managers.

Business context:
- Product: A data governance platform
- Target buyers: CIOs and data stewards at mid-market companies (500–5000 employees)
- Current awareness: Low (we're new to market)
- Budget: Moderate (can fund 1–2 contractors or in-house team)
- Goals: 50 qualified leads per month by month 6; 500 LinkedIn followers

Deliverables:
1. Monthly content themes (6 months)
2. Content format breakdown (blog, LinkedIn, video, etc.)
3. SEO keywords to target
4. Estimated workload and budget

Please provide a prioritized roadmap.

One generation, no round-trips. Faster and cheaper.

When to ask:

• Information is truly unknowable (e.g., "Which customer is complaining?").
• Iterative refinement is part of the process (e.g., brainstorming).

When to specify:

• Information is in your control (e.g., audience, goals, constraints).
• You want speed and determinism.

Mistake 4: Not testing clarified prompts on edge cases

You clarify a prompt, test it on the "happy path," and ship it. But on edge cases, it fails.

Fix: After clarifying, test on 10–20 diverse examples:

• Inputs at the boundary of your spec (e.g., if you said "200 words," try 199 and 201 as input).
• Inputs that are slightly off-spec (e.g., user provides 2 topics instead of 3).
• Inputs from different users/contexts (not just your own examples).

Log failures. They are data points for improving your prompt.