携程大模型算法一面：多 Agent 协同、RAG 全链路与意图路由

《面试题目》

1. 简单做一下自我介绍。
2. 说说多个智能 Agent 之间是怎么协同工作的？
3. 梳理 RAG 完整流程，并结合项目实践介绍。
4. 区分 context engineering 和 prompt engineering 的不同之处。
5. 解释召回率含义，同时说明它的计算方式。
6. 在召回优化手段里，哪一类优化带来的提升最明显？
7. 有哪些方法可以评估 Agent 输出内容的好坏？
8. 优质样例和失败样例是否会回流补充知识库？
9. Agent 方案主要缩减了哪些流程的时间开销？
10. 讲讲基于用户意图的路由模块是怎么运行的。
11. 意图路由的效果如何，如果识别错误该怎么处理？
12. 说明从用户自然输入到调用后端接口的完整链路。

《参考解析》

多 Agent 协同的三种形态：落地时基本是三类。一是编排式，一个主 Agent 负责规划，把子任务分给专职子 Agent，子 Agent 之间不直接通信，结果回主 Agent 汇总——好处是链路可观测、出错能定位到某个子任务，代价是主 Agent 上下文会膨胀。二是流水线式，抽取 → 校验 → 生成 串成固定顺序，节点之间只传结构化对象，适合步骤稳定的业务。三是辩论/投票式，多个 Agent 独立产出再交叉评审，用在答案质量比延迟更重要的场景。真实系统里通常是「编排 + 局部流水线」的混合：入口一个路由 Agent，按领域分派，领域内固定几步流水线。协同的关键不是架构图，而是契约——子 Agent 的输入输出要有 schema，必填字段缺了直接拒收，不然错误会一路漂到最后一层。

RAG 的完整流程：离线侧是文档接入（解析 PDF/HTML/表格，处理乱码与分页）、清洗去噪、按语义或结构切块、embedding、写入向量库并同步一份稀疏索引（BM25）。在线侧是 query 改写（补全指代、拆多跳）、召回（向量 + 关键词混合，多路各取 topK）、融合（RRF 或加权）、重排（cross-encoder 精排到 5～10 条）、拼上下文（带出处、按相关度裁剪）、生成（约束只依据给定材料、要求引用）、后处理（引用校验、敏感过滤）。工程上真正决定效果的往往是切块策略和 query 改写，模型换一代提升 5 个点，切块换一版能提升 20 个点。

context engineering 与 prompt engineering 的区别：prompt engineering 关心的是「这句话怎么写」——措辞、few-shot 示例、输出格式。context engineering 关心的是「模型这一刻看到什么」——哪些材料进上下文、按什么顺序排、多长的历史保留、工具描述怎么裁剪、什么信息用 id 引用而不是全文塞进去。前者是文本层面的优化，后者是信息架构层面的取舍：上下文窗口不是越大越好，无关内容会稀释注意力、拉高成本、放大幻觉。判断标准也很实际——prompt 改动影响的是同一批输入的表现，context 改动影响的是「该给模型什么输入」这件事本身。

召回率与它的计算方式：召回率 = 命中的相关文档数 / 全部相关文档数。工程上分母往往拿不到（不知道库里到底有多少相关文档），所以常用两种替代口径：一是构造标注集，对每个 query 人工标出全部相关 chunk，按上式算 Recall@K；二是在无法全标时用「召回集里相关条数 / 召回的 K 条」看精确率，再配合人工抽检估覆盖率。要注意 Recall@K 会随 K 单调上升，比较两套召回方案必须在同一个 K 下比，否则没有意义。

召回优化里提升最明显的一类：按实测经验，切块与预处理通常收益最大——切块过大导致语义被稀释、过小导致上下文断裂，加上表格/代码这类结构化内容的专门处理，往往比换 embedding 模型提升更明显。其次是混合检索（稠密 + 稀疏 + 多路召回融合），能补上纯向量对专有名词、型号、代码标识符不敏感的短板。再往后才是重排和 query 改写，最后才是 embedding 模型换代。这个顺序也和成本相关：越靠前的改动越不花钱。

Agent 输出的评估方法：分三层。自动指标：有标准答案时用 exact match / F1 / 相似度；开放式回答用 LLM-as-judge 按维度打分（准确性、完整性、引用一致性），但裁判模型要固定版本、要有校准集，否则分数漂移。人工评估：抽检打分 + 双人标注算一致性（Cohen’s kappa），用来看自动指标是否可信。线上指标：采纳率、追问率、人工转接率、任务完成率。评测集要从真实流量里采样构造，覆盖长尾问法和边界情况，而不是自己拍几个 demo 问题——自己出的题基本等于开卷。

样例回流：会回流，但要分层。优质样例进 few-shot 池或作为回归测试用例；失败样例要归因——是召回没捞到、是材料本身错、是模型没按指令走，还是业务规则缺失。只有「材料缺失」这一类才应该补进知识库；「模型没按指令」应该改 prompt 或加校验，不该污染知识库。回流的坑是不设准入就会自我强化：模型的输出被当成正确答案再喂回去，错误会越滚越大。

意图路由的实现与兜底：典型做法是「规则 + 小模型分类 + 置信度」。先做正则/关键词硬规则兜住高频明确意图（成本最低、可解释），再用分类模型或 LLM 做细分类，输出意图 + 置信度。置信度低于阈值就不强行路由——走澄清追问，或者落到通用 Agent 让它先收集信息。识别错误的三层兜底：可回退（子 Agent 发现自己处理不了，返回 unsupported 让路由重判）、可纠错（用户纠正后把这条样本进评测集和训练集）、可观测（路由决策全部打点，按意图统计后续的异常率，异常率高的意图回头查规则）。不要指望路由 100% 准，要让错了也能低成本修正。