01
默认模型做成确定性的 mock 替身，而不是直接接真模型
依据确定性替身用于断言编排、路由和错误状态；真实模型仍需固定评测集、统计判定和重复运行，不能把 mock 回归当成真实回答质量。
代价延迟数据对生产不具代表性——这一点我在项目自述里显式标注为已知边界，不拿它当性能结论。
PRODUCT → EVIDENCE
产品视角 · 问题、判断与结果
职责与判断：围绕企业问答的出处核对问题，定义引用、低置信拒答与反馈回收规则，结合 AI 辅助实现推进产品验证。
企业工作台：10-06 本地 mock 验收 17/17，泛化诊断 30/34，语义组 3/7；负反馈可入库并查询 Bad Case。独立座舱实验：11 篇样例文档、12 题，token-F1 0.7275、LLM 判官 faithfulness 0.9722，96 次调用 / 36,970 tokens；两组结果分别归属，不代表线上效果。
核验进展与复现材料 · 2026-10-06
已核对负反馈→SQLite Bad Case、四种产品事件，以及 CI 中的确定性 accept 门禁；公开仓库可访问。当前缺少 12 题语义质量基线门禁、批量导入/状态闭环和远端 Actions 成功凭证，因此只判定部分完成。
下一步：先固定语义评测集和批准阈值，打通 Bad Case 复现→修复→回归→状态变更；模型对比须使用同一数据与价格日期，实际 token 数不能直接等同于金额。
材料区分报告记录、源码核对与待办设计；不代表真实用户效果或本轮重新运行了底层项目。
② 角色与时间
角色
独立（架构设计 + 实现 + 验证，全流程无协作方）
时间
2026.09.27 – 09.30
规模
项目规模为早期快照，文件数与字节数不作为当前能力指标。当前案例区分确定性验收、泛化诊断和独立的智能座舱实验。
技术
Python(uv) + FastAPI + SQLite + SSE + Prometheus；Ruff / Mypy / Pytest；Docker
公开
github.com/Ricardo-ye/enterprise-rag-workbench
③ 问题背景
企业问答既可能检索不到，也可能检索到了却缺乏可核对的引用。这一版聚焦出处与质量门控：让结论可以追溯到证据，并明确拒答或转人工的条件。
默认的 mock 模型与 hashing-v1 嵌入是确定性的、离线的，不配 API key 也能把完整链路跑通——这是为了让它可复现，而不是为了让它好看。
④ 关键判断：选了什么 / 否掉了什么 / 代价是什么
02
检索走五路并行 + RRF 融合，而不是单一路
依据五路检索覆盖不同来源与提问形态；当前 hashing-v1 和字面路由对语义改写仍有短板。尚无同口径消融实验，不能将多路检索直接归因为效果提升。
代价复杂度上升，且融合权重需要调试；重建索引 5 次验证稳定在 6 文档 / 6 分块 / 1 FAQ，才敢定下来。
03
低置信度时宁可拒答，也不给一个像样的猜测
依据企业问答里，一次编造造成的信任损失远大于一次拒答。
代价拒答牺牲了一部分直接作答体验。当前未提供真实用户拒答率；验收中的 refusal=1.0 是预设拒答案例指标，不能当作线上拒答占比。
04
把「不做清单」写进项目边界，而不是留白
依据不写就等于默认都要做——这是我在其它项目里吃过亏的地方。
代价看起来「能力少」，但边界清楚反而更容易被信任、也更好接手。
⑤ 实现要点
分层编排：安全词表检查 → 消费者 / 业务分类 → 领域与子意图识别 → 路由到 reject / chitchat / task_flow / kbqa / rag 五条通道之一。命中的通道再走「五路并行检索 → RRF 融合 → 去重 → 可插拔重排 → 证据编号」。生成侧受控：证据约束提示词 → 引用与事实校验 → 合规审计 → 低置信拒答 → 一次自动修复 → 转人工。
关键数据结构是三张表：知识条目（带版本与软删除标记）、FAQ 对、知识图谱三元组；入库用 SHA-256 幂等 + 跨源去重，同一文档重复入库不会产生第二份分块。
⑥ 可验证结果
端到端验收
17 / 17（296.55 ms；10-06 mock 本地报告）
outputs/final-acceptance.json · 2026-10-06；摘要随站附带
工程回归
65 项为站内最近回归记录；本轮未重跑，不作为新的测试结论
tests/ + tests/test_quality_feedback.py；历史 61 项与新增反馈测试分开记录
代码覆盖率
93%（历史覆盖率；不能当作 65 项新版测试的实测覆盖率）
历史 .coverage 记录；本轮未生成新版覆盖率报告
泛化总通过
30 / 34 = 88.2%
outputs/generalization-stability-report.json · 2026-10-06
典型业务
6 / 6（100%）
✓
同上
语义泛化
3 / 7（42.9%）← 已知短板
!
同上。这是我这一版最明确的能力缺口。
输入边界
7 / 7（100%）
同上
安全异常
9 / 9（100%）
✓
同上
重复并发
5 / 5（100%）
✓
同上
路由 50 次
历史记录：50 / 50，P95 34.53 ms
旧版稳定性记录；未从本轮读取的报告复核同项数值，不并入 10-06 结论
8 并发 ×40 就绪
历史记录：40 / 40，P95 25.45 ms
旧版稳定性记录；未从本轮读取的报告复核同项数值，不并入 10-06 结论
检索稳定性
历史记录：20 次调用 source_id 顺序完全一致
旧版稳定性记录；未从本轮读取的报告复核同项数值，不并入 10-06 结论
重建索引
历史记录：5 次稳定 6 文档 / 6 分块 / 1 FAQ
旧版稳定性记录；未从本轮读取的报告复核同项数值，不并入 10-06 结论
answer_success / refusal / citation_recall
历史：1.0 / 1.0 / 1.0；预设验收指标，不是线上拒答率或用户效果
final-acceptance.json
同板块第二证据 · 智能座舱 RAG 能力评估工作台
这是独立的智能座舱评测实验，原站记录周期为 2026.09.24–09.29。11 篇语料 / 12 题仅用于样例链路验证，与企业级工作台的 34 场景诊断集不同。原始核验报告在 09-30 修订了离线基线；下列两种配置分别报告，不计算因果提升。
离线链路 · 09-30 默认配置复现
token-F1 0.3619；precision@k 0.1833；词法代理 faithfulness 1.0000。该组来自核验报告的默认配置复现，已替代旧文档的 0.4220 离线基线。
全 LLM 链路 · final_all_llm.json
token-F1 0.7275；precision@k 0.5000；LLM 判官 faithfulness 0.9722；answer_relevancy 0.3146。来自同一份 12 题原始报告；96 次调用、总 token 36,970。
比较边界
两条链路的重排、压缩、生成和判官配置不同，不将差值归因于某一个模型；faithfulness 的词法代理与语义判定不能直接比较。12 题样例不代表真实用户效果。
工程侧：端到端成功率 12 / 12；96 次 LLM 调用 0 重试 / 0 截断 / 0 上限抬升；token 用量 prompt 30,224 / completion 6,746 / total 36,970，累计 114.7 s；判官 36 次调用 / 49.4 s；平均检索 962.8 ms（含 LLM 重排）。定位并修复 9 个缺陷（含 2 个静默错误：P0×2 / P1×4 / P2×3），回归 7 / 7 全绿。
这一版最有价值的一条结果不是涨了多少，而是纠正了一个错的口径：耗时原本记为 5,674.3 ms，实际是 1,076.3 ms——虚高 5.3 倍，其中压缩环节占 4,598.0 ms（81%）。这是口径定义错误，不是性能问题。同一轮里还发现「推理模型 token 预算共享导致空答案被记为成功」的 P0 指标失真。
证据：智能座驾rag/VERIFICATION_REPORT.md（17,510 B）、data/reports/final_all_llm.json、final_compress_only.json、llm_live_check.json
诚实附注
- 企业级 RAG 工作台是单实例，无多副本一致性；服务级鉴权无租户 RBAC。
- hashing-v1 嵌入与 mock 生成是验证替身，不是生产模型——延迟数据不具生产代表性。
- 语义泛化 3 / 7（42.9%）是真实能力缺口，不是偶发失败；我把它标在表里而不是藏起来。
- SLO 快照样本过小（16 请求 / 6 回答）报 violated，我不拿它作结论。
- 智能座舱 RAG 的评测集是内置 11 篇语料 / 12 题，报告自述「不适合作为产品效果结论」；向量是本地 TF-IDF + SVD，不是语义向量。
⑦ 如果重做
下一步先为 hashing-v1 和字面路由的语义缺口建立可重复基线，再比较语义嵌入与重排。30/34 诊断中语义组仍为 3/7；这是定位线索，尚无消融实验证明单一根因。
另外 mock 替身虽然让回归稳定，但它把「延迟是否达标」这个问题搁置了，第二版应该补一条真实模型下的压测，哪怕样本小。