简介《2025大模型驱动下的知识图谱应用解析实践与案例大合集》是一份面向算法工程师、知识图谱研究人员及企业智能化决策者的PDF专题合集系统梳理了大模型与知识图谱融合落地的8个实践案例。整份资源为1个PDF文件压缩包大小16.72MB内容集中且便于按目录阅读。内容覆盖文档智能解析技术链路OCR-PIPELINE、OCR-Free、PDF-Parse三种方向的优劣对比、表格解析与版面分析难点、多模态GraphRAG构建范式并延伸到金融智能化产品架构、中医临床辅助决策体系、私域知识问答链路以及汽车制造业知识服务等场景。每个案例围绕技术链路与应用落地展开适合希望将大模型能力接入知识管理体系的读者建立全景认知。已有322人学习/浏览是一份兼顾行业案例与技术原理的参考合集。1. 大模型驱动知识图谱应用解析从一份案例大合集到可落地的技术框架把几千份非结构化文档直接喂给大模型做问答得到流畅回答的同时也会得到一本正经的幻觉。一个更务实的做法是让大模型先抽取实体与关系写进知识图谱再基于图谱回答。这类方案在2025年已经成为行业标配网上这类案例合集也正是围绕这个主线展开大模型负责理解与转化知识图谱负责存储与推理。它能解决“模型胡说、检索不精准、业务口径不一致”三类问题适合正在做知识中台、智能客服或行业问答的工程师。下面不逐行复述PDF原文而是把案例背后的技术原理、部署参数和常见坑按可复现的方式串起来。2. 大模型驱动知识图谱的技术路径抽取、融合与图存储知识图谱不是新概念但过去二十年最大的门槛是构建成本。手工定义实体、关系和属性再由标注团队逐个整理一个中型行业图谱要消耗上百人日。大模型把这道门槛压低了你只需要把原始文本交给模型它可以把实体、关系、属性按约束输出成结构化数据。2025年这套玩法已经相当成熟而标题里这8个案例的合集本质上讲的是同一条流水线。2.1 大模型在知识图谱生命周期中的落点实体抽取、关系分类、属性补全不要指望一个通用大模型从零生成整个知识图谱。实际项目中我一般把大模型放在三个位置。第一信息抽取从非结构化或半结构化文本中识别命名实体、关系三元组以及事件类的复杂结构第二知识融合判断两个名字是不是同一个实体比如“中移动”和“中国移动”模型能做语义层面的对齐第三知识补全利用已有三元组推理缺失关系类似补链路的推荐。知识抽取框架 OneKE 这类工具把基座模型微调成专门的抽取器效果通常比通用对话模型稳。图谱生命周期大模型承担的任务不交给大模型的部分常见工具形态构建期实体识别、关系抽取、事件抽取全局ID分配、唯一性约束OneKE、微调的Qwen/GLM、LLM引擎融合期实体对齐、指称消歧、冲突消解确定性规则与人工复核embedding相似度、规则引擎应用期自然语言转Cypher、图谱问答、路径解释事务写入、权限控制LangChain、Dify、Agent大模型负责的是“把文本转成三元组”和“把问题转成查询”而图数据库负责的是“存储”和“查询”。在2.2节我先给出一段能直接运行的抽取代码之后再说明代码里的参数为什么这样设。2.2 一套可跑通的抽取链路从文本到三元组下面的脚本通过 Ollama 的本地接口调用 Qwen2.5 7B 模型让模型只输出JSON格式的三元组数组。这是目前本地部署大模型最常见的链路之一。import json import requests OLLAMA_URL http://localhost:11434/api/chat def extract_triples(text: str, model: str qwen2.5:7b) - list: template ( 请从下面的文本中抽取(实体, 关系, 实体)三元组。 只输出JSON数组不要输出解释。\n 示例[{\head\:\实体A\,\relation\:\关系\,\tail\:\实体B\}]\n f文本{text} ) payload { model: model, messages: [{role: user, content: template}], stream: False, options: { temperature: 0.1, max_tokens: 2048 } } resp requests.post(OLLAMA_URL, jsonpayload, timeout60) resp.raise_for_status() content resp.json()[message][content] content content.strip().removeprefix(json).removesuffix() return json.loads(content) if __name__ __main__: sample 阿司匹林可抑制环氧合酶从而减少前列腺素合成。 triples extract_triples(sample) print(triples)这段代码通过 Ollama 的/api/chat接口调用本地模型streamFalse表示等待完整结果避免流式输出增加解析复杂度。temperature取 0.1抽取任务不能有太高随机性max_tokens按文本长度调整长文档抽三元组超过 2048 会被截断JSON解析就会失败。返回内容有时带 json 包裹先做一次字符清理再json.loads。生产环境建议在template里给出本业务领域的 3 个 few-shot 示例并限定关系词表否则同一类事实会出现“医治”“治疗”“用于治疗”三种关系名。提示如果返回的 JSON 总是带换行和反引号先content.strip().strip()再json.loads不要在正则上折腾。2.3 案例合集背后的统一模式GraphRAG 不是 RAG 的替代品RAG 的短板是检索以文档块为单位跨块的逻辑关系容易碎。GraphRAG 的做法是先建图再沿关系路径检索。标题里的8个案例不管来自医疗、金融还是工业落地链路基本一致非结构化文本 → LLM抽取 → Neo4j 或其他图库 → 图上查询 → LLM生成。区别只在图谱的规模、实体粒度和查询方式。这个模式下图谱不是替代 RAG而是给 RAG 加了一条结构化上下文通道。做这类案例拆解时可以先按这条主线给每个案例归类例如哪个案例偏重构建哪个偏重问答哪个偏重推理。3. 从0到1用LLM落地知识图谱环境搭建与必调参数光讲原理容易飘下面是一套在本地真正跑通过的最小方案。你会用到两个组件Neo4j 做图存储Ollama 或 vLLM 做大模型推理。整套环境在一台 16GB 显存的消费级显卡上就能跑起来。3.1 为什么选 Neo4j 而不是自建边表很多人拿到三元组后直接往 MySQL 里塞结果做多跳查询时 SQL 越写越长。Neo4j 的优势不是存储而是 Cypher 的关系遍历能力一次多跳路径查询在 SQL 里要 JOIN 七八次在 Cypher 里就是 MATCH 一条路径。社区版就够学习和中小型项目线上场景再评估集群扩展。另外Neo4j Browser 可以直接可视化图谱调试抽取结果非常方便这也是构建知识图谱时我优先选它的原因。3.2 本地部署与数据写入Ollama Python Neo4j 最小链路先用 Docker 启动 Neo4j再用 Ollama 拉取模型。如果你已经有 vLLM 或者其他 OpenAI 兼容服务可以把下面的抽取地址整体替换。docker run -d --name neo4j \ -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTHneo4j/yourpass \ neo4j:5-community ollama pull qwen2.5:7b ollama run qwen2.5:7bDocker启动时7474是浏览器端口7687是 Bolt 驱动端口。NEO4J_AUTH必填否则容器会初始化失败。Ollama 启动后先单独跑一次ollama run qwen2.5:7b确认模型能正常对话再进入写入步骤。from neo4j import GraphDatabase driver GraphDatabase.driver( bolt://localhost:7687, auth(neo4j, yourpass) ) def save_triples(triples, batch500): with driver.session() as session: for i in range(0, len(triples), batch): session.execute_write(save_batch, triples[i:ibatch]) def save_batch(tx, batch): for t in batch: tx.run( MERGE (h:Entity {name: $head}) MERGE (t:Entity {name: $tail}) MERGE (h)-[r:RELATION {name: $rel}]-(t) , headt[head], tailt[tail], relt[relation] )写入时必须用MERGE而不是CREATE因为MERGE会按name属性去重实体名完全相同时不会产生重复节点。这里按 500 条一批写入避免大事务把内存顶满。如果确实要支持同一个实体类型下的不同标签可以把Entity换成:Customer或:Drug这类更具体的标签。生产级写法还会给节点加source、updated_at等属性用于溯源。3.3 知识抽取的5个必调参数温度、上下文、批量、top_p、重复惩罚这组参数在 Ollama、vLLM、以及各类 OneKE 类抽取框架中都会遇到设置逻辑基本一致。参数建议值控制的内容异常表现temperature0 ~ 0.3生成随机性太高时关系名出现“可能、大概”top_p0.8 ~ 0.9采样候选集裁剪太低时实体变少上下文窗口截断到3000~6000 tokens单次送入文本量太长容易漏关系且耗时批量大小8 ~ 32 条请求并发与吞吐太大会触发输出截断频率惩罚0.1 ~ 0.5避免重复实体太高导致实体被替换成同义词在 Ollama 中temperature、top_p写在options里批量大小由调用方控制并发请求数上下文窗口受模型本身限制超过后必须丢弃中间段落。vLLM 部署时批量大小对应--max-num-seqs。我一般先用小批量8跑通再逐步加到32。失败时先看是不是 JSON 解析失败再调max_tokens最后才动温度。3.4 图模型设计节点、关系和属性怎么定才不过度设计知识图谱最容易犯的错是把所有信息都建节点。设计时先问一句这个属性是否需要参与关系遍历比如人的生卒年是单个时间值直接做属性如果要做“找所有出生于1990年后的人”属性加索引就够了。实体类型标签不宜过细先统一成Entity后续再按领域打二级标签。关系命名用动词而非状态比如“生产”比“相关”有区分度。先在小规模子集上跑一遍用 Neo4j Browser 预览图结构反复调整后再做全量抽取。4. 案例合集拆解医疗、金融、工业与科研文本的模型选型与图查询从标题里的8个案例看大模型驱动知识图谱的应用场景差异很大但工程上可以按文本类型分成四类。每一类对模型能力的要求、对图查询的模式都不一样。4.1 按文本类型选模型专业术语多的场景怎么配本地大模型领域文本特征常见模型方案图查询重点医疗病历/药品说明书术语密集、缩写多Qwen2.5-7B 术语表 few-shot药品-靶点-适应症路径金融研报/公告数字多、事件时间敏感GLM-4-9B 时间抽取优化公司-事件-行业传导链工业设备日志/故障单工单格式、标准动作多Llama3.1-8B 规范关系词表设备-故障-维修动作科研文献/专利长句、引用关系多抽取专用 OneKE 微调模型论文-方法-数据集关联本地部署配置上7B~9B参数的模型量化后大约5到8GB单卡24GB可以同时跑抽取和向量化。如果显存只有16GB优先选4bit量化版本。如果抽取质量不达标不要盲目换更大模型先补充领域词表并在 prompt 中给5个针对性示例效果往往提升更明显。4.2 vLLM 服务化部署并发抽取时的吞吐配置与踩坑当抽取量达到十万级文本时Ollama 的单请求并发会成为瓶颈。常见做法是把模型切到 vLLM 部署通过 OpenAI 兼容接口对外服务。vllm serve qwen2.5:7b \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 32 \ --enforce-eager用 vLLM 部署后前面的抽取脚本可以把 Ollama 地址换成http://localhost:8000/v1/chat/completions请求格式基本不用改。--max-model-len决定单序列最大上下文--max-num-seqs决定并发序列数不是越大越好32是7B模型在24GB显存上的常用起点。--gpu-memory-utilization设0.85是给 KV cache 和预填充留余量。常见坑是请求一多就排队等待先看/metrics里的队列长度再逐步加大并发不要只盯 GPU 利用率。4.3 图谱质量校验实体对齐、去重和关系置信度的三种做法实体对齐最简单的方法是字符串归一化大小写、全半角、公司后缀统一。import re import difflib def normalize(name: str) - str: name name.replace(, ().replace(, )) name name.lower().strip() return re.sub(r\s, , name) def deduplicate(names, threshold0.9): groups [] for name in names: n normalize(name) for g in groups: if difflib.SequenceMatcher(None, n, normalize(g[0])).ratio() threshold: g.append(name) break else: groups.append([name]) return groups这个平方级方法只适合小图谱。百万节点级时先按首字母或哈希桶分桶再用向量相似度做候选对。关系置信度可以从同一三元组在多个文档出现的次数统计例如在 Neo4j 给每个RELATION增加evidence属性写入时每次出现累加一次应用查询时按evidence排序。除了自动对齐每一类案例留20个人工标注三元组做抽检比只看几个样例有效得多。5. 让图谱真正服务大模型应用GraphRAG 召回验证与反幻觉技巧5.1 用 Cypher 把图查询变成上下文再拼进提示词构建完图谱后最常见的应用是让大模型基于图数据回答。这里的关键是把图查询结果压缩成紧凑的三元组列表再喂给生成模型。MATCH (h:Entity {name: $query})-[r:RELATION]-(t:Entity) RETURN h.name, r.name, t.name LIMIT 30prompt f根据下面的知识图谱三元组回答问题只允许使用给出的信息。 三元组 {triples} 问题{question} 这种上下文比纯文本块更紧凑可减少模型受无关文档干扰。因为是结构化信息模型自由发挥的空间被压缩。注意查询时先用实体识别把用户问题映射成图节点名直接拿原始问题去匹配图谱经常失败。5.2 召回效果怎么量化实体命中率与路径覆盖度指标计算方式观察目的实体命中率图谱检索到的实体 / 人工标注实体抽取覆盖度路径覆盖度答案相关路径数 / 需要路径数图结构完整性幻觉率生成结果中无支撑的实体/关系数可靠度工程上可以先准备20个问题和对应答案基于图谱生成候选答案再按这三档人工打分。幻觉率高于15%时优先看图谱查询是否查到空路径而不是立刻换一个大模型常见原因是抽取阶段漏关系而不是生成阶段不听话。把 Cypher 里的LIMIT调大、对关系类型做偏好排序往往比换模型见效快。本文还有配套的精品资源点击获取 大模型驱动知识图谱：从三元组抽取到GraphRAG落地
简介《2025大模型驱动下的知识图谱应用解析实践与案例大合集》是一份面向算法工程师、知识图谱研究人员及企业智能化决策者的PDF专题合集系统梳理了大模型与知识图谱融合落地的8个实践案例。整份资源为1个PDF文件压缩包大小16.72MB内容集中且便于按目录阅读。内容覆盖文档智能解析技术链路OCR-PIPELINE、OCR-Free、PDF-Parse三种方向的优劣对比、表格解析与版面分析难点、多模态GraphRAG构建范式并延伸到金融智能化产品架构、中医临床辅助决策体系、私域知识问答链路以及汽车制造业知识服务等场景。每个案例围绕技术链路与应用落地展开适合希望将大模型能力接入知识管理体系的读者建立全景认知。已有322人学习/浏览是一份兼顾行业案例与技术原理的参考合集。1. 大模型驱动知识图谱应用解析从一份案例大合集到可落地的技术框架把几千份非结构化文档直接喂给大模型做问答得到流畅回答的同时也会得到一本正经的幻觉。一个更务实的做法是让大模型先抽取实体与关系写进知识图谱再基于图谱回答。这类方案在2025年已经成为行业标配网上这类案例合集也正是围绕这个主线展开大模型负责理解与转化知识图谱负责存储与推理。它能解决“模型胡说、检索不精准、业务口径不一致”三类问题适合正在做知识中台、智能客服或行业问答的工程师。下面不逐行复述PDF原文而是把案例背后的技术原理、部署参数和常见坑按可复现的方式串起来。2. 大模型驱动知识图谱的技术路径抽取、融合与图存储知识图谱不是新概念但过去二十年最大的门槛是构建成本。手工定义实体、关系和属性再由标注团队逐个整理一个中型行业图谱要消耗上百人日。大模型把这道门槛压低了你只需要把原始文本交给模型它可以把实体、关系、属性按约束输出成结构化数据。2025年这套玩法已经相当成熟而标题里这8个案例的合集本质上讲的是同一条流水线。2.1 大模型在知识图谱生命周期中的落点实体抽取、关系分类、属性补全不要指望一个通用大模型从零生成整个知识图谱。实际项目中我一般把大模型放在三个位置。第一信息抽取从非结构化或半结构化文本中识别命名实体、关系三元组以及事件类的复杂结构第二知识融合判断两个名字是不是同一个实体比如“中移动”和“中国移动”模型能做语义层面的对齐第三知识补全利用已有三元组推理缺失关系类似补链路的推荐。知识抽取框架 OneKE 这类工具把基座模型微调成专门的抽取器效果通常比通用对话模型稳。图谱生命周期大模型承担的任务不交给大模型的部分常见工具形态构建期实体识别、关系抽取、事件抽取全局ID分配、唯一性约束OneKE、微调的Qwen/GLM、LLM引擎融合期实体对齐、指称消歧、冲突消解确定性规则与人工复核embedding相似度、规则引擎应用期自然语言转Cypher、图谱问答、路径解释事务写入、权限控制LangChain、Dify、Agent大模型负责的是“把文本转成三元组”和“把问题转成查询”而图数据库负责的是“存储”和“查询”。在2.2节我先给出一段能直接运行的抽取代码之后再说明代码里的参数为什么这样设。2.2 一套可跑通的抽取链路从文本到三元组下面的脚本通过 Ollama 的本地接口调用 Qwen2.5 7B 模型让模型只输出JSON格式的三元组数组。这是目前本地部署大模型最常见的链路之一。import json import requests OLLAMA_URL http://localhost:11434/api/chat def extract_triples(text: str, model: str qwen2.5:7b) - list: template ( 请从下面的文本中抽取(实体, 关系, 实体)三元组。 只输出JSON数组不要输出解释。\n 示例[{\head\:\实体A\,\relation\:\关系\,\tail\:\实体B\}]\n f文本{text} ) payload { model: model, messages: [{role: user, content: template}], stream: False, options: { temperature: 0.1, max_tokens: 2048 } } resp requests.post(OLLAMA_URL, jsonpayload, timeout60) resp.raise_for_status() content resp.json()[message][content] content content.strip().removeprefix(json).removesuffix() return json.loads(content) if __name__ __main__: sample 阿司匹林可抑制环氧合酶从而减少前列腺素合成。 triples extract_triples(sample) print(triples)这段代码通过 Ollama 的/api/chat接口调用本地模型streamFalse表示等待完整结果避免流式输出增加解析复杂度。temperature取 0.1抽取任务不能有太高随机性max_tokens按文本长度调整长文档抽三元组超过 2048 会被截断JSON解析就会失败。返回内容有时带 json 包裹先做一次字符清理再json.loads。生产环境建议在template里给出本业务领域的 3 个 few-shot 示例并限定关系词表否则同一类事实会出现“医治”“治疗”“用于治疗”三种关系名。提示如果返回的 JSON 总是带换行和反引号先content.strip().strip()再json.loads不要在正则上折腾。2.3 案例合集背后的统一模式GraphRAG 不是 RAG 的替代品RAG 的短板是检索以文档块为单位跨块的逻辑关系容易碎。GraphRAG 的做法是先建图再沿关系路径检索。标题里的8个案例不管来自医疗、金融还是工业落地链路基本一致非结构化文本 → LLM抽取 → Neo4j 或其他图库 → 图上查询 → LLM生成。区别只在图谱的规模、实体粒度和查询方式。这个模式下图谱不是替代 RAG而是给 RAG 加了一条结构化上下文通道。做这类案例拆解时可以先按这条主线给每个案例归类例如哪个案例偏重构建哪个偏重问答哪个偏重推理。3. 从0到1用LLM落地知识图谱环境搭建与必调参数光讲原理容易飘下面是一套在本地真正跑通过的最小方案。你会用到两个组件Neo4j 做图存储Ollama 或 vLLM 做大模型推理。整套环境在一台 16GB 显存的消费级显卡上就能跑起来。3.1 为什么选 Neo4j 而不是自建边表很多人拿到三元组后直接往 MySQL 里塞结果做多跳查询时 SQL 越写越长。Neo4j 的优势不是存储而是 Cypher 的关系遍历能力一次多跳路径查询在 SQL 里要 JOIN 七八次在 Cypher 里就是 MATCH 一条路径。社区版就够学习和中小型项目线上场景再评估集群扩展。另外Neo4j Browser 可以直接可视化图谱调试抽取结果非常方便这也是构建知识图谱时我优先选它的原因。3.2 本地部署与数据写入Ollama Python Neo4j 最小链路先用 Docker 启动 Neo4j再用 Ollama 拉取模型。如果你已经有 vLLM 或者其他 OpenAI 兼容服务可以把下面的抽取地址整体替换。docker run -d --name neo4j \ -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTHneo4j/yourpass \ neo4j:5-community ollama pull qwen2.5:7b ollama run qwen2.5:7bDocker启动时7474是浏览器端口7687是 Bolt 驱动端口。NEO4J_AUTH必填否则容器会初始化失败。Ollama 启动后先单独跑一次ollama run qwen2.5:7b确认模型能正常对话再进入写入步骤。from neo4j import GraphDatabase driver GraphDatabase.driver( bolt://localhost:7687, auth(neo4j, yourpass) ) def save_triples(triples, batch500): with driver.session() as session: for i in range(0, len(triples), batch): session.execute_write(save_batch, triples[i:ibatch]) def save_batch(tx, batch): for t in batch: tx.run( MERGE (h:Entity {name: $head}) MERGE (t:Entity {name: $tail}) MERGE (h)-[r:RELATION {name: $rel}]-(t) , headt[head], tailt[tail], relt[relation] )写入时必须用MERGE而不是CREATE因为MERGE会按name属性去重实体名完全相同时不会产生重复节点。这里按 500 条一批写入避免大事务把内存顶满。如果确实要支持同一个实体类型下的不同标签可以把Entity换成:Customer或:Drug这类更具体的标签。生产级写法还会给节点加source、updated_at等属性用于溯源。3.3 知识抽取的5个必调参数温度、上下文、批量、top_p、重复惩罚这组参数在 Ollama、vLLM、以及各类 OneKE 类抽取框架中都会遇到设置逻辑基本一致。参数建议值控制的内容异常表现temperature0 ~ 0.3生成随机性太高时关系名出现“可能、大概”top_p0.8 ~ 0.9采样候选集裁剪太低时实体变少上下文窗口截断到3000~6000 tokens单次送入文本量太长容易漏关系且耗时批量大小8 ~ 32 条请求并发与吞吐太大会触发输出截断频率惩罚0.1 ~ 0.5避免重复实体太高导致实体被替换成同义词在 Ollama 中temperature、top_p写在options里批量大小由调用方控制并发请求数上下文窗口受模型本身限制超过后必须丢弃中间段落。vLLM 部署时批量大小对应--max-num-seqs。我一般先用小批量8跑通再逐步加到32。失败时先看是不是 JSON 解析失败再调max_tokens最后才动温度。3.4 图模型设计节点、关系和属性怎么定才不过度设计知识图谱最容易犯的错是把所有信息都建节点。设计时先问一句这个属性是否需要参与关系遍历比如人的生卒年是单个时间值直接做属性如果要做“找所有出生于1990年后的人”属性加索引就够了。实体类型标签不宜过细先统一成Entity后续再按领域打二级标签。关系命名用动词而非状态比如“生产”比“相关”有区分度。先在小规模子集上跑一遍用 Neo4j Browser 预览图结构反复调整后再做全量抽取。4. 案例合集拆解医疗、金融、工业与科研文本的模型选型与图查询从标题里的8个案例看大模型驱动知识图谱的应用场景差异很大但工程上可以按文本类型分成四类。每一类对模型能力的要求、对图查询的模式都不一样。4.1 按文本类型选模型专业术语多的场景怎么配本地大模型领域文本特征常见模型方案图查询重点医疗病历/药品说明书术语密集、缩写多Qwen2.5-7B 术语表 few-shot药品-靶点-适应症路径金融研报/公告数字多、事件时间敏感GLM-4-9B 时间抽取优化公司-事件-行业传导链工业设备日志/故障单工单格式、标准动作多Llama3.1-8B 规范关系词表设备-故障-维修动作科研文献/专利长句、引用关系多抽取专用 OneKE 微调模型论文-方法-数据集关联本地部署配置上7B~9B参数的模型量化后大约5到8GB单卡24GB可以同时跑抽取和向量化。如果显存只有16GB优先选4bit量化版本。如果抽取质量不达标不要盲目换更大模型先补充领域词表并在 prompt 中给5个针对性示例效果往往提升更明显。4.2 vLLM 服务化部署并发抽取时的吞吐配置与踩坑当抽取量达到十万级文本时Ollama 的单请求并发会成为瓶颈。常见做法是把模型切到 vLLM 部署通过 OpenAI 兼容接口对外服务。vllm serve qwen2.5:7b \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 32 \ --enforce-eager用 vLLM 部署后前面的抽取脚本可以把 Ollama 地址换成http://localhost:8000/v1/chat/completions请求格式基本不用改。--max-model-len决定单序列最大上下文--max-num-seqs决定并发序列数不是越大越好32是7B模型在24GB显存上的常用起点。--gpu-memory-utilization设0.85是给 KV cache 和预填充留余量。常见坑是请求一多就排队等待先看/metrics里的队列长度再逐步加大并发不要只盯 GPU 利用率。4.3 图谱质量校验实体对齐、去重和关系置信度的三种做法实体对齐最简单的方法是字符串归一化大小写、全半角、公司后缀统一。import re import difflib def normalize(name: str) - str: name name.replace(, ().replace(, )) name name.lower().strip() return re.sub(r\s, , name) def deduplicate(names, threshold0.9): groups [] for name in names: n normalize(name) for g in groups: if difflib.SequenceMatcher(None, n, normalize(g[0])).ratio() threshold: g.append(name) break else: groups.append([name]) return groups这个平方级方法只适合小图谱。百万节点级时先按首字母或哈希桶分桶再用向量相似度做候选对。关系置信度可以从同一三元组在多个文档出现的次数统计例如在 Neo4j 给每个RELATION增加evidence属性写入时每次出现累加一次应用查询时按evidence排序。除了自动对齐每一类案例留20个人工标注三元组做抽检比只看几个样例有效得多。5. 让图谱真正服务大模型应用GraphRAG 召回验证与反幻觉技巧5.1 用 Cypher 把图查询变成上下文再拼进提示词构建完图谱后最常见的应用是让大模型基于图数据回答。这里的关键是把图查询结果压缩成紧凑的三元组列表再喂给生成模型。MATCH (h:Entity {name: $query})-[r:RELATION]-(t:Entity) RETURN h.name, r.name, t.name LIMIT 30prompt f根据下面的知识图谱三元组回答问题只允许使用给出的信息。 三元组 {triples} 问题{question} 这种上下文比纯文本块更紧凑可减少模型受无关文档干扰。因为是结构化信息模型自由发挥的空间被压缩。注意查询时先用实体识别把用户问题映射成图节点名直接拿原始问题去匹配图谱经常失败。5.2 召回效果怎么量化实体命中率与路径覆盖度指标计算方式观察目的实体命中率图谱检索到的实体 / 人工标注实体抽取覆盖度路径覆盖度答案相关路径数 / 需要路径数图结构完整性幻觉率生成结果中无支撑的实体/关系数可靠度工程上可以先准备20个问题和对应答案基于图谱生成候选答案再按这三档人工打分。幻觉率高于15%时优先看图谱查询是否查到空路径而不是立刻换一个大模型常见原因是抽取阶段漏关系而不是生成阶段不听话。把 Cypher 里的LIMIT调大、对关系类型做偏好排序往往比换模型见效快。本文还有配套的精品资源点击获取