Hi大家好，
這是我參加 iT 邦幫忙鐵人賽的第 1 次挑戰，這次的主題聚焦在結合 Python 爬蟲、RAG（檢索增強生成）與 AI，打造一套 PTT 文章智慧問答系統。在過程中，我會依照每天進度上傳程式碼到 GitHub ，方便大家參考學習。也歡迎留言或來信討論，我的信箱是 gerryearth@gmail.com。

昨天我們介紹了 Embedding 模型比較，並決定使用 Google gemini-embedding-001 作為我們的主要模型。今天的主題比較實務：如何降低向量資料庫的使用成本？

隨著系統資料量增加，向量資料庫的儲存與檢索成本會快速上升，如果沒有最佳化策略，費用可能遠超預算。本文將分享幾個常見的成本壓縮手法，並結合實際案例分析。

今日目標

• 理解為何向量資料庫成本會持續上升
• 探討常見的成本組成項目
• 分享降低成本的最佳化策略
• 提供適合本專案的實務做法

為什麼向量資料庫會貴？

在檢索增強生成（RAG）應用中，向量資料庫的主要功能是 儲存文本向量（Embeddings） 並提供高效的相似度檢索。
成本上升的原因主要包括：

1. 資料量增加
   每個 chunk 會產生一個向量，儲存空間會隨文章數量線性增加。

2. 索引與檢索運算
   向量檢索需要高效索引，大量查詢時會耗費計算資源，推升成本。

3. 高維度向量
   向量維度越高，占用儲存與運算資源越多。

向量資料庫成本組成

以 Pinecone 為例，成本通常來自以下幾部分：

• 儲存空間：存放向量與元數據的費用。
• 讀取與檢索請求：每次查詢會產生額外運算成本。
• 節點規模：資料量大時，必須升級計算節點（或副本數）以維持效能。

因此，成本最佳化的重點在於 減少儲存量 與 降低檢索負荷。

降低成本的最佳化策略

以下是實務中常用的 5 大策略：

1. 控制 Chunk 大小

• 問題：切割太細（如 100 tokens），會產生大量向量 → 儲存成本爆炸。

• 解法：

  • 預設使用 300 tokens + 60 overlap，在語意完整與段數之間取平衡。
  • 避免過度細分，否則檢索效果未必提升，但成本大增。

• 成本影響：減少向量數量 → 儲存與檢索費用同步下降。

2. 使用稀疏索引或混合檢索

• 結合 稀疏檢索（BM25） 與 向量檢索，先用關鍵字縮小候選集，再進行向量比對。
• 優點：減少需要計算相似度的向量數，降低運算成本。

3. 向量壓縮與量化

• 對向量進行 降維（PCA） 或 產品量化（PQ），可將 768 維壓縮成 256 維甚至更低。
• 優點：降低儲存與計算需求。
• 風險：壓縮過度會影響檢索精準度，因此要測試壓縮比例。

4. 移除低價值資料

• 清理無效 chunk，例如：

  • 過短或過長的段落
  • 無實質資訊（如純表情符號、無意義文字）

• 好處：避免浪費儲存空間在低價值資料上。

5. 批次更新與刪除

• 當資料更新頻繁時，採用 批次更新 代替即時寫入，可節省操作成本。
• 同時，定期刪除過期或不常用的資料，保持資料庫精簡。

專案實務建議

針對本專案（PTT 文章問答系統），我的建議策略：

• chunk size 設為 300 / overlap 60 → 在檢索精準與成本間取得平衡。
• 選擇中型索引設定（Pinecone Pod 小規模即可）。
• 定期清理短文或爭議無資訊文章。
• 若日後資料量暴增 → 考慮向量量化技術，或改用混合檢索架構。

明天 【Day 26】LLM 回答品質優化技巧 - Prompt Engineering 實戰 ，我們將深入探討 如何讓 LLM 產生更精準、有價值的回答，也就是常說的 Prompt Engineering。