什么问题该微调、什么问题该 RAG、什么问题写好 prompt 就够了？
谁在问：各轮必问；一面考概念边界，二三面考真实排除过程；产品向面试官也会问
口语化问法
- RAG 和微调你怎么选？分别适合什么场景？
- 给你一个新需求，你怎么判断该用哪种方案？
- 什么情况下你会说'这个 prompt 写好就行了，不用上别的'？
考察意图
这是本章最高频、也最能看出层级差异的一道题。三个层级：
- 背表格：知道"RAG 管知识、微调管风格"。2026 年这只是及格。
- 有决策树：能给出一个自上而下、可当场画出来的排除流程，且知道前置闸门是什么。
- 有排除过程：讲自己的项目时，先说"我排除了什么、为什么排除"，而不是从"我们的方案是 X"开始。
面试官真正在意的是第三层。直接从结论讲起的候选人，等于承认自己没做过比较。
参考答案
60 分答案（及格线）
- RAG 适合知识密集、更新频繁、需要溯源的场景。知识放在外部知识库里，改一条就生效，答案能标出处。
- 微调 适合需要固定风格、固定格式、领域表达的场景，把模式烧进权重，推理时 prompt 可以更短。
- prompt 适合需求简单、变化快、想快速验证的场景，成本最低、迭代最快。
一般的顺序是先试 prompt，不行再上 RAG，还不行再考虑微调。
三条都对，及格。但这是一张静态的对照表，没有判断动作，也没有 2026 的增量。追问一个具体场景就容易含糊。
90 分答案（有生产经验的回答）
我不按"技术"分，按问题的类型分。任何需求先归到三类之一：
前置闸门：没有评测集，四条路一条都不要开始
（50–100 条起步，含边界样例；先跑 few-shot 基线并记下分数）
│
模型的问题到底属于哪一类？
│
┌──────────────────────────┼──────────────────────────┐
▼ ▼ ▼
「不知道」 「不会做」 「做得到但太贵太慢」
知识/时效/要溯源 能力/格式/风格 延迟/单价/QPS
│ │ │
▼ ▼ ▼
RAG ① 先提 effort 档位 + 改 prompt 蒸馏到小模型
│
├─ 仍不行，且规则写不出、
│ 只能给例子 → SFT / LoRA
└─ 仍不行，且能写自动判分器
→ RLVR / RFT几个关键点：
① 逐级排除，不能跳级。 面试里最常见的失分就是直接从"我们做了微调"讲起，整段回答建立在一个没被验证的前提上。
② 微调那一支的判据非常锋利：你写不出这条规则，只能给例子。 反过来说，如果你能把它写成 200 字的 system prompt，那就别训。
③ 2026 年这张图和三年前不一样了。 微调的地盘被吃掉三块半：
- 知识注入 → RAG（2023 年就成立）
- 格式与指令遵循 → 基座能力 + 结构化输出/约束解码。OpenAI 官方就是拿这条当收缩微调平台的理由：新基座指令与格式遵循大幅提升，prompt 方案更便宜更快
- 推理深度 → effort 档位。答得浅先提档位，不是加提示词，更不是微调
- （半块）few-shot 示范 → 长上下文 + prompt 缓存，塞几百个例子已经是可负担的日常操作
④ 三个 2026 年的错误理由，说出来基本可以判定认知停在几年前："让模型学会公司知识"（该 RAG）、"让它稳定输出 JSON"（该结构化输出 + 三层校验）、"让它更聪明"（该提 effort 档位）。
⑤ 还有一条容易被忽略的判据：资产寿命。 评测集换基座 100% 保值且越攒越值钱，prompt 改改能用，RAG 索引基本无损，只有微调权重是换基座就归零的。所以"要不要微调"也可以问成：你愿意把多大比例的投入压在一个基座换版就清零的资产上？
举个我们真实做过的判断：法务同事要一个"合同风险条款提取"。第一反应可能是微调，但拆开看是三件事——条款在哪（知识，走 RAG 检索相关判例和内部条款库）、按什么口径判风险（规则，能写清楚，走 prompt + 结构化输出）、用什么口吻写结论（本所的行文风格，写不出规则只能给例子，只有这一块微调）。最后微调只做了最后一小块，1800 条数据、LoRA、几小时训完。把一个需求拆成三类而不是整包丢给一种方案，是这道题真正想考的能力。
追问链
客户问「公司年假是几天」，模型答错了，你怎么办？
期望典型的「不知道」→ 知识问题，走 RAG。不该微调：政策会改，改一次重训一次；答案还要溯源到制度原文，微调给不出出处。若制度文档本身写得含糊，那是数据源问题，先修文档信号答「把制度写进微调数据」→ 本章头号错误答案；主动提「需要溯源」这个额外理由 → 做过 toB 场景那如果是「回答的语气不像我们品牌」呢？
期望先判断规则写不写得出来：「多用短句、不用感叹号、不说『亲』」写得出 → 进system prompt，不训；只有怎么写都描述不清、只能拿出三百份范文说「照这个感觉」时，才是微调的场景。判据很实操：让最懂品牌的人把规则写成 200 字，写得出就不训信号直接答「语气问题该微调」→ 用的是 2023 年的映射表；给出「先让人试着把规则写出来」这个可执行判据 → 真做过取舍RAG 和微调能一起用吗？先后顺序是什么？
期望能，而且常见：RAG 供知识，微调调「怎么用这些知识说话」（引用格式、拒答口径、结论结构）。顺序是先 RAG 后微调 —— 检索不稳就去微调，等于把检索噪声一起学进权重；微调数据还要包含检索结果的形态，否则线上分布与训练分布对不上信号说得出「微调数据要包含检索结果形态」→ 真把两者串起来做过；只答「可以一起用」→ 泛泛什么时候你会说「这个需求根本不该用大模型做」？
期望四类：规则完全确定且枚举得完（走正则 / 规则引擎，又快又准又可审计）；要求 100% 准确、不容任何错（大模型给不了确定性保证）；输入输出是结构化数据的确定性变换（写SQL或代码）；只为「用上 AI」而没有可度量的业务指标信号主动说「没有可度量指标的需求先别做」→ 有产品判断力；答「什么都能用大模型」→ 缺边界感业务方点名要微调（老板看了新闻、竞品在宣传「行业大模型」），你评估下来该 RAG，怎么处理？
期望不正面否决，把选择权带代价交回去：先认同目标再拆手段 → 两天做对照实验，few-shot基线 vs RAG 在同一份 50 条评测集上跑 → 一张表并排效果、周期、成本、「基座升级后还剩多少」，微调那栏诚实填「标注两周、换版归零」 → 混合方案：先上 RAG 见效同时攒数据，三个月后确有写不出规则的部分再补一小块微调 —— 诉求没被否掉，只是被排了序信号硬顶「这个需求不该微调」→ 技术对、沟通零分，通常也推不动；摆得出「两天对照实验」这种低成本证据 → 在组织里真推动过技术决策
评分要点
- 能把需求归成"不知道 / 不会做 / 太贵太慢"三类，而不是背技术对照表
- 知道前置闸门是评测集 + few-shot 基线
- 微调那一支能给出"写不出规则只能给例子"这个判据
- 知道 2026 年格式问题该走结构化输出、推理深度该提 effort 档位
- 能说出至少两个"不该微调"的错误理由
- 知道 RAG 与微调可以叠加，且顺序是先 RAG
- （加分）能提资产寿命这条判据
- （加分）讲自己的项目时先讲排除过程再讲结论
- （加分）能把一个需求拆成三类分别处理，而不是整包给一种方案