7 篇博文 含有标签「ai-architecture」

长上下文与 RAG 的经济学在两年内翻转了两次，而在那两个窗口期中选择了某种架构的团队，现在正处处支付着错误的代价。在 2024 年，趋势是将一切都塞进上下文窗口，因为窗口在不断扩大，而每 token 的价格在持续下降，因此检索流水线被斥为过时的繁琐工作。在 2025 年，共识发生了反转：关于“上下文腐烂”的研究表明，在百万级 token 的提示词中，窗口中部的有效召回率大幅下降，全窗口调用的延迟变成了用户体验问题，且账单变得非常惊人，于是检索技术重新得到了重用。到 2026 年，正确的答案不再是任何一种口号。它是一个在设计阶段做出的基于单个功能的决策，并记录下四个维度的权衡，因为为整个产品选择单一架构，是让每个功能同时出错的低成本方式。

一直困扰着团队的思维模型是将长上下文 vs RAG 视为路线图上的承诺，而不是针对每个界面的选择。你阅读了一篇有影响力的博客，选边站队，雇佣了擅长那一边的工程师，编写了一份将其规范化的平台文档，现在每个新功能无论是否合适，都采用了相同的架构。需要新鲜数据的功能忍受着陈旧的上下文。需要可扩展语料库的功能为他们永远不会使用的检索基础设施买单。需要引用来源的功能在发布时却缺失了这一项。这些都不是 bug。它们是将功能级决策视为产品级决策所带来的必然代价。

LLM 功能的威胁模型过度关注三种失败模式：提示词注入、用户数据外泄和未经授权的工具调用。但还有一种更隐蔽、成本更低且很少出现在事后分析报告（因为没人提交过相关报告）中的攻击——提示词提取（prompt extraction）。对抗性用户（有时是竞争对手，有时是充满好奇的研究人员）只需经过几轮对话，就能诱导模型背诵出其系统提示词。那些编码了你团队产品行为、拒绝策略、检索支架和品牌语调的精心调优的指令，不到一周就会出现在公共 GitHub 仓库中。

这类仓库已经存在了。一个广为流传的 GitHub 项目专门追踪从 Claude、ChatGPT、Gemini、Grok、Perplexity、Cursor 和 v0.dev 中提取的系统提示词——随着新模型版本的发布而更新，通常在发布后的几小时内就会同步。Anthropic 完整的 Claude 提示词（包括工具说明）超过 24,000 个 token，而且你可以直接阅读。最热衷于对提示词保密的公司，往往也是其提示词泄露最频繁的公司，因为这类公司的攻击者动力最强。

你发布的每一个 AI 功能，在成为产品决策之前，都首先是一个架构选择：这个模型调用是发生在用户的请求链路中，还是在用户无需等待的地方运行？这个选择通常由编写第一个原型的人做出，之后便不再被审视，并默默地决定了该功能在余下生命周期中的 p99 延迟。当事后分析（Post-mortem）询问为什么生产环境仪表盘在每周一上午 10 点变得无法使用时，答案几乎总是：某些本应属于冷路径（Cold-path）的东西被焊死在了热路径（Hot-path）中——而在 p50 时表现良好的模型，在流量扇出（Fan out）时，其 p99 的表现会变得极具灾难性。

热路径与冷路径的区别比 LLM 还要早。CQRS、流式架构、Lambda 架构——它们都在“必须立即响应”和“可以最终送达”之间划定了相同的界限。AI 工作负载的不同之处在于，走错方向的代价比以前高出了一个数量级。一个耗时 50 ms 的同步数据库查询变成 200 ms 是一次回归（Regression）。而一个在 p50 时耗时 1.2 秒的同步 LLM 调用在 p99 时变成 11 秒，则是你无意中做出的一项商业决策。

人们的本能总是去选择最大的模型。GPT-4o、Claude Opus、Gemini Ultra——选一个前沿模型，把问题丢给它，然后寄希望于强大的能力来弥补架构上的懒惰。这在演示中行得通，但在生产环境中会失败。

2025 和 2026 年，那些交付最可靠 AI 系统的团队并没有使用单一模型。他们将三个、四个甚至五个专业化模型组合成流水线，每个组件只做好一件事。分类器负责路由，生成器负责产出，验证器负责检查。最终得到的系统不仅优于任何单一模型，而且成本只是"万事皆用前沿模型"方案的一小部分。

每个人都在讨论如何避免 LLM 供应商锁定。建议通常归结为"使用抽象层"——仿佛把 openai.chat.completions.create 换成 litellm.completion 就能解决问题。但事实并非如此。API 调用是最简单的部分。真正的锁定是隐形的：它存在于你的提示词、评估数据、工具调用假设，以及你不知不觉围绕特定行为设计的系统中。

供应商可移植性不是非黑即白的。它是一个连续谱系，大多数团队比他们认为的离可移植端更远。好消息是，实现真正可移植性的模式已经很成熟——只是比引入一个封装库需要更多的纪律性。

当一个购物助手向一位两年前曾提及怀孕的用户推荐婴儿产品时，系统没有抛出任何异常。它完全按照设计运行。LLM 返回了一个充满信心的 HTTP 200 响应。问题出在数据上——一段从未被清除的过期记忆——而且它完全隐形，直到一位用户投诉才被发现。这就是潜伏在有状态 AI 系统中的幽灵，其行为与你习惯调试的 Bug 截然不同。

有状态与无状态 AI 功能之间的抉择，表面上看起来异常简单。但在实践中，这是你在构建 AI 产品时最早做出的架构决策之一，其影响会贯穿存储层、调试工具链、安全态势和运营成本。大多数团队是在不经意间做出这个决定的——盲目沿用某种模式，却未仔细审视其权衡取舍。本文旨在帮助你做出有意识的选择。

在为你的智能体（agent）采用推理模型之前，有一个数字值得你深思：对于一个标准的快速模型，单次查询仅需 7 个 token，但在 Claude extended thinking 中则需要 255 个 token，而在配置激进的推理模型中更是高达 603 个 token。对于孤立的聊天机器人查询来说，这还是可以接受的。但在一个每项任务调用模型 12 次的智能体循环中，你支付的不只是 10 倍的溢价 —— 而是 10 倍溢价乘以 12，并且随着每一轮重新喂入不断增长的上下文窗口，成本还会进一步复现。账单带来的“惊喜”扼杀智能体项目的速度往往比准确性问题还要快。

问题不在于推理模型是否更好。在处理困难任务时，它们显然更出色。问题在于，推理模型是否更适合你的特定工作负载，是否更适合你在智能体循环中的特定位置，以及其提升的幅度是否足以抵消成本。大多数团队在这两个方向上都做出了错误的回答 —— 他们要么统一采用推理模型（在不需要它们的任务上浪费预算），要么完全避开它们（错失了在需要它们的任务上提升准确性的机会）。