我觉得这道题其实是在问一个很核心的问题:当大模型的知识不够用或者不准的时候,我们怎么给它补上?[[RAG]]就是目前最主流的一个答案。说白了,它就是把检索和生成拼在一起,让模型从闭卷考试变成开卷考试。
具体说一下工作原理,其实就是三个步骤:先把外部文档切碎、[[向量化]]、存到[[向量库]]里,这叫索引;然后用户提问时,把问题也向量化,去库里搜最相关的几段,这叫检索;最后把问题和搜到的内容拼成提示词,让大模型基于这些信息来回答,这叫生成。流程不复杂,但真正落地的时候,这里有很多细节。
先说边界划分。很多人会问,RAG和微调到底怎么选?我的看法是,它们不是二选一,而是互补。微调适合让模型学会某种风格或格式,比如把输出变成固定模板,但它很难注入新的事实知识,而且成本高、周期长。RAG正好相反,它特别适合知识频繁更新的场景,比如企业内部的SOP、实时新闻、客服政策。但RAG有个前提:你的文档库要质量高、覆盖全。如果文档本身是错的或者切分不合理,那检索出来的东西反而会带偏模型。所以真正落地的时候,我通常会把RAG和微调结合起来,比如用微调让模型学会怎么引用来源,用RAG提供实时信息。
举个例子,电商客服场景。用户问“我买的衣服退货期限是多少?”如果模型只靠参数知识,它可能回答“7天”,但不同商品、不同活动期间退货政策完全不同。用RAG的话,我们会先把所有退换货政策、满减规则、特殊活动说明都做成文档库。用户提问时,系统检索出对应的政策段落,比如“双十一期间购买的服装,支持30天无理由退换”,然后让大模型基于这段内容生成答案。这样准确率就高很多,而且政策更新时只需要改文档,不用重新训练模型。
这里有个坑:检索质量直接决定RAG的上限。如果检索回来的内容不相关,模型再强也白搭。所以我会特别关注检索这一步的工程细节,比如用 [[混合检索]],把关键词匹配([[BM25]])和向量相似度([[Dense Retrieval]])结合起来,因为很多专业术语或编号(像订单号、错误码)向量搜不好,但关键词能精准命中。另外,切分策略也很关键,固定大小切分容易把完整语义切碎,我一般会用语义切分,配合[[滑动窗口]]加一小段上下文重叠。
还有一个容易被忽略的点:RAG的评估。很多人上线后只看最终回答好不好,但中间检索召回率低的话,模型再聪明也救不回来。所以我上线前一定会做 [[RAGAS]] 评估,分开看检索的上下文精度和生成的回答[[忠实度]]。
最后说我的判断。我不会把RAG看作一个单独的组件,而是看作一个系统工程。我更倾向于把精力花在优化检索质量上,而不是一味追求更大的模型。因为对很多业务来说,一个中小模型加上高质量检索,效果往往比大模型硬背知识要好,而且成本低、迭代快。