京东实习 一面凉经

1. 实习经历1.1 IO密集型和CPU密集型的任务协程数量如何配置1.2 IO密集型的任务协程数量是越多越好吗2. java和go线程模型区别3. 调度时有的任务执行时间长导致其他任务饿死怎么解决4. 反射是什么5. 反射存在性能问题，如何优化6. TCP和UDP的区别7. UDP为什么不可靠8. 调用下游服务失败，怎么从网络层面定位问题，用什么工具，怎么解决9. 在广州访问一个网页，从广东的服务器得到相应，从网络层面这个流程经历了什么10. CDN的原理11. 路由协议有哪些，有什么区别12. NAT是什么，有什么作用13. 进程存在哪些状态14. 进程是怎么做上下文切换的15. 线程上下文切换了什么资源16. 多线程访问资源出现冲突怎么办17. 需要为一张表建索引的时候需要考虑什么18. 索引的原理，为什么比全表扫描要快19. 反问：1. 业务：云计算、网络相关基架；2. 开发语言：底层服务cpp，上层服务java、go，运维脚本用py；3. 几轮技术面：三轮；4. 有什么建议：挺不错的，原理可以更深入学习面的基础架构研发云服务方向，还担心拷打很多K8s八股特地看了下结果没问面试官评价挺不错的，许愿二面——————更新：第二天约了后面两面（搞错了是雷火的），等了六天约下一面

华为od零经验上岸虽然八成沾的学校的光，但还是想记录一下，哪天不想看了再删七月初加上了hr微信，机考准备了两个礼拜，遇到一道做过的题，总分差不多250（半夜做完给hr发分数居然能秒回资面还是很简单的，面试官很和蔼，聊到后面甚至有些愉快一面手撕很简单，问了几个很基础的八股，整体半小时不到因为没经验项目也不太行面试官觉得没什么可问的，不过也很和蔼，选的题也是特意选简单的二面没怎么问，还是因为没经验没项目，看得出来对此比较不满意，依旧没问啥技术或八股问题，但是手撕做了半小时做出来了，最后面试官还讲了下改进的方法（后来知道二面比一面评价差很多主管面特别严肃，问了几个问题就立马下线，薪资业务啥都没讲，看起来显而易见的嫌没经验，但好在结果还是过了hr特别负责，审批催得很紧所以非常快，三天左右吧好像，还给我多争取到了1k，租房什么的也都会帮忙看，总之是真的很感谢再过俩礼拜入职了，看到很多都说这个学历当外包浪费了，但是事实就是没经验真的很难找，特别是25校招已经过了的现在，不考研考公的话这个已经是我知道的比较好的选择了，准备准备上班吧，在家天天被念叨二战真的……

（鼠鼠处女面，感觉自己说的磕磕绊绊的，逻辑不够清晰，面试官居然说回答的还好。好开心~一面秒过。）面试问题与回答要点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轮。

研究生这两年C++的项目只做了两个，其中一个还是凑合的，现在撰写好了简历，麻烦大佬们帮我看看，有什么改进的么？