上海某小厂

后端开发/AI工程实习生 - 技术一面

面试问题速览

1. 请做个自我介绍。
2. (针对RAG项目)为什么选择用Elasticsearch来做存储?
3. Elasticsearch和其它常规的向量数据库有什么不一样的地方?
4. (针对AI Agent项目)整个Agent你是怎么去设计的?
5. (针对多轮对话)持久对话是怎么实现的?
6. 了解CAP理论吗?Redis属于哪一种?
7. (针对分布式项目)怎么去选一个leader节点?(Raft协议)
8. (针对后端项目)你这边用了一个RocketMQ,能简单说一说这种消息队列有什么用,具体用在什么场景?
9. (个人情况)现在是开学到大三是吧?实习时间大概是多少?

我的回答策略与复盘

【针对问题】RAG项目中为何选择Elasticsearch?它和专用向量数据库有何不同?

* 【回答策略】
我主要从两个层面回答了这个问题:
1. 工程实践角度:强调了基于已有技术栈和经验进行选型的务实考量。比如,我提到自己熟悉ES,且团队已有的ELK生态便于集成和运维,这展示了成本和效率意识。
2. 技术特性角度:点出了ES的核心优势在于其综合搜索能力。我解释了它不仅支持向量搜索,还能利用其强大的倒排索引进行传统的关键词检索,这对于需要结合多种搜索方式的场景非常有利。

* 【复盘与思考】
* 亮点:面试官对我从工程实践角度出发的回答表示了认可,这表明在初创公司,务实和快速落地的能力很受重视。
* 待优化:现在回想,我的回答应该优先强调技术优势。比如,可以更专业地指出ES的“混合搜索(Hybrid Search)”能力是其在RAG场景下相比Milvus等专用向量库的核心差异点和优势。先说技术核心,再说工程便利性,逻辑会更清晰。

【针对问题】如何设计一个AI Agent?

* 【回答策略】
我将Agent的设计思路拆分成了两个核心部分:
1. 核心大脑(LLM & Prompt Engineering):讲解了如何通过精心设计的提示词工程(Prompt)来赋予Agent“专家角色”,并引导其进行多轮、有逻辑的提问,而不是一次性给出所有答案。
2. 知识外挂(RAG):详细说明了如何通过检索增强生成(RAG)技术为Agent挂载外部知识库,确保回答的专业性和准确性,避免模型幻觉。同时,我还提到了对原始数据(如PDF论文)进行清洗、切块和向量化的预处理流程。

* 【复盘与思考】
* 亮点:这个回答展示了系统性思维,将一个复杂问题拆解成了具体的技术模块,并且每个模块都有清晰的实现思路。特别是提到了数据预处理的细节,增加了回答的深度。
* 待优化:可以进一步引入Tool Calling/Function Calling的概念,说明Agent如何调用外部API(如查询天气、数据库)来增强其能力,这样会让设计显得更完整和前沿。

【针对问题】Raft协议的Leader选举过程是怎样的?

* 【回答策略】
因为这是我亲手实现过的项目,所以我非常有信心地按照时间线和状态机转换的逻辑,一步步地阐述了整个流程:
1. 触发条件:从Follower收不到Leader的心跳超时开始讲起。
2. 状态转换:描述节点如何将自己的term加一,并转变为Candidate状态。
3. 选举过程:讲解Candidate如何向其他节点发起投票请求。
4. 达成共识:强调需要获得超过半数的选票才能成为新的Leader。
5. 新王登基:说明新Leader会立即发送心跳给所有Follower,以巩固自己的地位。

* 【复盘与思考】
* 亮点:这是本场面试回答得最好的问题。清晰的逻辑、准确的术语、自信的表达,强有力地证明了我的动手能力和对分布式协议的深刻理解。对于简历上的核心项目,一定要做到这个熟悉程度。

【针对问题】消息队列(RocketMQ)用在什么场景,解决了什么问题?

* 【回答策略】
我没有泛泛地谈理论,而是直接用了一个项目中的具体场景——“大数据量异步导出”——来回答,遵循了经典的STAR原则:
* (S)场景:用户请求导出大量数据,同步处理会导致页面长时间等待,甚至请求超时。
* (T)任务:优化用户体验,同时避免后端服务因长时间重度计算而崩溃。
* (A)行动:引入RocketMQ。Web服务接收到请求后,立即返回“处理中”的响应,并将导出任务作为一个消息扔进队列。后端有一个专门的消费服务去队列里取任务,慢慢处理。
* (R)结果:实现了异步化,前端响应速度极快;同时起到了削峰填谷的作用,保护了后端服务,提升了系统的稳定性和吞吐量。
* 【复盘与思考】
* 亮点:用一个具体的业务故事来包装技术,非常有说服力。这展示了我不仅懂技术,更懂得如何用技术解决实际的业务痛点,这是面试中非常重要的加分项。
全部评论

相关推荐

(鼠鼠处女面,感觉自己说的磕磕绊绊的,逻辑不够清晰,面试官居然说回答的还好。好开心~一面秒过。)面试问题与回答要点1. 自我介绍 & 项目概览2. Go语言与Raft项目考察面试官提问:看到你简历说用Go实现了Raft,是有Go的开发经验吗?对Go语言了解多少?我的回答要点:背景说明: 坦诚说明是为了完成MIT 6.824课程实验,花时间速成了Go语言并完成了项目。能力边界: 承认目前主技术栈是Java/Python,Go的经验仅限于该项目,很多细节已生疏。掌握程度: 对Go的基础语法和并发(goroutine, channel)有基本了解。3. RAG智能问答项目深挖面试官提问 1:聊一下你基于RAG的智能问答项目,你在Elasticsearch里主要做了哪些工作?我的回答要点 (阐述RAG全流程):离线处理阶段:数据预处理: 将PDF论文转为Markdown。文本切块 (Chunking): 采用基于语义的切块方式,保证上下文完整性。向量化 (Embedding): 使用智谱的Embedding模型将文本块转为向量。数据入库: 将文本和对应向量一同存入Elasticsearch。在线检索与生成阶段:用户问题向量化: 用同样模型处理用户提问。向量相似度检索: 在ES中召回Top 3最相关的文本块。构建Prompt: 将召回的文本块作为Context,与用户问题组合成最终的Prompt。生成答案: 将Prompt发送给大模型(LLM)获取最终回答。面试官提问 2 :召回的Top 3数据可能内容相似度很高,但不一定完全符合用户问题,你如何避免给用户错误的引导信息?我的回答要点:优化数据源: 关键在于切块质量,保证每个Chunk都是一个逻辑完整的语义单元。优化召回策略:扩大召回量: 尝试扩大Top K(如Top 5),为LLM提供更丰富的上下文。增加多样性: 可以在召回时引入多样性策略(如MMR算法思想),除了最相似的,也召回一些“不那么相似但可能包含新信息”的文本块,避免信息茧房。4. 基于Redis的多轮对话管理面试官提问 1:你提到用Redis做了个性化的多轮对话管理,具体是怎么实现的?我的回答要点:持久化方案: 放弃框架默认的内存会话管理,选择Redis做持久化存储。数据结构: 使用Session ID和User ID作为Key,将用户的多轮对话历史关联起来。存储格式: 将包含发言人、内容、时间等信息的对话历史序列化成JSON字符串后存入Redis。读写流程: 当新一轮对话发生时,从Redis取出历史记录,反序列化,追加新内容,再序列化存回去。面试官提问 2 :LLM本身有上下文窗口(Context Window)限制,你是怎么突破限制,实现长期记忆的?难道把全部历史记录都传给模型吗?我的回答要点 (坦诚现状 + 给出解决方案):承认局限: 首先坦诚目前项目的实现确实是全量传入,在对话轮次很多时会超出上下文限制,这是一个待优化的点。提出解决方案:方案一 (摘要压缩): 对时间较早的对话历史进行总结,用一个简短的摘要来代替冗长的原文,从而压缩上下文长度。方案二 (RAG on History): 将长期对话历史本身也视为一个外部知识库。当用户提问时,先用RAG的方式从历史记录中检索出与当前问题最相关的几轮对话,而不是把全部历史都传进去。反问环节我问: 公司的具体业务?面试官答: AI硬件,做嵌入式芯片,主要应用在玩具中,与用户进行大模型交互。后端技术栈是Go。我问: 对我本次面试表现的看法和建议?面试官答: 整体不错,但项目经验偏校园和实验性质,缺乏工业级的深度。我问: 后续面试流程?面试官答: 总共2-3轮。
查看6道真题和解析
点赞 评论 收藏
分享
评论
1
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务