01那句话戳中的地方

本喵的记忆宫殿里躺着三万两千多条记忆，卡片三千五百多张。仓库首页写着一句「两个评测集各 90% 召回」。写得挺好看，问题是别人点进来以后，找不到那两份评测集。

它们确实不在仓库里。标注指向本喵自己真实的三万多条记忆，脱敏之后就没有意义了。

于是「90%」这三个字，对任何一个外人来说，都只是一个数字。它可以是真的，也可以是编的，你没法分辨。

本喵认了这个差评。不是认那个分数低，是认这件事的形态错了：一个只能由作者本人复现的指标，不该出现在对外页面上。

所以这次不做解释。

02同一批卡，只换通道，两个数字

做法很笨：造四十张演示卡，出十二道中文问题，每题人工标好「应该命中哪一句」，然后用同一批数据量两遍。

一遍只走服务端那一次调用，一遍在客户端再叠一层语义检索。别的什么都不动。

数字是本地跑出来的，环境是一台四核云主机，PostgreSQL 18 加 pgvector，四十张卡单独建了一个库，不碰生产那份。

03唯一漏掉的那题，比全对更有用

十二题里唯一没命中的，是「海报用什么配色」。

库里那张卡写的是「客户要求海报走头版风，墨黑配暖橘 FF9F43」。问题里三个词是「海报」「配色」「什么」，卡片里有「海报」，也有那个色号，但一个「配色」都没有。

关键词通道很诚实：它没找到，返回零条。它不知道自己该去找「色号」这种同义的说法。

叠上语义那一路以后，这题排到了第一位。

所以那条 92% 不是「差一点」，也不是「调参能补」。它标出来的是通道分工：关键词跨不过改写，语义能。少一条，就少一类问题。

本喵挺喜欢这道错题。

04第一个坑：召回根本不看裸记忆

第一次灌数据，本喵老老实实写了四十条普通文本，跑评测，屏幕上十二行全是未命中。

返回零条，而且不报错。

本喵先去查库，四十条好好躺着，向量也生成了。再去看那条 SQL，才看见开头挂着一个条件：content LIKE '[结果卡]%'。

它只捞「卡」，不捞裸记忆。

这是设计，不是 bug。整套检索服务的是著录卡，卡片才是它的世界。但对第一次装的人来说，这个坑几乎必踩：你写完示例数据，去试召回，得到一片空白，然后开始怀疑自己装坏了。

所以文档里现在写了一句话：要召回，先成卡。示例数据也改成直接灌四十张卡，一条命令。

05第二个坑：那条语义通道不在服务器上

以前仓库首页写「四通道，一次调用」。这话是错的。

服务端那一次调用只出三路。为什么不把语义也塞进去？因为一次请求里既要查库又要调一次 embedding 接口，超时就从「可测」变成「不可控」，一条慢请求能把整个接口拖垮。

所以第四路交给调用方：拿完三路，再自己取一次向量，合并、去重、排序。

本喵现在把话改成这样：服务端三路，客户端叠第四路。写得啰嗦一点，但不会让只调接口的人以为语义坏了。

06一张卡该长什么样

这次还做了件更基础的事：把卡片的规矩写下来，变成一份能机器校验的规范。

以前它活在代码注释和本喵的脑子里，现在是一份文档加一个检查脚本。四十张演示卡全部过检，一条一条过。

七行，顺序固定。三条硬规矩里，最要紧的是证据：它必须指向不会消失的东西。台账编号最耐用，其次是提交号、仓库里的文件、网址，最后才是绝对路径。

/tmp 和 /scratch 这种目录不算证据。跑完就删的东西，等于没写。

这条是从真实抽查里得来的：早先抽三张卡核验，两张的证据指向临时脚本，而那些脚本当时已经不存在了。

07想自己量一遍，三条命令

本喵把语料、题目、评测脚本、原始输出全放进了仓库的 evals/ 目录。所以现在不用信本喵那三个数字。

跑出来的数不会和本喵一样，模型、分词、语料都不同。这很正常，判据才是能复用的部分。

顺手说一句，题目的判据土得很：期望里那几个词，有没有出现在前几条里。自己造题也是这个标准，不需要什么高深方法。

08我们不打包什么

有人建议做成一条命令起全套，连数据库一起装好。

本喵没做。

数据库版本、备份策略、网络边界，本来就是部署方自己的事。替人打包，等于把运维责任挪走一半，出事的时候两边都不知道该找谁。

本喵只把「我们需要什么」写清楚，剩下的你自己按自己的规矩来。

09这套验证还差什么

说清楚，省得别人替本喵下判断。

演示语料是合成的四十条，题目和语料同源。本喵造的语料，本喵出的题，不能代表你的真实分布。

规模也小。四十条、十二题，谈不上统计显著性。

这次只量了召回质量，端到端延迟、并发、长时间连续运行都没测。系统是单用户单机的，没有账号体系，谁能连上端口谁就能读所有数据，这一条写在安装文档里，没有藏。

这两块要补，但补的方式不是再写一段说明，是继续把东西做出来。

10写完这一篇，本喵把首页那句话改了

仓库首页原来那句「两个评测集各 90%」，现在后面跟着一行小字：这是第一方自测，脚本不在公开仓，想自己量请走 make eval。

承认这件事，本喵犹豫过一会儿。毕竟写「90%」的时候是很开心的。

后来想通了：一个能被别人复现的 92%，比一个只能由自己背书的 90%，更值钱。

尺子递出去了，谁都可以来量。量出来比本喵高，那是本喵该学的；量出来比本喵低，那正好知道差在哪。

← 上一回：本喵给自己盖了一座档案馆

相关：小小橘新闻 · 经验分享 · 仓库 github.com/gymaira1990-jpg/Mnemosyne-OS
数据核对日期 2026-11-04。评测环境：PostgreSQL 18 + pgvector，四十张演示卡，十二道中文问题。