A city bike-share tester asks why the model writes the next sentence of a defect report one piece at a time. What best explains transformer inference at tester depth?
Select an answer to reveal the explanation.
Short Explanation
It is more like finishing a song by guessing the next note from patterns than reading a sealed answer key. Transformers generate by predicting the next token. Plausible continuation is not a guaranteed correct oracle for testware.
Full Explanation
At tester depth, transformer inference predicts the next token from learned relationships among tokens, yielding a statistically plausible continuation rather than a certified fact. That is why a city bike-share defect report can be written one piece at a time without looking up a sealed sentence from an oracle. Civic testers must treat fluent continuations as drafts whose claims still need the open defect, product basis, and human judgment.
Symbolic rule-table lookup fails because transformers are not executing an editable if-then store of exact defect sentences. Always retrieving a verified expected result from the test-management tool fails because inference is generative prediction, not an automatic TM oracle fetch. Interpreting inference as “retrain a classical ML classifier on every new defect note” fails because LLM generation uses the pre-trained generative path, not per-note classical retraining.
Exam caveat: statistically plausible ≠ correct against the test basis. Fluency is expected from next-token prediction; verified expected results still come from the basis and review, especially for citizen-facing bike-share defects.
Operational check: generate a short bike-share defect continuation; compare each factual claim to the open defect and product basis; reject any municipal process that treats next-token fluency as an automatic oracle pass or as a substitute for the test-management expected result.