Meridian Line's crane maintenance logs use a dense shorthand ('spdr hyd lk stbd') that a general-purpose foundation model normalizes correctly about 70% of the time even with careful few-shot prompting, and the team has thousands of labeled shorthand-to-plain-English pairs from past triage tickets. What is the strongest next step to raise accuracy?
Select an answer to reveal the explanation.
Short Explanation
Few-shot prompting is flash cards you show every single time; fine-tuning is actually teaching the vocabulary. When you have thousands of labeled examples and a narrow, repeated pattern that prompting keeps missing, that's the fine-tuning case, not a prompt-engineering case.
Full Explanation
Fine-tuning is the right tool when a task involves a narrow, well-defined transformation with a large labeled dataset and general prompting has plateaued below the needed accuracy -- training on the shorthand-to-plain-English pairs lets the model internalize crane-maintenance vocabulary and abbreviation conventions directly into its weights, rather than relying on a handful of examples re-supplied in every prompt, which also shortens and cheapens each request since less context is needed. Continuing to add few-shot examples has diminishing returns once a task-specific pattern is this consistent and well-represented in labeled data, and it grows every prompt's length and cost without addressing the underlying gap. Switching to a smaller, cheaper model addresses cost, not the stated accuracy problem, and a weaker general model is not more likely to have learned crane shorthand than the current one. Abandoning normalization and having the agent reason over raw shorthand pushes the ambiguity downstream into every subsequent step of triage, which does not solve the accuracy problem, it just relocates it. Exam framing: selecting an appropriate model -- including when fine-tuning beats prompting a general foundation model -- is explicitly part of the Application Development objectives.