关键组件

1. 索引（Indexing） 📑：将非结构化文档（PDF/Word等）分割为片段，通过嵌入模型转换为向量数据。
2. 检索（Retrieval） 🔍️：基于查询语义，从向量数据库召回最相关的文档片段（Context）。
3. 生成（Generation） ✨：将检索结果作为上下文输入LLM，生成自然语言响应。

静态知识局限	实时检索外部知识库，支持动态更新
幻觉（Hallucination）	基于检索内容生成，错误率降低
领域专业性不足	引入领域特定知识库（如医疗/法律）
数据隐私风险	本地化部署知识库，避免敏感数据泄露

数据加载

PyMuPDF4LLM	PDF→Markdown转换，OCR+表格识别	科研文献、技术手册	开源免费，GPU加速
TextLoader	基础文本文件加载	纯文本处理	轻量高效
DirectoryLoader	批量目录文件处理	混合格式文档库	支持多格式扩展
Unstructured	多格式文档解析	PDF、Word、HTML等	统一接口，智能解析
FireCrawlLoader	网页内容抓取	在线文档、新闻	实时内容获取
LlamaParse	深度PDF结构解析	法律合同、学术论文	解析精度高，商业API
Docling	模块化企业级解析	企业合同、报告	IBM生态兼容
Marker	PDF→Markdown，GPU加速	科研文献、书籍	专注PDF转换
MinerU	多模态集成解析	学术文献、财务报表	集成LayoutLMv3+YOLOv8

Unstructured

• 支持多种文档格式：PDF、Word、Excel、HTML、Markdown等
• 统一的API接口，无需为不同格式编写不同代码

文本分块

大多数嵌入模型都基于 Transformer 编码器。其工作流程大致如下：

1. 分词 (Tokenization): 将输入的文本块分解成一个个 token。
2. 向量化 (Vectorization): Transformer 为每个 token 生成一个高维向量表示。
3. 池化 (Pooling): 通过某种方法（如取[CLS]1位的向量、对所有token向量求平均mean pooling等），将所有 token 的向量压缩成一个单一的向量，这个向量代表了整个文本块的语义。

在这个压缩过程中，信息损失是不可避免的。一个768维的向量需要概括整个文本块的所有信息。文本块越长，包含的语义点越多，这个单一向量所承载的信息就越稀释，导致其表示变得笼统，关键细节被模糊化，从而降低了检索的精度。

• 固定大小分块CharacterTextSplitter

1. 按段落分割：CharacterTextSplitter 采用默认分隔符 "\n\n"，使用正则表达式将文本按段落进行分割，通过 _split_text_with_regex 函数处理。
2. 智能合并：调用继承自父类的 _merge_splits 方法，将分割后的段落依次合并。该方法会监控累积长度，当超过 chunk_size 时形成新块，并通过重叠机制（chunk_overlap）保持上下文连续性，同时在必要时发出超长块的警告。

“段落感知的自适应分块”，块大小会根据段落边界动态调整

• 递归字符分块RecursiveCharacterTextSplitter

1. 寻找有效分隔符: 从分隔符列表中从前到后遍历，找到第一个在当前文本中存在的分隔符。如果都不存在，使用最后一个分隔符（通常是空字符串 ""）。

2. 切分与分类处理

   : 使用选定的分隔符切分文本，然后遍历所有片段：

   • 如果片段不超过块大小: 暂存到 _good_splits 中，准备合并

   • 如果片段超过块大小

     :

     • 首先，将暂存的合格片段通过 _merge_splits 合并成块
     • 然后，检查是否还有剩余分隔符：
       • 有剩余分隔符: 递归调用 _split_text 继续分割
       • 无剩余分隔符: 直接保留为超长块

3. 最终处理: 将剩余的暂存片段合并成最后的块

• 语义分块SemanticChunker

1. 句子分割 (Sentence Splitting): 首先，使用标准的句子分割规则（例如，基于句号、问号、感叹号）将输入文本拆分成一个句子列表。
2. 上下文感知嵌入 (Context-Aware Embedding): 这是 SemanticChunker 的一个关键设计。该分块器不是对每个句子独立进行嵌入，而是通过 buffer_size 参数（默认为1）来捕捉上下文信息。对于列表中的每一个句子，这种方法会将其与前后各 buffer_size 个句子组合起来，然后对这个临时的、更长的组合文本进行嵌入。这样，每个句子最终得到的嵌入向量就融入了其上下文的语义。
3. 计算语义距离 (Distance Calculation): 计算每对相邻句子的嵌入向量之间的余弦距离。这个距离值量化了两个句子之间的语义差异——距离越大，表示语义关联越弱，跳跃越明显。
4. 识别断点 (Breakpoint Identification): SemanticChunker 会分析所有计算出的距离值，并根据一个统计方法（默认为 percentile）来确定一个动态阈值。例如，它可能会将所有距离中第95百分位的值作为切分阈值。所有距离大于此阈值的点，都被识别为语义上的“断点”。
5. 合并成块 (Merging into Chunks): 最后，根据识别出的所有断点位置，将原始的句子序列进行切分，并将每个切分后的部分内的所有句子合并起来，形成一个最终的、语义连贯的文本块。

断点识别方法 (breakpoint_threshold_type)

如何定义“显著的语义跳跃”是语义分块的关键。SemanticChunker 提供了几种基于统计的方法来识别断点：

• percentile (百分位法 - 默认方法):
  • 逻辑: 计算所有相邻句子的语义差异值，并将这些差异值进行排序。当一个差异值超过某个百分位阈值时，就认为该差异值是一个断点。
  • 参数: breakpoint_threshold_amount (默认为 95)，表示使用第95个百分位作为阈值。这意味着，只有最显著的5%的语义差异点会被选为切分点。
• standard_deviation (标准差法):
  • 逻辑: 计算所有差异值的平均值和标准差。当一个差异值超过“平均值 + N * 标准差”时，被视为异常高的跳跃，即断点。
  • 参数: breakpoint_threshold_amount (默认为 3)，表示使用3倍标准差作为阈值。
• interquartile (四分位距法):
  • 逻辑: 使用统计学中的四分位距（IQR）来识别异常值。当一个差异值超过 Q3 + N * IQR 时，被视为断点。
  • 参数: breakpoint_threshold_amount (默认为 1.5)，表示使用1.5倍的IQR。
• gradient (梯度法):
  • 逻辑: 这是一种更复杂的方法。它首先计算差异值的变化率（梯度），然后对梯度应用百分位法。对于那些句子间语义联系紧密、差异值普遍较低的文本（如法律、医疗文档）特别有效，因为这种方法能更好地捕捉到语义变化的“拐点”。
  • 参数: breakpoint_threshold_amount (默认为 95)。

向量嵌入

MTEB (Massive Text Embedding Benchmark) 是一个由 Hugging Face 维护的、全面的文本嵌入模型评测基准。它涵盖了分类、聚类、检索、排序等多种任务，并提供了公开的排行榜，为评估和选择嵌入模型提供了重要的参考依据。

在查看榜单时，除了分数，你还需要关注以下几个关键维度：

1. 任务 (Task) ：对于 RAG 应用，需要重点关注模型在 Retrieval (检索) 任务下的排名。
2. 语言 (Language) ：模型是否支持你的业务数据所使用的语言？对于中文 RAG，应选择明确支持中文或多语言的模型。
3. 模型大小 (Size) ：模型越大，通常性能越好，但对硬件（显存）的要求也越高，推理速度也越慢。需要根据你的部署环境和性能要求来权衡。
4. 维度 (Dimensions) ：向量维度越高，能编码的信息越丰富，但也会占用更多的存储空间和计算资源。
5. 最大 Token 数 (Max Tokens) ：这决定了模型能处理的文本长度上限。这个参数是你设计文本分块（Chunking）策略时必须考虑的重要依据，块大小不应超过此限制。
6. 得分与机构 (Score & Publisher) ：结合模型的得分排名和其发布机构的声誉进行初步筛选。知名机构发布的模型通常质量更有保障。
7. 成本 (Cost) ：如果是使用 API 服务的模型，需要考虑其调用成本；如果是自部署开源模型，则需要评估其对硬件资源的消耗（如显存、内存）以及带来的运维成本。

多模态嵌入

向量数据库

1. 高效的相似性搜索：这是向量数据库最重要的功能。它利用专门的索引技术（如 HNSW, IVF），能够在数十亿级别的向量中实现毫秒级的近似最近邻（ANN）查询，快速找到与给定查询最相似的数据。
2. 高维数据存储与管理：专门为存储高维向量（通常维度成百上千）而优化，支持对向量数据进行增、删、改、查等基本操作。
3. 丰富的查询能力：除了基本的相似性搜索，还支持按标量字段过滤查询（例如，在搜索相似图片的同时，指定年份 > 2023）、范围查询和聚类分析等，满足复杂业务需求。
4. 可扩展与高可用：现代向量数据库通常采用分布式架构，具备良好的水平扩展能力和容错性，能够通过增加节点来应对数据量的增长，并确保服务的稳定可靠。
5. 数据与模型生态集成：与主流的 AI 框架（如 LangChain, LlamaIndex）和机器学习工作流无缝集成，简化了从模型训练到向量检索的应用开发流程。

向量数据库通常采用四层架构，通过以下技术手段实现高效相似性搜索：

1. 存储层：存储向量数据和元数据，优化存储效率，支持分布式存储
2. 索引层：维护索引算法（HNSW、LSH、PQ等），创建和优化索引，支持索引调整
3. 查询层：处理查询请求，支持混合查询，实现查询优化
4. 服务层：管理客户端连接，提供监控和日志，实现安全管理

主要技术手段包括：

• 基于树的方法：如 Annoy 使用的随机投影树，通过树形结构实现对数复杂度的搜索
• 基于哈希的方法：如 LSH（局部敏感哈希），通过哈希函数将相似向量映射到同一“桶”
• 基于图的方法：如 HNSW（分层可导航小世界图），通过多层邻近图结构实现快速搜索
• 基于量化的方法：如 Faiss 的 IVF 和 PQ，通过聚类和量化压缩向量

Milvus

https://datawhalechina.github.io/all-in-rag/#/chapter3/09_milvus

索引优化

上下文扩展

在RAG系统中，常常面临一个权衡问题：使用小块文本进行检索可以获得更高的精确度，但小块文本缺乏足够的上下文，可能导致大语言模型（LLM）无法生成高质量的答案；而使用大块文本虽然上下文丰富，却容易引入噪音，降低检索的相关性。为了解决这一矛盾，LlamaIndex 提出了一种实用的索引策略——句子窗口检索（Sentence Window Retrieval）]。该技术巧妙地结合了两种方法的优点：它在检索时聚焦于高度精确的单个句子，在送入LLM生成答案前，又智能地将上下文扩展回一个更宽的“窗口”，从而同时保证检索的准确性和生成的质量。

句子窗口检索的思想可以概括为：为检索精确性而索引小块，为上下文丰富性而检索大块。

结构化索引

其原理是在索引文本块的同时，为其附加结构化的元数据（Metadata）。这些元数据可以是任何有助于筛选和定位信息的标签，例如：

• 文件名
• 文档创建日期
• 章节标题
• 作者
• 任何自定义的分类标签

1. 创建两个独立的向量索引：
   • 摘要索引（用于路由）：为每个Excel工作表（例如，“1994年电影数据”）创建一个非常简短的摘要性Document，例如：“此文档包含1994年的电影信息”。然后，用所有这些摘要文档构建一个轻量级的向量索引。这个索引的唯一目的就是充当“路由器”。
   • 内容索引（用于问答）：将每个工作表的实际数据（例如，整个表格）转换为一个大的文本Document，并为其附加一个关键的元数据标签，如 {"sheet_name": "年份_1994"}。然后，用所有这些包含真实内容的文档构建一个向量索引。
2. 执行两步查询：
   • 第一步：路由。当用户提问（例如，“1994年评分人数最少的电影是哪一部？”）时，首先在“摘要索引”中进行检索。由于问题中的“1994年”与“此文档包含1994年的电影信息”这个摘要高度相关，检索器会快速返回其对应的元数据，告诉系统目标是 年份_1994 这个工作表。
   • 第二步：检索。拿到 年份_1994 这个目标后，系统会在“内容索引”中进行检索，但这次会附加一个元数据过滤器（MetadataFilter），强制要求只在 sheet_name == "年份_1994" 的文档中进行搜索。这样，LLM就能在正确的、经过筛选的数据范围内找到问题的答案。

通过这种“先路由，后用元数据过滤检索”的方式，既实现了跨多个数据源的查询能力，又避免了执行代码的安全隐患。LlamaIndex 官方也提供了类似的结构化分层检索4可以参考。

混合检索

混合检索（Hybrid Search）是一种结合了 稀疏向量（Sparse Vectors） 和 密集向量（Dense Vectors） 优势的先进搜索技术。旨在同时利用稀疏向量的关键词精确匹配能力和密集向量的语义理解能力，以克服单一向量检索的局限性，从而在各种搜索场景下提供更准确、更鲁棒的检索结果。

###倒数排序融合 (Reciprocal Rank Fusion, RRF)

RRF 不关心不同检索系统的原始得分，只关心每个文档在各自结果集中的排名。其思想是：一个文档在不同检索系统中的排名越靠前，它的最终得分就越高。

加权线性组合

这种方法需要先将不同检索系统的得分进行归一化（例如，统一到 0-1 区间），然后通过一个权重参数 α 来进行线性组合。

通过调整 α 的值，可以灵活地控制语义相似性与关键词匹配在最终排序中的贡献比例。例如，在电商搜索中，可以调高关键词的权重；而在智能问答中，则可以侧重于语义。

查询构建

文本到元数据过滤器

在构建向量索引时，常常会为文档块（Chunks）附加元数据（Metadata），例如文档来源、发布日期、作者、章节、类别等。这些元数据为我们提供了在语义搜索之外进行精确过滤的可能。

自查询检索器（Self-Query Retriever） 是LangChain中实现这一功能的核心组件。它的工作流程如下：

1. 定义元数据结构：首先，需要向LLM清晰地描述文档内容和每个元数据字段的含义及类型。

2. 查询解析

   ：当用户输入一个自然语言查询时，自查询检索器会调用LLM，将查询分解为两部分：

   • 查询字符串（Query String）：用于进行语义搜索的部分。
   • 元数据过滤器（Metadata Filter）：从查询中提取出的结构化过滤条件。

3. 执行查询：检索器将解析出的查询字符串和元数据过滤器发送给向量数据库，执行一次同时包含语义搜索和元数据过滤的查询

文本到Cypher

Cypher 是图数据库（如 Neo4j）中最常用的查询语言，其地位类似于 SQL 之于关系数据库。它采用一种直观的方式来匹配图中的模式和关系

与“文本到元数据过滤器”类似，“文本到Cypher”技术利用大语言模型（LLM）将用户的自然语言问题直接翻译成一句精准的 Cypher 查询语句。LangChain 提供了相应的工具链（如 GraphCypherQAChain），其工作流程通常是：

1. 接收用户的自然语言问题。
2. LLM 根据预先提供的图谱模式（Schema），将问题转换为 Cypher 查询。
3. 在图数据库上执行该查询，获取精确的结构化数据。
4. (可选)将查询结果再次交由 LLM，生成通顺的自然语言答案。

Text2SQL

• “幻觉”问题：LLM 可能会“想象”出数据库中不存在的表或字段，导致生成的SQL语句无效。
• 对数据库结构理解不足：LLM 需要准确理解表的结构、字段的含义以及表与表之间的关联关系，才能生成正确的 JOIN 和 WHERE 子句。
• 处理用户输入的模糊性：用户的提问可能存在拼写错误或不规范的表达（例如，“上个月的销售冠军是谁？”），模型需要具备一定的容错和推理能力。

1. 提供精确的数据库模式：这是最基础也是最关键的一步。我们需要向LLM提供数据库中相关表的 CREATE TABLE 语句。这就像是给了LLM一张地图，让它了解数据库的结构，包括表名、列名、数据类型和外键关系。
2. 提供少量高质量的示例：在提示（Prompt）中加入一些“问题-SQL”的示例对，可以极大地提升LLM生成查询的准确性。这相当于给了LLM几个范例，让它学习如何根据相似的问题构建查询。
3. 利用RAG增强上下文：这是更进一步的策略。我们可以像RAGFlow一样，为数据库构建一个专门的“知识库”，其中不仅包含表的DDL（数据定义语言），还可以包含：
   • 表和字段的详细描述：用自然语言解释每个表是做什么的，每个字段代表什么业务含义。
   • 同义词和业务术语：例如，将用户的“花费”映射到数据库的 cost 字段。
   • 复杂的查询示例：提供一些包含 JOIN、GROUP BY 或子查询的复杂问答对。 当用户提问时，系统首先从这个知识库中检索最相关的信息（如相关的表结构、字段描述、相似的Q&A），然后将这些信息和用户的问题一起组合成一个内容更丰富的提示，交给LLM生成最终的SQL查询。这种方式极大地降低了“幻觉”的风险，提高了查询的准确度。
4. 错误修正与反思 (Error Correction and Reflection)：在生成SQL后，系统会尝试执行它。如果数据库返回错误，可以将错误信息反馈给LLM，让它“反思”并修正SQL语句，然后重试。这个迭代过程可以显著提高查询的成功率。

查询重构与分发

1. 查询翻译（Query Translation）：将用户的原始问题转换成一个或多个更适合检索的形式。
2. 查询路由（Query Routing）：根据问题的性质，将其智能地分发到最合适的数据源或检索器。

查询翻译

查询翻译的目标是弥合用户自然语言提问与文档库中存储信息之间的“语义鸿沟”。通过重写、分解或扩展查询，我们可以显著提升检索的准确率。

• 提示工程

这是最直接的查询重构方法。通过精心设计的提示词（Prompt），可以引导 LLM 将用户的原始查询改写得更清晰、更具体，或者转换成一种更利于检索的叙述风格。

这种方法的思路是，要求 LLM 直接分析用户的意图，并生成一个结构化（例如 JSON 格式）的指令，告诉我们的代码应该如何操作。

• 多查询分解（Multi-query）

当用户提出一个复杂的问题时，直接用整个问题去检索可能效果不佳，因为它可能包含多个子主题或意图。分解技术的核心思想是将这个复杂问题拆分成多个更简单、更具体的子问题。然后，系统分别对每个子问题进行检索，最后将所有检索到的结果合并、去重，形成一个更全面的上下文，再交给 LLM 生成最终答案。

LangChain 提供了 MultiQueryRetriever 来完成这一过程。它在内部利用 LLM 将原始问题从不同角度分解成多个子问题，然后并行为每个子问题检索相关文档。最后，它将所有检索到的文档合并并去重，形成一个更全面的上下文，再传递给语言模型生成最终答案。通过这种策略，极大地丰富了检索结果，在有些应用种可以有效提升后续生成环节的质量。

• 退步提示（Step-Back Prompting）

当面对一个细节繁多或过于具体的问题时，模型直接作答（即便是使用思维链）也容易出错。退步提示通过引导模型“退后一步”来解决这个问题。

其核心流程分为两步：

1. 抽象化：首先，引导 LLM 从用户的原始具体问题中，生成一个更高层次、更概括的“退步问题”（Step-back Question）。这个退步问题旨在探寻原始问题背后的通用原理或核心概念。
2. 推理：接着，系统会先获取“退步问题”的答案（例如，一个物理定律、一段历史背景等），然后将这个通用原理作为上下文，再结合原始的具体问题，进行推理并生成最终答案。

通过先检索或生成高层知识，再进行具体推理，退步提示能够帮助模型构建一个更坚实的逻辑基础，从而提高在复杂问答场景下的准确性。

• 假设性文档嵌入（HyDE）

假设性文档嵌入（Hypothetical Document Embeddings, HyDE）是一种无需微调即可显著提升向量检索质量的查询改写技术，由 Luyu Gao 等人在其论文中首次提出。其核心是解决一个普遍存在于检索任务中的难题：用户的查询（Query）通常简短、关键词有限，而数据库中存储的文档则内容详实、上下文丰富，两者在语义向量空间中可能存在“鸿沟”，导致直接用查询向量进行搜索效果不佳。Zilliz 的一篇技术博客4也对该技术进行了深入浅出的解读。

HyDE 通过一种巧妙的方式来“绕过”这个问题：它不直接使用用户的原始查询，而是先利用一个生成式大语言模型（LLM）来生成一个“假设性”的、能够完美回答该查询的文档。然后，HyDE 将这个内容详实的假设性文档进行向量化，用其生成的向量去数据库中寻找与之最相似的真实文档。

HyDE 的工作流程可以分为三个步骤：

1. 生成：当接收到用户查询时，首先调用一个生成式 LLM（例如，GPT-3.5）。提示该模型根据查询生成一个详细的、可能是理想答案的文档。这个文档不必完全符合事实，但它必须在语义上与一个好的答案高度相关。
2. 编码：将上一步生成的假设性文档输入到一个对比编码器（如 Contriever）中，将其转换为一个高维向量嵌入。这个向量在语义上代表了一个“理想答案”的位置。
3. 检索：使用这个假设性文档的向量，在向量数据库中执行相似性搜索，找出与这个“理想答案”最接近的真实文档。这些被检索出的文档将作为最终的上下文信息。

通过这种方式，HyDE 将困难的“查询到文档”的匹配问题，转化为了一个相对容易的“文档到文档”的匹配问题，从而提升检索的准确率。

查询路由

查询路由（Query Routing） 是用于优化复杂 RAG 系统的一项关键技术。当系统接入了多个不同的数据源或具备多种处理能力时，就需要一个“智能调度中心”来分析用户的查询，并动态选择最合适的处理路径。其本质是替代硬编码规则，通过语义理解将查询分发至最匹配的数据源、处理组件或提示模板，从而提升系统的效率与答案的准确性。

查询路由的应用场景十分广泛。

1. 数据源路由：这是最常见的场景。根据查询意图，将其路由到不同的知识库。例如：
   • 查询“最新的 iPhone 有什么功能？” -> 路由到产品文档向量数据库。
   • 查询“我上次订购了什么？” -> 路由到用户历史SQL数据库（执行Text-to-SQL）。
   • 查询“A公司和B公司的投资关系是怎样的？” -> 路由到企业知识图谱数据库。
2. 组件路由：根据问题的复杂性，将其分配给不同的处理组件，以平衡成本和效果。
   • 简单FAQ → 直接进行向量检索，速度快、成本低。
   • 复杂操作或需要与外部API交互 → 调用 Agent 来执行任务。
3. 提示模板路由：为不同类型的任务动态选择最优的提示词模板，以优化生成效果。
   • 数学问题 → 选用包含分步思考（Step-by-Step）逻辑的提示模板。
   • 代码生成 → 选用专门为代码优化过的提示模板。

• 基于LLM的意图识别

通过设计一个包含路由选项的提示词，让大语言模型（LLM）直接对用户的查询进行分类，并输出一个代表路由选择的标签。

1. 定义清晰的路由选项（例如，数据源名称、功能分类）。
2. LLM 分析查询并输出决策标签。
3. 代码根据标签调用相应的检索器或工具。

• 嵌入相似性路由

这种方法不依赖 LLM 进行分类，延迟更低。它通过计算用户查询与预设的“路由示例语句”之间的向量嵌入相似度来做出决策。

检索进阶

重排序（Re-ranking）

• RRF（Reciprocal Rank Fusion）

它是一种简单而有效的零样本重排方法，不依赖于任何模型训练，而是纯粹基于文档在多个不同检索器（例如，一个稀疏检索器和一个密集检索器）结果列表中的排名来计算最终分数。

一个文档如果在多个检索结果中都排名靠前，那么它很可能更重要。RRF 通过计算排名的倒数来为文档打分，有效融合了不同检索策略的优势。但是如果只考虑排名信息，会忽略原始的相似度分数，可能丢失部分有用信息。

• RankLLM/LLM-based Reranker

RankLLM 代表了一类直接利用大型语言模型本身来进行重排的方法。其基本逻辑非常直观：既然 LLM 最终要负责根据上下文来生成答案，那么为什么不直接让它来判断哪些上下文最相关呢？

这种方法通过一个精心设计的提示词来实现。该提示词会包含用户的查询和一系列候选文档（通常是文档的摘要或关键部分），然后要求 LLM 以特定格式（如 JSON）输出一个排序后的文档列表，并给出每个文档的相关性分数。

• Cross-Encoder重排

Cross-Encoder（交叉编码器）能提供出色的重排精度。它的工作原理是将查询（Query）和每个候选文档（Document）拼接成一个单一的输入（例如，[CLS] query [SEP] document [SEP]），然后将这个整体输入到一个预训练的 Transformer 模型（如 BERT）中，模型最终会输出一个单一的分数（通常在 0 到 1 之间），这个分数直接代表了文档与查询的相关性。

1. 初步检索：搜索引擎首先从知识库中召回一个初始的文档列表（例如，前 50 篇）。
2. 逐一评分：对于列表中的每一篇文档，系统都将其与原始查询配对，然后发送给 Cross-Encoder 模型。
3. 独立推理：模型对每个“查询-文档”对进行一次完整的、独立的推理计算，得出一个精确的相关性分数。
4. 返回重排结果：系统根据这些新的分数对文档列表进行重新排序，并将最终结果返回给用户。

这个流程凸显了其高精度的来源（同时分析查询和文档），也解释了其高延迟的原因（需要N次独立的模型推理）。

• ColBERT重排

ColBERT（Contextualized Late Interaction over BERT）是一种创新的重排模型，它在 Cross-Encoder 的高精度和双编码器（Bi-Encoder）的高效率之间取得了平衡。采用了一种“后期交互”机制。

其工作流程如下：

1. 独立编码：ColBERT 分别为查询（Query）和文档（Document）中的每个 Token 生成上下文相关的嵌入向量。这一步是独立完成的，可以预先计算并存储文档的向量，从而加快查询速度。
2. 后期交互：在查询时，模型会计算查询中每个 Token 的向量与文档中每个 Token 向量之间的最大相似度（MaxSim）。
3. 分数聚合：最后，将查询中所有 Token 得到的最大相似度分数相加，得到最终的相关性总分。

通过这种方式，ColBERT 避免了将查询和文档拼接在一起进行昂贵的联合编码，同时又比单纯比较单个 [CLS] 向量的双编码器模型捕捉了更细粒度的词汇级交互信息。

为了更直观地理解不同重排方法的特点和适用场景，下表对讨论过的几种主流方法进行了总结：

特性	RRF	RankLLM	Cross-Encoder	ColBERT
核心机制	融合多个排名	LLM 推理，生成排序列表	联合编码查询与文档，计算单一相关分	独立编码，后期交互
计算成本	低（简单数学计算）	中 (API 费用与延迟)	高（N次模型推理）	中（向量点积计算）
交互粒度	无（仅排名）	概念/语义级	句子级（Query-Doc Pair）	Token 级
适用场景	多路召回结果融合	高价值语义理解场景	Top-K 精排	Top-K 重排

压缩（Compression）

“压缩”技术旨在解决一个常见问题：初步检索到的文档块（Chunks）虽然整体上与查询相关，但可能包含大量无关的“噪音”文本。将这些未经处理的、冗长的上下文直接提供给 LLM，不仅会增加 API 调用的成本和延迟，还可能因为信息过载而降低最终生成答案的质量。

压缩的目标就是对检索到的内容进行“压缩”和“提炼”，只保留与用户查询最直接相关的信息。这可以通过两种主要方式实现：

1. 内容提取：从文档中只抽出与查询相关的句子或段落。
2. 文档过滤：完全丢弃那些虽然被初步召回，但经过更精细判断后认为不相关的整个文档。

LangChain的ContextualCompressionRetriever

LangChain 提供了一个强大的组件 ContextualCompressionRetriever 来实现上下文压缩。它像一个包装器，包裹在基础的检索器（如 FAISS.as_retriever()）之上。当基础检索器返回文档后，ContextualCompressionRetriever 会使用一个指定的 DocumentCompressor 对这些文档进行处理，然后再返回给调用者。

LangChain 内置了多种 DocumentCompressor：

• LLMChainExtractor: 这是最直接的压缩方式。它会遍历每个文档，并利用一个 LLM Chain 来判断并提取出其中与查询相关的部分。这是一种“内容提取”。
• LLMChainFilter: 这种压缩器同样使用 LLM，但它做的是“文档过滤”。它会判断整个文档是否与查询相关，如果相关，则保留整个文档；如果不相关，则直接丢弃。
• EmbeddingsFilter: 这是一种更快速、成本更低的过滤方法。它会计算查询和每个文档的嵌入向量之间的相似度，只保留那些相似度超过预设阈值的文档。

校正（Correcting）

传统的 RAG 流程有一个隐含的假设：检索到的文档总是与问题相关且包含正确答案。然而在现实世界中，检索系统可能会失败，返回不相关、过时或甚至完全错误的文档。如果将这些“有毒”的上下文直接喂给 LLM，就可能导致幻觉（Hallucination）或产生错误的回答。

校正检索（Corrective-RAG, C-RAG） 正是为解决这一问题而提出的一种策略。思路是引入一个“自我反思”或“自我修正”的循环，在生成答案之前，对检索到的文档质量进行评估，并根据评估结果采取不同的行动。

C-RAG 的工作流程可以概括为 “检索-评估-行动” 三个阶段：

1. 检索 (Retrieve) ：与标准 RAG 一样，首先根据用户查询从知识库中检索一组文档。
2. 评估 (Assess) ：这是 C-RAG 的关键步骤。如图所示，一个“检索评估器 (Retrieval Evaluator)”会判断每个文档与查询的相关性，并给出“正确 (Correct)”、“不正确 (Incorrect)”或“模糊 (Ambiguous)”的标签。
3. 行动 (Act) ：根据评估结果，系统会进入不同的知识修正与获取流程：
   • 如果评估为“正确”：系统会进入“知识精炼 (Knowledge Refinement)”环节。如图，它会将原始文档分解成更小的知识片段 (strips)，过滤掉无关部分，然后重新组合成更精准、更聚焦的上下文，再送给大模型生成答案。
   • 如果评估为“不正确”：系统认为内部知识库无法回答问题，此时会触发“知识搜索 (Knowledge Searching)”。它会先对原始查询进行“查询重写 (Query Rewriting)”，生成一个更适合搜索引擎的查询，然后进行 Web 搜索，用外部信息来回答问题。
   • 如果评估为“模糊”：同样会触发“知识搜索”，但通常会直接使用原始查询进行 Web 搜索，以获取额外信息来辅助生成答案。

通过这种方式，C-RAG 极大地增强了 RAG 系统的鲁棒性。不再盲目信任检索结果，而是增加了一个“事实核查”层，能够在检索失败时主动寻求外部帮助，从而有效减少幻觉，提升答案的准确性和可靠性。

在 LangChain 的 langgraph 库中，可以利用其图结构来灵活地构建这种带有条件判断和循环的复杂 RAG 流程。

生成集成

格式化生成

从大语言模型（LLM）那里获得一段非结构化的文本在应用中常常不满足实际需求。为了实现更复杂的逻辑、与外部工具交互或以用户友好的方式展示数据，需要模型能够输出具有特定结构的数据，例如 JSON 或 XML。

• output parsers

LangChain 提供了一个强大的组件——OutputParsers（输出解析器），专门用于处理 LLM 的输出。它的核心思想是：

1. 提供格式指令：在发送给 LLM 的提示（Prompt）中，自动注入一段关于如何格式化输出的指令。
2. 解析模型输出：接收 LLM 返回的纯文本字符串，并将其解析成预期的结构化数据（如 Python 对象）。

LangChain 提供了多种开箱即用的解析器，例如：

• StrOutputParser：最基础的输出解析器，它简单地将 LLM 的输出作为字符串返回。
• JsonOutputParser：可以解析包含嵌套结构和列表的复杂 JSON 字符串。
• PydanticOutputParser：通过与 Pydantic 模型结合，可以实现对输出格式最严格的定义和验证。

Function Calling

Function Calling 的本质是一个多轮对话流程，让模型、代码和外部工具（如 API）协同工作。其核心工作流如下：

1. 定义工具：首先，在代码中以特定格式（通常是 JSON Schema）定义好可用的工具，包括工具的名称、功能描述、以及需要的参数。
2. 用户提问：用户发起一个需要调用工具才能回答的请求。
3. 模型决策：模型接收到请求后，分析用户的意图，并匹配最合适的工具。它不会直接回答，而是返回一个包含 tool_calls 的特殊响应。这个响应相当于一个指令：“请调用某某工具，并使用这些参数”。
4. 代码执行：应用接收到这个指令，解析出工具名称和参数，然后在代码层面实际执行这个工具（例如，调用一个真实的天气 API）。
5. 结果反馈：将工具的执行结果（例如，从 API 获取的真实天气数据）包装成一个 role 为 tool 的消息，再次发送给模型。
6. 最终生成：模型接收到工具的执行结果后，结合原始问题和工具返回的信息，生成最终的、自然的语言回答。

相比于单纯通过提示工程“请求”模型输出 JSON，Function Calling 的优势在于：

• 可靠性更高：这是模型原生支持的能力，相比于解析可能格式不稳定的纯文本输出，这种方式得到的结构化数据更稳定、更精确。
• 意图识别：它不仅仅是格式化输出，更包含了“意图到函数的映射”。模型能根据用户问题主动选择最合适的工具。
• 与外部世界交互：它是构建能执行实际任务的 AI 代理（Agent）的核心基础，让 LLM 可以查询数据库、调用 API、控制智能家居等。

RAG系统评估

RAG评估三元组

该架构包含以下三个维度，并在 TruLens 等工具中有深入的应用：

1. 上下文相关性 (Context Relevance)
   • 评估目标： 检索器（Retriever）的性能。
   • 核心问题： 检索到的上下文内容，是否与用户的查询（Query）高度相关？
   • 重要性： 检索是RAG应用在响应用户查询时的第一步。如果检索回来的上下文充满了噪声或无关信息，那么无论后续的生成模型多么强大，都没法做出正确答案。
2. 忠实度 / 可信度 (Faithfulness / Groundedness)
   • 评估目标： 生成器的可靠性。
   • 核心问题： 生成的答案是否完全基于所提供的上下文信息？
   • 重要性： 这个维度主要在于量化LLM的“幻觉”程度。一个高忠实度的回答意味着模型严格遵守了上下文，没有捏造或歪曲事实。如果忠实度得分低，说明LLM在回答时“自由发挥”过度，引入了外部知识或不实信息。
3. 答案相关性 (Answer Relevance)
   • 评估目标： 系统的端到端（End-to-End）表现。
   • 核心问题： 最终生成的答案是否直接、完整且有效地回答了用户的原始问题？
   • 重要性： 这是用户最直观的感受。一个答案可能完全基于上下文（高忠实度），但如果它答非所问，或者只回答了问题的一部分，那么这个答案的相关性就很低。例如，当用户问“法国在哪里，首都是哪里？”，如果答案只是“法国在西欧”，那么虽然忠实度高，但答案相关性很低。

评估工作流

• 检索评估

检索评估聚焦于RAG三元组中的 上下文相关性 (Context Relevance)，本质上是一次*白盒测试 。此阶段的评估需要一个标注数据集，其中包含一系列查询以及每个查询对应的真实相关文档。

这项评估借鉴了信息检索领域的多个经典指标：

• 响应评估

响应评估覆盖了RAG三元组中的 忠实度 和 答案相关性。此环节通常采用 端到端 的评估范式，因为它直接衡量用户感知的最终输出质量。无论采用何种评估方法，都主要围绕以下两个核心维度展开。

• 评估维度

1. 忠实度 / 可信度:
   • 衡量生成的答案在多大程度上可以由给定的上下文所证实。一个完全忠实的答案，其所有内容都必须能在上下文中找到依据，以此避免模型产生“幻觉”。
2. 答案相关性:
   • 衡量生成的答案与用户原始查询的对齐程度。一个高相关性的答案必须是直接的、切题的，并且不包含与问题无关的冗余信息。

• 主要评估方法

针对上述维度，目前主要有两类评估方法：

1. 基于大语言模型的评估

这是一种强大的评估方法，能够提供更深度的语义评估，正逐渐成为主流选择。利用一个高性能、中立的llm作为“评估者”，对上述维度进行深度的语义理解和打分。

• 忠实度评估： 首先，将生成的答案分解为一系列独立的声明或断言（Claims）。然后，对于每一个断言，在提供的上下文中进行验证，判断其真伪。最终的忠实度分数是所有被上下文证实的断言所占的比例。
• 答案相关性评估： 评估者需要同时分析用户查询和生成的答案。评分时会惩罚那些答非所问、信息不完整或包含过多无关细节的答案。

2. 基于词汇重叠的经典指标

这类指标需要在数据集中包含一个或多个“标准答案”。它们通过计算生成答案与标准答案之间 n-gram（连续的n个词）的重叠程度来评估质量。

基于LLM的评估更注重语义和逻辑，评估质量高，但成本也更高且存在评估者偏见。基于词汇重叠的指标客观、计算快、成本低，但无法理解语义，可能误判同义词或释义。在实践中，可以将两者结合，使用经典指标进行快速、大规模的初步筛选，再利用LLM进行更精细的评估。

评估工具

LlamaIndex Evaluation

LlamaIndex Evaluation 是深度集成于LlamaIndex框架内的评估模块，专为使用该框架构建的RAG应用提供无缝的评估能力。作为RAG开发框架的原生组件，其核心定位是为开发者在开发、调试和迭代周期中提供快速、灵活的嵌入式评估解决方案。它强调与开发流程的紧密结合，允许开发者在构建过程中即时验证和对比不同RAG策略的性能。

LlamaIndex 的评估理念是利用LLM作为“裁判”，以自动化的方式对RAG系统的各个环节进行打分。这种方法在很多场景下无需预先准备“标准答案”，大大降低了评估门槛。其典型工作流如下：

1. 准备评估数据集：通过 DatasetGenerator 从文档中自动生成问题-答案对（QueryResponseDataset），或加载一个已有的数据集。为了效率，通常会将生成的数据集保存到本地，避免重复生成。
2. 构建查询引擎：搭建一个或多个需要被评估的RAG查询引擎（QueryEngine）。这是进行对比实验的基础。
3. 初始化评估器：根据评估维度，选择并初始化一个或多个评估器，如 FaithfulnessEvaluator（忠实度）和 RelevancyEvaluator（相关性）。
4. 执行批量评估：使用 BatchEvalRunner 来管理整个评估过程。它能够高效地（可并行）将查询引擎应用于数据集中的所有问题，并调用所有评估器进行打分。
5. 分析结果：从评估运行器返回的结果中，计算各项指标的平均分，从而量化地对比不同RAG策略的优劣。

LlamaIndex提供了丰富的评估器，覆盖了从检索到响应的各个环节。上述示例中主要使用了响应评估维度：

• Faithfulness (忠实度): 评估生成的答案是否完全基于检索到的上下文，是检测“幻觉”现象的关键指标。分数越高，说明答案越可靠。
• Relevancy (相关性): 评估生成的答案与用户提出的原始问题是否直接相关，确保答案切题。

此外，它还支持专门的检索评估维度，如：

• Hit Rate (命中率): 评估检索到的上下文中是否包含了正确的答案。
• MRR (平均倒数排名): 衡量找到正确答案的效率，排名越靠前得分越高。

RAGAS

RAGAS（RAG Assessment）是一个独立的、专注于RAG的开源评估框架。提供了一套全面的指标来量化RAG管道的检索和生成两大核心环节的性能。其最显著的特色是支持无参考评估，即在许多场景下无需人工标注的“标准答案”即可进行评估，极大地降低了评估成本。现对RAG管道的持续监控和改进。如果你需要一个轻量级、与具体RAG实现解耦、能够快速对核心指标进行量化评估的工具时，RAGAS 是一个理想的选择。

RAGAS 的核心思想是通过分析问题（question）、生成的答案（answer）和检索到的上下文（context）三者之间的关系，来综合评估RAG系统的性能。它将复杂的评估问题分解为几个简单、可量化的维度。

1. 准备数据集：根据官方文档，一个标准的评估数据集应包含 question（问题）、answer（RAG系统生成的答案）、contexts（检索到的上下文）以及 ground_truth（标准参考答案）这四列。不过，ground_truth 对于计算 context_recall 等指标是必需的，但对于 faithfulness 等指标则是可选的。
2. 运行评估：调用 ragas.evaluate() 函数，传入准备好的数据集和需要评估的指标列表。
3. 分析结果：获取一个包含各项指标量化分数的评估报告。

其核心评估指标包括：

• faithfulness: 衡量生成的答案中有多少比例的信息是可以由检索到的上下文所支持的。
• context_recall: 衡量检索到的上下文与标准答案（ground_truth）的对齐程度，即标准答案中的信息是否被上下文完全“召回”。
• context_precision: 衡量检索到的上下文中，信噪比如何，即有多少是真正与回答问题相关的。
• answer_relevancy: 评估答案与问题的相关程度。此指标不评估事实准确性，只关注答案是否切题。

Phoenix

Phoenix (现由Arize维护) 是一个开源的LLM可观测性与评估平台。在RAG评估生态中，它主要扮演生产环境中的可视化分析与故障诊断引擎的角色。它通过捕获LLM应用的轨迹（Traces），提供强大的可视化、切片和聚类分析能力，帮助开发者理解线上真实数据的表现。Phoenix 的核心价值在于从海量生产数据中发现问题、监控性能漂移并进行深度诊断，是连接线下评估与线上运维的关键桥梁。它不仅提供评估指标，更强调对LLM应用进行追踪（Tracing）和可视化分析，从而快速定位问题。

1. 代码插桩 (Instrumentation)：基于开放标准 OpenTelemetry，在RAG应用代码中集成 Phoenix 的追踪功能，自动捕获LLM调用、函数执行等事件。
2. 生成追踪数据 (Traces)：运行RAG应用，Phoenix 会在后台记录下完整的执行链路。
3. 启动UI进行分析：在本地启动 Phoenix 的Web界面，加载并可视化追踪数据。
4. 评估与调试：在UI中对失败的案例或表现不佳的查询进行筛选、钻取，并运行内置的评估器 (Evals) 进行根本原因分析。

特色功能：

• 可视化追踪: 将RAG的执行流程、数据和评估结果进行可视化展示，极大地方便了问题定位。
• 根本原因分析: 通过可视化的界面，可以轻松地对表现不佳的查询进行切片和钻取。
• 安全护栏 (Guardrails): 允许为应用添加保护层，防止恶意或错误的输入输出，保障生产环境安全。
• 数据探索与标注: 提供数据探索、清洗和标注工具，帮助开发者利用生产数据反哺模型和系统优化。
• 与Arize平台集成: Phoenix 可以与Arize的商业平台无缝对接，实现生产环境中对RAG系统的持续监控。

基于知识图谱的RAG

尽管传统 RAG 通过”检索-生成”两阶段流程在一定程度上解决了LLM的知识更新问题，但其基于非结构化文本向量检索的核心机制仍存在几个关键局限。

关系理解的缺失：基于向量的检索主要关注语义相似性，难以捕捉和利用实体之间复杂的、隐含的关系。当查询涉及多实体关联或因果推理时，检索到的文本块之间可能缺乏逻辑联系，导致LLM难以进行有效的综合与推理。

上下文的碎片化：文本被切分成独立的块进行索引，这破坏了原文的结构和上下文连续性。对于需要跨越多个文档或长距离文本进行信息整合的问题，传统RAG往往力不从心。

检索噪声与幻觉风险：检索过程可能返回不相关或仅部分相关的噪声信息，这会干扰LLM的判断，甚至诱发其产生与事实不符的”幻觉”内容。知识图谱的引入被证实能有效减轻模型幻觉，提供更高质量的上下文。

推理能力有限：传统 RAG 的推理能力受限于检索到的线性文本内容，难以支持需要结构化知识进行导航的多跳推理。

跨文档联结能力弱：即便采用较大的切块与滑窗重叠，跨文档/跨章节的实体共现与隐式引用仍难以被显式建模，导致需要“连边”才能回答的问题（如沿因果、时间或供应链关系追踪）召回不足。

实体歧义与别名问题：仅依赖向量相似度很难稳定地区分同名实体（如不同城市/公司/人名），或统一别名、缩写与多语言变体，易造成错误对齐与语义漂移。

时效性与版本一致性不足：文本块往往缺少可计算的时间属性与有效期边界，导致时序敏感问题（如“某公司在某年是否仍为子公司”）难以得到一致答案。

知识图谱通过节点（实体）和边（关系）的网络结构，将离散的知识显式地组织成一个相互连接的语义网络，为克服传统RAG的局限性提供了强有力的解决方案。

结构化语义表达：知识图谱以图的形式直接编码实体间的显式语义关系（如”公司A-收购-公司B”），避免了LLM从文本中进行隐式、可能存在偏差的推断，为复杂查询提供了清晰的导航路径。

增强推理能力：图的结构天然支持多跳推理，系统可以沿着图中的路径遍历，发现间接但关键的知识关联，从而回答需要多步逻辑推导的复杂问题。

事实性与可解释性：基于知识图谱检索的答案可以追溯其在图中的推理路径，这为答案提供了事实依据，极大地增强了系统的可解释性和可信度，有效抑制了幻觉。

异构数据集成：知识图谱能够无缝集成来自不同来源的结构化（如数据库）和非结构化（如文本）数据，形成一个全面、统一的知识视图，这在金融、医疗等需要整合海量异构信息的领域尤为重要。

进一步地：

• 语义模式与本体支撑：通过模式（Schema）与本体（Ontology）明确实体类型、关系约束与属性域值，约束推理空间，降低歧义。
• 溯源与置信度管理：边与节点可携带来源、时间戳与置信度，便于在生成时进行来源归因与冲突消解。
• 时间与版本建模：支持时间态边与版本化节点，允许对“历史状态”与“有效区间”进行查询（Time-travel Query）。

GraphRAG

知识图谱构建 是 GraphRAG 的基础。该阶段的目标是从原始数据中构建一个高质量的知识图谱：

• 知识抽取：利用 LLM 或 IE 管线从非/半结构化文本中抽取实体、关系与属性，包含指代消解、别名归一（Normalization）与术语标准化。
• 质量控制：对三元组进行置信度评估、人机协同抽检与冲突消解；必要时通过规则与本体约束做一致性校验。
• 图谱融合：进行实体对齐与去重（Entity Resolution），合并跨来源知识并保留来源/时间戳等溯源信息。
• 存储与索引：落地到图数据库（如Neo4j/NebulaGraph/TigerGraph/Neptune等）并建立必要的属性与关系索引，便于后续高效检索与遍历。

图谱检索 阶段，当用户提出查询时，系统不再是简单地进行向量相似度搜索，而是执行更复杂的图谱检索操作。混合检索策略是主流趋势：

• 实体定位：先用实体链接（Entity Linking）或向量检索在图中锁定核心实体节点。
• 子图探索：从命中节点出发，利用图查询语言（如Cypher）或遍历算法进行邻域扩展、路径发现与约束过滤（例如限定关系类型、跳数、时间区间与置信度阈值）。
• 结构化证据抽取：将路径与关键节点属性序列化为可读证据片段，或生成子图的文本摘要。
• 高级检索：如GraphRAG采用社区检测（如Leiden）生成多层次摘要，实现“全局-局部”联合检索。

根据综述性研究，现有的 GraphRAG 方法大致可以归为三类，反映了知识图谱与 RAG 结合深度的不同。

知识驱动型： 检索过程主要或完全依赖于知识图谱。这类方法直接在图上进行查询与推理（如文本转 Cypher/Gremlin），适用于需要强逻辑约束与可解释性的任务。

索引驱动型： 将知识图谱的结构信息融入到文本索引。例如用邻居实体/关系充当元数据特征、或将子图摘要拼接到文本后再向量化，以提升召回与重排效果。

混合型： 同时使用图检索与文本检索，并对结果统一重排与融合：

• 简单事实问答可优先图检索；叙事性/描述性问题可补充文本证据。
• 对复杂查询，可先图上定位路径，再以路径节点为“导航枢纽”做针对性文档检索。

前沿GraphRAG框架：

• GraphRAG（Microsoft）

• LightRAG

• FRAG（Flexible RAG）

• GraphIRAG (Iterative Knowledge Retrieval)

性能评估和基准测试

GraphRAG 的评估体系是多维度的，主要涵盖三个方面。

检索质量：

• 传统：精确率（Precision）、召回率（Recall）、F1、命中率（Hit Rate@K）。
• RAG特有：
  • 上下文精确率（Context Precision）= 检索到的上下文中“真正相关”的比例；
  • 上下文召回率（Context Recall）= 所有应当支持答案的“金标准证据”被检回的比例；
  • 引用/归因准确率（Citation/Attribution）= 生成答案中的关键断言是否被检索证据正确支撑。

生成质量：

• 问答：精确匹配（EM）、F1；
• 摘要：ROUGE；
• 事实一致性/忠实度（Faithfulness）：断言与证据的一致性，可配合“逐句打标+归因检查”。

系统性能：

推理延迟（Latency）是从接收查询到返回最终答案所需的总时间，是衡量系统响应速度的核心指标。吞吐量（Throughput）指系统在单位时间内能处理的查询数量（QPS）。成本（Cost）包括API调用次数、计算资源（GPU/CPU）和内存消耗等。

学术界已经建立了一系列基准数据集来评测GraphRAG在不同任务上的能力。

多跳问答 数据集要求模型在多个知识源之间进行推理，是检验GraphRAG核心能力的试金石。代表性数据集包括 HotpotQA、2WikiMultihopQA 和 MuSiQue。

复杂问答 数据集包含结构复杂的查询，代表性数据集包括 WebQSP 和 ComplexWebQuestions (CWQ)。

知识图谱驱动的QA 是专门为评估知识图谱问答能力设计的数据集，如 KGQAgen-10k。