graphrag-system-design

目录

• 工作流
• GraphRAG 模式选择
• 集成架构
• 输出模板

GraphRAG 系统设计

工作流

复制此检查清单，并逐步完成：

GraphRAG System Design Progress:
- [ ] Step 1: Analyze domain requirements
- [ ] Step 2: Select GraphRAG pattern
- [ ] Step 3: Choose technology stack
- [ ] Step 4: Design integration pipeline
- [ ] Step 5: Apply domain customizations
- [ ] Step 6: Define deployment strategy
- [ ] Step 7: Produce specification

步骤 1：分析领域需求

描述检索问题：查询复杂度（单跳还是多跳）、数据量和更新频率、合规性约束、延迟要求以及可解释性需求。判断图结构相较于扁平检索是否能带来价值——多跳推理、实体消歧和基于关系的上下文组装都是适合采用 GraphRAG 的明确信号。定义系统必须服务的用户角色和查询模式。

步骤 2：选择 GraphRAG 模式

使用 GraphRAG 模式选择指南选择核心检索架构。根据查询模式匹配相应模式：混合符号-向量模式适用于结构化与非结构化混合查询，按需子图模式适用于聚焦式上下文组装，基于社区的全局摘要模式适用于广泛的主题类查询。如需详细的模式说明，请参阅方法论参考。

步骤 3：选择技术栈

为每个架构层选择组件：图数据库、向量数据库、编排框架和 LLM 提供商。使用技术栈参考逐一比较各组件。关键决策包括：单系统还是多系统混合、托管还是可自托管、基于框架还是自定义流水线。还要考虑团队专业能力、预算限制和现有基础设施。

步骤 4：设计集成流水线

定义从数据摄取到生成的端到端数据流。核心流水线阶段：摄取（原始数据）-> 提取（实体和关系）-> 构建 KG（填充图）-> 建立索引（向量嵌入 + 图索引）-> 检索（图 + 向量混合搜索）-> 生成（使用图谱依据上下文的大模型）-> 引用（来自图路径的溯源信息）。设计查询路由逻辑，以确定何时使用图遍历、向量搜索或两者兼用。有关流水线设计的注意事项，请参阅方法论参考。

步骤 5：应用领域定制

根据特定领域的需求调整通用架构：本体选择（医疗领域使用 UMLS，金融领域使用 FIBO）、合规模式（HIPAA 访问控制、监管审计轨迹）以及领域检索模式（金融领域使用时态图，临床领域使用分层患者图）。有关特定领域的指导，请参阅领域模式参考。

步骤 6：定义部署策略

明确部署架构：图数据库的容量规划和集群配置、向量索引配置、缓存策略、批量或实时摄取、监控和可观测性以及扩展计划。为查询延迟、吞吐量和数据新鲜度定义性能 SLA。规划图维护工作：增量更新、模式演进和数据质量监控。

步骤 7：编写规范

使用输出模板汇总完整的系统设计规范。根据系统设计评分标准中的质量评估标准进行验证。确保所有组件端到端连通，且数据流、错误处理和回退策略都清晰明确。

GraphRAG 模式选择

模式	查询类型	机制	最适用于	权衡
Hybrid Symbol-Vector	结构化 + 语义混合	先按图类型／约束预筛选，再按嵌入相似度排序；或先进行宽泛的向量搜索，再通过图引导扩展	同时需要精确结构化查询和模糊语义搜索的系统；需要消歧实体的企业级问答	复杂度较高；需要同步图索引和向量索引；延迟取决于“先筛选后排序”或扩展策略
Subgraph-on-Demand	聚焦的多跳查询	构建特定于查询的临时子图，而不是查询单体图；提取相关邻域、嵌入并检索	需要聚焦上下文的实时应用；频繁更新的系统；对成本敏感的部署	构建子图时存在冷启动延迟；需要高效提取子图；上下文可能遗漏较远但相关的节点
Community-Based Global Summarization	宽泛的主题／全局查询	检测图中的社区／集群，为每个社区的摘要生成嵌入，检索相关社区后再深入查询实体详情；Microsoft GraphRAG 模式	宽泛的“X 是关于什么的？”查询；语料库级摘要；在大型知识库中进行主题探索	需要定期进行社区检测（批处理）；摘要可能丢失细节；社区边界可能将相关概念分隔开

选择模式

• 如果查询既需要“查找 X 类型的实体”，又需要“查找语义相似的内容” -> Hybrid Symbol-Vector
• 如果查询范围较聚焦，且上下文窗口成本很重要 -> Subgraph-on-Demand
• 如果查询范围宽泛、围绕主题或跨越整个语料库 -> Community-Based Global Summarization
• 如果需求涵盖多种模式 -> 结合多种模式，并使用查询路由器将查询分派到相应的检索路径

集成架构

完整的 GraphRAG 系统集成了四个核心组件层：

+------------------+     +------------------+     +----------------------+     +-----------+
|  Graph Database  |     |  Vector Database |     |  Orchestration       |     |    LLM    |
|  (Structure)     |<--->|  (Semantics)     |<--->|  Framework           |<--->| (Reason)  |
|                  |     |                  |     |                      |     |           |
|  Neo4j / Tiger   |     |  Pinecone /      |     |  LangChain /         |     |  GPT-4 /  |
|  Graph / Neptune |     |  Weaviate /      |     |  LlamaIndex /        |     |  Claude / |
|  / GraphDB       |     |  Qdrant / pgvec  |     |  LangGraph / Custom  |     |  Llama   |
+------------------+     +------------------+     +----------------------+     +-----------+
        |                        |                          |
        v                        v                          v
  Graph Traversal          Embedding Search           Pipeline Logic
  Multi-hop Paths          Semantic Ranking           Query Routing
  Schema Filtering         Similarity Scores          Context Assembly
  Provenance Chains        Hybrid Re-ranking          Citation Generation

关键集成决策：

• 图优先与文本优先管线：查询首先访问图（结构化筛选）还是向量存储（语义搜索）？
• 单系统与多系统：使用 Neo4j 向量索引（单系统），还是 Neo4j + Pinecone（多系统）？
• 框架与自定义：使用 LangChain/LlamaIndex 快速开发，还是使用自定义管线以获得最大控制权？
• 同步：更新期间如何保持图索引和向量索引一致？

输出模板

GRAPHRAG SYSTEM DESIGN SPECIFICATION
======================================

Project: [Project name]
Domain: [Target domain]
Date: [Date]
Author: [Author]

1. DOMAIN REQUIREMENTS
   Query Patterns: [Single-hop / Multi-hop / Thematic / Mixed]
   Data Volume: [Document count, entity count estimates]
   Update Frequency: [Real-time / Daily / Weekly / Batch]
   Latency Requirements: [p50, p95, p99 targets]
   Compliance: [HIPAA / GDPR / SOX / None]
   Explainability: [Required / Nice-to-have / Not needed]

2. GRAPHRAG PATTERN
   Primary Pattern: [Hybrid Symbol-Vector / Subgraph-on-Demand / Community-Based]
   Secondary Pattern: [If hybrid approach, specify]
   Query Router: [How queries are dispatched to retrieval paths]
   Rationale: [Why this pattern fits the requirements]

3. TECHNOLOGY STACK
   Graph Database: [Product, version, deployment mode]
     Justification: [Why this choice]
   Vector Database: [Product, version, deployment mode]
     Justification: [Why this choice]
   Orchestration: [Framework or custom pipeline]
     Justification: [Why this choice]
   LLM Provider: [Model, API or self-hosted]
     Justification: [Why this choice]
   Supporting Infrastructure: [Cache, queue, monitoring tools]

4. INTEGRATION PIPELINE
   Ingestion:
     - Source types: [Documents, APIs, databases]
     - Processing: [Chunking strategy, metadata extraction]
   Extraction:
     - Entity extraction: [Method, model, confidence threshold]
     - Relation extraction: [Method, schema enforcement]
   Knowledge Graph Build:
     - Schema: [Node types, edge types, properties]
     - Population: [Batch / streaming, deduplication strategy]
   Indexing:
     - Graph indices: [Index types, query optimization]
     - Vector indices: [Embedding model, dimension, index type]
   Retrieval:
     - Graph retrieval: [Traversal strategy, depth limits]
     - Vector retrieval: [Top-k, similarity threshold]
     - Hybrid fusion: [How graph and vector results combine]
   Generation:
     - Context assembly: [How retrieved data becomes LLM context]
     - Prompt template: [Structure for graph-grounded generation]
   Citation:
     - Provenance: [How sources are tracked and surfaced]

5. DOMAIN CUSTOMIZATIONS
   Ontology: [Domain ontology or taxonomy used]
   Compliance Controls: [Access control, audit, encryption]
   Domain-Specific Patterns: [Temporal graphs, layered architecture, etc.]

6. DEPLOYMENT STRATEGY
   Infrastructure: [Cloud provider, regions, HA configuration]
   Scaling Plan: [Graph DB scaling, vector DB scaling, LLM scaling]
   Monitoring: [Metrics, alerts, dashboards]
   Maintenance: [Graph update strategy, schema evolution plan]

7. PERFORMANCE TARGETS
   Query Latency: [p50, p95, p99]
   Throughput: [Queries per second]
   Freshness: [Time from data change to queryable]
   Accuracy: [Retrieval precision/recall targets]

8. RISK AND MITIGATION
   - [Risk 1]: [Mitigation strategy]
   - [Risk 2]: [Mitigation strategy]
   - [Risk 3]: [Mitigation strategy]

NEXT STEPS:
- Build proof-of-concept with sample data
- Benchmark retrieval quality against baseline RAG
- Load test with production-scale data
- Iterate schema and retrieval strategy based on evaluation