Few-shot examples steer the output

Showing the model a few input and answer pairs teaches it the format and the labels, often better than describing them.

The idea

Few-shot prompting means putting a handful of worked examples in the prompt: an input followed by the answer you want. The model continues the pattern, so it copies the format, the label names and the style. Without examples (zero-shot) it may answer correctly in a chatty, unpredictable shape that your code cannot rely on.

Code

public record Example(string Text, string Label);

public static class TicketLabeler
{
    public static async Task<string> ClassifyAsync(ILlmClient llm, string query)
    {
        var sb = new StringBuilder("Label each message with one word.\n\n");
        var examples = new[]
        {
            new Example("app crashes on login", "BUG"),
            new Example("please add dark mode", "FEATURE"),
            new Example("reset my password?", "QUESTION"),
        };
        foreach (var e in examples)
            sb.Append($"Message: {e.Text}\nLabel: {e.Label}\n\n");
        sb.Append($"Message: {query}\nLabel:");
        string label = await llm.CompleteAsync(sb.ToString());
        return label.Trim();
    }
}

Tips

• Examples teach format and labels very strongly, so they must be correct and consistent. A wrong or inconsistent example gets copied.
• Pick varied examples, including a tricky or borderline case, not three near-duplicates.
• Examples cost tokens on every request. Use as few as work, and stop adding them once more examples stop helping.
• Ending the prompt with "Label:" makes the next token the label itself, which is exactly the thing we want.

In the .NET library

Keep the examples in data, not scattered string literals, for example a list loaded from a file or database. Then you can add a new tricky case when a user finds one, and re-run your evals.