Agent : 探索者 (explorer)Confidence : 83%Cost : $0.5092Duration : 2m 1sTask ID : f2d2c0c1-04f2-4c7f-88d4-ea69396a344e
現在我有足夠資料可以產出報告。
對話與星之間的距離——技術深潛報告 前置確認 主題與今日已發表文章高度重疊(cosine-distance-semantic-memory-2026-03-08.md),覆蓋了餘弦距離概念 + Cloudflare Vectorize 基礎 RAG 流程。本報告聚焦在文章未覆蓋的下一層實作細節 ,素材重疊度約 30%。
發現 1. sqlite-vec 在 D1 仍是 feature request(2026/03 現況) Cloudflare D1 尚未原生支援向量運算,sqlite-vec 整合仍在社群請求階段。這意味著目前必須分開用 SQLite FTS5(關鍵字)+ Vectorize(語意),不能合併成單一 DB 查詢。
2. Vectorize V2 關鍵規格
每個 index 最多 500 萬向量 ,median latency 31ms
bge-base-en-v1.5 = 768 維 ,metric 建立後不可更改(必須先決定 cosine)
每個向量可附帶 10KiB metadata (夠存 chatId + timestamp + 摘要)
3. 混合搜尋需要應用層 RRF(Reciprocal Rank Fusion) Cloudflare 官方不提供 FTS5 + Vectorize 的原生混合查詢。實作方式:
1 2 3 4 5 6 7 const [ftsResults, vecResults] = await Promise .all ([ db.query ("SELECT rowid, rank FROM fts_index WHERE content MATCH ?" , [q]), vectorize.query (embedding, { topK : 10 }) ]); const merged = reciprocalRankFusion (ftsResults, vecResults, k=60 );
4. 現有對接點:chat-memory-listener.ts 是天然上游 已確認 src/memory/ 有 chat-memory-listener,摘要產生後可直接送 Workers AI embedding → Vectorize。改動最小,風險最低。
5. 混合搜尋的架構抉擇 純 Vectorize 適合「語意相關」查詢;保留 FTS5 適合「精確詞形」查詢。兩者 RRF 合併後,在用戶輸入模糊、話題跨越時效提升最明顯。目前 Bot 沒有 RRF 實作。
有趣的連結
延伸問題
RRF 的 k 值(預設 60)對短對話 vs 長對話的搜尋品質影響為何?是否需要動態調整?
Workers AI embedding 的計費單位是 token 還是請求數?大量歷史對話批次 embedding 的成本如何估算?
重要性:4/5 能直接改善專案品質:現有 FTS5 搜尋有架構天花板,加入 Vectorize + RRF 是下一個明確升級路徑,且 Cloudflare 基礎設施已備齊,改動集中在 chat-memory-listener.ts 和 prompt 構建階段。
—HANDOFF— TO: ESCALATE INTENT: escalate ARTIFACT_TYPE: report SUMMARY: 探索完成。主題與今日發表文章重疊度 ~30%,補充了 sqlite-vec 在 D1 未支援現況、Vectorize V2 規格、RRF 混合搜尋實作方案等文章未覆蓋細節。建議若需後續行動可派 blog-writer 補充文章或派 programmer 實作 RRF。