携程 Agent 开发一面：LangGraph 项目全链路拷打

《面试题目》

1. 请做一下自我介绍。
2. 介绍一下简历里的项目（LangGraph、RAG、知识图谱）。
3. 项目里的核心链路，输入、过程、输出分别是怎么样的？
4. 为什么选用 LangGraph？里面主要的状态节点是怎么设计的？有没有设置过 checkpoint，作用是什么？
5. 知识图谱主要是干什么的、怎么来的？和单纯的 RAG 相比有什么效果？
6. 你这个系统有没有和其他知识库 + RAG 系统比较过？
7. 你这个项目里有自己训练的模型，是自己训练的吗？
8. 你写了测试集，测试集是怎么来的？有什么效果？后续测试集有没有做回归调优？
9. 你这个业务场景下模型延迟会不会很高？你怎么看待回答延迟？
10. 你的项目业务背景不是互联网相关的，为什么选这个岗位？

《参考解析》

为什么选 LangGraph、状态节点怎么设计：这类问题的评分点不在「LangGraph 好用」，而在你能不能把「为什么不是 LangChain 的 Chain / 不是手写状态机」说清楚。LangGraph 的定位是有环的、带持久化状态的执行图：节点是函数，边是控制流，条件是路由，state 是唯一的事实来源。选它的典型理由是链路里存在「判断 → 执行 → 再判断」的循环（工具调用失败要重试、检索不够要改写 query 再检索）、需要人工介入断点、需要失败后从中间恢复，这些都是线性 Chain 表达不了的。

状态设计上要讲三件事：①state 里放什么——用户输入与对话历史、检索到的证据、当前计划/待办、工具调用结果、错误与重试计数、最终答案，共同的判据是「跨节点要共享的才放，节点内部的临时变量不放」；②节点返回的是增量而不是整份 state，默认语义是字段级覆盖，需要追加的字段必须显式声明 reducer（如 Annotated[list, add_messages]），否则并发分支或多次写入会互相盖掉、消息列表越跑越短；③状态要可序列化，因为 checkpointer 要把它落盘，塞了连接、模型客户端这类对象会在恢复时直接炸。

checkpoint 的作用：checkpointer 会在每个 super-step 结束后把 state 快照写进后端存储（内存 / SQLite / Postgres），并按 thread_id 归组，一个 thread 就是一条可回放的会话。它带来的能力有四层：断点续跑（进程挂了用同一个 thread_id 重新 invoke 就能接着走）、人工介入（interrupt() 停在某个节点前，人审完再用 Command(resume=...) 继续）、失败重放与时间旅行调试（回到任意历史快照改一下 state 再往下跑）、以及多轮会话的天然记忆。面试官爱追问的坑：恢复时的非确定性——节点里有 time()、随机数、外部写操作（发邮件、扣款）时，重放会重复执行，所以副作用必须做成幂等或用幂等键；另外 checkpoint 表会随步数膨胀，生产上要配 TTL 清理和单独的库，别和业务库挤在一起。

知识图谱相对纯 RAG 的增益：向量 RAG 擅长「语义相近的一段文本」，短板是多跳和聚合——问「A 公司的子公司里哪些产品用到了 B 技术」这种要跨文档连线的 query，top-k 切片里往往凑不齐证据链，而且切片丢了实体之间的关系。知识图谱把「实体—关系—实体」显式存下来，检索时先做实体链接，再沿关系做 1~2 跳扩展，把相关子图连同原文片段一起喂给模型，回答的可解释性和可核查性都更好（能给出证据路径）。代价也很实在：图谱要靠抽取构建（LLM 抽取 + 人工校对），schema 一旦定死，新关系类型要改 schema 和重跑；覆盖率永远不完整，所以工程上通常是混合检索——向量/BM25 负责召回文本证据，图谱负责补关系和做约束，最后统一重排，而不是拿图谱替换 RAG。被问「有没有和其他知识库 + RAG 系统比较过」时，要能给出对比维度：召回率、答案正确率、多跳问题的通过率、构建与维护成本、增量更新的代价，说清楚在什么类型的 query 上图谱赢、什么类型上反而更慢更差。

测试集怎么来、怎么回归：凭空造几十条「标准问答」没有说服力，靠谱的来源是业务侧的真实问题日志 + 客服/业务同学的高频提问，分层抽样后人工标注「标准答案 + 必含要点 + 可接受的证据片段」。规模不一定大，几十到两三百条就够跑出趋势，关键是分层：单跳事实、多跳推理、需要拒答的越界问题、时效性问题各占一档，否则平均分会被简单题拉高、看不出回归。指标要分层看：检索侧 recall@k / MRR，生成侧要点命中率与事实一致性（LLM 打分 + 人工抽检校准），再加一个拒答准确率。回归的做法是把它固化成 CI 里的一键评测，改 prompt、换模型、调 chunk 参数都跑一遍并在 PR 里贴 diff，重点盯「哪些 case 从对变错」而不是只看总分。被问到「后续有没有回归调优」时，有就说清触发条件和最近一次结果，没有就老实说没有并把改进方案讲出来，比编一个数字安全得多。

回答延迟怎么看：先拆解再表态。延迟由几段构成：检索（向量库查询 + rerank）、模型首 token 时间、生成总时长、以及 Agent 场景下多出来的「多次 LLM 往返」。优化优先级一般是：能并行的并行（多路召回并行、检索与意图识别并行）、能缓存的缓存（embedding、热问题答案、图谱子图）、把 rerank 从「全量重排」收到 top-50、小模型做路由和改写、大模型只做最终生成，再往前端走就是流式输出——把用户感知的等待从「总时长」压到「首 token 时间」。业务上要不要为了准确率牺牲延迟，取决于场景：同步交互式的问答首 token 超过两三秒用户就会觉得卡，宁可先给一个带引用的初步答案再补充；离线批处理、报告生成这类场景则优先准确率。最忌讳的是两手一摊说「大模型就是慢」，面试官想听的是你量化过每一段耗时、知道瓶颈在哪一环。