同一份银行业务手册，让智能体重复提取合规义务，四次得出四组不同的结果。直觉上，人们会先怪大模型的随机采样。CTGT在10月21日公布的Concordance案例恰好给这个直觉泼了冷水：研究团队比对了74次重复出现的相同模型请求，回答始终一致；变的是上传文件标识、路由列表顺序以及任务进行中扩张的主题注册表。稳定标识、固定排序并隔离测试环境后，连续五次运行均提取出34项相同的义务。[1]
插图仅示意差异定位方法，图中“合同文件”等文字不是CTGT研究所用银行手册的真实界面或数据。
这个案例并不证明模型从此“确定”了，也不表示每个智能体偏差都出在编排层。它说明一件更实用的事：遇到任务结果漂移，要先判断究竟哪一层输入或状态变了。只看最终答案，连该不该换模型都无从判断。
先把“同一个任务”拆开
银行手册没有换、用户指令没有换，不等于模型收到的请求相同。一个文件抽取工作流至少会经历上传文件、生成或传递标识、选择页面或片段、登记主题、组装上下文、调用模型、合并义务、去重和输出。列表顺序变化会影响送入上下文的内容顺序；主题注册表中途扩张，则可能让本次运行后半段用上一套与前半段不同的分类状态。上述路径是根据CTGT披露的故障来源给出的工程解释，并非对其内部实现细节的复原。[1]
因而至少要区分三个问题。第一，原始资料是否一致：版本、页数、解析后的正文有没有变化。第二，送给模型的实际请求是否一致：系统指令、引用片段、工具反馈、上下文排列和参数是否相同。第三，模型返回之后的处理是否一致：同义项如何合并、重复项怎样判断、最终清单如何排序。如果只记录“用户上传了同一个文件”，第二和第三个问题都回答不了。
CTGT公开了测试协议、参考实现和实验数据，采用Apache 2.0许可。[1] 对企业团队来说，最值得借用的是对照实验的方法，而不是把案例里的34项义务当成自己的业务标准答案。它针对一份九页银行业务手册和一个具体应用；不同文档、检索器、工具链和模型配置会给出不同的故障分布。复现报告要描述自己的环境和数据，不要从这一个样本推算行业平均错误率。
那74次一致，到底能证明什么
“74次相同请求得到相同回答”的观察，缩小了该案例中模型输出波动的嫌疑，却没把整条流水线变成数学上的纯函数。这里的相同，是研究团队所比对的那些请求相同；不能把它偷换成“四次任务里所有模型调用完全一样”，也不能据此说模型在任意温度、任意硬件或任意服务版本下都必然稳定。[1]
恰恰是请求层的这种局部一致，才让排查有方向。如果A运行的最终清单多了两项，B运行少了两项，先比较两次任务中实际发送的请求序列：调用次数有没有变？相同编号的调用有没有取到同一个手册片段？主题名的出现顺序是否一致？在确认模型入参一致后，再去比较响应文本与后处理结果。这比先把采样温度改成零、又重新运行一遍更接近根因。
一个常见误区是“温度设为零，任务就可复现”。即使暂不讨论推理后端的差异，温度也管不到上传时产生的随机标识，管不到并发任务共用的注册表，更管不到工具返回列表未排序的问题。把所有非确定性都塞进模型参数，会让产品团队反复调推理配置，真正有问题的状态管理却原封不动。
给流水线一份可比较的账本
实际验收不一定需要一上来保存所有原始文件或敏感文本。可以先为每次任务生成一次运行标识，把文档版本、解析器版本、检索索引版本、提示模板版本、模型版本和工具版本关联起来。关键步骤留下有序事件：文件入库、片段命中、上下文组装、调用模型、合并义务、人工确认。对于合规手册，日志权限与保留期要跟着资料敏感程度走；“为了调试”不构成无限期复制业务材料的理由。
最有价值的比较对象是实际模型请求，不是开发人员以为已经发送的模板。模板一样，填入的检索片段、排序和注册表状态可能已经不同。若组织允许保存全文，应限制访问并避免把机密材料散落在普通日志里；若只能保存指纹，也要留有受控重放渠道，否则发现哈希不同却永远看不到差异所在。完整请求的审计和隐私保护并不矛盾，难点在于谁有权读取、保存多久，以及出现事故时能否重建。
接下来做差异定位：逐次对齐两条运行轨迹，找到第一处不一致。若第一处就在文件标识生成，观察标识是否进入了检索键、缓存键或提示内容；若发生在路由列表，检查排序规则、并发写入和依赖的默认顺序；若注册表变了，检查它是每次任务独立创建，还是被多个任务共享。这些都是根据披露故障点设计的排查问题，不表示CTGT曾公布相同的代码结构。[1]
并发环境尤其要谨慎。“我本机重跑五次都一样”只能说明该配置下五次一样，无法代替多租户并发验收。设计测试时，可以先用固定资料、固定版本做串行重复，再加入不同用户同时上传和不同任务交错执行，观察清单及中间轨迹。隔离任务状态不是为了做漂亮的演示，而是防止一个任务登记的主题污染另一个任务的判断。预期输出该如何定义，需要业务人员先确定可接受的同义项和漏项边界。
结果一致，也可能一致地错
五次都抽出34项，说明该条件下重复性改善，不等于34项必然完整、准确、符合法规解释。企业需要把“重复运行是否一致”和“答案是否正确”分开验收。前者比对同一任务的多次轨迹，后者要有专家核定的义务清单，检查漏提、错提、引用错页和需要人工判断的条目。把两个指标合并成一个“准确率”，问题一出现就很难定位。
设想一份手册有跨页的例外条款。每次都截掉后一页，模型可能稳定地产生同一个错误答案；这是确定的截断，不是好的系统。相反，两个答案用词不同，但都准确引用同一义务，不该简单判成业务失败。比较规则应先定义规范化方式和引用依据，再看条目级差异。如果业务要求记录审计链，最好让每项义务可追到手册位置和经手的处理步骤，而非只给一份没有出处的漂亮清单。
成本也需要算进来。存储受控运行轨迹、构建对照集、给关键步骤加版本号，都有工程代价。相比反复更换基础模型，这些工作往往更便宜，也更能解释到底是哪一处改动导致回归。但“更便宜”是基于操作路径的判断，不是CTGT实验披露的成本测量。团队可先选一个高频且容易核对的流程做小样本试验，统计重复运行差异率、定位一次差异所需时间，以及误报率，再决定是否推广。
试点预算可以按任务核算，而不是笼统买一套“可观测平台”。先估算每天多少次抽取，每次调用多少模型请求，完整轨迹占用多少存储，人工复核一条差异需要多久。若业务一天只处理少量材料，简单的版本记录加人工抽样可能就够；若每天大量并发，手工对日志会迅速失效。投入自动差异定位前，应算清当前一次异常导致多少重做工时，以及漏提义务造成的实际处置成本。没有这些基线，再精致的调试图也无法回答投入是否值得。
测试集也要避免只挑容易抽取的条款。可从历史材料选含附录、跨页引用、重复措辞和修订标记的样本，事先由熟悉业务的人标出必须出现的义务及证据位置。重复测试时固定这个集合，另设一组新文档观察泛化。测试集自身若不断被人工修改，却没有版本记录，团队会把标准答案的变化误判成系统退化。合规场景还需要处理个人信息：建立脱敏副本或在受控环境测试，不能把生产文档任意复制给外部调试服务。
差异定位工具应该让工程师看见有意义的变化，而非只吐出一大段文本diff。例如检索结果换了一段、顺序从甲乙丙变成乙甲丙、某个主题在运行中由十个变为十一个。若两个阶段都变了，就以最早出现的变更作为排查起点，再追后续连锁反应。注意“最早变化”仍是线索而非因果证明：某个无关ID变了，但真正导致清单变化的可能是下一步的检索缓存。需要用固定该变量的对照运行验证，不能凭时间先后就宣布修复完成。
上线前怎么签收
可以给一个合规抽取应用约定最小验收：同一输入和同一版本配置重复运行，记录每次最终清单与各阶段差异；任何差异都能追到首次变化的步骤；重要条目能反查证据位置；跨任务执行不会共享可变分类状态。后两项属于本文提出的工程验收建议，不是Concordance公布的产品功能保证。[1]
版本变化时别追求机械的一字不差。手册换版、模型升级或人工审核规则调整，输出理应可能变化。此时应把变更作为新的实验条件，以旧版结果作基线，解释哪些差异来自输入更新，哪些是意外回归。一个有用的流程不必承诺“永远不变”，必须能讲清楚“为什么变”。
真正棘手的是判定哪些变化值得报警。对一份合规清单来说，序号变了而条款证据没有变，通常只影响呈现；义务主体从银行换成客户，哪怕文字只差几个字，也可能改变业务处置。自动差异工具应把“排版变化”“同义措辞”“新增或遗漏义务”“证据冲突”分层，交由业务审核定义严重程度。这里没有可直接移植的通用阈值：银行手册、客服知识库和财务票据对漏项的容忍程度并不相同。
上线之后，别把每次漂移都交给一位工程师从头读日志。让系统先输出可理解的差异摘要：哪次运行、哪个版本、第一处变化在哪一阶段、受影响的最终条目有哪些。业务人员可以先核对条款，工程师再沿着事件链深入。若尚不能留存足够的中间记录，至少在试点期安排小规模定期复跑；等首次漂移出现时再补日志，已丢失的上下文无法凭最终答案倒推回来。
如果负责人只给一周时间试验，可以这样安排。第一天由业务审核选定少量有标准答案的材料，工程团队冻结解析器、检索索引和提示模板版本；第二天把任务调用链中的文档标识、路由顺序、实际模型请求和合并结果关联到同一运行号。接下来做串行复跑与并发复跑，遇到差异只记录第一处变化，不急着大改架构。最后请业务人员判断差异是否改变义务实质，再算修复前后的定位耗时。这是一套小范围验收建议，不是CTGT报告提供的固定工期，也不保证一周内能解决所有问题。
具体整改仍要看根因。若随机文件标识只用于日志，没必要为了“看起来一样”硬编码标识；若它影响缓存命中或输入顺序，就应修正用途。若列表顺序具有业务意义，直接排序可能掩盖优先级，此时要明确优先级规则而非按字母表粗暴固定。若共享注册表是出于性能考虑，隔离状态后还得验证吞吐和资源消耗。为了可复现而误伤业务语义，得到的不过是稳定的错误。
CTGT的案例给出的判断很具体：在这份手册的抽取任务中，74次相同模型请求没有出现响应分歧，真正需要修的是文件标识、排序和任务状态。下次智能体结果不一致，先保存实际调用轨迹、比较第一处分歧，再决定是否碰模型。把“模型随机”当万能解释，最容易错过能自己修掉的工程故障。
资料来源
[1] CTGT研究原文，《Deterministic Inference Did Not Make Our Pipeline Deterministic》，2026-10-21；2026-10-22《AI技术每日分析》第二节及参考资料[3]所引。https://www.ctgt.ai/research/concordance