RAG 专题

Q1 什么情况下用 RAG，什么情况下用微调？

考察的是选型判断，而不是概念背诵。要点：

• 知识会变 → RAG；行为/风格/格式要变 → 微调。这条是第一刀。
• 两者不是互斥：常见组合是”微调对齐输出格式 + RAG 提供事实”。
• 成本口径要能说出来：RAG 的边际成本在检索与上下文长度；微调的边际成本在标注数据与重训周期。
• 答”RAG 更便宜所以用 RAG”是减分项——长上下文下 RAG 的 token 成本并不一定更低。

追问：如果知识既会变、又要改行为怎么办？（看是否想到”微调让模型学会怎么用检索结果”）

Q2 文档分块策略怎么定？

能答出”按固定长度切”只是入门。有区分度的回答会提到：

• 分块大小与问题的粒度匹配，而不是与文档结构匹配。
• 保留父子块（小块用于召回，大块用于生成），兼顾召回精度与上下文完整性。
• 表格、代码块要单独处理——按 token 硬切会把表格切碎，检索出来的是无意义的半张表。
• 重叠（overlap）的作用是防止答案落在切口上，但重叠过大会让同一内容占据多个召回位。

追问：markdown 标题层级在分块里起什么作用？（考察是否理解”用结构信息做元数据”）

Q3 为什么召回的内容明明包含答案，模型还是答错？

这是最有区分度的一题，因为它测试的是分层排查能力，不是知识量。可以按这个顺序排查：

加分项：主动提出”先把召回的原文打印出来肉眼确认”，而不是直接调 prompt。

Q4 混合检索（向量 + 关键词）的权重怎么定？

• 先问清楚：这块知识里有没有大量专有名词、型号、错误码。有 → 关键词侧权重必须够，纯向量会把它们糊掉。
• 融合方式通常两种：RRF（倒数排名融合）或加权分数。RRF 的优势是不用归一化分数，对量纲不一致更稳。
• 权重不该手拍。可用的做法是准备一批”有标准答案位置”的问题集，扫参数看命中率。
• 反问面试官业务分布，是加分项——权重本来就该由数据分布决定。

Q5 重排（Rerank）放在哪一步？

• 位置：粗排召回之后、拼上下文之前。放在召回前没有意义（候选还没产生）。
• 代价：重排模型通常是交叉编码器，成本远高于向量检索，所以只能对 top-N 小集合做。
• 常见错误：先按业务条件过滤再重排。如果过滤后的候选本身就少，重排会把本来该召回的内容挤掉。
• 判断是否需要重排的标准：召回的 top-k 里有正确答案，但排名不稳定 → 该上重排；top-k 里压根没有 → 上重排无用，问题在召回。

Q6 怎么评估一个 RAG 系统？

要能把指标拆到阶段上，而不是只答”看准确率”：

• 检索阶段：召回率、命中率（目标块是否在 top-k）——这一层可以用构造好的问答对自动算。
• 生成阶段：忠实度（是否只用了给定材料）、答案相关性。
• 端到端：人工评分 + 自动指标混合。纯自动指标容易被”答得流畅但用错来源”骗过。
• 回归：固定一批用例，改动前后跑对比，否则无法判断”感觉变好了”是不是错觉。

追问：没有标注数据怎么做评估？（考察是否想到用 LLM 生成候选问题再人工筛）

Q7 长上下文已经这么便宜了，为什么还要 RAG？

有区分度的答法不是站队，而是给出判据：

• 上下文窗口能装下 ≠ 装得进去就有效。中间位置的信息容易被忽略，检索的作用是把相关内容放到显眼位置。
• 成本随长度线性上涨，而检索的成本与库大小弱相关。
• 权限隔离要求：多用户系统里不能把无关文档塞进同一个上下文。
• 但确实有一类场景该放弃 RAG：知识库很小（几页）、且变化不频繁——直接全量塞进系统提示词更简单可靠。

Q8 上下文工程里，检索结果怎么排布？

• 有区分度的答案会提到：把最相关的放在开头或结尾，避免中间位置衰减。
• 每段材料带来源标识（文件名 / 章节），方便模型引用，也方便你事后核查。
• 明确告诉模型”材料可能不完整”，这比假装材料完备更能抑制编造。
• 当材料之间冲突时，给出优先级规则（如按更新时间），否则模型会随机选一个。

附：一页纸的排查流程

# 最小可复现：先把 top-k 召回原文打印出来肉眼确认
import textwrap

hits = index.search(query, k=8)
for i, h in enumerate(hits, 1):
    print(f"[{i}] {h.doc_id}  score={h.score:.3f}")
    print(textwrap.shorten(h.text, width=200))

本专题持续补充。新增题目请用 npm run new 新建文档，或直接在此文档追加并跑 npm run validate。