RAG 五階段:從流水線到會思考的檢索,以及我站上那個 Naive RAG
RAG 這兩年從『線性流水線』演化到『循環推理』,可以用五階段梳理:Naive、Advanced、Modular、Graph、Agentic。分水嶺是控制權從管線移交給 Agent,範式從 System 1 進到 System 2。回頭看 engineer-news 這個站的實作,其實還卡在 Naive RAG 邊界——這篇順便把它的下一步應該補什麼寫清楚。
Tag
6 篇文章
RAG 這兩年從『線性流水線』演化到『循環推理』,可以用五階段梳理:Naive、Advanced、Modular、Graph、Agentic。分水嶺是控制權從管線移交給 Agent,範式從 System 1 進到 System 2。回頭看 engineer-news 這個站的實作,其實還卡在 Naive RAG 邊界——這篇順便把它的下一步應該補什麼寫清楚。
上一篇拉高看 RAG 五階段全景,這篇拉近看實際想蓋一個 RAG 要面對的 5 個 infra 功課:文件入口解析、Chunking 上下文化、三路混合搜尋、Tensor Reranker、GraphRAG 語意鴻溝。每個功課都對照 engineer-news 現況,收尾給出對個人站的優先順序清單。
Agent 按需載入工具,本質就是把 RAG 的『先檢索再注入』套在 tool schema 上,差別只在檢索器從向量相似度換成 LLM 自己的推理。
PageIndex 用階層樹索引 + LLM Agent 推理取代向量 DB,在長文件場景(FinanceBench 98.7%)表現亮眼;本站的 Hybrid RAG 則以向量搜尋 + 關鍵字 fallback 在 Cloudflare edge 上跑,取捨完全不同。
不靠人類回饋,語言模型能不能自己發現並修正錯誤?主流做法是 contrastive decoding:刻意製造一個一定會答錯的狀態,把正常輸出與錯誤輸出相減,把生成結果往遠離錯誤的方向推——不動模型參數,只在 inference 階段套用。
LLM Wiki 不是查詢工具,是讓知識隨時間複利成長的架構——LLM 主動建構並維護一個 markdown 知識庫,而非每次查詢都重新從原始文件撈取。