携程大模型算法一面 12 问：Agent 协同、RAG 流程与评估体系

《面试题目》

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

《参考解析》

协同机制要讲清「谁决定下一步」：面试官问多 Agent 协同，本质在问控制权在哪一层。如果每个子 Agent 都能自主决定调用谁，系统会变成不可预测的网状结构，链路一长就没法排查。所以协同要讲三件事：调度权集中在哪里（通常是一个 planner，子 Agent 只有执行权）、结果怎么合并（结构化输出而非自然语言转述，减少信息损耗）、失败怎么传播（子 Agent 失败是抛出还是返回部分结果，主 Agent 拿到后重试还是降级）。能把这三点说清，比画出三层架构图更有说服力。

RAG 流程中容易漏掉的环节：大多数人都能说出「切块—向量化—检索—生成」，但真正的工程细节在两头。前面是解析与切块：PDF 双栏、表格跨页、页眉页脚噪声，处理不好后面再优化检索也没用。后面是生成后的校验：回答里的每个论断能不能对回原文，引用编号是否真实存在。中间还有一块常被忽略的是索引更新——文档改了怎么增量重建、旧向量怎么失效，很多团队上线后才发现删掉的文档还在被召回。

context engineering 解决什么：可以把上下文当成一个预算池。窗口是池子容量，token 花在系统提示、历史对话、检索材料、工具描述、输出上。prompt engineering 优化的是「某一段怎么写更省更准」；context engineering 优化的是「这个池子怎么分配」——比如历史该摘要还是原样保留、工具描述要不要按当前意图裁剪、长文档用 id 引用还是塞全文。同一条 prompt，上下文结构不同，效果能差出量级。

召回率怎么落到工程上：公式是「召回到的相关条目 / 全部相关条目」，难点永远在分母。可操作的做法是建一个 query→相关 chunk 的标注集（每个 query 标全库范围内的相关块，量不用大，几百条就够看出趋势），然后看 Recall@K 曲线选 K：K 太小漏答，K 太大重排压力大、噪声进上下文。另一个常用口径是 MRR 或 nDCG，它们对「相关条目排在第几」更敏感，适合比较排序质量。

优化优先级与成本：性价比排序通常是切块策略 > 混合检索 > query 改写 > 重排 > 换 embedding / 换生成模型。原因是越往前越贴近「信息有没有被正确表示」，越往后越只是「在已有候选里挑」。而换模型成本最高、收益最不确定，还常常掩盖掉数据侧的真问题。

评估 Agent 输出：不要只报一个总分。拆成事实性（有没有编造）、完整性（该说的有没有说）、指令遵循（格式、长度、语气是否符合要求）、可用性（用户能不能直接拿去用）几个维度分别打分，再合成。裁判用 LLM 时必须固定模型版本、给出评分细则、并且用人工标注过的样本校准一遍，否则换个模型分数就跳。

缩短了哪些时间开销：回答这题要落到具体岗位的真实流程上。以客服/运营类场景为例，原来一次处理要经历「查资料—问同事—写回复—复核」，Agent 把查资料和初稿两步自动化，人工从「从零写」变成「审校改」，单次处理时间从十几分钟压到两三分钟；复核环节反而更重要了，因为错误更隐蔽。

意图路由与误判兜底：路由的输出应该是「意图 + 置信度 + 依据」，不是单一标签。低于阈值就走澄清或通用通道；高置信度也要保留「用户否决」的入口，让用户一句话就能改道。误判的定位靠打点：把路由结果和后续行为（是否追问、是否转人工、是否重问）关联起来，某个意图的追问率异常高，说明它和相邻意图的边界没划清。