大讲堂
它到底在干嘛？——拆了那层黑盒
RAG不是什么魔法。说穿了，就是让大模型在做生成的时候，能先去翻一堆文档，找到相关的片段儿，再基于这些片段儿吐答案。但你如果以为这只是在prompt里塞几段文本，那你就错了——错得离谱。
分块的艺术——一厘米的错误，一千米的偏差
分块策略比你们想象的要肮脏得多。简单的固定长度切分？会切断上下文。用句号或者段落切？有些文档根本不按常理出牌。我见过最惨的情况是，QA 对里边的答案正好被切成了两半，前半段在 chunk A，后半段在 chunk B，检索永远召回的是毫不相关的 chunk C。
- 固定长度512 tokens，无重叠：Top-5召回准确率 52.1%
- 基于标题的语义分块，无重叠：68.7%
- 基于标题的语义分块，15%重叠：89.3%
- 加上重排序后：94.6%
生成端的耻辱——幻觉的温床
检索召回了正确的文档，你满心欢喜地把它们塞进 prompt，结果模型给你胡诌一气。更可恨的是，它可能会过分强调检索回来的某一段无关信息，产生所谓的“上下文污染”。第三个坑：prompt 设计不合理，导致模型失去辨别能力。 我曾在 prompt 里说：“根据以下信息回答问题，如果信息不充分，请回答不知道。” 结果呢？模型执着地想要用上那些信息，就算答非所问也硬往上凑。 解决方案很微妙。你不能只给指令，你得给范例。我用了少样本提示，在 prompt 里加入两个例子：一个展示了如何正确使用上下文，另一个展示了如何拒绝不相关的上下文。然后，我又在生成之后加了一层验证——让同一个模型再读一遍自己的回答，判断是否有幻觉，如果有就不返回给用户，而返回“请重新提问”。这叫做反思性检查。这套组合拳把我们的凭空捏造率从12%压到了1%以下。代价是成本增加了大概30%，因为每次生成后要多一次模型调用。但在金融合规场景里，犯错的代价远高于这点儿算力。 再聊一个残酷的数据点。和直接使用长上下文大模型（比如GPT-4-32K）相比，RAG有什么优势？我们自己跑过基准测试：在需要频繁更新知识库（每天上千篇新文档）的场景下，长上下文模型每次都需要把整个知识库装进去，Token 消耗巨大，单次查询成本高达0.8美元；而我们的RAG流水线，虽然多了检索步骤，但单次成本只要0.02美元。延迟方面，RAG P50 是1.2秒，长模型是3.7秒。而且，长模型对最新信息的吸收有天然的延迟——它们不实时。RAG 的优势就在于知识库的即时更新，数据的隔离性，以及成本结构。但坑点也在这里：如果检索崩了，整个系统就是废物。这架构美就美在这种紧密的耦合里，某个环节的脆弱性能被放大到整个管道。 最后说一句掏心窝的话：别被那些花里胡哨的框架迷惑。RAG 没有银弹，它是一系列工程权衡的集合。你得自己去测，自己去品。那个在 demo 上跑得完美的系统，上了生产可能就是另一个故事。作者|大讲堂
排版|大讲堂
审核|乐乐