1. 为什么传统RAG切块方案在多跳问答里频频翻车
先讲一个我实际遇到的场景。某公司内部的智能问答系统，早期是基于经典RAG（检索增强生成）搭建的。向量库里存的是按固定窗口切好的文档块，512个token一段，重叠64个token。当时跑单轮事实性问题，比如“XX服务的超时时间默认是多少”，效果还不错，准确率能到八成以上。但一旦换成多跳问题，效果立刻崩盘。
所谓多跳问题，就是答案不能从单独一段文本里直接取到，需要把多个段落的信息串联起来推理。比如“A项目的验收标准里提到的性能指标，后来被哪个版本的需求文档改过？”这种问题，你要先定位验收标准里提到的指标是什么，再顺着指标去找后续需求文档里的修改记录，中间隔着至少两层关联。这种问题在传统切块方案里几乎无解，原因很直观：固定窗口切出来的块，只保留了局部上下文，跨块的实体关系、时间顺序、因果逻辑全部断裂。
我一度认为问题出在embedding模型不够强，换成更大规模的向量模型之后，单跳检索的召回率确实涨了，但多跳问答的提升非常有限。后来想明白了，embedding解决的是“语义相似度”问题，而多跳问答需要的是“图上的路径推理”能力。相似度和路径，是两个维度的东西。就像你拿一本百科全书，每页都是高清扫描，但你要回答的问题需要跨五个页码关联信息，检索器只能帮你找到最像的那一页，剩下的四页它不知道去哪找。
这个瓶颈直接推动我去调研句子图谱这条路。核心思路很朴素：既然文档是离散的块，那干脆把文档拆成句子级别的原子单元，然后以句子为节点，在它们之间显式建模各种关系，形成一个可遍历的图谱。这样多跳问题就从“模糊语义召回”变成了“图上定向寻路”，至少在机制上是对的。
在正式动手之前，我看了几篇相关方向的论文和开源实现，结论是：这个方向完全可行，但工程细节比想象中多。真正让我下定决心自己写SentGraph的原因是，现有工具要么偏研究、要么绑定特定大模型生态，抽出来用到实际业务上，定制成本太高。这文章会把我在构建SentGraph过程中踩过的坑、验证过的有效性、以及最后落地时的设计取舍完整写一遍。不想讲得太学术，就以工程实践的角度聊。
2. SentGraph的核心构造：句子节点、关系边、图存储三者如何取舍
既然叫句子图谱，第一个问题就是“句子”这个粒度到底怎么定义，第二个问题就是“关系”有哪些类型，第三个问题是图本身用什么存储。这三件事定下来，整个系统的地基才算稳。
2.1 句子边界识别：分句器选型与边界失效场景
句子边界识别听起来是个小问题，实际上非常影响图谱质量。我最初直接用正则表达式按句号分句，结果在技术文档场景里翻车率很高。原因是文档里有大量英文缩写、版本号、编号列表，比如“v3.2.1”“Fig.4”这类跟随句号出现的字符串，正则很容易误切。
后来换成了基于统计的分句器，但仍然会踩一个隐含的坑：PDF转出来的文本里，换行符经常出现在句子中间，导致一个完整句子被拆成两个节点。这里我的处理方案是在分句之前先做文本清洗，把孤立换行合并为空格，同时保留列表结构中的必要换行。多轮调整下来，分句召回率稳定在98%以上才够用。
分句粒度直接决定了图谱节点的数量级。我处理的语料大约是一批内部技术文档，总量约12万个句子，这个规模在单机上用内存图谱完全没有压力。如果换成千万级句子的互联网语料，那就必须考虑分布式图存储了，这个后面讲工程化的时候再展开。
我的结论是：句子粒度是图谱信息密度的最优解。段落粒度太大，关系抽取容易糊成一片，无法精细表达“A句提到的事件引发了B句的变更”这种细颗粒关联；短语粒度太小，节点数量爆炸，且很多短语本身没有独立检索价值。
2.2 边的定义：从三种基础边到带权重的复合边
图谱的表达力，很大程度上取决于边定义是否贴近业务语义。在SentGraph里，我设计了三种基础边类型，它们的来源和处理方式完全不同。
第一种是相邻边。也就是一个文档内，句子在原始上下文中的前后顺序关系。相邻边的价值在于保留语篇连贯性，后续做路径推理时可以顺着句子顺序回看上下文，类似人类阅读时的前后文记忆。相邻边的权重是固定值，我设为1.0。
第二种是语义相似边。通过句子向量计算相似度，超过阈值的句子对之间建立一条无向边。这个维度用来捕捉文档之间跨越位置的语义呼应。比如一篇需求文档说“要求延迟低于200ms”，另一篇设计文档说“系统需要在200ms内响应”，这两句用词不同、位置不同，但语义几乎重合，语义边能把它们连起来。
第三种是共指边。通过实体识别和共指消解，把包含相同实体的句子连起来。例如在两个不同模块的文档里都提到了同一个接口方法名，那么这两句话通过共指边连接，后续检索“这个接口被谁调用”时就能快速跳转。
邻边的权重计算我这里说细一点。语义边的权重就是相似度分值，共指边的权重则做了一个简单增强：如果两个句子共指同一个实体且该实体在各自句中均为主语，那么权重上浮0.3，其他情况保持基线相似度。这个设计的理由很直白，主语的共指往往意味着更紧密的“主体延续性”，对多跳推理的价值远大于宾语位置的共指。
三条边建完后，每个句子节点会同时具备局部连贯性、全局语义关联和实体扩展能力。从后续检索的效果看，这个复合边设计比只用单一类型的边要稳定得多。我在早期版本中只用了相邻边加语义边，结果在“跨文档实体溯源”类问题上召回率明显偏低。加上共指边之后，这类问题的准确率提升了将近14个百分点，代价是构建时间多了大约8%，完全可接受。
2.3 图存储选型：内存哈希表起步，图数据库视规模而定
图存储是我踩坑比较多的一块。最初我天真地把所有边存在关系型数据库里，每条边一行，结果检索的时候频繁join，性能完全跟不上。后来换成了纯内存方案，只用Python的字典加列表结构，节点表映射句子ID到句子文本和向量，边表维护邻接列表。对于百万边级别的规模，这个内存方案非常直接高效，检索一跳的开销平均只有0.2毫秒左右。
如果节点数突破千万级，内存方案就会变得吃紧，这个时候才需要考虑真正的图数据库。我研究过几款主流图数据库，结论是如果业务没有“动态多维度属性过滤”的需求，上图数据库带来的收益很小，反而是额外的运维负担。图数据库适合那种边类型极多、需要灵活查询语法的场景，像SentGraph这种固定三类边但追求极致检索性能的系统，内存邻接表几乎是最优解。
但内存方案有个需要注意的点：图的持久化和加载。我采用的方式是把整个图谱序列化成自定义二进制格式，加载时一次性反序列化到内存，启动时间控制在秒级。实时更新则通过增量边日志实现，每次文档更新后重算受影响句子的边，再合并进内存图。这部分我在第七章会专门聊工程化问题。
3. 层次化结构的设计思路：三层层级如何提升检索效率与可解释性
标题里特意写了“层次化”，这确实不是噱头。我在第一版只做了平面图谱，效果能跑通，但有两个问题非常扎心：一是检索时需要遍历的候选节点太多，噪声太大；二是图谱规模一大，解释性很差，前端把子图展示给用户时，用户根本看不懂为什么这些句子会关联在一起。
层次化的本质是把“图谱的视野”从显微镜变成可调焦距的望远镜。细看时能看清句子级细节，拉远时能看到主题级全貌，并且支持在多个视野之间来回切换。这样做给多跳检索带来了三个关键好处。
3.1 三层结构解析：句子层、段落层、主题层的组织方式
我把图谱分成三层。最底层是句子层，也就是把所有句子的节点和它们之间的细粒度边都保留。中间层是段落层，把同属于一个原始段落或逻辑块的一组句子聚合为一个段落节点，在段落节点之间建立继承自下层句子的聚合边。最上层是主题层，通过聚类算法把围绕同一子话题的多个段落再聚合为主题节点。
主题层的构建我采用了一个半自动方案。先对段落嵌入做层次聚类，得到聚类簇后，给每个簇自动抽取代表性关键词，生成主题标签，再由业务人员审核调整。全自动的聚类标签在内部文档场景下出现过明显的主题混淆问题，比如“性能”和“容量”两个主题经常互相掺杂。半自动审核比较适合可控的领域语料。
这三层之间通过上下级指针关联，每个句子知道自己属于哪个段落，每个段落知道自己属于哪个主题。查询的时候可以先在主题层定位候选范围，再下钻到句子层做精细匹配。这种“先粗后细”的检索策略，比直接在几十万句子节点里暴力搜索效率高出好几个数量级。
3.2 层级感知的索引结构：全局索引与局部索引的分工
在设计索引时，我把索引分成了两层。全局索引负责图结构和主题路由，局部索引负责句子内部的文本匹配和向量召回。全局索引的数据结构是主题节点的邻接列表，局部索引是每个主题内部的句子向量索引。查询先走全局索引锁定3到5个主题，再走局部索引召回候选句子。这样既控制了检索范围，又不会遗漏跨主题的关联路径。
这里有一个人为设计的权衡点：为什么不直接对所有句子向量做全局ANN索引？因为全局向量索引会把“距离近但语义不同主题”的句子混在一起，导致图谱遍历时需要大量剪枝。主题层先做一次路由，等于给遍历划定了高速公路收费站，后面的路径搜索就不用堵车了。
3.3 层次化如何实际改善多跳推理：一个案例演示
用一个实际案例来说明。假设知识库里有一句“认证服务在v2.3版本后启用了新的令牌格式”，另一句在完全不同的文档里写着“旧令牌格式在存量客户端中仍被兼容”。这两句话在句子层的语义相似度其实不高，但它们都属于“认证兼容性”这个主题。当用户问“新令牌格式是否影响存量客户端”，普通RAG只能召回第一句或第二句之一，然后就结束了。SentGraph会先在主题层定位“认证兼容性”，再在这个主题域内同时召回两句，通过主题边连接起来，使后续生成阶段能把因果链补全。
为什么这个机制在多跳推理里很有效？因为多跳问题的常见特征就是“第一次召回准确，但召回的信息分散在不同语义上下文里”。层次化主题层承担了软性的语义锚点，让跨上下文的关联被显式纳入检索范围，而不是依赖文本的浅层重合。
实测下来，加入了层次化之后，平均检索路径长度从2.7跳提升到了3.4跳，而端到端的问答准确率反而提升了约11%。路径更长但效果更好，说明层次化让更远距离的关联变得可及，同时主题路由过滤掉了大量不相关路径。
4. 多跳检索机制：从查询分析到图遍历再到证据链聚合
图谱建好之后，真正的硬骨头是多跳检索如何设计。这个过程我经历了三轮迭代，从最初的朴素BFS，到后来加入加权剪枝，再到引入查询意图分解。每一轮的改动都对应着明确的失败样例。
4.1 查询分析：把自然语言问题转化为图谱上可执行的搜索意图
在送入图谱之前，查询首先要经过一个分析层。这个分析层的职责有两个：一是抽取查询中的核心实体和关键词，二是判断查询的跳数复杂度。
实体抽取我用了一个轻量的方案，先把查询句子过一遍命名实体识别模型，但不直接依赖模型的结果。因为在技术文档场景里，很多关键实体是自定义的接口名、模块名，命名实体识别模型并不认识。我的做法是把候选词列表同时交给图谱的实体索引去匹配，能匹配到图谱中的真实节点才保留下来。
跳数复杂度判断则是通过一个小的分类器实现的，输入是查询文本，输出是一个整数，表示预计需要的推理跳数。这个分类器我用了几百条标注样本微调了一个小型文本编码模型，效果在内部测试集上够用。有了跳数预期之后，图谱遍历就有了终点条件，不会无脑往下走。
4.2 图遍历策略：加权启发式搜索与剪枝规则的配合
图谱遍历的核心算法我选用的是带权重的Beam Search。具体流程是：先从查询中的每个实体出发，找到对应的种子句子节点，然后并行扩展邻居节点。每一轮扩展之后，用评分函数对所有候选路径打分，只保留分数最高的topN条路径。N我一般设置为5到8之间，太小容易漏掉正确答案，太大则引入大量噪声。
评分函数的设计是这个环节的关键。我把它拆成三个因子相乘：路径上的边权重均值、路径终点句子与查询的语义相似度、路径经过的节点多样性惩罚。多样性惩罚的意思是，如果一条路径反复经过同一个文档或同一个主题下的句子，路径整体得分会打折。这个设计的动机很实际，多跳问题的答案往往需要覆盖多个来源视角，路径太集中说明信息广度高不了。
剪枝规则方面，我设置了两个硬限制。一是最大跳数不能超过查询分析阶段预判的跳数加1，二是路径上不能包含互斥文档（比如同一份文档的不同修订版本）。第二个限制在版本管理的知识库场景里特别重要，不同版本的文档经常会互相矛盾，如果图谱里同时存在新老版本的句子，遍历很可能陷入循环或者得出错误结论。
4.3 证据链聚合：多路径结果如何组装成一致性的证据包
经过图遍历之后，取出数条路径，每条路径就是一条候选证据链。但路径本质上只是一个句子序列，如果没有清晰的因果关系，直接送给大模型生成答案，效果不好。我在这个环节做了一个证据链聚合器，它负责把候选路径映射为核心证据包。
证据包是一个结构化的数据对象，包含一组句子文本、句子对应的来源文档、句子之间的关联类型，以及整条链路的置信度分数。聚合器的合并逻辑是：如果两条路径共享至少一半的句子节点，就把它们合并成一条更长的路径，置信度取高值；如果路径之间句子不重叠，则作为多个候选证据包一起传入下一阶段。
这一步非常重要，因为它直接决定了生成阶段能看到什么、看不到什么。如果证据包本身信息松散，大模型就算能力再强也巧妇难为无米之炊。我在测试中对比过“直接把路径拼接传给模型”和“经过证据包聚合再传”的效果差异，后者的答案准确率在内部评测集上高出7个百分点，主要改善在于跨路径信息整合后的上下文更连贯。
5. SentGraph与生成模型融合：如何把图谱证据链变成高质量问答输出
图谱检索做完，后面就是和生成模型的对接。这一部分有不少工程细节，但真正的难点在于“如何让大模型理解图谱证据链的结构化信息”。如果只是把句子列表拼在一起，大模型会当作普通的候选文档扫描一遍，无法有效利用句子间的路径关系。
我的方案是构造一种“图路径提示词”，把证据链编码成一条包含节点序号和边类型的路径描述。例如：
证据路径：节点A（v2.3版本启用了新令牌格式）→[共指边]→节点B（旧令牌格式在存量客户端中仍被兼容）→[语义边]→节点C（兼容策略将于下个版本退役）
这种结构化的路径文本，让大模型能直观看到推理链条，而不是自己从一堆句子里重新拼线索。实际验证下来，模型在收到这种路径描述时，多跳推理的稳定性显著提升，尤其是生成的答案中能更准确地区分“原文直接结论”和“推理中转结论”。
5.1 生成器选型与上下文组装策略
生成器我选用了当前主流的中大规模指令微调模型，基座模型的能力不需要太强，但上下文窗口一定要够大，因为证据包加上路径描述后可能占据较长上下文空间。组装策略上，我采用“先证据、后路径、再提问”的顺序：先把证据包中的句子文本按图遍历顺序排列，然后在末尾追加路径描述和推理提示词。
为什么要多次一举同时给句子文本和路径描述？因为大模型在回答过程中既需要逐句引用证据，又需要路径来维持推理逻辑。句子文本是素材，路径描述是提纲。只给素材，模型的推理容易发散；只给提纲，模型的回答容易臆造细节。两者叠加，实测效果最稳定。
在整个融合过程中，温度参数我设置得较低，一般控制在0.2左右。原因很直接，多跳问答重在准确，不需要创造性发挥，温度越高答案越容易出现幻觉，尤其是当图谱路径中存在中间推测节点时，高温会让模型把推测当成结论。
5.2 置信度校准与放弃回答机制
这一点是我在多次测试后深有体会的。多跳问答中，图谱路径搜索不总是能找到有效证据链。当证据包的置信度低于设置阈值时，正确的做法不是硬答，而是让模型明确说“当前知识库中找不到完整证据链”。虽然这会影响整体回答率，但能显著拉高回答准确率。
置信度阈值我通过一段时间的线上日志做了校准。从用户点击反馈和后续追问行为来看，当置信度分数低于0.6时，模型给出的答案错误率很高；高于0.7时答案基本可靠。所以我最终把阈值设为0.65，并在这个区间内做一个软性过渡：分数落在0.6到0.7之间时，模型会先说明信息概况，再给结论，避免过分自信。
这个放弃机制带来的整体收益是：用户的无效咨询数量明显下降，系统的专业可信度反而更高。毕竟对于问答系统来说，答错比不答的危害大得多。
6. 实测效果与调参经验：图谱规模、召回率、推理时延的真实数据
效果部分，我用自己的内部评测集做了系统性的对比实验。评测集包含800个问题，涵盖了单跳事实查询、双跳关联查询和三跳及以上的深层推理查询，分布比例约为4:4:2。这里记录几个关键数据。
6.1 基准对比：SentGraph与传统RAG方案的端到端差距
对比对象有两个，一个是固定切块的经典RAG方案，另一个是未加层次化结构的平面图谱检索方案。统一使用相同的生成模型和提示词框架，只改动检索层。结果如下：
| 评测项 | 经典RAG | 平面图谱 | SentGraph（三层图谱） |
|---|---|---|---|
| 单跳问题准确率 | 86.3% | 85.7% | 88.2% |
| 双跳问题准确率 | 51.2% | 63.6% | 72.8% |
| 三跳及以上准确率 | 22.4% | 41.5% | 54.9% |
| 平均首跳召回用时 | 480ms | 320ms | 210ms |
单跳问题的差距不大，甚至经典RAG表现也不差，因为单跳本质上就是一个相似度匹配问题，切块方案的优势还在。双跳问题开始拉开明显差距，而到了三跳以上，经典RAG基本可用性已经很低了。
这个结果也印证了我前面说的观点：多跳推理的瓶颈不在语义匹配，而在路径探索。平面图谱虽然能探索路径，但缺少层次化路由，路径容易发散，导致最终的证据包质量不稳定。SentGraph的层次化结构在双跳和三跳场景中体现出明显优势。
6.2 图谱规模与检索性能的关系：单机到千万节点的扩展预估
我把图谱规模从8万句子逐步扩展到20万、50万句子的规模做了压力测试。在50万句子、约500万条边的规模下，单机内存占用约4.2GB，平均检索耗时为280ms，相比8万句子的210ms只增加了约35%。这个增长曲线比我预期的好，原因在于层次化主题路由把大部分索引扫描限制在局部范围内，避免了全图扫描的线性开销。
如果句子规模继续增长到1000万，理论上单机内存和耗时都会变得不可控，需要引入分布式存储和图计算引擎。我做过一个简单的预估，1000万句子大约对应1亿条边，纯内存存储需要约60GB，推荐方案是把主题层路由放在内存，句子层的向量和边索引拆到远端KV存储，检索时按需拉取。这样单节点可以支撑更大的规模，但推理时延会有明显增加。
对大多数企业内部知识库来说，几十万句子的规模是主流，单机方案完全够用，这也是我在工程实现中优先保证单机性能和易部署性的原因。
6.3 调参手感：我调整过的关键超参数及观察到的变化
这一部分分享一下我在调参过程中的具体体会。首先是相似度边的阈值，我最初设为0.75，发现图谱变得过度稀疏，很多语义相近但表述差异略大的句子无法形成连接。反复下调到0.62之后，边的数量翻了两倍，但多跳路径的覆盖度明显提升。不过要留意，阈值过低则会把不相关句子连进来，噪声会快速累积。以我的语料特点来看，0.65是一个不错的平衡点。
其次是Beam Search的宽度N。N从3增加到8时，召回率上升约5个百分点，但检索耗时几乎翻倍。后来我让N根据查询分析阶段的跳数复杂度自动调节：单跳问题用较小的N（4），三跳以上用较大的N（8）。这样不需要为了少数高跳问题牺牲所有查询的响应速度。
最后是置信度阈值的校准方法。我采用的方法是先随机抽选200条线上日志，人工标注答案正确与否，再映射到对应的置信度分数，画出一条置信度和正确率的散点曲线。曲线在0.55到0.7之间是陡峭上升的，0.7之后趋于平缓，这说明阈值设在0.65确实比较合理。
7. 部署落地中的工程问题与实践笔记
很多技术方案在实验室里跑通不代表能上线。SentGraph的部署过程中有几个工程问题值得专门写一写。如果这些坑没提前排掉，系统在上线后的稳定性会非常糟心。
7.1 图谱的增量更新：文档修订后的重建策略
文档库绝不是静止的，尤其是企业内部知识库，文档每周都会有修订和新增。如果每次更新都全量重建图谱，计算成本太高；但如果只增量更新，又要小心旧边残留和新旧文档冲突的问题。
我采用的方案是为每个文档记录版本号，图谱中的每个句子节点都带上来源文档的版本标识。当一份文档更新时，我把旧版本对应的句子节点及其出边全部标记为失效，然后重新构建新版本的句子节点和关系边。相邻边和语义边的重算是局部范围的，只涉及更新文档及其语义相似度最近的若干邻居。这个方案下，单次增量更新涉及的计算量只占总图谱的5%左右，可以实现在线热更新。
7.2 在线更新中的图一致性：原子替换与只读快照
增量更新最怕的就是用户查询读到了半新半旧的数据。为了保证一致性，我在更新时采用写时复制加原子指针替换：每次更新先生成一份新的图快照，所有查询请求在快照上执行，更新完成后将请求路由切到新快照，旧快照在无请求后再释放。这个设计让在线查询完全不受更新进程干扰，代价是内存占用会临时出现双倍的情况。对于部署在8GB内存以内的节点，需要规划好更新时段，避免高峰时刻内存溢出。
7.3 存储与序列化格式：自定义二进制协议还是JSON
存储格式我对比过多种方案。JSON最直观，但序列化和反序列化的开销太大，50万句子的图谱加载需要将近20秒。MessagePack比JSON快一些，但仍存在较大的内存中间态。权衡之下，我写了一个自定义的二进制序列化协议，把节点表、边表、主题索引和向量索引分别编码存储，加载时间降到3秒以内。
这里有个实际经验：不要把向量索引和图结构放在同一个序列化文件里。句子向量动辄上百MB，而图结构相对小巧。把两者拆开之后，冷启动时先加载图结构，向量索引按需加载，体验会好很多。
序列化格式我额外加了一层校验哈希，避免文件损坏造成加载静默失败。这个坑我实际踩过，早期版本没有哈希校验，有一次图谱文件在拷贝过程中损坏了两个字节，加载进程没报错，但检索结果变得莫名其妙，排查了很久才定位到是文件损坏。
7.4 监控与日志：检索路径可视化是排障第一工具
上线之后，监控体系比模型效果更重要。我把检索链路中每个阶段的日志都做了结构化输出：查询分析结果、命中的主题列表、遍历出的路径链路、每个节点的置信度分数、最终生成的答案。当一条回答出错时，直接回溯日志就能定位是检索层漏召回、路径层剪枝错，还是生成模型幻觉。
这一点是SentGraph相比传统RAG项目的一个优势。传统RAG出错了很难定位，因为你不知道模型到底是基于哪段上下文生成了答案；而SentGraph本身就是图结构，每条路径可以渲染成一幅子图，排障时直接把子图发给业务方，对方能直观反馈哪一步关联有问题。检索路径的可视化能力，在B端知识库场景里几乎是刚需。
7.5 维护一个句子图谱系统的时间与人力成本
最后说个很多人关心的话题——这系统到底要多大的维护成本。我的体会是：图谱构建是一次性成本，后续核心维护集中在主题层调整和失效文档清理。句子拆分、嵌入向量生成、边计算这些过程全部是自动化流水线，每周跑一次即可。主题层更新则每月需要投入几个小时进行人工抽查，因为业务主题会随着文档演进发生漂移，失去监督的主题标签会逐渐失真。
这个成本相较于它带来的多跳问答能力提升而言，完全划算。如果团队有自然语言处理或知识图谱方向的工程师，单人维护这套系统没有任何问题。
8. 后续可扩展的方向与我对这个路线的持续思考
SentGraph当前版本已经投入使用，但它的能力还有明显的扩展空间。我在设计之初就预留了一些可插拔的接口，后续可能逐步接入，这里简单聊几个方向。
第一个方向是动态知识的时效性引入。当前图谱的边主要是静态的语义关联，没有时间维度的感知。如果能在共指边和语义边上附带时间戳权重，比如“最近更新过的文档对应的边权重上调”，那图谱对近期变更问题的感知能力就会更强，尤其适合那种知识库持续演进的业务。
第二个方向是多模态信息扩展。目前整个图谱只处理了文本句子，但内部文档中大量信息存在于表格、流程图和界面截图中。已尝试把表格转成文本描述后纳入句子层，效果不错，但流程图和截图的信息抽取还是空白。如果未来能把图片中的结构信息转化为可检索的句子节点，多跳问答的覆盖面还能再上一个台阶。
第三个方向是反馈闭环。现在图谱只服务于问答，我认为可以反过来从问答中学习。当用户对某个答案的反馈为负时，系统自动检查对应检索路径，如果发现路径中某个边权重导致错误关联，就下调该边权重。这会形成一个类似推荐系统里的在线学习环路。目前我还没有落实全自动闭环，而是用半自动的方式在离线日志中做周期性的边权重校准。
回顾整个项目，我最大的体会是：多跳检索增强问答本质上是一个“信息组织方式”问题，而不只是一个“模型能力”问题。图谱可以成为大模型和知识库之间那个中间层，既让模型获取结构化证据链，又不修改模型本身的能力。这和当前主流增强生成思路是互补的，它不追求让基座模型变聪明，而是致力于让模型“看到”的信息更结构化、更易推理。
每次调试路径遍历的剪枝规则时，我都能切身感受到检索链路对答案质量的杠杆效应。很多时候我们第一反应是换更大的模型来解决问题，但如果仔细排查检索链路，往往能发现问题的源头在信息组织层面。这个思路对任何构建知识问答系统的团队，都值得认真评估一次。
最后想说的是，没有任何方案能覆盖所有问题形态。SentGraph最擅长的场景是知识库内的跨文本推理，如果你遇到的问题大多是单点事实查询，传统RAG的成本和效果已经是很好的平衡了。但在多跳问题的重灾区，句子图谱这条路我用实际数据验证过，走得通。
