FDE W8D5 学习手册 · POC到生产·ROI·成本安全治理
W8 Day5 · A 级（高级/架构/负责人岗必考）· 5h · 学完能讲透"从 POC 到生产怎么走、价值怎么证明、成本安全怎么控"
本日定位：前 7 周你已掌握 RAG / Agent / 平台 / 评测 / 私有化（W6 安全合规、W7 Fine-tune）等技术点，W8 是"把技术收口成项目与岗位"的冲刺周。D5 聚焦高级岗不可回避的软硬复合问题：POC 如何推进到生产、怎么向业务方证明大模型项目的价值与 ROI、成本与安全怎么治理。
候选人背景：36 岁，Java + 大数据 + 医疗保险理赔领域，冲刺高级工程师 / 架构师 / 技术负责人。面试要体现"既懂技术细节、又能扛项目落地与商业价值"。
学完能回答：① 从 POC 到生产有哪些常见坑（数据/评测/监控/成本）与推进节奏；② 大模型项目 ROI 怎么算、怎么向业务方证明价值（不空谈准确率）；③ 成本控制（API vs 私有、缓存、批处理、小模型降级）与安全合规（PII/租户隔离/审计）。
使用方法：通读原理 → 重点看「工程含义」「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W8D5-评测题.md》。选中不熟的词可标注（左下★重要 / 右下📌待查）。
一、POC→生产总览：鸿沟到底在哪
1.1 原理：POC 和生产是两件事
POC（概念验证）的目标是证明"技术上可行"，通常用精选的小样本、人为构造的链路跑通 demo。生产的目标是在真实流量、真实数据、真实约束下"稳定、可控、可运营"。两者之间的落差（"POC 到生产的死亡之谷"）来自四类系统性差异：
| 维度 | POC 阶段 | 生产阶段 |
|---|
| 数据 | 精选样本、干净闭环 | 脏数据、长尾、分布漂移 |
| 评测 | 看几个 demo 觉得"牛" | 系统化指标、回归、bad case 管理 |
| 监控 | 基本没有 | 延迟/成本/质量/安全全链路可观测 |
| 成本 | 不计较 | 每 token 都要算账、要降本 |
1.2 推进的五个阶段
- Demo（1-2 周）：跑通最小链路，验证技术可能性。
- POC（2-4 周）：在代表性数据上验证效果能否达到业务阈值。
- 试点（Pilot，1-2 月）：小流量 / 小业务范围真实用户使用，收集真实反馈与 bad case。
- 灰度（Canary）：按比例放量，监控核心指标与异常。
- 全量生产 + 持续运营：SLA、成本、质量持续追踪与迭代。
生产化不是"把 demo 部署上去"，而是补齐数据、评测、监控、成本、安全、降级六套工程能力。高级岗面试里，能讲出"POC 之后还要补什么"比"怎么搭 demo"更值钱——因为这才是大多数大模型项目真正死掉的地方。
POC 证明"能做"，生产要求"稳做、算得过账、不出事"。从 demo 到全量要经 POC→试点→灰度→生产 四步，每一步补的是数据/评测/监控/成本/安全/降级能力，而不是模型能力本身。
① 别把 POC 的成功率当生产的成功率——POC 数据往往被"美化"（剔除了难样本），真实长尾一上来就崩。② 不要一上来就全量，没有试点和灰度，一次 bad case 可能直接让项目被砍。③ "模型效果不错"不是上生产的理由，"效果稳定 + 可监控 + 成本可接受 + 有降级"才是。
二、数据层面的坑
2.1 原理：LLM 应用的效果由"数据分布"决定
大模型应用的线上效果，很大程度上取决于输入数据的分布是否和评测/POC 数据一致。数据坑主要来自：
- 分布漂移：POC 用的是历史干净数据，线上来了新药品、新政策、新话术，模型没见过。
- 脏数据 / 格式异常：用户输入乱码、超长、非预期格式，导致解析失败或幻觉。
- 标注噪声：评测集标注不一致，导致指标不可信。
- 样本偏差：POC 只看"能答的"，忽略"该拒答的"（呼应 W2 拒答评测）。
2.2 工程应对
| 坑 | 应对 |
|---|
| 分布漂移 | 线上埋点回收真实 query，定期重训评测集；做数据漂移检测 |
| 脏数据 | 输入预处理 + 边界校验 + 失败降级（非预期输入转人工） |
| 标注噪声 | 双标 + 一致性仲裁；评测集版本化管理 |
| 样本偏差 | 评测集按真实分布抽样，专门保留 should_refuse 的 case |
医疗理赔场景数据坑尤其致命：一个新特药上市、一条新医保政策发布，RAG 知识库没更新，模型就用旧知识答，轻则答错、重则合规事故。所以"知识库更新机制"和"数据漂移监控"是生产必备，不是可选项。
数据坑 = 分布漂移 + 脏数据 + 标注噪声 + 样本偏差。应对是：线上回收真实 query 持续更新评测集、输入预处理与降级、评测集双标仲裁、按真实分布抽样（含拒答 case）。
① 很多团队"重模型、轻数据"——但 LLM 应用 80% 的问题在数据，不在模型。② 评测集一旦定下来就不动，等于"用去年的题考今年的模型"，指标虚高。评测集必须跟线上分布同步演进。
三、评测体系的坑（为什么只看准确率不够）
3.1 原理：单点准确率无法支撑生产决策
POC 阶段常犯的错是"看几个例子觉得准就上了"。生产评测需要多维度指标体系，把"准"拆开：
| 指标族 | 含义 | 为什么重要 |
|---|
| 任务准确率 | 答案对不对 | 基础，但不充分 |
| 拒答准确率 | 该拒答的是否拒答 | 企业场景防编造（呼应 W2） |
| 格式/可解析率 | 输出能否被系统消费 | 下游要 parse，解析失败=功能失效 |
| 安全合规率 | 有无泄露 PII / 越权 | 合规红线 |
| 鲁棒性 | 扰动输入是否仍稳 | 线上输入千奇百怪 |
| 成本/延迟 | 单次调用 token 与时延 | 直接影响 ROI |
3.2 评测要"可回归"
每次提示词 / 模型 / 知识库变更，都要跑同一套回归集，对比指标变化，防止"改一个 bug 引入三个 bug"。bad case 要入池、归因、闭环。
评测不是 POC 的"一次性表演"，而是生产的"持续质检线"。高级岗要能设计分层评测：单元测试（单步链路）+ 集成测试（端到端）+ 回归测试（防回退）+ 红蓝对抗（安全）。
只看准确率会漏掉拒答失败、解析失败、合规越权、鲁棒性差这些"要命"的问题。生产评测要多维：任务准确 + 拒答准确 + 可解析 + 安全合规 + 鲁棒 + 成本。且要可回归。
① "准确率 95%"如果没说清楚是"在哪些 case 上、含不含拒答"，就是误导。② 不要拿评测集当训练集调参（过拟合评测），否则线上一塌糊涂。③ 拒答率过高也会被业务嫌弃"答得太少"，要在"敢答"和"不乱答"之间找平衡。
四、监控与可观测性的坑
4.1 原理：LLM 应用是"概率系统"，必须可观测
传统软件出错是确定的（抛异常），LLM 应用出错是概率的、渐进的（今天 95% 准，下周政策一变 70%）。没有监控，你连"已经崩了"都不知道。
4.2 要监控的四类信号
- 质量信号：线上抽样评测、用户反馈（赞/踩）、bad case 自动聚类。
- 成本信号：每日 token 消耗、人均对话成本、异常尖峰。
- 延迟信号：P50/P95/P99 时延，超时率。
- 安全信号：PII 命中、越权访问、敏感词触发。
建议做法：每条请求落 Trace（输入、模型、参数、输出、token、耗时、评测分、用户反馈），既用于排障，也用于离线回放评测。这是 Java 大数据背景候选人的优势——把 LLM 日志当成"数据 pipeline"来做。
监控的目标不是"画大屏"，而是"能定位、能告警、能回放"。一个能说清"我们怎么发现模型效果下降、怎么定位到是知识库过期"的候选人，在架构/负责人岗非常加分。
LLM 是概率系统，效果会无声劣化，所以必须监控质量/成本/延迟/安全四类信号，并落全链路 Trace。监控是为了能定位、能告警、能回放评测，不是做报表。
① 只监控"服务可用性（HTTP 200）"不够——返回 200 但答非所问，业务照样崩。② 没有 Trace，出了问题只能"猜"，定位成本极高。③ 监控指标要设阈值告警，别等月底看报表才发现成本炸了。
五、成本控制的坑（看不见的成本）
5.1 原理：成本 = f(调用量, 单次 token, 模型单价)
大模型成本常被低估，因为 POC 阶段调用量小。生产一放大，成本来自：
- 推理单价：旗舰大模型贵，长上下文更贵。
- 重复计算：相同问题反复调用、长 system prompt 每次重发。
- 重试与兜底：校验失败重试、降级都增加调用。
- 上下文膨胀：RAG 召回太多、历史对话全塞进去。
单日成本 ≈ 日请求数 × 平均输入token × 输入单价 + 日请求数 × 平均输出token × 输出单价
成本治理是高级岗的硬指标。能讲出"我们怎么把单次成本从 X 降到 Y"的项目，比"用了最牛的模型"更体现工程能力。Java 大数据背景可以类比：就像优化一个高 QPS 服务的单位请求成本。
成本 = 调用量 × 单次 token × 单价。看不见的成本在重复计算、重试、上下文膨胀。治理要从"降单价、降 token、降调用"三路同时下手。
① 不要以为"用最贵的模型效果最好"——很多场景小模型 + 好 RAG 就够了，贵的只用在难样本。② 长 system prompt 每次重发是隐性浪费，可缓存或用短指令 + 外挂配置。③ 不做成本监控，业务量一上来账单会吓死人。
六、推进节奏：里程碑怎么定
6.1 原理：用"门禁（Gate）"控制每一阶段是否放行
每个阶段结束都要设明确的放行标准，达不到就退回或调整，不盲目推进：
| 阶段 | 放行门禁（示例） |
|---|
| POC 完成 | 在代表性评测集上达到业务阈值（如准确率≥90%、拒答率达标） |
| 试点完成 | 真实用户 NPS / 采纳率达标，bad case 收敛，成本在预算内 |
| 灰度完成 | 核心指标无回退，成本/延迟在 SLA 内，无安全事件 |
| 全量 | 监控告警闭环、降级预案就绪、运营机制就位 |
6.2 节奏原则
- 小步快跑、快速失败：不确定就先小范围试，别憋大招。
- 业务方共担目标：门禁指标和业务一起定，避免"技术说成了、业务说没用"。
- 留降级预案：每个阶段都要有"不行就退回到上一阶段/转人工"的路径。
推进不是"一路狂奔到全量"，而是每阶段设门禁：POC 看评测阈值、试点看真实采纳率、灰度看无回退无事故、全量看运营闭环。达标才放行，不达标就退。
① 门禁指标别定得虚（"效果不错"），要可量化、可测量。② 业务方不参与定门禁，最后容易"技术验收了但业务不认"。③ 没有降级预案就放量，等于赌运气。
七、评估大模型项目：ROI 怎么算
7.1 原理：ROI = (收益 − 成本) / 成本
大模型项目 ROI 的难点是收益往往间接、滞后、难归因。要把收益拆成可量化项：
| 收益项 | 量化方式 |
|---|
| 人力节省 | 原需 N 人天的任务，现自动化比例 × 人力成本 |
| 时效提升 | 处理时长从 X 小时降到 Y，折算业务价值 |
| 准确率/合规提升 | 错误率下降带来的赔付/罚款减少 |
| 收入增长 | 转化率、客单价提升（需归因模型） |
年化收益 = 人力节省 + 时效价值 + 风险下降价值 + 增收
ROI = (年化收益 − 年化成本) / 年化成本
年化成本 = 模型推理费 + 算力/私有化摊销 + 工程人力 + 运维
7.2 成本侧别漏算
- 推理 API 费 / 私有化 GPU 折旧与电费。
- 工程人力（开发 + 评测 + 运营）。
- 知识库维护、数据标注、持续评测成本。
- 试错成本（失败的项目、被砍的方案）。
ROI 不是财务一个人的事，是技术负责人必须能讲清楚的。能给出"我们这个项目第一年投入 X、节省 Y、回收期 Z 个月"的叙事，高级岗面试直接加分。注意把隐性成本（运营、评测、维护）算进去，否则 ROI 虚高。
ROI = (年化收益−年化成本)/年化成本。收益要拆成人力节省+时效+风险下降+增收并量化；成本别漏算推理费、工程人力、知识库运营、试错。回收期比单纯 ROI 更直观。
① 只算"模型调用费"不算"人力+运营"，ROI 会虚高到离谱。② 把"转化率提升"全算给大模型是过度归因，业务方不信。要用 A/B 或对照基线。③ "省了 10 个人"如果没真裁员或转岗，只是"理论上省"，业务方不认。
八、怎么向业务方证明价值（不空谈准确率）
8.1 原理：业务方听得懂的是"钱、时间、风险"，不是"准确率"
技术人爱讲"准确率 92%"，但业务方关心：省了多少钱、快了多少、少赔了多少、客户满不满意。价值证明要完成"技术语言 → 业务语言"的翻译。
8.2 证明价值的四步法
- 对齐业务目标：先问业务方"你最痛的是什么"——是理赔员不够、还是赔付差错高、还是客户等太久。
- 选对照基线：用"上线前 vs 上线后"或"A 组用 / B 组不用"的对比，给出可归因数字。
- 讲场景化收益：不说"准确率 92%"，说"特药理赔初审从 2 小时压到 8 分钟，初审员人均日处理量翻 3 倍"。
- 持续汇报：按月给业务方看成本、采纳率、bad case 收敛曲线，建立信任。
话术示例："我们不是来炫技术，是来解决'初审慢、差错高'的。上线 3 个月，初审时效降 93%，因材料不全的退件率降 40%，相当于释放 5 个初审人力去做高价值核赔——这是您能直接看到的。"
能向业务方"翻译价值"的技术负责人，才是真负责人。这恰恰匹配候选人"Java+大数据+医疗"背景——你懂业务系统、懂数据口径，比纯算法背景的人更适合做"技术到业务的桥梁"。
证明价值 = 对齐业务痛点 → 设对照基线 → 用"省多少钱/快多少/少赔多少"代替"准确率" → 持续汇报。业务方要的是结果指标，不是模型指标。
① 一上来就甩准确率，业务方直接走神。先听痛点再讲方案。② 没有基线对照的"提升"都是自嗨。③ 把技术收益翻译成业务结果时别夸大，一次翻车信任就没了。
九、成本控制方法：API vs 私有 / 缓存 / 批处理 / 小模型降级
9.1 API vs 私有化（呼应 W6 私有化与成本）
| 维度 | API（公有云） | 私有化（自建） |
|---|
| 起步成本 | 低，按量付费 | 高，GPU 采购/租赁 |
| 边际成本 | 随调用量线性上升 | 摊薄后趋近固定 |
| 数据安全 | 需脱敏/合规评估 | 数据不出域，合规友好 |
| 适用 | 量小、试水、波动大 | 量大、稳定、强合规 |
决策拐点：当月调用量 × API单价 > 私有化月摊成本 时，私有化更划算（医疗理赔量大且强合规，常走私有化）
9.2 缓存（Cache）
- 语义缓存：相似问题命中缓存答案，省一次推理（如 Redis + 向量相似度）。
- 前缀缓存：长 system prompt / 知识上下文复用，避免每次重算（很多 API 支持 prompt cache）。
- 结果缓存：对确定性查询（如"某药品报销比例"）直接缓存。
9.3 批处理（Batch）
非实时任务（如夜间批量初审、离线抽取）走批处理 API，单价常低 50%，用时延换成本。
9.4 小模型降级（Routing）
用路由器把简单问题分给小模型/规则，只有难样本才调旗舰模型：
分类/抽取/简单问答 → 小模型(7B/14B) ｜ 复杂推理/多步 → 大模型
成本治理是一套组合拳：先用路由把"简单活"留给小模型，再用缓存吃掉重复查询，长上下文走前缀缓存，离线任务走批处理，量大且合规的走私有化。Java 大数据候选人可把这套类比成"读写分离 + 缓存 + 批处理"的架构思想。
降本四招：① API/私有看拐点（量大合规选私有）；② 语义缓存+前缀缓存吃重复；③ 离线走批处理省半价；④ 路由器把简单问题分小模型，难样本才用大模型。组合用最划算。
① 缓存要防"脏缓存"——知识库更新后旧答案还在缓存里，要有失效机制。② 小模型降级若路由判错，会把难题给弱模型答崩，路由本身也要评测。③ 私有化不是"买了 GPU 就便宜"，还有运维、折旧、扩容成本，量不够反而更贵。
十、安全合规：PII / 租户隔离 / 审计（呼应 W6）
10.1 原理：医疗理赔是强合规场景
理赔数据含大量 PII（姓名、身份证、病历、保单），受《个人信息保护法》等约束。生产必须解决三件事：
| 合规项 | 工程做法 |
|---|
| PII 防护 | 输入脱敏（姓名/证件号打码）、输出过滤、最小必要原则 |
| 租户隔离 | 多租户数据物理/逻辑隔离，检索不串库，向量库按 tenant_id 过滤 |
| 审计 | 全链路日志留痕：谁、何时、用哪份知识、模型回了什么 |
| 权限 | 基于角色的访问控制（RBAC），越权请求直接拒 |
10.2 与 W6 私有化的关系
W6 讲的是"私有化部署怎么落地"，W8D5 这里强调"为什么必须私有化/合规"——医疗场景数据不出域，是私有化的核心驱动力之一。两者是"手段 → 目的"的关系。
合规不是"上线后补"，是"架构一开始就要内建"。能在面试里把"PII 脱敏链路 + 租户隔离方案 + 审计日志"讲成一套架构，是架构/负责人岗的硬通货。这正好发挥你医疗 + Java 后端（RBAC、多租户）的积累。
医疗合规三件套：PII 脱敏（输入打码+输出过滤）、租户隔离（检索按 tenant 过滤不串库）、审计留痕（谁何时用哪份知识回了什么）。合规是架构内建，不是事后补丁，也驱动 W6 私有化。
① 只脱敏输入不脱敏输出，PII 照样从回答里漏出去。② 向量库不做 tenant 过滤，A 客户的知识可能召回给 B 客户——严重事故。③ 审计日志本身含敏感信息，也要加密脱敏存储。
十一、规则 / RAG / Agent / 人工 边界怎么划分
11.1 原理：不是所有问题都该上大模型
大模型贵且概率性，要把确定性高、成本低的事留给传统手段，模糊、需推理的事才用大模型：
| 任务类型 | 首选方案 | 理由 |
|---|
| 固定规则/强校验（算保费） | 规则引擎 / 代码 | 确定、可审计、零成本 |
| 基于已知文档的问答 | RAG | 可控、可溯源、成本中 |
| 多步、需调工具的任务 | Agent | 灵活但贵且有风险 |
| 高风险/模型不确定 | 人工 | 兜底、合规 |
11.2 决策原则
- 能规则就别 RAG，能 RAG 就别 Agent：越往右越贵越不可控。
- AI 负责"初筛+建议"，人负责"决策+兜底"：理赔尤其如此。
- 每个 AI 环节都要能"转人工"：置信度低/触发安全/超阈值就交人。
边界划分本质是"成本与风险的分级治理"。高级岗要能画出"任务→方案"的决策树，并讲清为什么某些环节坚决不让模型碰（如最终赔付决定）。这是技术判断力的体现。
边界：规则(确定/零成本) → RAG(可控/中成本) → Agent(灵活/贵) → 人工(高风险兜底)。原则：能规则就别 RAG、能 RAG 就别 Agent；AI 做初筛、人做决策；每环都能转人工。
① "什么都用 Agent"是新手病——Agent 贵且有失控风险，简单检索别上 Agent。② 让模型直接做"最终赔付决定"是红线，模型只给建议，人来定。③ 没有"转人工"兜底，一旦模型抽风就是客诉/合规事故。
十二、相关学习资源（中文 / 非 OpenAI）
📚 本日配套资源：
• 《FDE面试备战手册.html》—— 高级/架构岗面试体系总览，含项目叙事与 ROI 话术模板。
• 通义千问（Qwen）大模型文档 / 阿里云百炼平台 —— 企业级 RAG、Agent、私有化部署实战参考。
• DeepSeek 开放平台文档 —— 成本控制（缓存、批处理）、API 调用与评测实践。
• 模拟面试：可用 通义 / DeepSeek 当面试官，把本手册各「面试话术」作为提问素材自测（详见 W8D6）。
• 合规参考：《个人信息保护法》、金融行业 AI 应用合规指引（了解 PII / 审计要求）。
资源用法：先啃《FDE面试备战手册》建立面试框架，再用通义/DeepSeek 模拟"怎么向业务方证明 ROI"这类开放题，最后回本手册补技术细节。
十三、面试达标线①：能讲清从 POC 到生产的路径和常见坑
| 阶段 | 核心交付 | 常见坑 |
|---|
| POC | 技术可行性 + 达到业务阈值 | 数据被美化、只看 demo |
| 试点 | 真实用户采纳、bad case 收敛 | 无真实反馈、样本偏差 |
| 灰度 | 按比例放量、无回退 | 没降级预案就放量 |
| 生产 | 监控/成本/安全闭环 | 只监控可用性、无 Trace |
核心叙事：POC 证明"能做"，生产要求"稳做+算账+不出事"。从 demo 到全量走 POC→试点→灰度→生产，每阶段设门禁；数据/评测/监控/成本四套工程能力是 POC 后必须补齐的，而不是模型能力本身。
十四、面试达标线②：能讲清怎么向业务方证明大模型项目的 ROI（不空谈准确率）
对齐痛点 → 设对照基线 → 量化收益(人力/时效/风险/增收) → 扣掉全成本(推理+人力+运营+试错) → 算回收期 → 持续汇报
- 对齐业务目标：先听业务最痛的点，不说技术黑话。
- 选对照基线：上线前后 / A-B 对照，避免过度归因。
- 量化收益：用"省多少钱、快多少、少赔多少"替代"准确率"。
- 全成本口径：推理费 + 工程人力 + 知识库运营 + 试错，别只算调用费。
- 持续汇报：按月给业务方看采纳率、成本、bad case 收敛。
证明价值不是报准确率，是翻译业务结果：用对照基线 + 场景化收益（如"初审从 2h 压到 8min，释放 5 个初审人力"）+ 全成本口径算回收期，并持续汇报建立信任。
十五、W8D5 自测清单
- 能画出 POC→试点→灰度→生产 四阶段，并说清每阶段要补的工程能力（数据/评测/监控/成本/安全/降级）。
- 能讲出 POC 与生产的四类系统性差异，以及"死亡之谷"为什么常死在坑上。
- 能列出数据层面的四个坑（漂移/脏数据/标注噪声/样本偏差）及应对。
- 能解释为什么"只看准确率不够"，并说出生产评测的六个指标维度。
- 能讲清 LLM 应用要监控的四类信号（质量/成本/延迟/安全）和为什么需要全链路 Trace。
- 能写出成本公式，并说出四个"看不见的成本"（重复计算/重试/上下文膨胀/隐性运营）。
- 能解释推进节奏的"门禁"机制，说出每个阶段的放行标准。
- 能写出 ROI 公式，并说清收益怎么拆、成本别漏算什么。
- 能讲出向业务方证明价值的四步法，并现场翻译一句"准确率 92%"成业务语言。
- 能对比 API vs 私有化的拐点，并说出降本四招（缓存/批处理/小模型降级/路由）。
- 能讲清医疗场景的合规三件套（PII/租户隔离/审计）及与 W6 私有化的关系。
- 能画出规则/RAG/Agent/人工 的边界决策树，并说清为什么最终赔付不让模型定。
- 能讲清两个达标线（路径与坑、ROI 证明）。
十六、高频面试题速记卡
Q：POC 成功是不是就能上生产？
不是。POC 证明"能做"，生产要求"稳做+算账+不出事"。POC 数据常被美化，真实长尾一上来就崩，必须补数据/评测/监控/成本/安全/降级能力。
Q：为什么不能只报"准确率 92%"？
准确率掩盖了拒答失败、解析失败、合规越权、鲁棒性差这些要命问题。业务方要的是省多少钱、快多少、少赔多少。
Q：大模型项目 ROI 怎么算才不虚？
ROI=(年化收益−年化成本)/成本；收益拆人力/时效/风险/增收并量化，成本必须含推理费+工程人力+运营+试错，并用对照基线避免过度归因。
Q：API 和私有化怎么选？
看拐点：月调用量×API单价 > 私有化月摊成本时私有化更划算。医疗理赔量大且强合规，常走私有化（呼应 W6）。
Q：降本除了换便宜模型还有啥？
四招组合：路由器把简单问题分小模型、语义/前缀缓存吃重复、离线批处理省半价、量大合规走私有化。缓存要防脏数据。
Q：医疗场景合规三件套是什么？
PII 脱敏（输入打码+输出过滤）、租户隔离（检索按 tenant 不过库）、审计留痕（谁何时用哪份知识回了什么）。合规内建非补丁。
Q：什么任务该用 Agent，什么不该？
能规则就别 RAG、能 RAG 就别 Agent。固定强校验用规则，已知文档问答用 RAG，多步调工具用 Agent，高风险/不确定转人工。
Q：为什么最终赔付决定不能让模型做？
模型概率性且可能幻觉，涉及钱和合规属红线。AI 做初筛和建议，人做决策和兜底，每环节都要能转人工。
Q：推进节奏里的"门禁"是什么？
每阶段设量化放行标准：POC 看评测阈值、试点看真实采纳率、灰度看无回退无事故、全量看运营闭环。不达标就退或调整。
Q：LLM 应用监控和 traditional 监控有何不同？
传统监控可用性(HTTP200)不够——返回200也可能答非所问。要监控质量/成本/延迟/安全四类信号并落全链路 Trace 以便定位回放。
FDE W8D5 学习手册 · POC到生产·ROI·成本安全治理（面试级）· 配合《FDE-W8D5-评测题.md》自测
📌 待查★ 重要