702 篇博文 含有标签「llm」

你的向量搜索在基准测试中表现出色，但用户依然感到沮丧。

失败模式非常微妙：用户询问“我们的哪些供应商卷入了影响与 Martinez 账户所在地区相同客户的事件？”你的嵌入模型检索到了事故记录。它们检索到了供应商合同。它们检索到了客户账户。但它们是以相互孤立的文档形式检索出来的，LLM 必须在上下文中理清这些关系——而这些关系横跨了实体图（entity graph）中的三个跳数（hops）。当每个查询涉及五个或更多实体时，如果没有关系结构，准确性会降至接近零。而有了关系结构，性能则保持稳定。

这正是知识图谱增强检索——GraphRAG——旨在解决的瓶颈。它不是向量搜索的直接替代品。它是一个具有不同成本结构、不同失败模式、以及在特定类别查询中具有压倒性优势的不同系统。

大多数采用知识蒸馏的团队，都在错误的理由和错误的时机下做出了这个决定。他们看到一个70B模型吞噬了推理预算，读到蒸馏可以产出一个"同样出色"的7B学生模型，便立即开干。六周后，他们得到了一个在验证集上表现良好的蒸馏模型，上线后却开始大规模输出自信满满的废话。验证集来自与教师模型合成训练数据相同的分布，而真实流量并非如此。

蒸馏是一种优化工具，而非能力升级手段。只有在特定条件下，经济账才算得过来——而且失败模式足够隐蔽，团队往往要等到用户先发现问题。

一个团队在周二下午将 GPT-4o 换成了一个更新的模型。到周四，支持工单增加了 30%，但没人能说清原因 —— 新模型的回答稍短，拒绝了一些旧模型能处理的边缘情况请求，并且日期格式化的方式不同，导致下游解析器崩溃。团队选择了回滚。两个迭代周期的工作付诸东流。

这种故事不断上演。问题不在于新模型更差 —— 它在大多数方面可能表现得更好。问题在于团队发布的流程与发布 bug 修复程序完全相同：合并、部署、观察。这对代码有效，但对 LLM 则行不通。

大多数构建 LLM 应用的团队都将隐私视为一个模型问题。他们担心模型知道什么——它的训练数据、它的记忆——却在模型周围的流水线中留下了巨大的漏洞。令人尴尬的事实是，生产环境 LLM 系统中绝大多数的数据泄露根本不是来自模型。它们来自你未经脱敏就索引的 RAG 分块、你逐字写入磁盘的提示词日志、包含数据库凭据的系统提示词，以及被投毒文档劫持以窃取知识库中所有内容的检索步骤。

Gartner 估计，到 2025 年底，30% 的生成式 AI 项目将因为风险控制不足而被放弃。这些失败中的大多数并不是因为模型幻觉——而是源于工程师本以为在掌控之中的系统隐私和合规性故障。

当 Gemini 1.5 Pro 发布并具备 1M token 的上下文窗口时，一波工程师宣布 RAG 已死。这种论点看似无懈可击：既然你可以把整个知识库直接丢进提示词（Prompt）中让模型自己去处理，为什么还要构建一个包含分块器（chunkers）、嵌入（embeddings）、向量数据库和重排序器（re-rankers）的检索流水线呢？

这种论点在生产负载下会分崩离析。Gemini 1.5 Pro 在“大海捞针”（needle in a haystack）基准测试（即隐藏在文档中的单个事实）中实现了 99.7% 的召回率。但在现实的多事实检索场景中，平均召回率在 60% 左右。这 40% 的遗漏率并非基准测试的偏差；而是你的系统在静默状态下未能向用户展示的事实。而且，一个 1M token 请求的延迟比 RAG 流水线慢 30–60 倍，而单次查询成本约为其 1,250 倍。

长上下文模型是强大的工具。它们只是不适合大多数生产环境的检索工作负载。

你的生产系统运行正常。可用性为 99.9%。延迟处于正常水平。错误率告警为零。然后一个用户提交了一个工单：“最近的摘要变得莫名其妙地偏差。”你调取日志，一切看起来都没问题。你检查模型版本 —— 还是三个月前部署的那个。到底发生了什么变化？

是模型提供商变了。而且是悄无声息地变了。

这就是模型升级陷阱：基础模型在你不知情的情况下发生了变化，而标准的观测基础设施对这种行为偏移（behavioral drift）完全视而不见。等到用户注意到时，性能下降已经持续累积数周了。

大多数团队最初都使用单一的 LLM 提供商 API 密钥，并在所有业务中共享。这在起初行得通，直到某天它突然失效。也许在某个下午，数据管道中的一个批量任务耗尽了全部速率限制，导致面向用户的聊天功能陷入沉寂。或者财务部门要求你按团队细分 4 万美元的 LLM 账单，而你意识到自己根本无法回答这个问题。

在 LLM 提供商前部署生产级 API 网关可以解决这两个问题 —— 但它也会引入一类复杂性，大多数团队在遇到麻烦之前往往会低估这种复杂性。

为 LLM 应用添加视觉能力看起来简单得令人误解。你将文本模型换成多模态模型，在提示词中加入一张图片，演示效果就非常出色。但在推向生产环境后，你会发现有一半的发票金额是错的，PDF 中的表格丢失了结构，而低质量的扫描件会产生言之凿凿的幻觉。调试这种系统的难度超过了你以前面对的任何纯文本系统，因为这些失败是视觉上的，且 LLM 不会告诉你它看不清楚。

本篇文章将介绍当多模态 LLM 输入从原型转向生产环境时，究竟会发生什么问题，以及能够防止这些失败的架构决策。

你在凌晨 2 点收到了报警。用户报告输出内容全是一堆垃圾。你通过 SSH 登录，检查日志，盯着追踪信息 —— 结构上看起来一切正常。模型有响应，延迟也正常。但答案就是不对劲。接着，事故频道里出现了一个问题：“现在到底运行的是哪个版本的 Prompt？”

如果你不能在 30 秒内回答这个问题，说明你正面临 Prompt 版本管理问题。

在大多数早期 LLM 项目中，Prompt 被当作配置来对待。产品经理修改 .env 文件中的字符串，开发者将更新后的指令粘贴到硬编码的常量中，还有人在 staging 的 Slack 频道中粘贴了一个略有不同的版本。最终，版本产生了偏差，没有人知道哪里运行的是什么。这种在实验阶段助你快速上线的随意性，在你拥有真实用户的那一刻就会变成一种负债。

每个销售 LLM 网关的供应商都会向你展示一张标有“95% 缓存命中率”的幻灯片。那张幻灯片不会告诉你的是小字说明：这个数字是指在找到匹配项时的匹配准确度，而不是找到匹配项的频率。实际的生产系统命中率为 20–45% —— 营销与现实之间的差距正是大多数团队踩坑的地方。

语义缓存（Semantic caching）是一项非常有用的技术。但在不了解其失效模式的情况下部署它，会导致你以极高的置信度向用户返回错误答案，并让你纳闷为什么支持工单翻了一倍。

当开发者第一次接入 JSON 模式时，响应结果感觉就像解决了一个大问题。LLM 不再返回 Markdown 围栏、文字道歉或靠近花括号的乱码。输出可以解析了，测试通过了，生产环境上线了。

然而，三周后，一个后台作业悄无声息地失败了，因为模型在 Schema 要求 {"status": "completed"} 时返回了 {"status": "complete"}。由于一个必填字段返回了 null 而不是被省略，数据流水线崩溃了。智能体工具调用循环（agent tool-call loop）提前终止，因为模型在字符串值中嵌入了一个异常换行符，导致下游解析器卡死。

JSON 模式保证了语法上有效的 JSON。它并不保证该 JSON 的含义与你的预期一致，不保证它包含你的应用程序所期望的字段，也不保证在多次请求之间保持语义一致性。这些是不同的问题，需要不同的解决方案。

大多数 Agent 演示仅使用 5 个工具，而生产系统通常拥有 50 个。这两个数字之间的差距，正是大多数 Agent 架构分崩离析的地方。

当你给一个 LLM 4 个工具和一个明确的任务时，它通常能选对。但当你给它 50 个工具时，更有趣的事情发生了：准确率大幅下降，Token 成本激增，且失败模式通常表现为模型幻觉出一个工具调用，而不是承认它不知道该用哪一个。来自 Berkeley Function Calling Leaderboard 的研究发现，在跨多个领域的日历调度任务中，当工具数量从 4 个扩展到 51 个时，准确率从 43% 骤降至仅 2%。这绝不是一个平滑的性能退化曲线。