RAG 評估框架與工具選型：Promptfoo、RAGAS、DeepEval、TruLens
RAG 評估沒有指定工具的業界標準；先把 retrieval、generation、operation 分開量，再依技術棧選 Promptfoo、RAGAS、DeepEval 或 TruLens。
ai
1239 篇文章RAG Guardrails：在輸入和輸出加一道防線
RAG 系統面對的攻擊不只是技術層面的，Prompt Injection 和 Jailbreak 是真實威脅。輸入輸出都需要獨立的防護層。
RAG 可觀測性工具全景：2026 年的選擇
自己寫 trace 夠用，但開源工具讓你少做很多事。Langfuse、Phoenix、LangSmith 各有定位，選哪個取決於你對自架、開源、整合複雜度的取捨。
RAG Observability：讓黑盒子變透明的逐節點追蹤
RAG 系統最難的不是建起來，是搞清楚為什麼這次回答不好。Pipeline Tracing 把每個步驟的決策和數據記下來，讓除錯有跡可循。
RAG Prompt Engineering：System Prompt 和 Context 怎麼設計
搜尋找到了正確的文件，但 LLM 的回答還是不好——很多時候問題在 Prompt 設計。System prompt 結構、context 排版、指令語言都會影響輸出品質。
RAG Streaming：SSE 讓 LLM 回答邊生成邊顯示
LLM 生成需要 3-5 秒，等全部生成完再顯示體驗很差。SSE 讓 token 一邊生成一邊推送，首個字元出現時間從 5 秒縮到 1 秒以內。
RAG 配額系統：用雙重限制控制 LLM 成本
只限制請求次數不夠，一個超長的查詢可能消耗掉十個普通查詢的 token。雙重配額（請求數 + token 數）才能真正控制成本。
RRF：RAG 系統裡多路結果怎麼合併
BM25、向量搜尋、HyDE、Multi-Query 各出一份結果，怎麼合理地合成一份？RRF 用名次而不用分數，規避了跨系統分數無法比較的根本問題。
Self-Reflection + LLM-as-Judge：讓 AI 評估自己的回答
用另一個 LLM 評估回答的準確度和品質，分數太低就重新生成，並自動加上適當的免責聲明。
Semantic Caching：語義相近的問題只跑一次 RAG
快取不只能比對完全一樣的查詢，語義相近的問題也能命中快取，省下整個 RAG pipeline 的執行。
SPLADE：比 BM25 更聰明的稀疏向量搜尋
BM25 只認識查詢裡出現的詞，SPLADE 能推斷相關詞彙並加入搜尋，在保持關鍵字搜尋精確性的同時獲得部分語義能力。
Text-to-SQL Router：精確查詢不走 RAG
「我今年完攀幾條」這種問題，RAG 語義搜尋永遠不如直接查資料庫。讓 LLM 識別意圖、提取參數，執行預定義 SQL 模板。
Vector Database 選型：Pinecone、Weaviate、Qdrant、Vectorize 怎麼選
向量資料庫的選型比 LLM 選型更受部署平台限制。先確認平台和規模需求，再看功能特性，不要只看 benchmark。