RAG 不是默认选项。这一节用我们真实拒绝过的三个需求,说明什么时候不该用它。
可复现前提: 三个案例的数据规模与判断依据都写在下面,你可以拿自己的需求对照。
一句话定义
RAG = 检索 + 生成。在回答前先从你的文档库里找出相关片段,拼进上下文再让模型作答。它解决的是「模型不知道你们公司的事」这个问题。
三个真实判断
案例一:客服知识库问答(用了 RAG)。 文档 4000 篇、每周更新、需要引用来源。这是 RAG 的标准场景——数据量远超上下文窗口,且更新频繁。
案例二:合同条款审查(没用 RAG)。 每次只审一份合同,长度约 8000 字。直接把整份合同放进上下文即可,加检索反而丢信息。能塞进上下文的,别做检索。
案例三:代码风格统一(没用 RAG,做了微调)。 需要模型稳定输出我们特有的代码风格。这是「行为」问题不是「知识」问题,检索帮不上忙。
决策表
| 特征 | 建议 |
|---|---|
| 知识量 > 上下文窗口 | RAG |
| 知识频繁更新 | RAG |
| 需要引用来源 | RAG |
| 单份文档能塞下 | 直接给全文 |
| 要改变输出风格/格式 | 调 prompt 或微调 |
| 需要精确计算/统计 | 给工具,不是给文档 |
下一节
确定要用 RAG 之后,第一个动手的环节是文档切分——也是最容易做错的环节。
评论与复现反馈 0
还没有人评论。复现之后回来说一声,对作者很有价值。