一句“已验证”为什么不够

一个检索函数返回正确片段,不代表引用真的出现在用户收到的回答中;浏览器能看到回答,不代表它来自当前已发布来源;一组请求没有报错,也不意味着延迟达标。项目因此把检索实验、回答验收、运行环境与性能分别记录。1

当前本地集成阅读修订是 c1609dd12523e780149ec7ac546a34509f907757,快照日期 2026-09-08。下文历史公开材料固定在 23fa19712c009cf864782401c449106b3ac9f17f,公开包的运行来源仍是 91753f1c1ff6fc07bc262dfa50fb719a63210e0b。本次未重跑上游检索、真实 Provider、提示注入、持久栈或性能测试。

先冻结比较对象,再比较算法

评测输入固定中文优先的项目派生语料和 16 条查询,分为精确约束、语义改写、组合条件、边界查询四类。语料和查询集各有哈希;三种模式对齐 QA Chunking 500/50、候选深度 20 与模型身份。12

Hybrid RRF 按 chunk_id 去重,用排名而非原始分数融合,k=60。这不是把 dense 分数与词法分数直接平均,也没有在这组实验中追加重排器。

比较条件固定的收益是差异更容易归因;代价是结论只能覆盖这套输入。增加一种更复杂的算法并不会自动增加证据力度,只有它在相同问题上改变了可观察结果,才值得讨论收益与成本。

边界查询不能混进可回答问题的平均值

边界问题对应证据不足、冲突或过时。它们的目的不是要求某条 Gold Evidence 必须被正常回答,而是检查系统是否识别不该回答的情形。因此其诊断单独报告,不进入可回答查询的质量聚合。2

观察回答的问题常见误读
Evidence Recall@k标注证据是否被找回找回了就一定支持最终答案
Context Precision@k前 k 个候选中标注证据的比例非 Gold 候选全部无用
首条 Gold 排名首个标注片段出现多早所有约束已覆盖
Boundary diagnostics不足、冲突、过时如何表现拒绝就是检索失败
检索耗时这次检索的成本整条回答端到端延迟

指标命名本身也是契约。把不同分母、不同边界问题混在一个平均值里,会让统计上更好看的结果失去可解释性。

记录结果没有选出普适冠军

公开记录中,三种模式的 Recall 与 Context Precision 逐项相同。首条 Gold 排名并不全部相同,耗时也不同;因此准确的说法是“这些质量指标持平”,而不是“所有表现完全一致”。2

冻结输入上的三模式检索结果
既有记录的可视化,不是本次重跑:Recall 与 Context Precision 持平,检索耗时不同。

BM25、Dense、Hybrid RRF 的记录检索耗时分别约为 0.44 ms、3816.7 ms、3261.7 ms。它支持在这套冻结输入与运行条件下讨论额外成本,不支持宣称某种模式在任意语料、模型与基础设施上都更优。数值与完整指标表保留在实验验证。2

更不能据此把生产 Migration Retrieval 改名成“经过评测胜出的 BM25”。一个负责迁移可用性,一个负责质量对比,职责不会因表格出现同类关键词而合并。

产品验收必须追到用户出口

既有持久栈记录覆盖认证普通回答、SSE、历史、证据不足、生成不可用且零回退、撤回、成员停用和角色边界。它观察的是用户实际收到什么,而不只是直接检索接口返回了什么。3

测试工具也把失败原因拆开。例如生成 smoke 的源码会核对普通、SSE 与历史的引用;SSE 缺少应有引用时,使用 STREAM_CITATION_MISSING 分类,而不是把“收到了 done”当作回答完整。4

检索候选正确
    != 普通回答有正确来源
    != SSE 已携带该来源
    != 历史仍能按同一规则投影

当前 SSE 的具体实现是完整结果完成后分块发送,见回答投影全文。产品验收包含 SSE,不等于验收过真正的 Provider token 流。

注入观察与性能目标分别保留边界

提示注入记录覆盖四类固定案例:指令覆盖、配置或密钥提取、伪造来源指令、施压无证据作答。公开材料保留归一化身份、通过与否、outcome、引用数量和失败分类,不公开原始私有对话。它是这些案例在记录条件下的观察,不是全面安全保证。5

性能 c1 与 c5 各有 20 个请求且记录零错误,端到端 P95 分别为 15.930 秒和 74.465 秒,12 秒目标均未达成。功能记录通过与性能目标失败并不矛盾。生成 Provider、embedding Provider 与应用受控时间还需要分开,不用应用内的一段较短耗时覆盖用户实际等待。16

这里最重要的不是补一句笼统免责声明,而是保留具体未达成条件。否则读者看到 PASS、零错误与性能表,很容易推断出材料从未证明的服务等级。

manifest 把结论连回哪次运行

公开包 manifest 记录 source revision、run identity、输入哈希、工件路径及哈希,还有显式 limits。报告说明与结构化 sections 一起收录;发布材料所在提交与产生运行记录的提交不必相同。7

source revision + frozen inputs
              |
              v
recorded run identities
              |
              v
sanitized sections + conditions
              |
              v
manifest + report + declared limits

这条链便于发现混用了语料、运行或工件的问题,但哈希清单不证明实验设计充分,更不是独立第三方认证。manifest 自身的工件项使用全零哈希占位,不能把它描述成包含自身真实哈希的递归签名链。

为了隐私排除原始问题、完整回答与来源摘录,也意味着公开读者不能只靠摘要复现所有实时请求。这里取得的是有边界的可复核性,不是无条件的全量复现。

怎样写出不越界的结论

当前集成包含 Pilot BM25、条件充分性、闭合回答执行与批准生成路由。新的验证需要检查决定性条件与证据预算、路由允许的失败类型、同一冻结载荷、执行消息绑定及流式交付中断;旧产品验收不能覆盖这些新契约。8

最终要证明的是团队能用经审校知识处理带条件的工程决定,还需要实际覆盖与日常使用证据。独立实验生命周期工作树尚未成为集成版本,不因存在实现就宣布新评测已完成。

可以写不应改写成
固定查询集上 Recall 与 Precision 持平Hybrid 永远没有收益
记录的四类注入案例通过模型不会被提示注入
持久栈记录覆盖撤回与历史任意存储副本都已擦除
c1/c5 请求零错误,P95 目标未达成已满足生产性能目标
阅读修订包含这些测试断言本次已重新运行全部验收

上游 README 提供本地确定性 gate 和证据包验证命令。执行这些命令前仍须使用匹配修订与锁文件;本篇引用命令入口不代表本次执行,更不要求为阅读文章连接真实 Provider。1

来源与范围

本篇给设计页的证据边界提供具体读法;实现分支见技术页和证据执行全文。网站构建与浏览器排版检查只验证这些内容能被正确发布,不加入上游产品的验收统计。

参考资料

  1. 发布范围、评测方法、性能与复现入口。 ↩ ↩ ↩ ↩

  2. 冻结检索结果 section。 ↩ ↩ ↩ ↩

  3. 既有产品验收记录。 ↩

  4. 生成 smoke 的引用与 SSE 失败分类测试。 ↩

  5. 有界提示注入记录。 ↩

  6. c1 性能记录;c5 性能记录。 ↩

  7. manifest 与来源链。 ↩

  8. 当前规范产品契约。 ↩