北京某小厂AI后端实习生面经

（鼠鼠处女面，感觉自己说的磕磕绊绊的，逻辑不够清晰，面试官居然说回答的还好。好开心~一面秒过。）

面试问题与回答要点

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轮。