DataOps Platform 已经具备以下知识库基础:
BusinessDomain、DataFlow、DataMeta、数据标准、标签和血缘,
是治理对象结构和关系的源真相。governance_documents、
governance_chunks 和 governance_sync_jobs。当前缺口不是再建设一套独立知识库控制面,而是完成:
LlamaIndex 与 Haystack 位于相同的通用 RAG 框架层。平台选择 LlamaIndex 作为 唯一主框架;LightRAG 不作为第二套通用框架,而作为隔离的图增强检索引擎。
DataOpsVectorStore、DataOpsNodeMapper 和治理图 Retriever,适配已有
PostgreSQL/pgvector 与 Neo4j 数据模型。only_need_context 语义,最终
DeepSeek 提示词、回答、引用和无答案判断由 DataOps 生成。GovernanceGraphRetriever 只读查询。lightrag-neo4j 服务和卷。生产环境可以使用
独立 Neo4j 数据库/集群,但不能只依赖与治理图共库的标签约定作为安全边界。flowchart LR
USER["管理员 / 编辑者 / 查看者"] --> API["DataOps Knowledge API"]
API --> ACCESS["KnowledgeAccessContext\n角色 + 业务域 + 对象范围"]
ACCESS --> ROUTER["确定性 Query Router"]
subgraph Standard["LlamaIndex 主链路(Flask 内)"]
EXACT["精确 / 别名 / 词法 Retriever"]
VECTOR["DataOps pgvector Retriever"]
GRAPH["治理 Neo4j Retriever"]
FUSION["RRF 融合"]
end
ROUTER --> EXACT
ROUTER --> VECTOR
ROUTER --> GRAPH
EXACT --> FUSION
VECTOR --> FUSION
GRAPH --> FUSION
ROUTER -->|关系 / 全局 / 多跳| LRCLIENT["LightRAG Client"]
LRCLIENT --> LRSVC["LightRAG 内部侧车"]
LRSVC --> LRPG["独立 LightRAG PostgreSQL"]
LRSVC --> LRNEO["独立 LightRAG Neo4j 投影"]
FUSION --> MERGE["候选合并 + 来源重新授权"]
LRCLIENT --> MERGE
MERGE --> RERANK["Cross-Encoder Reranker"]
RERANK --> QA["DataOps Answer Synthesizer"]
QA --> DEEPSEEK["DeepSeek"]
QA --> RESULT["答案 + 对象 UID + 版本 + 引用"]
| 能力 | 责任组件 | 源真相 |
|---|---|---|
| 用户、角色、业务域授权 | DataOps RBAC | PostgreSQL |
| 治理对象与血缘 | DataOps 治理 API | Neo4j |
| 规范化文档与分块 | DataOps Knowledge Indexer | PostgreSQL |
| 向量及 embedding 版本 | DataOps Knowledge Indexer | PostgreSQL/pgvector |
| 主检索编排 | LlamaIndex 适配层 | 无独立源数据 |
| 图增强抽取与检索 | LightRAG | 可重建投影 |
| LightRAG 图 | LightRAG | 独立 Neo4j |
| 候选融合、重排和无答案判断 | DataOps Retrieval Pipeline | 运行时 |
| 最终生成与引用 | DataOps Answer Synthesizer | PostgreSQL 来源映射 |
| 同步和补偿 | DataOps Outbox + Projection Worker | PostgreSQL |
| 评测、指标与查询审计 | DataOps | PostgreSQL/监控系统 |
LlamaIndex 只使用以下抽象能力:
governance_chunks 映射为带稳定 node_id 和 metadata 的 Node;以下能力不由 LlamaIndex 持久化或决定:
LightRAG 使用官方服务接口或由 DataOps 封装的兼容网关,接口至少包含:
mix/hybrid 模式查询上下文;所有调用必须携带:
correlation_id;object_uid、object_version 和 content_hash;LightRAG 返回内容只有满足以下条件才可使用:
KnowledgeAccessContext 内;新增持久化的用户—业务域授权关系。管理员可以拥有 * 范围;其他用户只读取被
授予的业务域。角色权限决定“能否使用知识库”,业务域授权决定“能看到什么”。
治理正文、附件、LightRAG 实体描述和关系说明全部视为不可信数据。最终系统 Prompt 明确禁止执行证据文本中的指令;候选内容只放在结构化 evidence 区域。
stateDiagram-v2
[*] --> pending
pending --> canonical_ready: 文档、分块、embedding 成功
pending --> failed: 构建或 embedding 失败
canonical_ready --> projecting: 创建 LightRAG 投影任务
projecting --> ready: LightRAG 投影完成并核验
projecting --> degraded: LightRAG 超时或失败
degraded --> projecting: 有上限重试 / 人工重放
ready --> stale: 源版本或模型 profile 变化
stale --> pending: 重建新 generation
graph_retrieval=degraded。search 仍返回来源;ask 返回模型不可用状态和已检索来源,
不伪造答案。拒绝。两者会引入重复 Document、Retriever、Pipeline、回调和配置抽象,增加维护 和排障成本。
首期拒绝。LightRAG 的实体/关系抽取模型与现有治理模型不同,直接写入会破坏源 真相、约束和审计边界。
拒绝。LightRAG 无法替代 DataOps 的业务域授权、版本核验、统一引用和无答案 策略。
拒绝。外部模型和图抽取延迟不应扩大治理写事务;使用 Outbox 和可重建投影实现 最终一致。
正面结果:
成本与限制:
详细实施工作包、Schema、API、验收门槛和回滚点见 LlamaIndex + LightRAG 数据治理知识库实施计划。