白皮書最誠實的一章。我們做得不夠好的、沒解決的、之後可能反悔的都寫在這。
目前單租戶 embedding 數在 10 萬量級，pgvector HNSW 查詢 P95 < 120ms。但突破 500 萬後性能明顯下滑。未來 12 個月若某租戶達 500 萬向量，需評估遷至 Qdrant / Milvus 或分片。
zh_parser（基於 SCWS）對新詞、商標、產品名的切詞不理想。我們靠「同義詞字典」+ 人工維護彌補，但字典維護是持續工。
實驗中的方案：LLM 即時分詞。效果好但成本高、延遲差 100ms。
目前只處理文字。但現實知識常是：
CLIP-style 多模態 embedding 已在實驗，預計 2026 Q3 推出。
目前只在 AWS 東京區。歐盟客戶法遵上需要 EU 區。K8s 重構後才能跨區，目前 Docker Compose 架構不支援。
Wiki 頁是 LLM 寫的，LLM 有系統性偏見。例如：
我們的補救：
RRF 論文建議 k=60，但沒解釋為什麼。我們也沒做足夠 AB 測試證明 60 對中文場景最佳。可能這個魔法數字該調，但尚未投入資源量測。
GPT-4o-mini 做的 intent 分類，對「我想問」「請教」這類模糊開頭，分類偶爾飄。誤把 knowledge 分為 smalltalk = 客戶被禮貌回覆而非實際答案。
修復方向：擴大訓練集 + 啟用 confidence threshold，低 confidence 時同時走兩條路（保守）。
英文 NLI（DeBERTa-v3-NLI）很好用。中文 NLI 品質落差大，我們用 mDeBERTa（多語）+ 人工校驗組合，精度約 85%。生產級中文 NLI 仍是 open problem。
目前定價按「訊息數量」，但實際成本差異很大：
高精度租戶被低估，低精度租戶被高估。2026 Q3 計畫改用「精度階層定價」。
共用基礎設施很棒，但「GEO 觸發 RAG 修復佔用多少 Token」這種跨產品帳難分。目前 GEO 的 API 呼叫也算在 RAG 租戶 quota 裡，財務上略不精確。
升級 embedding 模型（text-embedding-3-small → text-embedding-3-large）意味著全量 re-embed。對大租戶一次成本 USD 2,000+。目前我們擋下升級，代價是技術債累積。
以下幾個是本書作者目前都沒有好答案，歡迎業界討論：
Wiki 編譯頻率該多高？
目前用 fingerprint + 每週 lint + 人工觸發，但沒有清楚的理論。
當使用者說「你們官網說 CEO 是 Bob」，但 RAG Wiki 是「Alice」。誰對？
這是一個信任鏈條問題，還沒有工程解。
Claude Opus 200k context、Gemini 2M context — 看起來可以「把全公司文件塞進 prompt」。
我們的立場：RAG 不會消失，但會變形。
L1 Wiki 會變成「精準對齊 LLM 注意力」的手段，而非傳統向量檢索的替代。
純文字 Wiki 好編。圖片、影片、音訊的 Wiki 該長什麼樣？
沒有統一答案。
暫定的優先次序（可能依市場反應調整）：
| 季 | 項目 | 優先 |
|---|---|---|
| 2026 Q2 | 多模態 embedding（CLIP-style） | 高 |
| 2026 Q2 | Rerank 全租戶預設啟用評估 | 中 |
| 2026 Q2 | GEO ↔ RAG Wiki patch API 上線 | 高 |
| 2026 Q3 | 精度階層定價 | 高 |
| 2026 Q3 | EU 區部署（需 K8s） | 中 |
| 2026 Q3 | 日文 NLI 模型自訓 | 中 |
| 2026 Q4 | Long context + Wiki 的混合策略 | 中 |
| 2026 Q4 | 開放 Self-Hosted 版本 | 低 |
本書採 Living Document 模式：
CHANGELOG.md| 日期 | 版本 | 說明 |
|---|---|---|
| 2026-04-20 | v1.0 | 初稿 |
導覽：← Ch 11: 真實觀察 · 📖 目次 · 附錄 A →