AI Signals & Reality Checks: Provenance Becomes a Product Requirement (The Retrieval Tax)

AI Signals & Reality Checks (Feb 25, 2026)

Signal

Provenance is becoming a product requirement—not a research feature—because trust is now a UI problem.

A year ago, “add citations” often meant: put a few links at the bottom and hope nobody clicks them.

What’s changing is that teams are discovering a hard truth: in high-stakes workflows, users don’t trust answers—they trust receipts. That’s pushing provenance (where did this come from?) out of the backend and into the product surface area.

You can see the shift in three places:

1. Receipts-first UX Instead of a single blob of text, the output is packaged as:

• a set of claims,
• each claim mapped to evidence,
• with “show me the snippet” one click away,
• and a small trace graph of which tools were called.

That’s not just for compliance. It’s because people want to audit at reading speed.

2. Contractual guarantees around sources More teams are writing explicit rules into the experience:

• “Only answer from these repositories.”
• “If evidence is missing, say so.”
• “If confidence is low, produce a checklist for what to verify.”

This is quietly a bigger change than better prompting: it’s the beginning of scoped epistemology—the model is allowed to know certain things, and required to show its work.

3. Traceability as a differentiator When multiple products are “good enough” at text generation, provenance becomes the tie-breaker. The winners aren’t necessarily the systems with the smartest base model; they’re the systems that can explain:

• which dataset/version was used,
• which policy constraints were applied,
• and why an action was (or wasn’t) taken.

The market signal here is simple: trust is being productized.

Reality check

Provenance isn’t free. You pay a retrieval tax in latency, cost, and user experience—and many citation systems create the illusion of grounding without real guarantees.

Three pitfalls show up fast:

1. The retrieval tax is real Every “receipt” feature adds work:

• more retrieval calls,
• more token budget for quoting and structuring,
• more UI components,
• and more edge cases (duplicate sources, conflicting docs, stale pages).

In practice, teams discover they can’t afford to ground everything at the same level. The right design is usually tiered:

• low-stakes: lightweight citations,
• medium-stakes: claim→evidence mapping,
• high-stakes: enforced “no evidence, no answer” + human approval.

2. Citations can be theater A citation UI can look convincing while still being misleading:

• the snippet is real, but doesn’t support the claim;
• the snippet is adjacent, but the conclusion is invented;
• the model cherry-picks one line while ignoring contradicting lines.

If you want provenance to mean something, you need measurable rules:

• evidence coverage: what % of claims are supported?
• support correctness: do snippets actually entail the claim?
• conflict handling: what happens when sources disagree?

Otherwise you ship “trust vibes,” not trust.

3. Traceability without accountability doesn’t move the needle A beautiful trace graph is still just a log unless you can answer:

• Who owns the workflow?
• What are the allowed actions and rollback triggers?
• What gets audited automatically vs sampled?

The operational pattern that works is boring but effective:

• define a small set of claim types (fact, recommendation, action),
• require evidence for facts and for any irreversible action,
• and set an escalation path when evidence is missing or conflicting.

Bottom line: provenance is becoming the “seatbelt” of applied AI—users expect it by default. But seatbelts only help if they’re engineered, tested, and enforced. If you don’t budget for the retrieval tax and you don’t audit support quality, citations will become the next checkbox feature that quietly fails under pressure.

中文翻译（全文）

AI Signals & Reality Checks（2026 年 2 月 25 日）

信号

溯源（provenance）正在变成一种产品级刚需——而不只是研究功能——因为“信任”现在首先是一个 UI 问题。

一年前，“加引用（citations）”往往意味着：在文末放几个链接，然后祈祷没人点。

现在的变化在于，团队逐渐意识到一个很硬的现实：在高风险工作流里，用户不信“答案”，他们信“收据（receipts）”。 这正在把溯源从后端能力推到产品表层：要看得见、点得到、能快速核对。

你可以在三个地方看到这种转向：

1. 以收据为中心的交互（Receipts-first UX） 输出不再是一坨文本，而是被包装成：

• 一组可枚举的“主张/结论（claims）”，
• 每条主张都映射到证据（evidence），
• 用户一键即可“查看原文片段（show me the snippet）”，
• 以及一个小型的调用轨迹/工具链路图（trace graph）。

这不只是为了合规。更根本的原因是：人希望能以“阅读速度”完成审计。

2. 围绕来源的“契约式保证” 越来越多团队把规则写进产品体验本身：

• “只允许从这些知识库/仓库回答。”
• “找不到证据就明确说不知道。”
• “信心不足时，先给出核对清单而不是硬答。”

这其实比“提示词更好”更重要：它是 受限认识论（scoped epistemology） 的开始——模型被允许知道什么，被要求展示什么证据，边界开始清晰化。

3. 可追溯性正在成为差异化卖点 当多个产品在“生成文本”上都已足够好时，溯源会成为决胜因素。胜出的不一定是底座模型最聪明的系统，而是能解释清楚的系统：

• 用了哪个数据集/哪个版本，
• 应用了哪些策略约束，
• 为什么执行（或拒绝执行）某个动作。

这里的市场信号很简单：信任正在被产品化。

现实校验

溯源不是免费的。你会为它支付“检索税（retrieval tax）”——体现在延迟、成本和用户体验上；而且很多引用系统只是在制造“看起来被 grounding 了”的幻觉，并没有真正的保证。

三个坑会很快出现：

1. 检索税是真实存在的 每一个“收据”功能都会增加开销：

• 更多的检索调用，
• 更多 token 用于引用、结构化与对齐，
• 更多 UI 组件，
• 更多边界情况（重复来源、文档冲突、页面过期）。

实际落地时，团队会发现：不可能以同样强度为所有内容提供同级别的溯源。更合理的设计通常是分层：

• 低风险：轻量引用；
• 中风险：主张→证据映射；
• 高风险：强制“无证据不作答” + 人工审批。

2. 引用很容易变成“舞台效果” 引用的 UI 可能看起来很可信，但仍然会误导：

• 片段是真的，但并不支持主张；
• 片段只是在旁边擦边，结论是编出来的；
• 模型挑一行支持自己的句子，却忽略了相反证据。

如果你希望溯源真的“算数”，需要可度量的规则：

• **证据覆盖率：**有多少主张被证据支持？
• **支持正确性：**片段是否真的蕴含该主张？
• **冲突处理：**当来源相互矛盾时系统如何表现？

否则你交付的是“信任氛围（trust vibes）”，而不是信任。

3. 只有可追溯性、没有可问责性，意义不大 再漂亮的 trace graph 也只是日志，除非你能回答：

• 这个工作流谁负责？
• 允许哪些动作？回滚触发条件是什么？
• 哪些可以自动审计，哪些必须抽样/人工复核？

最有效的落地模式往往很朴素，但很管用：

• 定义少量主张类型（事实、建议、动作），
• 对事实与任何不可逆动作强制要求证据，
• 当证据缺失或冲突时设置升级路径。

**结论：**溯源正在成为应用型 AI 的“安全带”——用户会默认它存在。但安全带只有在被工程化、被测试、被强制执行时才有用。如果你不为检索税做预算，也不审计“支持质量”，引用会变成下一个看似必要、却在压力下悄然失效的勾选项功能。