【寒武纪】【Agent 开发】【暑期实习二面】面经（八股+大模型项目+手撕）

寒武纪 Agent 开发 暑期实习二面面经

背景：海外一年制硕士，此前一段大模型应用相关项目经历，无全职经验。

题目摘要

项目深挖

追问 1：你提到用 RAG 解决大模型幻觉问题，具体怎么做的？检索失败时如何兜底？

参考回答方向：先说明 RAG 整体链路——文档切分（chunk size 选取策略）、向量化（Embedding 模型选型）、召回（Top-K 选取）、重排（Rerank）。检索失败兜底分三层：第一层是相似度阈值判断，低于阈值直接返回"知识库中未找到相关信息"；第二层是意图识别，判断用户问题是否属于闲聊或知识库外问题，走 LLM 直接回答；第三层是反问澄清，当召回结果分散度太高时，让 LLM 追问用户以缩小范围。面试官实际考察的是你是否考虑过 RAG 的失败场景，而非只讲理想流程。

追问 2：Function Calling 的调用参数经常出现幻觉或格式错误，你怎么处理？

参考回答方向：强调三层防护。第一层是 Schema 约束——把参数定义写得足够严格，用 enum、format 等字段限制取值；第二层是校验兜底——LLM 返回的 JSON 先过一层校验器（如 Pydantic），不合法则构造错误信息重新喂给 LLM 让其修正，最多重试 2 次；第三层是默认值策略——对非关键参数设置默认值，避免因某个参数解析失败导致整个调用废弃。再补充一点：如果 Function 涉及外部 API 调用，建议加超时控制和幂等设计，防止重复执行产生副作用。

追问 3：Agent 上下文窗口有限，多轮对话中如何管理历史消息？

参考回答方向：分三个维度回答。一是消息裁剪——按 token 数做滑动窗口，保留 System Prompt 和最近 N 轮对话，中间轮次做摘要压缩（可用 LLM 生成结构化摘要存到独立字段）；二是关键信息持久化——用户偏好、已验证的事实等写入外部存储（Redis 或向量库），需要时再注入，不占用常规上下文；三是成本优化——对历史消息按重要程度分级，普通消息只保留关键词级别的摘要，关键信息才保留完整原文。另外可以提一个细节：注意预留 token 给 Function Calling 的返回结果，避免上下文写满导致调用失败。

手撕算法：LRU Cache

题意：设计一个数据结构，支持 get(key) 和 put(key, value) 两个操作，get 和 put 的时间复杂度均为 O(1)。当缓存容量达到上限时，淘汰最久未使用的 key。

关键思路：哈希表 + 双向链表。哈希表负责 O(1) 找到节点位置，双向链表维护访问顺序。get 时若 key 存在，将该节点移到链表头部；put 时若 key 已存在则更新值并移到头部，若不存在则插入头部，若超容量则删除尾部节点。注意用 dummy head 和 dummy tail 避免空指针判断。写完后主动和面试官说时间复杂度和空间复杂度，并说明 Go 标准库中 container/list 可以复用，但手写更稳妥。

准备建议

1. Go 语言重点看三块：goroutine 调度模型（GMP 各角色职责）、channel 的收发机制与死锁场景、sync 包常用原语（Mutex、WaitGroup、Once）。不用背源码，能画出调度流程图、说清 channel 缓冲区满/空时的阻塞行为即可。Java 方向则重点看 JVM 内存分区和 ConcurrentHashMap 的实现细节。

1. Redis 八股不要只背定义：缓存穿透、击穿、雪崩要能说出"发生原因 → 危害 → 至少两种解决方案"，并且能结合 Agent 场景举例。比如 Agent 的会话缓存失效瞬间大量请求打到 LLM API 上，这就是典型的缓存击穿，可以用互斥锁或逻辑过期解决。MySQL 索引部分重点复习联合索引最左前缀原则和隐式类型转换导致的索引失效，这两道题出现频率极高。

1. 项目复盘聚焦"失败与修复"：面试官对"我用了 RAG，效果不错"完全不感兴趣，他们想听的是"我遇到了什么问题，怎么定位的，怎么解决的"。建议把项目里踩过的坑整理成 3 个"问题 → 分析 → 方案"的故事线，每个控制在 1-2 分钟内讲完。另外把 RAG 的召回率、响应延迟等指标量化出来，没有真实数据就基于实验估算，但要能自圆其说。

结果反馈

一面通过，约一周后收到二面通知，整体面试节奏偏快，算法题和项目深挖占比最高，八股相对常规。

想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。