美团、阿里二面：nexus-agent-pro 项目深挖与 RAG 链路追问

《面试题目》

美团（二面）

1. 这个项目最难解决的问题是什么？当时具体卡在哪个环节？你尝试过哪些方案，最后采用了什么办法，又是怎么判断问题已经得到改善的？
2. 项目的整体技术方案是怎么确定的？为什么选择自行实现核心流程？有没有评估过 LangChain 这类框架，它们在哪些地方不符合项目需求？
3. 项目中的大模型和向量数据库是怎么选的？最终采用了哪些模型和数据库？选型时主要考虑了哪些因素，这些选择对检索效果、响应速度和成本有什么影响？
4. 文本向量化采用了什么 Embedding 模型？你是怎么比较候选模型的？为什么最终选择这一款？它对中文内容、专业术语和业务问法的适应情况如何？
5. 知识库目前有多大规模？可以从原始文档数量、切分后的片段数量和数据量分别说明。这个规模给存储、检索和更新带来了哪些实际问题？
6. 一份文档从上传到可以被检索，中间会经过哪些处理？系统接受哪些文件格式？不同格式如何解析，解析后的内容又如何进入清洗、切分、向量化和索引流程？
7. 文档进入知识库前，如何判断它是否合格？对内容缺失、重复、过时、表述冲突或解析异常的文档，系统怎么发现和处理？哪些环节需要人工审核？
8. 文档切分的规则是怎么设计的？切分时依据固定长度，还是标题、段落等结构？片段大小和重叠范围怎么确定，怎样避免把一段完整语义拆散？
9. 图片和表格中的信息怎样进入知识库？扫描件、截图、复杂表格分别怎么处理？提取后的内容如何保留与正文的关系，避免检索到信息却丢失上下文？
10. 用户发起一次提问后，系统内部会怎样执行？从接收输入、识别意图、选择处理路径，到调用 Skill 并组织结果，请按实际执行顺序说明。

阿里（二面）

1. 系统如何决定一个请求应该走哪条路径？哪些问题适合直接调用工具或执行确定性查询，哪些问题需要检索知识库？这个边界是怎么划分的？
2. 遇到过系统误判用户意图的情况吗？请举一个具体例子：错误发生在哪一步，为什么会判断错，后来怎样通过路由规则、上下文或追问机制修正？
3. 检索时使用的关键词和专业术语从哪里来？它们由模型自动提取、规则匹配，还是人工维护？自动识别结果在什么情况下需要人工确认？
4. 为什么要同时使用语义检索和 BM25？两种检索方式分别擅长处理什么问题？如果只保留其中一种，哪些类型的提问容易漏检或返回不相关内容？
5. 如果项目采用三路召回，第三路具体补充了什么能力？三条路径各自检索什么内容、解决什么问题？多路结果如何合并，怎样处理重复片段？
6. 召回结果是怎样一步步缩小到最终上下文的？请结合粗过滤、候选集和重排序说明完整过程。如果流程是先保留 Top20，再经 ReRank 选出 Top8，这两个数量是怎么确定的？
7. 不同检索路径的结果如何统一排序？各路得分能否直接比较？初步打分和 ReRank 分别承担什么作用，最终依据什么判断一个片段值得交给大模型？
8. 检索效果不好时，你会怎样定位原因？如何区分文档质量、切分方式、向量表示、查询表达和排序策略的问题？面对数据坍缩、噪声较多或召回不足，分别采取过什么措施？
9. 项目用哪些指标衡量 RAG 的效果？如何分别评价检索是否找到了正确资料，以及生成答案是否准确？这些指标具体怎样指导参数调整和方案选择？
10. 评测集及其参考答案是如何制作的？测试问题来自哪里，标准答案依据什么确定，由谁审核？对于存在多种合理回答，或者知识库中没有答案的问题，如何设置评分标准？
11. 怎样减少模型在回答中编造信息？检索不到依据、资料互相矛盾或证据不完整时，系统会怎样处理？如何让回答中的结论能够追溯到原始文档？
12. 什么情况下会启动多个 Agent 协作？系统依据什么判断任务需要拆分？子 Agent 的职责、输入和输出怎样划分，最终结果由谁汇总和检查？
13. 项目引入 MCP 的原因是什么？它解决了工具接入和调用过程中的哪些具体问题？与直接对接业务接口相比，实际收益体现在哪里？
14. Skill 和 MCP 在项目中分别负责什么？请用一个实际任务说明两者如何配合：哪些内容由 Skill 定义，哪些能力通过 MCP 提供，系统又如何完成调用？

《参考解析》

「为什么不用 LangChain」要答成一条可验证的判断：框架省的是从零到跑通的成本，代价是多了一层不可控的抽象。真正值得说的理由有三类：一是链路里每个环节都要能独立替换与观测——切分策略、召回通道、融合排序、路由规则都会被反复调整，需要逐段保留中间结果和分数，否则答不出「这次改动到底让哪一步变好了」；二是要按业务定制路由与 Skill 编排，框架的默认编排会把定制逻辑挤到框架外面，反而更难维护；三是成本和权限要对齐内部规范（调用次数、token 预算、工具鉴权）。答的时候同时给判断标准：哪些用了现成组件（向量库、Embedding、ReRank 模型），哪些自己写并行，并说明自研部分怎么控制维护成本——模块边界清晰、接口稳定、有回归评测。常见的追问是「如果重来会不会换框架」，稳妥的答法是指出哪些模块不值得自研（解析器、向量库运维），把这些交出去、只自研编排与评测。

Embedding 与向量库选型：结论要能落到自己的评测集上：选型不能只说「社区用得多」。Embedding 的比法是用业务问题构造「问题 → 正确片段」的评测对，算 Recall@k 与 MRR，并且专门造三类难例：专业术语与口语化问法、缩写与全称、同一问题的不同表述。中文与领域术语上，通用模型常常栽在专有名词和缩写上，这时可以考虑领域内继续训练或加一路关键词检索兜底。向量库看四件事：数据量与过滤条件的组合查询能力（能不能带元数据过滤再做向量检索）、更新与删除的代价（版本控制要能下架旧片段）、持久化与备份、运维成本；千万级以下，参数调优带来的收益往往大于换库。大模型按任务分层——路由、抽取、改写用小模型，最终生成用强模型，同时看上下文长度、工具调用稳定性和首 token 延迟；换模型必须用同一套评测集回归，否则「换完感觉更好」在面试官那里是不成立的。

文档入库全链路：解析、清洗、切分、索引每一环都要有明确规则：解析按格式分流，PDF 优先取文本层、扫描件走 OCR，Word 保留标题层级，表格转成结构化文本并保留表头，图片走多模态描述或「图注 + 所属章节」回填，避免只留一句「见下图」。清洗处理页眉页脚、水印、断行粘连、全半角与空白。切分以结构优先：先按标题层级切，超长段再按长度兜底并保留 10%~20% 重叠；表格、代码块、图片说明不跨块拆；每个片段带上标题路径作为上下文前缀，这样检索命中的是「某个小节的某一段」而不是一段孤立文字。索引时把 doc_id、文档版本、chunk_index、内容哈希、权限标签一起写进去，哈希用于增量更新与去重，版本用于下架旧内容——只重嵌入内容变了的片段，能省下大量算力。合格性判断交给一组显式规则加人工兜底：正文过短、解析成功率低、与已有文档近似重复（MinHash 或 SimHash）、超出有效期、同主题版本互相冲突，这几类分别标记；人工审核放在「高影响且低置信」的交叉点，比如首次入库的政策与价目类文档、解析置信度低、以及被反馈答错的文档。

混合检索与融合排序：分数不可比就用排名融合：语义检索擅长同义改写和自然语言提问，BM25 擅长型号、缩写、专有名词这类必须精确匹配的串。只留语义会漏掉精确串，只留 BM25 会在口语化问法上全军覆没。三路召回里第三路常见的是元数据或结构化检索（按产品线、时间、文档类型过滤，或实体/标题通道），它补的是「候选池里根本没有正确片段」这一类失败。融合方式上，RRF 只用各路排名、不用原始分数，天然绕开量纲不可比的问题；加权求和则必须先把分数归一化（min-max 或 z-score），并定期用评测集校准权重。ReRank 用交叉编码器对「问题-片段」逐对打分，比向量点积准但贵得多，所以先粗排取 Top20~Top50、再精排到 Top8。这两个数字不是拍出来的：候选数由「正确片段在粗排 TopN 里的命中率」定，最终条数由「再多给几条会不会引入互相矛盾的证据」和上下文预算定；延迟也是约束，ReRank 的条数与模型规模直接决定响应时间。多路合并时按内容哈希或近似指纹去重，保留得分最高的那份，同时保留来源文档与片段位置，供答案引用。

评测与幻觉治理：把「检索错」和「生成错」分开：检索与生成要分开评。检索看是否找到了正确资料——Recall@k、MRR、命中率，背后需要人工标注的「问题 → 正确片段」集合；生成看忠实度（结论是否只依据给定上下文）、答案相关性、完整性，机器评审加少量人工抽检校准。评测集来源要写清：真实用户问题脱敏回流、业务方整理的 FAQ、线上坏例。无答案的问题必须单列成「应该拒答」的样本，评分标准是「正确拒答」而不是「答出了什么」，否则会鼓励模型编造。定位问题时先看分水岭：正确片段在不在最终上下文里——不在就是检索侧（文档质量、切分、向量表示、查询改写、排序），在但答错就是生成侧（指令遵循、上下文过长导致忽略、模型自身知识干扰）。幻觉治理按四层做：检索不到依据就明确说不知道并给出可选项；答案里的结论必须能追溯到具体文档与片段（引用编号或链接）；证据互相矛盾时不做单边结论，而是并列冲突点并提示需要人工确认；生成后加一层校验，比如数字与单位是否与原文一致、是否出现上下文里没有的实体。

路由与多 Agent 拆分：先问「需不需要拆」：请求路由的边界可以按「答案是否需要事实检索」来划：确定性查询（订单状态、库存、配置项）走工具或 SQL，知识型问题走检索，混合型先取事实再用检索补背景。路由实现一般是规则 + 小模型分类，并保留置信度兜底——置信度低时先追问澄清，而不是赌一条路径。误判的典型案例是把「怎么配置 A」判成闲聊，或把闲聊判成检索；修正手段是补规则、把最近一轮对话状态纳入判断、以及给用户一个显式的「换一种理解」入口。多 Agent 只在任务确实需要多步且子任务边界清晰时启用：有独立上下文、可并行、可分别评估，才值得拆；单个检索加生成能解决的不要拆，拆完通信成本和一致性风险都会上来。子 Agent 必须约定输入输出契约，汇总方负责合并与校验（去重、冲突检测、引用核对），面试里讲清「谁汇总、怎么判成败」比讲有几个 Agent 更重要。

MCP 与 Skill：一个管能调用什么，一个管该怎么做：MCP 是模型与外部工具、数据源之间的协议层，规定服务端如何暴露工具与资源、客户端如何发现与调用。项目引入它的动机是把工具接入标准化、可插拔：新增数据源不用改编排代码，权限与审计也能收在接入层，而不是散落到每个业务接口的直连里。Skill 是任务级的知识与流程封装，把某类工作的方法、步骤、约束、示例组织成按需加载的内容，不占用常驻上下文。两者配合的典型说法是：Skill 里写「先取哪类数据、按什么顺序校验、什么情况下要追问、结论怎么组织」，MCP 提供「查订单」「查库存」「检索知识库」这些具体能力，编排层按 Skill 的流程调用 MCP 工具。一句能背下来的边界：MCP 管连接与能力边界，Skill 管策略与经验；追问「收益体现在哪」时，用「新增一个工具从改 N 处代码变成注册一次、权限校验只做一层」这种可核对的对比回答。