Affected Component
Backend Service & API
Problem Description
知识检索 API POST/GET /knowledge-bases/:id/hybrid-search(internal/handler/knowledgebase.go:286 -> internal/application/service/knowledgebase_search.go:87 HybridSearch)只执行向量检索 + 关键词检索,无法检索知识图谱内容。即使传入配置了图谱抽取(ExtractConfig)的 KB,图谱的节点-关系结构也不参与召回。
这造成了一种能力不对等:同一个 KB 在对话流程(chat pipeline)里能用上图检索,但通过 API 却用不上。通过 API 集成 WeKnora 的外部应用(编排型 Agent、RAG 管线、第三方系统)无法获取图谱关联内容,写入侧为图谱抽取消耗的 LLM 成本在 API 侧没有产出。
此外,前端检索策略文案标注了"混合检索 + 知识图谱 / BM25 + 向量 + 知识图谱"(frontend/src/i18n/locales/zh-CN.ts:3125,3134 及其他语言),但该能力对 API 不可达,容易引起误解。
Proposed Solution
让知识检索 API 能够召回知识图谱内容:在 HybridSearch 中为配置了 ExtractConfig 的 KB 增加一条图检索路径。推荐方案:
- 方案 A(推荐):API 内联实体抽取。 当请求开启某个开关(如
enable_graph=true)且 KB 配置了 ExtractConfig 时,API 内部调 LLM 抽实体再 SearchNode。调用方使用简单,但会让检索 API 变重、强依赖生成模型可用性,改变 HybridSearch 当前"纯检索、不依赖生成模型"的定位。
Alternatives
- 方案 B(不推荐):API 请求体新增可选
entities 字段。 调用方自行抽取实体传入,HybridSearch 对配置了 ExtractConfig 的 KB 额外执行 SearchNode,将节点关联的 chunk 与向量/关键词结果融合(复用 search_entity.go 中的 filterSeenChunk + chunk2SearchResult 逻辑)。API 保持轻量、不内联 LLM 调用,符合检索与生成分离的原则。适合调用方本身在做 LLM 编排的场景。
Impact
Many users would benefit
Use Case
当外部应用通过 API 集成 WeKnora,且所绑定的 KB 启用了知识图谱抽取时,应用希望不仅能检索到向量/关键词匹配的 chunk,还能通过实体关系网络定位到内容——例如查询"与 X 相关的实体",即使某些 chunk 在向量空间与 query 不相似,只要在图上与 X 相连,也能被召回。目前这一能力只存在于对话流程内部,API 集成完全无法触达。
Additional Information
代码依据
knowledgebase_search.go:334-401 —— HybridSearch 只构造向量(:336)和关键词(:346)两类 RetrieveParams,全函数无 SearchNode / RetrieveGraphRepository 调用。
knowledgebase_search.go:181,263-267,329-333 —— 注释明确将 graph-only KB 归类为"非检索型";选 graph-only KB 作 primary 时搜索被降级、向量检索被跳过。
search_entity.go:75,106 —— 真正的图检索(SearchNode)只挂在 chat_pipeline 的 ENTITY_SEARCH 事件上,API 路径无法触达。
retriever_graph.go:16 —— SearchNode 签名要求传入 nodes []string(实体名),而非自由文本 query。
根因
图检索依赖实体抽取作为前置步骤:SearchNode 需要实体名数组,而非原始 query 文本。实体抽取(extract_entity.go,LLM 驱动)只存在于 chat_pipeline 事件流中,API 层没有这条链路,因此手里只有原始 QueryText,无法直接调用 SearchNode。
备注
- 生效前置条件:
NEO4J_ENABLE=true、KB ExtractConfig.Enabled=true。
- 图检索当前仅做节点名
CONTAINS 匹配(repository.go:180),PMI 加权遍历(graph.go:484 CalculateRelationshipWeights)未接入,召回质量可能受限,建议一并评估。
- 与另一 issue(
query_knowledge_graph Agent 工具未做真图谱检索)相关,二者都涉及图检索在 API/Agent 路径的缺失,可一并评估。
Confirmation
Affected Component
Backend Service & API
Problem Description
知识检索 API
POST/GET /knowledge-bases/:id/hybrid-search(internal/handler/knowledgebase.go:286->internal/application/service/knowledgebase_search.go:87HybridSearch)只执行向量检索 + 关键词检索,无法检索知识图谱内容。即使传入配置了图谱抽取(ExtractConfig)的 KB,图谱的节点-关系结构也不参与召回。这造成了一种能力不对等:同一个 KB 在对话流程(chat pipeline)里能用上图检索,但通过 API 却用不上。通过 API 集成 WeKnora 的外部应用(编排型 Agent、RAG 管线、第三方系统)无法获取图谱关联内容,写入侧为图谱抽取消耗的 LLM 成本在 API 侧没有产出。
此外,前端检索策略文案标注了"混合检索 + 知识图谱 / BM25 + 向量 + 知识图谱"(
frontend/src/i18n/locales/zh-CN.ts:3125,3134及其他语言),但该能力对 API 不可达,容易引起误解。Proposed Solution
让知识检索 API 能够召回知识图谱内容:在
HybridSearch中为配置了ExtractConfig的 KB 增加一条图检索路径。推荐方案:enable_graph=true)且 KB 配置了ExtractConfig时,API 内部调 LLM 抽实体再SearchNode。调用方使用简单,但会让检索 API 变重、强依赖生成模型可用性,改变HybridSearch当前"纯检索、不依赖生成模型"的定位。Alternatives
entities字段。 调用方自行抽取实体传入,HybridSearch对配置了ExtractConfig的 KB 额外执行SearchNode,将节点关联的 chunk 与向量/关键词结果融合(复用search_entity.go中的filterSeenChunk+chunk2SearchResult逻辑)。API 保持轻量、不内联 LLM 调用,符合检索与生成分离的原则。适合调用方本身在做 LLM 编排的场景。Impact
Many users would benefit
Use Case
当外部应用通过 API 集成 WeKnora,且所绑定的 KB 启用了知识图谱抽取时,应用希望不仅能检索到向量/关键词匹配的 chunk,还能通过实体关系网络定位到内容——例如查询"与 X 相关的实体",即使某些 chunk 在向量空间与 query 不相似,只要在图上与 X 相连,也能被召回。目前这一能力只存在于对话流程内部,API 集成完全无法触达。
Additional Information
代码依据
knowledgebase_search.go:334-401——HybridSearch只构造向量(:336)和关键词(:346)两类RetrieveParams,全函数无SearchNode/RetrieveGraphRepository调用。knowledgebase_search.go:181,263-267,329-333—— 注释明确将 graph-only KB 归类为"非检索型";选 graph-only KB 作 primary 时搜索被降级、向量检索被跳过。search_entity.go:75,106—— 真正的图检索(SearchNode)只挂在 chat_pipeline 的ENTITY_SEARCH事件上,API 路径无法触达。retriever_graph.go:16——SearchNode签名要求传入nodes []string(实体名),而非自由文本 query。根因
图检索依赖实体抽取作为前置步骤:
SearchNode需要实体名数组,而非原始 query 文本。实体抽取(extract_entity.go,LLM 驱动)只存在于 chat_pipeline 事件流中,API 层没有这条链路,因此手里只有原始QueryText,无法直接调用SearchNode。备注
NEO4J_ENABLE=true、KBExtractConfig.Enabled=true。CONTAINS匹配(repository.go:180),PMI 加权遍历(graph.go:484CalculateRelationshipWeights)未接入,召回质量可能受限,建议一并评估。query_knowledge_graphAgent 工具未做真图谱检索)相关,二者都涉及图检索在 API/Agent 路径的缺失,可一并评估。Confirmation