GraphRAG整个Pipeline可划分为索引(Indexing)与查询(Query)两个阶段。索引过程利用LLM提取出节点（如实体）、边（如关系）和协变量（如 claim），然后利用社区检测技术对整个知识图谱进行划分，再利用LLM进一步总结。最终针对特定的查询，可以汇总所有与之相关的社区摘要生成一个全局性的答案。
• GraphRAG借助大语言模型处理整个数据集，以提取实体和关系，从而构建起全面的知识图谱的基本要素。
• GraphRAG运用社区检测算法，识别紧密相关实体的集群，随后系统生成这些实体及其关系的嵌入表示，从而实现高效的语义搜索功能。
• 当有查询接入时，GraphRAG可以执行两类搜索。对于宽泛性的问题，通过使用全局搜索，遍历整个图谱以总结主题和概念。对于具体的查询，则采用局部搜索，提取相关的子图，并结合图结构与原始文本数据以提供详细的且有上下文的答案。
面对GraphRAG落地过程中存在的挑战，我们通过项目实践，总结出一套切实有效的方法，使得RAG问答，特别是全局问答效果显著提升。
（1）适配本地模型服务
为了更好地支持OpenAI接口方式，选择并本地部署合适的大模型服务和嵌入模型服务。比如，通过评估大模型在自然语言处理任务中的准确性和效率，以及嵌入模型在向量表示方面的优劣等，选择适合的本地部署大模型。
此外，鉴于本地嵌入模型服务仅接受文本输入，所以有必要修改GraphRAG 源码。具体做法是把嵌入模型服务的输入由token ids 转换为文本，之后再把文本输入本地嵌入模型服务，以确保成GraphRAG 与本地模型服务的无缝适配。
（2）支持更多文件类型和切分方式
• 增加多种文件类型解析：在GraphRAG中，接入当前RAG能力中多种文件类型的解析和切分能力。例如，通过增加对pdf，word，excel，html，markdown等文件类型的加载，从而使GraphRAG能够处理更多类型的文件。
• 提供灵活切分策略：GraphRAG提供了灵活的文本切分策略，既可以根据token数量来切割，有助于控制输入到模型中的文本长度，避免过长或过短的文本对模型性能产生不利影响；也可以基于句子结构来进行划分，更符合语言的自然逻辑。为了更好地适应不同文件的特点，在实际应用时需采取多种合适的切分方法。比如，对于某些特定格式的文件，可以采用循环字符切分，适用于具有特定字符模式的文件；按页分割，常用于文档类文件；按行拆解，对于一些以行为单位组织的文件很有效；根据章节目录进行组织，适合结构清晰、有章节划分的文件。通过这些灵活的切分方式，以进一步提升GraphRAG在各种场景下的实用性和有效性。
（3）指定实体类型提取实体
• 取消默认实体类型设置：在 GraphRAG 进行文本实体提取时，原本需用户指定实体类型列表，以助力大模型完成实体抽取工作；若用户未指定，则会启用默认实体类型，如 organization（组织）、person（人物）、geo（地理）、event（事件）。然而，默认的实体类型可能并不总是与用户的特定文本内容完全匹配。为解决该问题，取消了默认实体类型的设置，改为让大模型自己根据文本进行实体抽取，并输出对应的实体类型。
• 用户可编辑实体类型：允许用户对大模型自动提取的实体类型加以编辑。大模型抽取实体后，用户可以根据自己对文本内容的理解和实际需求，对实体类型进行调整和优化。随后基于用户优化后的实体类型构建图谱，这样可以在一定程度上保障构建的图谱质量，使图谱更符合实际应用场景的需求。
（4）Prompt提示词场景优化
• 提示词汉化及优化：在GraphRAG中，实体抽取，关系抽取，摘要生成和问答等操作均借助了大模型进行处理，而这些环节都涉及到提示词工程。首先进行提示词汉化，将默认的英文提示词转换为中文，以便更好地适应中文用户的需求。然后针对应用场景进行优化，根据不同的应用场景特点，调整提示词的内容和表达方式，使GraphRAG能够更好地理解用户的需求，显著提升了GraphRAG在特定应用场景下的效果。例如，在医疗领域应用时，提示词要更侧重于医学术语和相关概念；在金融领域应用时，则要突出金融相关的词汇和逻辑。
• 统一配置管理：如图 4，将这些提示词模板整合起来并放置在一个config 文件夹中，以便于对提示词进行修改和更新，并在不同的应用场景中快速切换和使用合适的提示词模板。
图4：统一配置提示词模板
（5）问题属性判断
• 明确问答方式及逻辑：在进行GraphRAG问答时，需要用户指定问答方式，即选择全局问答还是局部问答，因为不同的问答方式背后的处理逻辑不同。
• 局部问答逻辑：在进行局部问答时，需要提供实体，关系，社区摘要以及文本块，然后根据query通过向量相似方法寻找与之相关的实体，再基于这些相关实体去查找相关边，从而构建local_context。同时，根据上述相关实体，寻找与query相关的社区，构建出community_context。最终final_context包含local_context，community_context，以及相关知识块，将final_context用于构建search_prompt并送入大模型，这样大模型就可以对query进行局部检索问答。
• 全局问答逻辑：进行全局问答时，主要以社区摘要信息为依据进行检索，检索过程分为map和reduce两个阶段。在map阶段，根据query对社区摘要提取关键点，在reduce阶段，则基于所有提取出的关键点和query得到最终回答。
• 默认与可选设置：由于局部问答和全局问答的检索逻辑存在差异，以明确query属于摘要性的全局问题还是局部问题，对检索结果极为重要。GraphRAG在处理全局问答方面表现出色，同时也具备处理局部问答的能力。因此，默认使用全局方式进行问答，但同时也支持用户根据自己的需求选择使用何种方式进行问答，使得GraphRAG能够更加灵活地适应不同用户的需求。
（6）图谱构建中的性能权衡
GraphRAG 内部会依次对文本块进行实体与边信息的提取，也会逐个为社区生成摘要。在这个过程中，若处理某个文本块或社区时大模型调用出错，内部会捕获异常，这可能致使pipeline执行看似 “成功”，但却未得到预期结果。由此可见，大模型调用服务在图谱构建流程中是极为关键的步骤，需要确保在出现错误时能够及时发现并采取相应措施，避免错误结果对图谱构建质量产生严重影响。
当多个任务并发时，必然会有部分大模型请求处于等待状态。此时，请求的超时时间、最大重试次数等参数决定了大模型调用能否成功。所以，应当依据所选用的大模型情况以及应用场景，确定恰当的大模型请求参数。例如，如果选用的大模型响应速度较快，可以适当缩短超时时间；如果发现大部分请求在首次尝试时就成功了，可以适当减少重试次数；如果经常遇到网络波动，可以增加重试次数。通过合理确定这些参数，在效率和结果之间达成最佳平衡，提高图谱构建的性能。
粤ICP备14082021号
免费POC，
零成本试错
