RAG 向量索引壓縮技術參考指南（TurboQuant / turbovec）
RAG 向量索引壓縮技術參考指南 本文件記錄 TurboQuant 演算法與 turbovec 實作，供本系統未來優化 wiki 知識庫 RAG 搜尋索引時參考。 核心問題：為什麼需要向量壓縮？ 本系統目前的 wiki/ 目錄包含大量 Markdown 文件，未來若要引入語意搜尋（RAG）以加速情報查詢，向量索引的記憶體佔用將成為瓶頸： TurboQuant
RAG 向量索引壓縮技術參考指南
本文件記錄 TurboQuant 演算法與 turbovec 實作，供本系統未來優化 wiki 知識庫 RAG 搜尋索引時參考。
---
核心問題：為什麼需要向量壓縮？
本系統目前的 `wiki/` 目錄包含大量 Markdown 文件，未來若要引入語意搜尋（RAG）以加速情報查詢，向量索引的記憶體佔用將成為瓶頸：
| 規模 | float32 儲存（無壓縮） | turbovec（TurboQuant） |
| 100 萬筆 | ~3.1 GB | ~0.4 GB |
| 1000 萬筆 | 31 GB | 4 GB |
| 壓縮比 | 1× | 16× |
---
TurboQuant 演算法原理
> 原始論文：https://arxiv.org/abs/2504.19874
> 開源實作：https://github.com/RyanCodrai/turbovec
壓縮流程（三步驟）
```
原始向量（float32, 1536 dim）
↓ 1. 正規化（Normalize）
↓ 2. 隨機正交矩陣旋轉（Random Orthogonal Rotation）
→ 旋轉後每個座標服從可預測分布
↓ 3. Lloyd-Max 最佳分桶 + Bit-packing
最終結果：1536 dim → 384 bytes（6144 → 384，16× 壓縮）
```
關鍵技術突破
| 技術 | 說明 |
| 隨機正交旋轉 | 讓量化誤差均勻分布，避免特定維度資訊損失集中 |
| Lloyd-Max 分桶 | 事先離線計算最佳量化邊界，推論時零額外計算 |
| SIMD 加速 | 手寫 NEON（ARM）和 AVX-512BW（x86）kernel |
| 速度比較 | ARM 上比 FAISS FastScan 快 12–20% |
---
與現有方案比較
| 方案 | 記憶體佔用 | 搜尋速度 | 精度損失 |
| FAISS（float32） | ❌ 最高 | 中等 | 無 |
| FAISS FastScan（PQ） | 中等 | 中等 | 少量 |
| turbovec（TurboQuant） | ✅ 最低（16× 壓縮） | ✅ 最快 | 極少量 |
---
本系統應用場景規劃
短期（可立即評估）
- 對 `wiki/concepts/` 與 `wiki/events/` 的文件建立 Embedding 索引
- 使用 turbovec 壓縮儲存，節省磁碟與記憶體
- 加速 Codex / Claude Code 在 Wiki 內的語意搜尋
中期（Pipeline 整合）
- 在 `daily_pipeline.py` 中新增「Wiki 語意更新」步驟：
1. 新增/更新的 wiki 文件 → 重新 Embedding
2. 增量更新 turbovec 索引
3. 讓 Supervisor Agent 可以用自然語言查詢歷史情報
長期（RAG 完整架構）
- 整合至 `intel-portal`，讓分析師可在儀表板直接輸入問題查詢知識庫
- 結合現有的 `wiki_health` 語意審計，定期偵測矛盾並觸發更新
---
實作注意事項
1. 相容性：turbovec 需要 Python ≥ 3.10，建議在 `uv` 虛擬環境內安裝
2. Embedding 模型：turbovec 與任何 Embedding 模型相容，建議與現有管線使用相同的模型（如 OpenAI `text-embedding-3-small` 1536 dim 或 `text-embedding-3-large` 3072 dim）
3. 資料品質：向量壓縮後精度稍有損失，建議先在 `wiki/concepts/` 小批量測試
4. ARM 優先：若系統跑在 ARM 架構（如 Apple Silicon / AWS Graviton），NEON 加速版本最適合
---
參考資源
- GitHub：https://github.com/RyanCodrai/turbovec
- 論文 ArXiv：https://arxiv.org/abs/2504.19874
- Google TurboQuant 原始技術：見論文附錄