Ambiguity Detection Prompt for Multi-Intent Streams

This prompt is designed for system architects and MLOps engineers who need to decompose complex, multi-intent user inputs in high-volume streaming or batch pipelines. The core job-to-be-done is reliable intent decomposition: taking a single input that contains multiple overlapping requests and producing a structured breakdown with confidence weights, enabling downstream systems to make informed routing or clarification decisions. The ideal user is an engineering lead building a classification middleware layer where a single record might need to trigger multiple workflows simultaneously—for example, a customer support message that contains both a billing dispute and a technical troubleshooting request.

Use this prompt when your system must handle inputs where a single classification label is insufficient. Concrete scenarios include: a chat message asking to 'cancel my subscription and also why is the mobile app crashing,' a support ticket mixing a feature request with a bug report, or an API call that combines a data export request with an access revocation command. The prompt requires a well-defined taxonomy of possible intents ([INTENT_TAXONOMY]) and a clear output schema ([OUTPUT_SCHEMA]) that downstream routers can parse. Do not use this prompt for simple binary or single-label classification tasks where a standard intent classifier is cheaper and faster. It is also inappropriate for real-time, sub-50ms decision loops where the token overhead of decomposition would violate latency budgets.

Before implementing, ensure you have a concrete plan for handling the prompt's output. The decomposition will produce multiple intent objects, each with a confidence score. Your harness must decide on a conflict resolution strategy: route to all detected intents in parallel, route only to the highest-confidence intent, or trigger a clarification workflow if confidence is split. Avoid deploying this prompt without eval checks that measure boundary precision—specifically, whether the model correctly separates truly independent intents from a single intent expressed in multiple ways. The next section provides the copy-ready template you can adapt to your taxonomy and output contract.

This prompt template is designed to be the core classification logic within a streaming or batch processing pipeline. It accepts a single input record and a taxonomy of known intents, then determines if the input contains one clear intent, multiple overlapping intents, or is genuinely ambiguous. The output is a structured decomposition that downstream routers, queues, or clarification modules can act on directly. Use this template as the starting point for your own ambiguity detection step, adapting the placeholders to your specific domain, intent taxonomy, and output schema.

textCopy
You are an intent classification and ambiguity detection system for a high-volume processing pipeline. Your task is to analyze a single input record and determine if it expresses one clear intent, multiple overlapping intents, or is genuinely ambiguous.

## INPUT
[INPUT]

## INTENT TAXONOMY
[INTENT_TAXONOMY]

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
1. Analyze the input against every intent in the taxonomy.
2. If the input clearly expresses a single intent, output a single intent classification with a confidence score of 0.95 or higher.
3. If the input expresses multiple distinct intents, decompose it into all constituent intents, each with its own confidence score. Do not force a single label when multiple intents are genuinely present.
4. If the input is genuinely ambiguous and you cannot determine the intent(s) with confidence above [MIN_CONFIDENCE_THRESHOLD], flag it for clarification and output your best hypothesis with a low confidence score.
5. For each detected intent, provide a brief rationale grounded in specific evidence from the input text.
6. If the input contains conflicting intents, note the conflict explicitly in the output.

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## EXAMPLES
[EXAMPLES]

To adapt this template for production, replace each placeholder with your specific configuration. [INTENT_TAXONOMY] should be a complete list of your supported intents with descriptions and examples. [CONSTRAINTS] can include rules like "never classify support requests as sales inquiries" or domain-specific boundaries. [MIN_CONFIDENCE_THRESHOLD] is a critical parameter—set it based on your tolerance for misrouting; start at 0.70 and tune using eval data. [OUTPUT_SCHEMA] must define the exact JSON structure your downstream systems expect, including fields for is_ambiguous, intents (array of objects with label, confidence, rationale), and requires_clarification. [EXAMPLES] should include at least one clear single-intent case, one multi-intent case, and one genuinely ambiguous case to calibrate the model's behavior. After deploying, monitor the rate of requires_clarification flags and the accuracy of multi-intent decompositions against human-reviewed samples.

The ambiguity detection prompt is not a standalone classifier—it is a pre-routing decomposition step that sits between your ingestion layer and your intent-specific workflows. In a streaming pipeline, each incoming record hits this prompt first. The model either returns a single dominant intent with high confidence (allowing direct routing) or decomposes the input into multiple intents with confidence weights and clarification flags. The harness must handle both cases without blocking the stream.

Integration pattern: Deploy this prompt as a lightweight pre-processor in your stream topology (e.g., a Kafka Streams processor, Flink operator, or AWS Lambda consuming from Kinesis). Each record triggers a model call with a strict timeout (recommend 2–5 seconds for real-time streams; up to 30 seconds for batch). The output schema must be validated before any routing decision: check that intents is a non-empty array, each intent has a label and confidence between 0 and 1, and the requires_clarification boolean is present. Reject malformed outputs and route them to a dead-letter queue with the raw model response attached for debugging. For high-throughput streams, batch multiple records into a single model call using a JSON array input and a corresponding array output schema to reduce API overhead—but cap batch size at 10–20 records to avoid confidence degradation on later items.

Multi-route dispatch logic: When the model returns multiple intents, your harness must decide whether to fan-out (send the record to all intent-specific queues), serialize (process intents in priority order), or escalate (send to a clarification queue for human review). Implement this as a configurable routing policy: if the top two confidence scores are within 0.15 of each other, fan-out to both workflows; if requires_clarification is true, route to a human review queue with the original input and the model's decomposition; if one intent dominates (confidence ≥ 0.8 and gap to next intent ≥ 0.3), route directly. Log every routing decision with the model's raw output, the routing policy applied, and the target queue for auditability.

Retry and fallback: Model calls will fail. Implement exponential backoff with jitter (initial delay 200ms, max 3 retries) for transient errors. For persistent failures or timeout breaches, fall back to a rule-based keyword classifier as a safety net—this won't catch multi-intent cases but prevents pipeline blockage. Monitor the fallback activation rate; if it exceeds 2% of traffic, investigate model availability or latency. For high-risk domains (healthcare, finance, legal), add a circuit breaker: if the model's confidence distribution shifts significantly (e.g., sudden spike in requires_clarification or drop in mean confidence), halt automated routing and escalate all traffic to human review until the shift is diagnosed.

Eval harness integration: Before deploying, run this prompt against a golden dataset of 200+ records with known intent boundaries, including single-intent, multi-intent, ambiguous, and out-of-scope examples. Measure intent boundary F1 (did the model correctly identify where one intent ends and another begins?), multi-intent recall (did it catch all intents present?), and clarification precision (when it flags requires_clarification, is human review actually needed?). Set acceptance thresholds: multi-intent recall ≥ 0.85, clarification precision ≥ 0.90. Run these evals on every prompt change and on a weekly schedule to detect model behavior drift. Wire eval failures to block automated deployment and alert the platform team.