返回 TraceWise 项目总览 · 交互图：端到端 · 工作流 / 产品 · 运行时 · 架构
很多项目把“接入 RAG”理解成两步：把文档切成文本块，再把与问题最相似的几段文字送给模型。这种方法能回答局部事实，却很难处理项目调查中的另一类问题：一个风险经过哪些依赖影响交付？某个方案与哪些约束冲突？一条结论依赖的是哪个版本、哪条关系和哪份 Evidence？
TraceWise 面对的不是单篇文档问答，而是项目关系分析。因此检索结果不能停留在一列文本片段。它需要先找到候选实体，再沿真实关系组织局部结构，最后把结论、缺失依据和冲突暴露给用户。
这篇文章只回答一个问题：TraceWise 如何把一次查询变成可检查的子图，而不是把“向量相似”包装成完整解释。
单一相似度为什么不够
项目知识具有几类同时存在的信号：
- 名称和缩写需要精确匹配；
- 描述和术语需要一定的语义容错；
- “风险”“人员”“服务”“决策”等查询隐含节点类型；
- 已选节点和查询结果之间可能存在直接关系；
- 高度相关的种子节点周围，往往还有解释路径所需的邻居。
只按文本相似度排序，会把“措辞相近”误当成“项目上相关”。只按图距离扩展，又会把所有邻居视为同等重要。TraceWise 的做法是保留多个可分辨信号，并把每个结果的分数组成暴露在响应中。
当前 MultiSignalSearch 综合 phrase、label、keyword、semantic、relation 和 type 等信号。关键词重合考虑文档频率；确定性向量用于提供有限的语义容错；类型先验识别查询中的类别别名；关系信号衡量候选与原始命中集合的邻接重合。权重可以配置，但排序结果仍是工程启发式，不是学习到的相关性概率。
query
├─ phrase / label：名称、缩写与短语
├─ keyword：带文档频率的词项重合
├─ semantic：确定性向量相似
├─ type：节点类型与别名先验
└─ relation：候选与命中集合的关系重合
↓
ranked node seeds
重要的是，接口不会只返回总分。它还返回 signal breakdown 和 diagnostics，使调用方能够回答“这个节点为什么被选中”。
从候选节点到问题子图
候选节点仍然不是解释。项目问题通常跨越多条关系，例如“模型升级为什么影响报告可信度”可能同时涉及模型版本、检索策略、Evidence、评估规则和报告生成。
子图编排器先根据问题、当前选中节点和显式上下文 ID 形成种子集合，再沿邻接关系扩展。扩展过程考虑：
- 搜索分数；
- 关系类型权重；
- 跳数衰减；
- 节点连接度；
- 每个子图的节点上限；
- 最多保留的子图数量。
相互高度重合的候选子图会被合并，避免把同一局部结构拆成多个看似独立的“Agent 结果”。最终得到的是围绕问题组织的责任段，而不是整个项目 Graph 的无差别复制。
技术解释图：检索与 Agent Context 位于 Host Model 调用之前，Graph、Evidence、Inference 和治理仍由明确的产品服务负责。该图解释关系，不证明检索质量。
子图分析输出必须带 Evidence 缺口
每个子图责任段会整理节点、关系、枢纽节点、候选 claims 和 Evidence。系统同时保留 missing_evidence 与 conflicts，而不是只输出一段流畅回答。
这样做的原因很直接：一个结构上合理的路径并不自动等于事实成立。Graph 能说明节点如何连接，Evidence 才能说明这些连接和结论凭什么被接受。没有 Evidence 的高连接节点，可能只是建模较充分，并不比低连接节点更真实。
TraceWise 因此把两个问题分开：
- 哪些项目对象可能与问题有关？ 由多信号检索与关系扩展回答。
- 这些关系是否足以支持结论？ 由 Evidence 链、缺口和后续人工审阅回答。
技术解释图：检索只是工作流起点，候选上下文还要经过推演、Evidence 检查、人审和历史记录。
为什么需要用户可以回到 Graph
搜索结果不是一个只读答案。工作台可以将命中节点重新聚焦到 Graph Canvas，用户继续查看邻域、路径、实体详情和 Evidence 状态。也就是说，检索负责缩小范围，Graph 负责呈现结构，Evidence Inspector 负责检查依据。
真实产品截图：Graph Canvas 用节点与关系呈现项目知识结构；画面使用合成项目数据，不代表真实客户环境。
这种交互比“模型给出答案后无法追问来源”多了一条回溯路径：用户能够看到哪些节点进入了当前分析，也能发现系统遗漏了什么。
降级比静默失真更重要
检索系统不能假设所有增强索引永远可用。当前实现保留候选索引模式，并在增强候选路径不可用时回到基础 Graph 搜索。响应会标记使用的 mode 与 fallback，而不是继续返回一个无法解释来源的“正常结果”。
降级路径的目标不是保证与增强路径完全同质，而是保证：
- 用户仍能得到有限但可解释的结果；
- 调用方知道发生了 fallback；
- 不因索引故障而偷偷改变写入或治理语义；
- 后续可以依据 diagnostics 判断是否需要重试或修复索引。
这套机制没有证明什么
当前证据可以确认多信号评分、候选扩展、子图上限、信号诊断和降级路径存在，也有 API 与前端测试覆盖基本工作流。但它没有提供一个独立、冻结的数据集来证明：
- 多信号一定优于向量检索；
- 排名分数等于真实相关概率；
- 子图结论具有经过校准的正确率；
- 当前实现满足生产数据规模下的性能要求。
这些判断需要查询集、人工相关性标签、明确基线、NDCG／Recall 等指标和可复现实验。TraceWise 当前更可靠的价值是：它把检索从“黑盒相似度”推进到“候选节点、关系路径、Evidence 与缺口都可以被检查”的产品机制。
可复用的设计结论
面向复杂项目知识的 RAG，可以按三层拆分：
- 用多信号召回候选，不把任何单一分数神化；
- 用关系扩展形成问题子图，不把整个知识库塞入上下文；
- 用 Evidence 和缺口约束结论，不把结构相关性当成事实正确性。
检查检索结果时，读者可以沿子图查看对象为何入选、关系如何连接，以及哪些节点还缺 Evidence。这些记录用于定位检索与依据缺口；回答准确率需要另行评测。