36 小時建出法律合約 RAG：Weaviate Query Agent + ColQwen 架構拆解
用 Weaviate Query Agent + ColQwen 多向量模型，一個 prompt 在 36 小時內搭出生產等級的法律合約搜尋系統——這篇拆解它的架構邏輯、技術選擇，以及你真正需要注意的事。
#rag
56 篇文章knowledge-pipeline：六層管線幫你的 RAG 做品質管控
一個六層確定性管線，從 URL 擷取到向量嵌入全自動處理，透過八維度評分系統在資料進 RAG 之前就篩掉垃圾。
MarkItDown：把任何檔案餵給 LLM 之前，先讓它變成 Markdown
Microsoft 開源的輕量工具，把 PDF、Office、圖片、音訊等格式統一轉成 Markdown，專門為 LLM pipeline 設計。
quidproquo 部落格改進完整規劃：從內容、技術、RAG 設計到 Harness 基礎建設
用自己寫的 30+ 篇 RAG/Agent 文章交叉檢視部落格現狀，整理出橫跨內容品質、網站技術、RAG 設計修正、Harness 基礎建設、AI Agent 應用的完整改進清單，按優先級排列、不分階段。
Cloudflare Workers AI binding 全貌：不只是 run()
env.AI 這個 binding 不是只有 run()。它還掛了 toMarkdown（文件轉 Markdown）、autorag（託管 RAG）、gateway（外部 provider 代理）、models（metadata 查詢）。認識這四組方法，才能在 Workers 上把 Cloudflare 當完整的 AI 平台用。
LLM 知識庫的三種模式：知識庫、經驗庫、部落格
Andrej Karpathy 提出用 LLM 編譯個人知識 wiki 的框架——收集原始資料、LLM 編譯成 .md wiki、對 wiki 做 Q&A、輸出歸檔回 wiki。本文比較三種實踐路線：Karpathy 的知識庫模式、社群的經驗庫模式、以及 quidproquo 的部落格模式。
AI-Ready Content：把網站變成 AI 可讀的資料來源，完整指南
2025–2026 年，網站不只要給人看，還要給 AI 看。從 llms.txt、Schema Markup、GEO 到 RAG ingestion pipeline，這篇整理了讓你的網站變成 AI 可用資料來源的完整技術地圖。
「推薦下一條」和「推薦類似的」不是同一件事 — RAG 推薦系統的意圖消歧
攀岩 RAG 系統中「推薦下一條路線」（progression）和「推薦類似路線」（similarity）被同一個 hasSimilarRouteIntent() 函式混為一談，導致推薦品質崩壞。解法是 Regex Fast Path + LLM Fallback 的兩階段意圖分類。
RAG 多實體查詢：當使用者一次丟五條路線，系統只看到第一條
RAG 系統的 extractRouteReference() 用 for...return 只抓第一個匹配，使用者給了五條完攀紀錄卻只用到一條。解法從 rule-based 多實體擷取、user profile aggregation 到 embedding centroid，分三層遞進實作。
當 Vector Search 把名字當難度搜：RAG 系統的 Attribute Conflation 問題
查詢「美人照鏡 5.11b，推薦類似難度路線」，結果回來的全是名字像的路線而不是難度像的。根因是 dense embedding 把多個屬性壓進同一個向量，名稱的稀有性壓過了難度信號。解法：metadata pre-filter + query rewriting + score fusion 三層防線。
LangGraph：用圖結構管理 Agent 工作流程
LangGraph 把 LLM 工作流程建模成有向圖，解決多輪迭代、條件分支、平行執行這些用線性 pipeline 做很痛的問題。
Context Engineering：為什麼你的 AI Agent 問題出在資訊，不在模型
Context Engineering 是 2025 年取代 Prompt Engineering 的核心概念：重點不再是「怎麼問」，而是「給什麼資訊」。把對的資訊在對的時機送進 context window，比換更強的模型更有效。這篇整理了定義、四大策略、實作技巧和常見失敗模式。
Agent Memory 系統：從 RAG 到 Read-Write 記憶的演化
RAG 是唯讀的。Agent Memory 讓 AI 不只能讀，還能寫入和持久化資訊。三種記憶類型：Procedural（行為模式）、Episodic（時間事件）、Semantic（事實知識），構成完整的認知記憶系統。
Multi-Agent RAG：多個專業 Agent 協作的分散式檢索架構
單一 RAG Agent 處理所有查詢會遇到知識邊界和效能瓶頸。Multi-Agent RAG 把檢索任務分派給多個專業化 Agent，每個 Agent 有自己的知識庫和檢索策略，由中央 Orchestrator 協調合併結果。
LongRAG：用長上下文模型重新思考 RAG 的 Chunking 策略
傳統 RAG 把文件切成小 chunks 再檢索，但這造成資訊碎片化。LongRAG 利用 100K+ token 的長上下文模型，檢索更大的文件區段（整個章節甚至整份文件），減少碎片化同時保持檢索效率。
Speculative RAG：用小模型平行打草稿，大模型一次驗證
Speculative RAG 用小型專家模型從不同文件子集平行生成多個答案草稿，再由大型模型一次驗證選出最佳答案。準確度提升最高 12.97%，延遲降低最高 50.83%。
RAG 系統模式完整指南：從 Naive 到 Multi-Agent 的十代演化與實戰導航
RAG 已經從簡單的「搜尋+生成」演化成涵蓋十個世代的技術體系。本文是系統化導航：從 Naive RAG 到 Multi-Agent RAG 的十代演化、檢索策略、Chunking、Embedding、Reranking、評估框架、可觀測性、成本優化。每個主題都有對應專文深入。
Agentic RAG：讓 LLM 自己決定要不要再搜尋一次
複雜多跳問題，RAG 一次搜尋不夠。Agentic RAG 讓 LLM 評估結果是否充分，不夠就改寫查詢再搜一次，形成 ReAct 迴圈。
BGE-M3：為什麼這個 Embedding 模型適合繁體中文 RAG
Embedding 模型的選擇直接影響 RAG 的搜尋品質。BGE-M3 的多語言訓練、1024 維向量、同系列 Reranker，是繁中 RAG 的實用選擇。
Chunking 策略：切塊方式決定 RAG 能不能找到答案
切太大找不準，切太小失去上下文。Chunking 是 RAG 最被低估的環節，策略選錯，後面再多優化都是白費。
ColBERT：向量搜尋的第三條路
Bi-Encoder 太粗糙，Cross-Encoder 太慢，ColBERT 的 Late Interaction 在兩者之間找到平衡：token 級別的相互比較，但可以預先計算文件向量。
Contextual Retrieval：幫每個 Chunk 加上「這段在說什麼」
文件切塊後，每個 chunk 失去了它在原文件中的上下文。Contextual Retrieval 在索引時為每個 chunk 注入文件級別摘要，解決 chunk 孤島問題。
CRAG：檢索失敗時，自動放寬條件重試
過濾條件太嚴格導致零結果？CRAG 自動放寬過濾條件重試，比讓 LLM 用通用知識瞎猜好多了。
Cross-Encoder Reranking：讓最相關的文件排到前面
向量搜尋的相似度分數不等於相關性，Cross-Encoder 用成對比較重新排序，把真正相關的文件推上來。
GraphRAG：把知識做成圖，讓 LLM 沿著關係推理
向量搜尋找相似，圖搜尋走關係。當問題需要跨多個實體的推理（岩場→路線→完攀者→難度分布），GraphRAG 比標準 RAG 更有優勢。
Hybrid Search：用 BM25 + 向量搜尋彌補彼此的盲區
向量搜尋抓語義，BM25 抓關鍵字，兩者用 RRF 融合才能同時照顧模糊查詢和精確術語。
HyDE：用假設答案提升向量搜尋的 Recall
用 LLM 先生成一份「理想答案」，再把這份假設文件 embed 去搜尋，比直接搜尋查詢本身效果更好。
RAG 個性化：從對話中學習用戶偏好
每次對話後，異步提取用戶可能的偏好和程度，下次查詢時自動個性化搜尋條件，不需要使用者手動設定。
MMR + 熱門度加權：讓推薦結果既相關又多樣
只看相關性會讓結果都是同一條路線的不同描述，MMR 在相關性和多樣性之間取平衡，再疊加熱門度讓結果更實用。
Modular RAG Pipeline：把 RAG 設計成可組合的 DAG
RAG 不是固定的三步流程，而是一組可以動態啟用、跳過、重排的步驟。Pipeline as Code 讓系統在不重新部署的情況下調整行為。
Multi-Query Expansion：一個問題，多個角度搜尋
複雜查詢只用一個向量搜尋容易漏掉相關文件，讓 LLM 改寫成 3-5 個子查詢並行搜尋，召回率顯著提升。
Multimodal RAG：把圖片也納入知識庫
攀岩路線有大量圖片資訊（路線圖、岩壁照片），純文字 RAG 遺漏了這些。Multimodal RAG 讓圖片也能被搜尋和理解。
RAG 的三個世代：從 Naive 到 Modular
Naive RAG 夠用但有很多問題，Advanced RAG 針對性修補，Modular RAG 重新架構讓系統可組合、可配置。了解三個世代，才能理解現代 RAG 系統為什麼長這樣。
Plan-and-Execute：先規劃再執行的 RAG 模式
對複雜問題，先讓 LLM 規劃出需要哪些資訊、分幾步取得，再按計畫執行，比邊搜邊想更系統化。
Query Classification：讓 RAG 知道該怎麼回答這個問題
不是所有問題都需要 RAG。用 LLM 先分類查詢類型，再決定執行路徑，節省成本又提升準確度。
RAG A/B 測試：怎麼科學地比較兩個 Pipeline 配置
「加了 Cross-Encoder 之後感覺好多了」不是科學的評估。A/B 測試讓你知道改動是否真的有效，效果多大，在哪類查詢上有效。
RAG 冷啟動：沒有資料時怎麼讓系統能用
RAG 系統需要資料才能回答問題，但一開始就沒有資料。冷啟動策略決定了系統從空到可用的路徑。
RAG 成本優化：把每次查詢的花費壓到最低
RAG 系統的成本來自 LLM token、Embedding API、向量搜尋。每個環節都有可以壓成本的地方，但要確認優化沒有犧牲太多品質。
RAG 評估框架：RAGAS、DeepEval、TruLens 怎麼用
RAG 系統的品質很難用直覺評估。RAGAS、DeepEval、TruLens 提供了系統化的指標框架，讓你知道是哪個環節出問題。
RAG 常見失敗模式：10 種問題和對應的解法
RAG 系統出問題，90% 的情況是這 10 種之一。先識別是哪種失敗模式，再找對應的解法，比盲目優化有效很多。
RAG Guardrails：在輸入和輸出加一道防線
RAG 系統面對的攻擊不只是技術層面的，Prompt Injection 和 Jailbreak 是真實威脅。輸入輸出都需要獨立的防護層。
RAG 可觀測性工具全景：2026 年的選擇
自己寫 trace 夠用，但開源工具讓你少做很多事。Langfuse、Phoenix、LangSmith 各有定位，選哪個取決於你對自架、開源、整合複雜度的取捨。
RAG Observability：黑盒子變透明的 17 步追蹤
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 數）才能真正控制成本。
RAG vs Fine-tuning：不是非此即彼
RAG 和 Fine-tuning 解決的是不同問題。RAG 給模型新知識，Fine-tuning 改變模型的行為風格。大多數情況是兩者都用，而不是選一個。
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。
攀岩社群為什麼需要 AI？NobodyClimb 的實驗與學到的事
NobodyClimb 用 RAG 解決攀岩路線資訊分散的問題，配額制度與社群參與度綁定，Cloudflare Workers AI 讓推論成本趨近於零。
NobodyClimb：用 Cloudflare 全端打造攀岩社群平台
一個攀岩社群平台，從 Web、Mobile 到 AI 問答全部跑在 Cloudflare 上，沒有獨立伺服器。
NobodyClimb AI 架構：在 Cloudflare Workers 上打造 20 節點 RAG Pipeline
用 Cloudflare Workers AI（gemma-3-12b-it + bge-m3）打造可動態組裝的 RAG pipeline，14 個基礎 step + 6 個 LangGraph 專屬節點，三種策略圖（Baseline / Agentic / Plan-Execute）動態切換。