6.3 生成式 AI 与 LLM 应用

概述与动机

生成式 AI，尤其是大语言模型（LLM），能够根据自然语言指令生成流畅的文本、代码、摘要和结构化数据。这让它们成为助手、搜索、文档处理和自动化的强大构建模块。但这些优势伴随着一种独特的风险特征。LLM 是概率性的。它们可能会自信满满地说出虚假的内容（幻觉）。它们对你如何提示（prompt）非常敏感。而且它们打开了新的攻击面，比如提示注入（把恶意指令偷偷塞进输入中，以劫持模型的行为）。因此，构建可靠的 LLM 应用，重点较少在于模型本身，更多在于围绕它的工程实践：你如何提供上下文、把答案锚定在可信知识上、约束输出，以及评估质量。

对于大型团队而言，LLM 应用需要有别于传统软件和经典机器学习的新模式。通常没有训练这一步骤。相反，行为是由提示、检索到的上下文、工具定义和护栏（在运行时约束模型输入输出的检查机制）来塑造的。这把工程投入的重心转向了上下文管理、检索质量、编排和评估。大规模采用 LLM 的企业需要共享的模式，这样每个团队才不必各自艰难地重新发现同样的失败模式。

政府和受监管的组织面临额外的要求。一个编造出一条政策引文或泄露敏感数据的 LLM，不仅仅是一个缺陷；它可能是一次法律或安全事件。这些场景需要将模型锚定在权威来源上、严格的输出验证、对有实质影响的输出进行人工监督，以及清晰记录系统被要求做什么、又产出了什么。本章介绍的技术（检索增强生成、护栏和严格的评估）正是让 LLM 足够安全、能够部署在高风险场景中的关键。Anthropic 的 Claude 模型是众多有能力的供应商中的一个领先选项；本章的实践方法适用于无论你选择哪个模型。

关键原则

把模型锚定在可信的知识上，而不是依赖它所记住的内容。
把提示和上下文当作经过工程设计、有版本管理的产物，而不是随手写的字符串。
假设模型可能出错或被操纵；验证输出并约束行为。
只给模型它所需要的上下文和工具，不多不少，以降低出错概率和攻击面。
持续用离线测试集、在线指标和人工判断进行评估。
对有实质影响的输出，让人始终参与其中。
把模型设计为一个可信系统之内的一个不可信组件。

建议

有意识地设计提示、管理上下文

把提示当作代码来对待：将它们存储在版本控制中，评审其变更，并对照一套示例进行测试。清晰地组织每一个提示：角色和任务、约束条件、格式要求，以及在有帮助的地方给出示例。把上下文窗口（模型一次能够考虑的固定文本跨度）当作一种稀缺资源来对待。纳入最相关的信息，用心安排其顺序，剔除噪声，因为无关或过多的上下文会降低质量、抬高成本。对于多轮对话的应用，要显式地管理对话状态，对历史内容进行摘要或截断，使其保持在限制范围内，同时保留重要的部分。优先选择清晰的指令和少样本示例（在提示中包含少量已完成的示范），而不是那些一旦模型更换就会失效的花哨技巧。

用检索增强生成（RAG）来锚定答案

对于知识密集型任务，从一个可信的语料库中检索相关文档，把它们作为上下文提供给模型，并指示模型只依据这些材料作答，并注明来源。RAG 让知识保持最新而无需重新训练，把答案限定在经批准的内容范围内，并支持引用和核实。要在检索质量上投入：合理地切分文档，选择适合你所在领域的嵌入（把相近含义映射到相近位置的数值向量表示），并检查检索到的段落是否真的包含答案，因为建立在错误段落之上的流畅答案比没有答案更糟糕。当没有找到任何相关内容时，要让系统如实说明，而不是凭空编造内容。

有节制地构建智能体（agent）和工具使用

LLM 能够调用工具（搜索、数据库、计算器、内部 API），也能够被组合成能够多步骤规划和行动的智能体。这增加了真正的能力，但也成倍地放大了风险：每一个工具都是一个出错或被操纵的模型造成伤害的又一条途径。要用精确的模式（schema）定义工具，验证每一个参数，应用最小权限原则，并对诸如发送通信或转移资金等有实质影响的操作要求确认或人工批准。要让智能体的循环保持有边界、可观测、可中断。在追求开放式的自主性之前，先从范围严格限定的单一用途工具开始。

添加护栏并验证输出

用多层防御把模型包裹起来。在输入端，过滤并检测提示注入，尤其是在不受信任的内容（网页、用户文档）进入上下文时。在输出端，对照模式验证结构，对照来源核实主张，过滤不安全或不合规的内容，并在验证失败时拒绝或重试。对于结构化输出，要解析和核实，而不是信任模型的格式化结果。绝不要让未经验证的原始模型输出触发不可逆的操作。要把幻觉缓解当作一种通过锚定、引用、验证和人工审查来实现的系统属性，而不是模型自己能够管理好的东西。

离线评估、在线评估，并结合人工评估

构建一套由代表性输入以及已知正确或按评分标准打分的输出组成的评估套件，并在每一次提示或模型变更时运行它（离线评估）。用诸如任务成功率、升级率和用户反馈等指标衡量生产环境中的真实行为（在线评估）。对于主观质量，使用人工评审员，并谨慎地使用基于模型的评分。评估是让你能够放心地改动提示和模型的安全网。没有它，你就是在盲飞。

权衡：利与弊

选择	优点	缺点	最适用场景
纯提示词方案	简单、快速、改动成本低	锚定有限，可能产生幻觉	宽泛的任务，风险较低
RAG	内容新鲜、有据可依、可引用	检索很难做对	知识密集型、注重事实的任务
带工具的智能体	能力强，能够行动	攻击面更大，更难控制	有护栏、范围明确的自动化场景
更大、更强的模型	质量和推理能力更好	成本和延迟更高	复杂或高风险的任务
更小、更便宜的模型	快速且低成本	在困难任务上表现较弱	高流量、简单的任务

核心张力在于能力与控制、成本之间的对抗。更强的自主性和更大的模型能带来更多价值，但也要求更多的护栏、更多的评估和更多的资金。通过 RAG 进行锚定能提升可信度，代价是检索工程的投入。正确的平衡点取决于风险高低：高风险的应用会倾向于锚定、验证和人工监督，即便这意味着更高的成本。

与团队讨论的问题

一个 LLM 功能在面向公众之前，必须达到怎样的准确性和锚定标准，由谁来签字确认？ 一个引用了错误来源或编造出一项政策的流畅答案，比没有答案更糟糕，而在政府场景中，一条捏造的引文不是一个缺陷，而是一次法律事件。对于大型团队而言，一个明确的标准能阻止每个小组按自己的感觉设定私有门槛。带上你们对”足够锚定”的定义：是否每一项主张都必须能追溯到一个检索到的、经过核实的来源，检索一无所获时系统是否必须拒绝作答，以及你们的对抗性评估集实际覆盖了什么。要观察的信号是，当前是否有人能够未经回归测试就把一次提示变更直接推送给用户。如果风险涉及法律或安全，答案应当是让风险最高的输出在发布前经过一位拥有实质权力的人工审查员。
我们的哪些 LLM 功能其实是隐性的智能体，每一个工具是否都被赋予了最小权限、对不可逆操作是否设有人工把关？ 任何让模型能够调用工具、或能够多步骤行动的功能，都已经跨入了智能体的领域，而每一个工具都是一个出错或被操纵的模型造成伤害的又一条途径。对于把 LLM 接入内部 API 的企业而言，这个问题揭示的正是”简单助手”这个标签所掩盖的风险。带上模型能够调用的每一个工具的清单、其参数验证方式、其权限范围，以及哪些操作（发送通信、转移资金、修改记录）需要确认。讨论智能体的循环是否有边界、可观测、可中断。答案应当是收紧权限范围，并在任何当前无需人工批准即可触及有实质影响或不可逆操作的地方添加人工审批关卡。
鉴于一个建立在错误段落之上的自信答案看起来一切正常，我们要如何在一天之内察觉我们的检索质量已经下降？ 只有当检索真正找出包含答案的那个段落时，RAG 才能让答案变得可信，而检索会在文档发生变化、切片过时，或嵌入偏离你所在领域时悄悄腐化。由于模型仍然会在糟糕的上下文之上写出流畅的文字，用户可能要等到信任已经流失才会抱怨。带上你们当前对检索延迟和召回率的度量、你们如何检查检索到的段落是否真的包含答案，以及索引的新鲜度如何跟上文档的变化。对于高风险或面向公众的部署，讨论是否为审计目的记录了检索到的来源，这样你才能把一个糟糕的答案追溯到它对应的糟糕段落。如果你们完全没有对检索进行评估，那你们的锚定就是靠信念在支撑。
我们是把提示、上下文和评估集当作有版本、有评审的产物来对待，还是任由它们像散落在笔记本和聊天记录中的字符串？ 当提示在各团队之间无版本管理、重复地蔓延开来时，一处的修复永远无法传达到其他地方，也没有人能够复现上个季度系统被要求做的事情。对于大型团队而言，一个共享的提示注册表，以及一套在每次变更时都会运行的回归测试套件，正是让你能够更换模型或编辑指令、而不会悄悄破坏两个团队之外的某个功能的关键。相互竞争的拉力是速度：工程师在能够粘贴一个提示就直接上线时迭代最快，因此要就快速实验和任何触及用户的东西之间的界线达成一致。带上你们的提示今天实际存放在哪里、是否有一套评估集在把关变更，以及你们如何为检索语料库和提示一起设定版本。在企业和政府场景中，还要加上审计要求：你可能需要在数月之后准确地展示是哪个提示、哪些来源产出了某个特定输出，而一个你无法重建的提示，就是一条你无法辩护的记录。
随着流量增长，我们要如何在不悄悄降低质量的情况下控制推理成本，谁负责模型选择的决策？ LLM 功能的总拥有成本主要由按次调用的推理成本主导，在试点阶段看起来微不足道的成本，在生产规模下会迅速累加，诱使团队悄悄降级到一个更弱的模型，并寄望没有人注意到质量的滑坡。对于一个大型组织而言，让每个团队凭感觉挑选模型和成本上限，既会带来出乎意料的账单，也会导致质量不一致。这里真实的权衡是能力与成本、延迟之间的取舍：一个更大的模型在困难任务上推理得更好，一个更小的模型在简单任务上更便宜、更快，而缓存、路由和检索范围都会影响这个数字。带上每个已解决任务的成本、按模型档位在你们评估集上的质量表现，以及提示或上下文膨胀在哪里推高了 token 花费。在企业和政府预算中，要指明谁批准模型选择和支出上限，因为一条没有人负责的成本线，就是一条在流量翻三倍时没有人能够控制的成本线。
哪些敏感数据能够到达模型，这些数据流向何处，我们能否证明它始终保持在边界之内？ 每一次提示、检索到的文档和工具结果，都可能把个人或机密数据带入模型，如果使用的是托管供应商，还可能带出你的边界之外，而这里的一次泄露是一次法律或安全事件，不是一张缺陷工单。对于把 LLM 接入内部系统的大型团队而言，风险往往藏在管道之中：一个包含了某个特定用户本不该看到的记录的检索语料库，或者捕获了原始输入的日志。这里的张力是能力与暴露风险之间的取舍，因为脱敏和严格限定范围可能会削弱你正在构建的那个功能。带上一份数据流图，说明什么内容进入了上下文、供应商的数据保留和训练条款，以及你们如何对敏感字段进行脱敏、限定范围和记录日志。在受监管和公共场景中，要把这个问题与数据驻留规则、记录保留义务，以及合同中对供应商如何使用你的数据的限制关联起来，因为一项你无法举证的监督，就是一项你实际上并不具备的监督。

行业视角

初创企业。 交付一个紧扣你核心价值的、范围狭窄的 LLM 功能，建立在一个托管模型之上，对你自己的内容进行检索，并把提示保存在 git 中、置于一层薄薄的接口之后，这样你就能更换供应商。在每次变更之前，对一份由真实问题组成的小型评估文件进行测试，过滤用户粘贴的文本以削弱提示注入的风险，并严格设定每月支出上限。要抵制住构建智能体和自建模型的诱惑：一个你无法监督的、无边界的工具调用循环是一项负债，而不是一个演示亮点。

中小企业。 你很可能没有机器学习专家，因此应购买已经嵌入在你已在使用的工具中的 LLM 功能，而不是自己组建团队去构建。把风险表述为一个直白的问题：一个自信但错误的答案会在哪里让你失去一位客户，谁在输出发出之前对其进行检查。优先选择那些会展示其来源、允许你让人工参与其中、并且在 AI 出问题时能够轻松关闭它的供应商。

大型企业。 问题在于跨众多团队的规模化：发布 RAG、护栏和工具模式的共享模式，再加上一套通用的评估工具和提示注册表，这样每个小组就不必各自重新发现同样的失败模式。明确地为推理成本和人工审查编列预算，把接口层标准化，使模型保持可替换性，并对智能体进行中心化治理，应用最小权限、有边界的循环和审计日志。要把 LLM 功能当作一个带有指标和终止标准的组合来管理，而不是一堆散乱的试点项目。

政府。 透明度、采购规则和问责塑造着每一个选择。要严格地锚定在经批准的来源并附带引文，在检索一无所获时拒绝作答，并禁止模型陈述它无法引证的法律条文。要让一位负责任的官员审查有实质影响的输出，为审计记录输入和检索到的来源，在每次发布前运行一套对抗性评估集，并要求在合同中披露模型的局限性和数据处理条款。

示例

初创企业。 一家三人的开发者工具初创公司在其自有文档之上添加了一个聊天助手，让用户不必再为基本问题发邮件询问。它使用了 RAG，让每个答案都引用一个具体的文档页面，并指示模型在检索一无所获时说”我不确定，这是你可以询问的人”，同时把提示保存在 git 中。在每次变更之前，它会对照一份由真实用户问题组成的小文件运行这些提示，以捕捉回归问题，并过滤用户粘贴的文本以削弱提示注入。这个助手处理了常见问题，并悄悄地把其余问题转发到创始人共享的收件箱中。

大型企业。 一家软件公司在其产品文档之上构建了一个内部支持助手。它使用了 RAG，让答案引用具体的文档页面，指示模型在检索失败时说”我不知道”，并核实每一个被引用的来源确实存在。提示被纳入版本控制，并在每次变更时对照一套由真实支持问题组成的套件进行测试。该助手挡掉了常规工单，把任何低置信度的情形升级给人工客服，同时在线指标持续跟踪解决率和纠正率。

政府。 一个公共机构部署了一个 LLM 助手，帮助工作人员起草对公民咨询的回复。锚定是严格的：模型只能依据经批准的指导材料、并附带引文来撰写回复，并被禁止陈述任何在检索到的来源中不存在的政策内容。一位负责任的官员会在每一份草稿发出之前进行审查。输入过滤能够防范来自公民提交文档的提示注入，输出被记录以供审计，并且在每次发布前都会运行一套包含对抗性和边界情形查询的评估集，以确认系统会拒绝就法律事项进行揣测。

商业案例：动机、投资回报率与总拥有成本

LLM 应用通过自动化语言密集型的工作来实现投资回报：回答问题、总结文档、起草内容，以及从非结构化文本中提取结构。价值体现为被挡下的工单、更快的起草速度、更少的人工审查，以及新的自助服务能力。因为通常没有训练这一步骤，实现首次价值所需的时间很短，这是一个主要的吸引力。

然而，总拥有成本主要由持续的推理成本、检索基础设施、评估流水线、护栏系统和人工审查所主导。按次调用的成本在规模化之后会迅速累加，一个缺乏监控的应用可能会逐渐漂移到不安全或代价高昂的行为。不采用的代价是在服务质量和员工生产力上落于人后。草率采用的代价是一次公开的幻觉事件或一次数据泄露。向领导层陈述这个案例时，要把一个具体的生产力目标与一份具体的安全和评估计划配对，并为维持价值持久性所需的护栏和人工监督编列预算。

反模式与陷阱

信任流畅的输出。 把自信、写得漂亮的文本误当作正确的文本。
没有检索评估的 RAG。 假设检索是有效的，却从不检查它是否找出了正确的段落。
对提示注入视而不见。 把不受信任的内容喂进提示，却没有任何防御措施。
无边界的智能体。 让智能体在没有限制或人工批准的情况下采取有实质影响的操作。
没有评估工具。 凭感觉改动提示和模型，没有任何回归测试。
提示蔓延。 提示分散、无版本管理，在各团队之间重复。
过度自动化。 把人从承担法律或安全责任的决策中移除。

成熟度模型

启动。 在孤立的项目中临时地编写提示；没有锚定、护栏或评估；提示存放在任何人随手粘贴的地方，幻觉是在生产环境中才被发现的。
发展。 一些团队添加了 RAG 和提示版本管理、基本的输出验证，以及一个小型的人工评估集，但做法因团队而异，依赖于个别的推动者，而不是共享的期望。
标准化。 关于 RAG、护栏、工具模式和提示版本管理的文档化模式在整个组织范围内得到强制执行；自动化的离线评估在每一次提示或模型变更时运行；高风险的流程配有在线指标和人工审查。
管理。 这个组合被对照基线进行度量：检索召回率、幻觉率和拒答率、注入防御覆盖率、按次调用的成本和延迟，以及升级率和纠正率，都在仪表盘上被跟踪；发布关卡和终止标准基于证据而非意见触发，一次回归测试运行会阻止任何让某项指标朝错误方向移动的变更。
编排。 持续的离线和在线评估与业务成果挂钩；注入防御、智能体和锚定机制都受到治理并可被观测；组织例行地淘汰、重新调优和重新界定 LLM 功能，并随着质量、成本和风险的变化而更换模型。

讨论思路

你们如何决定哪些输出在使用前需要人工审查？
在一个答案能够展示给用户之前，你们对”足够锚定”的标准是什么？
当不受信任的内容必须进入上下文时，你们如何防御提示注入？
什么时候一个智能体所增加的风险是值得的，相对于一个更简单的单次调用设计？
你们如何在规模化的情况下评估主观质量，而不过度依赖基于模型的评分？
你们如何在众多团队之间保持提示的可维护性和一致性？

关键要点

可靠性来自围绕模型的工程实践：上下文、锚定、护栏和评估。
RAG 把答案锚定在可信的来源上，并支持引用和核实。
把模型当作一个不可信的组件；验证输出并约束工具的使用。
给智能体最小权限、有边界的循环，以及对有实质影响的操作的人工批准。
持续地进行离线评估、在线评估，并结合人工评估；这正是让变更变得安全的关键。

参考资料与延伸阅读

Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
Jason Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.
OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
Chip Huyen, AI Engineering: Building Applications with Foundation Models.
Anthropic, Building Effective Agents (engineering guidance).
Louis-François Bouchard and Louie Peters, Building LLMs for Production.