Agentic Parsing：讓 Agent 決定怎麼解析文件
傳統文件解析用固定 pipeline 一體適用，但合約、財報、技術手冊各需不同策略。Agentic Parsing 讓 LLM agent 觀察文件後動態選工具——AgenticOCR 只解析需要的區域（視覺 token 省 70%+）、ParseBench 2,000 頁企業文件實測最佳方案也只拿 84.9%，沒有銀彈。
#rag
129 篇文章ColPali：跳過 OCR，直接用圖片做文件檢索
ColPali 把 PDF 每頁渲染成圖片，用 vision-language model 產生 patch-level multi-vector embedding，用 MaxSim 做 late interaction 檢索。表格密集的金融 PDF 上 recall 從 62% 跳到 84%，完全跳過 OCR 和 chunking。代價是儲存量 ~100 倍、需要 GPU、BM25 不可用。
Hierarchical Chunking + Auto-Merge：小 chunk 搜得準，大 chunk 讀得懂
小 chunk embedding 精準但缺上下文、大 chunk 上下文完整但 embedding 被噪音稀釋——Hierarchical Chunking 用多層索引（2048→512→128 tokens）配 Auto-Merge 演算法解決這個兩難：葉節點精準命中，命中密度超過閾值就自動回傳父節點給 LLM。HiChunk 實測 evidence recall 提升 12.7%，LlamaIndex 和 Haystack 都已內建。
Multi-hop Retrieval：當答案散落在多份文件裡
標準 RAG 一次檢索只找一組文件，但真實問題常需跨 2-4 份文件推理。IRCoT 開創交錯式檢索推理，PAR²-RAG 在四個基準上比 IRCoT 準確率高 23.5%，CompactRAG 把 LLM 呼叫壓到只有兩次。
Self-RAG：用 Reflection Token 讓模型自己決定要不要檢索
Self-RAG 在 LLM 裡訓練四種 reflection token（Retrieve / IsREL / IsSUP / IsUSE），讓模型在生成過程中自主決定何時檢索、檢索結果是否相關、生成是否有據可查。ICLR 2024 Oral（top 1%），7B 模型在多個 QA benchmark 超越 ChatGPT 和 Llama2-chat + RAG。代價是必須 fine-tune，無法用在 API-only 模型。
Table Serialization：表格該怎麼轉成文字才能讓 RAG 找到
Markdown-KV 格式在 LLM 理解準確度上達 60.7%，比 CSV 的 44.3% 高出 16 個百分點。但檢索用途的最佳格式不同於 LLM 理解用途——metadata prepend + row-wise key-value 是目前表格 RAG 的最佳組合。
AI Agent GitHub Digest — 2026-09-02
openclaw/openclaw 這款自架個人助理已經衝上 38 萬星，用單一 Gateway 串起 WhatsApp／Telegram／Slack 等聊天管道；同一週 NVIDIA 端出 SkillSpector，專門掃描 Claude Code／Codex／MCP skill 裡的 71 種漏洞模式，研究指出 26.1% 的 skill 有漏洞、5.2% 疑似惡意。另外 stablyai/orca 把多 agent 平行開發做成完整 IDE，VectifyAI/PageIndex 則用推理式樹狀索引挑戰「RAG 一定要向量資料庫」的預設。claude-code v2.1.257 新增 Containment Escape 安全規則，agno v3.0.5 把 embedding 失敗從默默吞掉改成如實回報。
Ask AI 明明有課程地圖，為什麼列不完整：Catalog Query 的召回與收斂事故
「有哪些課程文章」第一次觀測被舊快取干擾；真正未命中的 request 已找回四所大學課程地圖，卻因三輪 Writer／Critic 重試花了 51.169 秒。修正 catalog 專用檢索與 review 契約後，一次未命中快取的 production observation 在 26.821 秒內通過 q21。
Ask AI 怎麼找到文章：Planner、Hybrid Retrieval 與 Retry
Ask AI 先由 Planner 抽出 intent、complexity 與 1–4 個搜尋詞，再依查詢型態走 metadata、BM25、Vectorize 與 RRF；第二輪搜尋會加入 Critic gaps，並關閉第一次才允許的 BM25 short circuit。
Ask AI 的文章怎麼進知識庫：Chunk、D1 FTS5 與 Vectorize
Ask AI 的 production 索引分兩階段：先用 source hash 增量更新 D1、post_chunks 與 FTS5，再以 embedding checkpoint 和 delete queue 讓 Vectorize 非同步追上；兩邊不是同一個 transaction。
Ask AI 的問題怎麼走完整條 RAG 管線：UI、API、Agent 與來源卡片
Ask AI 把一次提問拆成 UI、`/api/chat`、Planner、Research、Writer、Validation、Critic 與 Related 八段；回答文字、參考來源和延伸閱讀各有不同的產生與顯示條件。
Ask AI Retrieval Eval 怎麼做：Golden Contract、Fixture、Live Run 與證據邊界
Ask AI 把 golden contract、offline fixture、live SSE output 與 production observation 分開保存。fixture 全綠只證明 harness 可重現；public sources 可以量 expected-source recall，不能拿來宣稱看過 hidden ranked chunks 或 model-graded faithfulness。
Ask AI 上線後怎麼查問題：SSE、Trace、Cache、Checkpoint 與 Shadow
Ask AI 同一次請求有五種不同證據：公開 SSE、Langfuse trace、D1 log、semantic cache 與 hidden shadow run。它們看見的資料不同，單看任一層都不能還原完整 retrieval context。
Ask AI 何時才顯示來源：Validation、Critic、降級與 Source Gate
Ask AI 找到文章，不代表畫面就該顯示來源。回答要先通過 Markdown／URL 的確定性驗證，再通過 Critic 的相關性、意圖與 groundedness 檢查；任一門檻失敗，來源卡片就不送到前端。
Ask AI 怎麼把證據寫成答案：Writer Context 與 Citation Contract
Writer 預設只讀 factual query 的前 8 筆或 recommendation 的前 12 筆候選證據，引用必須使用候選集合中的 exact `source_url`；檢索為空或被判為 weak 時，prompt 要求拒絕用模型常識補答案。
Cloudflare Agent Memory 怎麼用：把 agent 記憶和 RAG 文件分開
Agent Memory 是 Cloudflare 的 private beta 服務，用來讓 agent 跨對話記住使用者、團隊、專案與任務脈絡。它適合存 facts、events、instructions、tasks；RAG 文件、產品資料、檔案和 audit log 仍應該放在 AI Search、Vectorize、D1 或 R2。
Cloudflare AI app 資料怎麼放：D1、R2、Durable Objects 的分工
AI app 不該把 conversation、artifact、memory、retrieval document、lock、eval trace 全塞進同一個 storage。D1 適合查詢與產品資料，R2 適合大型檔案與 artifact，Durable Objects 適合具名協調、WebSocket、per-session state；Agent Memory / AI Search / Vectorize 則分別處理記憶與檢索。
Cloudflare AI Stack 導讀：在 Workers 上做 AI、RAG 和 agent
Cloudflare AI Stack 這條系列回答 AI app 的基礎設施問題：模型怎麼跑、gateway 怎麼控、RAG 怎麼做、agent 怎麼持續執行、memory 怎麼治理、browser/sandbox/secrets 怎麼接進產品。
Cloudflare Vectorize 怎麼用：自己掌控 RAG Retrieval 的時候
Vectorize 是 Cloudflare 的向量資料庫。AI Search 適合先把 RAG pipeline 交給平台；Vectorize 適合你要自己控制 chunking、embedding、metadata filter、hybrid retrieval、重新索引與降級策略。
Cloudflare AI Search 怎麼用：資料來源、混合檢索與 Workers 綁定的完整解析
前身 AutoRAG 的託管搜尋原語：丟文件進內建儲存或綁 R2／網站，自動走 Markdown 轉換、切分與向量加 BM25 索引，透過 hybrid 加 RRF 加 rerank 檢索，並以 namespace 與 instance 兩種綁定或 REST 與 MCP 在 Worker 與 Agent 內查詢。
問「我想找入門的ai課程」卻回 0 筆？RAG 中文分詞與資料鏈路脫節除錯實戰
在 Ask AI 輸入「我想找入門的ai課程」顯示搜尋文章 0 筆並觸發拒答，底部的延伸閱讀卻精準推薦相關文章。第一輪修正中文斷詞、LIKE fallback 與 Vectorize 資料鏈路；第二輪再補漢字＋數字短詞、文章 metadata 檢索，以及只在 Validation／Critic 通過後顯示來源。
Embedding：模型怎麼把文字變成可以計算的向量
模型不懂文字，只懂數字。Embedding 把每個 token 對應到一組幾百維的向量，意思相近的詞在向量空間裡距離相近。這是搜尋、RAG、分類背後共用的基礎機制。
Fine-tuning vs RAG：什麼時候該教模型、什麼時候該幫模型查資料
資料常更新、需要引用來源 → RAG。需要統一風格、要跑在小裝置上 → fine-tuning。實務上很多系統兩者都用：fine-tune 一個懂你領域語言的小模型，再用 RAG 補上最新資料。
搜尋只回 10 筆的解法：Cloudflare D1 FTS5 與 Hybrid Search 中文召回實戰
查「認證」只有 10 筆，149 篇裡 41 篇命中被漏掉：D1 FTS5 的 unicode61 對 2 字中文失效、本地 chunks_fts 0 筆、加上硬上限 12 的共同結果；用 LIKE fallback 與拆字 OR 先把召回補回來，再補 trigram 重建與分頁。
Agentic / Reasoning RAG：從 Search-R1 的 RL 多輪搜索到 Deep Research 與 MCP 的推理×檢索新範式
2025 年的 RAG 不再是「檢一次、生成一次」。Search-R1 用 RL 讓模型在推理中自主多輪搜索，REX-RAG/AlignRAG 補上策略與對齊的分支，OpenAI Deep Research 把整條鏈產品化，MCP 則把檢索泛化為統一的工具調用。本文拆開設計哲學、與舊世代的取捨、以及何時該用這套新範式。
圖譜 RAG 怎麼選：GraphRAG v3.1.2、LightRAG 與 HippoRAG 2 的設計、成本與選型
同樣是「知識圖譜 + 檢索」，Microsoft GraphRAG v3.1.2 用重索引換全局總結能力，LightRAG 用 dual-level 與增量把成本砍下來，HippoRAG 2 用 PPR 把 RAG 做成可持續增長的記憶；這篇按部件拆設計取捨，含四種查詢、索引流程與選型表。
Late Chunking vs Contextual Retrieval：先編碼後切塊的零成本上下文 vs LLM 前置生成的精準度交易
Anthropic Contextual Retrieval 用 LLM 為每塊生成 50-100 token 前置上下文把失敗率從 5.7% 壓到 1.9%（含 rerank），成本約 $1.02/1M tokens；Late Chunking 先以 32K 長上下文模型全文件編碼再切塊 mean-pool，零額外 LLM 成本，取捨在窗口、延遲與文件結構。
2024 AI 頂會導讀：自然語言處理篇
2024 年的 NLP 頂會在 LLM 全面統治下重新定義自己：ACL 把開放科學列為年度主題、七篇 Best Paper 有四篇在問語言模型的根本能力邊界；EMNLP 則把焦點轉向多語言與跨文化，Best Paper 從語音表徵做到梯度可解釋性。投稿量持續爆炸（ACL+EMNLP 合計破萬），但社群真正焦慮的不是數量，而是當 LLM 能做幾乎所有 NLP 任務時，NLP 研究本身還剩什麼。
Cohere——RAG 原生的異類：Command、Embed、Rerank、Aya 四支柱怎麼選
Cohere 是唯一把生成、檢索、重排、多語言四條線都做成產品的模型家族。Command A 111B 以兩張 GPU 跑 256K 上下文、Embed v4 支援圖文混合檢索、Rerank v4 32K 處理半結構化資料、Aya 覆蓋 101 種語言——四件套為 RAG 而生，這篇拆開每一塊的定位、授權與選型。
Amazon Bedrock 深入介紹：把模型 API 放進 AWS 治理邊界
Amazon Bedrock 不只是代售多家模型 API；它把模型呼叫、IAM、Region、Knowledge Bases、Guardrails 與 CloudWatch 串成同一套 AWS 控制面。它最適合已在 AWS 上、治理成本比最低 token 單價更重要的團隊。
Chroma 向量資料庫完整指南：從本機 RAG 到分散式檢索
Chroma 用 collection 統一管理 embedding、文件與 metadata；本機可嵌入 Python，單機版採 HNSW，分散式版則以物件儲存、SSD 快取與 SPANN 拆分運算和儲存。
Cognee 完整介紹：把文件變成 Agent 可查詢的知識圖記憶
Cognee 是資料到 AI memory 的 pipeline：用 relational store 保存來源與 provenance、vector store 找語意相近內容、graph store 表達 entity 關係，再以 remember、recall、improve、forget 管理生命週期。
CS124 Week 4 Information Retrieval：從倒排索引、tf-idf 到 RAG 的檢索底座
Week 4 從倒排索引建立候選集，以 tf-idf 與 cosine similarity 排序，再把檢索結果接到生成模型；PA3 要求實作的不是聊天介面，而是 RAG 前半段可檢查的搜尋核心。
CS224N 第 10 講：RAG 與 Language Agents 的六個元件
第 10 講從問答與 RAG 進入 language agents，再拆成推理規劃、記憶、工具、資料與評估；agent 不是單一模型，而是模型與外部狀態之間可被逐步檢查的迴圈。
Stanford CS224V 第 5 講：WikiChat 的七階段 RAG 如何逐條攔下幻覺
WikiChat 不把檢索結果直接交給一次生成，而是形成查詢、檢索、過濾、生成、拆主張、再檢索查核與移除無根據內容，並把檢索與事實性分開評估。
Stanford CS224V 第 2 講：STORM 與 Co-STORM 怎麼把搜尋變成知識策展
STORM 用觀點引導的提問、模擬訪談與大綱建立改善研究廣度；Co-STORM 再把人放進迴圈，讓探索未知問題與共同編修成為系統的一部分。
Dify 低程式碼 Agent 平台：從 Workflow 實作到 AI 應用發布
Dify 把模型、Knowledge、視覺化 Workflow、Agent、Plugin 與應用 API 放在共同 workspace；本文會實作一條可測試、發布並由 API 呼叫的最小 Workflow，再說明何時才該換成 Agent。
Haystack 深入介紹：用 Component 與 Pipeline 組出可測試的 RAG
Haystack 把 indexing、retrieval、generation 與 evaluation 都做成可替換的 Component，再用 directed multigraph Pipeline 串接；適合要把 RAG 流程當成程式資產測試、版本化與部署的 Python 團隊。
Jina Reader 完整指南：把網頁轉成 Agent 可讀 Markdown
Jina Reader 把單一 URL 轉成適合 LLM 使用的 Markdown；真正上線時，還要控制渲染時機、正文範圍、token 上限與失敗回退。
LanceDB 深入介紹：把向量搜尋嵌進 Arrow 資料工作流
LanceDB 以 Lance 欄式格式保存向量、metadata 與多模態原始資料；OSS 可直接嵌入 Python、TypeScript 或 Rust 程序，資料放大或多人共用時再轉向分散式 Enterprise。
Milvus 向量資料庫深入介紹：從 Segment、索引到分散式維運
Milvus 把即時寫入、歷史查詢、索引建置與持久化拆成可獨立擴縮的元件，適合需要大量向量、持續更新與分散式維運的檢索服務；小型專案則常會為這套架構付出過多複雜度。
pgvector 深入介紹：把向量搜尋放回 PostgreSQL
pgvector 是 PostgreSQL extension，不是獨立向量資料庫；它用同一份資料模型、交易與維運工具承接精確或近似向量搜尋，代價是索引調校與水平擴充仍屬 PostgreSQL 問題。
私有語料搜尋的邊界與架構：先決定資料能去哪裡
私有語料管線的第一個決定不是選向量資料庫，而是列出資料分級、信任區、權限決策點與 freshness SLA；索引、模型和觀測系統都只能收到被允許的最小資料。
私有語料 Retrieval Eval 實測：先把繁中題庫變成可重跑的 benchmark
Repo 已有 20 題繁中／英文 golden dataset，但缺少文件層級 qrels、retrieval run、延遲原始值與執行 script；目前不能誠實報 Recall@k、MRR 或 nDCG 實測分數。本文把缺口整理成可重跑的評估契約。
從來源到索引：私有語料的同步與增量更新管線
私有語料同步的核心不是定時重抓，而是用 canonical ID 固定文件身分、用來源版本與 checksum 判斷變更、用冪等 upsert 寫入，並讓 tombstone 走完所有索引的刪除傳播。
R2R 深入介紹：把 Ingestion、Hybrid Search 與 RAG 包成 API
R2R 把文件匯入、hybrid search、knowledge graph、RAG、Agent 與權限包在 REST API 後面；適合已有產品前後台、只想補上 retrieval service 的團隊。
RAG 框架怎麼選：LlamaIndex、Haystack、RAGFlow、Dify、R2R 不是同一層產品
LlamaIndex、Haystack 是以程式碼為主的框架；RAGFlow、Dify 是帶管理介面的平台；R2R 則把檢索系統包成 API 服務。先決定團隊要保留多少 ingestion、retrieval 與營運控制權，再選工具。
RAGFlow 深入介紹：從文件解析、Chunk 檢查到可追溯回答
RAGFlow 把文件解析、chunk 人工檢查、retrieval test、聊天與引用放在同一套平台；適合 PDF、表格與版面複雜文件，但部署重量和平台狀態都高於 Python library。
表徵學習：對比學習、語意檢索與 RAG
第 16 章把表徵學習連到實際系統：對比目標塑造向量空間，語意檢索在其中找鄰居，RAG 再把取回內容交給生成模型。
Berkeley CS288（四）：Retrieval、RAG 與進階架構如何變成一個系統
13–14 組教材把模型接到外部知識；A3 要學生自行蒐集資料、標註 QA、建索引、做 ablation，並在 CPU 與延遲限制下交付 RAG。
LlamaIndex：它已經不是 RAG 框架了，而你可能還在照舊教學選它
LlamaIndex（GitHub 51,775 star，MIT，2026-08-21 實查）的重心已經從索引搬到 Workflows：獨立套件 llama-index-workflows 的 PyPI 週下載 281 萬，比傘狀套件 llama-index 的 197 萬還高。這篇拆核心抽象、跟自己刻 pipeline 的取捨，並實測它在繁中語料上的預設值——同樣的 chunk_size=1024，英文裝得下 4,645 字元，繁中只有 1,332。另附一個選型前必看的事實：TypeScript 版已封存停更。
Qdrant 完整指南：Collection、Hybrid Search 與自架維運
Qdrant 的核心不是把 embedding 存進去，而是先固定 vector schema、替高頻過濾欄位建 payload index，再用 dense + sparse query、租戶邊界、snapshot 與監控把檢索做成可維運的服務。
Stanford CS224V 導讀：2026 年才改名叫 Agentic AI，教的卻是拿形式方法治幻覺
CS224V 的課名在 2026-2027 學年才從 Conversational Virtual Assistants 換成 Agentic AI，但底下的東西沒換：把自然語言翻成形式語意、用 SMT 與知識圖譜約束 agent，而不是拼框架。閱讀清單十一篇 Mandatory 裡，七篇出自授課者自己的實驗室。投影片全公開，課程網站卻明講它們是刻意殘缺的。
Stanford CS329Z 導讀：先用 litellm 手刻一遍 agent，再讓 DSPy 把它收走
CS329Z 是 Stanford 2026 年秋季新開的三學分 agent 工程課，第一份作業要求先用 litellm 從零刻出 RAG、工具呼叫與 ReAct 迴圈，再用 DSPy 把同一批元件重寫一次並交出對照。課程網站架在公開的 GitHub repo 上，commit 紀錄顯示 8 月中作業從三份砍成兩份，被砍掉的那份是「Data for Agents」。
LLM Application Design 面試攻略：從 RAG 到 Agent 架構
LLM Application Design 是 2025-2026 面試最熱的新題型。核心考點：RAG pipeline 的 chunking/retrieval/reranking 設計、agent 架構的 tool-use 與 planning loop、context window 管理策略、guardrails 與 safety 設計、以及 LLM 應用的評估方法。面試官特別看重你有沒有踩過坑。
AI Agent Arxiv Digest — 2026-08-19
QUMem 用情節切分加三階段 agent 推斷使用者狀態，在 KnowU-Bench 整體成功率贏最強 baseline 4.6 個百分點；LENS 免索引邊查邊定位證據，證據召回率 84.8% 遠勝 ReAct 基線的 50.4%，索引過期情境下完全不掉分；Intent-Guided Decoding 在解碼期仲裁檢索內容與模型記憶，事實衝突基準最高帶來 65.4 個百分點的準確率增益
AWS GenAI Developer Professional（AIP-C01）備考路徑：整張考試都在考別人的模型怎麼整合
AIP-C01 是 AWS 唯一專攻 GenAI 應用開發的 professional 級證照，官方明確排除模型訓練、進階 ML 與特徵工程——它考的是把別人的基礎模型整合進生產系統。五章權重 31/26/20/12/11，最重的第 1 章有將近一半的技能點落在向量儲存與 RAG。2026 年 3 月的改版加入 Bedrock AgentCore，beta 已於 3/31 結束，更早的教材全部過期。官方規格：$300、180 分鐘、75 題（65 題計分）、及格 750、效期 3 年，考過會同時續掉 AIF-C01、MLA-C01 與 Data Engineer – Associate。
RAG 與檢索評估的考點交集：四張證照重複考什麼，還有一張大家以為它考、其實沒有
真正把 RAG 與檢索評估當考點的是四張：AWS AIF-C01（第 2、3 章合計 52%，RAG、向量儲存、FM 評估指標全在裡面）、AWS AIP-C01（第 1 章 31% 裡有 11 個技能點落在向量儲存與 RAG）、NVIDIA NCP-AAI（Knowledge Integration 10% ＋ Evaluation and Tuning 13%）、微軟 AI-500（Develop 30–35% 裡的「多 agent RAG 架構」）。Google PMLE 只貢獻一條 LLM-as-a-judge，而 Claude CCDV-F——那張大家最容易假設它考 RAG 的開發者證照——八個領域裡一條檢索考點都沒有，Eval 只佔 2.6%。附 AIF 與 AIP 的同廠雙級別對照、四家名詞對照表、獨有考點清單與練習專案。
Agents, Prompts, and RAG：一堂課教完之後，剩下的才是難的
BCG 的實驗發現一條「鋸齒狀邊界」：邊界內 AI 大幅提升顧問表現，邊界外 AI 讓結果更差，而人們會在方向盤上睡著。這一講也給了一個很有立場的判斷——盡可能避開 fine-tuning，因為等你調完，下一代模型已經打敗你 fine-tune 過的版本了。
概念界線：agent、workflow、RAG、MCP 到底差在哪
workflow 與 agent 的分界是「步數由誰決定」——開發者在設計時決定是 workflow，模型在執行時決定是 agent。依這個定義，今天大多數上線的 LLM 系統其實是 workflow。附 agent / RAG / MCP 的可操作判準。
RAG 的三種形態與 evaluator paradox
Standard RAG 取錯 chunk 就答錯，而且沒有任何機制會發現。Agentic RAG 補上自我檢查，但代價是 evaluator paradox——自我修正能力的上限，就是那個做評估的 LLM 判斷相關性的能力。
解析層：當結構要用模型推斷——而授權才是真正的選型軸
掃描件與複雜版面只能靠模型推斷結構。但 MinerU、Marker、Docling 的技術差距遠小於授權差距——MinerU 過 $20M 月營收要另談授權、Marker 的模型權重過門檻要付費、只有 Docling 是乾淨的 MIT。選型先看 LICENSE，再看 benchmark。
文件解析的三層階梯：轉換、抽取、解析，先選對層再選工具
把文件餵給 LLM 之前，最常見的錯誤不是選錯工具，是選錯層。結構已經在檔案裡的用轉換層（毫秒級），有文字沒結構的用抽取層，連文字都要推斷的才用解析層——anydoc 的 4.7ms 到 Docling 的 513.6ms 差 109 倍，多數人卻直接跳最貴的那層。
調整 agent 之後，怎麼嚴謹比較前後差異：從 golden set 到統計檢定
即使 temperature=0，LLM 輸出實測仍可能抖動 15%。要嚴謹比較 agent 調整前後，得靠凍結 golden set、每題跑 ≥3 次取平均、LLM-as-judge 盲評（pairwise 偏好翻轉率高達 35%）與配對統計檢定，而不是前後各問一遍看感覺。
Agent 怎麼決定「要不要查、查什麼、怎麼合」：Agentic RAG 的三個決策層
傳統 RAG 是固定管線「先查再答」；Agentic RAG 把檢索拆成三層決策：何時檢索（FLARE 用 token 機率、Adaptive-RAG 用複雜度分類器）、檢索什麼（HyDE / RAG-Fusion / 分解 / Step-back）、如何整合（RRF k=60 → cross-encoder rerank → 壓縮，Anthropic 實測失敗率 −67%）。關鍵反直覺：不必要的檢索會傷品質，「決定不查」是一級能力。
語意相似 ≠ 檢索相關：embedding 檢索系統性失靈的情境、偵測與補救
Cosine similarity 和 relevance 在一整類情境系統性背離：否定詞（NevIR 上多數 IR 模型 ≤ 隨機）、精確識別碼、數值門檻、邏輯組合（SoTA 模型在 LIMIT 上 recall@100 < 20）——其中一部分是單向量範式的理論上限，換大模型無解。補救順序：hybrid BM25 → reranker（Anthropic 實測 −67%）→ 上游 metadata 路由 → 領域微調 / multi-vector。
換更貴的 embedding 救不了繁中 RAG：三層失敗成因與補救順序
繁中 RAG 檢索失敗是三層疊加：embedding 的粒度缺陷（BGE/GTE 從 0.1B 到 7B 都在「炸鸡」這種簡單 query 上排錯）、簡中/英文語料主導造成的在地詞彙偏移（保費、不保事項對齊不可靠）、MTEB 中文榜是簡體導致選型訊號失真。修復是架構性的：OpenCC 正規化 → hybrid + jieba 斷詞 → reranker → 最後才是在地微調——而且一切前提是先建繁中專屬 eval set。
上傳檔案就自動 embedding 是個壞預設：Adaptive / Agentic RAG 與 Agentic Parsing 論文導讀
把『使用者上傳檔案就自動切 chunk、embedding』設為預設行為，等於替 LLM 預先做了一個它本來可以自己做的決定。從 Self-RAG (2310.11511)、Adaptive-RAG (2403.14403) 到 AgenticOCR (2602.24134) 這條學術線索，正在把『要不要 retrieve、要不要 parse、怎麼切 chunk』三層決策權，從 ingestion pipeline 往後推到對話時的 agent。
LLM agent 的 tool description 決定它怎麼選 tool：三個踩坑修法
把 tool description 從軟建議改成硬規則（白名單 + 後果說明），LLM 亂選 tool 的問題消失了；另外加 skip_signal=True 修掉 vector store 雙重 indexing。
Claude for Financial Services：拆解 Anthropic 的多 Agent 參考實作
Anthropic 開源了 12 個金融業 Agent + 11 個 MCP connector，最值得抄的不是 Agent 本身，而是『同一份 prompt 雙 runtime』和『純檔案擴充』的分層設計。
DeepSeek-OCR：把長上下文壓成圖片的 10× 壓縮實驗
DeepSeek-OCR 的論文題目是 Contexts Optical Compression — OCR 只是手段，真正驗證的是『把文字渲染成圖片再餵給 VLM』能達到 10× 壓縮且 97% 精度。這對長上下文 LLM 與 RAG 的 token 成本是質變。
Local Deep Research 導讀：本地優先的深度研究 Agent
Local Deep Research 是個本地優先、隱私導向的深度研究 Agent，用 LangChain + LangGraph 串起 20+ 搜尋引擎和 30+ 種研究策略，旗艦的 langgraph_agent_strategy 走 LLM 自主 tool-calling 路線，跟固定流程的 RAG graph 是兩種思路。
PageIndex：不做向量的 RAG，把長文件變成一本有目錄的書
PageIndex 不切 chunk、不做 embedding、不存向量，靠 LLM 推理一份 LLM 自己寫的目錄樹，在 FinanceBench 上由開發方自評拿到 98.7%。它解的不是向量 RAG 的同一個問題——是『在一份結構清楚的厚文件裡找對的那一節』。
36 小時建出法律合約 RAG：Weaviate Query Agent + ColQwen 架構拆解
用 Weaviate Query Agent + ColQwen 多向量模型，一個 prompt 在 36 小時內搭出生產等級的法律合約搜尋系統——這篇拆解它的架構邏輯、技術選擇，以及你真正需要注意的事。
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 用小型專家模型從不同文件子集平行生成多個答案草稿，再由大型模型一次驗證選出最佳答案。論文在 PubHealth 上準確度提升 12.97 個百分點、延遲降低 50.83%——但這是最好的那一格，其他 benchmark 的幅度小很多。
RAG 系統模式完整指南：從 Naive 到 Multi-Agent 的十代演化與實戰導航
RAG 已經從簡單的「搜尋+生成」演化成涵蓋十個世代的技術體系，2025 年後更進入 Agentic/Reasoning RAG 新階段。本文是系統化導航：從 Naive RAG 到 Multi-Agent/LongRAG 的十代演化、後十代 Agentic Era（Search-R1/RL 搜索、MCP 協議、GraphRAG 3.x、視覺直嵌）、檢索策略、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 評估框架與工具選型：Promptfoo、RAGAS、DeepEval、TruLens
RAG 評估沒有指定工具的業界標準；先把 retrieval、generation、operation 分開量，再依技術棧選 Promptfoo、RAGAS、DeepEval 或 TruLens。
RAG 常見失敗模式：10 種問題和對應的解法
RAG 系統出問題，90% 的情況是這 10 種之一。先識別是哪種失敗模式，再找對應的解法，比盲目優化有效很多。
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 數）才能真正控制成本。
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）動態切換。