1. 项目缘起与整体架构思路1.1 为什么单靠向量库或图库都不够用做过大模型应用的人多半踩过同一个坑把文档切片、做嵌入、塞进向量数据库检索看起来跑通了但一旦用户问的是“A和B之间是什么关系”“这条链路上下游都有谁”这类问题返回的结果就开始飘。原因不复杂——向量检索擅长的是语义相似度它把一段文本压成一个高维向量靠余弦距离找“意思相近”的片段但它天生不擅长表达“谁指向谁”“谁属于谁”这种显式的结构关系。反过来图数据库把实体和关系存得明明白白做多跳关联、路径查询、子图匹配是它的强项可它有个硬伤你得先知道从哪个节点开始查。用户用自然语言问“那个负责库存调度又跟冷链相关的模块是哪个”图库里没有“库存调度”这个精确节点名你就无从下手。所以这个项目的核心思路就一句话用向量数据库解决“找得到入口”的问题用图数据库解决“理得清关系”的问题中间用大模型做语义翻译和推理编排。三者各司其职谁也别抢谁的活。1.2 三层协同的整体架构我把整个系统拆成三层来看这样排查问题时能快速定位是哪一层出了毛病。第一层是语义入口层由向量数据库承担。所有原始文本文档、工单、日志摘要、知识条目经过嵌入模型转成向量连同原文和元数据一起存进去。用户提问时先把问题也转成向量做近似最近邻搜索召回一批语义相关的候选片段。这一层的产出不是最终答案而是“可能相关的原材料”加上它们的标识符。第二层是结构关联层由图数据库承担。候选片段里提取出的实体人、模块、事件、概念和关系依赖、属于、触发、关联预先构建成图。拿到第一层的候选实体后在这一层做多跳扩展把相关的上下游、同级、跨层关系一次性拉出来形成一个小型子图。第三层是推理编排层由大模型承担。它拿到的是“候选文本片段 子图结构描述”负责理解用户真实意图、判断哪些关系是关键的、生成最终的自然语言回答必要时还会反过来决定要不要再查一轮。这里有个关键设计决策向量检索的召回数量不能太少也不能太多。太少会漏掉关键入口太多会把噪声灌进图查询导致子图爆炸。我实测下来单次召回控制在8到15条比较稳具体看你的文本粒度。1.3 技术选型的取舍逻辑向量库这块选型主要看三点是否支持元数据过滤、是否支持混合检索向量关键词、写入和查询的延迟是否可接受。小规模验证阶段用轻量级方案完全够用等数据量上到百万级再考虑分布式部署。图数据库这块重点看查询语言的表达力和多跳性能属性图模型对大多数知识关联场景都够用没必要一上来就上RDF那套。大模型的选择反而没那么纠结——推理编排层对模型的指令遵循能力要求高对纯粹的知识储备要求没那么高因为知识都在外部库里。所以选一个指令跟随稳、输出格式可控的模型就行参数规模中等偏上即可不必盲目追大。2. 核心细节拆解与实操要点2.1 向量化策略切多细才合适文本切片是第一个容易翻车的地方。切太粗一个片段里混了好几个主题向量表示被平均掉检索精度下降切太细语义碎片化检索出来的片段缺少上下文大模型拿到也拼不出完整意思。我的经验是按语义边界切而不是按固定字数切。具体做法是先用段落和标题做一级切分如果单段超过阈值比如500字再按句子边界做二级切分保证每个片段是一个相对完整的语义单元。片段之间保留一定的重叠10%到20%避免关键信息刚好卡在切分点上被切断。嵌入模型的选择上中文场景要特别注意模型对中文语义的覆盖程度。有些模型在英文基准上分数很高但中文短文本的区分度不够导致“库存调度”和“仓储管理”这种相近但不相同的概念被映射到几乎同一个位置。验证方法很简单拿一批你知道应该分开的相似词对算一下它们的向量距离如果区分度不够就换模型。2.2 图模式设计实体和关系怎么定图模式设计是整个项目里最需要提前想清楚的部分因为一旦数据灌进去后面改模式成本很高。我的建议是从查询需求反推模式而不是从数据源正向推导。具体操作先列出你希望系统能回答的10到20个典型问题然后逐个分析这些问题需要哪些实体类型和关系类型。比如“某个模块依赖哪些上游服务”需要“模块”实体和“依赖”关系“某个事件影响了哪些业务线”需要“事件”实体、“业务线”实体和“影响”关系。实体粒度也要控制。太粗比如把所有文档都当成一个“文档”实体会导致图查询没有区分度太细比如把每个句子都建成节点会导致图规模爆炸、查询变慢。一般建议实体粒度对齐业务概念比如“服务”“模块”“人员”“事件”“规则”这种级别。关系类型同理不要设计太多花哨的关系先把“属于”“依赖”“触发”“关联”这几个基础关系做扎实。关系上可以挂属性比如“依赖”关系上挂一个“强度”或“类型”属性后续推理时可以用到。2.3 大模型编排提示词怎么写才稳编排层的提示词设计有个核心原则给模型的结构信息要显式、要带标识、要可追溯。不要把子图直接序列化成一段自然语言丢给模型那样模型很容易丢失结构信息。更好的做法是用一种半结构化的格式比如每个实体一行、每个关系一行带上唯一ID让模型在生成回答时能引用这些ID。另一个要点是让模型做选择题而不是填空题。与其让模型自由发挥“根据以上信息回答”不如给它一个明确的输出格式约束比如“先列出你依据的关系ID再给出结论”。这样一方面输出更可控另一方面出问题时你能快速定位是检索错了还是推理错了。温度参数建议调低编排层不需要创造力需要的是稳定和可复现。我一般设在0.1到0.3之间具体看模型特性。3. 实操过程与核心环节实现3.1 数据准备与向量入库假设你手头有一批结构化和半结构化的知识数据第一步是把它们统一成“文本元数据”的格式。元数据里至少要包含来源标识、时间戳、类别标签这些在后面做过滤和溯源时都会用到。向量入库的流程大致是文本清洗去重、去噪、统一编码→ 切片 → 嵌入 → 写入向量库。这里有个容易忽略的点写入时要批量操作不要一条一条写。批量写入不仅快而且很多向量库对批量写入有优化单条写入反而容易触发频繁的索引重建。# 伪代码示意具体API按你用的库调整 def ingest_documents(docs, embed_model, vector_store, batch_size64): for i in range(0, len(docs), batch_size): batch docs[i:ibatch_size] texts [clean_text(d[content]) for d in batch] vectors embed_model.encode(texts) metadatas [build_metadata(d) for d in batch] vector_store.upsert(vectorsvectors, documentstexts, metadatasmetadatas)入库完成后一定要做一轮召回验证拿一批已知答案的问题去查看目标片段是否在Top-K里。如果不在要么是切片有问题要么是嵌入模型不合适要么是元数据过滤条件写错了。这一步不做后面全是空中楼阁。3.2 实体抽取与图构建实体抽取可以从两个方向做一是用规则和词典做精确匹配适合实体名称比较固定的场景二是用模型做开放抽取适合实体表达多样的情况。实际项目里通常是两者结合——先用词典保底再用模型补充。抽取出来的实体要跟向量库里的片段建立映射关系也就是说每个实体要知道它出现在哪些片段里。这个映射是后面“向量召回→图查询”联动的关键桥梁。图构建时节点和关系的写入要注意幂等性。同一个实体可能从多个片段里被抽出来写入时要先查再写或者用合并语义避免重复节点。关系同理同一条关系被多次抽到时要合并属性而不是新建。// 图数据库写入示意Cypher风格 MERGE (a:Entity {name: $name_a, type: $type_a}) MERGE (b:Entity {name: $name_b, type: $type_b}) MERGE (a)-[r:RELATES {type: $rel_type}]-(b) ON CREATE SET r.weight 1, r.sources [$source_id] ON MATCH SET r.weight r.weight 1, r.sources r.sources $source_id3.3 查询编排的完整链路用户提问进来后完整链路是这样的第一步问题向量化去向量库做近似搜索拿到Top-K候选片段及其元数据。如果元数据里有类别、时间等过滤条件在这一步就加上能显著提升召回质量。第二步从候选片段里提取实体提及去图数据库里定位对应节点。这里要注意实体消歧——同一个名字可能对应多个节点需要结合上下文或元数据做判断。第三步以定位到的节点为起点做N跳扩展。N一般取2到3太多会导致子图过大、噪声增加。扩展时可以加关系类型过滤只保留跟问题相关的几类关系。第四步把候选片段文本和子图结构一起喂给大模型让它生成回答。提示词里要明确告诉模型哪些是原始文本、哪些是结构关系、哪些是你不确定的信息。第五步如果模型判断信息不足可以触发第二轮检索用模型生成的新查询词再去向量库和图库各查一次。这个循环最多做两轮再多就说明初始设计有问题了。3.4 一个完整的参数配置参考下面这张表是我在一个中等规模知识库约50万片段、20万节点、80万关系上跑出来的配置供参考环节参数取值说明切片最大片段长度500字超过则按句子边界二次切分切片重叠比例15%避免关键信息被切断向量检索Top-K12太少漏召回太多灌噪声向量检索相似度阈值0.72低于此值不进入下一环节图查询扩展跳数2三跳以上子图规模失控图查询单节点最大邻居数50防止超级节点拖垮查询大模型温度0.2编排层求稳不求新大模型最大输出长度1024 token够用即可太长反而发散这些数字不是金科玉律但如果你刚开始调从这个基线出发比从零摸索快得多。4. 常见问题与排查技巧实录4.1 召回不准的三种典型情况情况一问题问法和文档表述差异太大。比如用户问“怎么防止库存积压”文档里写的是“库存周转率优化策略”。这种语义鸿沟靠单一嵌入模型很难完全弥合。解决办法是在向量检索之外加一路关键词检索做混合召回然后把两路结果合并去重。关键词检索能兜住那些字面匹配但语义向量没拉近的情况。情况二元数据过滤条件写得太死。比如你限定了时间范围但目标文档的时间戳格式不统一导致过滤后把该留的也滤掉了。排查方法是先去掉所有过滤条件跑一遍确认基础召回没问题再逐个加过滤条件看是哪个条件导致召回骤降。情况三嵌入模型对领域术语不敏感。通用嵌入模型在专业领域往往表现不佳因为领域术语在它的训练数据里出现频率低向量表示不准确。解决办法要么是用领域数据做微调要么是在检索时把领域术语先做一次归一化映射把同义词统一成标准表述再嵌入。4.2 图查询超时或子图爆炸图查询最常见的性能问题是超级节点——某个节点有几千上万个邻居一旦扩展到它查询就会拉出一大片子图既慢又噪声大。排查方法是先统计一下节点度数分布看看有没有度特别高的节点。处理超级节点有几种策略一是限制单节点的扩展邻居数按关系权重排序取Top-N二是对超级节点做特殊标记查询时跳过或降权三是把超级节点的关系做分层先查一层概要再按需下钻。另一个性能问题是多跳查询没有方向性。比如你从A出发做两跳扩展如果不限制关系方向可能会先走到B再走回A做了一堆无用功。在查询语句里明确方向能省不少时间。4.3 大模型输出不稳定的排查模型输出不稳定的表现通常是同样的输入有时回答得很准有时答非所问有时干脆编造关系。排查思路分三步先看输入。把喂给模型的完整提示词打印出来检查结构信息是否完整、ID是否对应、有没有明显的格式错误。很多时候问题出在输入而不是模型本身。再看提示词约束。如果提示词里没有明确要求“只依据给定信息回答”模型就可能用自己的先验知识补全导致编造。加一句“如果给定信息不足以回答请明确说明”能挡掉大部分幻觉。最后看模型参数。温度调高会增加随机性Top-P调大也会让输出更发散。编排层建议用低温度加较小的Top-P牺牲一点多样性换稳定性。4.4 常见问题速查表现象可能原因排查动作解决方向召回结果不相关切片粒度不当检查Top-K片段的完整性调整切片策略召回结果不相关嵌入模型不匹配算相似词对的距离换模型或微调图查询超时超级节点统计节点度数分布限制扩展数或分层图查询结果为空实体消歧错误检查实体到节点的映射加消歧规则或上下文模型答非所问提示词结构不清打印完整提示词改半结构化格式模型编造关系缺少约束语句检查提示词约束加“仅依据给定信息”整体延迟高串行调用过多打点各环节耗时并行化或加缓存4.5 几个踩过坑才明白的经验经验一不要试图一次性把图建完美。图模式和数据都是迭代出来的先建一个最小可用的图跑通链路再逐步补充实体和关系。一上来就追求大而全往往卡在数据准备阶段就推不动了。经验二向量库和图库的更新要解耦。新文档进来时先入向量库保证能检索到图库的更新可以异步做。这样即使图库暂时没跟上系统至少还能返回基于文本的答案不会完全不可用。经验三给每个环节加可观测性。召回了几条、命中哪些实体、扩展了多少节点、模型用了多少token这些指标都要打点记录。出问题时没有这些数据排查全靠猜效率极低。经验四缓存高频查询的结果。很多知识检索场景里用户问的问题是高度重复的。把“问题向量→最终答案”的映射缓存起来命中时直接返回能省掉后面所有环节的开销。缓存失效策略可以按时间或按数据更新事件来触发。这套东西跑通之后你会发现它真正的价值不在于某个单点技术有多先进而在于三层之间的配合是否顺畅。向量库负责广撒网图库负责理关系大模型负责做判断任何一层拖后腿都会让整体体验打折扣。我个人的体会是把精力优先花在数据质量和图模式设计上收益远比调模型参数大得多。
1. 项目缘起与整体架构思路1.1 为什么单靠向量库或图库都不够用做过大模型应用的人多半踩过同一个坑把文档切片、做嵌入、塞进向量数据库检索看起来跑通了但一旦用户问的是“A和B之间是什么关系”“这条链路上下游都有谁”这类问题返回的结果就开始飘。原因不复杂——向量检索擅长的是语义相似度它把一段文本压成一个高维向量靠余弦距离找“意思相近”的片段但它天生不擅长表达“谁指向谁”“谁属于谁”这种显式的结构关系。反过来图数据库把实体和关系存得明明白白做多跳关联、路径查询、子图匹配是它的强项可它有个硬伤你得先知道从哪个节点开始查。用户用自然语言问“那个负责库存调度又跟冷链相关的模块是哪个”图库里没有“库存调度”这个精确节点名你就无从下手。所以这个项目的核心思路就一句话用向量数据库解决“找得到入口”的问题用图数据库解决“理得清关系”的问题中间用大模型做语义翻译和推理编排。三者各司其职谁也别抢谁的活。1.2 三层协同的整体架构我把整个系统拆成三层来看这样排查问题时能快速定位是哪一层出了毛病。第一层是语义入口层由向量数据库承担。所有原始文本文档、工单、日志摘要、知识条目经过嵌入模型转成向量连同原文和元数据一起存进去。用户提问时先把问题也转成向量做近似最近邻搜索召回一批语义相关的候选片段。这一层的产出不是最终答案而是“可能相关的原材料”加上它们的标识符。第二层是结构关联层由图数据库承担。候选片段里提取出的实体人、模块、事件、概念和关系依赖、属于、触发、关联预先构建成图。拿到第一层的候选实体后在这一层做多跳扩展把相关的上下游、同级、跨层关系一次性拉出来形成一个小型子图。第三层是推理编排层由大模型承担。它拿到的是“候选文本片段 子图结构描述”负责理解用户真实意图、判断哪些关系是关键的、生成最终的自然语言回答必要时还会反过来决定要不要再查一轮。这里有个关键设计决策向量检索的召回数量不能太少也不能太多。太少会漏掉关键入口太多会把噪声灌进图查询导致子图爆炸。我实测下来单次召回控制在8到15条比较稳具体看你的文本粒度。1.3 技术选型的取舍逻辑向量库这块选型主要看三点是否支持元数据过滤、是否支持混合检索向量关键词、写入和查询的延迟是否可接受。小规模验证阶段用轻量级方案完全够用等数据量上到百万级再考虑分布式部署。图数据库这块重点看查询语言的表达力和多跳性能属性图模型对大多数知识关联场景都够用没必要一上来就上RDF那套。大模型的选择反而没那么纠结——推理编排层对模型的指令遵循能力要求高对纯粹的知识储备要求没那么高因为知识都在外部库里。所以选一个指令跟随稳、输出格式可控的模型就行参数规模中等偏上即可不必盲目追大。2. 核心细节拆解与实操要点2.1 向量化策略切多细才合适文本切片是第一个容易翻车的地方。切太粗一个片段里混了好几个主题向量表示被平均掉检索精度下降切太细语义碎片化检索出来的片段缺少上下文大模型拿到也拼不出完整意思。我的经验是按语义边界切而不是按固定字数切。具体做法是先用段落和标题做一级切分如果单段超过阈值比如500字再按句子边界做二级切分保证每个片段是一个相对完整的语义单元。片段之间保留一定的重叠10%到20%避免关键信息刚好卡在切分点上被切断。嵌入模型的选择上中文场景要特别注意模型对中文语义的覆盖程度。有些模型在英文基准上分数很高但中文短文本的区分度不够导致“库存调度”和“仓储管理”这种相近但不相同的概念被映射到几乎同一个位置。验证方法很简单拿一批你知道应该分开的相似词对算一下它们的向量距离如果区分度不够就换模型。2.2 图模式设计实体和关系怎么定图模式设计是整个项目里最需要提前想清楚的部分因为一旦数据灌进去后面改模式成本很高。我的建议是从查询需求反推模式而不是从数据源正向推导。具体操作先列出你希望系统能回答的10到20个典型问题然后逐个分析这些问题需要哪些实体类型和关系类型。比如“某个模块依赖哪些上游服务”需要“模块”实体和“依赖”关系“某个事件影响了哪些业务线”需要“事件”实体、“业务线”实体和“影响”关系。实体粒度也要控制。太粗比如把所有文档都当成一个“文档”实体会导致图查询没有区分度太细比如把每个句子都建成节点会导致图规模爆炸、查询变慢。一般建议实体粒度对齐业务概念比如“服务”“模块”“人员”“事件”“规则”这种级别。关系类型同理不要设计太多花哨的关系先把“属于”“依赖”“触发”“关联”这几个基础关系做扎实。关系上可以挂属性比如“依赖”关系上挂一个“强度”或“类型”属性后续推理时可以用到。2.3 大模型编排提示词怎么写才稳编排层的提示词设计有个核心原则给模型的结构信息要显式、要带标识、要可追溯。不要把子图直接序列化成一段自然语言丢给模型那样模型很容易丢失结构信息。更好的做法是用一种半结构化的格式比如每个实体一行、每个关系一行带上唯一ID让模型在生成回答时能引用这些ID。另一个要点是让模型做选择题而不是填空题。与其让模型自由发挥“根据以上信息回答”不如给它一个明确的输出格式约束比如“先列出你依据的关系ID再给出结论”。这样一方面输出更可控另一方面出问题时你能快速定位是检索错了还是推理错了。温度参数建议调低编排层不需要创造力需要的是稳定和可复现。我一般设在0.1到0.3之间具体看模型特性。3. 实操过程与核心环节实现3.1 数据准备与向量入库假设你手头有一批结构化和半结构化的知识数据第一步是把它们统一成“文本元数据”的格式。元数据里至少要包含来源标识、时间戳、类别标签这些在后面做过滤和溯源时都会用到。向量入库的流程大致是文本清洗去重、去噪、统一编码→ 切片 → 嵌入 → 写入向量库。这里有个容易忽略的点写入时要批量操作不要一条一条写。批量写入不仅快而且很多向量库对批量写入有优化单条写入反而容易触发频繁的索引重建。# 伪代码示意具体API按你用的库调整 def ingest_documents(docs, embed_model, vector_store, batch_size64): for i in range(0, len(docs), batch_size): batch docs[i:ibatch_size] texts [clean_text(d[content]) for d in batch] vectors embed_model.encode(texts) metadatas [build_metadata(d) for d in batch] vector_store.upsert(vectorsvectors, documentstexts, metadatasmetadatas)入库完成后一定要做一轮召回验证拿一批已知答案的问题去查看目标片段是否在Top-K里。如果不在要么是切片有问题要么是嵌入模型不合适要么是元数据过滤条件写错了。这一步不做后面全是空中楼阁。3.2 实体抽取与图构建实体抽取可以从两个方向做一是用规则和词典做精确匹配适合实体名称比较固定的场景二是用模型做开放抽取适合实体表达多样的情况。实际项目里通常是两者结合——先用词典保底再用模型补充。抽取出来的实体要跟向量库里的片段建立映射关系也就是说每个实体要知道它出现在哪些片段里。这个映射是后面“向量召回→图查询”联动的关键桥梁。图构建时节点和关系的写入要注意幂等性。同一个实体可能从多个片段里被抽出来写入时要先查再写或者用合并语义避免重复节点。关系同理同一条关系被多次抽到时要合并属性而不是新建。// 图数据库写入示意Cypher风格 MERGE (a:Entity {name: $name_a, type: $type_a}) MERGE (b:Entity {name: $name_b, type: $type_b}) MERGE (a)-[r:RELATES {type: $rel_type}]-(b) ON CREATE SET r.weight 1, r.sources [$source_id] ON MATCH SET r.weight r.weight 1, r.sources r.sources $source_id3.3 查询编排的完整链路用户提问进来后完整链路是这样的第一步问题向量化去向量库做近似搜索拿到Top-K候选片段及其元数据。如果元数据里有类别、时间等过滤条件在这一步就加上能显著提升召回质量。第二步从候选片段里提取实体提及去图数据库里定位对应节点。这里要注意实体消歧——同一个名字可能对应多个节点需要结合上下文或元数据做判断。第三步以定位到的节点为起点做N跳扩展。N一般取2到3太多会导致子图过大、噪声增加。扩展时可以加关系类型过滤只保留跟问题相关的几类关系。第四步把候选片段文本和子图结构一起喂给大模型让它生成回答。提示词里要明确告诉模型哪些是原始文本、哪些是结构关系、哪些是你不确定的信息。第五步如果模型判断信息不足可以触发第二轮检索用模型生成的新查询词再去向量库和图库各查一次。这个循环最多做两轮再多就说明初始设计有问题了。3.4 一个完整的参数配置参考下面这张表是我在一个中等规模知识库约50万片段、20万节点、80万关系上跑出来的配置供参考环节参数取值说明切片最大片段长度500字超过则按句子边界二次切分切片重叠比例15%避免关键信息被切断向量检索Top-K12太少漏召回太多灌噪声向量检索相似度阈值0.72低于此值不进入下一环节图查询扩展跳数2三跳以上子图规模失控图查询单节点最大邻居数50防止超级节点拖垮查询大模型温度0.2编排层求稳不求新大模型最大输出长度1024 token够用即可太长反而发散这些数字不是金科玉律但如果你刚开始调从这个基线出发比从零摸索快得多。4. 常见问题与排查技巧实录4.1 召回不准的三种典型情况情况一问题问法和文档表述差异太大。比如用户问“怎么防止库存积压”文档里写的是“库存周转率优化策略”。这种语义鸿沟靠单一嵌入模型很难完全弥合。解决办法是在向量检索之外加一路关键词检索做混合召回然后把两路结果合并去重。关键词检索能兜住那些字面匹配但语义向量没拉近的情况。情况二元数据过滤条件写得太死。比如你限定了时间范围但目标文档的时间戳格式不统一导致过滤后把该留的也滤掉了。排查方法是先去掉所有过滤条件跑一遍确认基础召回没问题再逐个加过滤条件看是哪个条件导致召回骤降。情况三嵌入模型对领域术语不敏感。通用嵌入模型在专业领域往往表现不佳因为领域术语在它的训练数据里出现频率低向量表示不准确。解决办法要么是用领域数据做微调要么是在检索时把领域术语先做一次归一化映射把同义词统一成标准表述再嵌入。4.2 图查询超时或子图爆炸图查询最常见的性能问题是超级节点——某个节点有几千上万个邻居一旦扩展到它查询就会拉出一大片子图既慢又噪声大。排查方法是先统计一下节点度数分布看看有没有度特别高的节点。处理超级节点有几种策略一是限制单节点的扩展邻居数按关系权重排序取Top-N二是对超级节点做特殊标记查询时跳过或降权三是把超级节点的关系做分层先查一层概要再按需下钻。另一个性能问题是多跳查询没有方向性。比如你从A出发做两跳扩展如果不限制关系方向可能会先走到B再走回A做了一堆无用功。在查询语句里明确方向能省不少时间。4.3 大模型输出不稳定的排查模型输出不稳定的表现通常是同样的输入有时回答得很准有时答非所问有时干脆编造关系。排查思路分三步先看输入。把喂给模型的完整提示词打印出来检查结构信息是否完整、ID是否对应、有没有明显的格式错误。很多时候问题出在输入而不是模型本身。再看提示词约束。如果提示词里没有明确要求“只依据给定信息回答”模型就可能用自己的先验知识补全导致编造。加一句“如果给定信息不足以回答请明确说明”能挡掉大部分幻觉。最后看模型参数。温度调高会增加随机性Top-P调大也会让输出更发散。编排层建议用低温度加较小的Top-P牺牲一点多样性换稳定性。4.4 常见问题速查表现象可能原因排查动作解决方向召回结果不相关切片粒度不当检查Top-K片段的完整性调整切片策略召回结果不相关嵌入模型不匹配算相似词对的距离换模型或微调图查询超时超级节点统计节点度数分布限制扩展数或分层图查询结果为空实体消歧错误检查实体到节点的映射加消歧规则或上下文模型答非所问提示词结构不清打印完整提示词改半结构化格式模型编造关系缺少约束语句检查提示词约束加“仅依据给定信息”整体延迟高串行调用过多打点各环节耗时并行化或加缓存4.5 几个踩过坑才明白的经验经验一不要试图一次性把图建完美。图模式和数据都是迭代出来的先建一个最小可用的图跑通链路再逐步补充实体和关系。一上来就追求大而全往往卡在数据准备阶段就推不动了。经验二向量库和图库的更新要解耦。新文档进来时先入向量库保证能检索到图库的更新可以异步做。这样即使图库暂时没跟上系统至少还能返回基于文本的答案不会完全不可用。经验三给每个环节加可观测性。召回了几条、命中哪些实体、扩展了多少节点、模型用了多少token这些指标都要打点记录。出问题时没有这些数据排查全靠猜效率极低。经验四缓存高频查询的结果。很多知识检索场景里用户问的问题是高度重复的。把“问题向量→最终答案”的映射缓存起来命中时直接返回能省掉后面所有环节的开销。缓存失效策略可以按时间或按数据更新事件来触发。这套东西跑通之后你会发现它真正的价值不在于某个单点技术有多先进而在于三层之间的配合是否顺畅。向量库负责广撒网图库负责理关系大模型负责做判断任何一层拖后腿都会让整体体验打折扣。我个人的体会是把精力优先花在数据质量和图模式设计上收益远比调模型参数大得多。
