← Projects
灵小禅 · 景区问答 RAG
在开源项目上补充混合检索、执行 Trace 与事实级评测，以 50 题、7 组消融分析检索链路。
Stack
目录5 节
我的工作范围
这是基于开源景区问答项目的二次开发。我的工作集中在检索链路与评测增量：围绕票价、开放时间等事实问答，补充向量、结构化与关键词三路检索，使用 RRF 融合候选并重排，通过 Express 接口返回答案、来源片段和执行 Trace。
把回答拆成可检查的事实
维护 50 题事实评测集，以事实契约检查答案是否包含预期信息。七组组件消融使用同一题集，逐题隔离会话，关闭历史与完整知识注入，固定 retrievalTopK=8、contextTopK=5，保存回答、事实命中、配置和模型身份。
历史实验结果
以下为 2026-09-17 单次受控消融实验，不是线上用户准确率，也不是当前代码的新复测。
| 配置 | 事实契约通过率 | 平均事实召回 | 平均耗时 |
|---|---|---|---|
| 向量单路 | 94%（47/50） | 0.960 | 2336.08 ms |
| 完整方案 | 98%（49/50） | 0.980 | 2882.68 ms |
同题集上完整方案多通过两题，同时平均耗时增加。这是一次运行的观察差异，尚不能推出对其他题集的普遍提升。独立正式基线为 48/50（96%），与上表消融结果分开记录。
请求模型为 deepseek-chat，服务端观测模型为 deepseek-flash，原始 manifest 保留了这一差异。
失败分析与质量门禁
检索、重排、生成和降级状态分别记录。质量门禁检查 API 失败、模型身份缺失与 Trace 不一致。2026-09-21 重跑因模型服务失败，七组门禁均未通过，因此归入服务故障诊断，不替换历史正式结果。
这段实践让我更重视执行链路是否真的发生：返回了答案，不代表成功运行了完整 RAG；测试集中的事实命中，也不能替代真实使用反馈。
复查入口
内容核对：2026-10-04；实验日期：2026-09-17。