基线 RAG文档切 chunk → 向量化 → 按相似度 Top-k 召回 → 把片段塞给 LLM 生成答案GraphRAG从文本中抽取实体、关系、属性构建知识图谱并结合图遍历、社区摘要和 LLM 生成答案。局限性基线 RAGGraphRAG串联信息无法通过共享属性遍历不同的信息片段来综合出新见解知识图谱通过关系显式链接实体支持多跳推理整体理解无法对大型数据集中的语义概念进行总结社区层次结构提供从局部到全局的多粒度摘要全局推理Top-K 检索只见树木不见森林对社区报告执行 Map-reduce 操作实现全语料库级别的推理这种差异的核心在于基线 RAG 更擅长“找相似片段”GraphRAG 更擅长“沿关系找证据、跨片段组合知识”。传统 RAG 在跨文档综合、全局主题理解、多跳推理上容易受限而 GraphRAG 通过实体、关系、社区节点构建多层知识网络让 LLM 可以从微观关系和宏观主题两个维度理解知识库。GraphRAG 也常被定义为把知识组织成“实体—关系—实体”的显式图结构从而增强复杂关系推理和多跳查询能力。1、GraphRAG 通过共享属性和显式关系做多跳推理核心差异传统基于向量数据库的基线 RAG 存在“孤立信息检索”的局限性。它仅依赖文本片段的语义相似度进行匹配将文本切分为孤立的语义碎片忽略了实体间的内在关联。当面对需要多步逻辑推导的复杂查询时它只能返回碎片化结果甚至可能因为拼凑信息而产生幻觉。相反GraphRAG 通过引入图数据库如 Neo4j将非结构化文本转化为结构化的知识存储层显式地将信息建模为“实体-关系-属性”的三元组如(公司A)-[投资]-(公司B)。这种图结构赋予了系统图遍历的能力从而支持跨文档的多跳关联检索为大模型提供结构化、可追溯的推理依据。1.1、例子一保险产品咨询——从“疾病”跳到“条款”再跳到“可投产品”假设企业知识库里有三份分散文档文档 A产品 X 的投保规则糖尿病患者需人工核保文档 B产品 Y 的免责条款既往高血压并发症不赔文档 C用户画像客户 45 岁有 2 型糖尿病和高血压病史。基线 RAG 的问题是它可能只召回“糖尿病”相关 chunk或者只召回“高血压免责”相关 chunk但不一定能把“用户疾病画像—核保规则—产品免责—适合产品”这几类信息串起来。传统向量 RAG 主要依赖文本相似度容易把信息当作孤立片段处理忽略实体之间的内在关联。GraphRAG 的做法是把知识抽成类似这样的图客户A --患有-- 2型糖尿病 客户A --患有-- 高血压 产品X --核保要求-- 糖尿病人工核保 产品Y --免责关联-- 高血压并发症 2型糖尿病 --属于-- 慢性病 高血压 --可能导致-- 心脑血管并发症当用户问“这个客户更适合买产品 X 还是产品 Y风险点是什么”GraphRAG 可以沿着路径客户A → 疾病 → 条款 → 产品 → 风险解释做多跳推理最后回答客户 A 同时存在糖尿病和高血压。产品 X 对糖尿病要求人工核保但未必直接免责产品 Y 明确关联高血压并发症免责因此产品 Y 的理赔不确定性更高。建议优先评估产品 X 的核保通过可能性并重点说明糖尿病核保材料要求。这类场景正是 GraphRAG 的典型优势因为保险咨询涉及“产品—条款—人群—疾病”的多条件组合查询知识图谱可以提供更清晰、可解释的建议。1.2、例子二金融风控——通过多跳关系发现隐性关联风险假设有这些分散信息文档 A张三是公司甲的法定代表人文档 B公司甲持有公司乙 35% 股份文档 C公司乙是目标企业丙的核心供应商文档 D公司丙近期申请贷款文档 E张三曾被列入失信被执行人名单。用户问“公司丙是否存在潜在关联风险”基线 RAG可能召回“公司丙贷款申请”或“公司乙供应商”相关内容但如果“张三失信”和“公司丙贷款”没有出现在同一段文本中向量相似度可能不足难以自然连接起来。GraphRAG可以形成路径张三 --法定代表人-- 公司甲 公司甲 --持股-- 公司乙 公司乙 --供应商-- 公司丙 公司丙 --申请-- 贷款 张三 --存在-- 失信记录于是可以推理虽然张三不是公司丙的直接股东或高管但他通过“公司甲—公司乙—公司丙供应链”形成三跳关联。若公司乙对公司丙业务依赖较高则张三的信用风险可能间接影响公司丙供应链稳定性构成潜在关联风险。金融风控正是 GraphRAG 适合的场景之一因为它需要构建企业、人物、交易、股权等复杂关系并通过多跳关系查询识别潜在风险。1.3、例子三医疗知识问答——药物、疾病、症状、禁忌之间的多跳推理假设知识库中有文档 A华法林与阿司匹林合用会增加出血风险文档 B房颤患者常使用华法林抗凝文档 C某患者有胃溃疡病史文档 D阿司匹林可能加重消化道出血风险。用户问“这个房颤患者能不能同时吃华法林和阿司匹林”基线 RAG也许能召回“华法林与阿司匹林相互作用”的片段但它可能忽略患者自身的“胃溃疡病史”这一风险属性尤其当患者病史在另一份文档中时。GraphRAG可以连接患者A --患有-- 房颤 房颤 --治疗药物-- 华法林 华法林 --相互作用-- 阿司匹林 阿司匹林 --风险-- 消化道出血 患者A --既往病史-- 胃溃疡 胃溃疡 --增加风险-- 消化道出血推理结果是患者因房颤可能需要抗凝治疗但华法林与阿司匹林合用会增加出血风险同时患者有胃溃疡病史会进一步提高消化道出血风险。因此需要医生评估是否必须联用并考虑胃黏膜保护、替代方案或更严密监测。医疗知识问答也是 GraphRAG 的典型应用因为疾病、药物、症状、禁忌、相互作用之间天然是图结构适合用关系推理来回答复杂问题。2、GraphRAG 的社区层次结构如何提供从局部到全局的多粒度摘要多粒度摘要的实现方式GraphRAG 的核心思想是通过构建多层次的知识网络来实现从局部到全局的理解。在将非结构化文本转化为“实体”和“关系”后系统会运用社区检测算法如 Leiden 算法将联系紧密的节点聚合成一个个“社区Community”。这些社区呈现出层次结构底层的微观社区包含具体的实体如某个员工、某份财报高层的宏观社区则聚合了多个微观社区如整个部门、整个公司的战略。GraphRAG 会利用大语言模型LLM自下而上地为每一个社区生成摘要报告。这样无论用户询问的是某个具体的细节局部还是整个语料库的宏观主题全局系统都能匹配到对应粒度的摘要进行回答。2.1、GraphRAG 的“社区层次结构”大致怎么实现GraphRAG 不只是把实体连成一张图还会在图上做社区发现。可以理解为如果一批实体之间关系非常密集它们就会形成一个“主题簇”或“知识社区”。例如在一个企业知识库里社区 A报销制度、差旅标准、发票、审批流程 社区 B销售合同、客户分级、折扣政策、续约条款 社区 C数据安全、权限管理、日志审计、合规要求然后 GraphRAG 会为不同层级生成摘要Level 0实体/关系级摘要 Level 1小社区摘要例如“差旅报销流程” Level 2大社区摘要例如“公司财务制度” Level 3全局摘要例如“公司运营管理制度概览”这就是所谓“从局部到全局”的多粒度摘要。GraphRAG 的核心思想之一就是把非结构化文本转化为实体、关系与社区节点构建多层次知识网络使 LLM 能从宏观和微观两个维度理解私有知识库。一个简化流程如下原始文档 ↓ 切分 chunk ↓ 抽取实体、关系、属性 ↓ 构建知识图谱 ↓ 社区发现把强关联实体划分为多个社区 ↓ 为每个社区生成 community report ↓ 递归汇总小社区 → 大社区 → 全局主题腾讯云文档https://cloud.tencent.com/document/product/1759/128202中也把 GraphRAG 描述为自动抽取实体、关系与属性构建可推理、可演进的结构化知识图谱并在问答过程中结合图谱关系推理与语义检索。2.2、例子一大型企业制度库假设公司有 10 万页制度文档包括人事、财务、采购、销售、法务、IT 安全等。用户问“公司当前管理制度里最容易产生跨部门冲突的地方有哪些”基线 RAG 的表现它会根据这个问题召回 Top-k 相似 chunk比如一段采购审批制度一段合同审批制度一段财务付款制度一段权限申请制度。但它很难知道整个语料库里有哪些制度主题也很难主动总结“采购、法务、财务之间的流程冲突”。这就是所谓“只看到几个相似片段看不到全局结构”。传统 RAG 在理解全局主题和跨文档合成信息时存在明显局限。GraphRAG 的表现GraphRAG 可能先形成这些社区社区 1采购申请、供应商准入、比价、招标 社区 2合同审批、法务审查、印章管理 社区 3预算控制、付款审批、发票校验 社区 4权限申请、数据访问、审计日志然后在社区报告上综合出最大的跨部门冲突集中在“采购—合同—付款”链条采购制度强调效率合同制度强调法务风险控制财务制度强调预算和发票合规三者对审批节点、责任人和材料要求存在不一致。建议统一供应商准入、合同审批、付款申请的数据字段和审批状态。这个答案不是来自某一个 chunk而是来自多个社区摘要之间的综合。2.3、例子二客户投诉数据分析假设电商平台有 500 万条客服记录。用户问“最近半年用户不满的核心原因是什么”基线 RAG向量检索可能召回一些投诉片段“物流太慢” “客服不回复” “售后退款慢” “页面显示有货但实际缺货”它能回答局部现象但容易受 Top-k 样本偏差影响。如果 Top-k 里刚好物流投诉多它就可能得出“主要问题是物流”但未必代表全局。GraphRAGGraphRAG 会把实体和关系组织成社区社区 A物流延迟、仓库、配送商、偏远地区 社区 B退款、售后审核、支付渠道、到账时间 社区 C库存显示、前端页面、仓储系统、订单取消 社区 D客服响应、工单分配、机器人转人工然后社区摘要可能发现投诉并不是单一物流问题而是“库存系统不同步 → 用户下单后缺货 → 订单取消 → 退款等待 → 客服压力上升”的链式问题。表面高频词是“退款慢”和“客服差”根因可能是库存同步和订单履约系统。这体现了 GraphRAG 的优势它不仅能总结“用户说了什么”还能通过关系网络总结“问题如何传导”。2.4、例子三科研论文库或行业报告库用户问“过去三年多模态 RAG 的主要技术路线是什么”基线 RAG可能召回几篇包含“multimodal RAG”的论文摘要然后总结成包括图像解析、向量检索、文本生成等方向。这个答案通常偏浅因为它依赖少量 Top-k 论文片段。GraphRAGGraphRAG 可以形成社区社区 A文档解析、OCR、版面分析、表格抽取 社区 B图像 embedding、跨模态检索、CLIP 类模型 社区 C知识图谱、实体关系抽取、多跳推理 社区 DAgentic RAG、工具调用、查询规划 社区 E评测指标、事实一致性、引用可追溯性然后生成更全局的综述多模态 RAG 的主线并不是单纯“图片 文本检索”而是从文档解析、跨模态表征、结构化知识建模、Agentic 查询规划、事实校验五个方向共同演进。其中 GraphRAG 负责补足传统语义检索缺少关系理解的问题。类似的多模态 GraphRAG 实践通常会采用“解析/OCR → 抽取 → Chunk KG 建图 → 向量库与图数据库双存 → Agent 混合检索”的流程这说明复杂文档理解确实需要语义检索和图结构推理结合。2.5、优劣总结维度基线 RAGGraphRAG局部事实问答很强简单高效也能做但成本可能更高多跳推理弱依赖 Top-k 是否刚好召回完整证据强可沿实体关系遍历全局主题总结弱容易样本偏差强可基于社区报告汇总可解释性一般只能引用 chunk较强可展示实体、关系、路径构建成本低高需要抽取、建图、社区发现、摘要维护适合场景简单问答、FAQ、说明书查询金融风控、医疗、保险、企业知识治理、科研综述所以不是 GraphRAG 在所有场景都优于基线 RAG而是当问题从“找一段答案”变成“理解一个知识网络”时GraphRAG 的优势才明显。当前研究也提醒我们RAG 知识图谱并不自动保证真正多跳推理成功很多方法在真实跨源推理问题上仍然可能表现不如预期。
GraphRAG 与 基线 RAG 对比（一）
基线 RAG文档切 chunk → 向量化 → 按相似度 Top-k 召回 → 把片段塞给 LLM 生成答案GraphRAG从文本中抽取实体、关系、属性构建知识图谱并结合图遍历、社区摘要和 LLM 生成答案。局限性基线 RAGGraphRAG串联信息无法通过共享属性遍历不同的信息片段来综合出新见解知识图谱通过关系显式链接实体支持多跳推理整体理解无法对大型数据集中的语义概念进行总结社区层次结构提供从局部到全局的多粒度摘要全局推理Top-K 检索只见树木不见森林对社区报告执行 Map-reduce 操作实现全语料库级别的推理这种差异的核心在于基线 RAG 更擅长“找相似片段”GraphRAG 更擅长“沿关系找证据、跨片段组合知识”。传统 RAG 在跨文档综合、全局主题理解、多跳推理上容易受限而 GraphRAG 通过实体、关系、社区节点构建多层知识网络让 LLM 可以从微观关系和宏观主题两个维度理解知识库。GraphRAG 也常被定义为把知识组织成“实体—关系—实体”的显式图结构从而增强复杂关系推理和多跳查询能力。1、GraphRAG 通过共享属性和显式关系做多跳推理核心差异传统基于向量数据库的基线 RAG 存在“孤立信息检索”的局限性。它仅依赖文本片段的语义相似度进行匹配将文本切分为孤立的语义碎片忽略了实体间的内在关联。当面对需要多步逻辑推导的复杂查询时它只能返回碎片化结果甚至可能因为拼凑信息而产生幻觉。相反GraphRAG 通过引入图数据库如 Neo4j将非结构化文本转化为结构化的知识存储层显式地将信息建模为“实体-关系-属性”的三元组如(公司A)-[投资]-(公司B)。这种图结构赋予了系统图遍历的能力从而支持跨文档的多跳关联检索为大模型提供结构化、可追溯的推理依据。1.1、例子一保险产品咨询——从“疾病”跳到“条款”再跳到“可投产品”假设企业知识库里有三份分散文档文档 A产品 X 的投保规则糖尿病患者需人工核保文档 B产品 Y 的免责条款既往高血压并发症不赔文档 C用户画像客户 45 岁有 2 型糖尿病和高血压病史。基线 RAG 的问题是它可能只召回“糖尿病”相关 chunk或者只召回“高血压免责”相关 chunk但不一定能把“用户疾病画像—核保规则—产品免责—适合产品”这几类信息串起来。传统向量 RAG 主要依赖文本相似度容易把信息当作孤立片段处理忽略实体之间的内在关联。GraphRAG 的做法是把知识抽成类似这样的图客户A --患有-- 2型糖尿病 客户A --患有-- 高血压 产品X --核保要求-- 糖尿病人工核保 产品Y --免责关联-- 高血压并发症 2型糖尿病 --属于-- 慢性病 高血压 --可能导致-- 心脑血管并发症当用户问“这个客户更适合买产品 X 还是产品 Y风险点是什么”GraphRAG 可以沿着路径客户A → 疾病 → 条款 → 产品 → 风险解释做多跳推理最后回答客户 A 同时存在糖尿病和高血压。产品 X 对糖尿病要求人工核保但未必直接免责产品 Y 明确关联高血压并发症免责因此产品 Y 的理赔不确定性更高。建议优先评估产品 X 的核保通过可能性并重点说明糖尿病核保材料要求。这类场景正是 GraphRAG 的典型优势因为保险咨询涉及“产品—条款—人群—疾病”的多条件组合查询知识图谱可以提供更清晰、可解释的建议。1.2、例子二金融风控——通过多跳关系发现隐性关联风险假设有这些分散信息文档 A张三是公司甲的法定代表人文档 B公司甲持有公司乙 35% 股份文档 C公司乙是目标企业丙的核心供应商文档 D公司丙近期申请贷款文档 E张三曾被列入失信被执行人名单。用户问“公司丙是否存在潜在关联风险”基线 RAG可能召回“公司丙贷款申请”或“公司乙供应商”相关内容但如果“张三失信”和“公司丙贷款”没有出现在同一段文本中向量相似度可能不足难以自然连接起来。GraphRAG可以形成路径张三 --法定代表人-- 公司甲 公司甲 --持股-- 公司乙 公司乙 --供应商-- 公司丙 公司丙 --申请-- 贷款 张三 --存在-- 失信记录于是可以推理虽然张三不是公司丙的直接股东或高管但他通过“公司甲—公司乙—公司丙供应链”形成三跳关联。若公司乙对公司丙业务依赖较高则张三的信用风险可能间接影响公司丙供应链稳定性构成潜在关联风险。金融风控正是 GraphRAG 适合的场景之一因为它需要构建企业、人物、交易、股权等复杂关系并通过多跳关系查询识别潜在风险。1.3、例子三医疗知识问答——药物、疾病、症状、禁忌之间的多跳推理假设知识库中有文档 A华法林与阿司匹林合用会增加出血风险文档 B房颤患者常使用华法林抗凝文档 C某患者有胃溃疡病史文档 D阿司匹林可能加重消化道出血风险。用户问“这个房颤患者能不能同时吃华法林和阿司匹林”基线 RAG也许能召回“华法林与阿司匹林相互作用”的片段但它可能忽略患者自身的“胃溃疡病史”这一风险属性尤其当患者病史在另一份文档中时。GraphRAG可以连接患者A --患有-- 房颤 房颤 --治疗药物-- 华法林 华法林 --相互作用-- 阿司匹林 阿司匹林 --风险-- 消化道出血 患者A --既往病史-- 胃溃疡 胃溃疡 --增加风险-- 消化道出血推理结果是患者因房颤可能需要抗凝治疗但华法林与阿司匹林合用会增加出血风险同时患者有胃溃疡病史会进一步提高消化道出血风险。因此需要医生评估是否必须联用并考虑胃黏膜保护、替代方案或更严密监测。医疗知识问答也是 GraphRAG 的典型应用因为疾病、药物、症状、禁忌、相互作用之间天然是图结构适合用关系推理来回答复杂问题。2、GraphRAG 的社区层次结构如何提供从局部到全局的多粒度摘要多粒度摘要的实现方式GraphRAG 的核心思想是通过构建多层次的知识网络来实现从局部到全局的理解。在将非结构化文本转化为“实体”和“关系”后系统会运用社区检测算法如 Leiden 算法将联系紧密的节点聚合成一个个“社区Community”。这些社区呈现出层次结构底层的微观社区包含具体的实体如某个员工、某份财报高层的宏观社区则聚合了多个微观社区如整个部门、整个公司的战略。GraphRAG 会利用大语言模型LLM自下而上地为每一个社区生成摘要报告。这样无论用户询问的是某个具体的细节局部还是整个语料库的宏观主题全局系统都能匹配到对应粒度的摘要进行回答。2.1、GraphRAG 的“社区层次结构”大致怎么实现GraphRAG 不只是把实体连成一张图还会在图上做社区发现。可以理解为如果一批实体之间关系非常密集它们就会形成一个“主题簇”或“知识社区”。例如在一个企业知识库里社区 A报销制度、差旅标准、发票、审批流程 社区 B销售合同、客户分级、折扣政策、续约条款 社区 C数据安全、权限管理、日志审计、合规要求然后 GraphRAG 会为不同层级生成摘要Level 0实体/关系级摘要 Level 1小社区摘要例如“差旅报销流程” Level 2大社区摘要例如“公司财务制度” Level 3全局摘要例如“公司运营管理制度概览”这就是所谓“从局部到全局”的多粒度摘要。GraphRAG 的核心思想之一就是把非结构化文本转化为实体、关系与社区节点构建多层次知识网络使 LLM 能从宏观和微观两个维度理解私有知识库。一个简化流程如下原始文档 ↓ 切分 chunk ↓ 抽取实体、关系、属性 ↓ 构建知识图谱 ↓ 社区发现把强关联实体划分为多个社区 ↓ 为每个社区生成 community report ↓ 递归汇总小社区 → 大社区 → 全局主题腾讯云文档https://cloud.tencent.com/document/product/1759/128202中也把 GraphRAG 描述为自动抽取实体、关系与属性构建可推理、可演进的结构化知识图谱并在问答过程中结合图谱关系推理与语义检索。2.2、例子一大型企业制度库假设公司有 10 万页制度文档包括人事、财务、采购、销售、法务、IT 安全等。用户问“公司当前管理制度里最容易产生跨部门冲突的地方有哪些”基线 RAG 的表现它会根据这个问题召回 Top-k 相似 chunk比如一段采购审批制度一段合同审批制度一段财务付款制度一段权限申请制度。但它很难知道整个语料库里有哪些制度主题也很难主动总结“采购、法务、财务之间的流程冲突”。这就是所谓“只看到几个相似片段看不到全局结构”。传统 RAG 在理解全局主题和跨文档合成信息时存在明显局限。GraphRAG 的表现GraphRAG 可能先形成这些社区社区 1采购申请、供应商准入、比价、招标 社区 2合同审批、法务审查、印章管理 社区 3预算控制、付款审批、发票校验 社区 4权限申请、数据访问、审计日志然后在社区报告上综合出最大的跨部门冲突集中在“采购—合同—付款”链条采购制度强调效率合同制度强调法务风险控制财务制度强调预算和发票合规三者对审批节点、责任人和材料要求存在不一致。建议统一供应商准入、合同审批、付款申请的数据字段和审批状态。这个答案不是来自某一个 chunk而是来自多个社区摘要之间的综合。2.3、例子二客户投诉数据分析假设电商平台有 500 万条客服记录。用户问“最近半年用户不满的核心原因是什么”基线 RAG向量检索可能召回一些投诉片段“物流太慢” “客服不回复” “售后退款慢” “页面显示有货但实际缺货”它能回答局部现象但容易受 Top-k 样本偏差影响。如果 Top-k 里刚好物流投诉多它就可能得出“主要问题是物流”但未必代表全局。GraphRAGGraphRAG 会把实体和关系组织成社区社区 A物流延迟、仓库、配送商、偏远地区 社区 B退款、售后审核、支付渠道、到账时间 社区 C库存显示、前端页面、仓储系统、订单取消 社区 D客服响应、工单分配、机器人转人工然后社区摘要可能发现投诉并不是单一物流问题而是“库存系统不同步 → 用户下单后缺货 → 订单取消 → 退款等待 → 客服压力上升”的链式问题。表面高频词是“退款慢”和“客服差”根因可能是库存同步和订单履约系统。这体现了 GraphRAG 的优势它不仅能总结“用户说了什么”还能通过关系网络总结“问题如何传导”。2.4、例子三科研论文库或行业报告库用户问“过去三年多模态 RAG 的主要技术路线是什么”基线 RAG可能召回几篇包含“multimodal RAG”的论文摘要然后总结成包括图像解析、向量检索、文本生成等方向。这个答案通常偏浅因为它依赖少量 Top-k 论文片段。GraphRAGGraphRAG 可以形成社区社区 A文档解析、OCR、版面分析、表格抽取 社区 B图像 embedding、跨模态检索、CLIP 类模型 社区 C知识图谱、实体关系抽取、多跳推理 社区 DAgentic RAG、工具调用、查询规划 社区 E评测指标、事实一致性、引用可追溯性然后生成更全局的综述多模态 RAG 的主线并不是单纯“图片 文本检索”而是从文档解析、跨模态表征、结构化知识建模、Agentic 查询规划、事实校验五个方向共同演进。其中 GraphRAG 负责补足传统语义检索缺少关系理解的问题。类似的多模态 GraphRAG 实践通常会采用“解析/OCR → 抽取 → Chunk KG 建图 → 向量库与图数据库双存 → Agent 混合检索”的流程这说明复杂文档理解确实需要语义检索和图结构推理结合。2.5、优劣总结维度基线 RAGGraphRAG局部事实问答很强简单高效也能做但成本可能更高多跳推理弱依赖 Top-k 是否刚好召回完整证据强可沿实体关系遍历全局主题总结弱容易样本偏差强可基于社区报告汇总可解释性一般只能引用 chunk较强可展示实体、关系、路径构建成本低高需要抽取、建图、社区发现、摘要维护适合场景简单问答、FAQ、说明书查询金融风控、医疗、保险、企业知识治理、科研综述所以不是 GraphRAG 在所有场景都优于基线 RAG而是当问题从“找一段答案”变成“理解一个知识网络”时GraphRAG 的优势才明显。当前研究也提醒我们RAG 知识图谱并不自动保证真正多跳推理成功很多方法在真实跨源推理问题上仍然可能表现不如预期。
