使用 LLM 构建的一年：该领域的实战经验总结

如今大多数使用 LLM 构建产品的团队都在重复别人一年前犯过的错误。最代价昂贵的错误就是将模型误认为是产品。

在 LLM 驱动的系统（代码生成工具、文档处理器、面向客户的助手、内部知识系统）上线生产环境一年后，从业者积累了一系列辛苦换来的知识，这些知识与炒作周期所暗示的大相径庭。这些教训不在于选择哪个基础模型，或者 RAG 是否优于微调，而在于构建可靠系统的那些枯燥工作：如何评估输出、如何构建工作流、何时投资于基础设施、何时继续迭代提示词，以及如何思考差异化。

这是对这些实战经验的总结。

模型是你系统中持久性最差的部分

以下是上线产品的团队中最一致的发现：模型并不是你的竞争优势所在，它也是最容易被商品化或颠覆的组件。

证据显而易见。BloombergGPT——由一个 9 人团队利用 3630 亿个领域特定 token 从零开始训练而成——在发布后不到一年内就被 GPT-3.5-turbo 超越。那些在 2023 年（在提示工程达到瓶颈之前）进行激进微调的团队，几乎一致认为这种投资为时过早。他们微调所基于的模型发布了版本更新，他们的评估失效了，他们又回到了起点。

自首个商业 API 推出以来，模型能力的成本每六个月大约减半——在约 18 个月内成本降低了 100 倍。实际的影响是：任何基于“更好的模型访问权限”建立的差异化都会迅速消失。不会消失的是基础设施：你的评估工具（evaluation harness）、你的防护栏（guardrails）、你的缓存层和你的数据飞轮。

构建持久系统的团队已经内化了这一点。他们将模型选择视为一种成本/性能的权衡决策——几乎是商品化的——并将工程精力集中在包裹它的系统上。护城河在于评估（evals）、数据收集和特定领域的工作流，而不是权重。

评估是工程工作，而非 QA 演戏

LLM 部署中最常见的失败模式是将评估视为事后的想法——只有在系统“感觉差不多了”时才加入。这样做会导致“感觉”（vibes）泛滥（“它似乎运行得更好了”），而无法安全地迭代。

适当的评估基础设施是工程工作，它需要与其他系统组件相同的严谨性。

一些在实践中行之有效的具体方法：

基于断言的生产样本单元测试。 每天检查生产环境中的实际输入/输出对。当你发现失败时，为它编写一个测试。目标是每个测试用例至少有三个不同的断言。这虽然不显眼，但是构建一套能追踪用户真正关注点的可靠评估套件的最快路径。

成对比较优于 Likert 量表。 当使用 LLM-as-Judge 自动执行大规模评估时，成对比较（“这两个回答中哪一个更好？”）比要求模型在 1–5 分的量表上打分要可靠得多。它们也更便宜：一个团队通过切换到成对比较法，将每个单元的标注成本从 25 美元降低到了 3.50 美元。将比较与思维链（chain-of-thought）推理结合，以减少位置偏见（positional bias）。

实习生测试。 在调试模型之前，请先问：一个称职的新入职员工在拥有我提供给模型的相同背景信息的情况下，能否成功完成这项任务？如果是，那么失败就是模型的问题。如果不是，那么失败就是背景信息的问题——增加更多背景信息或更好的检索可能比提示词工程（prompt engineering）修复得更快。

不要针对单一指标过度优化。 一个团队花了几周时间提高“大海捞针”（Needle-in-Haystack）的分数，结果却得到了一个摘要能力更差的模型。评估套件需要涵盖所有重要的方面，而不仅仅是那些最容易衡量的指标。

多步工作流始终优于单一提示词

一个根深蒂固的误解：更好的模型会让复杂的提示词变得多余。在实践中，情况往往相反——随着任务复杂性的增加，无论模型能力如何，结构化的多步工作流的表现都优于单次提示。

AlphaCodium 的结果清楚地说明了这一点。通过增加结构：反思问题、推理测试用例、生成解决方案、对备选方案进行排序、使用合成测试进行迭代，GPT-4 在竞赛编程基准测试中的准确率从 19% 跃升至 44%。底层模型并没有改变，改变的是工作流。

这种模式在各个领域都有体现：

• 一个被拆分为“提取决策” → “验证一致性” → “生成摘要”的会议摘要器，比单个超长提示词更可靠且更容易调试
• 在生成最终输出之前先反思边缘情况的代码生成流水线，表现优于直接生成
• 先识别文档类型、再应用特定类型的提取逻辑的文档分类器，能显著减少错误

工程上的启示是：尽早投资于工作流架构。与不透明的单一提示词相比，每一个步骤都可观察、可测试的结构化确定性流水线在根本上更容易调试和改进。只有在预定义工作流无法覆盖问题空间的真正开放式任务中，才保留自主智能体（autonomous agent）循环。

先做 RAG，再谈微调（如果真有必要的话）

一个常见的早期错误：在系统知识储备不足时就急于进行微调（Finetuning）。在绝大多数情况下，检索增强生成（RAG）才是正确的第一步。

基准测试对比中的证据是一致的：在注入新的、可更新的知识方面，RAG 的表现优于微调。微调将知识固化在权重中 —— 更新成本高昂，难以审计，且无法让模型具备引用来源的能力。RAG 则使知识显性化、可更新且可追溯。

从业者学到的一些细微差别：

向量嵌入（Vector embeddings）并不能魔法般地解决搜索问题。 在大多数生产环境中，纯语义搜索的表现不如混合方法。BM25 关键词搜索应该是基准 —— 它速度快、可解释，并且能处理嵌入经常遗漏的精确匹配查询。混合检索（BM25 + 嵌入，并结合重排序 Reranking）的表现始终优于其中任何一种单一方法。

检索质量有三个维度： 相关性（你检索到的东西对吗？）、信息密度（每个分块的信息含量有多高？）以及细节层级（检索到的内容是否有足够的特异性来完成任务？）。大多数团队只针对相关性进行优化，而忽略了另外两个维度。

长上下文模型并不会消除对 RAG 的需求。 即使拥有 128K 或 200K 的上下文窗口，出于相关性过滤和成本限制的考虑，检索仍然具有价值。将整个文档库塞进上下文中不仅昂贵，而且往往会降低性能 —— 模型在长上下文中会失去焦点。

只有当提示词工程（Prompting）触及明显的瓶颈时才考虑微调 —— 大致在你达到所需质量的 90% 左右，并且已经穷尽了提示词工程、少样本示例（Few-shot examples）和检索改进手段之后。大多数团队在下一代模型重置基准线之前，根本无法触及那个瓶颈。

只有在生产环境中才会显现的运维经验

有些经验只有在系统运行足够长的时间、积累了真实的搜索模式后才会显现。

锁定你的模型版本。 某家公司在 GPT-3.5 版本之间的平台迁移曾导致性能下降了 10% —— 这是一种在代码未变情况下的无声回归。生产环境中的 LLM 应用应该锁定特定的模型版本，并将升级视为需要重新评估的迁移任务。

从两个维度监控分布偏移（Distribution shift）。 跟踪结构性漂移（输入中的格式、字段名、大小写）和语义性漂移（主题或查询分布，可通过嵌入聚类检测）。大多数监控设置只能捕捉到前者，而忽略了后者。

使用能胜任工作的最小模型。 在一个记录在案的案例中，使用 10 样本提示（10-shot prompting）的 Haiku 在同一任务上的表现优于零样本（Zero-shot）的 Opus 和 GPT-4 —— 而成本仅为后者的一小部分。这个经验并不是说要始终使用小模型，而是说模型的选择应该是基于实证的，而非基于愿望。更大并不自动意味着更好。

从一开始就结构化输出。 让下游解析 LLM 的自由格式输出既是维护负担，也是脆弱点。像 Instructor（用于 API 调用）和 Outlines（用于自托管模型）这样的库可以强制执行结构化生成，从而消除整类脆弱的解析代码。

激进地使用缓存。 针对重复查询模式的语义缓存、针对护栏（Guardrails）和政策导向输出的响应缓存，以及多轮对话的上下文缓存，都能以较低的实现成本显著降低成本和延迟。

战略：何时投入，何时保持精简

LLM 产品的战略版图已经变得非常清晰。以下是几条经得起考验的原则：

在达到产品与市场匹配（PMF）之前，不要碰 GPU。 在你真正了解用户需求之前就训练基础模型，几乎总是资本配置上的错误。所需的资源是巨大的；在 PMF 之前，其相对于经过调优、提示词工程处理的商用 API 所获得的性能增益很少值得投入；而且维护负担是持续性的。只有当机密性要求或规模驱动的成本压力使之成为必要时，再考虑自托管 —— 而不是将其作为一种首要原则的架构决策。

建立模型供应商无法复制的护城河。 特定领域的评估框架（Evals）、私有数据飞轮、高质量的标注数据集、针对你特定风险面调优的护栏 —— 这些都会随时间积累，且运行相同基础模型的竞争对手难以轻易复制。通用的商品化功能（自然语言转 SQL、文档聊天机器人、通用的知识库集成）不会产生复利，也无法让你脱颖而出。

团队结构随成熟度演进。 成功的 LLM 产品往往经历三个阶段：第一阶段是产品和提示词工程 —— 寻找可行方案。第二阶段是仪器化和数据采集 —— 构建反馈循环。第三阶段是系统化优化 —— 利用评估和数据来推动可衡量的改进。在第一阶段产品目标尚不明确时就跳到第三阶段的基础设施建设，是一种常见的过早优化。

潜在的赌注

所有这些经验都指向同一个潜在的赌注：最终胜出的团队不是那些拥有最佳模型访问权限的团队，而是那些构建了最佳反馈循环的团队。

评估体系、数据采集基础设施、标注流水线、能产生信号的人机回环（Human-in-the-loop）交互设计 —— 这些都比写出一个好的初始提示词更难构建，也更难被复制。它们也是随着模型改进而唯一能持续产生复利的东西。当下一代模型发布、每个人的基准性能都飞跃时，拥有稳健评估基础设施的团队将能够衡量改进并快速适应。而其他人只能靠猜。

模型会变。但验证模型的系统不必随之改变。