这道题我觉得它问的不是[[RAG]]的原理,它本质是在问:怎么让大模型在不知道的情况下不要瞎编,同时还要高效、可信。RAG是个好办法,但落地时有很多坑,我主要从检索、生成和边界这三个角度来讲。
先说检索。最理想的情况是用户问什么,数据库里就有最匹配的文档。但实际往往有语义鸿沟,比如用户说“退款流程”,库里存的可能是“售后政策”,[[Embedding]] 没对齐就匹配不上。更糟的是检索噪声,Top-K里混进一堆无关文档,把关键信息稀释了。举个例子,电商客服场景,用户问“满减优惠和店铺券能不能叠加”,如果检索只靠向量相似度,可能捞出一堆满减规则,却漏了店铺券的条款。改进思路很简单:别只依赖一种检索方式。我会用 [[Hybrid Search]],把 [[BM25]] 的关键词匹配和向量检索结合起来,再做个 [[重排]],用 [[Cross-Encoder]] 把候选文档精排,把噪声过滤掉。这里的风险是,重排本身有延迟,如果QPS高,得控制候选数量,不然响应时间会崩。
然后是生成阶段。文档捞回来了,但可能太长,关键信息被淹没,模型反而开始“自由发挥”,也就是 [[Hallucination]]。比如客服回答里,模型把两个政策混在一起编了个新规则。我的做法是引入 [[Self-RAG]],让模型在生成时自己判断:这个片段要不要引用?引用哪个来源?如果模型不确定,就再检索一次。同时我会做上下文压缩,把长文档里不重要的句子剪掉,只保留和query最相关的段落。这个得配合 [[In-Context Learning]] 来设计,不然压缩会丢失上下文。
这里有个关键边界:RAG不是万能的。它适合知识频繁更新的场景,比如政策变更、实时数据;而 Fine-tuning 更适合把领域知识内化到模型参数里,比如专业术语、固定规则。真正落地往往是RAG加微调一起上,embedding层微调一下,生成模型做少量 [[SFT]],这样检索和生成在语义空间上更对齐。
另外,复杂推理场景,比如多跳问题“某订单异常,先查该订单关联的满减活动,再查该活动的生效时间”,RAG一次检索搞不定。这时候我倾向走 [[Agentic RAG]],用 [[ReAct]] 循环,让模型自己决定:先搜订单,拿到活动ID再搜活动表,最后推理出答案。但[[Agent]]化有风险,循环次数多了延迟会很高,而且模型可能跑偏。所以我会限定最大步数,并给每个工具加清晰的描述,让模型知道什么情况下该调用什么。
所以我的总结是:RAG是个好工具,但不是 silver bullet。我更倾向把它看成知识外挂,需要和微调、Agent配合使用。上线前我会特别关注检索的召回率和生成的事实一致性,用 [[RAGAS]] 这类框架做评估,不达标的场景宁可降级也不让模型瞎答。