GraphRAG实际表现评测：在中文处理方面表现欠佳

文章结果是通过本地部署Ollama+Gemma2+bge-large-zh-v1.5实测中文处理的各种问题记录下。

GraphRAG处理数据基本分为以下几个过程

├── create_base_text_units 文章分片段

├── create_base_extracted_entities 提取基础实体对象

├── create_summarized_entities 创建实体信息摘要

├── create_base_entity_graph 创建对象关系图

├── create_final_entities 创建最终实体

├── create_final_nodes 创建最终节点数据

├── create_final_communities 创建最终社区数据

├── join_text_units_to_entity_ids 关联数据

├── create_final_relationships 创建关系

├── join_text_units_to_relationship_ids 创建片段-关系

└── create_final_community_reports 创建最终社区报告

上文提到过项目自带的prompt模版都是英文的，中英文混合处理的时候大模型容易出现结果混乱。上文

我们翻译中文prompt后直接运行，发现存储的缓存文件全部ascii编码了，造成的结果是调用大模型的部分结果直接传递了ascii的编码过去，结果缓存中可以看到存储的数据中有大模型回答"你发给我的是unicode数据我没法回答啊"

实体数据缓存

通过查找源码找到缓存生成路径

Lib\site-packages\graphrag\index\cache\json_pipeline_cache.py async def set(self, key: str, value: Any, debug_data: dict | None = None) -> None: """Set method definition.""" if value is None: return data = {"result": value, **(debug_data or {})} await self._storage.set(key, json.dumps(data, ensure_ascii=False), encoding=self._encoding)

改变json.dumps方法的入参，让其不强制转ascii码，改完之后发现好了

数据存的都很好，另外我简单改了下promt中文，因为很多时候开源大模型不能很好理解并返回结构化数据

简单一要求就好。

数据全整好了，但是很郁闷的是！发起local和global查询的时候发现文本超出本地开源大模型的上下文长度限制了。另外不得不说这地方挺难定位的，超出上下文限制也没个提示，就是回答问题不上道！（可能是最近实操少了。。）

需要说明的是项目里自带的local和global提问system prompt也是英文的，我给改成了中文

由于ollama兼容的open ai接口没有找到修改上下文限制的参数，我最终将prompt的提示整个放到了open-ui中测试的效果

实测发现这玩意剧费token，不管是数据处理阶段还是最终提问阶段。

等待大神出完美兼容开源大模型和可以处理中文的GraphRAG再实测一下。

结论：

一点也不节省token

现有项目框架用来处理中文数据，基本不可行，需要很多地方进行手动调整

由于大模型在返回结构化数据的时候存在较大的不稳定性和不可控性，很容易造成数据偏差和数据不可用

新闻的标题为了博人眼球经常夸大事实，实践是检验真理的唯一标准[呲牙]