FTS5全文检索AI语义重排Siftly双引擎搜索架构深度解析【免费下载链接】SiftlyLocal Twitter/X bookmark organizer with AI categorization and mindmap visualization项目地址: https://gitcode.com/gh_mirrors/si/SiftlySiftly是一款本地自托管的Twitter/X 书签管理器它的搜索能力来自一套「双引擎」架构先用 SQLiteFTS5 全文检索在毫秒级圈出候选书签再让AI 语义重排按「意思」而不是「字眼」重新打分排序。整套流程跑在你自己的机器上数据不出本地除 AI API 调用外这让十万条书签里找一张特定梗图这类需求第一次变得轻松。 核心思路一句话FTS5 负责快AI 负责懂两者分工协作。为什么要双引擎单靠一种技术不行吗先理解痛点。书签搜索有两个天然矛盾的需求需求纯 FTS5 的问题纯 AI 检索的问题快✅ 倒排索引微秒级❌ 全库扫描不现实逐条问 AI 成本爆炸懂语义❌ 只能匹配关键词币圈崩盘搜不到 crash chart✅ 能理解同义、近义、甚至画面内容所以 Siftly 的做法是用 FTS5 把候选集从几万条缩小到150 条再让 AI 只精读这 150 条并打分。快和懂各取所长。用户查询 crypto 崩盘的搞笑梗图 │ ▼ ┌─────────────────────────┐ │ 引擎一FTS5 全文检索 │ 毫秒级按相关性排序 │ 几万条 → 150 条候选 │ └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ 引擎二AI 语义重排 │ 逐条精读0~1 打分 │ 150 条 → 15 条最优结果 │ 附为什么匹配的理由 └─────────────────────────┘引擎一FTS5 全文索引是怎么建的给书签建一份可搜索档案FTS5 是 SQLite 自带的全文检索扩展Siftly 用它建了一张名为bookmark_fts的虚拟表把每条书签的5 个字段全部纳入索引定义见 lib/fts.ts索引字段内容来源作用text推文正文最直接的文本信号semantic_tagsAI 生成的 25~35 个语义标签弥补推文里没写但主题相关的情况entities话题标签、工具名、提及精确命中#react、Docker 这类词image_tags视觉分析产出的图内 OCR、场景、物体标签让图里的字也能被搜到bookmark_id书签主键不索引关联回原记录这些字段正是 Siftly 四阶段 AI 流水线的产出——semanticTags和entities在数据模型里就有定义详见 prisma/schema.prisma。也就是说搜索的质量上限在导入时就被 AI 流水线决定了。索引创建时使用了tokenizeporter unicode61分词器这意味着 Porter 词干还原会生效——搜 crashing 也能命中 crash。索引何时重建FTS 表由rebuildFts()全量重建每批 200 条插入避免超出 SQLite 变量上限它在AI 分类流水线跑完后自动触发见 app/api/categorize/route.ts。逻辑很务实数据一变就重建本地 SQLite 上重建很快换来的是查询期零维护成本。查询时发生了什么用户输入的自然语言先经过关键词提取lib/search-utils.ts过滤掉 the / about / show / find 等停用词保留 2 个字符以上的短词——AI、KYC、DeFi 这类关键缩写不会被误杀随后拼成 FTS5 的OR查询按内置的rank相关性排序最多取 150 个候选 ID见 lib/fts.ts⚡ 150 这个数字是刻意为之——源码注释写得很直白smaller, richer set beats larger, noisier set小而精的候选集优于大而杂的。引擎二AI 语义重排让意思相近也能命中候选集不止 FTS5 一个来源拿到 FTS5 结果后搜索路由app/api/search/ai/route.ts还会并行跑一个「意图分类」查询识别查询中的主题信号词如meme|funny|viral→ 搞笑类crypto|defi→ 金融类code|typescript→ 开发者类命中后把对应分类下的书签也拉进候选池两路结果合并去重若候选不足 20 条还会补一批最近的书签兜底这个设计解决了一个 FTS5 的死穴当用户用找点搞笑的这种不含具体名词的问法时关键词检索几乎无能为力但分类意图信号能兜住。给每条候选书签写一份富档案进入 AI 重排前每条候选书签都会被buildIndexEntry渲染成一份结构化的档案app/api/search/ai/route.ts包含text: 推文正文截断 350 字 media: typephoto | scene街景 | ocrBUY THE DIP | vtags图表, 红蜡烛 ai_tags: 25~35 个预计算的语义标签最可靠的信号 categories: 金融与投资(0.9)注意ocr...——图片里的文字也被当作搜索内容。这是 Siftly 视觉分析流水线每图 30~40 个视觉标签的红利纯关键词引擎根本做不到。打分规则AI 不只是排序还要说为什么Siftly 给 AI 的指令相当严格返回必须是纯 JSON最多15 条匹配按分数降序最低分数线 0.30——对语义邻近结果大方给分0.9 留给完全命中每条必须附一句 ≤10 词的匹配理由且要求具体显示了比特币暴跌的 K 线图而不是与加密相关这份aiReason最终会展示在搜索结果卡片上——用户不只是看到结果还能看懂 AI 的推理路径。搜索页 UI 与示例查询见 app/ai-search/page.tsx。️ 三层容错为什么这套系统很难挂本地工具的生命力在于稳。双引擎的每个环节都有降级路径层故障场景降级策略1️⃣ FTS 层索引未建、查询语法错误ftsSearch返回空数组自动回退到LIKE contains模糊查询app/api/search/ai/route.ts2️⃣ AI 通道层API Key 未配置优先走 Claude Code / Codex CLI 的 OAuth 会话零配置复用你的订阅3️⃣ 结果层AI 调用失败返回明确的错误信息而非空响应前端有独立错误态另外还有一层5 分钟 TTL 的内存缓存最多 100 条记录重复提问不再消耗 AI 额度见 app/api/search/ai/route.ts。 这套架构在产品中的三个出口双引擎不只服务于网页搜索同一套 FTS 核心还有两个复用点AI 搜索页/ai-search自然语言输入展示带分数与理由的结果卡片命令行工具siftly search AI agents直接走 FTS5 检索输出 JSON方便脚本化使用cli/siftly.ts全局命令面板Cmd/CtrlK任意页面呼出跨库搜索总结这套双引擎值得借鉴的地方如果你也在给个人知识库做搜索Siftly 给出了三个低成本高收益的设计决策别一上来就上向量库——本地 SQLite FTS5 已能解决 80% 的找得到问题AI 重排补足最后的找得准AI 的价值在导入期前置语义标签、图像 OCR 标签、实体抽取在分类流水线里一次算好搜索期只是读档案处处留降级路径索引坏了退 LIKECLI 坏了退 SDK候选不够退最近记录——单点故障不会让用户面对空白页想深入源码推荐按这条线索阅读lib/fts.ts索引与查询→ app/api/search/ai/route.ts候选合并与重排编排→ lib/categorizer.ts标签从哪来。【免费下载链接】SiftlyLocal Twitter/X bookmark organizer with AI categorization and mindmap visualization项目地址: https://gitcode.com/gh_mirrors/si/Siftly创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考