Few-Shot and Chain-of-Thought
Explore how to apply few-shot prompting and chain-of-thought reasoning to improve AI model outputs in ticket classification tasks. Understand when to use examples to guide label formatting and when to apply reasoning scaffolds for consistent intermediate decisions. Learn to identify and address production failures like label drift and cost inflation, and adapt strategies for extraction tasks.
A support system receives ticket text and must output one label from BILLING, BUG, FEATURE, ACCOUNT, OTHER plus a one-sentence rationale. A plain instruction often fails in visible ways, with outputs like Billing Issue instead of BILLING, or a rationale that turns into multiple paragraphs, or two labels when the text mentions both an error and a refund request. Those failures are not subtle, and they break downstream routing.
With that single task in view, two levers change behavior in different ways. Few-shot prompting adds examples so the output matches our label set and formatting, while a reasoning scaffold adds an intermediate structure so the model is more likely to make the same internal decision steps on similar inputs. Neither is guaranteed to improve every run, so we compare them by observing label drift, formatting drift, and rationale length.
The table below shows where each lever helps and what it costs.
Prompt Style | Output Consistency | Token Cost | Brittleness to New Cases | Risk of Unwanted Rationale Text |
Zero-shot | Low | Lowest | High | Low |
Few-shot | High | Higher | Medium | Low |
Reasoning scaffold | Medium | Highest | Low | High |
A practical rule holds across models. Use few-shot examples when the main failure is schema and boundary coverage, and use a reasoning scaffold when the main failure is inconsistent intermediate decisions such as choosing between BUG and ACCOUNT based on whether the user can log in.
Setting rules using few-shot examples
Once we know the failure is label or format drift, examples work best when they teach the output ...