大模型实习模拟面试之快手AI Agent开发实习生二面：RAG评测体系、Agent智能优化与全排列手撕详解

大模型实习模拟面试之快手AI Agent开发实习生二面RAG评测体系、Agent智能优化与全排列手撕详解摘要本文完整还原了快手AI Agent开发实习生岗位的第二轮技术面试全过程。本轮面试聚焦于大模型应用工程核心领域——RAG检索增强生成与Agent智能体设计全程围绕项目深度展开不涉及传统后端知识。内容涵盖RAG评测维度与指标体系构建、数据集设计、相关性与回答质量优化策略、上下文工程优化、长短记忆协同机制、Agent智能化路径等前沿议题并附带一道经典算法题“全排列”的手撕实现。全文采用“面试官提问 候选人口头回答 连环追问”形式结构清晰、逻辑严密、内容翔实字数超9000适合准备大模型/AI Agent/LLM应用工程方向实习或校招的同学深度参考。一、引言为什么二面更聚焦“Agent智能”在大模型从“能用”走向“好用”的关键阶段AI Agent智能体已成为各大厂落地LLM能力的核心载体。与一面考察系统工程能力不同二面往往聚焦业务理解、产品思维与AI工程方法论。快手作为内容平台其内部AI Agent团队致力于构建高效、可靠、可解释的智能工具平台服务于客服、运营、数据分析等场景。因此本轮面试完全围绕RAG系统优化与Agent智能增强展开问题层层递进从“你做了什么”深入到“你怎么想”“你怎么系统化解决”极具代表性。本文将以第一人称视角高度还原这场技术对话并穿插专业解析与延伸思考助你掌握大模型应用面试的核心逻辑。二、RAG项目深挖评测体系与数据集构建面试官提问“你之前提到做了RAG项目那你们是怎么评测效果的有哪些维度用了哪些指标”我的回答这是个非常关键的问题。RAG系统的最终目标不是“召回多”而是“生成有用、准确、可信的答案”。所以我们构建了一个多维度、分层次的评测体系主要包含以下三个层面1.检索层RetrievalRecallK前K个召回结果中是否包含至少一个相关文档人工标注。我们通常看Recall5和Recall10。MRRMean Reciprocal Rank衡量相关文档的排名靠前程度对排序敏感。Hit Rate用户点击的文档是否在召回列表中线上行为数据。2.生成层GenerationFaithfulness忠实度答案是否严格基于检索到的文档是否存在幻觉Hallucination。我们用规则小模型打分比如检查答案中的实体是否出现在上下文中。Relevance相关性答案是否直接回应了用户问题。采用5分制人工评分。Usefulness有用性用户是否认为答案解决了问题通过“有用/无用”按钮收集。3.系统层SystemLatency端到端响应时间P50/P95Token Usage输入/输出token数影响成本Fallback Rate因检索失败或置信度过低而返回兜底话术的比例。我们每周跑一次离线评测500条样本同时监控线上AB实验的核心指标如会话完成率、NPS。两者结合避免“离线涨点但线上无效”。面试官追问“你们的数据集包括什么怎么构建的”我的回答我们的数据集分为三部分1. 查询-文档对Query-Document Pairs来源历史用户搜索日志、客服工单、产品FAQ构建方式对每个Query由领域专家标注1~3个最相关的知识库文档正样本并采样若干不相关文档负样本规模约10,000条高质量标注对。2. 查询-答案对Query-Answer Pairs来源客服标准答案、产品文档摘要用途用于评估生成质量Faithfulness/Relevance特点答案需简洁、无歧义、可验证。3. 对话上下文数据Contextual Queries模拟多轮对话如Q1: 如何重置密码 A1: 请进入“设置”-“账号安全”... Q2: 找不到“账号安全”选项用于测试Agent的上下文理解和指代消解能力。数据构建难点在于覆盖长尾场景。我们通过主动学习Active Learning将模型不确定的Query如低置信度送人工标注持续迭代数据集。三、优化思路从经验驱动到体系化建设面试官提问“如果让你对相关度和回答效果做优化你有什么思路有没有更体系化的思路”我的回答初期我们靠“试错调参”比如换embedding模型、调rerank阈值。但后来意识到需要体系化优化框架。我总结为“三层优化漏斗”第一层数据层优化Query改写Query Rewriting用LLM将模糊Query转为明确表述如“弄不了” → “无法完成操作”文档增强对知识库文档做摘要、关键词提取、同义词扩展提升召回率负采样优化在训练reranker时加入“难负例”Hard Negatives如语义相近但答案错误的文档。第二层检索层优化混合检索权重自适应不再固定向量:BM256:4而是根据Query类型动态调整如技术类Query提高BM25权重多粒度索引除了子块增加句子级、段落级索引按需召回Reranker微调用我们自己的Query-Document对微调Cross-Encoder比通用模型更贴合业务。第三层生成层优化Prompt Engineering明确指令“仅基于以下文档回答若信息不足请说‘我不知道’”结构化上下文“[来源1] … [来源2] …”后处理校验实体一致性检查答案中的产品名、版本号必须出现在上下文中置信度过滤若rerank最高分低于阈值触发兜底。体系化体现我们将上述优化点封装为可配置的Pipeline支持A/B测试不同组合并通过自动化评测平台量化每个改动的影响。这比“拍脑袋”调参科学得多。四、数据处理场景分布式思维与Agent协作面试官提问“如果设计一个数据处理场景比如有一千条数据需要求和你会怎么做处理”我的回答这个问题看似简单但考察的是Agent如何分解任务、调度资源、保证正确性。我的思路如下1.任务分解Task Decomposition将1000条数据分成N个子任务如N10每份100条每个子任务由一个Worker Agent处理。2.并行执行Parallel Execution主AgentOrchestrator分发任务给Worker AgentsWorkers独立计算局部和partial sum可利用多进程、多线程甚至分布式集群如Ray、Celery。3.结果聚合Result Aggregation主Agent收集所有partial sum求总和total sum(partial_sums)关键点需处理Worker失败重试机制、结果去重幂等性。4.容错与验证校验和对原始数据计算MD5确保未被篡改冗余计算对关键子任务分配多个Worker取多数结果日志追踪记录每个子任务的输入/输出便于Debug。如果数据在数据库中直接SELECT SUM(column) FROM table当然最快。但若数据分散在不同系统如日志文件、API返回Agent的协调能力就至关重要。延伸思考这其实是一个MapReduce模式——Map阶段分片计算Reduce阶段聚合。Agent天然适合这种范式。五、RAG性能优化速度与质量的平衡面试官提问“RAG性能如何提升”我的回答RAG性能瓶颈通常在检索延迟和LLM生成延迟。我们的优化策略分两方面1.检索加速索引优化向量索引用HNSW替代Flat Index牺牲少量精度换毫秒级响应倒排索引对BM25预计算文档权重缓存高频Query结果。缓存机制Query-Level Cache相同Query直接返回历史结果TTL5minChunk-Level Cache对高频知识块缓存其embedding和rerank分数。异步预加载用户输入时前端预测可能Query后台预检索。2.生成优化上下文压缩用LLM对检索结果做摘要只送摘要给主模型或用Sentence-BERT选最具代表性的句子。流式输出Streaming边生成边返回提升用户体验小模型兜底对简单Query如“公司电话”用规则或小模型直接回答绕过LLM。权衡点性能优化不能牺牲准确性。例如HNSW的ef_search参数调太低会导致Recall暴跌。我们通过P95延迟 vs Recall5曲线找到最佳平衡点。六、上下文工程从拼接到智能裁剪面试官提问“你的上下文怎么处理的有什么优化思路”我的回答上下文处理是RAG的“艺术”。我们经历了三个阶段阶段1简单拼接文档1: ... 文档2: ... 问题: ...问题冗余多、关键信息淹没、超出LLM窗口。阶段2结构化截断按父块分组标注来源动态截断按rerank分数累加token直到上限。阶段3智能上下文选择当前方案相关性重排rerank后不仅看分数还看与Query的关键词重叠度冲突检测与融合若多个文档对同一事实说法不同如“退款周期3天” vs “7天”优先取最新版本或在Prompt中提示差异指代消解在多轮对话中将代词“它”、“这个功能”替换为具体名词元信息注入添加文档可信度标签如“来自官方手册” vs “用户论坛”引导LLM加权信任。未来方向探索LLM-guided context selection——让一个小模型先判断“哪些信息对回答此问题最关键”再构造上下文。虽增加一步调用但可显著提升生成质量。七、记忆机制长短记忆的协同之道面试官提问“长短记忆之间怎么做协同呢”我的回答这是Agent智能化的核心挑战。我们的设计原则是短期记忆管“对话状态”长期记忆管“用户画像/知识沉淀”。1.短期记忆Short-Term Memory存储内容最近3~5轮对话历史实现方式内存缓存如Redis HashKeySessionID用途指代消解“它坏了” → “直播推流功能坏了”意图延续“还有别的方法吗”生命周期会话结束即清除。2.长期记忆Long-Term Memory存储内容用户偏好如“常用iOS设备”历史问题如“曾咨询过退款”知识沉淀如“用户A擅长视频剪辑”实现方式向量数据库 结构化DB向量库存储对话摘要的embedding用于相似问题召回结构化DB存储明确事实如设备型号。3.协同机制读取阶段短期记忆直接拼入上下文长期记忆通过记忆检索Memory Retrieval触发用当前Query检索向量库召回相关历史摘要。写入阶段对话结束后用LLM生成对话摘要如“用户咨询了iOS版直播推流问题”提取结构化事实如“设备: iPhone 14”存入DB摘要向量化后存入向量库。冲突处理若长期记忆与当前上下文矛盾如用户换了设备以最新对话为准并更新长期记忆。隐私考量长期记忆需用户授权且支持“遗忘”GDPR合规。八、Agent智能化从工具调用到自主规划面试官提问“你有什么思路去对你的agent做优化让他更智能呢”我的回答“智能”不是单一功能而是感知-决策-执行-反思的闭环。我的优化思路分四步1.增强感知能力多模态输入支持图片、语音如用户上传报错截图上下文理解用NLU模块识别意图、槽位、情感环境感知获取用户设备、网络状态等上下文。2.强化决策能力工具调用Tool Calling预定义工具集查订单、查文档、发邮件LLM根据问题选择工具参数示例用户问“我的订单到哪了”Agent调用get_order_status(order_id)。规划与反思Plan Reflect复杂任务拆解为子目标如“帮我分析上月DAU下降原因” → 1. 查DAU数据 2. 查活动日历 3. 生成报告执行后自我评估“答案是否完整是否需要补充”3.提升执行可靠性工具沙箱限制工具权限防止误操作结果验证工具返回后用规则或小模型校验合理性降级策略工具失败时切换备用方案或请求人工。4.构建学习闭环用户反馈收集“有用/无用”、修正答案自动标注将高置信度交互对加入训练集在线学习定期微调工具选择模型、reranker等组件。终极目标让Agent从“被动问答”进化为“主动助手”——能预判需求、提出建议、持续学习。九、算法手撕全排列Permutations面试官“写一个全排列的函数。”我的回答边写边解释好的我用Python实现。全排列是回溯算法的经典题。假设输入是不含重复数字的列表如[1,2,3]。defpermute(nums):res[]defbacktrack(path,used):# 终止条件路径长度等于原数组iflen(path)len(nums):res.append(path[:])# 注意拷贝returnforiinrange(len(nums)):ifused[i]:# 已使用则跳过continue# 做选择path.append(nums[i])used[i]True# 递归backtrack(path,used)# 撤销选择回溯path.pop()used[i]Falsebacktrack([],[False]*len(nums))returnres关键点used数组标记元素是否已选避免重复path[:]必须拷贝否则res里全是同一个list的引用时间复杂度O(n! * n)空间O(n)递归栈。如果输入有重复元素需先排序然后跳过“同一层”的重复选择nums.sort()ifi0andnums[i]nums[i-1]andnotused[i-1]:continue这确保重复元素只在“前一个已使用”的情况下才选避免重复排列。测试用例permute([1])→ permute([1,2])→[[1,2],[2,1]]十、反问环节与岗位洞察我的反问“请问后续还有几轮面试团队主要做什么业务”面试官回答后续可能有三面技术终面或HR面团队主要做内部AI Agent工具和平台比如智能客服Agent数据分析Agent自动写SQL、生成报告运营助手自动生成文案、审核内容技术栈以Python为主配合公司内部框架类似LangChain但更轻量、可控。我的思考这说明岗位强业务导向要求候选人不仅能调模型更要理解业务场景设计实用Agent。后续准备应侧重熟悉Agent设计模式ReAct、Plan-and-Execute了解内部工具链可提前研究LangChain、LlamaIndex思考如何将RAG/Agent落地到具体场景如客服、BI。十一、总结大模型时代工程师的新能力模型这场二面让我深刻体会到大模型应用工程师 ≠ Prompt Engineer。真正的竞争力在于系统化思维能构建评测体系、优化Pipeline、权衡性能与效果Agent-first视角将问题视为“智能体如何完成任务”而非“如何调用API”数据驱动用数据验证假设而非主观判断工程严谨性即使做AI也要考虑容错、隐私、可维护性。对于准备类似面试的同学我建议深挖一个RAG/Agent项目准备好“为什么-怎么做-效果如何-如何改进”四连问掌握核心算法回溯、DFS、动态规划仍是手撕重点关注前沿实践如Self-RAG、CRAG、Memory Bank等新范式。