一份文档究竟该切几次：TraceWise 的来源、证据、索引与引用

返回 TraceWise 项目总览

把一份长文切成小块，再做 embedding，是检索系统里很常见的起点。等到系统需要回答“这个关系来自哪里”“原文更新后哪些内容还能用”“为什么点击引用没有高亮正确句子”时，问题就不再只是块长应该设为多少。

TraceWise 的检索开发涉及两种使用方式：读者可以直接查原文，也可以先定位图上的概念或关系，再沿声明的依据返回资料。两种方式都需要文本，却不要求所有环节使用同一个文本块。我的主要决定是把来源身份、证据治理、索引表示和精确引用分开；后来的长文档处理又补上了抽取任务的粒度。这样，改进召回时不必同时改写证据身份，调整引用时也不必重新定义整张图的依赖。

先分清资料进入检索与引用的四种对象

原始文档回答“材料是什么”。它保留接收时的字节内容、文件身份和完整哈希，是复核其他对象的起点。一份文档可能有多个章节、重复术语、表格或代码；这些结构本身还没有告诉系统，哪些内容适合参与某次召回。

受治理的 Evidence 单元回答“哪一份内容以什么身份被登记”。登记后取得准确的 revision 和内容指纹，后续查询据此判断该对象的版本、撤销与有效性。这里的文本可以是一个有来源映射的章节，而不必缩到一句话。它承载的是治理边界，不是“这个章节里的每一句话都支持当前结论”的语义承诺。

索引切片回答“用什么表示参与检索”。一个 Evidence revision 可以产生多个片段；切片尺寸、文本表示、模型和索引代次属于这层配置。结果命中的是一个候选窗口，之后仍要回到登记内容确认身份，不能只凭向量相似度把候选当成可靠事实。

精确引用回答“结论具体依赖哪一段”。它应落到某个固定来源或 revision 的明确区间，而不是只展示文档标题。读者需要看到的句子通常比用于召回的窗口更短；必要时，多个引用还需要合在一起才能支持一个要点。

查看原图

职责对照：载体、治理、召回和定位需要不同的对象边界。这四层可以关联，但不要求一对一。

为什么把章节登记为证据单元

如果每一句话都登记为独立 Evidence，引用会很细，却容易丢掉适用条件。例如某段写“出现请求超时后应先核实结果”，下一段补充“仅对已确定失败的操作重试”。单独存储两句话并不会自动保持这个约束。反过来，把整本文档登记为唯一单元，又会让一次局部变更牵涉过大的依赖范围。

2026 年 9 月 10 日的来源准入实现采用一个折中：沿 Markdown 标题结构划分来源章节；实现以二级标题（H2）所在层次作为章节边界，超出预算时优先落在块边界。这里的预算是完整序列化 payload 的 48 KiB，不是正文字符数，更不是模型 token 数。路径、哈希、区间和 JSON 转义也会占用空间。

一个章节过大时，程序寻找预算以内的块边界；如果一个块本身就太长，会显式记录强制拆块。处理结果拼接后必须还原原始文本，而不是只保留解析器提取出的可见文字。表格、代码围栏、列表以及原始换行都可能影响复核，不能因为展示层暂时不用就从来源映射中消失。

这项实现带来的可确认能力，是保留完整来源、限制单元大小，并标明结构被拆开的地方。它没有证明“按标题切分在所有资料上优于固定切分”。要讨论检索收益，还需要同语料、同模型、同问题与上下文预算的切分对照；章节边界合理，不等于排序质量已经得到测量。

登记较大单元，为什么仍要保留短引用

设想一个章节同时介绍超时、幂等与转人工。把它作为 Evidence 单元登记，可以使来源身份和版本校验保持稳定；图上的“重试需要幂等约束”这条关系，仍应记录实际支撑该主张的原文范围。这是一个解释用场景，不是本轮测试原题。

这样，用户点击关系时能区分“这份登记材料仍可用”和“这几句话支持该主张”。前者是有效性判断，后者是内容解释。只展示整个章节，容易让用户自己寻找论据；只返回短句，又可能隐藏限定条件。更合适的呈现是保留上下文，并对准确区间做定位。

引用还可能跨越两个 Evidence 单元。当前准入工具会保留所有覆盖该原文范围的单元，不因边界碰巧落在中间而漏掉一半。如果资料给出两个充分的替代支持组，则明确选择其中一个并保存选择记录；不能把“任选一组即可”悄悄改成“所有来源都必须有效”。这套准入实现没有自动切换替代依据的机制。

历史对照中的两组数字，不能串成一条转换链

2026 年 9 月 10 日的正文检索对照复用的是 24 份固定资料、432 个 Evidence revision，以及 637 个 canonical-JSON 向量片段。它们来自同一套已有候选检索库。原文 revision 数与索引片段数不同，本身就是治理粒度和召回粒度分开的体现。

另外一套业务开发图使用 12 个固定来源，登记了 161 个 Evidence 单元。其中 159 个是完整原文的分段单元，另外 2 个是明确标为派生材料的捕获元数据摘录。这套图包含 142 个节点、131 条有方向关系，经历了公开治理准入与当前内容读回，但尚未为该业务图建立正文语义索引。

查看原图

数据边界对照：两列属于不同夹具。不能写成“161 个证据切出了 637 个向量块”，也不能用节点数反推每个证据的文本长度。

这里还有一个容易忽略的材料筛选问题：用于比较历史捕获的完整文件中包含旧问题。将整包送进正文索引，会把测试材料也变成可检索内容。因此，第二套图只从明确引用的位置导出时间与代码哈希，保留父文件身份及派生标记。它们可以证明捕获来源，不代表真实发布版本，更不能作为额外的正文召回成绩。

比块长更容易出错的是坐标系

同样写作 start=100, end=150，可能指原始文件解码后的 Unicode 字符，也可能指某个 Evidence 的 payload.text，还可能指整个 canonical JSON 字符串。三个数值看起来一样，位置却完全不同。

例如原始正文中的换行，在 JSON 字符串里需要转义；字段名称和其他元数据也会进入 canonical 表示。把 canonical-JSON 索引返回的区间直接加上正文起点，不能保证定位到原文。中文的 UTF-8 字节长度与 Unicode 字符数也不是一回事。

TraceWise 的源码映射 profile 明确区分原文区间与 payload.text 区间；已有正文语义检索则使用自己的 canonical-JSON 表示。不同 profile 的索引代次不能混用。回溯时先核对来源哈希、revision 和表示标识，再把区间转换到对应层；只有证明转换关系成立，才能谈高亮是否准确。

因此，引用验收需要检查到具体区间。一个页面可以打开正确文件，同时把错误的几行标为依据。真正有用的检查，是返回文本与固定来源的对应区间一致，且当前引用仍然有效。

抽取任务还需要自己的粒度

如果目标是从长文档中抽取实体与关系，单元大小还影响一次模型调用要处理多少内容，以及失败后重做多少工作。这与“用什么片段做向量召回”是两个不同的问题。

TraceWise 在 9 月 11 日采用抽取专用的结构与 token 预算切分。源码限制每个新单元不超过 1200 个 cl100k_base token，保留完整原文区间；这个计数用于约束输入规模，不等于所用模型的真实计费 token。结构解析尽量尊重块和主题边界，超长块仍需进一步拆分。

实际迁移记录保留了 55 个已成功的旧单元，将剩余部分重分为 459 个新单元，总计 514 个。这是一条具体任务的迁移记录，不能和另一份 27 文件离线切分审计混用。它说明变更可以作用于未完成尾部，而不用抹掉已经完成的检查点；该时点的记录仍显示任务进行中，不代表完整抽取已验收。

保留成功结果也有条件。如果源文档、抽取目标或关键提示发生变化，旧结果可能不再适用；不能因为重跑昂贵就继续沿用。适合复用的是输入身份与处理语义仍然有效的部分。对应回归检查了原文覆盖、偏移和旧单元身份，不是对所有语义变化自动判断可复用。

小块减少重做范围，也可能丢失上下文

块变小并不必然让结果更好。一个关系的主体可能在上一节才出现，适用条件可能在下一段；抽取或检索若只看局部短句，就可能漏掉限定。

Anthropic 在 2024 年介绍 Contextual Retrieval 时，用缺少公司和时间信息的财务片段说明局部文本丢失上下文的问题，并在索引前为片段补充解释性背景。这是厂商提出并评估的一种检索方法，不能直接证明 TraceWise 的抽取切分更优。Introducing Contextual Retrieval

这项对照提示我，选粒度时应同时问两个问题：失败后重做多少，成功时还保留了多少解释条件。对很短、上下文紧密的资料，整篇处理可能比多次切分更简单；对长资料，可以考虑补充来源标题或必要邻近上下文，但补充内容仍需保持来源身份，不能被当作新的原文证据。

若要判断新切分是否值得采用，我会固定原文、模型与输出要求，比较关系完整性、引用定位、跨块遗漏和失败后的重做量，并把调用开销一起计算。这是建议的对照方法，目前没有独立结果支持“1200 是最佳块长”。

调整之前，先说明要重建什么

下表是结合项目经验整理的变更检查方法。粒度可以不同，但每次调整都需要知道哪些结果会受影响。

切分策略和权威生命周期分别由谁负责

哪些资料进入产品、实体和关系怎样定义、哪些章节值得保留、怎样组合召回，属于 TraceWise 的业务选择。Markdown 的领域处理也留在产品侧；采用 Foundation 并不意味着由基础平台决定产品该怎样读一份资料。

对于明确登记并通过其治理流程写入的对象，Foundation 负责对应 Evidence 的版本、撤销、有效性和权威校验，以及已经启用的 Graph Proposal 提案、审核与执行约束。产品提供业务授权与审核人选择，平台按公开契约校验。这个范围必须逐对象判断，不能扩展为所有产品数据都已经被平台接管。

因此，后续若要调整索引切片，优先改变可重建的检索表示，保留来源和治理身份；若要改变 Evidence 登记粒度，则把它作为迁移决定，检查依赖与引用如何继承。两种变化的风险不同，不应被笼统的“重新切块”操作掩盖。

好的切分设计不只是找到一个合适的长度，而是让系统知道：正在改变的是哪一层，哪些身份应保持稳定，以及用户最终能回到哪段原文。