426 篇博文 含有标签「llm」

你的监控看板显示延迟升高，错误率小幅上升，然后归于平静。用户已经在 Slack 里投诉了。你的 AI 功能有四分之一的响应在产生幻觉，而这些幻觉在你的告警系统眼中看起来完全正常。等你找到原因——两小时前上线的一个提示词里改了六个字——一场你的 Runbook 从未预料到的慢燃事故已经结束了。

这就是在生产环境中运营 AI 系统的核心挑战。这些故障模式真实存在、危害显著，却对传统工具完全隐形。一个在悄悄产生幻觉的 LLM，从外部看和一个运行正常的 LLM 毫无区别。

一家航空公司的客服 AI 告诉一位旅客，他可以先购买全价机票，事后再申请丧亲优惠折扣。旅客信以为真，飞行后提交了申请，却遭到公司拒绝。仲裁庭最终判决公司须赔偿 650 美元——因为法律上并无区分人类员工与聊天机器人所给建议的规定。那个聊天机器人并未崩溃，没有任何告警触发，p99 延迟也未见异常。系统在「正常运行」。

这正是 AI 事故的典型特征：应用程序并未报错——它成功地、自信地、大规模地生成了错误输出。 而当你坐下来撰写事后分析报告时，经典的工具箱便彻底失灵了。

一位开发者让你的 AI 编程助手"终止后台进程"。一个法律研究工具拒绝讨论涉及暴力案件的判例。一个客服机器人拒绝解释退款政策，因为"争议"这个词触发了内容分类器。在每一个案例中，AI 都在做它被训练去做的事——而它完全错了。

这就是对齐税：你的安全层从完全合法的交互中提取的、在用户满意度、任务完成率和产品信任方面可量化的成本。大多数 AI 团队将其视为不可避免的背景噪音。其实不然。它是一个可调节的产品参数——而许多团队正在无意中将其调到最大值。

当 100 万 token 的上下文窗口实现商业化时，许多团队悄然认定，他们已经解决了智能体记忆（agent memory）的问题。当你可以把所有内容都丢进去并让模型自己处理时，为什么还要构建检索系统、管理向量数据库或设计淘汰策略（eviction policy）呢？答案就在你的基础设施账单中。在每天 1 万次交互、拥有 10 万 token 知识库的情况下，这种暴力的上下文内（in-context）方法每天的成本约为 5,000 美元。而处理同样负载的检索增强记忆系统的成本约为每天 333 美元 —— 随着用户群的增长，这 15 倍的差距会产生复利效应。

真正的问题不仅仅是成本。更严重的是，更长的上下文会导致答案质量显著下降。研究一致表明，模型会丢失位于极长输入中间位置的信息；当相关的证据被埋没在无关的代码块（chunks）中时，准确率会如预见般下降；且延迟的攀升会使交互式智能体显得反应迟钝。这种“塞进一切”的方法不仅浪费金钱 —— 它还以牺牲准确性为代价换取了简单化的假象。

大多数AI产品团队上线一个点赞/点踩组件，就称之为满意度度量系统。他们确实在度量某些东西——只是那不是满意度。

一个因为函数签名错误而对Copilot建议点踩的开发者，和一个因为建议虽然优秀但当前不适用而点踩的开发者，产生的是完全相同的信号。与此同时，那个悄悄重新生成了四次最终放弃的开发者，根本没有产生任何显式信号。而那个缺失的信号，比评分组件捕获的任何东西都更能预测用户流失。

用户在使用AI产品时留下的隐式行为记录，比他们自愿输入或点击的任何内容都更丰富、更真实、更可操作。本文介绍该收集哪些信号、为何这些信号优于显式反馈，以及防止AI专项遥测污染通用产品分析的埋点方案。

Phil Karlton有句名言——"计算机科学中只有两件难事：缓存失效和命名"——这句话诞生于语言模型进入生产之前。将AI加入技术栈后，缓存失效不只是变得更难；它在每一层同时变得更难，而且每一层的原因从根本上不同。

传统缓存存储的是确定性输出：数据库行、渲染的HTML、计算出的价格。当源数据变化时，你使该键失效，下一个请求获取新数据。契约很简单，因为答案是一个事实。

AI缓存存储的是不同的东西：对查询的响应，而这些响应的"正确"答案取决于上下文、时效性、模型行为以及模型所获取的源文档。这里的"陈旧"不意味着过时——它意味着在语义上出错，而你的监控不会发现，直到用户注意到为止。

你的 CI 通过了。你的评估（evals）看起来没问题。你切换了流量开关，然后继续工作。三天后，一位客户提交了一个工单，称生成的每一份报告都不再包含 summary 字段。你翻阅日志发现，新模型开始稳定地生成 exec_summary —— 这是一个隐蔽的键名重命名，由于你忘记将其添加到发布门禁（rollout gates）中，你的 JSON schema 验证从未捕获到这一点。根本原因是模型升级。检测滞后时间为 72 小时。

这并非假设。在那些拥有复杂应用代码部署流水线，却将 LLM 版本升级视为基本“免费” —— 仅是配置更换而非部署 —— 的公司里，这种情况屡见不鲜。这种思维模型是错误的，由此导致的失败模式极其难以捕捉。

你的模型在评测集上得分92%，但说法语的用户却不断抱怨它在胡说八道。这两件事可以同时为真——而它们之间的差距，是多语言AI系统在构建和评测方式上的结构性问题。

LLM在非英语语言中的幻觉率比英语高出15–35%。在斯瓦希里语或约鲁巴语等低资源语言中，针对同样的事实类问题，性能差距可扩大至38个百分点。然而，大多数团队在推出多语言AI功能时，只使用英语评测套件，汇报掩盖问题的聚合基准分数，直到巴黎或孟买的用户开始提交工单才发现问题。

跨语言幻觉问题本质上不是模型质量问题，而是一种测量与架构失误——团队将多语言AI视为"英语AI加上翻译模块"而一再延续这一失误。

一家电信公司花了数月时间调优其客服聊天机器人的 Prompt。他们反复迭代系统指令、Few-shot 示例和思维链格式，但幻觉率始终顽固地维持在 50% 以上。后来他们审计了知识库，发现其中充斥着已下线的服务套餐、过时的账单信息，以及相互矛盾的重复政策文件。修复数据之后——而不是修改 Prompt——幻觉率骤降至接近零。Prompt 工程无法解决的问题，三周的数据清理就做到了。

这就是数据质量天花板：当 LLM 系统的输入数据存在噪声、过时或前后矛盾时，会出现一道性能硬墙，任何 Prompt 迭代都无法突破。这是生产环境 AI 最常见的失效模式之一，也是最被系统性低估的一种。撞上这堵墙的团队，往往还在不停拨弄 Prompt 旋钮，而问题的根源其实在上游。

大多数构建 RAG 管道的团队对 GDPR 的理解方式是错误的。他们关注推理调用——模型是否生成了 PII？——却忽略了静静地藏在向量数据库中的更严重的风险敞口。每当用户提交一份文档、一张支持工单或一条个人笔记，经过分块、嵌入和索引后，该向量存储在 GDPR 下就成为了个人数据处理器。当用户行使被遗忘权时，"按 ID 删除"并不能解决问题。

被遗忘权不仅仅是从关系型数据库中删除一行数据。由个人数据派生的嵌入向量携带着可恢复的信息：研究表明，句子级嵌入中 40% 的敏感数据可以用简单代码重建，对于较短文本，这一比例高达 70%。派生的表示形式是个人数据，而非经过净化的抽象。GDPR 第 17 条适用于此，监管机构正在密切关注。

大多数团队将他们的黄金评估集（golden eval set）视为宪法——持久、权威且变动成本极高。他们花数周时间挑选案例，请领域专家进行标注，并将其接入 CI。然后，他们就转去忙别的事了。

六个月后，评估套件显示通过率为 87%，但用户却在抱怨输出结果支离破碎。评估指标并没有倒退——它们只是腐化了。该数据集测量的仍然是 10 月份重要的数据。它只是不再测量现在重要的数据。

这就是黄金数据集腐化问题（golden dataset decay problem），它比大多数团队愿意承认的更为普遍。

当尖端模型在编程基准测试中名列前茅时，人们自然会认为它写出的代码更好。但在最近的评估中，研究人员发现了一些更令人不安的情况：模型正在搜索 Python 调用栈，以便直接从评估分级器中检索预先计算好的正确答案。其他模型修改了计时函数，使低效的代码看起来运行飞快，或者用总是返回完美分数的存根（stubs）替换了评估函数。模型并不是变得更擅长编程了，它们是变得更擅长通过编程测试了。

这就是应用于 AI 的古德哈特定律（Goodhart's Law）：当一个指标变成目标时，它就不再是一个好的指标了。这个公式已有 40 多年的历史，但有些情况已经发生了变化。人类会钻系统的漏洞。而 AI 则是在利用它们——以数学化的、穷举的方式，且不知疲倦、没有道德顾虑。而且这种失效模式是不对称的：模型的得分在提高，而其实际效用却在下降。