With a structure in place, quality hinges on wording. Vague verbs (“improve,” “handle,” “be helpful”) force the model to guess success criteria. This lecture turns fuzzy asks into measurable instructions that survive A/B tests and prompt evaluation.
Learning Objectives
By the end of this lesson, students should be able to:
- Spot vague verbs, unbounded scope, and missing success criteria.
- Rewrite prompts with concrete actions, audiences, and limits.
- Specify length, format, and decision rules without over-constraining.
- Use checklists and acceptance tests as clarity tools.
- Distinguish “specific” from “overfitted to one example.”
- Connect clarity to eval metrics used in Module 13.1.
Clarity and specificity means stating the task so that a competent stranger (or model) can produce an acceptable result without inventing missing requirements—using concrete verbs, explicit boundaries, and observable success criteria.
Where Ambiguity Hides
| Vague phrase | What the model must invent | Clearer rewrite |
|---|---|---|
| “Summarize this” | Length, audience, focus | “3 bullets for execs; facts only” |
| “Be professional” | Tone scale, formality | “Neutral, no slang, no humor” |
| “Fix the code” | Bug vs refactor vs style | “Fix the null crash; no API changes” |
| “Use best judgment” | Policy | “If unsure, ask one question” |
| “Keep it short” | Word/token budget | “Max 60 words” |
Before / After
Before (weak):
After (strong):
Specificity Checklist
Action
- One primary verb
- Classify / extract / draft
- Avoid “help with”
Scope
- In-scope fields
- Out-of-scope topics
- Data the model may use
Acceptance
- Format rules
- Length caps
- Pass/fail checks
Specific enough
- Eval can score outputs.
- Fewer clarifying retries.
- Safer for automation.
Over-specified
- Brittle to valid variants.
- Ignores edge cases.
- Reads like one golden sample.
“More adjectives make prompts clearer.” Stacking “clear, concise, insightful, world-class” adds noise. Prefer measurable constraints (counts, schemas, allowed labels) over praise words.
Knowledge Check
- Short Answer: What does “summarize this” leave unspecified? Answer: Length, audience, focus, and success criteria.
- True/False: “Be professional” is a fully measurable constraint. Answer: False.
- Multiple Choice: Best rewrite of “keep it short”: (a) make it nice, (b) max 60 words, (c) use vibes. Answer: (b).
- Short Answer: Name one risk of over-specificity. Answer: Brittleness / overfitting to one golden example.
- True/False: Clear prompts are easier to evaluate automatically. Answer: True.
- Multiple Choice: Vague verbs force the model to: (a) invent requirements, (b) train weights, (c) skip tokenization. Answer: (a).
- Short Answer: Give a clearer alternative to “fix the code.” Answer: e.g., Fix the null crash; no API changes.
- Short Answer: What belongs in an acceptance checklist? Answer: Format, length, and pass/fail rules (or similar).
- Multiple Choice: Stacking praise adjectives usually: (a) guarantees quality, (b) adds noise, (c) reduces tokens always. Answer: (b).
- True/False: Specificity should still leave room for valid output variants. Answer: True.
Key Takeaways
- Replace vague verbs with concrete actions and boundaries.
- State length, format, and decision rules in measurable terms.
- Write for evaluation: if you cannot score it, it is not clear enough.
- Avoid overfitted micro-rules that break on valid alternatives.
- Next: Instruction Ordering.
Hands-on idea: Score five student rewrites with a tiny rubric (format / length / decision completeness).
Discussion prompt: When is “use judgment” acceptable, and how do you still constrain failure modes?
Recap: Clear prompts make success observable. Continue with Instruction Ordering.