FDE W1D3 学习手册 · 模型选型与技术边界
W1 Day3 · A/C 级（必掌握 + 架构考察）· 4h · 学完能针对任意需求"画出决策树"，并讲清为什么在某个保险场景选 RAG 而非微调
本日定位：前两日讲"模型怎么算、参数怎么调"。今天进入工程决策层——面对一个业务需求，怎么判断该用 Prompt 优化 / RAG / 规则引擎 / 微调 / 小模型 / 本地模型 / 闭源模型。这是 FDE 面试的"总纲级"问题，几乎所有方案题都建立在它之上。
学完能回答：① 给定一个需求如何一步步决定用哪种方案；② 8 大选型的权衡维度；③ 为什么特药理赔审核该用 RAG 而不是微调；④ 数据安全、成本、延迟如何改变选型。
使用方法：先看 s2 决策树与 s10 矩阵建立框架 → 重点背 s13/s14 两个达标线 → 配合《FDE-W1D3-评测题.md》自测。选中不熟的词可标注（左下★重要 / 右下📌待查）。
一、选型总览：你手里有哪些"杠杆"
大模型工程落地，并非"调一个模型"那么简单。FDE 在方案设计时要从一套分层技术杠杆里组合出最优解。按"改动成本从低到高、能力上限从低到高"排序：
- 优化 Prompt：零代码改动，只改输入文本。成本最低、见效最快。
- 规则引擎 / 硬编码：确定性的 if-else、正则、查表。零模型不确定性，但只能覆盖已知模式。
- RAG（检索增强）：外接知识库，让模型"边查边答"。解决知识时效和私有知识问题。
- 小模型 / 本地模型：用 7B~14B 本地模型或蒸馏模型替代大模型，省成本、保隐私、低延迟。
- 闭源模型：GPT/Claude/Qwen-Max/DeepSeek 等 API，能力上限高，但成本高、数据出域。
- 微调（Fine-tuning）：用自有数据训练模型权重，改变模型"固有行为"。成本最高、周期最长、维护最难。
关键认知：这六种不是互斥的，而是可叠加的组合。一个生产系统往往是"规则引擎做前置拦截 + RAG 做知识补充 + 大模型做语义理解 + 小模型做轻量过滤"的混合体。
选型本质是在"成本、延迟、能力、可控性、数据安全"之间做权衡。口诀：能不调模型就不调，能不微调就不微调，能用小模型就不用大模型，能用规则就不用模型。
二、决策树：从一个需求到一种方案
面试要能口头画出一棵"需求 → 方案"的决策树。下面给出标准骨架，面试时可据此展开。
需求 → 是否需要"模型理解语义/生成"？
├─ 否 → 规则引擎 / 查表 / 正则（确定性问题）
└─ 是 → 知识是否私有 / 高频变动 / 需溯源？
├─ 是 → RAG（知识在库外，模型只负责"读+答"）
└─ 否 → 是否需改变模型"固有行为/风格/稳定格式"？
├─ 是（且数据量足、长期复用）→ 微调
└─ 否 → 是否对成本/延迟/隐私极敏感？
├─ 是 → 小模型/本地模型（或规则兜底）
└─ 否 → 直接用闭源大模型 + 优化 Prompt
2.1 决策节点的判断条件
| 判断节点 | 选 A 的条件 | 选 B 的条件 |
|---|
| 要不要模型 | 需语义理解/生成/泛化 | 输入确定、规则可穷举 |
| RAG vs 纯模型 | 知识私有、变动快、需可溯源 | 知识在预训练内、静态常识 |
| RAG vs 微调 | 知识型（"知道什么"） | 能力型（"怎么做/什么风格"） |
| 大模型 vs 小模型 | 复杂推理、长上下文 | 简单分类/抽取、高并发低成本 |
| 本地 vs 闭源API | 数据不可出域、延迟敏感 | 追求最强能力、可接受出域 |
把决策树固化成团队的"选型 checklist"，能大幅减少"先拍脑袋选了微调，三个月后发现 RAG 就够了"的返工。FDE 的价值之一，就是阻止过度工程——能用 Prompt 解决的，不上 RAG；能用 RAG 的，不微调。
口述决策树：先问"这活要不要模型干"；要 → 问"知识是不是私有/会变的"→ 是就 RAG；否 → 问"要不要改模型骨子里的能力/风格"→ 是才微调；否则问"成本/隐私敏感吗"→ 是就小模型/本地，否则直接闭源大模型 + 优化 Prompt。
三、何时优化 Prompt（最优先的杠杆）
3.1 原理
Prompt 是模型的"输入指令"。很多效果问题（格式不对、答非所问、缺步骤）其实只是 Prompt 没写清。先调 Prompt 的边际成本几乎为零，所以它是永远的第一步。
3.2 适用条件
- 任务模型"本来就会"，只是输出不稳定 / 不合要求。
- 需要更强的角色设定、步骤拆解、输出格式约束。
- 通过 few-shot 示例就能显著提分的场景。
- 知识是公开常识、无需私有库。
3.3 局限
Prompt 改不了模型的固有知识边界和固有能力上限。它解决"怎么说"，不解决"知不知道"。
优化 Prompt 是成本最低、永远该先试的一步：角色 + 任务 + 约束 + few-shot + 输出格式。只有 Prompt 调到天花板仍不行，才上 RAG/微调。记住——Prompt 管"怎么说"，管不了"知不知道"。
① 别一上来就微调，先确认 Prompt 是否已经穷尽（加角色、加示例、加格式约束、加思维链）。② Prompt 过长会挤占上下文、增加成本，且过复杂的指令模型可能不遵守。③ "Prompt 工程"不是玄学，要靠测试集量化对比，而不是"看着像更好了"。
四、何时用 RAG（检索增强生成）
4.1 原理
RAG = 检索（Retrieval）+ 生成（Generation）。先根据用户问题从知识库检索相关片段，再把"片段 + 问题"一起喂给模型生成答案。模型本身不必"记住"私有知识，而是"临时读"。
用户问题 → 向量/关键词检索 → 取 Top-K 相关文档 → 拼进 Prompt → 模型基于检索内容作答（附引用）
4.2 适用条件
- 知识私有：企业内部文档、保险条款、药品目录（不出域、不进预训练）。
- 知识高频变动：条款每月更新，不可能每次重训模型。
- 需要可溯源：每句答案要能指向原文，便于合规与审计。
- 缓解幻觉：让模型"有据可依"，降低编造。
4.3 局限
- 引入检索链路，增加延迟与维护成本（向量库、切片、召回质量）。
- 检索错了（召回噪声）会"带偏"模型。检索质量决定上限。
- 不改变模型的推理能力，只补充知识。
RAG 是"企业知识库问答"的事实标准。在医疗保险场景，理赔规则、特药目录、医保政策都是私有且常变的，RAG 几乎是必选项。工程上要重点保障召回质量（切片策略、混合检索、重排）和答案溯源。
RAG 解决的是"模型知不知道私有/最新知识"，做法是"先查再答 + 附引用"。它适合知识型问题而不是能力型问题。RAG 的天花板由检索质量决定——召回错了，模型再强也答不对。
① RAG 不是"接个向量库就完事"，检索质量是命门，召回噪声比没有检索更危险（模型被错误文档带偏还显得"有依据"）。② RAG 解决不了"模型不会推理"的问题，复杂多跳推理仍需模型能力或 Agent 编排。③ 数据更新要同步更新索引，否则检索到的是旧知识。
五、何时用规则引擎 / 硬编码
5.1 原理
对确定性强、可穷举、不容错的逻辑，用 if-else、正则、查表、有限状态机实现。零模型不确定性，结果 100% 可预测、可审计。
5.2 适用条件
- 输入/输出可穷举：如"理赔类型 ∈ {门诊,住院,特药}"的分类路由。
- 强合规要求：金额计算、资格校验必须精确，不能"差不多"。
- 高频、低延迟、低成本：规则引擎毫秒级，远快于模型。
- 作为模型的"安全护栏"：模型输出先过规则校验再放行。
5.3 局限
无法处理语义歧义、无法泛化到未见过的表述。规则越堆越难维护（"规则地狱"）。
在保险理赔里，规则引擎应做"前置路由 + 后置校验"：前置把"明显不符合资格"的请求直接拦掉（省模型钱），后置对模型抽取的字段做范围/格式/业务合法性校验。模型负责"语义理解"，规则负责"精确兜底"。
规则引擎适合"确定、可穷举、不容错"的逻辑（资格校验、金额计算、路由）。它零不确定性、可审计、成本低。定位是模型的护栏和前置过滤器，而不是替代模型做语义理解。
六、何时微调（Fine-tuning）
6.1 原理
微调是用自有标注数据更新模型权重，让模型固化某种能力或风格。它改变的是模型"骨子里的东西"，而不是靠 Prompt 临时引导。
6.2 适用条件（谨慎）
- 能力型需求：需要模型稳定学会某种输出格式、特定语气、领域专属推理路径，且 Prompt 已穷尽仍不稳。
- 数据量充足且可复用：几百到几千条高质量指令数据起。
- 长期、高频、规模化：值得为它付出训练与维护成本。
- 开源模型自托管场景，需把"通用模型"变成"业务专用模型"。
6.3 与 RAG 的核心区别（面试高频）
| 维度 | RAG | 微调 |
|---|
| 解决什么 | 知识型（"知道什么"） | 能力/风格型（"怎么做"） |
| 知识更新 | 改知识库即可，模型不动 | 需重新训练，成本高 |
| 数据隐私 | 知识在库内，可控 | 权重可能"记住"训练数据，需脱敏 |
| 成本/周期 | 低（只接检索） | 高（标注+训练+评估+维护） |
| 幻觉控制 | 可溯源，较好 | 仍可能幻觉，且更难排查 |
绝大多数企业场景，"私有知识问答"用 RAG 就够了，不需要微调。只有当你需要模型改变固有行为（比如稳定用某种医学编码风格、某种拒答话术）且 Prompt 无法稳定达成时，才考虑微调。微调和 RAG 也可结合：RAG 补知识 + 微调固能力。
微调改的是模型"能力/风格"，RAG 补的是"知识"。知识型问题优先 RAG（更新便宜、可溯源）；只有"模型怎么答都答不对/不稳"且数据充足时，才微调。能 RAG 不微调，是铁律。
① 最常见的错误：把"模型不知道公司条款"当成需要微调——其实那是 RAG 的事。微调救不了"不知道"，只能救"不会做"。② 微调有"灾难性遗忘"风险，可能把通用能力搞退化。③ 微调数据质量 >> 数量，脏数据会固化坏行为。④ 隐私数据进训练集要脱敏，权重可能泄漏训练样本。
七、何时用小模型 / 本地模型
7.1 原理
小模型（7B~14B，如 Qwen2.5-7B、Phi-3）或本地部署的开源模型，参数量小、推理快、可离线、数据不出域，但能力上限低于旗舰大模型。
7.2 适用条件
- 简单任务：文本分类、简单抽取、意图识别、摘要——这些小模型已足够。
- 高并发、低成本：用 1/50 的成本扛 80% 的简单请求，大模型只处理难的（级联/路由）。
- 数据不可出域：金融、医保等强监管，必须本地推理。
- 低延迟 / 离线：边缘设备、内网环境。
7.3 典型架构：模型路由（小模型打底，大模型兜底）
请求 → 小模型/规则先处理简单case → 置信度低或复杂 → 路由到大模型 → 大模型结果回填
"大模型不是唯一解"。用本地小模型做 80% 的简单请求，既省钱又保隐私；只对复杂/高风险请求调用闭源大模型。这种级联是成本优化的核心手段，也是医保系统常见的合规架构。
小模型/本地模型适合"简单、高并发、数据不出域、低延迟"的任务，成本可低至大模型的几十分之一。经典做法是小模型打底 + 大模型兜底（路由），兼顾成本与能力。
八、何时用闭源模型 / 开源模型
8.1 闭源模型（API 调用）
- 优势：能力上限高、开箱即用、无需运维 GPU、迭代快（厂商持续升级）。
- 劣势：按 token 计费（规模大时成本高）、数据出域（合规风险）、有速率限制、不可控（厂商改模型你被动）。
8.2 开源模型（自托管）
- 优势：数据不出域、可微调、无调用费（仅算力）、可离线、可审计权重。
- 劣势：需 GPU 运维、能力上限通常低于旗舰闭源、版本升级自己负责。
8.3 选型取舍
| 维度 | 闭源 API | 开源自托管 |
|---|
| 能力上限 | 高 | 中（旗舰级开源在追赶） |
| 数据隐私 | 出域风险 | 完全可控 |
| 成本模型 | 按量付费（规模化贵） | 固定算力（规模化便宜） |
| 运维 | 零 | 需 GPU/工程团队 |
医保/金融强监管场景，数据不可出域是硬约束，往往被迫走开源自托管或"闭源 + 严格脱敏 + 合规审查"。FDE 要能根据合规等级倒推架构：合规红线定架构，能力需求定模型。
闭源=强能力、零运维、但出域+按量贵；开源=数据可控、规模化便宜、但要自己扛 GPU 运维。强监管（医保/金融）常被迫选开源或闭源+脱敏。合规红线决定架构，能力需求决定模型。
九、选型维度全景（8 大维度）
任何选型决策，都要从这 8 个维度打分权衡。面试时可逐维度说清"这个场景看重哪个、能牺牲哪个"。
| 维度 | 含义 | 典型取舍 |
|---|
| ① 准确率/效果 | 任务做对的概率 | 高风险（拒赔误判）优先，可牺牲成本 |
| ② 延迟 | 单次响应耗时 | 实时对话要低延迟，批处理可放宽 |
| ③ Token 成本 | 每次调用花费 | 高并发需压成本→小模型/缓存 |
| ④ 上下文长度 | 能处理多长输入 | 长文档/多轮→长上下文模型或切片 |
| ⑤ 数据安全 | 数据能否出域 | 医保强约束→本地/脱敏 |
| ⑥ 部署复杂度 | 运维/集成成本 | 小团队→闭源API，有工程力→自托管 |
| ⑦ 并发吞吐 | 同时扛多少请求 | 高峰并发→需水平扩展/小模型分流 |
| ⑧ 多模态 | 图文/语音支持 | 需读影像/票据→多模态模型 |
选型要按 8 维度打分：准确率、延迟、成本、上下文、数据安全、部署复杂度、并发吞吐、多模态。没有"最好模型"，只有"最适合约束的模型"。先定不可妥协的红线（如数据安全），再优化其余。
十、技术 × 维度 权衡矩阵
| 方案 | 准确率 | 延迟 | 成本 | 数据安全 | 适用边界 |
|---|
| 规则引擎 | 高(确定) | 极低 | 极低 | 优 | 可穷举逻辑 |
| Prompt优化 | 中 | 低 | 低 | 取决于模型 | 模型已会，仅不稳定 |
| RAG | 高(有依据) | 中(含检索) | 中 | 可控 | 私有/变动知识 |
| 微调 | 高(固能力) | 低(自托管) | 高(训练) | 需脱敏 | 能力/风格固化 |
| 小模型/本地 | 中 | 极低 | 极低 | 优 | 简单任务/高并发 |
| 闭源大模型 | 高 | 中 | 高 | 出域风险 | 复杂推理 |
真实系统几乎都是"混合栈"：规则做前置路由+后置校验，RAG 补私有知识，大模型做复杂语义，小模型分流简单请求。FDE 要能画出这个栈，并说清每层为什么在那。
没有单一方案通吃。生产系统是混合栈：规则拦截+校验、RAG 补知识、大模型攻复杂、小模型分流简单。面试能画出混合架构并解释每层取舍，就是高级水平。
十一、医疗保险实战：特药理赔审核选型
以"特药理赔审核"为例，完整走一遍选型。业务：患者提交特药（高值抗癌药）理赔申请，系统需判断是否符合报销政策、是否在目录内、资料是否齐全。
11.1 需求拆解
- 知识来源：特药目录、报销比例、适应症限制——私有、每月更新、需溯源（合规审计）。→ RAG。
- 资格校验：患者是否在保、药品是否目录内、用量是否超上限——确定逻辑、不容错。→ 规则引擎。
- 材料理解：从病历/发票抽取诊断、药品名称、金额——需语义理解。→ 大模型抽取（低 T + 结构化）。
- 敏感数据：病历含个人健康信息，不可出域。→ 本地/开源模型 或 闭源+脱敏。
- 拒答/转人工：存疑案件必须转人工，不能硬编结论。→ 模型 should_refuse + 规则兜底。
11.2 推荐混合架构
申请材料 → [规则引擎] 资格/格式前置校验 → [本地小模型] 字段抽取 → [RAG] 查特药目录与政策 → [大模型] 综合判定(附引用) → [规则引擎] 金额/边界后置校验 → 通过/拒付/转人工
特药理赔选型：知识私有又常变→RAG；资格/金额校验不容错→规则引擎；病历抽取需语义→大模型(低T结构化)；健康数据不出域→本地/开源或闭源脱敏；存疑→转人工。混合栈，RAG 负责"知不知道政策"，规则负责"算得对不对"。
十二、常见误区与踩坑
- 误区1：模型越大越好——大模型的钱花在"简单请求"上是浪费，路由到小模型更优。
- 误区2：一上来就微调——多数私有知识问题 RAG 即可，微调是过度工程。
- 误区3：RAG 解决一切——RAG 补知识不补能力，复杂推理仍需模型或 Agent。
- 误区4：忽视数据安全红线——医保数据出域是合规事故，架构必须先满足合规。
- 误区5：没有量化评估就选型——"感觉 RAG 更好"不算数，要用测试集对比准确率/成本/延迟。
① 选型最大的坑是"先选技术再找需求"（拿着锤子找钉子）。正确顺序是"需求 → 约束 → 决策树 → 混合栈"。② 别用单一大模型硬扛所有请求，成本会爆炸。③ 所有选型结论都要有评测数据支撑，否则无法说服业务方和面试官。
十三、面试达标线①：口头画出决策树
面试官可能直接说："给我讲讲，给你一个需求你怎么决定用什么方案。"标准回答框架：
- 先问清需求性质：要不要模型做语义理解？不需要→规则引擎。
- 再问知识属性：知识私有/常变/需溯源吗？是→RAG。
- 再问能力属性：要改变模型固有行为/风格且 Prompt 不够吗？是→微调。
- 再问约束：成本/延迟/隐私敏感吗？是→小模型/本地。
- 否则：闭源大模型 + 优化 Prompt。
- 收尾：强调真实系统是混合栈，并点出"能不调模型就不调，能 RAG 不微调"。
达标线①满分回答：能不假思索地按"模型否→规则 / 知识私有→RAG / 改能力→微调 / 约束敏感→小模型 / 否则闭源+Prompt"的顺序口述决策树，并补一句"实际是混合栈，FDE 要阻止过度工程"。
十四、面试达标线②：特药理赔为什么选 RAG 而非微调
核心论证（面试要对答如流）：
| 角度 | 选 RAG 的理由 | 不选微调的理由 |
|---|
| 知识性质 | 特药目录/政策是"知识"，不是"能力" | 微调解决能力，解决不了"知不知道最新目录" |
| 更新频率 | 目录每月变，改知识库即可，模型不动 | 微调需重训，更新成本极高 |
| 数据隐私 | 知识留在库内，可控 | 训练数据进权重，有泄漏风险 |
| 可溯源 | 每条结论可附政策原文引用，合规友好 | 微调后模型"内化"知识，难溯源 |
| 成本 | 接检索即可，无需训练 | 标注+训练+评估+维护，昂贵 |
达标线②满分回答：特药理赔是"知识型"问题——目录/政策私有且常变、需溯源合规、数据敏感。RAG 补知识、易更新、可溯源、成本低；微调改的是能力不是知识，且更新贵、难溯源、有隐私风险。所以选 RAG。若还需"稳定用某种医学判定风格"，才在 RAG 之上叠加微调。
面试官可能追问"那什么时候该微调这个场景"——答案是：当抽取/判定的稳定格式与风格（而非知识）Prompt 无法固化、且数据充足时，才在 RAG 之外微调一个专用小模型，二者互补而非替代。
十五、Day 3 自测清单
- 能按"模型否→规则 / 知识私有→RAG / 改能力→微调 / 约束敏感→小模型 / 否则闭源+Prompt"口述决策树。
- 能说清 RAG 与微调解决的本质区别（知识 vs 能力）。
- 能列出 8 大选型维度，并针对一个场景指出"不可妥协的红线"。
- 能解释规则引擎的定位（前置路由 + 后置校验护栏）。
- 能解释小模型/本地模型的适用条件及"小模型打底+大模型兜底"路由架构。
- 能对比闭源 API 与开源自托管在隐私、成本、运维上的取舍。
- 能以"特药理赔审核"为例，讲清为何选 RAG 而非微调（达标线②）。
- 能说出至少 3 个常见选型误区（如先选技术再找需求、一上来就微调）。
- 能画出医疗保险场景的混合栈架构（规则+RAG+大模型+小模型+转人工）。
- 能说出 RAG 的局限（检索质量决定上限、不补能力、需同步索引）。
十六、高频面试题速记卡
Q：给个需求你怎么决定用哪种方案？
先问要不要模型（否→规则）；要→知识私有/常变/需溯源→RAG；改能力/风格且Prompt不够→微调；成本/隐私敏感→小模型/本地；否则闭源大模型+Prompt。实际是混合栈。
Q：RAG 和微调到底什么区别？
RAG 补"知识"（知道什么），易更新、可溯源；微调改"能力/风格"（怎么做），更新贵、难溯源。知识型问题优先 RAG。
Q：特药理赔为什么选 RAG 不选微调？
目录/政策是知识型、常变、需溯源合规、数据敏感。RAG 补知识+易更新+可溯源+成本低；微调改能力不解决"知不知道最新目录"，且更新贵、有隐私风险。
Q：什么时候该直接上规则引擎？
输入/输出可穷举、强合规（金额/资格校验）、高并发低成本、或作为模型护栏前置拦截与后置校验时。
Q：小模型/本地模型适合什么？
简单分类/抽取、高并发低成本、数据不可出域、低延迟。经典做法是小模型打底+大模型兜底路由。
Q：闭源和开源怎么选？
闭源=强能力零运维但出域+按量贵；开源=数据可控规模化便宜但要自己扛GPU。强监管常被迫开源或闭源+脱敏。
Q：选型要评估哪些维度？
准确率、延迟、Token成本、上下文长度、数据安全、部署复杂度、并发吞吐、多模态。先定不可妥协红线再优化其余。
Q：RAG 的致命弱点是什么？
检索质量决定上限——召回错了模型被带偏且显得"有依据"更危险；不补推理能力；索引需随数据同步更新。
Q：微调有哪些坑？
灾难性遗忘、数据质量>数量、救不了"不知道"只救"不会做"、训练数据可能泄漏（需脱敏）、维护成本高。
Q：FDE 在选型上最大的价值是什么？
阻止过度工程——能不调模型就不调，能Prompt不RAG，能RAG不微调，用决策树和评测数据支撑混合栈方案。
FDE W1D3 学习手册 · 模型选型与技术边界（面试级）· 配合《FDE-W1D3-评测题.md》自测
📌 待查★ 重要