你目前还在实习吗？你参与的 AI 产品主要面向什么问答场景，包含哪些问题类型
1️⃣ 考察意图
这道题看似是简历确认，实则是场景化技术匹配度的压力测试。面试官想看的不是“你做了什么”，而是“你能否把业务场景、问题类型和技术选型串成一条逻辑链”。考察类型是系统设计+工程取舍，刁钻点在于：如果你只背了RAG流程但说不清场景里为什么用RAG而不是微调，或者说不清问题类型如何驱动chunking策略，就会暴露“纸上谈兵”。答好了能展示：对产品落地的整条链路理解、从问题类型反推技术方案的工程直觉，以及迭代优化的完整流程思维。
2️⃣ 标准答
当前状态与项目定位目前我在XX公司AI部门实习，负责一个企业级知识库问答Agent，面向内部员工和外部客户的混合场景。产品核心是让用户用自然语言查询技术文档、产品手册和FAQ库，覆盖从“WiFi密码怎么改”到“API限流策略如何配置”的跨度。
问题类型与技术选型的映射我把问题拆成三类，每类对应不同技术方案：
- 事实型（Factoid）：如“服务器IP是多少”。这类问题答案唯一，对延迟敏感。技术选型：BM25+向量检索双通道。BM25用默认k1=1.5,b=0.75处理精确匹配，向量检索用bge-large-zh-v1.5做语义召回。坑：纯向量检索在“IP地址”这种数字文本上召回率低，所以必须加BM25兜底。解法：用RRF（Reciprocal Rank Fusion） 合并排序，权重设为BM25:0.3、向量:0.7，实测准确率从82%提到94%。
- 推理型（Reasoning）：如“如果A服务挂了，B服务会受影响吗”。这类需要多步推理和文档引用。技术选型：RAG+Chain-of-Thought。先用检索拿到相关文档片段（chunk size设为256 tokens，overlap 32 tokens），再让LLM（GPT-4o-mini）按“问题→相关文档→推理步骤→答案”输出。坑：LLM容易幻觉，比如自己编造“A服务依赖B服务”。解法：强制LLM在输出中引用文档ID，并在后处理中校验引用是否真实存在，不存在则拒绝回答并返回“信息不足”。
- 多轮对话型（Multi-turn）：如用户先问“怎么重置密码”，再问“那邮箱呢”。这类需要上下文记忆。技术选型：对话状态追踪（DST）+ 缓存检索。用LangChain的ConversationBufferMemory存储最近5轮对话，每次检索时把历史query和当前query拼接成“历史摘要+当前问题”再检索。坑：历史太长会稀释当前意图。解法：用LLM自动摘要，每轮对话后压缩成“用户想解决XX问题”，只存摘要而非原始文本。
实际落地的坑与解法
- 坑1：chunking粒度。一开始用固定512 tokens，结果“API限流策略”这种长文档被切碎，推理型问题召回不全。解法：改用语义chunking，用spaCy的句子分割器按段落边界切，再对每个chunk做标题增强（把文档标题拼到chunk开头），召回率提升15%。
- 坑2：评估指标。只用准确率不够，因为用户可能对“答案正确但啰嗦”不满意。解法：引入用户满意度评分（1-5星），结合答案长度惩罚（超过300字扣分），迭代后平均满意度从3.2提到4.1。
迭代方向下一步计划引入Agentic RAG：让Agent能主动调用外部API（如查询数据库）来回答实时数据问题，而不是只依赖静态文档。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，当前实习状态——我在XX公司做知识库问答Agent；第二，问题类型——我把它分为事实型、推理型和多轮对话型，分别用BM25+向量检索、RAG+CoT、DST+缓存检索来处理；第三，技术取舍——比如事实型必须加BM25兜底数字匹配，推理型必须强制引用校验防幻觉。总结一句：我的技术选型完全由问题类型驱动，每个决策都有数据支撑和迭代验证。”
4️⃣ 高频追问 & 应对
追问 1：你说用了BM25+向量检索双通道，那怎么确定RRF权重0.3:0.7是最优的？
应对策略：权重不是拍脑袋定的，而是通过网格搜索在验证集上调参。验证集是500条人工标注的query-answer对，覆盖事实型和推理型。搜索范围BM25权重0.1-0.5，步长0.05，用NDCG@10作为指标。结果0.3:0.7时NDCG最高（0.89），而纯BM25是0.72，纯向量是0.85。另外，权重对问题类型敏感：事实型问题BM25权重可以提到0.4，推理型降到0.2。所以实际部署时，我们先用一个问题分类器（基于BERT微调，准确率96%）判断类型，再动态调整权重。
追问 2：多轮对话里，你用了LLM自动摘要，那摘要本身会不会丢失信息？
应对策略：会，所以做了两层兜底。第一，摘要只压缩“用户意图”，不压缩“具体实体”。比如用户说“重置密码”，摘要必须保留“密码”这个实体，否则后续检索会偏。实现上，用命名实体识别（NER） 标记摘要中的实体，如果丢失则回退到原始文本。第二，如果摘要后检索不到相关文档，就触发全量检索：把历史所有query拼接成一个大query重新检索。实测中，摘要丢失信息导致召回失败的概率只有2%，且全量检索能挽回其中80%。
追问 3：你提到要引入Agentic RAG，那Agent调用外部API时，怎么保证API返回的数据安全？
应对策略：这是企业级场景的核心问题。解法是权限隔离+沙箱执行。Agent调用API前，先通过RBAC（基于角色的访问控制） 检查用户是否有权限访问该API。比如普通员工不能查数据库里的薪资数据。API调用在沙箱容器中执行，限制网络访问和文件系统写权限。另外，API返回的数据会经过脱敏层，用正则替换手机号、邮箱等敏感信息。如果API调用失败，Agent会返回“数据暂时不可用，请稍后重试”，而不是暴露错误堆栈。
5️⃣ 避坑 · 常见错误答法
- ❌ 只说“我用了RAG，效果很好” → ✅ 必须拆解：RAG的哪个环节（检索/生成/重排序）用了什么具体技术（BM25/DPR/CoT），以及为什么选它而不是别的。
- ❌ 把问题类型说成“简单问题和复杂问题”这种模糊分类 → ✅ 必须用技术术语：事实型（Factoid）、推理型（Reasoning）、多轮对话型（Multi-turn），并给出每种对应的技术方案。
- ❌ 只讲成功不讲坑 → ✅ 必须至少提一个实际踩过的坑（如chunking粒度、幻觉校验）和具体解法（如语义chunking、引用校验）。
6️⃣ 简历呼应
- 如果你有RAG项目：从“问题类型驱动chunking策略”切入，展示你对检索粒度的理解。比如“事实型用256 tokens小chunk，推理型用512 tokens大chunk+标题增强”。
- 如果你只做过传统NLP：用“分类任务类比”迁移。比如“我把问题类型当成一个分类任务，用BERT微调做问题分类器，再根据分类结果选择不同检索策略”。
- 如果你是校招无项目：聚焦“论文复现demo”。比如“我复现了RAPTOR论文的树状检索结构，在WikiQA数据集上验证了多跳推理的召回率提升，并分析了chunk size对结果的影响”。
- 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020）
- 《RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval》（Sarthi et al., 2024）
- 《Lost in the Middle: How Language Models Use Long Contexts》（Liu et al., 2023）
- LangChain官方文档：ConversationBufferMemory与对话摘要
- 《Dense Passage Retrieval for Open-Domain Question Answering》（Karpukhin et al., 2020）