将 LLM 系统落地生产的血泪经验

大多数使用 LLM 构建产品的工程师都经历过相同的轨迹：两天内跑通 demo，六周后生产环境一片混乱。这项技术在真实负载、真实用户和真实数据下的表现截然不同。从中得出的教训不是哲学层面的，而是操作层面的。

在观察了众多公司的团队发布（有时也放弃）LLM 驱动产品之后，一些规律反复出现。这些不是边缘案例，而是普遍经历。

评估不是可选的基础设施——它是基石

最常见的错误是在没有评估体系的情况下就上线。没有 evals，每一个架构决策——RAG 还是微调、选哪个模型、思维链是否有帮助——都只是凭感觉。你无法判断某次提示词修改是改进还是退步。你是在盲飞。

从基于真实生产样本（而非合成样本）构建的断言式单元测试开始。如果还没有生产数据，就手动收集，哪怕只有五十条。为每个评估集编写具体、可衡量的标准（至少三条）。这些标准起初看似显而易见，但不会一直如此——随着团队接触真实数据，"好"的定义会发生偏移，如果不明确追踪这些标准，你根本不会注意到这种漂移。

对于成对比较，LLM-as-Judge 的效果出奇地好，但前提是要校准。不要使用现成的 judge 提示词。从手动标注的样本开始，检查 judge 与团队判断在哪里存在分歧，并持续迭代 judge 提示词直到对齐度高。一个校准错误的 judge 比没有 judge 更糟——它会给你虚假的信心。

将人工标注任务简化为二元判断或成对比较。细致的评分量表会引入标注者间的方差，把信号淹没在噪声中。任务越复杂，标注者越容易赶工，从而引入更多错误。保持简单。

混合搜索优于纯向量检索

默认的 RAG 实现——嵌入所有内容，按余弦相似度检索——在演示中有效，在生产中悄悄失败。失败模式很微妙：检索结果看起来合理，但遗漏了真正重要的文档。

关键词搜索（BM25）能处理嵌入无法处理的精确术语、产品名称、SKU 和专有名词。向量搜索处理语义相似性和同义改写。两者单独使用都不够。切换到混合方式——结合 BM25 和嵌入检索，使用分数融合——的团队，持续观察到检索质量的提升，而这些改进是下游生成过程无法从检索失败中弥补的。

决定检索质量的三个因素：相关性（正确的文档是否被召回？）、信息密度（检索内容是否含有有效信号，还是大多是样板文本？）、细节层级（检索的分块是否足够细粒度，能够回答问题？）。分别追踪这三个因素。看起来像生成失败的检索失败是最难调试的，因为你会在错误的组件上浪费数周时间。

分块策略比大多数团队预期的更重要。基于 token 数量的分块实现快速但对密集文档来说悄然灾难性。一个跨越两个分块的法律条款在句中断开时就失去了其含义。按章节或逻辑单元进行语义分块，以实现复杂度换取更好的检索效果——通常这样做是值得的。

多步骤工作流优于单一巨型提示词

把所有内容塞进一个提示词的冲动可以理解——更少的 API 调用，更简单的代码。但在复杂任务上，这种做法可靠地表现更差。

将复杂任务拆分成专注的、单一目的的提示词，能同时提高可靠性和可调试性。当流水线有六个步骤时，你可以定位哪个步骤失败了。当你有一个超级提示词时，你无法定位。代码生成研究表明，将单次生成替换为包含自我审查和精炼阶段的多步骤工作流，准确率提升了 2 倍甚至更多。

实现启发式：如果一个提示词要求模型同时做两件以上实质性不同的事情（提取、然后分类、然后格式化），就拆分它。编排代码的开销相比可控性的提升来说微不足道。

对于智能体系统——模型在其中做出顺序决策——优先选择确定性计划而非开放式探索。先规划后执行（而非同时规划和执行）的智能体更可靠，也更容易监控。规划步骤可以由 LLM 生成；执行步骤应该是受约束且可预测的。

模型选择是一个移动的靶子

在项目开始时选定一个模型并假设它会一直保持最优，这种想法是错误的。模型会被更新、弃用和超越。GPT-3.5-turbo 在 2023 年初是最先进的；不到一年，就出现了性能显著更好且成本更低的模型。

在生产中固定特定模型版本。浮动版本（如"gpt-4"）可能会悄悄改变行为。一次提升通用能力的模型更新，如果你的提示词依赖特定的响应模式，仍然可能让你的特定用例发生退步。

模型之间的提示词迁移比预期更痛苦。从一个模型系列切换到另一个，通常需要从头重建提示词，而不是移植。即使语义相同的提示词，不同模型之间也会有 10% 以上的性能差异。如果你已经建立了评估套件，这是可管理的。如果没有，你只是在猜测。

满足评估质量标准的最小模型通常是正确的选择。提示词工程良好的小模型，经常优于提示词粗糙的大模型，而成本差异在规模上会复利放大。这并非总是如此——某些任务确实需要最大的模型——但应该把"使用最大的模型"视为后备方案，而不是默认选项。

不适合演示的运营经验

每天监控输入和输出。 开发数据不能反映生产分布。结构性偏差——格式差异、字段类型——容易检测。语义偏差——用户询问内容的含义随时间变化——需要人工审查。每天查看一批随机生产输入输出样本的团队，能发现自动化监控遗漏的漂移。这种听起来不正式的"感觉检查"实际上是不可替代的。

大量使用缓存。 LLM 延迟高，每次调用的成本不容忽视。精确匹配缓存处理重复输入（在 FAQ 类系统中很常见）。语义缓存——与已缓存查询嵌入距离在某个阈值内的查询返回缓存答案——处理近似重复。两者都需要缓存失效策略，但延迟和成本节省足以证明实现工作是值得的。

护栏需要输出监控，而不仅仅是输入过滤。 LLM 即使在不应该生成内容时也会生成文本——当它们不确定、当问题超出范围、当检索到的上下文不支持答案时。仅靠提示词工程无法防止听起来自信但实际不正确的输出。构建输出端检查：针对检索来源的事实一致性验证、拒绝检测、输出结构验证。无参考评估——在不需要标准答案的情况下评估输出质量——可以作为运行时护栏发挥双重作用。

在不得不微调之前不要微调。 早期的微调决策常常令人后悔。微调需要标注数据集、训练基础设施和随着模型更新而持续的维护。它也使调试更难——来自微调的行为变化和来自提示词更改的行为变化难以区分。带有精良提示词的 RAG 能处理团队最初求助于微调的大多数情况。只有在有强有力的评估证据证明提示词已经到达上限之后，才投入微调。

什么真正创造长期价值

模型本身不是竞争护城河。模型正在以可预测的曲线变得更便宜、更强大。创造持久价值的是周围的系统：

• 评估体系，编码了你所在领域对质量的定义，并随时间改进
• 数据管道，捕获用户反馈并将其转化为训练信号
• 护栏和可观测性，使系统足够可信赖从而能够扩展
• 领域专业化，创造通用工具无法匹敌的粘性

在 2023 年和 2024 年试图在模型能力上差异化的团队发现这种区别消失了。构建了深度评估基础设施和领域专属数据飞轮的团队，发现这些投资在复利增长。

从原型到生产的过渡，主要不是技术挑战——而是纪律挑战。使 LLM 系统可靠的实践（评估、监控、结构化检索、模块化提示词）都是已知的。只是需要在能感受到跳过它们的后果之前就坚持做到。

等后果显而易见时，你已经在救火了。