先判断任务停在哪个阶段
AI工具很快给出答案，但关键资料没有出现在结果中。先不要急着把现象归结为线路、设备或客户端。查询理解、向量检索、排序、上下文组装和模型生成分别消耗时间并改变答案范围，任何一段发生变化，都可能让最后结果看起来相似。
理解语义检索的重点，是让观察条件足够清楚，使同一个人隔天复查时仍能看懂当时发生了什么。接下来要比较的是过程，而不只是最后出现的一个数字或提示。
把任务拆成阶段
准备、发起、首段响应、连续交互、完成与恢复对应不同观察点。围绕语义检索逐段记录，比反复刷新后只写成功或失败更有解释力。
给结论加上范围
响应时间无法证明事实正确，较多结果也不代表每项都相关。因此，结论应写明设备、任务、地点和时段，不把一次现场观察扩大成所有人、所有资源或全天都成立的规则。
缓存既能加快也会误导
缓存减少重复下载，却可能让一台设备停留在旧版本。判断语义检索时，要区分页面显示时间、服务端更新时间和本地文件修改时间。
从分布而非单点读数据
最小值、平均值和较慢样本各自回答不同问题。生成速度与召回完整度若只留下一个数字，使用者会看不见波动和极端事件。
记录停止测试的理由
测试并非越久越好。确认问题已经定位、条件开始变化或继续操作可能覆盖资料时，应停止并写下原因，避免产生更多互相冲突的记录。
把观察转成下一项动作
好的结论会明确下一次做什么，而不是只说情况复杂。分别记录检索来源、首段等待、引用覆盖与需要人工核对的结论，并在执行前保存当前状态，结果才可以和之前的记录直接比较。
答案出现快不代表资料找得全
语义检索通常先理解查询，再寻找候选资料、排序、组装上下文，最后交给模型生成。首段文字很快出现，只说明前几步在当时给出了可用输入；它不能证明重要来源没有被遗漏，也不能证明生成内容事实正确。
召回与排序承担不同责任
召回阶段决定哪些资料有机会进入候选，排序阶段决定哪些内容优先进入有限上下文。候选过窄会漏掉关键资料，候选过宽则可能带入噪声。评估时应查看引用覆盖和来源相关性，而不只记录总耗时。
查询写法会改变检索范围
同一个问题加入时间、地区、产品版本或文件类型后，检索结果可能完全不同。模糊查询适合探索，精确查询适合核对。若答案缺少关键资料，可以先修改约束，而不是连续要求模型用同一输入重答。
上下文长度会迫使系统取舍
候选资料超过可用上下文时，系统需要截断、摘要或减少来源。更长输入不一定带来更完整答案，反而可能稀释核心证据。重要任务应明确列出必须覆盖的来源，并检查它们是否实际进入回答。
生成流畅度不是证据等级
模型能够把不完整信息组织成连贯文字，因此语言自然不能替代来源核对。涉及版本、价格、服务状态或安全设置时，应回到发布者页面确认适用日期和对象。没有来源的结论只能作为待验证线索。
引用存在也要检查是否支持结论
回答列出链接，并不代表链接中的原文支持每一句推断。核对时应打开来源，确认发布者、日期、适用版本和原文范围。来源只说明一般机制时，不能被扩大成某个服务当前状态；来源已经过期时，也不能替代最新公告。
相同问题需要稳定的评估样本
比较两次语义检索时，应保持查询、资料库版本和筛选条件一致。若资料库在两次测试之间更新，召回差异可能来自内容变化。评估可以预先准备若干已知答案与必须出现的来源，再分别记录是否召回、排序位置和生成引用是否准确。
人工复核应集中在高风险结论
并非每个句子都需要同等强度核对。涉及账号安全、下载安装、价格、法律要求和服务可用性的内容，应优先回到一手来源；一般写作建议可以作为辅助。把时间投入到后果更大的判断，比只追求更快生成更有实际价值。
速度与覆盖应分别下结论
分别记录检索来源、首段等待、引用覆盖与需要人工核对的结论。若结果仍然矛盾，先保存现场信息，再到连接检查核对测量方法，或从全平台说明检查系统差异。操作过程需要进一步说明时，可继续查看使用帮助。