1. 概念图谱：这四兄弟到底谁是谁？
先说个结论：本体（Ontology）、知识图谱（Knowledge Graph）、RAG、GraphRAG，这四个词其实不在同一个维度上，但它们经常被放在一起讨论，因为这四者恰好能拼出一条完整的LLM应用增强链路。
我用大白话把这四兄弟掰开揉碎讲清楚。
1.1 本体（Ontology）：给世界画一张“概念定义表”
本体在计算机科学里的定义是“对某一领域概念的显式、形式化、规范化的描述”。听起来拗口，但说白了，本体就是在回答三件事：
- 这个领域里有哪些概念（类/Class）
- 概念之间是什么关系（对象属性/Object Property）
- 概念本身有哪些属性（数据属性/Data Property）
举个例子。你在做招聘领域的AI助手，那你可能需要定义一个“候选人”类，一个“职位”类，然后是“候选人 投递 职位”、“职位 属于 公司”、“候选人 拥有 技能”这些关系。这就是一个很完整的小本体。
> 注意：本体不是数据，它是数据的“说明书”。就像《新华字典》解释字义，本体解释的是概念、关系、约束，但它本身不含具体的张三李四。这决定了後面知识图谱和RAG的分工。
很多朋友把本体和知识图谱当成一回事，其实完全不是。本体更抽象，知识图谱更具体——你可以把知识图谱理解成“套用本体模板之后填上真实数据形成的具体图”。用工程语言说：本体是Schema，知识图谱是Schema + Data。
1.2 知识图谱（Knowledge Graph）：把数据织成网
知识图谱是以图结构（点、边、属性）来存储和表达知识的数据形态。点是实体，边是关系。拿招聘场景来讲，图谱里会有一个点叫“张三”，一个点叫“阿里巴巴”，然后一条边“张三-投递-阿里巴巴”。
知识图谱最大的价值在于：它能让机器以“关系”为线索进行推理和查询。比如“张三投了阿里，阿里要求P7以上，张三的职级是P6”——这个推理链路在关系型数据库里写SQL要关联三张表，在图里一跳就出来了。
知识图谱这几年在企业行业用得很多，比如银行做客户关联风险分析、电商做商品推荐血缘、医疗做疾病和药品关系推理，本质上都是在用图谱的关系表达力做“多跳”问题。
1.3 RAG（检索增强生成）：给大模型装一个“外接硬盘”
RAG全称是Retrieval-Augmented Generation，中文是检索增强生成。它的核心思路不复杂：当用户问大模型一个问题，系统先去一个外置的知识库（向量库为主）里检索出相关的内容片段，把这些片段连同用户问题一起拼进Prompt，送给大模型，让大模型基于这些材料作答。
这个方案解决了LLM的两个大痛点：
- 幻觉问题：模型对不知道的知识会一本正经地胡说八道。
- 知识陈旧问题：模型训练数据有截止时间，新知识它不知道。
RAG的做法等于让模型考试时带教材进场。教材里的内容检索得准，模型就能答得准；检索不到，模型就只能靠瞎猜。
1.4 GraphRAG：给RAG加上“关系推理翅膀”
GraphRAG是微软在2024年提出的一种进阶RAG架构。它的关键洞察是：传统的向量RAG只能做“相似度匹配”——你在教材里找跟问题字面上像的内容。但很多问题靠相似度是解不了的，比如“谁影响了张三的晋升决策”，这种问题需要对知识做多跳关系推理。向量检索在“单段文本找答案”上很好，但一到“跨实体找关系”，就只能干瞪眼。
GraphRAG的做法是：在RAG前面的知识组织阶段，先构建一份领域知识图谱，然后在检索和推理阶段，既做向量相似度检索，也做图的子图检索、多跳遍历、社群检测（Community Detection）等分析操作，把从图里挖出来的结构化关系一并喂给大模型。这样模型既看到了文本细节，又理解了实体间的深层关系网络。
到此，四兄弟的关系可以一句话总结：本体是图纸，知识图谱是照着图纸盖出来的楼，RAG是让大模型能在楼里快速翻书查资料，GraphRAG是让大模型既能翻书，又能顺着楼里的管道和水电线路摸出隐藏的关系。
2. 四个核心应用场景：哪里真正用得上？
概念讲明白了，接下来聊落地。说实话，这几种技术各有各的脾气，用错场景就是杀鸡用牛刀，甚至牛刀还割不动鸡。我按实际项目中最常遇到的四类场景来拆解。
2.1 高精度企业知识库与问答：RAG的主场
这是RAG应用最成熟的场景。企业内部通常有海量的制度文档、产品手册、客服话术、技术规范，员工需要一个“企业百科问答机器人”。
传统做法是搞一个全文搜索框，搜出来的是一堆文档标题，用户还得自己一篇篇点开看。RAG的体验好很多——用户直接提问“报销差旅费的流程是什么？”，系统检索后直接给出归纳好的步骤答案，还附上原文引用。
这类场景用纯RAG就够，原因也很简单：大部分企业知识是“片段型”的，答案通常藏在某一段文档里，单跳检索就能找到。比如“报销流程”“年假天数”“产品某功能怎么用”，都是文本片段匹配。企业知识库本身不涉及太多实体间复杂关系推理，没必要上GraphRAG。
实操上的选型思路我直接给出来：
- 文档解析：PyMuPDF / Unstructured / MinerU（PDF转Markdown效果好）
- 切片策略：优先按Markdown章节结构切，不要无脑按固定字符数切
- 向量化模型：中文场景首选BAAI/bge-large-zh-v1.5或bge-m3，英文可以考虑OpenAI的text-embedding-3-large
- 向量数据库：Milvus、Qdrant、pgvector都可，量小直接用pgvector省事
- 生成模型：按成本和效果平衡，可以选Qwen或DeepSeek系列，追求SOTA再考虑Claude/GPT
典型案例：某制造型企业要做“售后维修问答助手”，维修手册几千页，一线工程师带个平板就能查故障码。但维修手册里大量内容是“故障码A123对应的排查步骤是……”这类直查型知识，没有复杂关系网。纯RAG跑起来，准确率已经能从0%直接干到85%以上。
2.2 需要关系推理的复杂决策场景：GraphRAG的机会区
GraphRAG适合的问题跟纯RAG有本质区别——它需要模型理解“谁影响谁”“A跟B之间隔了几层关系”这类问题。
举几个真实场景：
- 金融风控：客户与客户之间互相担保、资金往来，构成担保圈。风控人员问“这家公司是否处于担保圈中心？”系统需要顺着“公司-担保-公司”的关系网络做多跳遍历。
- 医疗辅助：患者症状、疾病、药品、不良反应构成一个复杂关系网络。医生问“这个患者吃的他汀类药物和目前的肝功能指标有没有冲突性关联？”这需要跨实体推理。
- 供应链分析：厂商、部件、产品、地域之间的依赖与风险传导，是天然多跳关系。
在这些场景里，纯向量检索的问题非常明显。你问“这个公司是否处于风险担保圈中心”，向量检索会找出所有跟“公司”“担保”“风险”字面上相似的文档片段，但这些片段之间是割裂的，模型拼不出完整的关系链。GraphRAG就不一样——它提前把公司间关系建成图，检索时直接从图里捞出“该公司到其他所有公司的两跳连接路径”，模型一眼就能给出结论。
> 个人体会：判定一个场景要不要上GraphRAG，就一条标准——问题里是否包含“关系、链路、影响传导、多跳推理”中的任何一个要素。没有，纯RAG足够；有，GraphRAG的价值立刻显现。
2.3 数据资产盘点与血缘分析：知识图谱的稳定阵地
有一类场景和LLM关系不大，但却是知识图谱最纯正的应用——数据资产盘点、数据血缘分析。
很多大企业的数据体系非常混乱，几十个业务系统，上千张表，数据从生产库到数仓再到应用层，链路很长。数据治理团队常年被问三个问题：这个字段是哪来的？这个报表的数据可信吗？某个下游应用挂了，影响哪些上游？
这正是知识图谱的主场。把表、字段、ETL任务、报表、应用建模成实体，把“生成、依赖、消费”关系建成边，就形成一个数据血缘图谱。查询时顺着边走一二跳，问题立刻有答案。
这些场景我不建议强行引入RAG。数据血缘本质上是一个确定性的工程问题，用户想问“我的报表数据来源是什么”，一条Gremlin/Cypher查询就解决了，不需要大模型生成。硬上RAG反而会引入幻觉风险。
2.4 低资源冷启动场景：本体先行，图谱后建
还有一种场景，数据还没有积累，但要先搭一套知识系统——比如一个刚创业的垂直领域问答平台，比如一个新药研发团队要整理文献知识体系。
这种时候优先做的是本体设计，而不是急着灌数据。先把领域的概念体系定义清楚：这个领域有哪些类、哪些关系、哪些属性，数据来了之后才知道怎么归类、怎么建边。没有本体直接怼数据进图，后面十有八九要返工。我见过太多项目栽在“无Schema建图”上——图建到一半，发现两个实体类应该合并，结果整张图都要改。
本体先行还有一个好处：它可以让多源异构数据的接入变得可控。不同来源的数据字段五花八门，但你有了本体之后，每一条进来的数据都能被“映射”到一个统一的概念框架里，数据质量检查也有了明确的规则。
3. 技术栈组合模式与选型工具箱
前面讲场景，很多人可能已经心里有数了。但真正动手时，最容易卡壳的是“我到底该用哪套技术栈”。这里我给出几条我自己验证过可行的组合路线。
3.1 纯向量RAG标准组合
这是最轻量、最易起步的方案，适合中小团队快速上线。技术栈：
- 文档解析 + 切分：LangChain / LlamaIndex + Unstructured
- 向量化：bge-m3（中国语料效果好，检索中文强烈推荐）
- 向量存储：Qdrant或Milvus，测试阶段用Chroma也凑合
- 重排序（Rerank）：bge-reranker-v2-m3
- 生成：DeepSeek-V3/Qwen2.5-72B，API调用即可
这个组合在标准知识QA场景，检索Top5召回率能做到90%以上，答案生成质量很稳定。
有几个参数需要重点调：
- 切片大小（Chunk Size）：我在中英文混合文档上通常设512~768个token。太大检索粒度太粗，太小语义被切断。
- Top-K：生成阶段取3~5个片段链接式送进Prompt足够，取多了反而让模型抓不住重点。
- Rerank是必选项。实测发现，纯向量检索Top5准确率大约70%，加上Rerank之后能提高到85%以上。记住，向量检索是“海选”，Rerank才是“精选”。
3.2 GraphRAG标准组合
GraphRAG的工程复杂度比纯RAG高一个量级，但效果上限也高得多。技术栈：
- 图谱构建：Neo4j（开发效率高，生态完善）/ NebulaGraph（超大规模场景）/ 开源的Kuzu（单机轻量，原型验证很香）
- 本体定义：自定义OWL或直接定义为Neo4j的标签和关系类型，不一定要上重型本体编辑器
- 知识抽取：用LLM（GPT-4o/Claude/Qwen-Max）从非结构化文本里抽取实体和关系。这一步是整个GraphRAG成本最高的地方，要反复调抽取Schema、做样本校准
- 检索融合：先向量检索文档片段取TopK，同时用知识图谱查询扩展实体邻居（1~2跳子图），两路结果合并去重送Prompt
- 图嵌入（可选）：用Node2Vec或GraphSAGE学实体向量，用于“相似实体推荐”类需求的召回
GraphRAG的部署要注意两点：一是抽取质量直接决定答案质量，二是图存储和向量库要做双写，保持一致。
3.3 本体 + 图谱 + GraphRAG 的全链路组合
这是我认为尤其在垂直行业最能打的终极形态。流程是：
- 和领域专家协作设计本体（明确类、属性、关系）
- 存量数据通过ETL/LLM抽取映射成本体实例，构建知识图谱
- 图谱同时输出两种格式：三元组数据入图数据库，自然语言摘要入向量库
- 用户提问时，做混合检索（向量相似 + 图谱多跳）
- 把两路证据一起喂给LLM，要求它在回答中引用图谱路径
这套组合在金融投研、医疗问诊、工业质检等高价值场景已经有不少落地先例。比如某券商做“行业产业链分析助手”，本体里定义了“上游-中游-下游”“供需”“价格传导”等关系，图谱里塞满了产业链实体，模型回答“锂电池价格上涨对整车厂的影响”这类问题时，既引用了新闻片段，又能顺着图谱给出传导路径，效果是纯RAG完全达不到的。
4. 从头跑通一个GraphRAG小项目：从本体设计到答案输出
概念和选型说完，我直接用一个最小可复现的项目来走一遍全流程。这个案例是“简化版智能招聘助手”，目标是从一堆简历和岗位描述里回答“张三适不适合投递后端开发岗”。
4.1 定义本体：先把图纸画出来
在这个小项目里，本体可以定义得很精简。我用JSON Schema形式来表达，这也是目前实践中比较常见的方式。
{ "classes": [ { "name": "候选人", "attributes": ["姓名", "工作年限", "当前职级"] }, { "name": "职位", "attributes": ["职位名称", "技能要求", "职级要求"] }, { "name": "技能", "attributes": ["技能名称", "熟练度"] }, { "name": "公司", "attributes": ["公司名称", "行业"] } ], "relations": [ { "name": "投递", "domain": "候选人", "range": "职位" }, { "name": "要求", "domain": "职位", "range": "技能" }, { "name": "拥有", "domain": "候选人", "range": "技能" }, { "name": "属于", "domain": "职位", "range": "公司" } ] }这个本体定义了4个类和4个关系。它是我们后面知识抽取的“答案模板”——从文本里抽出来的实体和关系，必须落在这些类和关系上，否则就丢弃或人工复核。
为什么用JSON Schema而不是OWL？因为对于大部分工程团队，OWL的推理复杂度（RDFS/OWL DL推理）在落地时用不上，反而增加维护负担。先用简单Schema保证可迭代性，等系统成熟了再考虑形式化本体升级。
4.2 数据准备与知识抽取
数据就是简历文本和JD文本各几十份。预处理分两步走：
第一步，文本清洗：去掉简历里的照片占位、格式符号，保留纯文本。
第二步，用LLM做信息抽取。这里我给出一个非常稳定的抽取Prompt模板：
你是一个信息抽取引擎。从下面文本中抽取实体和关系。 实体类别：候选人（姓名、工作年限、当前职级）、职位（职位名称、技能要求、职级要求）、技能（技能名称、熟练度）、公司（公司名称、行业）。 关系类别：投递、要求、拥有、属于。 输出格式为JSON数组，每个元素包含“实体1”、“关系”、“实体2”、“来源句子”。 如果文本中没有明确提到的信息，不要臆造。 文本： {输入文本}实际操作里，我会用大模型输出JSON，然后用pydantic做校验。无效输出重试一次。抽取的准确率在90%~95%之间，剩下的人工抽检修正即可。
4.3 图存储与写入
这个项目我用Neo4j做图存储。写入的Cypher语句长这样：
// 创建候选人节点 CREATE (p:候选人 {name: '张三', years: 5, level: 'P6'}) // 创建技能节点和拥有关系 CREATE (s:技能 {name: 'Java'}) CREATE (p)-[:拥有 {熟练度: '熟练'}]->(s) // 创建职位节点和投递关系 CREATE (j:职位 {name: '后端开发工程师', skill_requirement: 'Java,Spring', level_requirement: 'P7'}) CREATE (p)-[:投递]->(j) // 创建要求关系 MATCH (j:职位 {name: '后端开发工程师'}), (s:技能 {name: 'Java'}) CREATE (j)-[:要求]->(s)图写入完毕后就形成一个完整的招聘图谱。这一步可以用Neo4j的Python驱动批量执行，不需要逐条手写Cypher。
4.4 双通道索引构建
除了图结构数据，我还会为每个实体生成一段自然语言摘要文本，然后做向量化，存入向量库。为什么要这么做？
因为有些问题适合走图查询，有些问题适合走向量检索，两路结果合并能覆盖更完整的语义。比如“张三的工作经历是什么”——这是一个“属性型”问题，从图里直接查节点属性就行；“为什么张三适合这个岗位？”——这要求把图关系的证据串起来，走图路径；而“Java相关职位的薪酬水平”这种问题，图里可能没有薪酬节点，需要从简历原始文本的向量索引里检索。
具体做法：把每个候选人节点的属性拼成一段话，比如“候选人张三，5年经验，P6职级，精通Java和Spring”，向量化后存入向量库。每份简历的原文片段也做向量化。两张向量“表”分别支撑实体级检索和段落级检索。
4.5 检索与答案合成
用户提问“张三适不适合投递后端开发岗位？”到这一步，系统分四路并行：
- 路径A：在向量库里检索与问题最相近的简历片段Top3；
- 路径B：在向量库里检索与问题最相近的JD片段Top3；
- 路径C：在Neo4j里查询张三实体，并沿“拥有”“投递”“要求”关系做2跳子图提取。Cypher大概是：
MATCH (p:候选人 {name: '张三'})-[r1]-(n)-[r2]-(m) RETURN p, r1, n, r2, m LIMIT 50- 路径D：把张三的技能集和JD的技能要求集做集合运算，找出交集和缺失项：
MATCH (p:候选人 {name: '张三'})-[r:拥有]->(s:技能) WITH collect(s.name) AS skill_set MATCH (j:职位 {name: '后端开发工程师'})-[rq:要求]->(req_skill:技能) WHERE req_skill.name IN skill_set RETURN req_skill.name然后我把四路结果全部拼接进Prompt：
请基于以下材料回答问题。 【简历片段】…… 【JD片段】…… 【图谱路径】张三-[拥有]->Java；后端开发工程师-[要求]->Java；张三-[投递]->后端开发工程师 【技能匹配】命中技能：Java；缺失技能：Spring（职位要求，简历未体现） 问题：张三适不适合投递后端开发岗位？ 要求：回答必须基于材料，给出支持依据，不得使用材料外的信息。模型给出的答案就会非常扎实：“张三基本适合。他已具备Java核心技能，但职位要求Spring框架，简历中未体现，建议面试中重点确认。”——这个答案里有明确的证据链和风险提示，直接可用。
> 关键心得：GraphRAG的价值不在于“让模型更聪明”，而在于“让模型的答案拥有可追溯的证据链”。证据链是B端企业决策系统最看重的东西，这也解释了为什么GraphRAG在金融、医疗、法务等高合规行业最早落地。
5. 我实际踩过的坑：常见的陷阱与性能调优细节
理论讲再多，不如把实操中切实遇到过的坑直接晒出来。下面这些问题几乎每个项目都会碰见，新手踩坑概率接近100%。
5.1 文档切分不当导致上下文断裂
这是我见过最多的坑。固定512字符硬切，把“候选人的技术栈包括”和“Java, Python, Go”切成两段，检索时只命中后半段，模型的回答就变得莫名其妙。
解决思路是层级切分：先按Markdown标题/文档结构切出章节，再对超长章节做递归切分。切分时保留章节上下文信息作为元数据，检索返回时把元数据一并喂给模型。另外，我强烈建议切分时做10%~15%重叠，重叠区间能显著降低信息截断概率。
5.2 实体抽取的“幻觉实体”污染图谱
LLM抽取实体时有个顽固毛病：文本里没有的东西，它可能根据上下文脑补出来。比如简历里只写了“熟悉Java”，模型可能顺手抽出一个“熟悉C++”的技能节点——“熟悉”这种词被误判了范围。
我处理这个问题用三层防护：
- 抽取Prompt里明确加一句“只抽取文本中明确出现的信息，禁止推断”。
- 输出JSON后做实体对齐校验，不在本体定义中的实体类别直接丢弃。
- 关键实体（候选人、职位）做人工抽检，设定阈值，低于90%准确率就调整Prompt或换更强的抽取模型。
5.3 图谱更新与一致性
知识图谱不是建完就完事的。企业数据日更，实体属性会变，关系会变。我见过很多项目上线后图谱一个月没更新，用户问到新增业务数据，系统给出过期信息。
建议的做法是：建立增量更新管道。每次有新文档进来，先走抽取，然后做一个“实体消歧”步骤——判断该实体在图谱里是否已存在，存在就更新属性，不存在就新建节点。这一步理论上可以全自动，但为了稳妥，批量更新前加一层规则校验，比如同名合并、关系冲突报警。
5.4 混合检索的结果融合策略
GraphRAG最常见的检索问题是“两路结果冲突”——向量检索说A公司是风险企业，图谱路径说A公司和风险企业无关联。这时候怎么办？
我的经验是分情况处理：
- 图谱路径权威性更高：图谱是无中生有的结构化事实，经过人工校验，可信度排序最高；
- 向量片段补充细节：向量检索通常提供背景性描述，可信度次之；
- 最终裁决交给模型：在Prompt中明确要求“若证据冲突，请说明冲突并优先采用图谱路径结论”。
这种处理方式并非完美，但在工程上是可接受的权衡。
5.5 RAG知识库能不能存图片？顺便回答这个热词
这个话题在社区被问得很高频。结论是：
- 如果是“图片里的文字”，可以存。做法是先用OCR把图片中的文字抽出来，再按纯RAG链路处理。
- 如果是“图片本身的视觉语义”，纯RAG成本很高，目前主流方案是给图片生成一段详细的文本描述（Caption），把描述文本向量化入库。真正查询时，检索到的是图片的描述文本。
对绝大多数企业场景来说，RAG的输入输出都以文本为主，图片属于附属资源，建议“文本化处理后来参与检索”，不要直接对图片做向量化检索——效果不稳定且成本高。多模态检索是另一个专门的技术栈，跟RAG是两码事。
5.6 性能调优：从“能跑”到“跑得好”
最后分享几个见效极快的调优手段：
- 索引优化：Neo4j里对高频查询的属性建索引，Cypher性能直接从秒级降到毫秒级。实体名称字段一定要建索引。
- 向量索引参数：HNSW的M参数（每个节点的连接数）设16~32，efConstruction设200~400。M越大召回越好但内存开销大，需要做取舍。
- 缓存：几类高频查询结果做Redis缓存，命中率能达到30%以上的场景收益非常明显。
- 重排序（Rerank）不能省：这一点在纯RAG里强调过，GraphRAG里同样适用。理由很简单，两路结果的合并集合可能很大，直接全量塞给模型既费token又降低回答质量。先用Rerank模型从两路候选里选出最相关的5~10条，再进Prompt。
6. 要不要用LLM来建本体？聊聊这件反直觉的事
有不少朋友问过这样一个问题：本体这种形式化知识描述，能不能直接让LLM来自动生成？省得请领域专家来做知识工程。
这是个大坑。
6.1 本体工程中的LLM角色边界
我的实践经验是：LLM适合做“建议草稿”，不适合做“最终决策”。
原因是本体设计本质上是一个“业务共识达成的过程”。不同部门对同一个概念的定义可能完全不同——“客户”在销售部门眼里是交易对手，在客服部门眼里是服务对象，在财务部门眼里是付款方。本体设计者要做的不是选一个“最正确的定义”，而是让各方达成一致。LLM没有参与业务讨论的能力，它只能基于语料统计给出一个“平均水平”的建议。
我建议的协作分工是：
- 领域专家负责定义核心类和关系：这是最关键的决策，必须人来拍板。
- LLM负责辅助发现遗漏：比如让LLM阅读领域文档，找出“专家可能遗漏的概念或关系”。
- 工程团队负责把专家定义的本体转换成代码Schema和校验规则。
6.2 LLM在拼接本体时的“顺手”用法
虽然本体设计不能全交给LLM，但有一个环节我确实一直在用LLM，而且效果非常好——实体链接和属性解析。
比如简历里有一句“工作于某大型互联网公司，担任高级工程师”。在图谱里，我需要把“高级工程师”映射到“候选人.当前职级”属性上，而不是把“高级工程师”识别成一个职位类型。这种语义解析正是LLM的强项。
换一批写法完全不同的简历，抽取出错率会明显升高。这时把错误样本收集起来，微调一个小的抽取模型，准确率可以稳定提升。
7. 落地路线规划建议
最后聊一点务实的东西。如果你的团队已经决定要在实际产品里引入这一套技术体系，我强烈建议分三个阶段走。
7.1 第一阶段：纯RAG快速打底（1~2周）
先把最基础的企业知识问答跑起来。不需要建本体，不需要建图谱，工具链全部用现成的，保证一个可以用的MVP。这一阶段的核心目标是验证“检索+生成”链路在你的数据上能达到什么效果，同时积累一批人工标注的问答对作为后续评测集。
7.2 第二阶段：引入本体 + 知识图谱（3~6周）
基于第一阶段的文档样本，与领域专家共同设计本体，构建知识图谱。这一阶段可以做半自动抽取——先用LLM提取，再人工校验。核心目标是让系统具备多跳查询能力和结构化推理能力。
7.3 第三阶段：GraphRAG融合与调优（2~4周）
把向量检索、图谱路径检索、Rerank三者融合起来，做系统评测和迭代优化。这一阶段开始打磨Prompt模板、检索参数、图谱更新策略。最终目标是让系统的回答质量和可追溯性达到可上线水平。
我给团队定的一个简单的“三级跳”原则：先用最蠢的办法跑通，再用聪明的办法调优，最后才上复杂架构。很多项目死在“一上来就搞GraphRAG”这种激进路线。
8. 最后的几句心里话
做知识增强的LLM应用做了这几年，我个人的体会是：技术选的不是最先进的，而是最匹配业务形态和团队能力的。本体和知识图谱擅长的东西，纯RAG确实做不到；但纯RAG能两天上线拿到结果，图谱方案可能要两个月。
最怕的是团队没想清楚业务问题就无脑上全套图谱+RAG。“我的业务到底需要回答什么样的问题？”“这些问题需要关系推理吗？”“多跳查询的复杂度业务能接受吗？”——这三个问题先问清楚，再谈技术选型。
前面几节提到的工具和参数都是我的实测数据，可以放心参考。但更建议你在自己的数据集上多跑几轮离线评测，拿数据说话。知识增强系统有一个特点：效果好不好，不看模型多聪明，看的是索引工艺和证据组织做得好不好。在这一点上，本体和知识图谱提供的“结构化骨架”功不可没。
