多家小公司 Java 后端一面：版本号追问、上机 AI 编程与 RAG 深挖

《面试题目》

1. 介绍一下你的背景和课题组的研究方向。
2. 现场上机：用 AI 辅助编程处理文档和表格。
3. 自我介绍。
4. 你们项目里 SpringBoot 和 Redis 用的是什么版本？
5. 笔试：MySQL、HTTP、Linux、Docker 基础，以及开放性题目。
6. 讲讲你的 RAG 项目。
7. Agent 能用到哪些工具？怎么发现和调用这些工具？
8. 你的 RAG 流程是怎样的？
9. 为什么只对标题做向量化？
10. 改进之后效果怎么样？

《参考解析》

版本号这类问题在考什么：答不出 Redis 版本被质疑「不是忘了而是根本没在意、教程拿来就用」，面试官真正想确认的是有没有独立选型和踩坑的经历。准备项目时把依赖版本、为什么选它、升级时踩过什么坑记清楚：SpringBoot 2.x 到 3.x 换了 Jakarta 命名空间、以 JDK 17 为基线；Redis 6 引入多线程 IO 和 ACL，7 加了 Function。说不出小版本没关系，讲清大版本差异和自己实际用到的特性就够。

为什么只向量化标题会翻车：标题短、噪声低、向量化成本小，但召回只能命中标题里出现过的词，正文信息全部丢失。改进方向不是把正文切块一起塞进去——切块后单块语义被稀释、块间内容重复，反而干扰排序。可行的是父子块（子块检索、父块喂给模型）、标题加正文摘要的混合表示、BM25 与向量混合召回再重排，并用评测集量化每一步收益。

工具发现与调用：给模型一份工具清单（名称、描述、参数的 JSON Schema），由模型输出结构化调用，服务端校验参数后执行并把结果回灌。工具多了要做检索式选择，否则上下文放不下、模型也容易选错。描述要写清「什么时候该用」。MCP 是把工具供给标准化的做法，同一套工具能被不同客户端复用。

RAG 的完整链路：文档解析清洗、切块、向量化入库；查询侧做改写和多路召回（向量加关键词），融合后重排，取 top-k 拼进上下文，最后约束模型只依据给定材料作答并给出引用。最容易被忽略的是切块策略和评测：切块决定召回上限，没有评测集就判断不了改动好坏。

三场面试的差别：不在题目难度，而在面试官愿不愿意花时间。第一场把人叫到线下却只问背景，还现场让用 AI 处理表格，说明岗位要的是能立刻上手的人；第二场拿版本号否掉人；第三场项目被追问到崩，但面试官给了优化建议，这类反馈比结果更有价值。