RAG 2.0：高级检索增强生成技术与GraphRAG实践

朴素RAG的困境

过去两年，"向量检索 + LLM"的朴素RAG方案被广泛应用。但随着场景复杂度提升，我们发现这种方案在以下场景表现糟糕：

• 多跳推理："A的老板的女儿在哪所学校？" — 需要跨多个文档
• 聚合查询："2024年我们公司在AI领域投入了多少？" — 需要整合多份报告
• 因果推断："为什么这次发布会失败？" — 需要理解事件链
• 对比分析："X方案和Y方案哪个更适合我们？" — 需要并行检索后综合

问题的根源在于：朴素RAG只能"找到相似的内容"，但无法"理解文档之间的关系"。

1. Agentic RAG：让Agent主导检索

Agentic RAG的核心思想：把检索过程交给一个能规划、反思、迭代的Agent来主导。

def agentic_rag(query):
    # Step 1: 任务分解
    sub_queries = planner.decompose(query)

    # Step 2: 并行检索
    results = []
    for sq in sub_queries:
        chunks = retriever.search(sq, top_k=5)
        results.append({"query": sq, "chunks": chunks})

    # Step 3: 自我评估
    if not evaluator.is_sufficient(results, query):
        # 不够则迭代
        new_queries = planner.refine(query, results)
        return agentic_rag_iter(new_queries, results)

    # Step 4: 生成
    return generator.synthesize(query, results)

2. Self-RAG：让模型自己决定检索时机

Self-RAG引入了三种特殊token：

• [Retrieve]：决定是否需要检索
• [Relevant]：判断检索结果是否相关
• [Supported]：判断生成是否被检索结果支持

这种设计让模型动态判断何时需要外部知识，避免不必要的检索调用，同时保证生成质量。

3. CRAG：纠正性RAG

Corrective RAG的关键创新是检索质量评估器：

1. 检索后先评估结果质量
2. 低质量结果触发查询重写
3. 必要时启用Web搜索作为补充
4. 多个来源的结果融合后再生成

4. GraphRAG：图谱驱动的革命

微软的GraphRAG提出了一个全新视角：不仅检索片段，更要构建文档的语义图谱。

构建阶段

# 1. 文档分块
chunks = chunk_documents(docs)

# 2. LLM抽取实体和关系
for chunk in chunks:
    entities = llm.extract_entities(chunk)
    relations = llm.extract_relations(chunk, entities)
    graph.add(entities, relations)

# 3. 社区检测（聚类）
communities = louvain(graph)

# 4. 社区摘要
for community in communities:
    summary = llm.summarize(community.entities, community.relations)
    community.summary = summary

查询阶段

GraphRAG提供两种查询模式：

• Local Query：针对具体实体的精确查询
• Global Query：基于社区摘要的全局推理

实战效果

在我们的法律咨询场景中，GraphRAG相比朴素RAG：
✅ 多跳问答准确率：62% → 89%（+27%）
✅ 全局推理准确率：45% → 82%（+37%）
✅ 复杂查询响应时间：3.2s → 4.5s（略有增加）

5. RAG 2.0 综合架构

真正的生产级RAG系统通常融合多种技术：

┌─────────────────────────────────────┐
│         Query Understanding         │
│    (重写 + 分类 + 子查询拆分)        │
└─────────────────┬───────────────────┘
                  ↓
┌─────────────────────────────────────┐
│        Hybrid Retrieval             │
│  ┌──────┬───────┬────────┬───────┐ │
│  │向量库│ BM25  │知识图谱 │ Web   │ │
│  └──────┴───────┴────────┴───────┘ │
└─────────────────┬───────────────────┘
                  ↓
┌─────────────────────────────────────┐
│         Reranking + Filtering       │
└─────────────────┬───────────────────┘
                  ↓
┌─────────────────────────────────────┐
│      Self-Evaluation (CRAG)         │
└─────────────────┬───────────────────┘
                  ↓
┌─────────────────────────────────────┐
│         Generation + Citation       │
└─────────────────────────────────────┘

6. 关键工程细节

① Chunk策略

不要简单按字符数分块。建议：

• 语义分块：基于句子边界 + 语义相似度
• 层次分块：保留章节、段落、句子的层次结构
• 重叠分块：相邻chunk保留10-20%的重叠

② Embedding选型

不同场景需要不同模型：

• 通用场景：bge-m3 或 jina-embeddings-v3
• 中文优化：bge-large-zh-v1.5
• 代码检索：jina-embeddings-v2-base-code

③ Reranker的重要性

向量检索召回后，用Cross-Encoder重排能显著提升精度。常用模型：bge-reranker-v2-m3。

7. 评估方法论

RAG系统必须有完整的评估体系：

• 检索评估：Recall@K, MRR, NDCG
• 生成评估：Faithfulness, Answer Relevancy
• 端到端评估：Ragas, TruLens

结语

RAG 2.0不是单一技术，而是一套系统工程。从查询理解到结果生成，每个环节都需要精心设计。GraphRAG的出现标志着RAG正式进入了"语义关系"时代，而这只是开始。

码龙寄语：技术发展的趋势永远是从"匹配"到"理解"，从"检索"到"推理"。RAG的未来，将和Agent深度融合，成为AGI不可或缺的记忆系统。