小厂面试官问我：“公司内部文档不多，直接用小模型代替 RAG 可行吗？”，我笑了说：“RAG 解决的不是文档多不多的问题。。”

大家好，我是R哥。

有个兄弟前段时间面试，面试官问了他一个很有意思的问题：

公司内部文档并不多，可能就几十份文档、几百页内容，为什么还要上 RAG？直接训练一个小模型不行吗？

很多人听到这个问题，第一反应是肯定可以。毕竟文档量不大，把这些资料整理出来，微调一个小模型，然后直接提供问答能力，看起来似乎比搭建 RAG 还简单。

但如果你这样回答，很可能就正中了面试官的圈套了。

因为这道题真正考察的并不是 “小模型能不能替代 RAG 的问题”，而是你是否理解模型训练和 RAG 分别解决什么问题。

很多人认为 RAG 的作用是增强大模型能力，或者认为大模型能力不足时才需要 RAG。

实际上这种理解并不准确，现在大模型生成能力已经非常强了，无论是写代码、写文案还是分析问题，本身都没有太大问题。

所以，企业之所以大量使用 RAG，并不是因为模型不会回答，而是因为模型不知道企业最新、最准确、最权威的知识是什么，这才是问题的关键。

举个简单的例子：

公司员工手册里面规定年假为 5 天，于是你把这份资料训练进一个小模型中。上线之后，员工询问年假规则，模型能够准确回答，自然没有任何问题。

但半年之后，公司制度调整，年假从 5 天变成了 10 天，此时问题不就来了吗？

如果知识是存储在模型参数中的，那么你需要重新收集数据、重新训练模型、重新测试效果，最后再重新部署上线。哪怕只是修改了一条制度，你是不是也需要重新走一遍完整流程？

而如果采用 RAG 方案，只需要更新知识库文档并重新构建索引即可，整个过程可能只需要几分钟，模型本身甚至不需要发生任何变化。

如图所示：

那么，是不是意味着小模型永远无法替代 RAG 呢？

当然也不是。

如果企业知识本身非常稳定，几年都不会发生变化，而且数据规模确实很小，那么微调一个小模型完全是一种合理方案。

比如：产品说明书、培训教材、标准化业务规则、固定知识问答等场景，本身知识更新频率极低，维护成本也不高，直接通过模型记忆这些知识反而更加简单。

但现实中，大部分企业知识库都不属于这种情况。

企业制度会调整，产品功能会迭代，接口文档会更新，业务流程会变化，甚至同一个问题在不同时间段都可能对应不同答案。

在这种情况下，哪怕只有几十份文档，我依然会优先考虑 RAG，而不是把所有内容都训练到模型里面。

所以，当面试官问 “公司内部文档不多，直接用小模型替代 RAG 可行吗” 时，正确的回答不应该围绕文档数量展开，而应该围绕知识变化频率展开。

因为决定是否需要 RAG 的关键因素，从来不是文档有多少，而是知识更新得有多快。

最后，你 Get 到了吗？

最后，认真推荐下我的《Spring AI 开发实战课 》，学完把它落地到真实项目里，出去面试的时候就有竞争力了，很多面试官都不一定会，你能落地应用，能说上来，可以和其他同学直接拉开差距了。

我目前正在适配 Spring AI 2.0 和更新 Agent 内容，后续等 Spring AI 课程内容逐渐丰富，肯定会涨价一波，早订阅，早学习，早受益。

Spring AI 2.0 发布后，Java AI 真正要起飞了。。

Spring AI 让 Java 再次伟大！！