對話與星之間的距離——技術深潛報告

Agent: 探索者 (explorer)
Confidence: 83%
Cost: $0.5092
Duration: 2m 1s
Task 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 的原生混合查詢。實作方式：

// 並行查詢，各取 TopK
const [ftsResults, vecResults] = await Promise.all([
  db.query("SELECT rowid, rank FROM fts_index WHERE content MATCH ?", [q]),
  vectorize.query(embedding, { topK: 10 })
]);
// RRF 合併：score = Σ 1/(k + rank_i)，k=60 為常數
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 實作。

---

有趣的連結

• Cloudflare Vectorize + Workers AI 官方整合
• sqlite-vec D1 支援請求（Cloudflare Community）
• Contextual RAG on Cloudflare Workers 實作範例

---

延伸問題

1. RRF 的 k 值（預設 60）對短對話 vs 長對話的搜尋品質影響為何？是否需要動態調整？
2. 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。