Zero-shot or few-shot CoT for a bank's KYC risk memos — how do you choose?

## Why this is a judgment question There is no universally right answer, and an interviewer asking it is checking whether you can separate the strands: reasoning quality, recurring cost, output consistency, and regulatory data handling. A candidate who answers only on accuracy has missed most of the question. ## Strand one: does the demonstrated reasoning actually help? Risk-memo generation is a house-procedure task — a specific ordering of checks, specific thresholds, a specific way findings are worded. That is exactly the profile where worked examples usually help, because a trigger phrase cannot convey a bank's internal method. But "usually helps" is a hypothesis to test, not a conclusion. Build an eval set from real historical cases with analyst-written outcomes, run a zero-shot variant and a few-shot variant, and compare on the dimensions that matter separately: correctness of the risk determination, coverage of required checks, and format conformance. Frequently the exemplars turn out to be carrying format rather than method — in which case a written output template achieves the same result for a fraction of the tokens and none of the data risk. ## Strand two: the token economics Exemplar tokens are input tokens on every call. A prompt carrying four full worked memos is not a one-time setup cost; it is a per-request cost multiplied by volume for as long as the prompt lives. On a batch path processing overnight review queues, that is a budget line someone will eventually ask about. Prefix caching changes the arithmetic — a stable exemplar block shared across requests can be billed at a reduced rate after the first call — but it does not make the tokens free, does not help when the prompt prefix changes often, and does nothing at all about what the exemplars contain. Treat caching as a reason cost stops being the *deciding* factor, not as a reason to stop counting. There is a second, less visible cost: context occupancy. Every token of exemplar is a token unavailable for the case file, the policy extract, or the prior-review history. On long inputs that tradeoff bites before the invoice does. ## Strand three: what the exemplars contain This is the strand that makes the KYC setting different from a generic prompt-tuning exercise. The instinctive way to write a good exemplar is to take a real, well-handled case and write up its reasoning. That decision quietly means: - Customer personal data is transmitted to the model provider on **every** request, not only on requests about that customer. - It appears in provider-side logs, in your own request tracing, in eval fixtures, in prompt-version history in source control, and in any debugging capture. - The subject of those exemplars has no relationship to the request being processed, so there is no processing basis tied to the request itself. - Data-subject rights and retention rules now apply to a prompt template, which is not where anyone expects to look for personal data. The practical answer is **synthetic exemplars derived from the policy** — invented customers, invented identifiers, reasoning written to demonstrate the escalation logic in the written procedure. They are usually as effective, because what you needed to transfer was method, not the specific customer. Where realism genuinely matters, aggressive redaction plus a review step is the fallback, but redaction is a control that must be verified rather than assumed. ## The recommendation and how to defend it A defensible position for a regulated memo generator: start with a strict output template and zero-shot reasoning; measure; add the smallest number of *synthetic* worked examples that closes a measured gap; re-measure; and treat the exemplar block as reviewed, version-controlled artifact with a named owner, because it now encodes bank policy. Never put real customer records in it. Say the quiet part out loud in the interview: format consistency is not optional here — a memo that a reviewer, an auditor and a downstream system all have to read needs a fixed shape — but format consistency can be bought with a template, and it does not require handing the model somebody's file. ## What else this touches Auditability: if a determination is challenged, you need to be able to say what the prompt contained at that moment, which means versioning the exemplar block alongside the code. Change control: editing an exemplar changes decision behaviour and should go through the same review as changing the policy it encodes. And human review: for adverse determinations, the model's memo is an input to an analyst, not the decision itself — which is the control that makes the rest of the tradeoffs survivable.