Enterprise-RAG · RAG → Knowledge Agent
底层是通过冻结留出集验收的权限感知 RAG；上层 Agent 通过六个有限只读工具分步查证，并持久化任务、事件与工具轨迹。所有内容读取都重新鉴权，最终回答仍必须回到原文。依据不足时拒答，撤权后已有结果隐藏。
这个系统解决什么
授权范围是检索查询的一部分，关键词与向量两路共用同一集合，返回答案前再校验一次。先检索全部再过滤，意味着敏感资料已经进过排序和生成链路。
模型只选带编号的证据片段，服务端取回真实原文、校验版本与权限后才组装引用。校验不通过的答案不会被修复，而是判定失败。
决定可见性的是业务库而不是搜索索引。撤权提交后的下一个请求就被拒绝，不等待索引清理——连历史记录里的提问文本都会被遮蔽。
只有模型交出分属两份不同文档的两段矛盾原文，系统才报告冲突。加这道门槛之前，冲突判定的精确率是 4.2%。
Knowledge Agent · Phase B
固定工作流提供低成本基线，动态模式由本地 7B 模型在白名单中选择动作。身份、租户和 ACL 由服务端注入，模型不能指定；重复动作会消耗步数预算并停止，不会无限循环。
| 真实冒烟 | 动作 | 墙钟时间 | 结果 | 引用 |
|---|
动态 Agent 这次约 111 秒，固定工作流约 23 秒。两次任务不同，所以这只能证明两条链路都能运行，不能比较效果。下一阶段必须在同一冻结任务集上配对评测；若质量没有增量，简单任务继续走固定工作流。
实测结果
下面每个数字都由脚本从运行产物中读回生成，不手工填写。开发集参与过选型，留出集只运行一次，验收门槛在运行之前就已写定。
| 检索配置 | Recall@5 | MRR@10 | 回答正确率 |
|---|
混合检索的检索指标低于 BM25，端到端却最高。证据预算只有 4 段时，决定成败的是这 4 个位置被谁占了，而不是金标文档在不在前 10。差异未达统计显著（McNemar p = 0.19），所以准确的说法是实测最优，不是已证明更优。
| 指标 | 门槛 | 实测 |
|---|
留出集比它从未参与过的开发集高 0.9 个百分点，没有观察到开发集过拟合。
| 检索配置 | Recall@5 | 回答正确率 |
|---|
英文语料 + 100 份干扰文档。这里混合检索的检索优势明显，与内部数据上的排序相反——说明 BM25 在自建语料上的领先来自那批资料的专有名词特征，不能推广。
界面
下面的截图来自一份可执行走查：它对着当前版本真实操作，断言每一步应当展示的内容，结束时清理自己上传的资料。录像只能证明演示发生过一次，走查每次都跑。
没有采用的方案
检索指标明显改善（Recall@5 0.935 → 0.968），端到端几乎不动（p = 0.79），同时冲突精确率从 100% 掉到 92.3%、耗时增加 22%。已实现，默认关闭。
四组对照显示：不给历史的 LLM 改写与完全不改写逐位完全相同。收益全部来自对话历史，没有一点来自"用模型改写"。最终采用零模型调用的规则拼接。
为堵"答非所问"实现，在冻结集上校准后发现：判对回答的重合度 5 分位是 2，判错的无一低于 3——阈值只会误杀正确答案且抓不到任何错误。已完整回退。
保留这些记录，是因为一个系统最终为什么没有采用某个常见组件，本身就是工程结论。
边界
本页是项目展示，不是可交互的在线系统。系统需要 PostgreSQL、OpenSearch 与本地 7B 模型（约 7 GB），无法在静态托管上运行。要实际试用请按仓库里的 make 步骤在本机启动。