这篇重点学什么
本篇重点：沿一次请求的完整记录（trace）和各步骤记录（span）查找失败位置与耗时，再结合指标排查线上问题。
开始读正文 ↓学过相近内容？查看哪些可以跳过
两条路线有些基础相同。已经学会的部分可以跳过，另一条路线只用来补你当前需要的内容。
失败定位与归因
共同基础保留完整的输入、执行步骤和结果；同时发生的变化，不一定就是导致失败的原因。
另一条路线补充什么？
逐步删减仍能触发同一失败的输入，固定其他条件后替换一个环节（反事实实验），检查结果是否变化，以及是否还有其他因素同时影响结果。
读完这篇，你能做什么
能运行固定评测集比较版本，提交分项结果、失败轨迹和有证据的改进结论。
学习理由、准备要求与知识点
为什么学它
评测告诉我们任务是否做成，过程记录帮助找到失败在哪一步，两者结合才能改进整条执行流程。
先读这些内容
知识点清单
- 结果和过程分别评估
- Schema 权限预算检查
- 引用支持与人工核对
- 模型裁判局限
- 运行和 trace 标识
- 提示版本与工具状态
- 脱敏和采集范围
- 失败轨迹回归
运行前先确认完整算法使用 Java 17 标准库；JDK 源码基线为 OpenJDK 17 GA。示例是内存中的机制模型，外部服务接入需要另外配置和验证。
01先弄懂它是什么
只看到最终答案，往往不知道错误出在哪里。可观测性就是留下足够的过程证据：收到什么输入、找了哪些资料、调用了哪些工具、在哪一步失败、花了多少时间和用量。即使最后答对，也可能在中间重复请求、无效循环或尝试了不允许的操作，因此结果和过程都需要检查。
一次任务先分配稳定的运行 ID，再把模型调用、检索、工具执行分别记录成 span，也就是一个操作的起止时间、状态和关联信息。多个有关联的 span 组成 trace，用来回看整条流程；指标汇总成功率和延迟，日志记录具体事件。三类记录用受控标识连接起来，不应默认把原始提示和凭据全部写进监测数据。
评测回答“做得对不对”，运行记录帮助追查“为什么会这样”。一条失败用例最好能找到当时的配置、数据版本和关键步骤。可以记录检索到的文档编号、工具参数摘要及状态变化，但只收集确有需要的内容，并规定保存多久。即使保留了这些记录，带随机性的模型重跑时也未必逐字给出相同回答。
文中这几个词，先认一认
- span
- 一项操作从开始到结束的记录，带有时间、状态和其他属性，通常属于一条 trace。
- trace
- 把同一次请求中相关操作串起来的记录，方便看清它经过了哪些步骤。
- 基数
- 某个标签可能有多少种不同取值。例如把每次请求的唯一 ID 都作为指标标签，会产生很多取值并增加存储成本。
02看看它怎么工作
并发操作的耗时不能直接相加当作用户等待。两个工具区间分别为一到五、三到七，相加为八，但至少一个工具正在运行的时间并集长度是六；请求从零到十的总延迟又是十，剩余部分可能包含排队、推理或其他阶段。
本题要计算的是：在选中的这些 span 里，至少有一项操作正在运行的时间有多长。先按开始时间排序，再把重叠的时段接起来：下一段已经开始、当前段还没结束，就把右边界延长；两段之间有空档，才结算上一段。父操作的时间段若包住子操作，这样合并也不会把重叠部分算两遍。前提是这些时间能放在同一条时间轴上比较，结果只是它们共同覆盖的时长。
覆盖时长不等于 CPU 真正在计算的时间，也不能告诉你哪条依赖路线决定了任务结束，更不能单凭它证明故障原因。不同机器的时钟若有偏差，直接比较时间戳也会错。真实链路还要把同一次请求的关联信息正确传下去，用单调时钟测量本机耗时，并设计跨机时钟同步。若部分 span 丢失或没有被采样记录，算出的覆盖时长可能偏小，所以报告必须说明实际采集了哪些操作。
正在加载流程图…
查看流程图源码（Mermaid）
flowchart TD
R["任务运行ID"] --> T["模型 检索 工具span"]
T --> M["指标聚合"]
T --> L["受控日志与链路"]
L --> D["慢点与失败诊断"]
D --> E["回归评测案例"]按顺序看，每一步做了什么
- 建立运行ID、trace与span的关联规范。
- 给检索、模型、工具和恢复步骤记录有限属性。
- 用指标观察总体分布，用链路解释具体慢请求。
- 区分并发重叠、排队等待和真正关键路径。
- 把可复现失败整理为评测案例，并检查脱敏和保留策略。
03对照实现代码
OpenJDK 17 GA，jdk-17+35 · Arrays.sort(T[], Comparator)
下方为原创 Java 教学片段，调用已核验的 JDK API 说明局部机制；不是该类原样源码，也不实现神经网络。完整程序见算法模块。
Span[] ordered = spans.clone(); // 复制引用数组，保留调用者原有顺序。
Arrays.sort(ordered, Comparator.comparingLong(Span::start)); // 用比较器避免时间相减溢出。
for (Span span : ordered) { consumeInterval(span); } // 排序只提供顺序，合并逻辑由应用负责。Arrays.sort的对象数组重载接受比较器，在JDK17实现中使用稳定对象排序路径。稳定性可以保留相同键的相对顺序，但本题正确性不依赖相同起点的先后。
比较器应使用comparingLong而不是强转时间差。两个合法long时间相减后截成int会破坏顺序，使区间合并产生错误。
clone仅复制数组，不复制span对象；因此算法使用不可变record保存起止时间，避免排序过程中外部修改时间破坏前提。
源码桥梁只验证Java侧排序机制。OpenTelemetry负责遥测数据模型与传播，排序API不会自动创建链路、校准时钟或识别模型调用。
代码先调用谁，再调用谁
- 采集同一坐标系的区间
- 校验并复制数组
Arrays.sort按起点排序- 线性合并重叠区间
- 输出覆盖时间并说明范围
04动手写一个例子
并发span的时间并集
输入非负long起止时刻组成的半开区间，输出至少一个操作运行的时间总长。拒绝结束早于开始；输入数组不改动。Java17完整自测。
- 输入 1
[1,5),[3,7)- 输出 1
6
- 输入 2
[0,10),[2,3)- 输出 2
10
排序后所有未处理区间的起点都不早于已处理区间。维护当前合并段的最早起点与最远终点，遇到重叠只扩大终点，不提前累计重复部分。
遇到严格分离的起点时，后面不可能再与当前段相交，可以安全结算长度。相接区间也允许合并，因为端点本身没有时间长度。
最后补上未结算的当前段，空集合返回零。非负时间保证每段减法安全，使用精确加法检查使代码对今后输入范围扩展也不会静默溢出。
为什么这样写是对的total只包含已经关闭且互不重叠的段；当前段等于所有已处理但尚未结算区间的连续并集。
复制和对象排序需要线性额外空间，合并扫描线性时间；时间为固定宽度long，不计算实际span采集开销。
保存为 Main.java，运行 javac --release 17 -encoding UTF-8 Main.java，再运行 java Main。程序包含固定输入自测，断言失败时会抛出错误。
import java.util.*;
public class Main {
record Span(long start,long end){}
static long union(Span[] spans){
for(Span s:spans)if(s==null||s.start()<0||s.end()<s.start())throw new IllegalArgumentException("interval");
if(spans.length==0)return 0;Span[] a=spans.clone();
Arrays.sort(a,Comparator.comparingLong(Span::start)); // 只排列副本，保留原输入。
long left=a[0].start(),right=a[0].end(),total=0;
for(int i=1;i<a.length;i++){
if(a[i].start()<=right)right=Math.max(right,a[i].end()); // 重叠部分只扩边界，不重复累加。
else{total=Math.addExact(total,right-left);left=a[i].start();right=a[i].end();} // 分离后关闭上一段。
}
return Math.addExact(total,right-left);
}
static void eq(long expected,long actual){if(expected!=actual)throw new AssertionError(actual);}
public static void main(String[] args){
eq(6,union(new Span[]{new Span(3,7),new Span(1,5)}));
eq(10,union(new Span[]{new Span(0,10),new Span(2,3)}));
eq(4,union(new Span[]{new Span(1,3),new Span(5,7)}));
eq(4,union(new Span[]{new Span(1,3),new Span(3,5)}));
eq(0,union(new Span[]{}));eq(0,union(new Span[]{new Span(8,8)}));
eq(Long.MAX_VALUE,union(new Span[]{new Span(0,Long.MAX_VALUE)}));
try{union(new Span[]{new Span(2,1)});throw new AssertionError();}catch(IllegalArgumentException expected){}
System.out.println("PASS 8 tests");
}
}这些特殊情况也要试一试
- 空集合与零长度区间都贡献零。
- 区间必须使用相同单位和可比较时间基准。
- 嵌套span不能简单相加当作端到端延迟。
进阶选读 · 后续再读：大规模在线时间覆盖
场景大量span持续到达，需要实时查询某窗口的覆盖长度。
做法离线可采用端点扫描；在线可用坐标压缩后的线段树维护覆盖计数和覆盖长度，动态坐标需要不同结构或分段窗口。
复杂度固定压缩坐标下每次区间增删O(log M)，空间O(M)，窗口过期还需管理事件生命周期。
好处与代价更多索引提高查询能力，但不修复时钟误差、采样缺失与错误父子关系。
05项目里怎么用
指标标签适合用来分成数量有限的几组，例如“查询工具或写入工具”“成功或失败”“哪个版本组”。以 Prometheus 这类系统为例，每种标签组合都会增加一条时间序列；把每个用户 ID、运行 ID 或完整问题都作为标签，分组就会不断膨胀，增加内存和存储开销。某次请求的细节应放进有访问限制的日志或链路记录（trace），再按用途决定抽样比例和保留期限，减少敏感信息暴露和长期积累。
不要把所有失败都归为一个“调用出错”。网络超时是没有及时收到回复，Schema 失败是返回数据的形状或类型不合要求，权限拒绝是当前身份不允许操作，业务未完成则可能是请求都成功了、目标仍没达到。例如查询工具返回了数据，但最终答复没有解决问题，要同时保留各 span 的局部状态和整项任务的结果，不能用一次工具成功盖住整项失败。
看速度时，分别观察第一个输出出现的时间、全部完成的时间和失败请求；排队等待也要与实际处理分开。拿不到用量数据就写“未知”，不要填成 0。再抽查几条从输入到结束的完整记录，确认能顺着找到问题，并把真实失败整理成以后反复检查的用例。
容易踩的坑
- 把所有span耗时相加当成用户等待。
- 将提示词、凭据和个人数据原样记录。
- 用运行ID作指标标签造成高基数。
- 缺失span或用量直接按零处理。
几种做法，怎么选
表格有四列，窄屏可左右滑动查看代价和适用条件。
| 方案 | 优势 | 代价与限制 | 适用条件 |
|---|---|---|---|
| 指标聚合 | 适合趋势与告警 | 缺少单次执行细节 | 总体健康观察 |
| 链路采样 | 能解释调用关系和慢点 | 采样可能遗漏稀有问题 | 请求诊断 |
| 完整受控评测轨迹 | 可复查确定用例的每步行为 | 存储与脱敏成本较高 | 离线回归与高风险审计 |
06检验是否读懂了
先自己想、自己写，再展开答案核对。场景题是假设的练习情境；遇到还没学过的内容，可以做完基础后再回来。
先用自己的话解释
01trace与指标有何区别？
展开参考答案与推导
trace关联一次请求的操作，指标聚合很多请求的分布；两者互补，不能用一条成功链路证明整体健康。
02区间并集为何不是关键路径？
展开参考答案与推导
它只统计选定操作覆盖了多少时间，没有使用依赖边、排队和因果关系。
03未知用量为何不能写零？
展开参考答案与推导
零表示确认没有消耗，未知表示缺少证据，混合会系统性低估成本。
换个情况，还会处理吗
01两工具各四秒，总请求六秒，异常吗？
展开参考答案与推导
未必，可能重叠两秒；查看起止区间和依赖，不应直接判定计时错误。
02日志很多仍无法定位失败，缺什么？
展开参考答案与推导
可能缺稳定关联ID、版本和结构化步骤状态，应先构建可串联的一次执行轨迹。
03线上图表正常但用户抱怨失败，查什么？
展开参考答案与推导
检查失败是否被排除分母、采样是否偏向成功、业务失败是否仍返回技术成功状态。
写代码试一试
01嵌套区间怎样算？
- 输入 / 条件
[0,10),[2,3)- 输出 / 预期
10
提示 用并集。
展开参考答案与推导
父区间已覆盖子区间，右边界保持十，不能增加一。
02相接区间会双计端点吗？
- 输入 / 条件
[1,3),[3,5)- 输出 / 预期
4
提示 半开区间。
展开参考答案与推导
端点没有长度，合并后区间一到五长度四，与分别相加相同。
03为什么复制数组？
- 输入 / 条件
原顺序用于后续展示- 输出 / 预期
原输入顺序保留
提示 clone后排序。
展开参考答案与推导
排序会改变数组位置；复制引用并使用不可变span避免影响调用者和时间键。
商户项目 · 本篇加练
先跑十道固定题，再看哪里失败
核查日期：2026-10-11。状态：新增教学练习未运行。
目标与前置知识
用固定问题和逐题记录判断商户 Agent 做了什么，避免只评最后一句话。
前置：工具、FAQ 与权限边界已写清；能读取一次运行的事件及工具结果。
按顺序完成
-
固定十题：基础查询、自取 FAQ、工具与 FAQ 组合、停车资料不足、不存在商户、工具异常、越权、缺少商户标识需澄清、检索片段提示注入、今日工具与旧资料冲突。第 4 题另用空检索和无关检索重复，第 7 题另用 A/B 互换身份重复。它们仍是十个题型，变体要单独记录。
-
每题分别验收三层：工具是否真实执行、检索与实际传入上下文是否正确、最终回答是否受证据支持。无需检索可把检索项记为不适用，但仍须确认本轮工具结果或失败结果真正进入生成回答的模型调用；成功工具事件不能代替上下文证据。有要求但证据不全则标记未能验收，不要填通过。先检查越权和捏造成功等硬失败，再报告其他分项，不以平均分覆盖安全失败。
-
逐题记录题号、运行 ID、身份、应用/依赖/数据/提示/模型版本、预期、实际调用及状态、检索片段、实际上下文、回答、断言、人工复核、失败分类、耗时、模型调用次数、可取得的用量和费用依据。未运行或拿不到的数据留 null/空白；不能填 0。实测的 0 次调用需要完整事件覆盖或受控客户端/仓库断言。
-
Spring AI 的工具名单说明本次提供了哪些能力；工具执行观察和应用记录才用于核对实际调用。缺日志可能来自未启用、采样、导出失败或执行路径未覆盖，不等于没有执行。记录观测是否完整，并把模型请求次数与框架自动重试、工具循环次数分开。
-
默认不收集完整提示词、工具参数和检索正文。仅在这个虚构数据实验中显式打开教学留证，保存复核所需片段与上下文；普通业务记录保留必要标识、耗时、状态和可用用量。费用需要计价日期、价格来源与实际用量，未知就留空。模型裁判可辅助相关性判断，不能取代权限、调用结果及逐条证据检查。
验收与交付
- 交付十题 JSON、每次运行记录、三层结果及逐项结论→证据映射
- 越权泄漏和捏造工具成功直接失败，证据不足则不能验收；分母、变体和未运行数量清楚
- 没有运行时保留空白模板和未运行标记，不给分数、耗时、性能或成本
十题与记录模板尚未运行；原文的二十例综合练习保留，十题只作为商户项目的入门固定集。
原始来源
商户项目 · 延伸练习 · 未运行
跨线程日志关联与退出后的上下文恢复
先完成本页固定题目的事件记录，以及异步任务的身份与检索范围。适用阶段：商户查询已使用异步执行器或 Agent 工具，需要定位日志关联缺失或串线。先区分请求、线程、trace 与 span，固定项目依赖、执行器和客户端配置；日志标识不能替代授权身份。
资料原核查：2026 年 10 月 20 日 00:04–00:05 JST；同日复核 Spring Boot Tracing、Observability的相关段落，页面仍标 4.1.1，未标独立发布日期。Logback MDC手册没有标明单独发行版本或发布日期。以下执行器、追踪与清理练习均未运行，不要求升级项目依赖。
分别检查日志字段、线程上下文和网络传播
使用 Micrometer Tracing 时，Boot 默认以 MDC 的 traceId/spanId 关联日志，依赖正确的上下文传播。该版本文档说明，自动配置 AsyncTaskExecutor 用于 @Async 时，要通过 spring.task.execution.propagate-context 选择启用传播；自定义执行器需核对其配置要求，不能推断任意线程池已自动适用。跨 HTTP 客户端自动传播还依赖自动配置的客户端 builder。
Logback 的 MDC 按线程管理，子线程不自动继承父线程副本。手册建议线程池场景在提交前取副本、任务执行时设置，put/remove 配对并在 finally 清理以覆盖异常。本节的工程推演是：手工处理嵌套作用域时应恢复进入前的上下文，避免清空外层原有内容；用框架传播时验证其作用域行为，不叠加未经核实的全量手工复制。复制 MDC 字符串不能单独证明完整追踪上下文已传播。
已有异步身份章节验授权与数据范围；本节另外验诊断关联。日志中出现 ID、执行线程内上下文正确、下游网络链路连续是三项不同证据，不能互相代替。
建议练习：让同一线程处理不同请求
- 关联缺失与误串分别验收。 固定一个工作线程，顺序执行虚构请求 A、B，记录提交、执行中和退出后的关联值。A 正常完成、抛异常各做一遍，再运行 B 与无请求上下文的控制任务。A 执行中属于 A，B 属于 B，控制任务不残留 A/B；退出后恢复原上下文。保留未配置传播的对照，不以同线程名断言同请求，也不要求父子 spanId 相同。
- 沿边界定位。 沿“入口 → 异步商户查询 → 下游 HTTP”逐段检查执行器传播配置、实际客户端 builder、日志关联及下游接收的追踪上下文；对照自动配置 builder 与未接入自动传播的客户端，找出断开位置。先确认采样和测试配置：该 Boot 文档默认采样 10%，
@SpringBootTest不自动配置上报数据的追踪组件。后台无记录不能单独证明商户查询没有执行。
交付依赖版本、执行器和客户端构建方式、正常/异常路径、作用域进入/退出状态、采样配置和观察位置。使用合成关联值，不把令牌、完整请求参数或检索正文放入 MDC。
限制：没有运行 Java 程序、搭建追踪后台或修改项目配置，实际传播和清理仍需按项目锁定版本验证。缺观测不等于零调用；请求 ID、trace ID、线程名也不赋予商户访问权限。
读完之后，独立完成
课后作业：自己做一遍
本篇共 12 道作业，先完成 9 道基础与综合任务，再按前置知识挑战进阶题。其中包含 2 道思维拓展，试着换个条件，看看原来的办法是否还管用。不附参考答案。
能运行固定评测集比较版本，提交分项结果、失败轨迹和有证据的改进结论。
本篇重点加练
硬约束检查与失败回归让可靠性改进可验证，需要测试评测链路本身的失效。
- Schema 权限预算检查
- 失败轨迹回归
重点内容会多练几次。先说清楚怎么做，再试试空数据、出错或条件改变时会发生什么。
先自己做，卡住时记下问题，再回来查。问答题写清“为什么、什么时候适用”；动手题留下输入、输出和运行步骤，方便下次重做。
基础必做
- 作业 01原理问答
为一个答对问题却访问越权资料的运行分别设计结果评分与过程评分，列出Schema、权限、预算三类独立验收项。
- 提交内容
- 一份独立书面回答或标注图，包含自造例子、概念边界及判断依据。
- 怎样算完成
- 逐项回应题目要求，区分事实、假设与个人判断。
- 能用自己的例子解释适用条件，记录尚未弄懂的点。
练到的知识点结果和过程分别评估 · Schema 权限预算检查
- 作业 02代码推演
给一段带两处引用的回答制定人工核对表，再设计模型裁判流程；写出分歧如何复审及裁判不能独立证明的事项。
- 提交内容
- 手工推演记录，写明输入约定、中间状态、最终判断；可运行时附程序对照记录。
- 怎样算完成
- 推演包含中间过程，数据形状、单位、顺序或状态前后一致。
- 主动检查至少一个边界或异常条件，能解释手算与运行差异。
练到的知识点引用支持与人工核对 · 模型裁判局限
- 作业 03原理问答
定义一个失败样本可以加入回归测试的标准，分别检查输入要求、权限条件、预算与可复现证据是否齐全。
- 提交内容
- 概念或合同说明、关系图与自造案例，明确事实、假设和适用条件。
- 怎样算完成
- 关键概念有明确边界，能用案例检验声明。
- 未获证据支持的假设单独标注。
练到的知识点Schema 权限预算检查 · 失败轨迹回归
综合应用
- 作业 04面试场景
两次运行文本相同但提示版本、工具响应和耗时不同。制定trace事件模型，说明排障时如何精确定位到各自执行上下文。
- 提交内容
- 场景分析与决策记录，包含信息缺口、约束、备选方案和验证计划。
- 怎样算完成
- 方案回应给定约束，列出至少一种替代方案及代价。
- 每项关键结论说明所需证据，不能核实的部分明确标注。
练到的知识点运行和 trace 标识 · 提示版本与工具状态
- 作业 05编程实践
将一条失败轨迹脱敏后转成固定回归用例；实现假工具回放，检查敏感字段不会进入日志且失败仍能复现。
- 提交内容
- 可复现的最小程序或实验材料、自写测试、环境说明与运行记录；题目允许纸面实验时提交完整案例表。
- 怎样算完成
- 提交物按说明可以重现；测试覆盖正常、边界与失败场景。
- 运行证据与断言能核验声明的行为，注明模拟与真实执行范围。
练到的知识点脱敏和采集范围 · 失败轨迹回归
- 作业 06排错实验
人为删除一段span并重复上报结束事件，检验统计和链路展示的处理；记录缺失、重复与真实耗时之间的区分方法。
- 提交内容
- 最小故障输入、复现步骤、观测记录、定位依据及回归用例。
- 怎样算完成
- 其他人可按记录复现故障，并区分现象与已验证原因。
- 定位过程有观测依据，回归用例可以再次暴露原问题。
练到的知识点结果和过程分别评估 · 运行和 trace 标识 · 脱敏和采集范围
- 作业 07编程实践
为评测器加入三个人为缺陷：忽略权限字段、漏计一个工具调用、跳过Schema失败；用一个独立的小用例集验证这些缺陷能否被识别。
- 提交内容
- 可复现的小程序或题目允许的离线实验、自写测试、输入和运行记录。
- 怎样算完成
- 输入、环境和运行过程可重现，测试覆盖声明的重点条件。
- 验证目标由合同确定，模拟结果不冒充真实服务证据。
练到的知识点Schema 权限预算检查 · 失败轨迹回归
- 作业 08排错实验
某失败轨迹缺少最后一个工具事件，但回放得到成功。记录回放所作的补全假设，设计将不完整轨迹标记为证据不足的检查。
- 提交内容
- 最小故障序列、观测记录、原因核对与可再次触发原问题的测试。
- 怎样算完成
- 故障可以稳定重现，现象与已验证原因分开。
- 观测记录足以判断声明的合同是否被违反。
练到的知识点Schema 权限预算检查 · 失败轨迹回归
- 作业 09面试场景
一次版本升级改善大部分任务，却引入一个权限回归。为报告、发布决策和后续验证分别设计责任与证据要求，不把总分代替约束判定。
- 提交内容
- 场景评审记录，包含约束、备选方案、未决信息和验证计划。
- 怎样算完成
- 方案回应题目约束，取舍能对应到可核验的事实。
- 给出失败或条件变化时的检查方式。
练到的知识点Schema 权限预算检查 · 失败轨迹回归
进阶挑战 · 掌握前置后选做
- 作业 10设计评审
建立发布前评测与线上抽查的分工，明确抽样偏差、人工复审资源和回归集版本，提交一次模拟发布决策记录。
- 提交内容
- 设计评审文档或对照实验报告，包含前置条件、方案取舍、验收证据与尚未验证的范围。
- 怎样算完成
- 比较使用一致条件与事先声明的标准，记录失败与未知结果。
- 说明方案的适用前提、未覆盖风险及后续验证方法。
练到的知识点Schema 权限预算检查 · 模型裁判局限 · 失败轨迹回归
思维拓展
先写出你的猜想，再用例子或实验验证。答案可以不同，但要说清依据、适用情况，以及还有什么没弄懂。
- 作业 11思维拓展 · 反例构造
审查“加入更多历史失败用例后，线上可靠性必然提高”。构造回归集存在偏差或条件失真的具体例子，并给出检验方法。
- 提交内容
- 具体反例、原主张的适用前提、复现或逻辑证明及结论边界。
- 怎样算完成
- 反例满足原主张所声称的前提，确实针对其结论。
- 说明一个反例能推翻什么、不能进一步证明什么。
练到的知识点Schema 权限预算检查 · 失败轨迹回归
- 作业 12思维拓展 · 开放探究
设计评测器自身的可信度实验：选取若干预先植入的缺陷类型，测量漏检与误报，说明哪些未知故障仍不在该实验的证明范围。
- 提交内容
- 可证伪假设、预先声明的比较协议、小规模证据与限制说明。
- 怎样算完成
- 假设存在可被否定的条件，协议在观察结果前声明。
- 包含不支持假设的可能结果及不确定性说明。
练到的知识点Schema 权限预算检查 · 失败轨迹回归
完成后，再检验一次
给每题标记“独立完成 / 查阅后完成 / 尚未完成”。查过资料或没做出的题，记下卡在哪里。隔一天换一组输入再试，能解释结果和出错原因，再把这个知识点标为掌握。
继续阅读
先看能帮你完成当前练习的部分。例子跑通后，再读更深入的解释。
- 必读实践指南英文
Spring AI：Evaluation Testing （新标签页）↗
阅读
EvaluationRequest、相关性与事实评估接口，理解模型评分的输入并配合独立人工标注。 - 实践参考文档英文
Spring AI：Observability （新标签页）↗
查看模型、工具和向量检索的观测字段及默认内容采集策略，按运行标识定位耗时与失败。
- 深入参考文档英文
OpenTelemetry：Traces （新标签页）↗
阅读 trace、span、父子关系和上下文传播，用一条运行轨迹定位模型、工具与数据库步骤。
- 实践实践指南中文
OpenCompass 中文：分数前面还经过了哪些处理 （新标签页）↗
先看“已支持评估指标”和“如何配置”，标出 evaluator、
pred_postprocessor、dataset_postprocessor。自拟三组答案，分别按原样比较和你明写的整理规则比较，记录差异；不要把自拟规则说成框架默认。首轮跳过代码执行评测、外部评分 API 和榜单排名。 正文公开可读，无需登录。阅读和手工练习无需模型；完整框架评测另需安装依赖、数据与可用模型，本轮未运行。 - 深入参考文档英文
OpenJDK 17 Arrays 源码 （新标签页）↗
按指定版本定位
Arrays.sort(T[], Comparator)；对照源码分析理解实际调用边界。