RAG 工程实践:双向量检索 + 重排 + RRF 融合

两个项目,一套方法论

• LawRAG-Agent:中文法律问答,要求准确的条文引用
• rag_microencomic:微观经济学教材问答(马斯-克莱尔《微观经济理论》),含公式与图表

场景不同,但技术骨架一致——这条骨架值得记录。

技术栈

三个关键设计

1. 双向量检索(原文 + 摘要)

单路检索的痛点:原文 chunk 和”问题”的语义距离远(法律条文表述与日常提问差异大), 长文档被切碎后主题信息丢失。

解法:建两个向量库——原文库 + 摘要库。摘要库负责”找到相关主题”, 原文库负责”找到精确条文”。两条路召回后合并。

2. 重排序

向量检索是”近似”的,Top-K 里混着似是而非的结果。重排模型(交叉编码器) 逐对计算 query-document 相关性,把真正相关的提到前面。

组合拳:嵌入负责召回(快,覆盖广),重排负责精排(准,只对 Top-K 算)。

3. RRF 融合

双路检索怎么合并?不是简单的分数相加(两路的分数尺度不同,没法比)。

用 Reciprocal Rank Fusion:每个结果按它在各自列表里的排名取倒数求和:

RRF(d) = Σ 1 / (k + rank_i(d))

只看排名不看绝对分数,天然解决尺度不一致问题。

PDF 解析的坑(经济学项目)

教材是 PDF,含公式和图表——纯文本提取会毁掉这两类内容:

• 公式会被提成乱码,向量化后污染检索
• 图表信息直接丢失

解法:专用 PDF 处理器 + OCR 兜底(扫描页)+ 图表识别,再结构化分块。 分块策略(chunking)对公式密集型文档尤其重要:公式必须和上下文一起入块, 否则检索到的公式碎片没有意义。

部署取舍:本地化

两个项目都选择了完全本地部署(BGE + Qwen 全家桶):

• 法律数据不外传
• 教材数据有版权顾虑
• 7B/14B 量化后消费级 GPU 可跑

代价是答案质量上限低于云端大模型——但检索质量决定 RAG 下限, 生成模型只是锦上添花。检索做扎实了,7B 也能给出带准确引用的答案。

结论

RAG 的工程重点从来不是”接一个大模型”,而是:

1. 召回层:双路检索扩大覆盖面
2. 排序层:重排 + RRF 保证精确
3. 数据层:PDF 解析质量决定天花板

代码

• LawRAG-Agent
• rag_microencomic