字节 Agent 开发后端日常实习一面：RAG 检索与评测深挖

《面试题目》

1. 先整体介绍项目，为什么选 LangGraph？工作流是怎样的？
2. 项目中的评测数据集是怎么构造的？
3. 数据主要由 AI 生成，如何保证数据集质量和覆盖度？
4. 如何保证 Agent 能在这些数据上更好地回答问题？
5. 用户问题比较口语化、有错别字或意图不明确时，如何处理？
6. 知识库如何构建？Markdown、TXT、PDF 分别怎么切块？
7. 为什么同时使用 BM25 和向量检索？两者各自适合什么问题？
8. 两路召回结果如何融合？
9. RRF 的原理是什么？为什么不直接融合两种检索的原始分数？
10. 粗排后为什么还要使用 Cross-Encoder 重排？
11. Cross-Encoder 为什么会比向量相似度更准确？
12. 直接使用预训练 Cross-Encoder，训练目标和你的业务场景并不一致，如何保证效果？
13. 简历里写了多种检索方式，分别是什么，为什么需要这么多种？
14. 这个项目和上一个项目除了技术栈不同，还有什么本质区别？
15. 做这个项目最大的收获是什么？
16. 项目里遇到的最大困难是什么，怎么解决？
17. 评测体系里有很多指标，哪个指标最能衡量系统是否达成目标？
18. 手撕算法：一道偏简单的贪心题。

《参考解析》

RRF 以及为什么不直接融合原始分数：RRF（Reciprocal Rank Fusion）对每一路召回结果只取排名，按 score(d) = Σ 1 / (k + rank_i(d)) 累加，通常取 k = 60，最后按总分重排。它之所以好用，是因为不同检索器的分数没有可比性：BM25 是词频与逆文档频率算出的无界正数，受文档长度和词项分布影响；向量检索给的是余弦相似度或内积，落在固定区间且分布完全不同。直接加权求和必须先做归一化（min-max、z-score 或概率化），而归一化对每路的分数分布极其敏感，换一批 query 分布一变，权重就得重调。RRF 只依赖排名，天然免归一化、对异常分数稳健、两路权重也近似对称，实现只要几行。代价是丢失了分数的幅度信息——「第一名远超第二名」和「险胜」在 RRF 里等价，所以更精细的做法是 RRF 打底、再叠一路学习到的融合模型（把各路分数、排名、文档特征一起喂给 LTR）。面试里补一句「k 的作用是压制头部差异、让中段排名也有贡献」会很加分。

Cross-Encoder 为什么会更准，以及预训练模型与业务不一致怎么办：向量检索用的双塔结构里，query 和文档各自独立编码，只在最后做一次向量比较，交互发生在压缩之后的单个向量上，信息损失不可避免；Cross-Encoder 把 [query, document] 拼成一条序列送进模型，从第一层开始就做 token 级交叉注意力，能捕捉否定、限定、数字与条件的细微差别，所以排序质量显著更高。代价是无法预计算：每个 query 都要和候选文档逐一前向，复杂度与候选数成正比，因此只能放在召回之后的精排段，且要限制候选规模（几十到一两百条）。预训练模型与业务不一致是真实问题，常规解法有四条：一是领域微调，用业务里的 query-正例-难负例三元组建训练集，损失常用 pairwise ranking 或 MarginMSE，难负例从现有检索器的 Top-K 里挖；二是蒸馏，把 Cross-Encoder 的排序结果蒸馏回双塔，让召回阶段也变准；三是提示式使用，不微调时把任务写成明确的判定模板（「这段文档能否回答该问题」）并做分数校准；四是兜底评估，先在业务 golden set 上看它相比现有精排的增益，涨了再上，没涨就说明瓶颈在召回或切块，不在重排。面试官追问「怎么证明有效」时，要给出离线指标（NDCG@10、MRR、Recall@k）与线上指标（答案采纳率、点踩率）的对照。

BM25 与向量检索的分工：BM25 属于稀疏检索，靠精确的词项匹配加 TF-IDF 式加权和文档长度归一化，对术语、型号、代码符号、人名、报错码这类低频但关键的词极其可靠，而且可解释、能给出命中了哪些词；它的短板是同义词与改写——用户问「怎么让模型记住之前聊过的东西」而文档里写的是「多轮对话的上下文管理」，词项对不上就召不回。向量检索是稠密语义匹配，把 query 和文档映射到同一空间比距离，擅长处理口语化、同义改写、跨语言，但会把具体数字和稀有实体模糊掉（「iPhone 15 和 iPhone 16 的区别」可能召回 14 的内容），且对领域外的 embedding 模型效果不稳。所以混合召回是互补而不是叠加噪音：稀疏保精确、稠密保语义，再让融合层决定顺序。工程上还可以加一路「结构化过滤」（按时间、权限、文档类型先筛）和一路「精确串匹配」，命中关键实体时直接提权。评估时最好把两路分开看召回率，确认它们确实覆盖了不同的失败集合，否则混合只是白花算力。

AI 合成评测集的构造与质量控制：AI 生成数据的最大风险是与提示词同源、分布失真——用同一个模型生成的问答往往比真实用户提问更规整、更书面，模型在它上面表现虚高，上线就被真实流量打脸。可控的做法分四层：一是来源分层，合成数据之外必须混入真实来源（脱敏线上日志、客服工单、用户反馈、人工撰写的 golden set），并规定真实数据的最低占比；二是生成时约束，从真实语料反向出题（基于 chunk 生成问题，保证有答案可依），同时显式要求覆盖不同意图、难度、长度与口语化程度，并让生成模型标注它依据的原文片段，便于后续判定忠实度；三是自动过滤，用规则去重（近重复、模板化句式）、用另一个模型做交叉校验（答案能否由给定文档支持、是否有幻觉、问题是否自洽），把不合格的丢掉；四是人工抽检与评测护栏，按维度分层抽样人工打分，统计合成集与人工集上同一系统的表现差距，差距大就说明数据集不可信。最后不要把所有指标压成一个平均分——按意图类别、难度、问题长度分桶看，平均值往往掩盖了最差的那一桶。

评测体系里哪个指标最能衡量目标：要先回到「系统要达成什么」。如果是问答型系统，单一最有代表性的指标是端到端的任务成功率（答案正确且被引用支持、用户不需追问），它直接对齐业务目标，其他指标都是它的分解与诊断工具；在线下则通常用「忠实度 + 正确性」的人工或模型评判作为代理。如果是检索型，核心是 Recall@k（能召回才有后续），用 NDCG 看排序质量。指标选择的两个原则：一是分层，端到端指标看结果，过程指标（召回率、重排增益、幻觉率、拒答率、P95 延迟、单次成本）用来定位问题出在哪一环；二是对齐线上，离线涨了线上不涨，多半是指标选错了或者评测集分布不对。面试里如果只答「看准确率」，会被追问准确率怎么算、谁来判断对错——把判定口径（人工标注、LLM-as-judge 加人工抽检校准）讲清楚才算答完。