放弃了「融合一定更强」的卖点
多路融合在 demo 里更好看，但实测更差。把负面结果写进 README 会让项目显得「没那么强」，但这就是测量的意义：数字约束项目能宣称什么。
四条索引逐维实测，赢的留、输的关
2026 · 独立设计与开发 · Python · SQLite FTS5 · RRF · Local-first
书签搜索只匹配标题，但你记得的是「为什么存」。我给每条书签建四条索引（字面、内容、意图、上下文），用 RRF 融合，然后逐维跑对照实验：融合组输给了最简配置 5.4 个百分点，于是输掉的维度默认关闭，负面结果写进 README。
4索引假设
1,524测试用例
5.4pp融合组实测负增益
1SQLite 文件
01背景
八个月前存过一个页面。你记得为什么存（「帖子里有人讲 Postgres 索引类型的那个」），也记得大概什么时候存的。唯独不记得标题，而浏览器书签搜索只匹配标题。
02卡在哪
直觉的解法是「索引越多越好」：字面匹配、语义向量、LLM 生成的意图查询、收藏时的上下文，四路召回用 RRF 一融合，听上去就是答案。但每多一路索引，构建成本、存储、查询延迟都在涨，而「多一定比少好」从来没有人真量过。
03怎么解
把每条索引当成一个可证伪的假设：四套索引全部建出来，配 RRF 融合，再写一个 eval 命令对 20 余种配置逐个跑同一组查询集。结果发表在 README 里：融合组输给了最简的内容向量配置 5.4 个百分点，加字面索引再掉 5.4pp。于是出厂默认只开赢的那一路，输掉的保留开关但默认关闭。检索之外的一切刻意从简：单文件 SQLite、本地优先、对浏览器书签库永远只读。
关键取舍
写清楚放弃了什么，比罗列做了什么更说明判断。
放弃了云端同步与账号体系
本地单文件意味着换机器要自己搬数据。但书签是隐私数据，「什么都不上传」这条承诺比同步便利性更值钱。
1,524 测试用例facetmark README Tests 徽章与 tests/ 目录，2026-09-21
融合 -5.4ppREADME「What Is Actually Measured」：配置 B 对配置 A 的 W1 查询集实测
4 条索引 / RRF 融合README「How It Works」：lex_tri / lex_seg / content / intent + context
0 Star / 1 ForkGitHub API：GET /repos/88lin/facetmark，2026-10-01