怎么考「什么问题该微调、什么问题该 RAG、什么问题写好 prompt 就够了？」
谁在问：各轮必问；一面考概念边界，二三面考真实排除过程；产品向面试官也会问
开场怎么问
RAG 和微调你怎么选？分别适合什么场景？
换个问法
- 给你一个新需求，你怎么判断该用哪种方案？
- 什么情况下你会说'这个 prompt 写好就行了，不用上别的'？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
客户问"我们公司年假是几天"，模型答错了。你怎么办？
- 期望
- 典型的"不知道"——知识问题，走 RAG。不该微调：政策会改，改一次重训一次；而且答案需要溯源到制度原文，微调给不出出处。补充：如果制度文档本身写得含糊，那是数据源问题，先修文档。
- 信号
- 答"把制度写进微调数据"——本章头号错误答案。能主动提"需要溯源"这个额外理由——做过 toB 场景。
那如果是"回答的语气不像我们品牌"呢？
- 期望
- 先判断规则写不写得出来。"多用短句、不用感叹号、不说'亲'"——写得出，那就写进 system prompt，不要训。 只有当你怎么写都描述不清、只能拿出三百份范文说"照这个感觉"时，才是微调的场景。判断方法很实操：让最懂品牌的人试着把规则写成 200 字，写得出就不训。
- 信号
- 这一层是本题最锋利的一刀。直接答"语气问题该微调"的人，用的是 2023 年的映射表。 能给出"先让人试着把规则写出来"这个可执行判据的，是真做过取舍。
RAG 和微调能一起用吗？先后顺序是什么？
- 期望
- 能，而且常见：RAG 供知识，微调调"怎么用这些知识说话"（引用格式、拒答口径、结论结构）。顺序是先 RAG 后微调——先把知识供给稳定下来，否则你会拿着一个检索不稳的系统去微调，把检索的噪声一起学进权重。另外微调数据里应当包含检索结果的形态，否则线上分布和训练分布对不上。
- 信号
- 能说出"微调数据要包含检索结果形态"——真把两者串起来做过。只答"可以一起用"——泛泛。
什么时候你会说"这个需求根本不该用大模型做"？
- 期望
- 规则完全确定且枚举得完（用正则/规则引擎，又快又准又可审计）；要求 100% 准确且无法容忍任何错误（大模型给不了确定性保证）；输入输出是结构化数据的确定性变换（写 SQL 或代码）；只是为了"用上 AI"而没有可度量的业务指标。
- 信号
- 能主动说"没有可度量指标的需求先别做"——有产品判断力。答不上来或说"什么都能用大模型"——缺乏边界感。
业务方点名要微调——老板看了新闻，或者竞品在宣传自己的"行业大模型"。你评估下来该 RAG。这时候你怎么处理？
- 期望
- 不要正面否决，要把选择权交回去但带上代价。 先认同目标（"要让模型更懂我们这行"这个目标是对的），再拆手段。
- 拿数据说话，而不是拿观点说话：花两天做一个对照实验——few-shot 基线 vs RAG 方案，在同一份 50 条评测集上跑。用一张表把两条路的效果、周期、成本、以及"基座升级后还剩多少"并排放出来。 微调那一栏诚实地填上"数据标注两周、基座换版归零"。
- 给一个混合方案而不是二选一：先上 RAG 快速见效，同时攒微调需要的数据；等三个月后如果确实有 RAG 解决不了的风格问题，再补一小块微调。这样业务方的诉求没有被否掉，只是被排了序。
- 明确保留一条真实的微调入口：如果评估中确实发现有"写不出规则只能给例子"的部分，就诚实地说这部分该微调——不要为了推 RAG 把它一起否掉，那会损失可信度。
- 管理预期的话术：竞品宣传的"行业大模型"多数是 RAG + prompt 包装，这一点可以说，但要以"我们也可以这样对外表述"的方式说，而不是拆台。
- 信号
- 直接顺从业务方做微调——没有技术判断，也没有为公司省成本。
- 直接硬顶"这个需求不该微调"——技术上对，沟通上是零分，通常也推不动。
- 能把"两天对照实验"这种低成本证据摆出来——是真在组织里推动过技术决策的人。
- 能主动保留一条真实的微调入口、而不是一刀切否掉——判断力和可信度都在线。
- 能点出"竞品的行业大模型多半是包装"但用建设性方式说——成熟度高。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 能把需求归成"不知道 / 不会做 / 太贵太慢"三类，而不是背技术对照表
- 知道前置闸门是评测集 + few-shot 基线
- 微调那一支能给出"写不出规则只能给例子"这个判据
- 知道 2026 年格式问题该走结构化输出、推理深度该提 effort 档位
- 能说出至少两个"不该微调"的错误理由
- 知道 RAG 与微调可以叠加，且顺序是先 RAG
- （加分）能提资产寿命这条判据
- （加分）讲自己的项目时先讲排除过程再讲结论
- （加分）能把一个需求拆成三类分别处理，而不是整包给一种方案
参考答案与考察意图面试中途别看这一段
考察意图
这是本章最高频、也最能看出层级差异的一道题。三个层级：
- 背表格：知道"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、几小时训完。把一个需求拆成三类而不是整包丢给一种方案，是这道题真正想考的能力。