Multi-Agent RAG:多個專業 Agent 協作的分散式檢索架構
單一 RAG Agent 處理所有查詢會遇到知識邊界和效能瓶頸。Multi-Agent RAG 把檢索任務分派給多個專業化 Agent,每個 Agent 有自己的知識庫和檢索策略,由中央 Orchestrator 協調合併結果。
單一 RAG Agent 處理所有查詢會遇到知識邊界和效能瓶頸。Multi-Agent RAG 把檢索任務分派給多個專業化 Agent,每個 Agent 有自己的知識庫和檢索策略,由中央 Orchestrator 協調合併結果。
傳統 RAG 把文件切成小 chunks 再檢索,但這造成資訊碎片化。LongRAG 利用 100K+ token 的長上下文模型,檢索更大的文件區段(整個章節甚至整份文件),減少碎片化同時保持檢索效率。
Speculative RAG 用小型專家模型從不同文件子集平行生成多個答案草稿,再由大型模型一次驗證選出最佳答案。論文在 PubHealth 上準確度提升 12.97 個百分點、延遲降低 50.83%——但這是最好的那一格,其他 benchmark 的幅度小很多。
Ollama 把 llama.cpp 包裝成 Docker 風格的 CLI + REST API,一行指令就能在本地跑 LLM。這篇從核心概念、安裝、API、硬體需求到 Modelfile 自訂,完整介紹這個工具適合什麼、不適合什麼。
RAG 已經從簡單的「搜尋+生成」演化成涵蓋十個世代的技術體系,2025 年後更進入 Agentic/Reasoning RAG 新階段。本文是系統化導航:從 Naive RAG 到 Multi-Agent/LongRAG 的十代演化、後十代 Agentic Era(Search-R1/RL 搜索、MCP 協議、GraphRAG 3.x、視覺直嵌)、檢索策略、Chunking、Embedding、Reranking、評估框架、可觀測性、成本優化。每個主題都有對應專文深入。
vLLM 用 PagedAttention 解決 KV cache 記憶體浪費問題,搭配 continuous batching 和 prefix caching,成為目前最主流的開源 LLM 推論引擎。
聊天機器人不只是接 API。對話狀態管理、記憶機制、Streaming、Guardrails、可觀測性、tech stack選型,每一層都影響使用者體驗。
好的 Prompt 不是一次寫出來的,而是迭代出來的。從最簡單的 prompt 開始,用真實 case 測試,分類錯誤類型,針對性修改。本文涵蓋 System Prompt 三段式結構、推理框架選擇、Few-shot 最佳化、Token 預算管理和六個常見錯誤。
複雜多跳問題,RAG 一次搜尋不夠。Agentic RAG 讓 LLM 評估結果是否充分,不夠就改寫查詢再搜一次,形成 ReAct 迴圈。
Embedding 模型的選擇直接影響 RAG 的搜尋品質。BGE-M3 的多語言訓練、1024 維向量、同系列 Reranker,是繁中 RAG 的實用選擇。
切太大找不準,切太小失去上下文,碰到表格更是全軍覆沒。Chunking 是 RAG 最被低估的環節,策略選錯,後面再多優化都是白費。
Bi-Encoder 太粗糙,Cross-Encoder 太慢,ColBERT 的 Late Interaction 在兩者之間找到平衡:token 級別的相互比較,但可以預先計算文件向量。
文件切塊後,每個 chunk 失去了它在原文件中的上下文。Contextual Retrieval 在索引時,用整份文件為每個 chunk 各自生成一段上下文再前綴進去,解決 chunk 孤島問題。
過濾條件太嚴格導致零結果?CRAG 自動放寬過濾條件重試,比讓 LLM 用通用知識瞎猜好多了。
向量搜尋的相似度分數不等於相關性,Cross-Encoder 用成對比較重新排序,把真正相關的文件推上來。
向量搜尋找相似,圖搜尋走關係。當問題需要跨多個實體的推理(岩場→路線→完攀者→難度分布),GraphRAG 比標準 RAG 更有優勢。
向量搜尋抓語義,BM25 抓關鍵字,兩者用 RRF 融合才能同時照顧模糊查詢和精確術語。
用 LLM 先生成一份「理想答案」,再把這份假設文件 embed 去搜尋,比直接搜尋查詢本身效果更好。
每次對話後,異步提取使用者可能的偏好和程度,下次查詢時自動個性化搜尋條件,不需要使用者手動設定。
只看相關性會讓結果都是同一條路線的不同描述,MMR 在相關性和多樣性之間取平衡,再疊加熱門度讓結果更實用。