我觉得这道题其实是在问,为什么看起来挺合理的检索加生成流程,落地时总是差一口气。传统[[RAG]]的痛点,说到底就一个核心矛盾:检索端是近似匹配,生成端却要求精确回答,这个缝隙就是问题来源。
先说检索噪声。向量检索返回的Top-K里,经常混进一些语义相似但实际无关的文档。举个例子,用户搜'苹果手机充电器',结果捞出来一篇'安卓快充协议技术文档'。从向量空间看,充电、协议这些词确实近,但这个文档根本回答不了iPhone配件的问题。模型拿到以后,很可能生成错误的购买建议,直接导致客诉。这个痛点的本质是,语义相似不等于任务相关,检索的排序信号和下游生成任务的需求是错位的。
再一个,上下文冗余。检索回来的多个chunk经常包含大量重复信息。拿商品详情页的RAG来说,好几个chunk都写着'7天无理由退换',但真正关键的'电池容量参数'只在一个chunk里出现了一次。LLM的注意力被分散,最后回答抓不住重点,而且白白浪费token,推理成本也上去了。这里有个坑:冗余不只是浪费,它会稀释关键信号的权重,导致模型在细节问题上回答不准确。
还有就是知识更新延迟。[[向量库]]从构建到索引生效往往有小时级甚至天级的延迟,完全跟不上实时变化。大促期间,价格库存秒级变动,但RAG还在返回昨天缓存的活动信息,用户下单时发现优惠失效,体验极差。所以,如果业务对实时性有要求,传统RAG直接不可用。
针对这些痛点,优化方向其实挺明确的。检索噪声可以用[[重排]]或者多路召回融合来解决,比如先用[[BM25]]和向量做[[混合检索]],再让一个更精细的排序模型过滤一遍。上下文冗余可以做上下文压缩,或者用摘要增强,把多个chunk的关键信息提炼成一个精炼版本。知识更新延迟就得靠实时索引管道,或者干脆让模型直接调用API获取动态数据。
不过说实话,这些优化都是打补丁。真正要想从根本上解决问题,得跳出'检索-拼接-生成'这个线性范式。比如现在比较热的 [[Agentic RAG]],让模型自己决定什么时候检索、检索什么、怎么验证结果,甚至主动调用工具去获取实时信息。我特别关注的一个方向是让模型在生成过程中做自我反思,如果发现生成的内容和检索结果矛盾,它能主动发起二次检索。这个思路其实把RAG从被动接收信息变成了主动求证。
所以我的判断是,传统RAG最适合那些知识相对静态、查询模式比较固定的场景,比如企业内部的知识库问答。一旦涉及实时数据、长尾查询或者高度依赖上下文的任务,就得在检索策略和生成逻辑上都做改造,不能指望一个固定流程解决所有问题。