問題：跟不上速度的 RAG
知識庫只有在檢索夠快的情況下才有用。當我們在 JieGou 推出 RAG 支援時，整個流程是可行的——文件被切塊、嵌入、並注入到提示詞中。但效能數據說明了另一個故事。
一個包含 705 份文件的知識庫，檢索相關內容需要 約 160 秒。這意味著每次配方執行、每個工作流程步驟、每次使用知識庫的代理對話，都要在 LLM 開始生成之前付出數分鐘的延遲代價。
對於互動式使用場景——客服人員查詢政策、業務代表在對話中調出產品規格——160 秒是無法接受的。
我們需要在不增加基礎設施複雜度的前提下，將檢索時間壓到一秒以內。
第一階段：Firestore 原生向量搜尋
原始的檢索方式是從 Firestore 載入所有嵌入向量，在應用程式碼中計算餘弦相似度，然後回傳 top-k 結果。這個方法簡單且正確，但隨文件數量線性擴展。
第一個優化是使用 Firestore Vector Search（基於 ScaNN 索引）將相似度搜尋移入 Firestore 內部。我們不再將全部 705 個嵌入向量拉到記憶體中計算距離，而是讓 Firestore 原生處理最近鄰搜尋。
改變了什麼
- 之前：取得所有嵌入向量 → 在 Node.js 中計算餘弦相似度 → 排序 → 取 top-k
- 之後：單一 Firestore 查詢，使用
findNearest()→ 直接回傳 top-k
這消除了 O(n) 的資料傳輸和計算。Firestore 的向量索引使用近似最近鄰演算法，以極微小的召回率損失換取大規模集合的巨大速度提升。
結果
705 份文件的冷查詢從 約 160 秒降至約 10 秒。16 倍的提升——但對於互動式工作流程來說仍然太慢。
第二階段：混合檢索與降級機制
並非每個查詢都能從向量搜尋中同等受益。某些知識庫足夠小，暴力搜尋比向量索引查詢的開銷更快。其他文件的嵌入效果不佳（表格、程式碼片段、結構化資料）。
我們實作了混合檢索策略：
- 優先嘗試向量搜尋 — 如果 Firestore 向量索引存在且知識庫有嵌入向量，使用
findNearest() - 降級到暴力搜尋 — 如果向量搜尋失敗、不可用或回傳結果太少，載入嵌入向量並在應用程式碼中計算相似度
- 合併與去重 — 結合兩條路徑的結果，按文件 ID 去重，按相似度分數重新排序
混合方式確保檢索永不失敗。如果 Firestore 向量索引尚未建立（例如新佈建的環境），系統會優雅地降級到原始的暴力搜尋路徑。
usedVectorSearch 旗標
每次檢索操作現在都在其追蹤 span 中包含一個 usedVectorSearch 布林值。這讓我們能夠監控哪些查詢走了快速路徑，哪些走了降級路徑，並識別需要建立索引或重新嵌入的知識庫。
第三階段：Redis 快取處理熱查詢
最後一個優化針對的是重複查詢——在短時間內對相同知識庫提出相同問題。這在生產環境中持續發生：
- 多個工作流程步驟查詢同一個 FAQ 知識庫
- 代理對話在每一輪都重新檢索上下文
- 批次執行中 50 個項目查詢相同的參考文件
我們新增了每文件 Redis 快取，TTL 為 10 分鐘：
- 在執行相似度搜尋前，以
(knowledgeBaseId, queryEmbeddingHash)為鍵檢查 Redis - 命中快取時，立即回傳——完全不需要 Firestore 查詢
- 未命中時，執行混合檢索流程並快取結果
結果
| 場景 | 優化前 | 優化後 |
|---|---|---|
| 冷查詢，705 份文件 | ~160 秒 | ~10 秒 |
| 熱查詢（Redis 命中） | ~160 秒 | <1 秒 |
| 小型知識庫（<50 份文件） | ~5 秒 | ~2 秒 |
| 50 個項目批次，同一知識庫 | 總計 ~8,000 秒 | ~10 秒 + 49×<1 秒 |
批次場景是快取帶來最大收益的地方。第一個項目承擔冷查詢成本；其餘 49 個項目命中 Redis，在毫秒內回傳。
架構：零外部依賴
一個關鍵的設計約束是不增加額外基礎設施。許多 RAG 平台要求你佈建和管理專用的向量資料庫——Pinecone、Weaviate、Qdrant、Milvus。每一個都會增加：
- 另一個需要部署和監控的服務
- 另一組需要管理的憑證
- 另一個供應商計費維度
- 另一個流程中的故障點
JieGou 的方式只使用你已有的基礎設施：
| 元件 | 用途 | 已存在？ |
|---|---|---|
| Firestore | 向量索引 + 文件儲存 | ✅ 你的主要資料庫 |
| Redis | 查詢結果快取 | ✅ 用於速率限制、會話管理 |
| 應用程式碼 | 暴力搜尋降級 | ✅ 在你現有的 pod 中運行 |
不需要 Pinecone。不需要 Weaviate。不需要佈建、保護或付費的新基礎設施。
這對你的工作流程意味著什麼
更快的配方執行
每個使用知識庫的配方現在在熱查詢時都能在一秒內檢索上下文。重複使用場景中，生成前的「思考中…」等待消失了。
實用的批次處理
對同一知識庫處理數百個項目的批次執行現在是可行的。第一個項目暖機快取；其餘的飛速完成。
即時感的代理對話
對話式代理在每一輪都重新查詢知識庫。有了 Redis 快取，第 2 輪到第 N 輪的上下文檢索只需毫秒，而不是重新執行相似度搜尋。
可觀測的檢索
usedVectorSearch 追蹤旗標意味著你可以看到每次執行使用了哪條檢索路徑。如果某個知識庫持續降級到暴力搜尋，你就知道它需要關注。
立即體驗
如果你已經在使用 JieGou 知識庫，這些優化已經上線——不需要任何配置更改。你現有的知識庫會自動受益於 Firestore 向量搜尋和 Redis 快取。
如果你還沒有設定知識庫：
- 前往 JieGou 控制台的知識庫
- 上傳文件或從 URL 匯入
- 將知識庫附加到任何配方或工作流程
- 觀察檢索在一秒內完成
Firestore 原生向量搜尋、混合檢索和 Redis 快取的結合，意味著你的 AI 自動化可以獲得公司特定的上下文，而不需要承受延遲代價——也不需要管理任何額外的基礎設施。