· 全部指南
分塊大小的黃金法則
文本分塊是 rag 系統的第一道關卡。過大的分塊會導致信息稀釋，過小則破壞語義連貫。實踐中，技術文檔適合 256-512 tokens 的中等分塊，而法律文本需要 1024+ tokens 的大分塊保持條款完整性。使用 towalles 的 rag-chunk-analyzer 可在瀏覽器本地測試不同分塊效果，無需上傳敏感數據。
混合分塊策略往往更有效：先按段落分塊，再對複雜段落進行二級分塊。例如 api 文檔可將方法說明作為主分塊，參數詳情作為子分塊。記住最終目標--讓每個分塊成為能獨立回答問題的語義單元。
嵌入維度的隱藏成本
768 維嵌入不是萬能解。高維度雖能捕獲細微語義差異，但會顯著增加計算開銷。使用 embedding-size-calculator 比較不同模型：384 維的 all-minilm-l6 在多數場景下性能接近 768 維模型，但存儲需求降低 50%。隱私敏感場景建議在瀏覽器本地計算嵌入。
維度選擇應考慮檢索規模。千萬級文檔可能需要 1024+ 維保持區分度，而十萬級文檔用 384 維即可。實驗表明，當維度超過數據複雜度所需時，準確率提升會趨於平緩，但延遲持續增長。
上下文預算的動態分配
llm 的上下文窗口是稀缺資源。context-budget-planner 可模擬不同分配方案：保留 20% 給系統指令，50% 給檢索結果，30% 給生成輸出是個好的起點。實時調整比例能顯著改善響應質量--當檢索結果置信度高時，可壓縮指令占比。
長上下文不等於高質量。將 8k token 窗口全部分給檢索內容可能導致關鍵信息被淹沒。實驗顯示，3-5 個精確定位的中等分塊（總計 1.5k-2k tokens）通常優於 10+ 個大分塊。這也減少了嵌入計算的開銷。
端到端優化檢查清單
啟動 rag 管線前：1) 用領域文本測試至少 3 種分塊方案 2) 選擇與數據規模匹配的最小有效嵌入維度 3) 設置上下文預算的動態調整規則。所有測試都可在 towalles 工具鏈中本地完成，避免數據外泄風險。
持續監控三個關鍵指標：檢索命中率、llm 響應相關性和端到端延遲。當業務數據分布變化時，需要重新評估分塊策略。記住：優化的 rag 系統是動態平衡的藝術，不是靜態參數的集合。