技術選型：自建、開源框架還是商業平台

• 自建：完全掌控、無授權費、可深度優化；但要自己處理所有邊角，人力成本最高。
• 開源框架：起步快、社群資源多；但抽象層可能綁住你，且版本更新頻繁。
• 商業平台：最快上線、含維運與支援；但成本隨用量成長，且有鎖定風險。

八個評估維度

維度              權重  自建  開源  商業
────────────────────────────────────────
上線時間            高    低    中    高
總持有成本(2年)     高    ?     ?     ?
可控性與客製         中    高    中    低
團隊現有能力        高    ?     ?     ?
維運負擔            中    高    中    低
資料落地與合規      ?     高    高    ?
供應商鎖定風險      中    無    低    高
長期演進彈性        中    高    中    低

四個常見的誤判

1. 低估自建的長尾工作：核心邏輯一週寫完，但監控、重試、限流、版本管理要三個月。
2. 高估開源框架的省力程度：框架幫你到八成，最後兩成常常要讀原始碼才能改。
3. 忽略商業平台的成長曲線：用量成長十倍時費用也成長十倍，且此時遷移成本最高。
4. 沒有把團隊能力納入：技術上最好的選擇，若團隊沒人維護得了，就不是好選擇。

務實的混合策略

• 核心差異化的部分自建：你的提示、評測、資料處理邏輯。
• 通用基礎設施用開源或商業：向量資料庫、推理服務、可觀測性。
• 保留可替換性：模型呼叫做抽象層，向量儲存不要用太特殊的功能。

決策的記錄

# 決策紀錄（ADR）範本
標題：向量儲存選型
日期：2026-08-21
背景：文件量預估 50 萬片段，需支援 metadata 過濾與權限隔離
選項：A 自建 pgvector / B 開源專用資料庫 / C 商業服務
決定：A
理由：資料量在 pgvector 的舒適區；團隊已維運 PostgreSQL；
      權限過濾可直接用既有的資料庫權限模型
重新評估的觸發條件：片段數超過 300 萬，或 p95 檢索延遲超過 100ms