企业官网建设流程全解析

最近在整理 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的天然替代品

现在长上下文模型越来越普及，所以经常有人问：

“既然能一次输入几十万甚至更多Token，RAG还有什么意义？”

这个问题不能简单回答“有”或者“没有”。

我们先比较两种方案。

方案一：长上下文问答

基本流程：

用户提问 → 提供相关文档或全部文档 → 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，什么时候不应该用，以及如何证明自己的选择合理，才是更值得训练的能力。