Route the Request

A teammate brings you a model problem, and the meeting wants a decision today: better prompt, retrieval, or fine-tune. Interviewers ask it in exactly that phrasing, and the defensible answer is not a vibe; it is a fixed route rule you can state before anyone opens a laptop. The rule runs cheapest-first. A carefully written prompt, one that states the format and shows worked examples, is the cheapest thing that can work, so when one already does the job, everything else is spending to feel busy. When the problem is knowledge that goes stale, facts that stop being true within days, no prompt can carry them, because the person writing the prompt does not know next week either, and training bakes in a snapshot that is dated the day it finishes; that is exactly what retrieval, the build-time habit of looking the current facts up at question time, is for. When the problem is a habit, a repeating style or format that serious prompt work demonstrably could not fix, fine-tuning is the tool, and it is only rational once you hold enough labeled examples, texts paired with the answer that was wanted, for the run to learn the habit instead of memorizing your few. The bar this route uses is one thousand cleaned examples. Implement decide_route(labeled_examples, drift_days, prompt_already_works): labeled_examples is the count of cleaned examples you can train on; drift_days is how many days your facts stay true before they change, and use 365 for knowledge that effectively never moves; prompt_already_works is a boolean, true when prompt work already does the job. Return one string, decided in this fixed order: prompt when prompt_already_works is true; otherwise retrieval when drift_days is at most 7; otherwise finetune when labeled_examples is at least 1000; otherwise collect-more-data. The fixed order is the interview answer, because checking the expensive tool first is how tuning projects get funded for problems a rewrite would have solved.