Temporal-GraphRAG：让 RAG 系统拥有时间意识

一封来自财报电话会议的追问

2023年第二季度，某科技公司的投资者在业绩电话会议上追问管理层："你们在2022年下半年的研发投入，与同期的竞争对手相比，到底处于什么水平？"这是一个典型的时间敏感型问题——答案不仅取决于"是什么"，更取决于"发生在什么时候"。

传统的 RAG（检索增强生成）系统，面对这个问题时会犯迷糊。它把2022年7月的事实和2023年6月的事实混在一起用向量相似度去匹配，却无法区分"同一件事在不同时间点的状态变化"。这就像一位记忆力很好的助手，能告诉你所有关于某公司的事实，却记不住这些事实发生的时间顺序。

Temporal-GraphRAG（TG-RAG）正是为了解决这个痛点而生。

背景：从 GraphRAG 到时间感知

GraphRAG（以微软开源项目为代表）通过构建知识图谱来改进纯向量检索，它将文档中的实体和关系抽取出来，形成图结构，从而让 RAG 具备了"关系推理"能力。然而，GraphRAG 依然忽略了知识的本质特性——知识是随时间演化的。

同一个公司、同一类产品、同一个市场，在不同时间点可能呈现完全不同的面貌。财报数据的增减、人事任免的变动、技术里程碑的达成……这些信息都带有天然的时间标签。一套不考虑时间的知识检索系统，在处理时间敏感型问题时注定力不从心。

TG-RAG 来自学术界研究团队，论文发表于 arXiv（arXiv:2510.13590），第一作者为 Jiale Han。团队构建了一个金融领域的时间敏感问答数据集 ECT-QA（收录在 HuggingFace），包含24家公司2020-2024年的480份财报电话会议记录，以及1105个精心设计的时间相关问答对，作为基准评测数据集。

核心原理：双层时间图谱

TG-RAG 的核心创新在于将外部语料库建模为双层时间图谱（Bi-level Temporal Graph）：

第一层：时间知识图谱（Temporal Knowledge Graph）。这是对原始文档内容的结构化表示，节点代表实体（公司、产品、人物、事件等），边代表实体间关系。每条边都带有时间戳，精确记录该关系存在的时间范围。例如，"A公司在2022年Q3收购了B公司"这条信息，会在图中生成一条带有明确时间范围标注的边。

第二层：层次时间图谱（Hierarchical Time Graph）。这是对时间维度本身的抽象建模，按年→季度→月→周→日逐级组织。在每一级时间节点上，TG-RAG 会自动生成多粒度时间摘要（Multi-granularity Temporal Summaries），捕捉该时间段内的关键事件和宏观趋势。这使得系统既能回答精确到某一天的问题，也能回答"2023年整年行业发生了什么"这类抽象问题。

查询时，TG-RAG 支持三种模式：Local 模式（精确查找特定时间点的事实）、Global 模式（跨时间范围的趋势分析）、Naive 模式（传统向量检索基线，用于对比）。系统会动态检索符合时间和语义范围的时间子图，结合 LLM 生成答案。

技术架构与代码实现

项目使用纯 Python 实现，核心依赖包括：

• LLM 调用：支持 OpenAI（GPT 系列）、Google Gemini、Azure OpenAI、Amazon Bedrock 和本地 Ollama，通过统一 client 封装多provider
• 向量数据库：使用 nano-vectordb（轻量级向量库）和 hnswlib（HNSW 近似最近邻检索）
• 图结构：基于 NetworkX 构建内存图，可选 Neo4j 持久化存储
• 异步处理：全程异步 I/O，使用 aiohttp + nest-asyncio，支持批量文档插入

代码结构清晰，分为以下模块：

• temporal/normalization.py + normalizer.py：时间标准化，将各种格式的时间表达（"2023年Q3"、"last quarter"、"in mid-2023"等）归一化为结构化时间戳
• extraction/extractor.py：使用 LLM 从文档中抽取实体和关系，基于 prompts.yaml 中定义的 prompt 模板
• core/building.py：构建时间图谱的核心逻辑，包括分块、实体抽取、关系抽取、社区检测、时间摘要生成
• core/querying.py：查询处理，包括 Local/Global 模式下的子图检索和答案生成
• storage/：多种存储后端（JSON KV、HNSW 向量库、Neo4j 图数据库）

配置通过 YAML 文件管理，支持调整实体类型、LLM 模型、分块策略、检索参数等。项目代码质量较高，有完整的类型注解（types.py）、日志管理、成本追踪等工程化实践。

快速上手

# 克隆并安装
git clone https://github.com/hanjiale/Temporal-GraphRAG.git
cd Temporal-GraphRAG
python3.12 -m venv venv && source venv/bin/activate
pip install -r requirements.txt

# 配置 API Key
export OPENAI_API_KEY="sk-..."    # 用于 embedding
export GOOGLE_API_KEY="..."        # 用于 LLM（Gemini）

# 构建时间知识图谱
python build_graph.py --output_dir ./graph_output --corpus_path ./my_documents/

# 查询（Local 模式：精确事实）
python query_graph.py --question "该公司2023年Q1的营收是多少？" --mode local

# 查询（Global 模式：趋势分析）
python query_graph.py --question "2022-2024年该公司经历了哪些重大战略变化？" --mode global

Python API 方式：

from tgrag import create_temporal_graphrag_from_config

graph_rag = create_temporal_graphrag_from_config(
    config_path="tgrag/configs/config.yaml",
    config_type="building"
)
graph_rag.insert([{"title": "财报2024Q1", "doc": "本季度营收同比增长15%..."}])
answer = graph_rag.query("Q1营收增长了多少？", mode="local")

当前局限与挑战

API 成本不容忽视：每次构建图谱都需要调用 LLM 进行实体/关系抽取，时间摘要生成也依赖 LLM 调用。在 ECT-QA 这样的完整语料上跑一遍，成本可能达到数十美元。增量更新（--incremental）是一个缓解方案，但依然无法完全消除 LLM 调用的必要性。

时间标准化是难点：项目的时间标准化模块（temporal/normalization.py）虽已覆盖常见格式，但对于中文非标准表达（如"去年Q3"、"上上个月"）和模糊时间（如"近期"、"早些时候"）的处理能力仍有限。在实际部署到特定领域时，可能需要针对领域特点扩充时间标准化规则。

不支持中文语料的最佳实践：项目 prompt 默认针对英文设计（实体类型如"financial concept"、"business segment"），直接迁移到中文场景需要调整 prompt 和实体类型定义，中文的时间表达形式也远比英文复杂。

评测基准较为单一：ECT-QA 仅覆盖金融财报领域，对于医疗记录、法律文档、历史新闻等同样具有强时间特性但文本结构差异大的领域，TG-RAG 的泛化效果尚待验证。

行业意义与未来方向

TG-RAG 的出现，填补了 RAG 系统在时间建模方面的空白。它不仅仅是一个技术方案，更代表了一种趋势：RAG 系统的下一阶段竞争，将从"检索精度"转向"知识理解深度"——包括时间、因果、多模态等多个维度。

从增长曲线看，时间敏感型 RAG 在金融分析、医疗记录检索、法律文档搜索、历史研究辅助等垂直领域都有明确的落地价值。增量更新能力的支持，也让系统可以随时间推移持续吸收新知识，而无需全量重建。

如果你是 AI 开发者，TG-RAG 的代码结构值得一读——它展示了一个工程化程度较高的学术开源项目如何组织异步 LLM 调用、多后端存储和多粒度摘要生成。如果你是 AI 爱好者，这个项目背后的思考方式值得关注：好的 AI 系统，不仅要"知道答案"，更要"知道答案的时间背景"。