让内部资料能被问，撑不住的那句会被标出来

答案里每一句都拿去和检索到的段落比对，撑不住的那句当场标出来。这一步是自动的，也是看得见的，不靠人事后抽查。

这是产品自己的截图，不是示意图。问的是达尔文，前两句挂着 [1] [2]，第三句「作者是在热气球上写的」是我们故意塞进去的假话，当场被标成 unsupported。底下那行是验证器读数：2 条有据、1 条被标、阈值 0.55。右上角标着 mock model，因为要让这句假话每次都稳定复现。

为什么这件事值得单独做

资料不是没有，是散着。合同在一个网盘，工艺参数在某个人的电脑上，去年那次返工的结论只留在一封邮件里。新人问一句，老人要翻二十分钟。

直接丢给大模型答，它会编。更麻烦的是挂上引用之后编得更像：引用就摆在旁边，读的人默认那句有据，于是反而不去查了。

所以真正值钱的不是「会答」，是没把握的那句会被指出来。这套东西的工程量基本都花在这一件事上。

现在能跑出来的数

检索评测：不同 k 下的命中率和平均倒数排名
指标	k=3	k=5	k=10
命中率 recall@k	0.867	0.867	1.000
平均倒数排名 MRR	0.789	0.789	0.810

15 道金标问题跑在 254 个分块上，语料是三篇公共版权文献。命令 npm run eval，2026-08-31 现跑。k=3 和 k=5 命中的是同一批，所以那两列一样。另一条：npm test 出 223 项通过，另有 9 项要装 Postgres 才跑，没装就自动跳过。

建索引和检索这两步跑在你自己的机器上，用的是本地嵌入模型，不需要任何 API key，资料不出门。只有最后生成答案那一步才走模型。

它什么时候会错

验证器是个启发式判断，不是逻辑证明。下面三条是已知的失效方式。

看不出否定。「X 会导致 Y」和「X 不会导致 Y」在向量空间里挨得很近，所以被反过来说的一句，仍然可能算成有据。
会误伤。改写得厉害、或者要跨好几段综合才成立的句子，本来是有据的，也可能掉到阈值下面被标红。
它量的是对不对得上原文，不是对不对。原文自己写错了，照抄过来一样算有据。

交付边界

你给

一批文档，md 和 txt 起步
一个具体的问法场景，比如客服要查工艺参数
一个人负责判断答得对不对

我们给

索引和检索，跑在你自己机器上，不用 key
带引用的问答端点，出处可点回去，撑不住的句子带标记
一行 script 标签挂进你现有页面

不接

要它替你拍板的场景。它是查资料的，不是签字的
把出处链接拆掉只留结论。那一拆，上面写的保证全部作废

接着看

另一条服务线线索到外联自动跑开始说说你现在哪一步最花时间