Large language models are persuasive writers. That is a feature in creative tools and a liability in systems that imply factual grounding. The squeeze arrives when a stakeholder reads a confident paragraph and treats it as audit-ready, while the engineering reality is that retrieval may be empty, sources may conflict, or the policy layer has not yet decided what the product is allowed to say.
Separate rhetoric from provenance
A practical habit is to label outputs with their evidence class: quoted from corpus, synthesized from multiple chunks, or speculative with no supporting chunk. Users do not need a lecture on embeddings—they need a consistent vocabulary. When you pair that with a written truth contract, support and legal can reason about the same object engineering uses in tests.
Why evals miss this failure mode
Offline scores often reward coherent prose. Production failures show up as “wrong but plausible”—exactly where a layered eval stack should combine deterministic checks with sampled human review. If your suite only asks whether the answer “sounds right,” you are still optimizing fluency.
Telemetry you can defend in a postmortem
When something goes wrong, screenshots are not enough. You want traces that show retrieval payloads, model ID, and policy decisions—patterns we outline in structured logging for LLM apps. That is how you prove whether the model hallucinated, the index was stale, or the user asked something out of contract.
UX patterns that signal uncertainty
Inline citations, collapsible source lists, and explicit “I could not find this in your documents” states reduce the rate at which users mistake polish for proof. Those patterns should be designed alongside hardening so they are regression-tested like any other UI contract—not bolted on after a legal escalation.
Sales and support as truth amplifiers
When marketing copy promises more than the corpus can support, fluency problems become revenue problems: demos win deals that engineering cannot fulfill. Run joint reviews with GTM on example outputs from pilots, using the same evidence classes you use in product.
Multilingual and domain jargon
Fluency varies by language: a model may sound native in English and brittle in Spanish, or vice versa. If your contract assumes parity across locales, you need parallel eval slices per language—not a translated rubric pasted from headquarters. The same applies to vertical domains: legal, medical, and financial phrasing carries implied warranties; tune disclosure copy and retrieval scope together so fluent tone does not imply professional certification the product never had.
Anti-patterns we see in the field
- Screenshot reviews. Approving outputs from static images instead of traces—impossible to reproduce when users complain.
- “The model passed our vibe check.” Subjective thumbs-up without schema or source checks—see hardening for what to automate first.
- Confidence UI without provenance. Stars, thumbs, or “high confidence” badges that users interpret as factual certainty—clashes with oversight when escalations spike.
A practical review checklist
Before any release that widens audience, ask: (1) Can we show which chunks supported this answer? (2) What happens on empty retrieval? (3) Which trace fields will appear in the incident ticket? (4) Did policy sign off on the same wording users see? If any answer is fuzzy, you are still shipping fluency—not truth.
Fluency is cheap; alignment is negotiated. If you cannot state what counts as “true enough” for your surface, you do not have a product requirement—you have a tone of voice.