Lec 9LLM 代码架构
Lec 9 LLM 代码架构
本节学习目标：
- 技术路径 掌握 LLM 推理的基本技术方法，为项目构建 AI 功能（AI-powered）
- 提示与评估 理解如何设计和迭代高效提示词
- 实际考量 比如安全、成本等等，这样你不容易犯错
TL;DR
- LLM 调用应放在服务端，并把鉴权、输入验证、模型选择、结构化输出校验和真实业务动作分成清晰边界；模型输出始终按不可信输入处理。
- Prompt 是需要版本化和回归测试的接口规格，而不是一次性的自然语言咒语；质量判断依赖代表性样例、边界案例和明确评分标准。
- 采样参数、few-shot、best-of-N 与自动提示优化都只是在质量、稳定性、成本和延迟之间取舍，不能替代任务定义与评估。
- 自托管、统一网关或闭源 API 的选择应同时比较能力、隐私、运维、可用性和总成本；关键工具调用仍需权限限制与用户确认。
推理调用的基本结构
应用通常经由服务商 API 调用模型：将系统指令、用户输入和必要上下文组成请求，接收文本或结构化响应。模型调用应放在服务端：API key 不可放进浏览器；服务端也更适合做权限检查、速率限制、日志与成本控制。
模型提供商、统一网关（如可切换多模型的 API）和自托管开源模型是不同部署选择。选择时比较质量、上下文长度、工具支持、价格、数据处理约束、延迟与可用性，而不是只看排行榜。
API、编排与模型选择
课件用 OpenAI 风格 API 讲解，但大多数供应商调用结构相似；OpenRouter 一类统一网关可让应用以相近接口切换不同厂商的模型。多步骤 agent 的“调用哪个工具、何时再次推理、怎样保存状态”可以交给 agent orchestration library，也可以由应用自己实现。无论使用哪种库，业务的权限、验证和失败处理仍属于应用设计，不能外包给编排框架。
何时自行托管？
课件区分：open-weight 指公开模型权重；open-source 通常还公开训练所需的完整材料。自行托管的合理理由包括：
- 已有大量 GPU、推理规模很大，边际成本可能更低；
- 数据必须完全留在内部；
- 需要离线/端侧推理；
- 研究、微调权重或观察模型内部行为。
代价是部署、扩缩容、监控和安全都需要自己承担，且对多数任务，闭源前沿模型仍可能更强。因此这是成本、隐私、能力与运维负担的选择，而不是“开源必然更好”。
Prompt 是接口设计
一个可维护的 prompt 至少明确：角色/任务、输入数据及其来源、输出格式、限制条件、示例与不确定时的行为。要求 JSON/字段化结果时，必须在代码中验证 schema；模型输出始终是不可信输入，不能直接拼接进数据库查询、HTML 或工具调用。
从模型机制看，prompt 的作用是建立一个让模型更可能续写出正确 token 序列的上下文。因此模型本身、训练数据、配置、措辞、语气、结构和附加上下文都会影响结果；prompt engineering 只能是可实验、可回归的迭代过程，不是凭感觉找到一句“神奇咒语”。
迭代靠代表性测试集：收集真实任务、定义“好结果”的标准、记录模型/提示/参数版本，改变一个变量后再比较。不要只凭一个漂亮 demo 判断效果。
课件中的常用推理技巧
- role prompting：指定“编辑、客服、领域专家”等工作角色，能改变风格与任务聚焦；但这不意味着模型真的复制了真人的知识或人格。
- step-back prompting：先让模型提炼高层原则/计划，再将该结果用于具体任务；适合复杂、创造性问题。
- best-of-N / self-consistency：以非零随机性多次生成，再用规则或 judge 选优；可提高重要任务质量，代价是延迟与费用。
- 一次产生多样输出：需要多种方案时，通常一次请求多个不同候选比多次相同请求更容易避免重复。
temperature 等参数控制随机性与多样性：需要稳定分类或结构化抽取时宜低；需要发散创意时才提高。它们是质量—多样性—成本的取舍旋钮，而不是“聪明度”。
Sampling 参数与示例
模型会为每个候选 token 生成概率分布：
- temperature 越低，越偏向最高概率 token；
0是贪心解码，结果更稳定。越高则更随机、更有意外性。 - top-k 只从概率最高的 k 个 token 中采样；
k = 1等价于贪心。 - top-p（nucleus sampling） 只保留累计概率不超过 p 的候选集合。
实际中通常先使用模型默认参数；当 temperature = 0 时，top-k/top-p 不再产生随机采样效果。关键不是每次都调参，而是先确认任务需要的是稳定性还是多样性。
zero-shot 只给任务；few-shot 则附上输入—理想输出示例。课件经验是 3–5 个好示例常有帮助，复杂任务可能需要更多；若希望在真实世界稳定工作，示例必须包含罕见、意外但仍应正确处理的边界情况。
自动优化仍需要评估
课件以 DSPy/GEPA 为例：给定输入、金标准输出和评分方式，系统可从执行反馈中搜索更好的 prompt。其前提不是“让优化器替你想需求”，而是你已经定义了代表性数据集、可测量的正确性和失败成本。
课件中的设施服务邮件分类例子很直观：最初提示只有“判断紧急程度”；优化后补入了领域背景、严格输出格式、low/medium/high 的定义、触发词和安全事故等例子。改善来自明确任务规格与可评估反馈，而非单纯把 prompt 写得更长。应保留训练/开发样例之外的测试集，避免优化器只记住已见案例。
成本、安全与可靠性
- 限制输入长度、缓存可复用结果，并为昂贵任务设置预算和超时；
- 不把密钥、隐私数据或内部提示词随意暴露给客户端/日志；
- 过滤和授权工具调用，关键操作要求用户确认；
- 处理限流、空响应、格式错误与服务不可用，提供非 AI 的替代流程。
一个可落地的调用边界
浏览器：收集用户输入、展示 loading / 输出 / 可编辑草稿
服务端：鉴权 → 验证输入 → 选择模型与 prompt → 调用 API
服务端：验证结构化输出 → 记录必要指标 → 返回受控结果
业务动作：只有经过权限检查与用户确认后才执行这条边界避免 API key 泄露，也将“不可信模型输出”与“可信业务状态”隔开。记录日志时还要避免把敏感 prompt、个人资料和密钥原样写入；指标可记录模型版本、token 数、延迟、错误类型与匿名化评估结果，用于成本追踪和回归测试。
从原型到上线的检查清单
- 任务能否用输入、期望输出、边界样例与失败代价清楚定义？
- 是否有代表性测试集与人工/程序化评分，而非只看 demo？
- 采样参数、模型版本、prompt 与上下文版本是否被记录？
- 是否把密钥、权限校验、schema 验证和工具调用限制在服务端？
- 用户能否理解等待/费用，并在超时、限流或低质量输出时继续完成任务？
我的理解
LLM 架构最重要的分界不是“用了哪一个模型”，而是系统是否把概率性推理隔离在可评估、可替换的边界内。只要 prompt、模型输出和工具请求都经过显式契约，换模型只是实现选择；若业务权限和状态更新直接依赖自由文本，任何模型升级都会成为系统级风险。