TRACE: Accountable Agentic Retrieval for Source Discovery in Digital Archives

原文：TRACE: Accountable Agentic Retrieval for Source Discovery in Digital Archives。以下依据论文正文第 3–6 节和表 1–3；工业迁移建议为本报告分析，不是作者已经完成的社区搜索实验。

1. 问题与动机

TRACE 处理的是带 OCR 噪声的法国历史档案。问题经常横跨议会辩论与报刊，既要找相关材料，也要保留可检查的来源路径。只看最终回答是否正确，会把模型已有知识和真正找到了证据混在一起；对历史研究者而言，返回哪些文献以及为什么返回，本身就是任务结果。作者因此把评价对象放在文档发现，而非生成答案的流畅度上。

语料有两个特别约束。首先，同一实体在 OCR 文本中的拼写可能受损，纯向量检索和纯词法检索都会遗漏材料。其次，不同子语料规模不均，如果把所有结果共用一个截断上限，较小的报刊集合可能被大量议会材料挤出候选池。正文回放发现，BM25 与稠密检索的 top-20 集合平均 Jaccard 仅 0.19，融合找回的金标文档有 28.8% 只能由其中一路命中；融合召回 78.9%，较好的单路为 70.1%。这直接支持先做互补召回，再让智能体判读证据。

框架沿用问题分解、ReAct 式交替检索与观察、倒数排名融合等成熟机制，贡献在于围绕语料边界、可追溯判断与重新规划组织这些组件。它没有声称提出新的基础模型，也不需要为该语料微调模型。

2. 方法详解

规划器首先用一次 LLM 调用，把原问题拆成有限个子问题。每个子问题记录文本、目标子语料和实体；提示要求覆盖原问题含义、一个子问题只指定一种子语料，并保留实体的原语言表面形式。跨语料问题因此产生多条有明确去向的检索路径。这个目标子语料约束只用于初始候选分配，后续探索仍允许跨库追踪线索。

热启动阶段融合 BM25、稠密向量和日期检索。每一路先按片段打分，再把同一父文档的片段分数取最大值，使长文档不会凭片段数量多次占位；之后用 RRF 合并，常数为 60，即各路名次通过 1/(60+名次) 累加形成排序信号。日期通道仅在子问题包含可解析日期时启用，按时间距离指数衰减。候选截断在目标子语料内部执行，避免大库挤占小库。

接下来进入有预算的智能体循环。可执行动作包括词法、语义、时间和精确子串搜索，以及审阅待处理片段。每次检索后必须审阅，不能连续搜索而不消化返回材料。审阅结果有三类：accept 表示可支持原始问题，记录至多 120 字符的理由，并对父文档去重；reject 只剔除当前片段，保留该文档其他片段的机会；hold 暂存尚无法确认的材料，等后续证据出现再评估。相关性始终对照原始问题，避免子问题过窄导致跨主题证据被提前丢弃。

系统以五个槽位保存先前发现、问题分析、证据、缺口和下一步。每轮覆盖更新这些槽位，而不是不断累积原始对话；同时仅提供最近八条行动日志。模型以单次 JSON 输出返回 thought、action、args、memory_update，应用重新构造全部状态。重复查询、解析失败和空结果不计入有效动作预算，但连续两次相同检索会被强制终止。这一区别在实现时必须保留，否则无效调用可能无限消耗资源。

时间搜索会在指定日期窗口两侧各扩展一天，边缘新增结果自动进入 hold，避免日期边界误差造成永久漏召回。子问题结束后，模型依据已接受证据和紧凑记忆重新审阅暂存项，然后生成包含事实、日期、实体、缺口和检索提示的简报。后续子问题通过简报获得上下文，重规划器可修改或增加未执行任务，但总数受上限约束。

所有路径结束后，同一文档被不同子问题接受的次数成为第一排序依据。系统先按确认次数分组，再仅在组内有多个文档时，利用先前记录的接受理由进行 LLM 重排；单个文档的组直接通过。这里的确认次数是启发式证据，不能当成独立概率，因为不同路径仍由同一规划器和模型产生。

实验使用 DeepSeek-V4-Flash 与 Qwen3-Embedding-8B；另比较 DeepSeek-V3.2。因为不训练，没有可复现的优化器、训练 batch size 或训练步数可填。真正需要固定的是分块、模型版本、提示、动作预算与子问题上限；正文未给出所有预算常数的具体值，复现时应进一步查开源配置，而不是凭空补写。

3. 核心技术贡献

第一，语料定向分解把跨库需求落实到初始候选预算。它不只改写查询，还改变不同数据来源获得召回机会的方式。累积消融中，单独加入分解使整体 R@10 从 0.688 到 0.777，是最大的一步提升，说明结构化任务分配比继续扩大无方向搜索更有价值。

第二，显式接受、拒绝、暂存机制把不确定性保存在状态里。特别是拒绝片段不拒绝整篇文档，适合信息分散在不同位置的长文；暂存项则可以利用后来发现的实体关系重新判断。最终加入 hold 与复审使 R@10 从 0.851 到 0.856，增益较小，不能把它包装成主要效果来源。

第三，系统将证据理由复用于最后排序，既降低重复阅读成本，也保留文档进入结果集的依据。确认次数优先、同次数才调用重排器的设计，使额外模型调用取决于并列组数。论文尚未通过用户研究证明这条审计路径确实提升专家信任，因此应把可追溯结构与已经验证的业务价值区分开。

4. 实验结果分析

数据集含 3,386 篇文档，分成 5,664 个不重叠片段，每段最多 1,000 个空格分隔 token；共 1,752 个问题，其中单跳 889、多跳综合 529、桥接实体 142、对比 192。所有系统共享文档、分块与适用的模型设置。论文的 MRR 对每个金标文档的倒数名次求平均，与只看第一个正确结果的常见定义不同，横向引用时必须说明。

TRACE 相对稠密检索的 R@10 增加 0.122，即 12.2 个百分点；这不是 CTR 的提升。对比类问题中，TRACE 为 0.674，稠密检索为 0.302，表明跨来源组织的价值更集中在复杂查询。图方法没有恢复其在其他基准上的优势：HippoRAG 2 与 LinearRAG 的 top-10 分别平均与稠密检索重叠 7.1 和 6.7 篇，新增命中与丢失大致相抵，说明 OCR 与领域结构会改变图索引的有效性。

累积消融依次为：基础智能体 0.688，加入分解 0.777，加入记忆与重规划 0.801，加入热启动 0.851，加入暂存复审 0.856。对应增量是 8.9、2.4、5.0、0.5 个百分点。这是按固定顺序累加，不是独立组件因果效应；组件相互依赖，不能把四个数字理解为任意顺序都能获得的固定收益。局部结果也并非全部单调，例如最后一项使对比类 R@10 从 0.695 降为 0.674。

模型选择体现精确率和召回率取舍。V3.2 的整体 R@10 为 0.884，接受集合精确率仅 0.238，每题平均接受 10.4 篇；V4-Flash 分别为 0.856、0.393 和 7.0 篇。更高召回意味着研究者要读更多材料，不宜单凭一个指标宣布某模型全面更好。

失误归因进一步显示：82.6% 的漏失发生在智能体循环内，17.4% 是已接受但最终排在十名之外。循环内，被检出后误拒绝占全部漏失的 36.8%，从未检出占 36.5%，暂存后未提升占 9.3%。因此下一步优化应同时关注相关性判断和检索覆盖，而不是只更换 embedding。

比较也有局限：A-RAG 与 MA-RAG 本来不输出文档排名，作者按发现顺序排序进行比较，这对它们不利。论文另报不依赖排序的接受集合精确率和召回率，TRACE 仍领先，但排名协议的不对称不能省略。

5. 局限与未来方向

作者明确列出：测试只覆盖 1887 年法国档案，其他语言、年代和文体尚待验证；提示中部分议会与报刊关系属于特定领域假设；动作预算、子问题数、记忆大小和时间扩展常数在该语料开发时固定，换域可能不适用。规划器偶尔把多跳问题缩为单个子问题，18 个这样的案例有 13 个失败，约 72%，显著高于文中引用的 20% 基准失败率。

部署只是 DECIDON 内部原型，向六个机构的 24 名研究者开放，支持过数百次探索查询，不能等同于生产规模验收。可追溯信息能否降低阅读与核验负担，还没有系统用户实验。作者计划加入专家对分解、暂存和最终证据集的检查点，并扩大延迟、成本和用户工作量评估。

本报告额外提醒：缺少多次随机运行的不确定性报告，也缺少社区短文本、实时更新和点击行为验证。知识密集的历史研究与移动端快速搜帖具有不同的延迟容忍度，结果迁移需要重新建立评价集。

6. 工业实践意义

可先在社区复杂搜索的异步研究入口试用三个设计：按帖子、问答与评论划分初始召回预算；保存逐步接受理由与原文链接；让后续证据触发暂存结果复审。评估应同时覆盖文档召回、nDCG、证据引用正确率和最终任务成功，线上再观察 CTR 与满意度。论文没有在线 A/B 数据，所以不能给出预期点击提升。

成本便宜不代表响应快。全文报告 V4-Flash 在全部问题上消耗 177.6M 输入、39.7M 输出 token，实验时价格约 36 美元，平均每题约 0.02 美元；200 题计时样本平均每题 33.8 次 LLM 调用，模型时间 169 秒，97.8% 的墙钟时间用于等待服务。八题并发后的每题 22 秒是批处理摊销吞吐，不能误称为单个用户请求的响应延迟。

因此社区搜索主链路可只借鉴分库预算、证据状态和紧凑记忆，把完整多步循环放在复杂问题的后台研究任务。对本地部署，作者在 RTX PRO 6000 上的初步测试发现小模型仍存在规划与结构化输出稳定性问题，未报告足够的数据来推算显存或吞吐；工程选型应先跑真实负载。只有在业务需要跨帖证据整合、且能接受多次模型调用时，完整 TRACE 才值得进入试点。