只取向量检索，为什么专名和问题老对不上

问知识库：「配置项 max.pool.size 默认值是多少？」

向量检索返回了讲连接池原理的三段话，都没有这个精确字符串；关键词检索一命中，chunk 里清楚写着 max.pool.size=32。

反过来，问「怎么降低检索延迟」——用户没提「混合检索」「rerank」这些词，向量检索能命中讲 RAG 优化的段落；纯 BM25 可能被「延迟」这个词带到网络运维文档里去。

单一检索路各有盲区；生产知识库几乎总是混合的。

#两路检索各擅长什么

有谷 RAG 服务（LightRAG 系）支持多种 mode：naive 纯向量、local / global 图谱、hybrid、mix 等。Agent 工具 query_knowledge_base 默认走 mix——在多数知识库问答场景里，语义 + 结构信息互补最好。

Backend RAGClient.retrieve() 把 tenant_id（知识库 UUID）、可选 document_uuid（限定单文档）、top_k、是否 enable_rerank 等参数传给 RAG 服务；返回 chunks、entities、relationships、references，再格式化为 citation 证据块。

#融合：不是简单拼两个列表

两路各取 top-50，直接合并会有大量重复 chunk，且分数尺度不同。常见做法：

• RRF（Reciprocal Rank Fusion） — 按排名融合，不依赖原始分数标度
• 加权合并 — 向量分 + BM25 分归一化后加权（权重可按库调优）

融合后的候选集仍可能把「相关但非最优」的 chunk 排在前面——尤其问法短、库很大时。

#Rerank：精排是可选的第二道门

enable_rerank 默认 false，与 RAG 服务一致；打开后，对融合候选（例如 top-50）用交叉编码模型（如有谷部署的 qwen3-rerank 类服务）重新打分，再取 top-k 给模型。

Rerank 的代价是延迟和算力；收益是：

• 把「语义沾边但答非所问」的 chunk 压下去
• 把含精确答案的短 chunk 顶上来

适合法规、手册、API 文档这类答案在某一两段里、周围大量相似表述的库。纯叙事性文档，向量 + 融合往往已够。

#和入库 chunk 质量的关系

检索再好，chunk 切错也救不回来：

• 合同按条款切，「赔偿上限」和「例外」在同一 leaf chunk
• Excel带表头坐标，max.pool.size 若被硬切成数字孤岛，BM25 也找不到列语义
• 网页没清洗，「相关阅读」chunk 在向量空间里和正文很像，融合后仍可能进 top-k

混合检索是检索层的互补；索引层仍要格式专用解析。两者乘在一起，不是互相替代。

#单文档 vs 全库

阅读模式下传 document_uuid，检索限定在当前文档——混合逻辑不变，搜索空间变小，专名命中更稳。

全库问答不传 document 限制，tenant 级检索；MCP 和 Open API 同样走 tenant_id = 知识库 UUID。

#图谱 entity 给 Agent 什么额外信息

mix / hybrid 返回的 entities、relationships 会写进工具文本（对齐 LightRAG 的 kg_query_context 结构），帮助模型理解「A 公司 ─收购→ B 产品」这类关系——不是替代 chunk citation，而是辅助综合多段证据。

模型仍必须用 [citation:N] 标注最终结论依据的 chunk；图谱边本身不当作可点击出处。

#调参时的实用建议

小库（< 1000 chunk） — naive 或 hybrid 即可，rerank 收益有限。

中英混排、专名多 — 提高关键词路权重或启用 mix；embedding 模型对英文代号、版本号不一定友好。

法规 / 标书 — 优先保证条款级 chunk，再开 rerank；否则精排是在一堆碎块里选相对不差的那块。

Latency 敏感 — top_k 从 20 降到 10，rerank 候选从 50 降到 30；Agent 多轮工具调用时检索延迟会累加。

#在问答链路中的位置

用户问题 → AG-UI Agent → query_knowledge_base → RAG hybrid/mix → citation_sources → 模型生成 → 用户点击出处

入库进度 SSE 保证 chunk 进索引可观测；混合检索保证 chunk 进 context 更准；引用链保证用户能验证。

向量检索让知识库「懂意思」；关键词和图谱让知识库「认字眼」。有谷默认把两路都打开，是因为真实问题里，用户两种问法都会用——只押一条路，产品会在专名和 paraphrase 上轮流翻车。