检索日志很干净。针对你手动标注的查询集，Recall@10 在几个月内都没有出现退化。答案质量仪表盘显示忠实度（faithfulness）保持在 90% 以上。然后，一位客户向你的支持代理粘贴了一个问题，金标准文本（gold passage）就在组合提示词的 12 个位置中的第 7 位，而模型的回答却好像从未检索到它一样。
检索团队会告诉你该分块（chunk）确实在那里。提示词团队会告诉你提示词是正确的。两者在技术上都是对的。模型关注了前一千个标记（tokens），关注了最后一千个标记，却略过了答案所在的中间地带。你的流水线正面临着一种位置注意力偏置（positional attention bias），没有哪个团队对此负责，没有哪个仪表盘在追踪它，也没有哪个基准测试能捕捉到它。
长上下文与 RAG 的经济学在两年内翻转了两次，而在那两个窗口期中选择了某种架构的团队，现在正处处支付着错误的代价。在 2024 年，趋势是将一切都塞进上下文窗口，因为窗口在不断扩大，而每 token 的价格在持续下降，因此检索流水线被斥为过时的繁琐工作。在 2025 年，共识发生了反转：关于“上下文腐烂”的研究表明，在百万级 token 的提示词中，窗口中部的有效召回率大幅下降，全窗口调用的延迟变成了用户体验问题，且账单变得非常惊人，于是检索技术重新得到了重用。到 2026 年，正确的答案不再是任何一种口号。它是一个在设计阶段做出的基于单个功能的决策，并记录下四个维度的权衡，因为为整个产品选择单一架构，是让每个功能同时出错的低成本方式。
一直困扰着团队的思维模型是将长上下文 vs RAG 视为路线图上的承诺，而不是针对每个界面的选择。你阅读了一篇有影响力的博客，选边站队，雇佣了擅长那一边的工程师，编写了一份将其规范化的平台文档，现在每个新功能无论是否合适，都采用了相同的架构。需要新鲜数据的功能忍受着陈旧的上下文。需要可扩展语料库的功能为他们永远不会使用的检索基础设施买单。需要引用来源的功能在发布时却缺失了这一项。这些都不是 bug。它们是将功能级决策视为产品级决策所带来的必然代价。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
