Positive instructions say what to do; negative instructions fence failure modes. Used well, they cut common bugs. Used poorly, they become a laundry list that the model ignores—or paradoxically highlights forbidden content. This lecture balances “do” and “don’t” after templates are in place.
Learning Objectives
By the end of this lesson, students should be able to:
- Write negatives that target observed failure modes.
- Prefer positive replacements when clearer than bans.
- Avoid contradictory do/don’t pairs.
- Limit negative lists to high-severity items.
- Pair negatives with examples of correct behavior.
- Test whether negatives actually reduce the failure.
Negative instructions are explicit prohibitions (“do not…”) that constrain disallowed content, behaviors, or formats. They complement positive task statements and are most effective when few, specific, and tied to real errors.
When Negatives Help
| Use a negative when… | Prefer a positive when… |
|---|---|
| A specific bad pattern keeps recurring | You can describe the desired pattern cleanly |
| Safety / legal lines must never be crossed | Style choices have many valid forms |
| Output must omit fields (no preamble) | You can show the exact schema |
| Untrusted context may contain commands | Fencing + “treat as data” already covers it |
Before / After
Before (weak): endless don’ts, no positive target.
After (strong): positive target + few high-value negatives.
Design Rules
Keep short
- Top 3–7 bans
- Severity first
- Drop unused bans
Be precise
- Name the pattern
- Show a counterexample
- Avoid vague “don’t be bad”
Resolve conflicts
- Do vs don’t clashes
- Use priority language
- Re-test both sides
“Listing every possible bad thing makes the model safe.” Long negative catalogs dilute attention and still miss novel failures. Prefer tight bans plus positive schemas, retrieval grounding, and code-side validators.
Knowledge Check
- Short Answer: What are negative instructions? Answer: Explicit prohibitions that ban disallowed behaviors or formats.
- True/False: Longer don’t lists always increase safety. Answer: False.
- Multiple Choice: Prefer positives when: (a) the desired pattern is clear, (b) you want contradictions, (c) eval is banned. Answer: (a).
- Short Answer: How many high-value bans should you keep roughly? Answer: About 3–7 (a short list).
- True/False: Negatives should target observed failure modes. Answer: True.
- Multiple Choice: “Do not invent facts” pairs well with: (a) refuse/ask rules, (b) deleting context, (c) raising temperature blindly. Answer: (a).
- Short Answer: Why pair negatives with good examples? Answer: To show the allowed alternative, not only the ban.
- Short Answer: What should you do if do and don’t conflict? Answer: Resolve with priority language and re-test.
- Multiple Choice: Code-side validators: (a) replace all prompting, (b) complement negatives for hard guarantees, (c) train embeddings. Answer: (b).
- True/False: Vague bans like “don’t be bad” are precise enough. Answer: False.
Key Takeaways
- Use short, specific negatives tied to real failures.
- Lead with positive targets whenever possible.
- Resolve do/don’t conflicts explicitly.
- Back hard rules with validators, not bans alone.
- Next: Output Format Specification.
Hands-on idea: Trim a 20-line don’t list to five severity-ranked bans and measure format compliance.
Discussion prompt: Which negatives belong in the prompt vs only in post-processing filters?
Recap: Negatives fence errors; positives define success. Continue with Output Format Specification.