大模型项目面试技巧：如何清晰展示RAG系统开发经验

1. 为什么大模型项目总是讲不清楚？

最近在帮几位准备面试的朋友做模拟面试时，发现一个普遍现象：很多人在简历上写了大模型项目，但一到面试环节就卡壳。明明做过RAG系统、搭建过Agent框架，技术栈也写得漂漂亮亮，但面试官随便追问几个细节就露馅了。

上周有个案例特别典型：一位候选人简历上有个基于RAG的保险问答系统项目。当面试官问"系统上线后第一个暴露的真实问题是什么"时，他只回答"召回率不够高"。追问"哪种查询召回率最低"、"怎么发现这个问题的"时，回答越来越模糊。最后面试官直接点出问题："你讲了十分钟工具，但没说清楚你做了哪些决策"。

1.1 问题背后的根本原因

这种现象的本质不是技术能力问题，而是思维习惯问题。大多数人在项目开发过程中，遇到问题就解决，然后继续推进，很少停下来思考：

• 问题的根本原因是什么？
• 当时的判断依据是什么？
• 有没有其他备选方案？
• 效果如何量化评估？
• 如果重来会怎么改进？

这种思考习惯的缺失，导致面试时只能说出模糊印象："做过RAG项目，用了这些工具，效果还不错"。一旦被追问具体细节，就陷入被动。

1.2 两种项目介绍的对比

同一个RAG项目，两种介绍方式给面试官的印象天差地别：

工具清单型介绍：
"用了Milvus向量数据库，bge-large-zh embedding模型，支持PDF/Word解析，知识库有5000份保险条款，召回准确率85%，响应时间1.5秒内。"

这种介绍的问题在于：

1. 像是在背诵简历内容
2. 没有体现个人决策过程
3. 缺乏具体场景和问题细节

问题驱动型介绍：
"上线第一周发现，用户问'核辐射能赔吗'时，系统返回的都是意外险承保范围的正面描述，但实际答案在责任免除条款里。分析发现这类'问能不能赔但答案在免责条款'的查询占12%，召回率仅39%。我们增加了BM25混合检索，调整否定关键词权重，单独建立免责条款子索引，最终将这类查询召回率提升到83%。"

这种介绍的优势：

1. 展示了真实场景中的问题
2. 说明了分析过程和决策依据
3. 提供了量化改进效果
4. 体现了个人技术判断能力

2. 面试官真正想评估什么

很多候选人误以为面试官是在故意刁难，其实他们是在给你机会展示价值。面试官的核心评估标准不是"用了什么技术"，而是