第三部分 · 工程上手（核心动手）

课程讲义 · 学习版AI 工程与平台 · F3无需代码基础也能读懂主线

这门课要用绝大多数学员最想要的方式——边做边学——把"数据、训练、推理、RAG、Agent、上线运维"六件事逐一动手示范。学完你能回答三问、办成三事：懂 RAG 三大支柱与每段之坑、懂微调与 RAG 的分工、懂 Agent 靠哪几层"办成事"；并亲手把 RAG 问答跑起来、跑通一次 LoRA、能给推理与 Agent 定一套可观测的评估口径。

逐章推进先读知识小节 → 紧接着做该章实操配套 → 勾选通关卡 → 进下一章
五段式结构每个知识小节统一为：【小目标】【方法论】【知识点】【名词卡】【练一练】
学用一致名词口径与知识库 F3 严格一致，知识不悬空、可直接落回实践

课程地图（学完能得到什么）

怎么学：逐章推进——先读该章的知识小节，紧接着做该章末尾的实操配套，做完勾选通关卡，再进入下一章。若想"先做出东西再补原理"，可以先把第六章低代码 / 第四章 RAG 的实操配套提前做一遍，再回头补齐对应知识。

教材坐标系：本讲义与你的 AI 知识库 F3 工程与平台（F3.1–F3.7）严格对应，观点、边界、信源与库内一致。每个知识小节统一五段式；实操配套里标注「（可选进阶）」的节可选择性深挖。

模块知识域一句话收获知识详解实操配套自查
第一章 数据与标注F3.1模型"吃什么"决定它"长什么样"1.1（1.1.1~1.1.2）1.2 实操配套（60min）1.3 通关
第二章 模型训练与微调★★F3.2用数据把模型调成"你的模型"，含 LoRA 上手2.1（2.1.1~2.1.4）2.2 实操配套（2~4h）2.3 通关
第三章 推理与部署优化F3.3模型怎么"更快更省更稳"地跑起来3.1（3.1.1~3.1.3）3.2 实操配套（45min）3.3 通关
第四章 RAG 检索增强★★F3.4把私有知识喂给模型并防编造4.1（4.1.1~4.1.4）4.2 实操配套（60~90min）4.3 通关
第五章 Agent 系统工程★★F3.5让模型"办成多步实事"而非只答一句5.1（5.1.1~5.1.3）5.2 实操配套（60~90min）5.3 通关
第六章 MLOps 与工具链F3.6+F3.7可上线、可回滚、可观测 + 低代码快搭6.1（6.1.1~6.1.3）6.2 实操配套（45~60min）6.3 通关

第一章 数据与标注

知识域 F3.1 · 模型"吃什么"决定它"长什么样"

1.1 知识详解 · 数据与标注先问"为什么要干净、一致、足够多"，再动手做原料

1.1.1 数据生命周期与质量：为什么"垃圾进、垃圾出"

小目标

这一节点回答最基础的一个问题：数据是怎么决定模型好不好用的？也就是一块乱糟糟的原始数据，怎么被收拾成"机器能学"的样子。

模型不会凭空变聪明，它学到的就是喂进去的数据。数据干净、有规律，学出来的就是干净、靠谱的本事；图省事塞进乱码、错别字、自相矛盾的"垃圾"，它就会把这些"垃圾"当作真理学下去，回答里也全是同样的毛病——这就是"垃圾进、垃圾出"。

对做产品的人来说，数据还有另一层分量：它是最贵、最难攒、又最容易踩合规红线的家底——真实数据买不到、攒得慢、还牵涉隐私；可一旦攒成体系，就是别人很难抄走的护城河。所以当模型表现不对，先怀疑数据、再怀疑模型——大多数情况下问题出在数据。

方法论

一句话结论：数据决定模型的上限，先洗质、再谈规模。意思是，与其急着堆更多数据，不如先把已有的数据洗干净——算力再强、模型再新，也补不回"喂进去的是垃圾"这个硬伤。

具体走一条数据供给管线，前面任何一环出错，后面全白做：

① 采集/获取爬取、委托、开源、用户生成
↓② 清洗与去重 —— 去噪：删乱码/错乱/无意义；去重：删近似重复
③ 标注/结构化打分类标签、填语义字段、标好坏/偏好对、写标准答案
↓④ 质检与一致性 —— 定一套标准，同一份料两个人标得出同一结果
⑤ 进入下游训练（见第二章） / RAG 检索库（见第四章） / 评测集（见第六章评测与观测）

管线上最容易掉进去的"坑"，就是下面四类关键动作：

  • 去重（Dedupe）：近似重复的样本会让模型只记住一种说法、还白费算力。
  • 去噪（Denoise）：乱码、错乱、无意义碎片，按规则或启发式滤掉。
  • 去敏感与合规（Sanitize）：个人隐私、版权、涉政涉敏内容，入库前先做一遍安检。
  • 质检（QC）：做一致性校验 + 人工按比例抽检，作为数据质量的可观测指标。
知识点
  • 质量优先于数量：质量决定数据"干不干净、能不能学"，数量决定"够不够用"。别贪多——一份干净的小样本，常常好过一大堆又脏又乱的大样本。
  • 以数据为中心（Data-Centric AI）：与其拼命堆量，不如先把现有数据洗干净。做得好不好，看它喂出来的模型/评测是否变好——别只看数据自己"看起来不错"。
  • 供给管线一环也不能错：从采集、清洗、标注到质检，前面一环错，后面全都白做。
名词卡
名词一句话白话
Data Quality｜数据质量数据够不够"干净、一致、无偏、可学"。数据不干净，模型会把脏东西当成规律学进去，回答就会出错。
Data-Centric AI｜数据为中心与其堆量，不如先把数据洗干净——因为数据质量决定模型能学到什么上限。
Data Cleaning/Dedup｜清洗与去重去噪（删乱码/错乱/无意义内容）+ 去重（删近似重复样本）。先洗质、再谈规模。
Data Augmentation｜数据增强在已有真实样本上做增删改写来扩充数据量。（≠ 合成数据：增强是改旧样本，合成是造新样本）
易混点数据质量（管"干不干净、能不能学"）≠ 数据规模（管"够不够用"）——先质后量；清洗（"删掉脏的"）≠ 标注（"加上机器能读懂的结构"）。
练一练

微观小实验（聚焦本节点，约 10 分钟）：亲手跑一遍供给管线的清洗段，体会"垃圾进"如何变"相对干净"。

  1. 取一份手头的原始短文本（如会议纪要、一段客服聊天记录）。
  2. 人工去噪：标出/删掉乱码、语无伦次、无意义碎片，数一数删了几条。
  3. 再去重：找出"同一意思说了两遍"的近似重复段落，保留一份、记录去处。
  4. 验证：重读清洗后的文本，回答"同一问题再答的一致性是否明显变好"。这为下节「标注一致性」为什么必须建立在干净料之上埋下直观印象。

1.1.2 标注与合成数据：先把数据"标成 AI 学得懂的样子"

小目标

这一节点回答两件事：为什么给原始文本做标注、让它变成"模型看得懂"的样子；以及当真实数据不够用、又太敏感时，怎么用合成数据造出更多训练素材。原因是：后面要做的微调、对齐、评测，全都建立在"机器能读懂、口径又统一"的标注数据之上——没有标注，这些环节一个都跑不起来。

方法论

主线 A——标注：难点不是"标得对不对"，而是"标得一不一致"。同一批数据，两个人标的结果差别很大，模型学到的是"你标你的我标我的"的那种混乱，而不是真正的规律。要做到一致，靠两条：

  • 机器预标 + 人工抽检：先用模型/规则把大部分标掉提效率，再让真人按比例抽查把关——既省成本，又保证可信。
  • 管好成本：标注很花钱，用"标注规范 + 抽检命中率"来控质量、控工期。宁可少而准，不要多而乱。

主线 B——合成数据（Synthetic Data）：真实数据不够时的另一条来源。专门解决真实数据"稀缺、太贵、太敏感"的问题，比如补足某些类别数量太少、冲淡掉里面的脏数据、或者拿到现实中根本不存在的训练语料。注意两点：

  • 怎么来：用生成模型或规则模板，按想要的分布"造"一批数据，然后回到 1.1.1 那套流程里走清洗、质检，再当下游的输入。
  • 最大的坑是分布偏差：造的分布 ≈ 真实分布，不等于真实分布。模型可能"只认得造出来的那种话术，一遇到真人说话就不灵"。所以必须用少量真实样本做对照基准，把偏差校准回来。
知识点
  • 一致性是标注的质量命门：标注规范写到多细、抽检率定多高、要不要"机器预标+人工把关"，直接决定这批数据最终的质量和花了多少钱。
  • 合成数据利弊并存：能补稀缺、能冲淡脏数据，但"机器味、分布有偏差"是硬伤，必须用真实样本做对照基准。
名词卡
名词一句话白话
Annotation / Labeling｜标注把无结构原始文本加工成模型可学的结构化素材（分类标签、语义字段、偏好对、标准答案），是 SFT/RLHF 的原料。
标注一致性｜质检指标同一批数据多人标注应基本一致；不一致会让模型学到"随机噪声"而非规律。
人工抽检｜质检兜底对机器预标结果按比例人工复核，兼顾效率与可信度；抽检命中率是可量化指标。
Synthetic Data｜合成数据用规则或模型"造出来"而非真实采集的训练/评测数据；真实数据稀缺/涉隐私时的另一条数据来源。
易混点合成数据（造"新样"）≠ 数据增强（改造"旧样"）；人标（最准最贵）≠ 机器预标+人工抽检（效率与成本平衡）。
练一练

微观小实验（聚焦本节点，约 10 分钟）：抓一次"合成数据的机器味"，体会分布偏差。

  1. 打开任意大模型，命令它"扮演用户，用很口语的说法，围绕导购场景问一批多轮问题"，一次生成约 20 条。
  2. 扫一遍，标出其中"太书面、太完整、缺口语情绪"的样本。
  3. 验证：数一数"机器味重"占几成 → 回答"为什么合成分布 ≠ 真实分布，为何必须用少量真实样本当锚点"。

1.2 实操配套 · 数据与标注

目标学完 1.1.1、1.1.2 后马上动手。不写代码，用"你自己的文档"，把本章 1.1 讲的"清洗→去重→标注一致→质检"+合成数据，各亲手做一遍。约 60 分钟。

步骤 1 · 取一份"脏"一点的真实文本（找原料）

  1. 拿出一份你日常的原始资料：一篇会议纪要 / 客服聊天记录 / 群里攒的评价。
  2. 把它复制进一个空白文档，假装它就是你即将喂给模型的"原始数据"。
  3. 有意留意它里面有：错别字、语无伦次、重复段落、零散碎片——这些就是"噪声"和"重复"。

步骤 2 · 亲手做"清洗与去重"（对应支柱一）

  1. 去噪：用笔/文本工具，把乱码、无意义、错乱片段标记或删除。
  2. 去重：找近似重复的段落（同一意思说了两遍），保留一份。
  3. 记录：你删了多少条、为啥。观察：清洗后，内容一致性明显变好。

步骤 3 · 做"标注一致"演练（对应支柱二）

  1. 从清洗后的文本里抽出 5 个句子。
  2. 给它们打标签，例如按"客服意图"归类：[售前咨询 / 投诉 / 售后 / 一般闲聊]。
  3. 找另一个人（同事/朋友）也标一次这同样的 5 句。
  4. 对比你们的标签：一致率有多高？不一致的地方，就是"标注规范没写清"的证据。
你会亲眼看到：一致性差的标注 = 模型学到的噪声。这就是为何"标注规范 + 抽检"重要。

步骤 4 · 造一批"合成数据"，并抓它的"机器味"（对应支柱三）

  1. 打开任意大模型，让它"扮演用户，用各种口语说法，问一个导购多轮问题"（你熟悉的业务）。
  2. 让它一次生成比如 20 条"用户问法"。
  3. 你自己挑 5 条，改成"真实用户会说的样子"。
  4. 观察机器味：合成的提问是不是"太书面、太完整、缺口语情绪"？→ 这印证本章 1.1.2 讲的"合成分布 ≠ 真实分布，要少量真实样本当锚点"。

1.3 自查通关 · 数据与标注

第二章 模型训练与微调

知识域 F3.2 · 用数据把模型调成"你的模型"，含 LoRA 上手

2.1 知识详解 · 模型训练与微调先想清"要不要微调"，再选全参还是 PEFT，最后落到 LoRA 上手

2.1.1 预训练 vs 微调：先想清楚"要不要微调"

小目标

这一节点要回答：在基础模型之上，怎么用数据把模型调成"你产品的专属模型"。价值在于——基础模型只擅长"通用应答"，不会你的领域口径、话术、格式与业务流程；微调是把模型从"通才"调成"懂你的专才"的路径入口。先想清楚"要不要微调"，再谈"怎么微调"。

方法论

先看一条"从零到专属"的训练谱系，微调只是其中一环：

预训练海量语料学通用语言常识，资源重，多为厂商做
↓
微调 SFT用"指令-答案"标注数据，教它跟随指令/领域风格
↓
对齐 RLHF/DPO让输出符合人类偏好与安全底线
↓
适配落地 PEFT/LoRA在既有基座上加小增量，低资源适配 —— 产品侧最常做的一层
怎么读这张图PEFT/LoRA 不是对齐之后又一步——它是实现"微调"这一环的省资源做法（所以常和 SFT 一起出现）。对产品实践，最常见的其实是"拿一个已对齐的开源基座，直接上 PEFT/LoRA 做小适配"。

选型第一逻辑：多数产品级适配，先用 RAG+提示词往往就够了，不必一上来就微调；只有 RAG/提示搞不定、或要深改行为/表达风格/领域术语时，才谈微调——判断标准看你要改的是"知识"（走 RAG）还是"说话风格/行为"（走微调）。

最容易混的一对——微调 vs RAG，务必分清：

RAG（第四章）微调（本章）
改什么改喂给模型的输入（临时注入外部知识）改模型整体权重（永久学进去）
快慢快、可随时更新慢、更贵
适合外部/私有/动态知识改变表达风格、领域术语
结论不是二选一，常结合用
知识点
  • 谱系定位：预训练（学通用）→ 微调 SFT（学指令/风格）→ 对齐（学被接受）→ PEFT 落地（低资源适配）；厂商把多数能力与对齐做进了基础模型。
  • 要不要微调是头号判断：RAG+提示够用就别微调；微调改"表达风格/领域术语"，RAG 改"喂的输入"——不冲突、常结合用。
名词卡
名词一句话白话
Fine-tuning｜微调用数据在基础模型上继续调整权重，让它适配领域/任务；与 RAG 并列的两条主路之一。
SFT｜监督微调用"指令-答案"标注数据教模型跟随指令与领域风格，是产品调到自己的范围最常见手段。
Alignment｜对齐让模型输出符合人类偏好与安全底线（RLHF/DPO）。SFT 教"怎么做对"，对齐教"怎么做被接受"。
RLHF｜人类反馈强化学习用人类偏好训练奖励模型再调优生成；效果强但工程复杂。
DPO｜直接偏好优化绕开显式奖励模型、直接用偏好对优化生成，更简单稳定、更广被采用。
易混点微调改"模型权重"（永久学进去）≠ RAG 改"喂的输入"（临时注入、快、可换）。
练一练

微观小实验（约 5 分钟）：做一次"要不要微调"的选型判断。

  1. 写下你产品里一个"想让模型答得好"的真实诉求。
  2. 套判断口径走一遍：需要"多快好省地加私有/动态知识"→ 走 RAG；还是要"改说话风格/术语/输出格式"→ 才谈微调。
  3. 验证：用一句话给判断落结论（如"这个场景该走 RAG，因为要的是动态知识"）。

2.1.2 全参 vs 参数高效微调（PEFT）：大多数场景其实用不上"全参"

小目标

确定要微调之后，先要回答"调多深"：是把模型的所有参数整体重训（全参），还是只动一小块"增量参数"（PEFT）？这一节点就是在两者之间帮你做选择——选错会白烧算力，选对则又省、又快、还好回滚。

方法论

两条路线的取舍逻辑：

  • 全参微调（Full Fine-Tuning）：所有参数整体重训。效果上限高，但成本高（显存/算力/存储），且风险大——整体重调易发生灾难性遗忘（变笨、产生不可控偏移）。
  • 参数高效微调（PEFT）：只动一小块"增量参数"。参数量小、见效快、易回滚、可多版本并存——对领域风格、输出格式、特定话术这类多数适配需求，往往绰绰有余。

实现要点与边界：默认从 PEFT 起步；只有需要深度改变模型行为、或对质量与手上数据都有把握时，才考虑全参。无论哪条，微调后必须用评测兜底防变笨（评测做法见第六章）。

知识点
  • 选型口诀：能用 PEFT 就别全参——多数适配需求 PEFT 绰绰有余。
  • 安全底线：微调后不评测=白做；全参尤其易"灾难性遗忘"，要用评测前后对比防退化。
名词卡
名词一句话白话
Full Fine-tuning｜全参微调把模型全部参数整体再训；效果上限高但贵、易"灾难性遗忘"、难回滚。
PEFT｜参数高效微调只训练一小块增量参数的总称；成本低、见效快、易回滚、可多版本并存。
Catastrophic Forgetting｜灾难性遗忘微调时把模型原本学会的能力"忘掉/变笨"；全参尤易发生，须评测前后对比防退化。
Adapter / 增量参数PEFT 里额外加入、只被单独训练的小块参数（LoRA 的低秩增量即其一）。
易混点全参（调所有参数）≠ PEFT（只调增量参数）。
练一练

微观小实验（约 5 分钟）：给"选 PEFT 还是全参"做一次快速取舍演练。

  1. 拿一个具体的适配目标（如"让客服话术更礼貌、带固定格式"）。
  2. 用两条路线的特征各给一次判断：要不要动到"模型已学会的世界知识"？要不要"深度改变行为"？
  3. 验证：用一句话说清为何这类诉求 PEFT 足够、不必全参。

2.1.3 LoRA 与 QLoRA：让"小团队微调"变得可负担

小目标

这一节点回答：全参微调贵到大多数团队做不起，怎么用 LoRA/QLoRA 让"小团队微调"变得负担得起。价值在于——用很小的资源也能做出领域风格、格式上的适配，而且产出的是"小文件、多版本、可回滚"的结果，对产品和运维都很省心。

方法论

两条关键机制的递进逻辑：

  • LoRA（Low-Rank Adaptation，低秩适配）：只训练权重里一个很小的"低秩增量矩阵（A×B）"、冻结其余参数。只需调原始参数约 0.1%–1%，就能在普通单卡微调，并产出一个很小的增量文件（adapter）——易分发、易多版本并存、易回滚。
  • QLoRA = 量化 + LoRA：在 LoRA 基础上再对权重量化，进一步省显存，让消费级/单卡也能微调更大的模型。

重要边界：LoRA 适配"任务/风格/格式"，不改变模型已学到的世界知识——想"加知识"走 RAG，不要指望微调。

知识点
  • LoRA 的三个红利：极省资源（只调 0.1%–1%）、可单卡、易分发回滚。
  • 小增量文件天然运维友好：小文件、多版本、可回滚，配合第六章的版本化正好。
  • QLoRA 是消费级钥匙：要跑更大模型又缺显存，就"量化+LoRA"。
名词卡
名词一句话白话
LoRA｜低秩适配PEFT 主流代表：在原权重旁训练一个小的"低秩增量矩阵（A×B）"，只调它、其余冻结；极省资源、易分发回滚。
QLoRA｜量化+LoRA在 LoRA 基础上对权重量化进一步省显存，让消费级/单卡也能微调更大模型。
易混点LoRA（调 0.1%–1% 增量）≠ 全参（整体重训）；它改"风格/格式"，不增加"世界知识"。
练一练

微观小实验（约 5 分钟）：感受"LoRA 只动一小块"的直觉。

  1. 回想或查证：一次 LoRA 微调，最终改动的是"一个大的权重文件"还是"一个小的 adapter 增量文件"？
  2. 顺着"小增量文件"推演：为什么它天然适合"多版本并存 + 秒回滚"（呼应第六章的版本化）？
  3. 验证：用一句话解释"为什么 LoRA 改不了模型的世界知识"。

2.1.4 进阶上手 · 跑通一个 LoRA 微调

定位本节面向你的长期目标（微调模型、调试代码）。不必一步到位，但值得完整走一遍。保持低门槛：能复现一个基线、能读懂每个参数在干嘛就及格。
小目标

这是一堂"上手课"：把前三节的概念，在一次真实的微调训练中验证——亲眼看"数据集长什么样 → 配置怎么设 → loss 怎么掉 → 输出怎么变"，并学会"模型没学上去"时往哪排查。价值在于它是你调试微调代码的第一块能力拼图。

方法论

一套"从看懂到亲自动手"的操作骨架，共 7 步：

  1. 准备数据：取一小份"指令-答案"数据（几十到几百条即可），格式如 `指令→期望输出`；质量比数量重要（回到第一章）。
  2. 选基座模型：一个开源的中小模型，能本地跑就行。
  3. 套上 QLoRA：量化加载 → 只加 LoRA 适配器 → 冻结其余参数——这是"小资源微调"的关键。
  4. 设好关键参数并理解它们：学习率、训练轮数、LoRA 秩（r）、上下文长度、batch 大小；每个参数都能用一句话说清"动了它会怎样"。
  5. 跑训练，盯 loss：正常会看到 loss 下降；若震荡/不降，从排查清单找原因。
  6. 微调后对比：用同一句话比"微调前 vs 微调后"（你领域风格上的变化）。
  7. 防变笨：跑一组"通用能力"样例，确认它没把通用回答能力丢掉。

排查清单（"没学上去/变笨"往哪看）：

现象优先查方向
loss 不降/震荡学习率太高、数据太乱调低学习率、回第一章清数据
loss 降了但输出不对格式混淆 / 数据覆盖不全补数据、统一格式
通用能力崩了过拟合 / 遗忘减轮数、回归评测、或回到更小改动
上下文/显存爆块太长 / r 太大减长、降秩、调量化
知识点
  • 七步闭环：数据 → 基座 → QLoRA → 参数 → 看 loss → 对比 → 防变笨。
  • 会看 loss 不等于会评测：loss 是"体温计"（在不在学），答案质量要拿到训练外去评测——微调后不评测=白做。
名词卡
名词一句话白话
SFT｜监督微调用"指令-答案"标注数据教模型跟随指令与领域风格；上手的原料就是这类数据。
QLoRA｜量化+LoRA消费级更小资源跑更大模型的关键：量化加载 → 只加 LoRA 适配器 → 冻结其余。
Catastrophic Forgetting｜灾难性遗忘微调把模型原本能力"忘掉/变笨"；第 7 步"防变笨"就是测它有没有发生。
学习率 / 训练轮数 / LoRA 秩（r）/ batch调起来会改变训练行为的关键旋钮，每个都能用"动了会怎样"一句话说清。
易混点看 loss（模型在学的"体温计"）≠ 看答案质量——输出对不对要拿到训练外去评测。
练一练

微观小实验（约 10 分钟）：不跑真训练，先在"排查清单"上练诊断。

  1. 造两个"故障案例"描述，如"loss 一路横盘"、"通用能力答 1+1 都错了"。
  2. 对每个案例，从排查清单里找出"优先查什么、往哪个方向调"。
  3. 验证：把两条诊断各写成一问一答。

2.2 实操配套 · 模型训练与微调

目标学完 2.1.1~2.1.4 后马上动手。在云端跑通一次真正的 LoRA 微调，这是你长期目标（微调代码）的关键一课。方法：Google Colab（浏览器跑、免装、免本地 GPU）+ Unsloth。约 2~4 小时。

第 0 步 · 先过一道"要不要微调"的判断

想改"说话风格/格式/话术" → 微调有价值；想加"新知识/私有知识" → 该用 RAG（见第四章），微调改不掉知识缺失。先自己判断一次属于哪种。

第 1 步 · 开环境

  1. 用谷歌账号登录 Google Colab（colab.research.google.com）。
  2. 菜单 代码执行程序 → 更改运行时类型 → 硬件选 GPU（T4 即可，QLoRA 量化后能跑）。

第 2 步 · 装库（想明白在装啥）

!pip install "unsloth[colab-new]@git+https://github.com/unslothai/unsloth.git"

看到 Successfully installed 即成功。网络/版本报错属正常，重跑一次即可。

第 3 步 · 量化加载一个小模型（QLoRA 压进显存）

from unsloth import FastLanguageModel
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/Llama-3.2-1B-Instruct",
    max_seq_length = 2048,
    dtype = None,
    load_in_4bit = True,       # QLoRA 量化，省显存关键
)
model = FastLanguageModel.get_peft_model(
    model,
    r = 16,           # LoRA 秩：越大学得越狠、越贵、越易过拟合
    lora_alpha = 16,
    target_modules = ["q_proj","k_proj","v_proj","o_proj"],
    lora_dropout = 0,
)
要懂的三样load_in_4bit=True（量化）、r=16（低秩增量尺寸）、get_peft_model（只训适配器＝参数高效微调）。

第 4 步 · 造一小份"指令→回答"数据（宁少而准，呼应第一章）

data = [
  {"instruction":"客户问：你们的发货周期是多久？",
   "output":"您好，我们标准发货周期为 1-3 个工作日，加急可当天发出。"},
  {"instruction":"客户问：可以退货吗？",
   "output":"可以的，7 天内无理由退货，请保留吊牌与凭证。"},
  # 补到你业务领域的十几~几十条，注意口径统一
]

第 5 步 · 训练（盯 loss 这个"体温计"）

from trl import SFTTrainer
from transformers import TrainingArguments
from datasets import Dataset

ds = Dataset.from_list([
  {"text": f"### 指令：{d['instruction']}\n### 回答：{d['output']}"} for d in data
])
trainer = SFTTrainer(
  model=model, tokenizer=tokenizer, train_dataset=ds, dataset_text_field="text",
  max_seq_length=2048,
  args=TrainingArguments(
    per_device_train_batch_size=2, gradient_accumulation_steps=4,
    warmup_steps=5, num_train_epochs=1, learning_rate=2e-4,
    logging_steps=1, save_strategy="no"),
)
trainer.train()

看 loss：稳步下降=在学；震荡不降=学习率太高或数据乱；狂掉又横盘=数据太少/太简单。

第 6 步 · 验证——风格像不像 + 有没有变笨

FastLanguageModel.for_inference(model)
toks = tokenizer("### 指令：客户问：你们可以开发票吗？\n### 回答：", return_tensors="pt")
out = model.generate(**toks, max_new_tokens=128)
print(tokenizer.decode(out[0]))

再用一个与风格无关的问题（如"1+1=？"）测通用能力没崩——这就是"微调后必须评测防变笨"的落地。

第 7 步 · 动参数看因果（练调试手感，核心）

  • 把 learning_rate 改大 10 倍（2e-3）再训 → 看 loss 更震荡、输出更乱。
  • 往 data 塞几条答案不一致的 → 看输出变"抽风"。
  • 做 r=8 vs r=32 对比 → 感受"秩越大学得越狠也越易过拟合"。
要点你不必改对，要的是亲手看到每个旋钮拧到这儿会怎样——这就是调试手感，直指你"能调微调"的目标。

2.3 自查通关 · 模型训练与微调

第三章 推理与部署优化

知识域 F3.3 · 模型怎么"更快更省更稳"地跑起来

3.1 知识详解 · 推理与部署优化先定"卡在延迟还是吞吐还是成本"，再看引擎、调度与瘦身

3.1.1 铁三角：先定"你这个场景到底卡在哪一项"

小目标

模型训练好了，还要解决"怎么跑得快、便宜、稳"——把 token 推理的延迟、吞吐、成本压下来。这一节点先回答：你这个场景到底卡在哪一项？没有这一步，大模型只能"演示跑得动、商业化跑不起"。

方法论

核心是理解"延迟—吞吐—成本铁三角"：三者互相牵制——想降延迟常降吞吐、提吞吐摊薄单价但可能抬高首 token 延迟。判断逻辑：

  • 延迟（Latency）：单请求首字/整答耗时。交互问答、客服最关心它（流式响应感取决于首 token 延迟）。
  • 吞吐（Throughput）：单位时间处理请求/token 量。离线条批处理看重它，摊薄单价。
  • 成本（Cost）：总算力/单询预算。预算紧时用它牵制选型。

优化第一课是"没指标别优化"：先量出延迟/并发/P99 基线，再确定约束项是哪一项；最优解常是配置面的东西（并发限制、上下文与 top-k 限长、流式、缓存命中），往往比换大模型更省。

知识点
  • 铁三角互相牵制：没有免费的午餐——优化第一步不是调引擎，而是先定约束项、量好基线。
  • 配置面优化最划算：限长、流式、缓存命中，往往比换模型更值钱。
名词卡
名词一句话白话
Latency｜延迟单请求首字/整答耗时，决定产品体验感；交互问答/客服重它。
Throughput｜吞吐单位时间处理的请求/token 量，决定支撑力与摊薄单价；离线条批重视它。
Cost｜成本（单位 token）模型跑起来的算力/计费总成本；预算紧时用它牵制选型。
P99（延迟百分位）99% 请求延迟低于该值，比平均值更能暴露"最差体验"的尾部风险。
易混点延迟（管单条体验）≠ 吞吐（管整体支撑）≠ 成本（管预算）——三视角互相牵制。
练一练

微观小实验（约 8 分钟）：给自己的场景定一个"约束项"。

  1. 说出你产品一次典型问答，你最在意哪一个：体验（首字快不快）？并发支撑（人多扛不扛得住）？预算（token 贵不贵）？
  2. 估算一下：如果优化它，可能以牺牲另外三角的哪一项为代价？
  3. 验证：写下一句"我最先卡 __，用 __ 作约束项"。

3.1.2 推理引擎与批量优化：同样的模型靠"调度"跑得更快

小目标

这一节点回答：同样的模型、同样的硬件，怎么跑出更快的速度与更高的吞吐。价值在于——多数吞吐翻倍不靠换模型、而靠引擎与调度；看懂"读/写"两阶段，就能定位延迟与成本从哪来。

方法论

看懂三个机制，就掌握了"调度与缓存提速"的逻辑：

  • 预填充与解码（Prefill / Decode）：生成分两阶段——预填充先并行"读完"所有输入 token、算好前置状态；解码再逐 token 生成剩余回答。预填充是"读"（吃长输入/显存），解码是"写"（决定逐 token 速度，是主要瓶颈）。
  • KV 缓存（KV Cache）：解码阶段把已算过的 Key/Value 注意力结果缓存复用，避免每次重复算整个前文。它是解码关键加速、也是显存占用大头——决定能装多长上下文、扛多大并发。
  • 连续批处理（Continuous Batching）：不把批次"填满再一起算完"，而是多请求你进我出、实时拼进同一批计算流，谁先完成谁先下场、新请求随时补位。让 GPU 时刻满载，大幅拉高吞吐、摊薄单价。

边界与选型：有成熟引擎就别自造轮子——用 vLLM/SGLang 等优化引擎，吞吐能靠"调度与缓存"而非换模型大幅提升；引擎只是"快跑"，约束仍回三角判断。

知识点
  • 两阶段决定延迟与成本：prefill 管"读"、decode 管"写"；decode 逐 token 是延迟/成本大头。
  • 两条提速引擎：KV 缓存（复用前文=加速关键、也是显存大头）+ 连续批处理（"边算边进出"让 GPU 满载、吞吐大涨）。
名词卡
名词一句话白话
Prefill / Decode｜预填充 / 解码生成两阶段：预填充并行"读完"输入算好前置状态，解码逐 token 写；预填充管"读"（吃长输入），解码管"写"（是瓶颈）。
KV Cache｜键值缓存解码阶段缓存已算过的注意力 Key/Value 复用，是加速关键、也是显存占用大头。
Continuous Batching｜连续批处理多请求"你进我出"实时拼一批计算流，GPU 满载、大幅拉高吞吐、摊薄单价。
PagedAttention｜分页注意力vLLM 提出的 KV 缓存"分页管理"，把缓存按页塞进零散显存，省显存又高吞吐。
Prompt Cache｜前缀缓存把整段输入/前缀的预填充结果缓存复用，管"读"阶段的复用。（≠ KV 缓存）
Inference Engine｜推理引擎把"同样模型跑更快"的服务层（vLLM/SGLang 等），内置批处理与缓存调度。
易混点KV 缓存（管解码"写"的复用）≠ 前缀缓存（管输入"读"的结果复用）。
练一练

微观小实验（约 8 分钟）：用"读/写"两阶段解释一次体验。

  1. 回看你某个问答应用："要等一会儿才出第一个字"像不像卡在哪个阶段？"字一个个蹦出来"又在消耗哪个阶段？（思考 prefill vs decode）
  2. 想一条"又长输入又长输出"的请求：为什么它又慢又贵？
  3. 验证：用"prefill（读）/ decode（写）"各一句话，说明一次回答的时间与成本最可能从哪来。

3.1.3 模型瘦身：量化与蒸馏（够用前提下的省钱之道）

小目标

这一节点回答：怎么让模型更小、更省显存与成本、又尽量不伤功能——支撑端侧/私有化低成本部署。主流两条路：量化（压缩位数）与蒸馏（用大模型学个小模型）。

方法论

路线 A——量化（Quantization）：把模型权重与激活从 FP16/FP32 压到 INT8/INT4 低精度 → 模型变小、省显存、推理快而省。主流方法 GPTQ（逐层近似）、AWQ（按激活敏感度加权）、GGUF（端侧/CPU 格式）。铁律：位宽越低越省，但精度损失越大——4bit 多数任务够用，但个别能力会掉、随机质量会劣化，关键场景必须回归评测。

路线 B——知识蒸馏（Knowledge Distillation）：用大模型（教师）生成高质量标注/合成数据，训练一个更小的模型（学生），让小模型在特定领域/任务上逼近大模型。天然天花板：领域太宽会崩，只适合某领域反复调用（如客服意图/FAQ）。

瘦身路径先小步再大动作：量化先小步试（便宜）；蒸馏是大动作（重训+数据工程），只有"高频调用又吃不住成本"才上。瘦身后必做"精度-收益"回归评测。

知识点
  • 两条路别混：量化=压缩位数、不学数据；蒸馏=用小模型"重学"、变小也学。
  • 任何瘦身都有质量代价：量化的代价在"位宽精度"，蒸馏的代价在"领域天花板"——都必须回归评测。
名词卡
名词一句话白话
Quantization｜量化把权重/激活压到 INT8/INT4 低精度：变小、省显存、更快；位宽越低越省但精度损失越大。
GPTQ｜逐层近似量化对权重逐层"整数化+误差补偿"的量化方法，适合 GPU 部署。
AWQ｜按激活敏感度加权量化按激活敏感度对不同通道分配不同量化精度，直观上更少掉点。
GGUF｜端侧/CPU 量化格式专为端侧与 CPU 部署设计的量化模型文件格式（llama.cpp 生态）。
Knowledge Distillation｜知识蒸馏用大模型（教师）生成数据训更小模型（学生），让小的在特定任务逼近大的；降本不改硬件的选择。
易混点量化（压缩位数、不学数据）≠ 蒸馏（用小模型"重学"、变小也学）。
练一练

微观小实验（约 8 分钟）：做一次"瘦身选型"判断。

  1. 给一个"高频调用、预算吃紧"的场景，判断该先走量化还是蒸馏，并说清为什么。
  2. 顺着"位宽越低越省、精度损失越大"推演：说明为什么关键场景必须做"瘦身前 vs 瘦身后"对比评测。
  3. 验证：把"量化试小步 + 蒸馏大动作 + 回归评测"写成一句话的落地动作。

3.2 实操配套 · 推理与部署优化

目标学完 3.1.1~3.1.3 后马上动手。不写代码，用你的 RAG/对话应用，亲手测一次"延迟、吞吐、成本"，并体验"配置面优化（限长/流式）比换模型更省"。约 45 分钟。

步骤 1 · 先定"这个场景卡在哪一项"（铁三角第一课）

想清楚你现在关心的是：交互体验（→看延迟）？并发量大（→看吞吐）？预算紧（→看成本）？记录下你选哪项。

步骤 2 · 测"首 token 延迟"（交互体验最敏感指标）

  1. 打开你第四章搭的应用的调试对话。
  2. 用手机秒钟：点发送的同时计时，到"第一个字开始流式出现"为止。
  3. 连续测 3 次，记下时间；取中位数当"首字延迟基线"。
  4. 观察流式：你的应用是"转圈等一整段"还是"边生成边出"？如果有"打字机"效果，那就是流式(Streaming)已开——这是降低"等待感"的关键。

步骤 3 · 体验"限长"对成本/速度的影响（配置面优化）

  1. 在应用的上下文/模型设置里，把 Top-K / 上下文长度 调小一档（比如 3→1，或 max_tokens 调短）。
  2. 再测同一个问题的时间。
  3. 观察：输入更短 → 检索更少 → 往往更快/更省。这印证"配置面优化（限长/流式）往往比换模型更省"。

步骤 4 · 体验"连续批处理/缓存"的直觉（了解即够）

不需要你搭服务器，只需记住一个直觉：Dify/托管平台的底层，GPU 是靠"连续批处理(边算边进出)"+"KV 缓存(复用前文)"才干快的；并发高时你体验到的"稳定"背后就是这两招。认清"吞吐翻倍靠引擎调度，不靠换模型"。

3.3 自查通关 · 推理与部署优化

第四章 RAG 检索增强

知识域 F3.4 · 把私有知识喂给模型并防编造

4.1 知识详解 · RAG 检索增强先查、再答、有据可依：检索、分块、注入三大支柱

4.1.1 RAG 是什么：先查、再答、有据可依

小目标

这一节点回答：大模型的知识截止在训练时，训练后既访问不到新信息、也装不进私有信息，还容易"一本正经地编"（幻觉）——怎么让模型"有据可依"地答？三大痛点：

  • 训练截止 → 不知道训练之后的事；
  • 私有知识进不去 → 商品库、FAQ、操作手册喂不进去；
  • 幻觉 → 答不确定的问题倾向硬编一个像样的答案。

RAG 的思路很朴素：在模型生成之前，先从外部知识库里查出与问题最相关的片段，拼进上下文，再让模型基于这些片段作答——答案是"内容来自检索，模型负责组织语言"。

方法论

RAG 不是单点技术，而是一条五段管线：

① 离线处理：原始文档 → ①分块(切检索粒度) → ②嵌入(编码成向量) → ③建索引(存进向量库)
↓
② 在线问答：用户提问 → ④检索(嵌入→按相似度召回 Top-K，可选重排) → ⑤注入生成(拼进提示词作答)
↓
③ 输出答案 + (可选)引文来源

它的所有坑，都发生在某一段没做对。管线归为三大支柱，也是后面三节：

支柱哪一段核心命题
检索与召回质量④答错先怪检索——召回若漏，后面全白费
分块与索引策略①②③分错块，再强的检索也救不回来
注入与幻觉控制⑤检索好 ≠ 答得好，注入与约束不当照样编
知识点
  • 一句话记忆：没有 RAG，企业私有知识（商品库/FAQ/手册）就喂不进大模型——这是现阶段把企业权威知识交付给 LLM 的最主要工程手段（与微调并列，选型见 2.1.1）。
  • 是管线不是单点：分块→嵌入→索引→检索→注入生成，坑都发生在某一段没做对。
名词卡
名词一句话白话
RAG｜检索增强生成生成前先从外部库检索相关片段注入上下文再作答；解决训练截止知识+私有知识进不去+幻觉三大短板。
易混点RAG 改"喂的输入"（临时注入、快、可换）≠ 微调改"模型权重"（永久学、慢、贵）。
练一练

微观小实验（约 5 分钟）：先做一次"裸模型 vs RAG"的痛点预演。

  1. 拿着想给大模型做问答的"私有资料"，先直接问裸模型一个"答案只在你的资料里、模型并不知道"的问题。
  2. 观察它大概率"编一个像样的答案"还是"说不会"。
  3. 验证：把这次"没有 RAG 的痛点"写下来，作为后面搭 RAG 时的对照基线。

4.1.2 支柱一：检索与召回质量（答错先怪检索）

小目标

这一节点回答：怎么让 RAG 先"把对的东西捞进来"——因为检索决定"把哪些候选喂给模型"，若漏了正确答案，后面再好也白费。价值在于它是 RAG 的头号决定因素，"答错先怪检索"。

方法论

让"召回准"的方法体系，按"初检→精排"两段组织：

  • 语义检索（Semantic Search）：靠向量语义相似度召回、不靠字面匹配。用户问"充电快"，库里是"快充/长续航"，也能对上。
  • 混合检索（Hybrid Search）：向量（语义）+ 关键词 BM25（术语/型号精确）双路取并集——治"语义/术语变形漏召回"，几乎 RAG 必配。
  • 查询改写（Query Rewriting）：query 太口语/太宽时，先让模型改写/拆解再检索（HyDE：先"脑补答案"再检索）。
  • 重排（Rerank）：初检索求快召回一堆"大致相关"但排序不准；再用更慢更准的交叉编码器精排前几十条——真正有用的片段进前几名，才决定上下文质量。

关键认知：召回多 ≠ 答得好。召回放量到 Top-50~100 再精排，比只做纯向量 Top-K 明显更准，代价是多一次重排的延迟/成本。

知识点
  • 召回漏了=后面全白费：答错先查检索。
  • 混合检索几乎必配：向量+BM25 双路并集，治"术语变形漏召回"。
  • Rerank 值得那一次延迟：把对的片段推进前几名，才真正决定上下文质量。
名词卡
名词一句话白话
Semantic Search｜语义检索靠语义相似度而非字面匹配从库里找最相关内容；用户换说法也能命中。
Hybrid Search｜混合检索向量（语义）+ 关键词 BM25（术语/型号精确）双路取并集，治"语义/术语变形漏召回"，几乎必配。
Rerank｜重排 / 精排用更慢但更准的交叉编码器对初筛候选精判、重排序，把真有用的提到最前。
Query Rewriting｜查询改写query 太口语/太宽时先让模型改写/拆解再检索（HyDE：先"脑补答案"再检索）。
Top-K / Recall@KTop-K 取前 K 条；Recall@K 前 K 条里命中多少标准答案——评价检索质量核心指标。
易混点语义检索（初检，快粗量大）≠ 重排（精排，慢准量小）。
练一练

微观小实验（约 8 分钟）：亲眼比较一次"纯向量 vs 混合检索"。

  1. 在任意 RAG 工具/平台上，先用纯向量检索问一批"换个说法/带型号术语"的问题。
  2. 再切成混合检索，用同一批问题再问一遍。
  3. 验证：对比命中率，用一句话说明"为什么混合检索在术语变形场景胜出"（落到"语义+BM25 双路并集"）。

4.1.3 支柱二：分块与索引策略（分错块，再强的检索也救不回）

小目标

这一节点回答：怎么让检索"命中正确的粒度"——因为检索能不能命中，取决于文档怎么切、索引怎么建。重点是文档分块是 RAG 的第一道工程抉择：分错块，再强的检索也救不回。

方法论
  • 粒度是门艺术：块太大语义稀释、太小易断裂。FAQ 短块够用；手册/合同要大块或"父子块"，按文档类型与答案粒度试。
  • 结构化分块优于硬切：按标题/段落/表格/列表切，别硬按字符切碎表格——客服 FAQ、参数类知识尤其吃亏。
  • 父块保上下文（small-to-big）：子块检索 + 父块喂模型——用细块精确定位、用粗块给完整上下文。
  • 元数据是门禁：给块打"来源/版本/适用条件"，检索时用元数据过滤（如只搜某产品线），既准又防误导。
  • 索引要生命周期：知识源更新/下架/改版都要重建索引、清理失效块，否则出"旧答案"；隐私密级应在检索层过滤，不能只靠生成层。
知识点
  • 分块是第一道抉择：分错块，再强的检索也救不回。
  • 父块保上下文是经典手法：小检索+大喂入，兼顾"准"与"完整"。
  • 索引有生命周期与门禁：重建/清理失效块防"旧答案"，元数据过滤既准又防误导。
名词卡
名词一句话白话
Chunking｜文本分块 / 切片把长文档切成检索的基本单元；块太大语义稀释、太小断裂。常见固定长度、按语义边界、父子块。
Small-to-big / 父子块子块检索 + 父块喂模型：细块精确定位、粗块给完整上下文，兼顾"准"与"全"。
Embedding｜向量嵌入把词/句/文档映射成高维向量，使语义相近内容向量距离就近；语义检索的地基。
Vector Database｜向量数据库专门存"向量"、按相似度快速检索的库，是 RAG 存文档块嵌入的载体。
Index｜索引把已嵌入片段组织成便于快速检索的结构（如 HNSW），是"存得下、查得快"的关键。
易混点文本分块（"切"）≠ 向量嵌入（"编码"）；向量数据库只是"存+查"，效果取决于嵌入模型。
练一练

微观小实验（约 8 分钟）：体会"分块粒度"这一个旋钮能造成多大差别。

  1. 取一份文档上传进 RAG 工具，把分段长度调成很大再重建索引。
  2. 问一个"需要某个细节"的问题，对比"大块 vs 小块"下的答案质量。
  3. 验证：用一句话说明"为什么块太大时，细节答案变差"（落到"语义稀释"）。

4.1.4 支柱三：注入与幻觉控制 + 实操组装（检索好≠答得好）

小目标

这一节点回答：检索做得再多，注入与约束不当照样产生幻觉——怎么把检到的知识喂对、并让它不编。价值在于它是"让 RAG 答得好"的最后一环，同时把五段管线落到一次实操组装。

方法论

做法 A：把"喂"和"不编"做对。

  • 注入要克制：Top-K/token 预算有限，上下文越长越稀释相关度且烧成本；限长并按相关度排序喂入。
  • 提示工程化：固定"仅凭下方资料作答、未命中则明说不知道"作为产品级提示配置。
  • "考不到"必须承认：命中不足时叫它"说没查到"而非硬编；可带置信分阈值触发话术兜底/转人工。
  • 引文溯源是信任红利：让模型引用检到的块（返回来源 ID/页码），事实可回查、幻觉可定位——这是 RAG 区别于裸 LLM 的最大红利，产品尽量保留。
  • no-answer 训练：小样本让模型学会"不知道就说不知道"，配合结构化输出（JSON schema）减少答非所问。

做法 B：实操组装（把五段管线搭出来）——用低代码平台（第六章）或知识库工具，把"上传文档 → 分块 → 嵌入 → 检索 → 注入 → 生成+引文"串起来，做一个能回答你业务知识的问答；给自己留三组测试问题（正常 / "库里没有" / "表述很口语变形"）。

知识点
  • 支柱三管两件事：注入克制（限长+按相关度排序）与防编造（考不到就明说+引文溯源）。
  • 引文溯源是最大信任红利：产品尽量保留，出错才能定位到是哪段资料误导。
名词卡
名词一句话白话
Context Injection｜知识注入把命中片段按相关序拼进提示词上下文；要克制——token 有限，越长越稀释相关度且烧成本。
Structured Output｜结构化输出用固定格式（JSON schema）约束模型输出，配合"拒答/置信度"字段减少答非所问。
Hallucination｜幻觉模型生成的与事实不符内容；RAG 用外部依据+引文回链抑制它。
Citation Grounding｜引文溯源让模型返回检到块的来源 ID/页码，事实可回查、幻觉可定位——RAG 最大红利。
No-Answer｜拒答让模型"命中不足就说没查到"而非硬编；配合置信阈值触发话术兜底/转人工。
易混点检索好（召回准）≠ 答得好（注入+防编造得当）——两码事，支柱三专管后者。
练一练

微观小实验（约 8 分钟）：亲手测"会不会编"并补上"防编造提示"。

  1. 在你的 RAG 问答里，问一个"资料里没有"的问题——看它硬编还是说没查到。
  2. 写一条"仅凭下方资料作答、未命中则明说查不到"的提示，挂到应用的系统提示里。
  3. 验证：再问同样的问题，对比前后，说明"提示工程化 + no-answer"解决了什么。

4.2 实操配套 · RAG 检索增强

目标学完 4.1.1~4.1.4 后马上动手。从 0 搭出一个能"基于你资料回答 + 防编造 + 带出处"的知识问答，并亲手制造两个故障学会排查。对应本章 4.1 讲的五段管线与三支柱。约 60~90 分钟。

写在前面 · 准备什么

浏览器 + 邮箱注册 Dify；3~15 份你熟悉的短文档（FAQ/周报/商品清单）。Coze/元器同理可选。

第 0 步 · 先做一次"裸模型"对照（记住痛点）

问任意大模型一个"只有你资料才知道"的问题（如"FAQ 里 3 级投诉时限"）。它大概率要么编、要么说不会。记下答案，后面对比用。

第 1 步 · 注册 Dify 新建应用

  1. 注册登录 Dify。
  2. 创建 聊天助手(Chatbot)，命名如"我的知识问答"。

第 2 步 · 建知识库并上传（管线①②③）

  1. 侧边 知识库 → 创建。
  2. 上传你的文档；记下分段长度(chunk)用了多大（第 7 步要回来改它）。
  3. 选 embedding 模型(默认即可) → 「保存并索引」。
理解此刻平台帮你把文档切成卡片 + 转向量 + 建了索引。索引完显示"已处理 N 条"=分段数。

第 3 步 · 把知识库挂到应用（注入外部知识）

应用画布 → 右侧上下文(Context) → 选中刚才的知识库挂进去。应用从"纯聊天"变"RAG 聊天"。

第 4 步 · 看一眼检索设置（管线④，头号决定因素）

  1. 找检索模式：向量检索(语义) / 全文检索(BM25 精确) / 混合检索(双路并集=几乎必配)。
  2. 把 Top-K(召回数量) 设成比如 3。

第 5 步 · 写"会防编造"的系统提示词（管线⑤，支柱三）

你是一位只依据【上下文】回答问题的助手。
规则：1.优先依据检索到的【上下文】回答；上下文不足时明说"根据现有资料我查不到"，不要编造。
2.回答时尽量标注信息来自哪个文档/片段。3.保持简洁、口语化。

第 6 步 · 发布实测——第一次"有据可依"

发布后调试框输第 0 步那个问题。看它是否给来自你资料的答案 + 带出处；再问个"资料里没有"的，看它是否说"查不到"。成功了。

第 7 步 · 制造两个故障学排查（最有价值一节）

  • 故障 A：把分段长度改为很大(如 500→2000)重新索引 → 问细节问题 → 通常答案变差(块太大语义稀释)。学会：答不到先查"分块与检索"。
  • 故障 B：把应用上下文里的知识库暂时移除 → 问同一个问题 → 退回"裸模型"。亲测 RAG 的"有/无"差别。

第 8 步（可选进阶）· 两个产品化坑

  • 保留引文/来源：出错能定位到是哪段资料误导。
  • 资料会过期：文档更新/下架后必须重新索引，否则出"旧答案"。

4.3 自查通关 · RAG 检索增强

第五章 Agent 系统工程

知识域 F3.5 · 让模型"办得成多步实事"的执行引擎层

5.1 知识详解 · Agent 系统工程大脑＋手脚、记性、调度三层，先 workflow 再 agent

5.1.1 推理循环与工具调用（大脑＋手脚）

小目标

这一节点回答：怎么让模型"办得成多步实事"——从单次问答扩展到能调用工具、多步自主完成任务。价值在于它是智能客服、自动化工作流的执行引擎层；多数 Agent 的 80% 价值来自"接对工具 + 循环够健壮"，而不是模型本身多聪明。

方法论

先把 Agent 的三层架构放进来，本节专讲第一层：

① 推理循环 + 工具调用 —— 大脑+手脚：模型循环"思考→选工具→看结果→再思考"
      ↓
② 记忆与状态管理     —— 记性：短期(会话) + 长期(跨会话) + 状态机(任务进度)
      ↓
③ 编排框架与演进     —— 调度：从单Agent到工作流与多Agent，配可靠性+评测

第一层的三个组件与其逻辑：

  • 推理循环范式（ReAct）：让 LLM 交替输出"推理"与"行动（调工具）"，靠工具观察结果继续推理——一个"思考-行动-观察"的自主循环，是 Agent 最通用的底座。它压制多步错误累积，把模型从单次问答扩成能一步步办成事。
  • 函数/工具调用（Function/Tool Calling）：让模型"决定要调哪个函数、并生成结构化参数"，由外部系统真正执行——把"理解"变"动作"。导购里：模型判断用户要查库存→调查库存函数→返回真实数据再组织回答。这是 Agent 能"办成事"的关键开关。
  • 状态机（Task State Machine）：用一组"状态+转移+门控"显式描述任务走到哪步、下一步能否走，防止多步丢线头/跳步，是可恢复、可续跑的工程底盘。

落地要点：接对工具（schema 清晰、返回结构化结果）+ 循环设置合理（循环上限+超时防"无限跳舞"）比追求模型更聪明更值钱。每一轮循环都是一次完整模型调用——轮数越多越慢越贵。

知识点
  • 80% 价值来自"接对工具 + 循环健壮"：先磨工具与循环，不必苛求模型更聪明。
  • 循环有成本：每轮循环=一次完整模型调用，轮数越多越慢越贵——要设循环上限防"无限跳舞"。
名词卡
名词一句话白话
ReAct｜推理与行动循环让 LLM 交替输出"推理"与"行动（调工具）"，再靠工具观察结果继续推理——Agent 最通用的底座。
Function/Tool Calling｜函数/工具调用让模型"决定调哪个函数、生成结构化参数"，由外部系统真正执行；Agent 办成事的关键开关。
Plan-and-Execute｜先计划再执行先生成完整计划再逐条执行，更适合明确多步骤任务。（≠ ReAct）
State Machine｜任务状态机用"状态+转移+门控"显式描述多步任务走到哪、下一步可不可走；可恢复、可续跑、可观测。
Workflow｜工作流确定性节点编排，步骤与门控清楚可控——可控性与可预期性优先。
易混点函数调用（决定执行动作+参数、会真去做）≠ 结构化输出（只约束格式、不执行）；ReAct（边想边做）≠ Plan-and-Execute（先出计划再执行）。
练一练

微观小实验（聚焦本节点，约 8 分钟）：用"你的一句对话"拆出 ReAct 循环。

  1. 挑你产品里一句常见用户话，分析它"要不要调工具、调哪个"。
  2. 试点走一遍完整循环：模型看到话→判断→选工具→看结果→组织回答。
  3. 验证：写下这轮循环里"哪一次是完整模型调用"——体会"轮数越多越慢越贵"。

5.1.2 记忆与状态管理（记性）

小目标

这一节点回答：怎么让 Agent"记得住"——记忆决定它是"每次都失忆的外包"还是"有上下文、能接续的服务者"。价值在于：多步任务要在多轮里不丢线头，靠"记忆管内容 + 状态机管进度"两层配合。

方法论

三层实现逻辑：

  • 短期记忆：一次会话/任务内的"当前工作区"——对话内容、已处理中转状态，随上下文窗口走、用完即清。窗口将满时用摘要/裁剪/检索腾位置，而非无限塞。
  • 长期记忆：跨会话、跨任务持久保存的"关于用户/过去结果"的记忆，放在模型上下文之外、需要时再检索回来（实现侧复用 RAG，见第四章）。让 Agent 记住用户偏好、历史结论。
  • 状态管理：短期/长期管"内容"，状态机管"任务进度本身"——多步任务每步都可能出错，显式状态让 Agent 可恢复、可续跑、可观测。

产品边界：记忆择要而存（存目标/结果/约束，不存冗长中间输出）；长期记忆可编辑、可过期、可清除（防陈旧/错误记忆固化）；记忆含个人数据即涉合规——持久化要过隐私/安全口径。

知识点
  • 记忆两层的分工：短期（会话内、用完即清）vs 长期（跨会话、靠检索取回）。
  • 管"内容"≠ 管"进度"：记忆管内容，状态机管任务进度——两套东西别混。
  • 合规红线：记忆含个人数据即涉合规，持久化要过隐私/安全口径。
名词卡
名词一句话白话
Short-term / Working Memory｜短期记忆一次会话/任务内的"当前工作区"，随上下文窗口走、用完即清。
Long-term / External Memory｜长期记忆跨会话、跨任务持久保存的用户画像/历史结果，放上下文外、需要时检索（实现侧复用 RAG）。
MemGPT｜分层记忆范式提出"工作记忆 vs 长期记忆"分层管理的代表范式，Agent 记忆架构的参照。
State｜状态任务进度本身（未开始/取参中/已下单/完成/失败）——管"进度"，不是"内容"。
易混点状态（管"进度到哪一步"）≠ 记忆（管"内容本身"）；短期（当前会话）≠ 长期（跨会话靠检索取回）。
练一练

微观小实验（聚焦本节点，约 8 分钟）：在一个 Agent 应用里亲手验证"长期记忆"。

  1. 打开 Agent 设置里的长期记忆开关，先问一次"帮我关注发货快的平台"。
  2. 另开一个新对话，问"我之前说过要啥？"——能想起来=长期记忆生效，想不起来=没开或没存上。
  3. 验证：用一句话说清"长期记忆放哪、何时取回"，并答"这里存的是记忆还是状态"。

5.1.3 编排框架与演进 + 可靠性评估

小目标

这一节点回答：多个 Agent / 多条流程怎么协同不打架、且不被"多步错误"越放越大。价值在于——从单 Agent 到大系统的关键不是"再加一个 Agent"，而是怎么编排（协同）+ 怎么保证可靠（评测）；多步任务每步累加一点错误可能串联成不可逆错误，编排与可观测评测是把这条"放大链"关进笼子。

方法论

演进路线走 workflow-first——能确定的用节点编排，不确定的才引 Agent，可控性永远优先：

  • 工作流（Workflow）：确定性节点编排，步骤与门控清楚、可控、可预期。
  • 多智能体（Multi-Agent）：把复杂任务拆给多个各司其职的角色（规划/执行/质检等）分工协作。每个做窄活更准、也易判断哪一环出错；但更灵活也更不可控，通常要配人监督。
  • 辨析红线：单 Agent + 多工具 ≠ 多智能体——前者是"一个 Agent 的推理循环 + 多个工具"，后者是"多角色分工"。

评测 Agent：别只看"答对没"，三路一起看——

  • 推理循环健壮：工具调用成功率、单任务平均步数、超时/重试/卡死比例。
  • 记忆衔接：会话续跑不丢线、长期记忆命中率、记忆陈旧率、PII 越权访问=0。
  • 编排三件套：成功率 / 轨迹质量 / 成本延迟 + 黄金轨迹回归。

产品防线：多步失控放大器——要锁步数上限、设门控、留人审，把"写外部系统、动钱、发消息"这类高风险动作限制在授权范围。

知识点
  • 演进路线 = 先 workflow、再引 Agent 自主：能确定的用节点编排，不确定才引 agent——可控性是产品底线。
  • 多 Agent ≠ 单 Agent+多工具：前者是多角色分工协作，后者是一个推理循环配多个工具。
  • 评测看三件套：成功率 / 轨迹质量 / 成本延迟 + 黄金轨迹回归，别只看"答对没"。
名词卡
名词一句话白话
Workflow｜工作流确定性节点编排，步骤与门控清楚可控——可控性与可预期性优先的"守规则"底座。
Multi-Agent System｜多智能体系统把一个复杂任务拆给多个各司其职的 Agent（规划/执行/质检等角色）分工协作；每个做窄活更准，但更灵活也更不可控。
Agent Loop / Orchestration｜编排调度多个 Agent 或多条流程的协同、状态流转与消息协议。
黄金轨迹（Golden Trajectory）｜评测基准一组"理想执行轨迹/断言"作回归参照，衡量实际执行与预期的贴合度。
易混点单 Agent+多工具（一个推理循环）≠ 多智能体（多角色分工）；工作流（确定性节点、步骤可预期）≠ 多智能体（自主协作、灵活但不可控）；评测别把"答对/答不对"当唯一标准。
练一练

微观小实验（聚焦本节点，约 8 分钟）：亲手对比一遍 workflow vs Agent 的可控性。

  1. 在低代码平台同一场景，分别用"固定节点"（workflow）与"自由循环"（Agent）各搭一个最小可跑版本。
  2. 各自连跑 3 次，记下"结果是否一致"与"是否偶尔跑偏/失控"。
  3. 验证：用一句话说清"能确定的用节点编排、不确定才引 agent"，并指出"查库存后给建议"这种确定流程该用哪一版。

5.2 实操配套 · Agent 系统工程

目标学完 5.1.1~5.1.3 后，马上动手。目标：在低代码平台搭一个"会调用工具、能记状态"的 Agent，亲手体会"大脑+手脚+记性"三层，理解"workflow-first"与多步风险。约 60~90 分钟。
写在前面你 第四章 已注册 Dify；本套继续用它的 Agent 编排 / 工作流 能力（Coze 同理）。

第 0 步 · 先想一个"要办多步实事"的场景

挑一个需要"多步 + 查外部数据 + 有状态"的小事，例如"查某商品的实时库存再给建议""查天气再决定带伞建议"。Agent 的价值 = 办成多步实事，而非只答一句。

第 1 步 · 搭"推理循环 + 工具调用"（大脑+手脚）

  1. 新建一个 Agent 应用（Dify 有 Agent 类型，或在工作流里加"工具调用"节点）。
  2. 给 Agent 接一个工具（平台预置了查询类工具，或你手动定义一个"查询库存"的函数，含参数 schema）。
  3. 让 Agent 在对话里先判断要不要调工具 → 生成参数 → 平台执行 → 返回结果 → Agent 组织成回答。
理解这就是 ReAct 循环：思考→行动(调工具)→观察结果→再思考。导购查库存就是它。

第 2 步 · 体会"状态机/记忆"（记性）

  1. 在 Agent 设置里找 记忆：开一个"长期记忆"（跨会话记住用户偏好）。
  2. 场景演练：先问一次"帮我关注发货快的平台"，另开新对话再问"我之前说过要啥？"——能想起来=长期记忆生效。
  3. 体会 Dify 里的 对话状态：多轮里它还记不记得"任务做到哪一步"。
关键认知记忆要择要而存、可编辑、可过期；含用户个人数据即涉合规，演示/笔记别用真实个人信息。

第 3 步 · 体会"workflow-first"（可控性是底线）

  1. 在同一平台切到 工作流(Workflow) 视图（确定性节点编排）。
  2. 把刚才的 Agent 场景改成"固定节点"（比如固定"先调查询→再生成"，不带自由循环）。
  3. 对比：workflow 结果更稳定可控、Agent 更灵活但可能跑偏。→ 记住：能确定的用节点编排，不确定才引 Agent。

第 4 步 · 看清"多步 = 成本放大器"

在一个循环较多的 Agent 里，数一数"每多一步，就多一次完整模型调用"。想象如果循环失控(无限跳舞)——所以要有循环上限/超时/门控（Dify 的工作流节点通常可设最大循环次数）。这直接对应本章 5.1.3 讲的"多步失控放大器"，以及第六章 6.1.2 的成本观测。

5.3 自查通关 · Agent 系统工程

第六章 MLOps 与工具链

知识域 F3.6 · 让 AI 应用能长跑、能持续迭代的底盘

6.1 知识详解 · MLOps 与工具链版本化、灰度观测、低代码平台三块让 AI 能长跑的底盘

6.1.1 MLOps 平台化：把模型当"代码"一样做版本与发布

小目标

这一节点回答：怎么把 LLM/RAG/Agent 的迭代从"手工作坊"变成可版本、可复用、可监控、可持续的平台化运维管线。价值在于——没有它，模型一升级就全员出乱、出问题回不去、烧钱看不清；所有"要长跑、要持续迭代"的 AI 应用都绕不开这块底盘。

方法论

核心逻辑一句话：把模型和 Prompt"当代码"做版本、发布、监控、回滚——因为 LLM 应用的业务逻辑大量在配置里而非代码里。

判断是否"可持续"，沿一条可闭环的运维管线自查五步是否成立：

版本化 → 回归门禁 → 灰度 → 观测 → 秒回
(可回溯)  (先过评测集) (小流量试) (盯trace/成本/质量) (越线自动回滚)

配套三块能力：

  • 统一模型网关（Model Gateway）：收敛所有对模型/供应商的调用，管权限、限流、成本、一键切换后端。
  • 配置版本化（Config Versioning）：把 Prompt/Agent 工作流/RAG 索引配置当"代码"同级，可回溯、可整体回滚。
  • 以回归为门禁的流水线：改动先过评测集，不达标不放行。
知识点
  • 业务逻辑大量在配置里：LLM 应用的核心逻辑在 Prompt/工作流/索引配置，不在代码里——不改版本化，一出问题只能靠记忆回改。
  • 五步可闭环即"可持续"：版本化→回归门禁→灰度→观测→秒回，缺一环就成了"手工作坊"。
名词卡
名词一句话白话
MLOps / LLMOps｜平台化运维把模型从训练到上线、监控、回滚做成可版本、可复用、可持续的平台化管线；LLMOps 特指大模型/Prompt/Agent 侧。
Model Gateway｜模型网关把所有模型/供应商调用收敛到统一入口：管权限、限流、成本、一键切换后端。
Config Versioning｜配置版本化把 Prompt/Agent 工作流/RAG 索引配置当"代码"同级，可版本、可回溯、可整体回滚。
易混点模型网关（统一入口治理，第六章）≠ 推理引擎（单点跑快，第三章）；配置版本化 vs 代码版本管理——机制相似，但对象是配置而非源码。
练一练

微观小实验（聚焦本节点，约 8 分钟）：在 Dify 里亲手做一次"配置版本化"。

  1. 打开你 第四章 的 RAG 应用，改一行系统提示词（如换一句语气）。
  2. 保存，找平台的历史版本/发布记录，确认能"一键回到上一版"。
  3. 验证：用一句话说清"为什么 LLM 应用的配置不改版本化、一出问题只能靠记忆回改"。

6.1.2 灰度发布、回滚与观测：改模型怎么不"炸全员"

小目标

这一节点回答：改模型 / 改 prompt 怎么"小流量试、可秒回"，不"炸"到全量用户。价值在于——LLM 输出是概率性的、会静默改变行为，改动影响面难预估；若直接全量替换，可能一个月后才发现大量用户受影响。

方法论

上线动作三件套：

  • 金丝雀/灰度（Canary Release）：新版先切极小流量（常见 1–5%）给真实用户试，指标达标再逐步放量——因为 LLM 改版会静默改变行为，必须先小流量验证。
  • 快照回滚（Snapshot Rollback）：出问题时把整个应用一次恢复到某个历史"配置快照"——回滚的不只是单点，而是整套 prompt+agent+模型+参数的绑定关系（坏常来自多配置叠加，只回滚单点反而制造不一致）。
  • A-B 测试（发布版）：真实环境同时跑两版、随机分桶，用在线事实对比决定去留。

观测四件套（上线盯防，缺一即短板）：

  • 链路追踪（Tracing）：记录一次调用的完整轨迹（prompt→命中检索→工具/Agent多步→回答→引文），让坏答案可定位到具体环节。
  • 成本观测（Cost Observability）：对每次调用 token 用量/费用持续计量与告警——成本是烧钱哨兵（Agent 多步循环可能成本失控）。
  • 在线质量指标：转人工率、满意度、一次解决率、超时率——作为灰度/回滚的判据。
  • 回归门禁（Regression Gate）：把业务评测集当发布"闸门"，任何改动指标不达标就拦下；定时重评抓"漂移"。

核心口诀：没观测不碰生产；在线指标比离线榜更可信，小流量期间就看在线。

知识点
  • 没观测不碰生产：先建 trace+成本+质量+回归四件套，缺一项即是短板。
  • 改动 LLM = 金丝雀小流量试 + 快照整体回滚 + A-B 在线对比，没有这套别直接全量上。
名词卡
名词一句话白话
Canary Release｜金丝雀 / 灰度发布新版先切 1–5% 流量试运行，指标达标再逐步放量——因 LLM 会静默漂移，改版必须小流量试。
Snapshot Rollback｜快照回滚出问题把整套"prompt+agent+模型+参数"配置快照整体恢复，而非单点回滚。
A-B Testing｜A/B 测试（发布版）真实环境同时跑两版、用户随机分桶，用在线事实对比决定去留。
Tracing / LLM Tracing｜链路追踪记录一次调用全链路轨迹（prompt→检索→工具/Agent→回答→引文），坏答案可定位到具体环节。
Cost Observability｜成本观测对每次调用 token 用量/费用持续计量与告警，把"烧钱"变成可设预算、能告警的对象。
Regression Gate｜回归门禁把业务评测集当发布"闸门"，改动指标不达标就拦下；定时重评抓"漂移"。
易混点灰度（上线稳妥放量、发现问题回滚）≠ A/B（长期同时两版、用数据做产品决策）；回归门禁（上线前/离线过评测集）≠ 灰度盯盘（小流量在线看指标）。
练一练

微观小实验（聚焦本节点，约 8 分钟）：在一个不影响真实用户的测试应用上，完整走一遍"改糟→回滚→秒回"。

  1. 改一个东西当作"发新版"，设一个"小范围先试"（平台有发布/访问范围可切）。
  2. 故意改糟，用版本回滚退回上一版，看能否"一键秒回"。
  3. 验证：用一句话说清"为什么必须小流量试 + 快照整体回滚"，并指出观测四件套里缺了哪一件会出大事。

6.1.3 工具链与低代码平台：不写代码也能搭起 AI 应用

小目标

这一节点回答：不写代码也能搭起 AI 应用——把 RAG、Agent、工作流封装成"搭积木式配置"的一层。价值在于它是从想法到 Demo、再到轻量上线的最快路径，也是产品/业务人不用等工程也能自己点起来的第一块敲门砖。

方法论

先分清"一层的两端"——按想要多少自由度划分：

  • ① 编排框架（代码级）：LangChain / LlamaIndex，自由度最高，工程团队掌控，可深度定制、做灰度与观测——更接近"造轮子升级"，运维责任在你。
  • ② 低代码/可视化平台：Dify / Coze / 腾讯元器，免代码、快、可上线，产品/业务人也能搭——把"上线效率 vs 可控性/迁移成本"做权衡。

一句话：框架给自由度、平台给速度。平台越快，越可能有供应商绑定与迁移成本；重度定制/复杂编排要退回代码级。

看懂一个平台靠五层坐标系（不只会用，还要能看懂内部由哪些能力层构成，换平台/查问题/估天花板才有共同坐标系）：

① 模型接入层  统一接多模型/多供应商：密钥、路由、成本
② 知识库层    封装RAG：上传→分块→向量→检索（对应第四章）
③ Agent/工作流层 可视化节点编排：工具、循环、记忆、门控（对应第五章）
④ 应用/发布层  做成对外入口：对话、API、Webhook
⑤ 观测/运营层  日志、调用量、错误、成本看板（对应 6.1.2）

看平台天花板 = 看这五层各自的开放度：哪层锁死、哪层可被代码覆盖——平台绑定风险本质上发生在每一层的"可迁出成本"上。

知识点
  • 框架给自由度、平台给速度：别混；重度定制/复杂编排仍要退回代码级。
  • 看懂平台靠五层：模型接入/知识库/Agent工作流/应用发布/观测运营——换平台、查问题、估天花板才有共同坐标系。
  • 选型看三点：从想法到可上线 Demo 的周期、集成打通企业系统（知识库/CRM/工单）的难易、平台绑定与迁移成本。
名词卡
名词一句话白话
Low-code / No-code Platform｜低代码 / 免代码平台用可视化节点/积木式配置搭 AI 应用（RAG/Agent/工作流），不写代码也能验证与轻量上线。
Orchestration Library｜编排框架（代码级）以编程方式组装 RAG/Agent/工作流的库（LangChain / LlamaIndex），自由度最高但要求工程能力、运维责任在你。
LLM Gateway 平台化｜模型接入层低代码平台里 AI 应用统一接入多模型/供应商的能力抽象（与第六章的模型网关话题相接）。
Workflow｜工作流（平台内）可视化节点编排图层，把步骤与门控串成可执行流程（工程语义见第五章）。
易混点低代码平台（免代码快验证、迁移成本高）≠ 编排框架（代码级全可控、要工程能力）；平台知识库（封装好的 RAG 应用级能力）≠ 向量数据库（底层存查引擎，见第四章）。
练一练

微观小实验（聚焦本节点，约 8~10 分钟）。

  1. 在任一低代码平台，不写代码，按"知识库→搜索→对话→发布"搭一个回答你业务知识的问答应用，再给它套一个简单的输出格式约束（结构化输出）——这是第三部分最简单、最有成就感的第一块敲门砖。
  2. 用五层坐标系认一认刚搭的这版应用：①模型接入/②知识库/③Agent工作流/④应用发布/⑤观测运营各对应去哪找。
  3. 刻意换一层试试（如换一个模型、或把分块大小调大），看它能不能被调整。
  4. 验证：用一句话说清"这版的门在哪、绑定/迁移风险在哪个层"，并回答"重度定制要退回哪一层"。

6.2 实操配套 · MLOps 与工具链

目标学完 6.1.1~6.1.3 后，马上动手。目标：看懂一个低代码平台内部五层、并做一次"灰度/回滚/观测"的演练（不需要真服务器，在平台上安全模拟）。约 45~60 分钟。

步骤 1 · 用"五层坐标系"看懂 Dify（本章 6.1.3 的核心）

在 Dify 后台逛一圈，找到这五层各自对应哪：

  1. 模型接入层：应用设置里的"模型"（多模型切换/密钥）。
  2. 知识库层：你 第四章 建的"知识库"模块（封装 RAG）。
  3. Agent/工作流层：应用编排画布（节点/工具）。
  4. 应用/发布层：右上角的"发布"、对外 API/Webhook 入口。
  5. 观测/运营层：日志、调用量、错误、成本看板。
理解看平台天花板 = 看这五层各自开放度：哪层锁死、哪层可被代码覆盖。→ 这就是"平台绑定风险"在哪的抓手。

步骤 2 · 玩一次"版本化"(把配置当代码)

  1. 在你 第四章 的 RAG 应用里，改一行系统提示词（如换一句语气）。
  2. 保存；找找平台的历史版本/发布记录。
  3. 理解：能一键回到上一版本 = 配置版本化。LLM 应用逻辑大量在配置里——能版本化才能秒回。

步骤 3 · 模拟一次"灰度/回滚"（在平台上安全演练）

  1. 拿一个不影响真实用户的测试应用。
  2. 改一个东西 → 当作"发新版"；设一个"小范围先试"(平台有发布/访问范围可切)。
  3. 故意改糟 → 用版本回滚退回，看能不能"秒回"。
体会LLM 输出是概率性的，改动影响面难估，必须小流量试、可秒回(金丝雀+快照回滚)。你的一个小测试应用就是最安全的练手场。

步骤 4 · 看一眼"观测四件套"该盯啥（对应 6.1.2）

在日志/成本看板里认一认：

  • Tracing：能不能看到一次调用的"prompt→检索→回答"轨迹。
  • Cost：有没有单次调用 token 用量/费用(Agent 多步=烧钱哨兵)。
  • 质量：转人工率/满意度/超时率。
  • 回归门禁：一个"改动要先过评测集才算数"的闸门，先理解概念即可——具体怎么改到评测，在本节自查后的路线里展开。
口诀没观测不碰生产；在线指标比离线榜更可信。

6.3 自查通关 · MLOps 与工具链

附录 A 收尾检验

学完本阶段后的总验收：三个问题过后，动手完成三件事

A.1 能回答（知识点清晰）

  1. RAG 的三支柱是哪三条？每一段的坑是什么？
  2. 微调 vs RAG 改的分别是什么？为什么"能用 PEFT 就别全参"？
  3. Agent 能"办成事"靠哪三层？为什么"先 workflow 再 agent"是底线？

A.2 能动手（循序渐进、符合实操）

关卡任务对照章节
落地·最低门槛用低代码平台把一个 RAG 知识问答"搭起来跑起来"6.1.3
进阶·核心跑通一次 LoRA 微调，能看懂 loss、能排查"没学上去"2.1.4
进阶·度量能说清推理的决策、能给 Agent 定一套成功/成本评估口径第三章、5.1.3
检验通过标准（来自知识库"如何评测"的工程化落地）：RAG 检索/生成分层有数可看、微调前后有对比有回归、Agent 用成功率/轨迹/成本三件套兜底。

附录 B 本阶段与前后阶段的衔接

把这一阶段放进完整学习路线看它垫了什么、通向哪里

  • 前置：建议先花约 3 小时垫底 ①0-1 / ①4-1 / ①4-3；RAG 的知识底座见 ②6；微调（Fine-Tuning）依赖 ①3。
  • 后置：本阶段讲"怎么把模型搭出来"→ 下一阶段把它产品化 → 再下一阶段做评测与合规。其中评测、幻觉与时效，是与本阶段关系最紧的两个后续方向。