RAG 答對了，也可能洩漏別人的資料
每次檢索都帶可信使用者權限，在資料進入模型前過濾；快取命中與撤權後也要重新驗證資料依賴。
#rag
170 篇文章切塊與索引：要切多大、用什麼搜，以及怎麼知道選對了
建索引要做三個決定：切塊的單位、用關鍵字還是向量還是兩者都用、用哪個 embedding 模型。這三個都是半永久的選擇，改了就要整批重建。研究的建議偏保守：語意切塊沒有一致比較好，按句子或按文件結構切通常就夠；overlap 的效果很小、依設定而定。繁體中文的一項研究裡，正確段落排在第一名的比例，只用向量搜尋 57%，關鍵字搜尋 76%，兩者混合 81%。不要憑感覺選：用 order 11 的測試題比較兩種設定，一次只改一件事。
評估與上線：怎麼知道 AI 知識庫好用，上線後怎麼持續變好
評估要分兩層：檢索有沒有找到出處段落，回答有沒有依據段落、答得對不對。只看回答會被騙：一項研究發現，給的資料不足以回答時，模型仍有三到六成答對，靠的是它自己的知識，換成只有你們公司答得出的問題就會壞。用 order 11 的測試題兩層都評，越權題和答不了的題也要評；LLM 當評審要跟人工抽樣校準。上線後，把轉人工、被抱怨的對話整理成失敗案例，交回文件負責人修，再加進測試題。
結構與 metadata：除了內文，每份文件還要記哪些欄位
metadata 有三種用途：回傳給人引用、參與搜尋、檢索前過濾；型號、年份、地區這種精確條件要放在欄位裡，一項研究把公司和年份寫在每段前面，前五名找到正確段落的比例從 33% 升到 55%。過濾用的欄位從來源系統取值、用固定選項、日期存成數字，不要讓 LLM 自由產生。
解析與清洗：PDF、表格、掃描檔轉成文字時，哪些東西會悄悄壞掉
文件轉成文字時，壞掉的地方通常不會報錯：多欄的段落接錯順序、表格的合併儲存格被攤平、頁首頁尾混進內文、掃描檔的錯字、圖片和刪除線消失。OCR 的準確率高也不代表 RAG 答得好：一項研究裡，帶刪除線和顏色標記的文件 OCR 分數 82.9%，問答卻只答對 52.8%。比起換工具，怎麼切塊影響更大：同一份轉換結果，改成依標題階層切塊並附上標題路徑，表格題從 66.6% 升到 99.8%。所以解析完一定要抽檢，對照原檔看這幾種壞法。
權限：怎麼確保 AI 不會把 A 部門的文件答給 B 部門
權限要在檢索時就過濾：每段文字帶著能看它的群組，查詢帶著使用者的群組，不符合的根本不進候選，而不是讓模型讀了再叫它別說。AI 不會新增權限，但會讓本來分享得太寬的文件變得一問就找得到，所以上線前要先整理過度分享。權限改了，索引不一定跟著改：有的連接器只在完整爬取時更新權限，最多延遲一天。過濾也有代價：條件很嚴時，某些向量資料庫會回傳不足的結果。上線前寫一題越權測試放進測試題。
安全：收進知識庫的文件，會不會洩漏個資或反過來指揮 AI
收進知識庫的文件可能夾著個資，也可能藏著寫給 AI 的指令；後者已在 Slack AI 和 Microsoft 365 Copilot 上被示範過。只在系統提示叫模型忽略效果很小，比較穩的是入庫時加個資與指令兩道關卡，再限制模型能做的動作。偵測工具都不保證找全，每一層都只是降低風險。
盤點來源：哪些文件該進 AI 知識庫，信哪個版本
共用硬碟整包匯進去，是 AI 知識庫最常見的開頭，也是最常見的錯。舊版和現行版一起被撈到時，模型會混在一起答：一項研究裡，現行資料明明有被撈到，旁邊只多一段過時資料，總分就降了兩成多。先做一張來源盤點表，記下每個來源的負責人、更新頻率、存取限制和處理方式；第一批只收一個工作流程、治理良好的來源；同一份文件只收現行版，舊版要收就標版本與失效日期。匯入之後核對檔案數，因為有的連接器權限不足時一個檔案都不匯，也不報錯。
更新與刪除：文件改了、刪了，AI 知識庫怎麼跟上
文件改了或刪了，索引不會自己跟上。比較穩的增量同步是：用內容雜湊判斷哪些文件變了，只重做變了的；刪除要清到每一個存放處，包括全文索引和向量庫。很多工具預設不處理刪除，刪除和更新也可能要過一段時間才生效。為什麼要刪乾淨：一篇預印本把一份過時文件放進上下文，兩個小模型原本答對的醫學題有三到四成被翻錯；要求模型「照文件回答」時，比例升到三分之二到四分之三。
給 AI 讀的知識庫差在哪：動手前先寫測試題
人看得懂的 wiki，AI 還是可能答錯：它看到的是被切出來的幾段文字，看不到導覽、標題層級和前後文。所以動手建 RAG 之前，先寫一份測試題：每題附上答案和出處段落，並刻意放幾題文件答不了的。Azure 的 RAG 指南把這一步跟內容分析平行做；一項研究發現，只用 AI 生成的題目評估，會高估檢索表現 29 到 37 個百分點，所以要混入真實使用者的問題。知識庫小於約 500 頁時，也可以先不做 RAG，整份放進提示裡。
知識庫怎麼建：個人筆記、團隊 wiki、AI 知識庫的四個共同問題
個人筆記、團隊 wiki、給 AI 用的知識庫，差在讀者是誰：未來的自己、同事、模型。三種都要回答收什麼、怎麼整理、怎麼找到、誰來維護。個人收藏的研究發現，「找」多半是找回自己看過的東西；企業 wiki 的研究則看到，負責整理或代寫的人一離開，內容就開始變亂、過時。
對比學習與語意檢索：沒有標籤，怎麼學出能比相似度的向量｜Stanford CS229 第 13 堂
這堂課把 SimCLR 損失拆成一張 B×B 相似度矩陣：每一列做一次 softmax 分類，答案是對角線那一格。對角線被拉高、其餘被壓低，模型不需要標籤就學到「相似的東西向量相近」。後半堂用同一組向量做語意檢索，再接到 RAG。
Liquid AI LFM：裝置端推理與 Agent 工作流
LFM2.5-2.6B 是裝置端 hybrid 推理模型；官方權重與 OpenRouter 端點的上下文限制不同，部署前也要核對授權與資料條款。
pplx-embed-v2-late：免 OCR 搜 PDF 頁面的開源 late-interaction 模型
Perplexity 10 月 7 日以 MIT 授權開源 0.6B 與 9B 兩個 ColBERT 式多模態嵌入模型，每個 token 一個 128 維向量、用 MaxSim 評分，可直接檢索 PDF 頁面圖片。9B 在 MADQA 拿到 92.4%（自家測試，搭配 Gemini 3.5 Flash agent），代價是索引大小隨文件長度線性成長。
pplx-embed——Perplexity 的嵌入模型家族：單向量、上下文、late interaction 三條線怎麼選
pplx-embed 是 Perplexity 2026 年 2 月起陸續釋出的嵌入模型家族，分三條線：v1 單向量（0.6B／4B，API 每百萬 token $0.004／$0.03）、context 上下文嵌入（v1 4B 與 9B 預覽版）、v2-late 多向量（0.6B／9B，可直接搜 PDF 頁面圖片）。三條線解決不同問題，不是新舊取代。
AWS Machine Learning Engineer Associate（MLA-C02）備考路徑：107 條技能裡有 45 條是新加的
MLA-C02 自 2026 年 9 月 29 日起取代英文版的 MLA-C01。四章權重 28 / 24 / 24 / 24，章節名稱都加上了 AI 或 FM：官方對照表列出 45 條新增技能，內容是向量資料庫、embedding、RAG、基礎模型的選擇與微調、agent 的部署與監控，另刪掉 7 條。目前是英文 beta（考試代碼 ME1-C02、170 分鐘、85 題、$75）；正式版依考試指南是 65 題、及格 720、效期 3 年，日文、韓文、簡中要等正式上線，沒有繁體中文。
微軟 AI-200（Azure AI Cloud Developer）備考路徑：名字有 AI，考的是後端工程師怎麼把 AI 應用撐起來
AI-200（Azure AI Cloud Developer Associate）接替 2026 年 7 月 31 日退場的 AZ-204。四塊權重 20–25 / 25–30 / 20–25 / 20–25：容器、資料服務、訊息與 serverless、資安與監控。整份考綱沒有一條在考模型部署、prompt 或 agent，跟 AI 最直接相關的是 Cosmos DB、PostgreSQL pgvector、Managed Redis 三種向量搜尋。官方規格：美國 $165、台灣 $83、120 分鐘、及格 700、13 種語言含繁體中文、效期一年，練習測驗尚未開放。
AI Agent GitHub Digest — 2026-10-07
**Autoloom**（256★）把 Aegis 的工程治理方法包進 coding agent 的執行流程，底層跑在 DeepSeek 官方開源的 DeepSeek Harness 上；**pi-pocket**（136★）是給新 coding agent 「Pi」在剛發布的 Pi Durable 這套可持久 harness 上做的手機／網頁多人協作殼；**brewery-ai**（193★，前身 Homebrew）用一段對話帶你完成模型微調全流程，授權是 MIT 加商業營收門檻；**jev-doc-search**（99★）不用向量資料庫、不算 embeddings，靠 TypeSafe 的機率決策模型 Jev 配合 PageIndex 的樹狀索引做長文件搜尋。Claude Code 2.1.291 修了兩個會丟訊息、丟權限回覆的 regression。
ML／LLM 系統設計與 Coding 面試：四題架構、三題 Python 與 STAR 骨架
面試常被問到的四題系統設計（企業 RAG、推論服務、客服 Agent、線上 A/B 與資料飛輪）、三題 Python（動態批次、取樣、退避重試加 token bucket）與 STAR 行為骨架，每題附可講出口的回答與核對清單，程式碼都實際執行通過。
RAG 面試整理：從三階段流程到 Agentic RAG，九種變體怎麼分、怎麼答
RAG 面試題用「三階段流程 → 各階段的失敗點 → 九種變體各補哪個洞 → 6 類 RAG 解不了的問題」四步回答：Self-RAG、CRAG、Adaptive-RAG 補判斷，Graph RAG、KG-RAG 補索引，CAG 乾脆不檢索，Agentic RAG 與 Reasoning RAG 把決策交給模型。
AI Agent GitHub Digest — 2026-10-02
PageIndex（38.4k★，單日 +1,097）用目錄樹取代向量索引做推理式 RAG；iFixAi（18.3k★，+340）給 agent 配一個 120 秒稽核工具；Octop（6.2k★，+285）是騰訊雲開源的 local-first 多 agent 助理平台；BMAD-METHOD（53.7k★）把敏捷開發改寫成給 coding agent 用的 spec-driven 流程。Agno v3.1.0 加入 RBAC 權限套件但檔案系統要停機遷移；Pydantic AI v2.52.0 修了 web_fetch 的資安漏洞並把 harness 併入主倉庫。
檢索增強生成（RAG）的原理及實作——切文字塊、算特徵向量、找最接近的段落塞回 prompt｜政大蔡炎龍 生成式AI 第 8 堂
L06 說 prompt 只有兩件事：正確的資訊和清楚的指引。RAG 就是讓電腦自動去找「資訊」那一段：先把自己的文件切成文字塊，用同一個模型 fθ 把文字塊和問題都變成特徵向量，找出最接近的幾塊，再套進「請根據 {retrieved_chunks} 回答 {question}」的樣板。實作拆成兩支程式：Demo06a 用 LangChain 與 FAISS 建向量資料庫並壓成 faiss_db.zip，Demo06b 讀回資料庫、接 LLM、包成 Gradio。第八週作業就是換上你自己的資料。
用 LangChain 和手刻兩種方式，做一個回答貓咪冷知識的 RAG｜清大高宏宇 自然語言處理 作業 4／助教課
兩堂 RAG 助教課各做一個版本：第一堂在 Colab 裝 Ollama 跑 llama3.2:1b，用 LangChain 的 Chroma、MMR 和 retrieval chain 串出最小的 RAG；第二堂只在資料準備用 LangChain，其餘自己寫：切塊、存文字與向量資料庫、BM25 加 cosine 的混合檢索、用 RRF 合併排名，再拿 Llama-3.2-1B-Instruct 生成答案。HW4 把第一堂的骨架套到 150 則貓咪冷知識和 150 組 GPT-5 生成的問答上，生成器限定 Llama3.2-1b、embedding 限定 jina-embeddings-v2-base-en，要回報 recall@1、recall@5 與 exact match。程式占 45%，報告占 55%，報告要分析 prompt、資料格式、文件順序與反事實資訊的影響。
清大 NLP RAG（下）：檢索器接上生成器之後——從 ORQA、REALM 到 Self-RAG｜清大高宏宇 自然語言處理 主題單元
W11_RAG.pdf 的後半從「From Retrievers to QA」那一頁開始，把檢索器和讀者（reader）接成完整的問答系統。先看 2019–2020 年用 BERT 當讀者的 ORQA 與 REALM，再看第一篇叫 RAG 的論文和凍結 LLM 的 REPLUG；接著用一張表整理七個近年修法：改寫查詢（Query Rewriting、HyDE）、讓生成器不怕雜訊（RetRobust、RAFT、RAAT）、決定何時檢索（FLARE、Self-RAG）。最後談雜訊的類型、LLM 在 RAG 裡該有的四種能力，以及生成式檢索（GR）與可靠回應生成（RRG）。錄影方面，W11 週四那支講到 RAG 論文為止，後面的頁數本文找不到對應的錄影片段。
清大高宏宇 NLP 導讀：RAG（上）——幻覺與檢索器，從 BM25 到 DPR、GTR｜清大高宏宇 自然語言處理 主題單元
LLM 會一本正經地回答「歐本海默生於 1967 年」（那其實是他過世的年份），RAG 的做法是先檢索、再生成。高宏宇 Fall 2025 的 RAG 投影片前 60 頁都在講「怎麼找對資料」：稀疏向量（詞袋、TF-IDF、BM25）便宜可靠，稠密向量抓得到同義改寫；BERT 的 [CLS] 不適合直接當句向量，所以有 Sentence-BERT 的 pooling 和 bi-encoder；cross-encoder 準但一萬句要跑近五千萬次，bi-encoder 只要兩萬次；SimCSE 拿 dropout 當資料增強，DPR 只用一千筆訓練資料就贏過 BM25，GTR 則證明把 dual encoder 放大能改善跨領域檢索。
RAG：模型記不住、會過時的知識，怎麼先查再答｜台大陳縕儂 深度學習之應用 第 8 堂
語言模型把知識存在參數裡，冷門的記不熟、訓練後發生的不知道、公司內部文件沒看過，而且答案無從查證。RAG 的做法是讓它開書考：先依問題檢索相關段落，再連同問題一起交給模型回答。這一堂依序講檢索怎麼做（切段、sparse 與 dense retrieval、bi-encoder 與 cross-encoder、沒有標註資料時怎麼訓練 retriever）、檢索前後還能加什麼（改寫問題、重排序、多次檢索）、RAG 的幾條發展路線（檢索什麼、怎麼用、何時檢索），最後比較 prompting、RAG 與 fine-tuning 各適合什麼情境。
Agentic LLM，讓模型查資料、叫函式、自己跑完一輪｜Stanford CME295 第 7 堂
CME295 2025 版第 7 講用三塊補 LLM 的洞：RAG 補「知識停在訓練那天」，分成候選檢索與重新排序兩階段；tool calling 補「不能動手」，由後端執行模型寫出的函式呼叫；agent 用 ReAct 的觀察、規劃、行動迴圈把呼叫串起來。2026 版把這講改成 AI Agents，新增 context compaction、harness、coding agent、skills，是整個系列改最多的一講。
用 DSPy 做少樣本 OpenQA｜Stanford CS224U 作業 2
CS224U 作業二 hw_openqa.ipynb 要你只用凍結的語言模型與凍結的 ColBERT 檢索器回答沒有附原文段落的問題。2023 春季版寫的是 DSP，repo 現行版在 2024 年 1 月改成 DSPy 並釘在 dspy-ai==2.4.13。開工前得先準備 OpenAI API key、約 406 MB 的 ColBERTv2 權重與 600 MB 的預建索引；而 notebook 第一行 dspy.OpenAI 在 DSPy 3.4 已經不存在。
從 classical IR、IR 指標到 neural IR｜Stanford CS224U 主題單元
CS224U 2023 春季版花一整個單元講檢索，理由是 OpenQA 只給問題、證據要自己找，而大型語言模型會捏造來源。Potts 與 Omar Khattab 的投影片從 TF-IDF、BM25 講到 Success@K、MRR、average precision，再講 cross-encoder、DPR、ColBERT、SPLADE 四種 neural IR 在表達力與規模之間怎麼取捨，最後要你把延遲與成本也當成指標。
找不到那張蟲害照片：Image Search 的三輪修正
AI 助理平台的圖片搜尋連續三輪修正：第一輪把 node_type 過濾推進 ES query 解決文字 chunk 搶佔問題；第二輪讓 filename 匹配不再依賴 LLM 是否傳參數；第三輪從 Postgres icontains 換成 ES match 解決 CJK 部分匹配失效。
10% 的對話在編答案：Retriever 靜默失敗的排查紀錄
AI 助理平台約 10% 的對話隨機沒有知識庫工具，agent 直接用訓練資料編答案。根因是 retriever 初始化時的 except Exception 吞掉了 Elasticsearch 連線失敗，導致工具註冊靜默跳過。修法：加 retry + 把失敗 surface 到 system prompt + metadata 追蹤。
修了三次才對：一個設定值在四層架構裡的不一致
使用者在後台把檢索 top_k 設成 15，但監控面板顯示 5、串流 UI 先閃 5 再跳 15。根因是同一個 top_k 值存在於四層——LLM 工具參數、執行時 runtime、trace DB、串流 payload——每層都要個別 override。三次修正，每次修完才發現下一層也錯。
商業文件解析 API 橫評：專用 Parser、通用 VLM、三大雲，交叉點在哪？
商業文件解析分三條路線：專用 Parser（Cohere Parse $1.50/千頁、LlamaParse Agentic Plus 90.2%）、三大雲 Prebuilt（Azure/Google/AWS，結構化欄位抽取）、直接用通用 VLM（Fable 5.1 在 ParseBench 拿 78.92，圖表理解碾壓專用 parser，但每頁成本 3-16 倍且會幻覺）。10 萬頁/月純 OCR 各家都 ~$150，加表格後 AWS 跳到 $1,500、用 Claude Sonnet 5 跑要 $900。選型的第一個問題不是「哪家最準」，是「你要轉錄還是理解」。
Groundlane 實戰系列（篇 6）：Document 工具全家桶 — effort 旋鈕、field-aware chunking 與 confidence routing
document_parse 新增 effort 參數（fast/standard/deep）把 anydoc WASM、OCR.space、Docling VLM 三條路徑統一成一個旋鈕；document_chunk 的 fieldAware 模式從表格 header 和 metadata 抽欄位名附到 chunk，解決 RAG 的 attribute conflation；document_smart_parse 回傳 confidence 分數讓 agent 自己決定要不要升級。
Groundlane 實戰系列（篇 7）：Selector Healing、Retrieval Test 與品質 Benchmark
Groundlane v0.1.0 新增四個品質機制：web_extract 的 selector healing（三層確定性 fallback，不用 LLM）、corpus_retrieval_test（RAG 召回品質驗證，受 RAGFlow 啟發）、document benchmark CLI（character-level F1）、search benchmark framework（ground truth corpus + 多 provider 比較）。工具數從 54 增至 55。
手刻第一個 RAG：從切 chunk 到讓 agent 決定何時查｜Stanford CS329Z 第 3 堂
Lecture 03 從 project 問題出發，依序拆解 RAG 的動機、chunk 邊界、近似向量搜尋、BM25／dense／hybrid／reranker，以及讓 agent 決定何時查。指定讀物 Lewis 等人的 RAG 論文與 ColBERT 補上原始配方與 late interaction。
讓 agent 記住該記的事：MemGPT、Letta、Mem0 與 Generative Agents｜Stanford CS329Z 第 7 堂
Lecture 07 把 agent 記憶分成 working、episodic、semantic、procedural 四類，比較技能庫、MemGPT 式分層、反思整併與記憶維護四種架構，並談記憶評測與遺忘、隱私、過度個人化。讀物從 MemGPT 的虛擬記憶體，延伸到 Letta、Mem0 與 Generative Agents。
寫程式的智慧體，先替它造一把順手的 IDE｜Stanford CS329Z 第 17 堂
第 17 堂依課表談 coding agent 的端到端運作：SWE-agent、Claude Code 與 OpenHands 的架構，scaffold 作為設計決策，SWE-bench 與 4-tuple 框架的實際應用，以及軟體開發的未來。讀物涵蓋 SWE-agent 的 ACI、OpenHands 的事件流沙箱、Claude Code 實務、長任務 harness 與 SWE-bench。
複合式 AI 系統：模型、資料與工具如何配合｜Stanford CS329Z 第 1 堂
先從第一堂投影片理解 agent 迴圈、元件與工程問題，再分別深讀 BAIR 的複合系統觀點、Ng 的工作模式，以及 Si 的執行回饋實驗；清楚區分課堂主線、指定閱讀與延伸閱讀。
Marker: Datalab's Open-Source, Apache 2.0 Pipeline Parser — Faster, CPU-Ready, More Accurate
Marker（Datalab 開源，Apache 2.0 授權，v2.0.0 於 2026-07-20 發布，39.5k stars）是一個以 Markdown 與 JSON 為輸出的 pipeline 式文件解析標準庫，支援 PDF、圖像、PPTX、DOCX、XLSX、HTML、EPUB，並提供可選的 LLM 增強（`--use_llm`，預設 `gemini-3.5-flash`）、可自訂格式邏輯與表格/公式/內嵌數學/連結/參考/程式碼區塊的完整處理、圖像提取與保存、標頭/頁尾移除，並可在純 CPU、GPU 或 MPS（Apple Silicon）環境運作。與 [Docling](/posts/tech/2026-09-06-docling-document-parsing) 同屬解析層，但授權路徑（`Apache 2.0` 代碼 + `AI Pubs Open Rail-M` 模型權重，有商業門檻 `$5M`）、輸出核心（`Markdown` 為主而非結構化 `JSON`）、解析引擎特點（`Pipeline` 式可替換階段，但 `VlmPipeline` 為可選的 `LLM` 增強而非固定 `VLM` 選項）、與 [MinerU](/posts/tech/2026-09-05-mineru-ocr-doc-parsing)（自訂協議、`Markdown` 為核心、`Hybrid` `effort` 參數）的差異形成解析層內三種不同取捨路徑。
Docling：IBM 開源、MIT 授權、結構化 JSON 為核心的文件解析標準庫
Docling（IBM Research Zurich 起源，現由 Linux Foundation AI & Data 治理，MIT 授權，v2.100.0 於 2026-06-09 發布）是一個以結構化 JSON 為核心輸出的文件解析標準庫，支援 PDF、DOCX、PPTX、XLSX、HTML、EPUB、Apple Pages、影片（MP4/AVI/MOV，含 ASR 轉錄與代表性幀）、音訊（WAV/MP3）、電子郵件（EML/MSG）、ODF 與 XBRL 財報，並提供可替換階段的 pipeline 式解析（純 CPU 或 GPU 加速）、VlmPipeline 選項（GraniteDocling 258M VLM）、MCP server 與 API server（docling-serve），與 LangChain / LlamaIndex / Crew AI / Haystack 原生整合。
MinerU：從 PDF 到結構化 Markdown 的文件解析引擎
MinerU 是 OpenDataLab 的開源文件解析引擎，可將 PDF、圖像與 Office 文件轉成保留表格、公式和閱讀順序的 Markdown 與 JSON，適合 RAG 前處理與知識庫建構。
Agentic Parsing：讓 Agent 決定怎麼解析文件
傳統文件解析用固定 pipeline 一體適用，但合約、財報、技術手冊各需不同策略。Agentic Parsing 讓 LLM agent 觀察文件後動態選工具——AgenticOCR 只解析需要的區域（視覺 token 省 70%+）、ParseBench 2,000 頁企業文件實測最佳方案也只拿 84.9%，沒有銀彈。
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 管理生命週期。
Information Retrieval：從倒排索引、tf-idf 到 RAG 的檢索底座｜Stanford CS124 第 4 週
第 4 週教搜尋：把查詢和文件都變成向量，用 tf-idf 加權、cosine 相似度排名，用倒排索引加速，用 precision、recall 與 MAP 評估，最後接到向量檢索與 RAG。本文把投影片的四篇迷你文件例子完整算一遍。
RAG 與 Language Agents 的六個元件｜Stanford CS224N 第 10 堂
第 10 講從問答與 RAG 進入 language agents，再拆成推理規劃、記憶、工具、資料與評估；agent 不是單一模型，而是模型與外部狀態之間可被逐步檢查的迴圈。
WikiChat 的七階段 RAG 如何逐條攔下幻覺｜Stanford CS224V 第 5 堂
WikiChat 不把檢索結果直接交給一次生成，而是形成查詢、檢索、過濾、生成、拆主張、再檢索查核與移除無根據內容，並把檢索與事實性分開評估。
STORM 與 Co-STORM 怎麼把搜尋變成知識策展｜Stanford CS224V 第 2 堂
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。
Retrieval、RAG 與進階架構如何變成一個系統｜Berkeley CS288 主題單元
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 與監控把檢索做成可維運的服務。
Agentic AI：用形式方法處理幻覺｜Stanford CS224V 課程總覽
CS224V 是 Stanford 的 Agentic AI 課：教怎麼用形式語意、知識圖譜與形式方法約束 LLM agent，讓它少編造，兩份作業之後以專案為主。十四堂講義、閱讀清單、作業講義與課程用到的開源系統（STORM、WikiChat、SUQL、Genie Worksheets）都公開；沒有公開錄影，公開的投影片是刻意留白的版本，作業要用的憑證也只發給選課學生。
AI Agent 工程：不靠框架，從一個 chat-completion 呼叫做出 agent harness｜Stanford CS329Z 課程總覽
CS329Z 是 Stanford 的 AI agent 工程課：先不靠框架手刻 RAG、工具呼叫與 agent 迴圈，再看 DSPy 這類框架抽掉了什麼，兩份作業分別是做 agent harness 與設計 agent 評估。課綱、指定閱讀、前十一堂投影片與第一份作業的起始碼、資料和公開測試都拿得到；錄影要以選課身分登入 Canvas。
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 應用：RAG、agent、安全治理、成本與評估。本文依官方五章考綱，整理前置能力自評、四步準備法、教材選擇與實作驗收，附十週安排、AI 輔考範本及應考提醒。先做診斷，再用同一個 RAG 加 agent 專案補齊弱項。
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：一堂課教完之後，剩下的才是難的｜Stanford CS230 第 8 堂
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）動態切換。