面试官问：知识库只有100篇文档，你还会选择RAG吗？

最近在整理 AI 开发岗位的面试题时我发现一道很有意思的问题。面试官问“假设公司只有100篇内部文档要做一个智能知识库问答系统你会选择RAG吗”很多人第一反应就是“当然选RAG啊把文档切片、向量化存入Milvus用户提问时先检索再交给大模型生成答案。”听起来没什么毛病。但面试官可能会接着问“现在大模型都支持很长的上下文了为什么不能直接把这100篇文档放进Prompt”你可能会说“因为RAG可以节省Token。”面试官再问“如果这100篇文档加起来只有5万Token呢”到这里问题就有意思了。因为面试官真正想考察的可能根本不是你会不会搭建RAG而是面对实际业务你能不能判断到底需不需要RAG一、100篇文档真的需要RAG吗先看两个场景。场景A一家小公司100篇内部制度文档。这些文档加起来只有5万Token。每个月更新一两次。每天只有几十个员工提问。大部分问题也很简单比如“员工年假怎么计算”“出差住宿标准是多少”“试用期的报销流程是什么”这种情况下一定要上RAG吗不一定。完全可以考虑把文档整理后放进长上下文由大模型直接回答问题。如果所选模型能够稳定处理这些内容并且响应速度和调用成本都在可接受范围内这可能是更简单的方案。不需要单独维护向量数据库也不用处理Chunk切分、Embedding和检索排序。但是别急着下结论。场景B一家设备制造企业同样只有100篇文档。但这100篇文档包括大型设备维修手册设备参数表故障诊断流程历史维修记录一篇维修手册可能就有几百页。用户经常问“XH-3200F设备出现E200故障代码应该怎么处理”这时候100篇文档可能包含几十万甚至上百万Token。而且问题往往具有很强的定位特征需要找到特定设备、型号和故障代码对应的内容。这种场景下使用检索机制就可能更加合适。所以你会发现决定是否使用RAG的不是文档有多少篇而是文档包含多少信息、用户怎么提问以及系统需要怎样提供答案。二、长上下文不是RAG的天然替代品现在长上下文模型越来越普及所以经常有人问“既然能一次输入几十万甚至更多TokenRAG还有什么意义”这个问题不能简单回答“有”或者“没有”。我们先比较两种方案。方案一长上下文问答基本流程用户提问 → 提供相关文档或全部文档 → LLM → 生成回答优点很直观。实现简单。没有额外的向量化和检索服务。如果文档之间存在复杂的关联关系模型也有机会同时阅读多个章节进行综合分析。但它也有问题。首先模型标称支持很长的上下文不等于它能在上下文的任意位置都稳定找到正确的信息。其次如果每次提问都要重复输入大量文档成本和延迟可能会成为问题。虽然Prompt Caching等技术可以改善重复输入的成本但具体收益仍然取决于模型服务和缓存命中情况。方案二RAG问答基本流程用户提问 → 检索相关文档片段 → LLM → 生成回答RAG的一个核心优势是不必把全部知识都交给大模型。比如知识库有100万Token用户只问某个设备的故障处理流程。如果系统能准确定位相关内容就可能只需要提供几千Token的上下文。但是RAG也有自己的问题。文档切分错了可能破坏原有语义。Embedding模型不合适可能找不到正确内容。检索召回不足正确答案可能根本没有进入上下文。即使召回了排序和上下文组织也可能影响最终回答。长上下文的风险主要集中在上下文利用效果、延迟和成本RAG则额外引入了检索链路的质量问题。两者并不存在一个适用于所有业务场景的绝对胜负。三、面试官真正想听的是你的技术选型依据如果我是面试官听到候选人直接说“100篇文档就用RAG”我可能继续问“你做这个选择之前评估过哪些指标”一个有实际工程经验的开发者至少应该考虑以下几个方面。1.文档总量和有效上下文长度100篇文档可能只有5万Token也可能有500万Token。我们应该关心的是清洗、解析之后的有效文本量而不是文件数量。另外不仅要考虑知识库的总量还要判断单次问题究竟需要多大范围的上下文。2.用户查询的特点如果用户经常问“总结这份制度里所有涉及员工权益的条款。”这种问题可能需要较大范围的全文理解。但如果用户问“XH-3200F的E200故障代码是什么意思”这类问题有明确的实体、型号和编号通过关键词检索甚至混合检索就有机会快速定位相关内容。不同查询类型适合的检索和上下文组织方式并不一样。3.文档更新频率如果文档半年才更新一次预处理并缓存较稳定的上下文可能比较方便。但如果知识库每天都有大量新增和修改检索式架构在维护外部知识方面通常更灵活。当然RAG也不是天然解决更新问题。新增文档需要重新解析、切分、索引旧版本还需要及时失效。4.成本与响应速度假设某种方案每次都要输入5万Token而另一种方案通过检索只需要输入3000Token。仅从输入量来看差异很明显。但不能就此断定RAG一定更便宜。因为RAG还涉及Embedding、向量存储、检索服务、可能的Rerank以及运维成本。而长上下文方案又可能享受缓存折扣。真正做技术选型时应该结合实际请求量、价格和延迟进行测试。5.答案的准确性与可追溯性企业内部知识库问答很多时候不仅要求回答正确还要求回答有依据。比如某个设备的维修指导系统需要明确告诉用户答案来自哪一份手册、哪个章节、哪个版本。RAG可以通过检索结果保留来源信息便于生成引用。但能提供引用不代表引用一定正确。同样长上下文方案也可以通过文档编号、章节标记等方式实现来源追踪。所以还是要测试系统实际的引用准确性而不是只看架构名称。四、再追问一步如果用户需要跨文档推理呢面试官可能还有一个问题“用户问的问题需要同时查阅好几篇文档才能回答RAG怎么处理”比如一家制造企业有三类文档设备维修手册、备件库存记录、历史维修案例。用户问“XH-3200F出现E200故障目前仓库的备件能不能支持今天完成维修”这个问题不是简单检索某一个知识片段就能回答的。它可能需要首先从设备维修手册找到E200故障的排查和维修要求。然后识别可能需要更换的备件。接着查询库存系统中这些备件的实时数量和状态。最后综合维修要求、库存和其他业务条件判断能否完成维修。注意这里还有一个关键问题实时库存不应该仅依靠静态文档检索来判断。因为库存随时可能发生变化应该查询业务系统的实时数据。也就是说这个场景可能需要RAG 业务API 多步骤工作流。如果相关文档数量有限使用长上下文完成文档分析也可能可行但仍然需要获取实时库存数据。所以系统设计的核心从来不是“选RAG还是选长上下文”这么简单。而是先搞清楚哪些信息来自静态文档哪些信息来自实时业务系统哪些问题需要单次检索哪些问题需要多步骤分析把这些问题想明白技术架构才有选择依据。五、这道面试题到底应该怎么回答如果面试官现在重新问你“只有100篇文档你会选择RAG吗”我更希望听到这样的回答“我不会只根据文档数量决定是否使用RAG而是先评估文档总Token量、查询特点、更新频率以及对延迟、成本和准确性的要求。如果文档总体较小、更新不频繁而且用户经常需要跨章节综合分析我会先验证长上下文方案。如果文档内容庞大、查询定位明确、更新频繁或者需要按权限检索特定内容我会优先评估RAG。最后我会构建一组真实业务问题同时测试长上下文和RAG方案比较答案正确率、证据引用准确率、响应延迟和整体成本再确定最终架构。”这段回答并没有展示多少复杂术语。但它至少说明你在尝试从业务需求出发做技术决策。当然真正的面试官还可能继续追问“你的测试集怎么构建”“检索效果怎么评估”“如果两种方案准确率差不多但成本相差很大你会怎么选”这才是技术面试真正有意思的地方。六、为什么很多人觉得自己会了面试却答不上来因为平时我们学习一项技术经常是这样的顺序学习RAG概念。学习Chunk切分。学习Embedding。学习Milvus。学习Rerank。最后跟着教程搭建一个知识库问答系统。这些知识当然有价值。但学完之后我们往往没有认真检验过一个问题面对真实业务我究竟能不能独立判断该使用什么技术这也是我最近在做「搞定面试」时越来越重视的一个方向面试驱动式学习。先通过真实业务场景和连续追问发现自己的理解盲区。然后再针对薄弱环节学习。学完之后重新接受追问检验自己是不是真的掌握了。因为对于一个准备进入AI开发岗位的程序员来说知道RAG是什么只是起点。知道什么时候应该用RAG什么时候不应该用以及如何证明自己的选择合理才是更值得训练的能力。