A bicycle-share depot wants one model that can look at a photo of a bent wheel and read the mechanic's typed note, then draft a shop email. They do not want a text-only chat, and they do not want a utility that only extracts printed letters from the photo. Which model type fits?
Select an answer to reveal the explanation.
Short Explanation
Think of one mechanic who looks at the bent-wheel photo and the typed note, then drafts the shop email. That is multi-modal: more than one input type. A text-only chat cannot see the photo, and OCR only lifts printed letters.
Full Explanation
Looking at a bent-wheel photo, reading a mechanic's typed note, and drafting a shop email in one pass requires a multi-modal model that handles more than one input or output type. Vision and language must be consumed together so the email can reference both the damage seen and the written diagnosis. The bicycle-share depot explicitly rejected text-only chat and rejected a utility that only extracts printed letters.
A text-only LLM cannot use the photo. It might draft email prose from the note alone, but it cannot ground statements in the bent-wheel image the depot wants included in the workflow.
A single-purpose OCR utility only lifts printed letters from the image. OCR does not understand a typed mechanic note as chat context or draft a coherent shop email that fuses visual and textual evidence.
A time-series forecast of next month's flat tires predicts a future count. It does not inspect a current photo or compose repair-shop correspondence.
Exam caveat: multi-modal capability still needs operational guardrails—wrong visual grounding can invent damage not present in the photo—so human review may remain appropriate for safety emails.
Operational check: test the depot workflow with paired photo-plus-note cases, including conflicts where the note and image disagree, and confirm the draft email flags uncertainty rather than silently inventing a repair story.