节点已经找齐，关系为什么还是没显示？

返回 TraceWise 项目总览

查找一个函数属于哪个类，结果里出现了函数节点和类节点，看起来已经成功了。但如果图上没有连接它们的关系，用户仍然不知道：这个类定义了该函数，还是只是提到了它？

TraceWise 在一轮真实接口回归中遇到了这种情况。7 道定义归属题的两个目标节点全部进入结果，只有 4 道返回了必要的有向关系及其登记依据。另 3 道不是节点没找到，也不是证据已经失效，而是关系在最后的展示阶段被截掉了。

这次修正没有更换向量模型，没有增加重排，也没有扩大关系数量。它只调整了一件事：同样 20 个关系展示名额，应该先给哪些关系。

节点命中，不等于关系问题完成

对“某个函数由哪个类或模块定义”这类问题，两个名字只能构成答案的一部分。还需要看到它们之间的实际连接，并确认方向、关系类型和依据。

例如，函数节点与类节点同时出现，不能自动推导类定义了函数。它们可能只是共享某个文档来源，也可能通过另一种关系连接。如果界面根据共同出现的位置画一条线，反而会制造一条原图中没有的知识。

因此，这轮检查把任务拆成三个观察点：是否找齐指定节点，是否返回原有的目标有向边，以及返回的边能否定位到正确版本的全部登记依据。后两个观察点不能用第一个替代。

46 道固定源码题中，43 道有候选正例目标，另 3 道资料不足，只作诊断。7 道定义归属题是 43 道的子集。这个集合适合暴露结构与展示问题；它不是人工独立标注的通用知识问答集。

稳定排序怎样变成了不合适的展示排序

旧逻辑取得当前有效关系，筛出至少一个端点位于本次节点结果中的邻边，然后按内部 ID 排序，取前 20 条。稳定 ID 排序的优点是相同输入得到相同顺序，但 ID 的大小不表示关系对本次问题的重要性。

问题在连接很多对象的节点上尤其明显。假设搜索结果命中了一个类，它可能有许多方法、文档与其他对象的邻边。即使目标函数也已经命中，类与函数之间那条关系仍要和大量只接触一个命中节点的邻边竞争展示名额。

对当时的完整冻结图和实际返回逐项核对后，3 个遗漏都可以定位到同一个截断点：

三条关系都还在当前有效图里。继续扩大向量召回，不能改变它们在这个展示窗口里的位置；反复检查 Evidence 是否撤销，也解释不了这次遗漏。根因在产品侧对已取得关系的分配顺序。

先用一个更小的反例检验规则

修复没有针对这三个题目添加例外，而是构造了一个与题号无关的反例。候选中有 21 条只连接一个命中节点的 hub 邻边，ID 从 hub-00 到 hub-20；另外有一条同时连接两个命中节点的关系，ID 为 z-dual。

总共 22 条关系，预算为 20。旧排序必然先返回 hub-00 至 hub-19，把 z-dual 排除。即使两个端点已经正确命中，它们之间唯一的已知直接连接仍然没有机会出现。

新的规则先按命中端点数量降序排列：两个命中端点优先于一个；数量相同时，再按内部 ID 排序。这样，反例中先返回 z-dual，剩余 19 个名额仍按照稳定顺序分给邻边。

查看原图

最小反例：候选集合没有扩大，返回上限没有增加，只改变展示名额的分配。分组框是数量构成说明，不按面积表示比例。

实现中保留原来的 source 和 target，没有为了看起来顺畅而调换方向。它只选取已经存在的当前关系，不生成关系、不推导额外路径，也不在展示时通过答案标签补查某条边。

为什么这条规则属于产品，而不是底层权威治理

Foundation 负责判断：在当前登记、版本和依赖约束下，哪些图对象可以使用。TraceWise 则要判断：面对本次搜索结果，有限的展示空间应该优先解释哪些连接。

两端命中优先是一种展示选择，不是一条新的知识真实性规则。仅命中一个端点的关系并没有因此变成无效，也没有失去原文依据；它只是可能在这次结果中排在后面。

这个区别使修复范围能够保持很小：节点上限仍为 10，关系上限仍为 20，九信号权重、Graph 范围、公开治理读取与 Evidence 生命周期不变。关系选择也没有增加一次模型调用。

若另一种产品任务专门要从一个节点向外探索新的对象，那么单端邻边可能正是最有价值的结果。双端命中优先适合这里的“解释已找到对象之间的连接”，不能直接宣布为所有图探索场景的最佳策略。

同题回归改变了什么

修正前后使用同一隔离部署、注册范围、post22 运行环境、7 份固定 Python 源码、328 个节点、321 条关系和 60 个 Evidence 版本。46 道题各顺序执行一次；请求只携带原问题、范围和固定上限，标签在返回之后用于判分。

这里最重要的对照是：46 道题的节点顺序、分数、九项信号、对象内容和非易变引用逐题比较，变化为零。节点不变而联合完成数改变，说明这次收益来自关系出口，而不是更强的节点召回。

对于已经返回的目标边，再实际读取其依据。修正前读取 5 份、修正后读取 9 份，内容和身份均匹配。读取数增加是因为更多目标边得到返回。两轮分母不同，因此这里只记录各自的内容与身份一致性。

两个阶段总计 92 次节点请求、14 次按需来源请求，没有新增在线模型调用。这个修正本身不以延迟优化为目标，也不与此前维护式图读取的单题耗时合并计算。

回归通过以后，仍然有哪些问题

7 个归属标签还对照了冻结 Python 原文的 AST，核对直接类或模块定义作用域。这样可以避免仅用图中的一条边证明这条边正确。不过，AST 验证的是代码结构，不是人工对自然语言问题的独立语义判断。

并且，这次修复是在看过旧题失败后作出的。4/7 到 7/7 是有明确原因的缺陷回归结果，不能写成独立留出集准确率，也不能推导所有关系搜索问题都已经解决。

修正后，43 道正例题中仍有 5 道未找齐指定节点，其中 1 道同名题、4 道自然语言描述题；描述题的完整目标只有 3/7。这些问题发生在节点阶段，调整关系展示不会替它们补齐答案。

关系上限同样仍然存在。如果双端命中的关系本身超过 20 条，同组 ID 排序仍可能遗漏用户需要的边。是否需要按关系类型、路径或查询意图分配预算，应该在对应任务和新评价材料中另行验证。当前结果不支持立即引入一套更复杂的关系重排器。

从这个缺陷看检索系统的最后一段

用户最终看到的结果，受召回、排序、有效性过滤和展示截断共同影响。只观察前一阶段是否成功，容易把最后一段的损失藏起来。

这次修正留下的规则很具体：先确认必要信息在哪个阶段消失，再修改那个阶段的契约。节点已经命中、关系已经存在时，首先需要解决的是展示名额的分配，而不是继续添加检索模型。

这项修正完成了展示缺陷的本地真实接口回归，尚未正式发布。独立业务质量验收与正式版本采用仍需另外完成。