收益：
- 可以设计端到端架构，将法学硕士功能从想法转化为生产
- 建立验证执行、人工批准和跟踪（日志记录/指标）层
- 边界将道德和隐私原则转化为生产决策
在前面的十个单元中，我们一一学习了各个部分：请求结构、代币经济学、流程、系统提示、模型选择、缓存、批处理、错误管理、安全密钥和自动化。在最后一个单元中，我们将各个部分结合起来并建立了整体架构，该架构具有从想法到生产的法学硕士特征。生产不同于“工作演示”：验证是强制性的，输出必须受到监控，边界和道德原则必须嵌入决策中。该单元为模块的承载柱；之前的一切都聚集到了这里。
生产架构的层次
扎实的法学硕士资格大致由五个层次组成：
- 输入层：收集数据、清理数据、屏蔽敏感区域、仅传输必要的数据。
- 模型层：选择正确的模型（单元5）、设置系统提示和参数（单元4）、缓存（单元6）。
- 验证层：根据架构/规则、来源和人工批准（如有必要）检查输出。
- 动作层：通过经过验证的输出执行动作；捕捉高影响力的动作。
- 监控层：记录并衡量每一次调用、成本、错误和质量。
这些层是一个管道；每个都检查前一个的输出。
为什么需要验证？
法学硕士可以产生流畅但有时不准确的输出。这称为幻觉：模型可能会伪造看似真实但事实并非如此的信息。在聊天游戏中这是可以忍受的；在生产系统中（发票、健康、法律、财务）是不能容忍的。事实证明，盲目的不可靠；已确认。
验证层（按影响增加）：
- 格式/架构验证：输出是否符合预期的 JSON 架构？ （结构化输出很大程度上保证了这一点。）
- 规则/逻辑验证：值是否合理？ （金额是否为负数、日期是否为未来、类别是否有效？）
- 来源验证：该声明是否基于所提供的文档？模型是否说了文档中没有的内容？
- 人工批准：专家审查影响较大或模棱两可的决策。
注意：“模型这么好，不需要进一步验证”是最危险的生产谬误。无论模型有多好，验证层都是高影响力决策中的安全网。即使一个错误的自动决策也可能会夺走所有节省的时间。
人在环
并非每个决定都必须是完全自动的。在人机交互方法中，模型加快了工作速度，并且得到了人类的认可。正确的平衡取决于决策的影响以及模型对该任务的可靠性。
该决定的影响
方法
低（标签建议、草稿）
全自动化；错误是廉价且可逆的
中（路由、优先级）
自动化+采样控制
高（金钱、合同、健康、删除）
人类的同意是强制性的；该模型仅表明
监控：您无法管理您看不到的内容
在生产中，您必须监控每个调用。如果没有监控，您就无法提高成本、质量或及早发现问题。要记录的关键指标：
- 使用/成本：每个请求和总代币、模型分布、每日支出。
- 延迟：平均和最坏情况的响应时间。
- 错误率：429/500 率、重试、放弃。
- 质量：验证层的拒绝输出率、人工批准的纠正率、用户反馈。
提示：不要将敏感数据（个人信息、密钥）写入监控日志。考虑保密范围内的日志；如有必要，通过屏蔽进行记录（单元 9）。
道德与界限
道德责任与技术准确性一样是生产决策的一部分：
- 透明度：用户应该知道他们正在与人工智能还是人类交谈。
- 公平性和偏差：模型可能带有来自其训练数据的偏差；监控高影响力决策（招聘、信贷）中的歧视性后果。
- 责任：如果自动决策造成损害，您需要承担责任； “模型是这么说的”并不是辩护。
- 接受限制：模型无法可靠地执行某些任务；不将它们自动化也是一个设计决策。
可复制模板
# 验证清单（输出生成后）1) 模式有效吗？ （结构化输出验证）2）这些值有意义吗？ （规则检查：范围、日期、枚举）3) 声明是否基于来源？ （文档中没有则拒绝）4）影响大吗？ → 发送以供人工批准5) 如果全部通过 → 允许操作，保存
# 强制依赖源的系统提示仅依赖所提供文档中的信息。不要添加文档中未包含的任何内容。如果文档中没有信息，请写“未在文档中找到”。永远不要猜测或编造事情。
# 人工批准阈值（决策规则）如果决策类型为[金钱、合同、删除、健康]→强制人工批准IF model_trust <阈值或验证“不确定”→提交人工批准OTHER→自动应用+抽样控制
# 跟踪日志模板（写入敏感数据）{ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected| human", "cost_usd":... } // 永远不会写入个人数据和密钥
弱提示/强提示（生产可靠性）
# 弱（无验证，无来源，自动应用）评估此请求，做出退款决定并申请。
# 强（基于来源，生成建议，留给人工批准）仅根据退货政策文档评估此退货请求。建议有理由的决定但不实施：{"recommendation":"approve|reject","reason":"...","policy_clause":"..."}。如果政策文件没有明确依据，则给予“不清楚”。代表将批准最终决定。
强大版本；它将决策归因于来源，将模型定位为“建议者”而不是“执行者”，并将高影响力的步骤置于人类批准之后。这就是生产可靠性的本质。
三个迷你箱
情况 1 — 验证层保存的日期。一家金融科技公司正在使用该模型对交易描述进行分类并创建自动会计记录。他们添加了规则验证：一旦模型输出错误的金额（12,500，而不是文档中的 1,250），“金额与文档不匹配”规则会拒绝输出，记录就落到了人类手中。如果没有验证，错误的记录就会默默地进入系统。
案例2——逃犯被监控抓获。 SaaS 团队设立了一个监控面板；一天早上，每日费用增加了两倍。从日志中可以看出，客户端进入了一个循环，并发送了数千次相同的请求。他们增加了配额和重复数据删除功能；问题在数小时内得到解决。如果没有跟踪，该账单在月底将会是一个惊喜。
情况 3 — 接受限制。一家医疗保健初创公司计划全自动提出诊断建议并将其展示给患者。在道德和责任审查中，他们认为这是禁止的：该模型仅向医生提供摘要和可能的要点，由医生做出诊断。不将工作自动化也是一个成熟的设计决策。
常见错误
- 跳过验证：盲目应用输出，说“模型很好”。
- 自动化高影响力的决策：人类的批准对于金钱/健康/法律至关重要。
- 不监控：成本和质量问题发现较晚。
- 将敏感数据写入日志：侵犯隐私；通过屏蔽它来保存它。
- 不要试图依赖来源：模型可能会弥补文档中没有的内容。
- 忽略限制：不将某些任务自动化是正确的决定；透明度和责任是你的。
更深入：发布管理、回滚和增量部署
将 LLM 功能投入生产并不是设置好之后就忘记它；而是将其投入生产。是随着时间的推移安全地修改实时系统。它具有三个支柱。
版本控制。您的系统提示、模型选择和验证规则会随着时间而变化。对每个重大更改进行版本控制并记录哪个版本是实时的。如果有一天质量下降，“我们改变了什么？”您应该能够在几分钟内回答这个问题。在无版本系统中，找到回归的根本原因需要几天的时间。
回滚。如果新的提示或模型在实时情况下表现比预期差，您应该能够快速恢复到以前的众所周知的版本。没有回滚计划的变更就是盲目地接受现实风险。 “我改变了一些东西，它变坏了，我无法回去”是最昂贵的生产场景。
逐步推出。您不必立即对所有流量应用更改，而是先将其推广到一小部分（例如 5%）并监控指标（质量、成本、错误）。如果效果好，就增加百分比；如果效果好，就增加百分比。如果坏了，你可以把它拿回来，只影响一小部分。这极大地限制了风险。
这三种实践结合了之前所有单元的技术：评估（单元 5）提前测量变化，监控（该单元）在传播过程中提供早期预警，验证层在错误输出变得可操作之前捕获它们。生产不是一个单一的正确设置；而是一个过程。这是一种持续的纪律，可以自信地测量、监控和改变。整个模块是为了让你建立这个纪律。
综上所述
生产不仅仅是一个工作演示：它是输入、模型、验证、操作和监控层的管道。未经验证，输出不可靠；高影响力的决策与人类的批准息息相关；每个呼叫的成本、错误和质量都会受到监控。道德、透明度、偏见控制、问责制和接受限制是技术决策的组成部分。本模块中学到的每一部分都汇集在这个整体设计中。
应用任务
端到端设计 LLM 功能。 (1) 填写您的具体任务的五个层（输入、模型、验证、操作、监控）。 (2) 按影响标记哪些决策需要人工批准。 (3) 编写至少三项验证检查（模式、规则、源）。 (4) 确定您将跟踪的关键指标以及您不会记录的内容。 (5) 在此功能中写下您接受的限制和道德原则。
清单
- [ ] 我可以设计五层生产流水线。
- [ ] 我可以根据架构、规则和源验证输出。
- [ ] 我可以根据决策的影响设置人工批准阈值。
- [ ] 我监控成本、错误和质量，并练习不在日志中写入敏感数据。
- [ ] 我可以将道德、责任和界限转化为生产决策。
模块考试
1. LLM 聊天 API 中的“系统”角色有什么作用？
- A) 为模型提供适用于整个对话的永久指示和行为规则 ✔
- B）保留用户写的最后一个问题
- C）存储模型产生的响应
- D) 加密 API 密钥
描述：系统角色为模型提供适用于整个对话的持久指令、个性和规则；这是一个高级重定向，与用户消息分开。
2. 为什么每次API请求时都会重新发送会话历史记录（之前的消息）？
- A) 服务器删除历史记录时需要备份
- B) API调用是无状态的； ✔ 每个请求都会重新发送上下文，因为模型不记得历史记录
- C) 仅用于开发票，对模型没有影响
- D) 必须发送历史记录以避免减慢响应速度
说明：LLM API调用是无状态的；该模型不记得前几轮，因此每次请求时都会重新发送所有相关历史记录以保留上下文。
3. LLM定价中的“代币”是什么？
- A) 用于登录API的一次性密码
- B) 每次请求支付固定费用
- C）模型处理文本的最小单元；通常对应单词部分✔
- D）仅测量输出长度的单位
描述：Token是模型处理文本的最小单位；它通常对应一个单词的一个片段，输入和输出都是根据token的数量来收费的。
4. 为什么大多数 LLM 提供商的输出令牌比输入令牌更贵？
- A）输出令牌总是比输入长
- B) 输入代币是免费的
- C) 输出令牌通过互联网发送两次
- D) 单位成本较高，因为输出生成需要对每个代币进行额外计算 ✔
说明：每一个输出token都需要模型进行一步一步的生成（计算）；这种生产成本比一次处理所有输入要高，因此输出单价通常更高。
5. 在什么情况下使用流媒体最有益？
- A) 长答案；减少感知延迟并防止超时 ✔
- B) 只能用非常简短的一个词来回答
- C）将成本降低到零
- D) 隐藏 API 密钥
描述：在长响应中，流式传输通过使第一个单词立即出现来减少感知延迟，并防止在较大 max_tokens 值时发生 HTTP 超时。
6. 在现代模型中增加“努力”参数通常会产生什么影响？
- A）始终缩短答案
- B) 自动轮换 API 密钥
- C) 它只会降低输入代币的价格
- D) 增加思考深度和代币支出；它可能会提高质量，但也会增加延迟和成本 ✔
描述：工作量参数调整模型对任务的思考深度以及将花费多少代币；升级可能会提高质量，但也会增加延迟和成本。对于简单的任务，只需付出很少的努力就足够了。
7. 对于简单、大批量的分类任务，通常最经济有效的方法是什么？
- A）始终使用最昂贵和最强大的型号
- B) 每个请求同时调用所有模型
- C) 通过一点评估来验证它，选择完成任务的最轻/最便宜的模型 ✔
- D）将 max_tokens 值保持不必要的过高
解释：如果任务并不复杂，选择一个更快、更便宜、可以轻松完成任务的模型（例如俳句类）而不是使用最昂贵、最强大的模型将显着降低成本。
8. 提示缓存在什么场景下降低成本最大？
- A) 当在多个请求中重复使用大型且固定的上下文时 ✔
- B）当每个请求发送完全不同的文本时
- C) 当只发出一个请求时
- D) 减少输出代币
说明：缓存是前缀匹配；如果在许多请求中重用大型的、不可变的上下文（系统提示符、文档），则从缓存中读取的内容只是全价的一小部分（~0.1x）。
9. 我应该如何编辑提示以使提示缓存命中？
- A) 将可变内容放在开头，将固定内容放在结尾
- B) 在每个请求的系统提示中嵌入当前日期和时间
- C) 将固定内容（系统提示、文档）放在开头，可变内容放在结尾✔
- D) 根据每个请求更改工具列表的顺序
说明：由于缓存是前缀匹配，固定/不变的内容（系统提示、文档）被初始化；可变内容（日期、用户问题、请求ID）放在最后。即使一开始改变了一个字节也会使缓存失效。
10. 批处理最适合什么类型的工作负载？
- A) 实时聊天，用户期望屏幕上立即得到响应
- B）只有一个简短的问题
- C) 生成 API 密钥
- D) 能够容忍延迟、工作量大且不需要立即得到结果的工作 ✔
描述：批处理适合批量大、不需要立即响应、容忍延迟的作业；一段时间后即可交付结果，但单位成本通常较低。
11. 如何自信地匹配批次中结果属于哪个请求？
- A) 请求的发送顺序（位置）
- B）答案的长度
- C) API 密钥的最后 4 位数字
- D) 为每个请求提供唯一的custom_id ✔
备注：批量结果返回的顺序可能与提交顺序不同；因此，有必要通过 ID（而不是位置）来匹配结果，并为每个请求提供唯一的 custom_id。
12. 当您收到来自 API 的 429（速率限制）错误时，建议采取什么行为？
- A）通过同时发送更多请求来强制
- B) 按照“重试后”标题，使用指数退避重试 ✔
- C) 完全取消请求并向用户显示错误作为崩溃
- D) 更改 API 密钥
解释：429是可重试错误；正确的方法是使用指数退避重试，尊重重试后标头。大多数官方 SDK 会自动执行此操作。
13. 以下哪些 HTTP 错误代码通常被认为是可重试的？
- A) 400（无效请求）
- B) 401（认证错误）
- C) 529（服务器超载）✔
- D）404（未找到）
说明：429（速度限制）、500（服务器错误）和529（过载）是临时错误，可以通过后退重试。像 400 和 401 这样的错误是请求/身份问题；再试也解决不了问题。
14. 以下哪项是管理 API 密钥的安全方法？
- A) 存储在环境变量/隐藏管理器中，不嵌入代码中并定期轮换✔
- B) 将密钥直接写入源代码并发送到存储库
- C) 将密钥放入客户端（浏览器）JavaScript
- D) 通过电子邮件与整个团队共享单个密钥
描述：密钥永远不会写入源代码或存储库；它存储在环境变量或隐藏管理工具中，授予最小权限，并定期轮换。
15. 在隐私方面，LLM 与自动化工具（n8n、Zapier、Make）集成的最佳方法是什么？
- A）将所有原始数据发送到模型，即使没有必要
- B) 在流程步骤中以纯文本形式写入 API 密钥
- C) 最小化和屏蔽敏感数据并将密钥存储为秘密凭证 ✔
- D) 将个人数据永久保留在流历史记录中
描述：随着数据输入自动化通过第三方系统和模型，敏感/个人数据需要最小化、屏蔽并仅发送必需的字段； API 密钥还作为秘密凭证存储在工具内。
16. 为什么在基于 LLM 的生产功能中必须验证输出？
- A）只需要格式化，因为模型永远不会出错
- B) 因为模型可以流畅地生成，但有时会出错；架构/规则必须经过资源和人员批准的审核 ✔
- C) 应避免验证，因为它只会增加成本
- D) 验证只是为了减少代币数量
描述：法学硕士可以产生流畅但有时不准确（幻觉）的输出；所以它出现在具有重大影响力的决策中；必要时应通过架构/规则检查、源验证和人工批准对其进行审核。