这道题问的是[[RAG]]的性能瓶颈和优化,其实本质上是在问,你怎么理解RAG系统中检索、生成、效率这三环的协同关系,而不是让我列一堆技术点。我一般会从三个维度去拆解:检索精度、生成质量和系统效率,但真正落地时,这三者经常是互相牵制的,你得有取舍。
先说检索精度。最直接的瓶颈是向量语义匹配不准,尤其当query里带专有名词或者缩写时,纯向量检索很容易跑偏。我的做法是上[[混合检索]],把[[BM25]]关键词召回和向量召回结合起来,用RRF融合排序。比如客服场景里用户问“满200减50怎么用”,向量可能把“满减规则”和“优惠券叠加”混在一起,但BM25能精准匹配“满200减50”这个短语。不过这里有个前提,就是你得有好的分词和停用词表,否则BM25也会引入噪声。
再一个就是查询改写,用LLM把query扩展成更完整的表述,比如生成一段假设回答再检索,也就是HyDE,或者补全省略的主语。但这里有个坑,改写本身会引入延迟,而且如果LLM改错了,反而会误导检索。所以我一般只在query长度很短或者明显模糊时才触发改写,做个规则兜底。
检索出来以后,我还会加一道[[重排]],用[[Cross-Encoder]]精排,把候选从100缩到Top-5。精度提升确实明显,但代价是延迟增加。所以我会根据场景取舍:如果是对实时性要求高的在线系统,重排只对Top-20做,而不是全量。说白了,重排是个奢侈品,得用在刀刃上。
生成质量这块,核心问题是上下文过长和[[幻觉]]。我常用的策略是上下文压缩,检索后用一个小模型把文档里的关键片段抽出来,或者做递归摘要,确保输入在模型有效窗口内。比如企业合规文档,动辄几十页,直接塞给LLM,它会忽略重要细节,压缩后反而更聚焦。
还有一个关键点是答案溯源,强制模型输出引用标记,比如[1][2],然后事后校验这些片段是否真实支撑答案。这能显著降低Hallucination,但前提是检索回来的文档本身质量够高。如果文档本身就是错的,溯源反而会放大错误。所以我会在检索阶段就做相关性过滤,分数低于阈值时直接拒答,比胡说八道更安全。
系统效率方面,我比较关注的瓶颈是检索延迟和吞吐。索引分层是基础,热数据用[[HNSW]]内存索引,温数据放磁盘,冷数据按需加载。比如电商库存查询,热门的SKU命中率很高,冷门商品可能几周才查一次,分层能省不少成本。
缓存策略也很关键,query [[embedding]]缓存和热门答案缓存,命中率通常能到30-50%。但缓存要小心过期问题,比如促销活动期间,规则变了,缓存里的旧答案就不能用了。所以我会加一个基于时间戳的失效机制,或者用LRU加主动淘汰。
异步流水线是我比较推崇的优化方式,检索和生成解耦,检索走异步批量,生成用流式输出,这样TP99能降不少。另外量化加速也很实用,比如把向量做INT8量化,或者优化[[KV Cache]],牺牲1-2%精度换2倍吞吐,对成本敏感的场景很划算。
说到量化,我其实更关注它和重排的配合。量化后的向量检索精度下降,重排能不能补回来?这取决于重排模型的质量。如果重排模型本身也是量化过的,那精度损失可能会叠加。所以我会先做一组A/B测试,看量化加全精度重排 vs 全精度检索加量化重排,哪个组合在Recall和延迟上更平衡。
最后说一下迭代路径。我一般分三步走:先保证召回率,别漏掉关键文档;再优化精确率,别返回无关内容;最后做效率调优。监控看板上我会同时跟踪检索命中率、答案相关度、用户反馈,形成闭环。如果只让我挑一个指标,我会看用户是否点击了“有帮助”,这比任何离线指标都真实。所以整体上,我更倾向把RAG当成一个持续调优的系统,而不是一锤子买卖。