778 篇博文 含有标签「llm」

每个事件流系统最终都会将同一条消息投递两次。网络抖动、Broker 重启、偏移量提交失败——至少一次投递不是 Bug，而是契约。传统消费者能够优雅地处理这种情况，因为它们是确定性的：处理同一事件两次，得到相同的结果，写入相同的记录。第二次写入是一个空操作（no-op）。

LLM 不是确定性处理器。相同的提示词加上相同的输入，每次运行都会产生不同的输出。即使设置了 temperature=0，浮点运算、批次组合效应以及硬件调度的差异也会引入方差。针对"确定性" LLM 设置的研究发现，在自然发生的多次运行中，准确率差异高达 15%，最优与最差性能之间的差距甚至达到 70%。至少一次投递加上非确定性处理器，并不会给你带来至多一次的行为，只会带来不可预测的行为——这是一场蓄势待发的生产环境危机。

关于生产环境中的 LLM，大多数讨论都围绕着聊天界面、Copilot 和自主代理。但如果你审计企业 LLM Token 的实际消耗去向，你会发现一个完全不同的景象：绝大多数的使用都发生在批处理数据管道（batch data pipelines）中 —— 从文档中提取字段、对支持工单进行分类、规范化混乱的供应商记录、为原始事件添加语义标签。没有人为这个层级编写会议演讲，也没有人认真地对其进行基准测试。而这种沉默正让团队付出真金白银和准确性的代价。

这是从业者最先构建、最后辩护、且监控最少的 ETL 层级。对于大多数组织来说，这也是 LLM 支出杠杆率最高的一层，同时也是产生隐形失败潜力最高的一层。

一个团队在 GPT-4 上构建了一个生产环境功能。几个月后，出于成本考虑，他们决定评估 Claude。他们花了两周时间进行“迁移”——但核心的 API 替换只花了一个下午。剩下的十天都花在了修复损坏的系统提示词（system prompts）、重新测试拒绝服务的边缘情况、调试由于意外文本而崩溃的 JSON 解析器，以及重新调整在不同供应商之间表现迥异的工具调用模式（tool-calling schemas）。原本以为只是简单的连接器更换，结果迁移预算膨胀成了多层重构。

这就是现实中的 LLM 供应商锁定问题。那些受挫的团队并不是因为选错了供应商——而是因为他们没有意识到锁定存在于多个维度，且每个维度都有不同的风险画像。

当一个用户的 80 轮支持对话突然开始与其 60 轮前的建议相矛盾时，团队最初将其归咎于 Bug。其实并没有 Bug，只是模型“迷失”了。在所有主流的前沿模型中，多轮对话在相同任务上的表现平均比单轮交互下降了 39%。大多数团队从未衡量过这一点。他们假设上下文窗口的效力大致等同于其 Token 限制所暗示的程度，并据此构建产品。

这种假设在无声无息中出现了错误。长会话不仅仅是变得更慢或更昂贵 —— 它们变得不可靠，而这种不可靠性在用户感到沮丧之前几乎无法被察觉。

在AI工作中遇到困难的工程师，最常见的问题不是缺乏技术知识，而是他们一直在问错误的问题。他们想知道的是："这能用吗？"但他们真正应该问的是："这个系统的失败率是多少，这个失败率对于这个使用场景来说是否可以接受？"

这一转变——从二元正确性转向可接受的失败率——是有经验的AI工程师思考问题的核心差异。听起来简单，其实不然。由此延伸的一切都是不同的：你如何调试、如何测试、如何部署、监控什么、以什么为信心基础。没有完成这一转变的工程师会一直在与工具对抗并且不断失败。

大多数在大语言模型（LLM）之上构建 SaaS 产品的团队都是通过惨痛的教训才发现多租户问题的：他们利用单一的共享提示词配置快速出海，然后惊恐地发现一个客户的系统提示词泄露到了另一个客户的响应中，或者某个企业级客户耗尽了所有人的速率限制，亦或是当月 AI 账单寄来时，根本无法确定是哪个客户造成了 40% 的支出。这种失败模式并非停留在理论层面——NDSS 2025 的一篇论文证明，vLLM、SGLang、LightLLM 和 DeepSpeed 中的前缀缓存（prefix caching）可以被利用，仅通过时间信号和精心构造的请求，就能以 99% 的准确率重建另一个租户的提示词。

构建多租户 AI 基础设施与传统数据库的多租户化并不相同。共享组件——推理服务器、KV 缓存、嵌入流水线、检索索引——每一个都面临独特的隔离挑战。这篇文章涵盖了你实际必须解决的四个问题：隔离、定制、成本归因以及单租户质量追踪。

大多数构建AI智能体的团队在投产三个月后都会发现同一个问题：他们精心设计的评估套件——围绕文本输入和JSON输出构建——当智能体遇到模糊的发票、扫描合同或从未见过的UI截图时，毫无参考价值。纯文本评估通过了，但用户提交了工单。

多模态输入不仅仅是另一种需要接入的模态，它们引入了一类截然不同的故障，需要不同的架构决策、不同的成本模型和不同的评估策略。将视觉能力视为对现有文本智能体的即插即用扩展的团队，无一例外地低估了所需的工作量。

大多数构建端侧 LLM 功能的工程师，将时间花在解决那些显而易见的问题上：量化、延迟、内存限制。模型能装进手机，推理速度够快，演示效果也很好看。然后他们向数百万台设备发布，才发现一个更难的问题——从来没人提前告诉他们：你现在有数百万个独立的计算节点，运行着你 AI 模型的不同版本，而你根本没有可靠的方式知道任何一个用户运行的是哪个版本。

云端推理在最好的意义上是无聊的。你更新模型，重新部署服务器，几分钟内整个用户群就都在运行新版本了。端侧推理则彻底打破了这个假设。一个三个月前最后一次打开你应用的用户，仍在运行那时当前的模型——而且没有干净的方法强制更新，没有服务器端回滚，也没有简单的方法在没有你从一开始就构建的监控埋点的情况下检测到版本不匹配。

这种版本碎片化是端侧 AI 的核心运营挑战，其后果远不止缓慢的发布。它造成无声的能力漂移，使事故响应复杂化，并将你的"AI 功能"变成一个由独立运行的异构系统组成的庞大集群——你对其负责，却无法直接控制。

Writer 团队在对其 RAG-MCP 基准进行插桩测试时发现，当 Agent 可以访问大量工具集时，基准工具选择准确率——在无任何特殊处理的情况下——仅为 13.62%。不是 80%，不是 60%，而是 13%。而同一个 Agent，在通过检索增强的工具选择仅暴露最相关子集后，准确率达到了 43%。工具没变，模型没变，唯一变化的是推理时可见的工具定义数量。

这就是工具过载问题，它正在悄无声息地摧毁大规模生产 AI 系统。

你的新内部聊天机器人刚刚告诉一名实习生整个工程部门的薪资范围。HR 总监没有配置错任何东西。没有人分享了不该分享的链接。系统只是... 检索到了它，因为实习生询问了“工程师的薪酬预期”。

这是大多数团队预料不到的 RAG 隐私失效模式。它不是传统意义上的漏洞 —— 而是检索工作方式与访问控制预期方式之间的根本不匹配。

你加入了一个团队，他们已经在生产环境中运行某个 LLM 功能十八个月了。这个功能运作正常——用户喜欢它，业务也在乎它——但没有人能确切解释这个提示词做了什么，或者为何要这样写。编写它的工程师已经离职。当时讨论它的 Slack 消息埋在某个不复存在的频道里。提示词躺在数据库记录中，长达 900 个 token，没有注释，提交信息除了"更新提示词"什么都没有。

而现在，你被要求去修改它。

这种情况比业界承认的要普遍得多。提示词被当成配置值来对待：写起来很快，代码审查中看不到，一旦跑通就被遗忘。区别在于，配置错误的 feature flag 会立即暴露问题，而配置错误的提示词会在数周内悄悄地降低某些边缘情况的处理质量，直到有人注意到。

进入生产环境六个月后，你面向客户的 LLM 功能的系统 Prompt 已从最初清爽的 11 行增长到超过 400 个 token，充斥着各种条件指令、对冲表述和异常处理。质量明显比发布时更差，但当时的每一次单独修改似乎都是合理的。没人知道哪些条款相互冲突，也没人知道其中一半是否仍然必要。没人敢动它。

这就是 Prompt 债务螺旋——大多数处于生产阶段的团队已经深陷其中。