SYSTEM MAP / MVP 01CLOUDFLARE NATIVE

一条记录，
两套索引，一个出口。

D1 是标题与链接的唯一事实源；FTS5 负责精确词，Vectorize 负责语义近邻。Worker 在边缘执行筛选、并行召回与融合排序。

设计约束不保存正文不依赖爬虫流程面向百万级记录

01 / REQUEST PATH

查询路径

关键词与向量召回并行执行，避免让一种算法决定全部结果。

Browser

检索界面React / vinext

Worker

查询编排筛选 · 缓存 · RRF

03A

D1 + FTS5

记录与关键词标题 · 链接 · 元数据

03B

Workers AI

查询向量化BGE-M3 · 多语言

Vectorize

近邻召回record_id · filters

RRF / RECIPROCAL RANK FUSION

关键词结果与语义结果各自保留原有顺序，再按名次融合。不需要维护脆弱的分数权重，也不会混淆 BM25 与余弦相似度的量纲。

score(d) = Σ 1 / (60 + rank(d))

02 / BOUNDARIES

服务与存储边界

D1 保存什么

标题、原文链接、分类、来源、语言和发布时间。标题同步进入 FTS5 虚拟表；链接保持唯一，点击后始终跳往原站。

Vectorize 保存什么

由“分类 + 来源 + 标题”生成的数值向量，以及 record_id 和筛选字段。它是可重建索引，不是业务事实源。

为什么暂不使用 R2

当前没有正文、附件或其他大对象。TXT/JSON 只是导入介质，完成校验后无需永久保存，MVP 不创建空闲存储。

Worker 做什么

校验查询、执行过滤、并行访问两类索引、融合排名，并将稳定的 SearchResponse 返回给界面；前端不接触任何 Cloudflare 凭证。

03 / SCALE PATH

从展示 MVP 到数百万条

先保持系统简单，再依据真实文件大小和查询压力分片。

MVP单库 + 单索引

验证数据契约、界面和三种检索体验。导入以小批量受保护 API 完成。

100K — 3M索引与缓存优化

基于真实记录测量 D1 体积、FTS 查询时间和热门查询命中率。

3M+按来源或哈希分片

查询路由并发访问少量 D1 分片；Vectorize 保持统一或按语言拆分。

标题语义的天然上限

向量只能理解标题提供的信息。标题过短、玩梗或缺乏上下文时，语义召回质量会低于全文检索系统；这是“不保存正文”带来的明确取舍。

04 / DATA CONTRACT

最小输入契约

只有 title 与 url 必填，其余字段用于筛选和提升标题语义。

[
  {
    "title": "中文短标题如何做语义检索",
    "url": "https://example.com/topic/42",
    "category": "搜索工程",
    "source": "Example Forum",
    "language": "zh",
    "publishedAt": "2026-09-02T08:00:00Z"
  }
]

必填

title · url

一条记录，两套索引，一个出口。