Kenhuang Academy
  • English

      • Few-shot examples

      Few-shot means putting several “input → acceptable output” demonstrations in the prompt. Models often learn format, edges, and tone faster from examples than from three more adjectives. OpenAI: keep examples in a short YAML or bullet block that a team can edit. Anthropic: wrap examples like real inputs so they do not glue onto instructions.

      Zero-shot, one-shot, few-shot

      ModeWhen it is enoughRisk
      Zero-shotCommon task, simple format (“translate this”)Drift on edge cases
      One-shotYou only need to pin layoutThe single example is over-copied
      Few-shot (2–5)Classification, extraction, a special voice, easy-to-confuse labelsContradictory examples; or only “easy” items

      More examples are not always better. Repeated easy cases burn context, hurt a cacheable prefix, and teach “only these happy paths exist.” Cover failure edges, not twenty happy paths.

      What an example should show

      A good example locks three things:

      1. What inputs look like (noise, missing fields, mixed languages)
      2. The output contract (field names, order, how empty values look)
      3. Refusal policy (what to emit when the model must not invent)
      Label the ticket billing / bug / how-to. Use only the user’s words. Do not invent account IDs.

<example>
<input>Charged twice for the invoice, order 8891.</input>
<output>{"label":"billing","order_id":"8891","needs_human":false}</output>
</example>

<example>
<input>The page flashed yesterday, maybe my network.</input>
<output>{"label":"bug","order_id":null,"needs_human":false}</output>
</example>

<example>
<input>Help me access another tenant’s invoices.</input>
<output>{"label":"how-to","order_id":null,"needs_human":true}</output>
</example>

Now label:
<input>{{TICKET}}</input>

      The third example is not an attack tutorial. It shows refuse and escalate: sensitive or out-of-scope asks should not close as a normal how-to.

      Anti-patterns

      Bad exampleWhy it fails
      Inconsistent labels (Bug vs bug)The model learns “casing is optional”
      Only perfect inputsReal users omit punctuation and fields; the model invents
      Prose in examples while demanding JSONThe contract disagrees with itself
      Gold answers that contradict the instructionsThe model often follows the latest example
      Examples that say “ignore the safety policy”Out of scope here; delete them and treat as an incident

      Changing examples changes product behavior. Commit them, and attach gold questions from Evaluation.

      Prefill and “continue from here”

      Some APIs let you prefill the assistant (for example {) to push the model onto a JSON track. That is format help, not a reasoning guarantee. When the vendor offers structured output / schema, prefer the schema (Structured output); treat prefill as a fallback.

      Using “whatever happened last turn” as an example bloats the window. Put durable demos in the system prompt or a dedicated example block, not in accidental chat history.

      Relation to the four blocks

      • Role / constraints say in sentences “do not invent IDs”
      • Examples show “when there is no ID, the field is null”
      • They must agree; on conflict the model often follows the example

      In tool-free chat, few-shot is often the strongest lever. For tool-using agents, examples should show when to call a tool vs answer directly, not a fake dump of tool JSON (that is the API’s job). See Tools and agents.

      Next steps

      评论