26 篇博文 含有标签「ai-infrastructure」

成本仪表盘一片绿意。自从级联路由（cascade router）上线以来，单次请求的支出下降了 62%。CFO 很开心。平台团队正在庆祝。而与此同时，你的 p95 延迟悄然上升了 40%，你最重要的客户刚刚流失，理由是“机器人在处理关键查询时变笨了”，而实验团队已经连续两周在追踪一个根本不存在的幻影回归（phantom regression）了。

这就是级联路由的可靠性陷阱。它是每一个“先尝试廉价模型，如果不成功再升级”架构的隐蔽失败模式，也是生产环境 LLM 系统中最少被讨论的二阶效应之一。成本上的收益是真实的、可衡量的，且易于归因。而可靠性上的损失则是弥散的、统计性的，几乎无法追溯到导致它们的路由。因此，成本上的胜利受到赞彰，可靠性上的损失被归咎于“模型变差了”，团队就这样把自己优化进了一个坑里。

打开任何 2024 年时代的 AI 功能链路追踪 (trace)，模型调用就像是一头巨鲸。八百毫秒的生成时间，包裹在检索、鉴权和数据库查询组成的薄壳中，后者的时间几乎可以忽略不计。那一年的每一个架构决策——缓存、预取、流式 UX——都是为了隐藏那头“巨鲸”。

现在，查看运行在 2026 年推理栈上的相同功能的链路追踪。那头巨鲸已经变成了一只海豚。缓存后的预填充 (prefill) 在 180ms 内返回第一个 token。解码 (decode) 以每秒 120 个 token 的速度流式传输。模型不再是慢节点。你自己的基础设施才是，而且大部分基础设施还没有意识到这一点。

这种顺序重排是今年最重要的性能转变，也是各团队一直反应不足的一个。现在，AI 请求的 p99 底限是由特征存储 (feature store) 调用、鉴权中间件以及那些一直都很慢的 Postgres 查询决定的——在模型占据九成预算时，没人关心这些。

大多数团队在发布智能体时，其威胁模型中都潜伏着一个沉默的假设：当模型调用工具时，返回的任何内容都是可以安全读取的。在这个剧本里，用户提示词是唯一的对手，而工具输出则被视为“仅仅是数据”——搜索结果、收件箱摘要、数据库行、RAG 分块、文件内容、网页抓取。正是这种观念导致提示词注入（prompt injection）不断出现在生产环境中。工具输出并不是数据。它们是进入规划器（planner）的另一个输入通道，拥有与用户提示词相同的权限，却完全没有被怀疑。

如果这种说法听起来有些抽象，请考虑 2025 年 6 月 Microsoft 365 Copilot 内部发生的事情。一名研究人员发送了一封带有隐藏指令的电子邮件；受害者从未点击过链接，从未打开过附件，甚至从未亲自阅读过该邮件。一个常规的“总结我的收件箱”查询请求 Copilot 读取该邮件。智能体忠实地执行了在正文中发现的指令，访问了 OneDrive、SharePoint 和 Teams，并在任何人察觉之前通过受信任的 Microsoft 域名外泄了组织数据。该 CVE（2025-32711，“EchoLeak”）获得了 9.3 的 CVSS 评分和服务器端修补，但这类漏洞并未消失。它不可能消失，因为生产环境中智能体上的每一个读取工具都是那个电子邮件收件箱的变体。

这篇文章讨论的是能让你摆脱困境的思维转变：停止将“提示词注入”视为用户输入问题，并开始将每一个工具输出视为一个恰好与你的系统提示词共享 Token 流的不可信渠道。

你的智能体调用了一个数据库工具。查询返回了8000个Token的原始JSON——嵌套对象、null字段、分页元数据，以及每一行都带有时间戳。智能体只需要其中三个字段。你刚刚为7900个噪音Token付了费，并把它们全部注入上下文，让它们与真正的任务争夺注意力。

这就是工具输出注入问题，也是智能体设计中最被低估的架构决策。大多数团队都是在付出代价后才意识到这一点：演示运行顺畅，生产逐渐退化，却没人能解释为什么模型开始对之前能自信回答的问题开始含糊其辞。

大多数工程团队对待 LLM 上下文窗口的方式，就像早期 Web 开发者对待全局变量：先塞进去，问题以后再说。上下文里堆满了最近 40 轮对话、仓库里的三个完整文件、十几份检索到的文档，以及一个经过六个月集体修改、越来越臃肿的系统提示词。一切看起来都能运行——直到某天突然不行了，而那时已经很难判断究竟是哪里出了问题。

上下文窗口不是堆内存。它更接近于 CPU 寄存器文件：容量有限、单位成本高昂，且其内容直接影响模型执行的每一次计算。当你把寄存器当成草稿纸随意使用而忘记管理时，程序会以各种匪夷所思的方式崩溃。当你把上下文窗口当成草稿纸时，LLM 会以悄无声息且代价高昂的方式退化。

你的模型精度在某个夜晚突然下降了8%。模型代码没有任何改动，没有发生任何部署，评估套件是绿色的。于是你花了一周时间调整超参数、修改提示词、对比检查点损失——最终有人注意到，三天前特征流水线里落地了一次Schema迁移。一个字段从NULL改成了空字符串。就这样，就是这个变化导致了回退。

这是生产ML系统中最常见的故障模式，与模型质量几乎毫无关系。问题的根源在于大多数团队被坑过之后才会补上的一个结构性缺口：数据版本和模型版本紧密耦合，但它们由不同的工具追踪、归属于不同的团队。

每个开发 AI 产品的团队最终都会发布一个反馈组件。点赞、点踩、或者星级评分，又或者是修正字段。组件上线了，数据流转了，但随后几周甚至几个月，模型却没有任何改变——而团队仍然坚信他们拥有一个有效的反馈闭环。

组件只是简单的部分。其背后的标注流水线（annotation pipeline）才是 AI 产品真正陷入停滞的地方。

Prompt 缓存听起来是一个稳赢的方案：Anthropic 和 OpenAI 都宣传缓存命中可享受 90% 的折扣，且文档中展示了令人印象深刻的成本削减图表。团队实施了它，观察着缓存命中率计数器不断上升，并理所当然地认为自己在省钱。但实际上，有些团队支付的费用比完全不使用缓存时还要 多。

问题在于“写入溢价”（write premium）。每当你缓存一个前缀时，你都需要支付额外的费用——在 5 分钟的缓存窗口内是 1.25 倍，在 1 小时的窗口内是 2 倍。如果你的命中率太低，这些写入溢价的累积速度会超过读取折扣所节省的费用。缓存并不是免费的保险；它是你对自己流量模式下的一场赌注。

典型的 AI 叙事往往是这样的：你构建一个产品，添加一个 AI 功能，用户就能获得更智能的输出。这种框架虽然正确，但并不完整。更持久的优势根本不在产品层，而是在其底层运行的数据流水线中。

越来越多的工程团队悄然将 ETL 流水线中的正则规则、自定义分类器和手写解析器替换为 LLM 调用。结果是：流水线可以处理非结构化输入，适应模式偏移（schema drift），并对数千个类别的记录进行分类——而无需为每一个新的边缘情况重新训练模型。大规模运行这种模式的团队正在构建具有复利效应的数据资产。而那些仍将 LLM 纯粹视为产品功能的团队则不然。

在大多数 RAG 架构中都存在这样一种信念：如果检索返回了正确的区块（chunks），LLM 就会生成正确的答案。团队在嵌入模型选择、混合检索策略和重排序流水线方面投入了巨资。然而，在部署到生产环境三个月后，回答质量悄然下降——这不是因为模型变了，也不是因为查询模式发生了剧变，而是因为底层的语料库腐烂了。

企业级 RAG 的实施失败率约为 40%，而从业者最容易低估的失败模式既不是幻觉，也不是检索召回率低，而是文档质量。一项分析发现，通过引入文档质量评分，一个实施方案在不改变嵌入模型或检索算法的情况下，将搜索准确率从 62% 提高到了 89%。语料库是唯一的变量。语料库一直都是变量。

在AI功能上线之前，你的连接池一直运行良好。登录正常，仪表板加载顺畅，CRUD操作以个位数毫秒的延迟稳定运行。然后团队部署了一个RAG驱动的搜索、一个Agent驱动的工作流，或者一个LLM支持的摘要端点——几个小时内，你的核心产品开始超时。数据库并没有变慢，你的连接池只是被一种它从未被设计来处理的工作负载吞噬了。

这就是LLM连接池问题，随着AI功能从原型走向生产环境，它正在影响整个行业的团队。解决方案不是"增加更多连接"。事实上，这通常会让事情变得更糟。

大多数 RAG 架构长得都一样：你的应用从 Postgres 读取数据，将文本发送到嵌入 API，将向量写入 Pinecone 或 Weaviate，并在读取时查询两个系统。你维护着两个数据存储、两套一致性模型、两套备份策略，以及一条同步管道——这条管道总是离让你的向量索引落后源数据数周只差一个边缘情况。

如果数据库自己就能搞定一切呢？这已经不再是假设。PostgreSQL 扩展如 pgvector、pgai 和 pgvectorscale——以及 AlloyDB AI 等托管服务——正在将整个嵌入与检索堆栈折叠进数据库本身。结果不仅仅是减少了活动部件，而是一种根本不同的运维模型：你的向量始终与其所代表的数据保持事务一致。