[Feature]: 将知识图谱抽取后端适配为 LightRAG（替代当前模型强耦合实现），提升可用性与可配置性

相关组件

其他

问题描述

知识图谱

感谢贵公司产品发布了这么优秀的产品，我大概整理了图谱抽取策略优化上支持更多配置选项

但是在其工程上其实现方式强依赖模型，与社区开源的HKUDS/LightRAG处理策略相比工程上达不到可用级别

实际测试：无法生成图谱信息

下面是我认为这个产品比较优秀的功能，它们与LightRAG高度重合，很希望后台换成LightRAG

业务兼容策略

实体描述信息维护

增强实体的描述偏差问题，增强召回率

实体关系处理

对实体之间的链接关系补齐，增强模型对未知语料的识别效果

建议的解决方案

希望新增/调整的能力（功能请求）

• 后端替换/新增实现：将图谱抽取与构建模块的后端实现切换为（或提供可选项）基于 LightRAG 的处理策略与数据结构。
• 解耦模型依赖：抽取流程应尽量与具体大模型实现解耦，模型仅作为可插拔的“能力提供者”（prompt/函数调用/结构化输出）。
• 增强可配置性：把抽取粒度、Schema/本体约束、去重/合并策略、置信度阈值、边类型规则、实体规范化等配置项沉淀为统一配置（CLI/JSON/YAML均可）。
• 工程可用级别：提供可复现的最小示例与稳定的输出协议（nodes/edges/properties/metadata），保证在常见数据集上能够持续产出图谱。

建议的实现方案（可选其一或组合）

1. 双后端并存：保留现有实现，同时新增 backend=LightRAG 开关，方便灰度与对比。
2. 统一抽取接口：抽象 GraphExtractor / GraphBuilder 接口，当前实现与 LightRAG 作为两个实现类，配置驱动选择。
3. 标准化输出协议：定义稳定的图谱中间表示（IR），避免后续检索、可视化、存储与推理模块被某个模型输出格式牵制。

替代方案

No response

优先级

高 - 对工作流程很重要

使用场景

Description（描述）
目前知识图谱抽取链路在工程实现上与特定模型绑定较深，导致在一些实际场景中难以稳定产出图谱结果（我这边的端到端测试中未能生成任何可用的图谱节点/边/属性）。与此同时，现有产品里若干优秀能力（如：可配置的抽取策略、增量更新/复用、面向检索的图结构组织等）与社区方案 HKUDS/LightRAG 的设计高度一致，但当前落地方式在工程可用性上仍有明显差距。

补充信息

No response

确认事项

• 我已经搜索了现有的 issues，确认这是一个新的功能请求
• 我理解这个功能请求可能需要讨论和评估

The issue names no files, tests, or entry points. Start by locating the existing knowledge-graph extraction backend and its model-coupling points, then review how a LightRAG-compatible backend and configuration could fit; done should include a selectable implementation, stable nodes/edges/properties/metadata output, and a reproducible example.