除了“向量”与“关键字”之外的多路召回方式

在真实的复杂企业业务中，只有两路是远远不够的。为了填补纯文本检索的盲区，业界目前主流的“多路召回”通常还会加入以下 4 支特种部队：

1. 知识图谱召回 (Knowledge Graph Recall / GraphRAG)

这是目前大厂 RAG 架构里最火的“第三路”，专门用来解决向量库“缺乏逻辑推理能力”的致命伤。

• 盲区场景（多跳推理）： 用户问“张三的上司负责什么项目？”。向量检索和 BM25 会被搞死，因为文档里可能一句是“李四是张三的 Leader”，另一句是“李四正在负责神盾局项目”。它们无法做 A $\rightarrow$ B $\rightarrow$ C 的连线。
• 做法： 在数据入库阶段，用大模型把文本里的实体（张三、李四、项目）和关系（上司、负责）抽出来，存进图数据库（如 Neo4j）。
• 召回方式： 用户提问时，将 Query 转化为 Cypher（图查询语言），沿着“张三 $\rightarrow$ 上司 $\rightarrow$ 负责的项目”这根线索，把图谱节点召回出来。

2. 结构化/元数据召回 (Structured Data / SQL Recall)

专门对付那些绝对不允许模糊匹配的硬性条件（比如时间、状态、权限），业界也叫 Text-to-SQL 或标量过滤。

• 盲区场景（精确限制）： 用户问“帮我找一下2023年Q3，状态为已完结的，由王五编写的设计文档。”
• 做法： 向量模型对数字和时间的敏感度极低，BM25 找出来的可能全是不相干的 2023 年的内容。
• 召回方式： 依赖你在切分文档时挂载的 Metadata（元数据）。在检索前，通过 LLM 意图识别，提取出 {"year": "2023", "status": "closed", "author": "王五"}，然后直接向 ES 或数据库发起精确过滤（Filter）查询。这一路召回往往作为其他召回的前置门神（只在特定范围内搜）。

3. 晚期交互模型召回 (Late Interaction / ColBERT)

这是对传统向量召回的一种“降维打击”式的升级。

• 盲区场景（细节丢失）： 传统的 Embedding（比如 BGE-m3）会把一整段话“压缩”成一个单一的向量（比如 768 维的数组）。就像把一整盆菜榨成汁，如果这段话很长，里面某个细微的知识点（比如某个冷门参数）的信息就会被稀释掉。
• 召回方式： 引入 ColBERT 模型。它不榨汁，而是把这句话里的每一个 Token（字词）都保留一个独立的向量。检索时，让 Query 里的每一个词去和文档里的每一个词做矩阵交叉匹配。它的精确度极高，介于粗排和精排之间。

4. 规则与正则召回 (Rule-based / Regex Recall)

这是程序员最熟悉、最古老，但在特定业务里召回率 100%、准确率 100% 的杀手锏。

• 盲区场景（特定编码与格式）： 用户搜“订单号 D10086-XYZ 的发货状态”。
• 召回方式： 不需要麻烦向量库也不需要 BM25。在网关层写死一段正则表达式 r'D\d{5}-[A-Z]{3}'。一旦命中，直接调取订单数据库拿数据。这一路的优先级永远是最高的（Top Priority），命中则直接截断后续检索。

---

总结多路召回的“兵种搭配”

在终极的架构图里，多路召回就像是海陆空联合作战：

1. 正则召回： 狙击手（百发百中，只打特定目标）。
2. 结构化召回： 结界师（先画个圈，比如“只准看 2023 年的数据”）。
3. 向量召回： 雷达兵（靠大意和语义去模糊扫描）。
4. BM25 召回： 缉毒犬（死死盯住关键词不放）。
5. 图谱召回： 侦探（顺藤摸瓜找关系）。

结合你们团队目前的业务场景，你需要处理的数据源中，是“复杂的业务逻辑关系（适合图谱）”多一些，还是“强依赖时间/分类等硬性筛选（适合结构化）”多一些？