文件解析是檢索的瓶頸

資料來源#

• Beyond RAG: Building Agentic Document Workflows with LlamaIndex
• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders

摘要#

Pierre-Loic Doulcet（LlamaIndex，AI Engineer Singapore 2026，116 張投影片，practitioner-opinion）回顧三年的 RAG 實務，將其歸結為一連串瓶頸：

瓶頸在檢索，而非生成。在檢索之中，瓶頸是解析。在解析之中，問題是文件結構流失。大多數調校工作都花在模型上；大多數成果卻來自模型上游。

演講的編排本身就是論點：列出 2024 年的失敗分類，指出到 2026 年哪些項目已成為例行工程，再觀察殘餘問題集中在管線的第一步——把 PDF 轉成代理程式看得懂的文字。結尾這句是精簡版：「瓶頸往上游移動了。離開模型，離開檢索器，進到文件裡。」

證據與利益衝突聲明，以下內容皆適用。 這是一場廠商演講。LlamaIndex 銷售解析器（LlamaParse）與託管管線（LlamaCloud），也發布自家解析器領先的基準測試（ParseBench）。本文所有量化主張分為：(a) 投影片引用的第三方數據；(b) LlamaIndex 數據，會標明來源；或 (c) 未附來源的實務主張，也會標明。演講一開始便自我聲明——「到 2027 年，這裡幾乎所有內容都會是錯的；這套技術堆疊中『最佳實務』的半衰期不到一年」——這正是看待具體細節時應採取的分量。分類方式與連鎖方向才是持久的部分；技術排名只是 2026 年的快照。

12 個痛點，以及連鎖效應為何比清單更重要#

投影片採用的 2024 年基準，是 Wenqi Glantz 的 12 RAG Pain Points and Proposed Solutions（Towards Data Science，2024）——7 項取自 Barnett 等人的論文，5 項來自生產環境。Glantz 的圖（已檢視；它是管線圖，不是清單）將每種失敗放在產生它的階段：索引流程（文件 → 分塊器 → 區塊 → 資料庫）包含內容缺失與資料匯入擴展性；查詢流程（查詢 → 改寫器 → 檢索器 → 重排序器 → 整合器 → 讀取器 → 回應）包含排名靠前項目漏失、不在上下文中、未擷取、格式錯誤、不完整、特定性錯誤。另有四項橫跨管線之外的問題：結構化資料 QA、複雜 PDF、備援模型、LLM 安全性。

這份演講的貢獻，是依照誰會破壞誰重新分群（已檢視圖表）：

群組	痛點	關係
解析	複雜 PDF	↓ 造成破壞 ↓
檢索	內容缺失 · 前 k 項漏失 · 整合 · 特定性 · 不完整	↓ 造成破壞 ↓
綜合	未擷取 · 格式錯誤	—
相鄰但不連鎖	結構（表格 QA）· 規模（匯入）· 作業（備援 · 安全性）	各自獨立

關鍵主張是：解析只占 12 個痛點中的 1 個，但其錯誤會傳播到其他 7 個——而且傳到下游時，會披著檢索或綜合問題的外衣。一張被攤平成一行的表格會產生「頁碼正確、列錯、欄錯、年份錯」的結果，看起來像是綜合失敗（模型誤讀區塊），實際上卻是匯入失敗（區塊已無法表示哪個數字屬於哪一欄）。錯誤歸因正是演講指出 2024 年修正方式——更好的提示、更多 few-shot、調整 top-k、微調區塊大小——針對錯誤層級的原因：「這些做法全都把綜合器當成要修正的對象。」

哪些已成為例行工程（2024 → 2026）#

演講按原本順序列出投資報酬率階梯，並建議由上而下採用，做到足夠就停（「多數團隊需要 1–3 項，不是全部五項」）。

1. Cross-encoder 重新排序——「沒有其他旋鈕有這種效益比。」 第二階段以能同時讀取查詢與文件的模型重新評分候選項，而非比較預先算好的嵌入。第一階段廣泛檢索以提高召回率（bi-encoder，前 50 項，對 1,000 萬份文件約 5 毫秒）；第二階段重新排序以提高精確率（cross-encoder，50 組配對，約 100 毫秒），最後保留 5–10 項。這兩種模型並不能互相取代——bi-encoder 在結構上看不到配對，因此會漏掉否定、範圍與限定條件。據稱可提升 +4 至 +14 nDCG@10，延遲只增加數百毫秒。引用的依據層級不一：BEIR/sentence-transformers 結果（最大型 cross-encoder 平均比最佳 bi-encoder 高約 +4 nDCG@10，單一資料集最高 +12——gooaq-dev 59.12 → 71.35）來自第三方；配對數據（Voyage rerank-2.5 在 93 個資料集的 nDCG@10 比 Cohere rerank-v3.5 高 7.9%，在 MAIR 高 12.7%）是勝出廠商自己的部落格主張。可消除痛點 2、3，並部分消除 6。

2. 查詢改寫——地位降低。 HyDE（先草擬假想答案，再嵌入那份答案並搜尋——彌合使用者說法與文件說法之間的語域差距）和 multi-query + Reciprocal Rank Fusion（用 N 種說法各自檢索，再依排名融合——彌合角度差距）是 2024 年代理程式普及前的技巧。演講的結論是：兩者都已被代理式迴圈吸收，因為能評分並改寫的代理程式可以動態執行這些操作，還能在第一次嘗試失敗時恢復。保留它們是為了歷史脈絡——「你會在 2024 年左右的程式碼中看到 HyDE 和 QueryFusionRetriever。」

3. 代理式／修正迴圈——「投資報酬率第二高。」 CRAG（Yan 等人，2024）是典型模式：檢索 → 生成前逐一評分每個區塊 → 分支處理（高信心 → 綜合；模糊 → 精煉區塊後重試；低信心 → 重新擬定查詢或改用網頁搜尋）。演講強調的機制是，評分器會將檢索品質與生成品質解耦：一般 RAG 一律生成，因此品質不佳的區塊會變成語氣篤定的幻覺；評分器是「管線上的斷路器」。刻意設計得很便宜——小模型評分（查詢、區塊）配對，輸入形式與 reranker 相同，只輸出一個信心值，而非判斷。可消除痛點 1、4、7。成本是多 1–3 次 LLM 呼叫，以及 P50 延遲增加 2–4 倍；演講也特別清楚指出何時不該付出這筆代價：查詢分布中最常見的一群仍然故障時、延遲預算低於 2 秒時、沒有 eval 時（迴圈會掩蓋回歸），以及「所謂的『迴圈』其實只是掩蓋錯誤的重試」時。

手工打造迴圈，正受到兩端擠壓。 Adaptive-RAG（Jeong 等人，NAACL 2024）用小型分類器依複雜度路由——不需檢索／單跳／多跳——因為多數查詢根本不需要迴圈。Search-R1 / R1-Searcher（2025）訓練模型在推理途中呼叫 search()，因此迴圈最後會進到權重裡。Speculative RAG（Wang、Google，2024）則以平行化處理：小型起草模型從互不重疊的區塊子集中產生 N 個答案，再由較大的驗證器選出一個。演講總結道：「手工打造的 CRAG 正從下方被路由取代，從上方被模型吸收；工作流程的形狀會留下來，但每個步驟內部的運作會持續改變」——這是檢索層對模型進步，harness 隨之精簡的表述。

4. 多模態描述並建立索引。 向量搜尋會嵌入文字；2026 年企業文件的關鍵內容往往是圖片。兩階段修正：匯入時由 VLM 為每張圖表撰寫說明，並將說明連同周邊文字一起建立索引；綜合時擷取原始圖片交給模型。明確指出不是使用圖片嵌入——「CLIP 位於另一個空間：兩條管線、沒有共用 reranker；說明文字仍在文字空間。」兩項作業注意事項：瓶頸在說明品質（要寫出座標軸和單位，不能只說「顯示資料的長條圖」），而且不可改述 VLM 在回答時能直接讀取的內容。

5. 結構化資料——查詢，不要嵌入。 表格嵌入成文字後會失去形狀：列變成句子、欄變成雜訊、彙總也無從進行。「APAC 2025 年支出最高的 5 家供應商」這種問題會找到供應商表格，卻無法篩選、分組或排序。修正方法是使用路由器：索引結構描述與範例列，讓模型了解資料形狀；表格型問題交給查詢語言（JSON 用 JQ、關聯式資料用 SQL、圖形用 Cypher），文字敘述型問題交給向量檢索，最後在綜合階段合併。值得保留的是這句坦白話：「路由器才是工作本身。多數團隊都跳過了它，而它正是讓一切能運作的關鍵。」 提供的預設啟發式刻意簡單——數字／清單／篩選 → 查詢；摘要 → 檢索。

附錄列為有條件採用，而非預設作法：Graph RAG 適用於答案確實需要圖形遍歷，且實體／關係結構描述穩定的情況——「應因 eval 顯示單跳檢索漏失才採用，而不是因為它有趣」；預留一般方法 2–3 倍的延遲預算，並留意隱藏成本：錯誤實體會產生錯誤邊，再造成錯誤遍歷。多粒度索引——建立句子、章節與頁面層級的索引，並在其中路由或重新排序，「儲存空間增加 3 倍；向量很便宜，值得付出」。增量 upsert 加上內容雜湊去重，能悄悄解決匯入擴展性痛點；「多數團隊仍因習慣而採用批次處理」。

三個觀念轉變#

檢索，而非生成。 2024 年：「模型產生幻覺」→ 試試更大的模型。2026 年：「檢索交給它錯誤的區塊」→ 修正解析、分塊、重新排序。支持這項說法的圖表指出，單純 RAG 有 約 40% 的機率在檢索階段失敗；圖表未附引用，應視為實務工作者對量級的估計，而非測量結果。投影片中最有力的處方，是以預算比較取代辯論：一週該花在哪裡——解析＋分塊 2 天、檢索＋重新排序 2 天、綜合提示 1 天、模型 0 天——對比多數團隊實際的做法——解析 0 天、檢索 1 天、綜合提示 2 天、更換模型 2 天。

長上下文並未終結 RAG——2024 年的預測並未成真。 當時的預測是，100 萬 token 的上下文視窗會讓檢索變成小型上下文的權宜作法。「上下文視窗推出了，檢索也增加了；把整個語料塞進去的做法則徹底失敗。」原因有三，而且只有第一項與 token 有關：成本（依前沿模型價格，每次查詢使用 100 萬 token；快取雖有幫助，但對任何非微不足道的語料而言，計算結果仍不划算）；治理（塞入資料代表也塞入請求者不該看到的文件——「『模型答應會忽略』不是一道界線」）；以及可稽核性——「『AI 為什麼這麼說？』檢索會留下引用紀錄；長上下文只留下感覺。」 有用的重新定位是：檢索後來更像稽核軌跡，而非容量不足的權宜作法；因此，即使上下文免費，檢索仍然有用。

Eval 本身就是一套堆疊。 2024 年：一個 notebook、十道手寫問題、人工目測、上線。2026 年：生產查詢 → 抽樣建立 eval 集 → 三項評分（忠實度 · 相關性 · 召回率）→ 每次部署都執行回歸閘門，並搭配追蹤與重播（RAGAS、DeepEval、Langfuse、Phoenix）。保留兩項規則：不要用同一個模型生成並評分——「它會認同自己」（見LLM-as-a-Judge）；也不要只評估系統本來就擅長回答的問題——要保留明確的長尾測試集。結尾的說法是：「如果你無法衡量某項變更是否有幫助，你做出來的只是展示，而不是系統。」

解析器破壞文件的六種方式#

這是演講的核心段落，每張投影片各剖析一種失敗，使用同一份具挑戰性的來源（銀行年報）。每種失敗都配上它會引發的下游痛點：

失敗	留下的內容	下游影響
1. 多欄被攤平	兩句不相關的句子逐字交錯拼接（「淨利息收入 集團持續穩健表現 上升 8%，因存款成長……」）	嵌入結果帶有雜訊鄰近關係；檢索找到文件中不存在的文字
2. 表格 → 管線符號雜湊	標題與列分離、數字失去單位、列標籤與下一列數字黏在一起	PP 4——「頁碼正確、列錯」；代理程式信心十足地從錯誤列取值
3. 腳註插入正文	限定說明看起來像下一句；數字失去上下文	代理程式把數字引述成整體成長，卻不知道其中排除了單次收益
4. 圖表遭丟棄	可能留下說明文字；通常只留下圖例字串（「FY21 FY22 FY23 FY24 FY25」）	PP 10——答案位於圖表中的問題會無聲無息地失敗
5. 標頭／頁尾造成污染	每個區塊都帶有相同的文件標題與頁面裝飾	每個嵌入都被拉向同一個中心點；餘弦相似度失去區辨力；PP 2 出現在 top-k 邊界，reranker 還得花預算區分近似重複項
6. 跨頁閱讀順序錯亂	區塊 A 在子句中間結束，區塊 B 也在子句中間開始，各自單獨嵌入；表格列與標題分離	一次換頁就同時引發 PP 3 和 PP 4

演講附帶的指示是：「挑一份你還沒親自檢查過的生產 PDF。至少有一種問題正在發生。」 受到批評的 2024 年基準是 PyMuPDF / pdfplumber——「免費、快速，處理簡單文件時出奇地好用；處理年報、合約、法規文件就很差」，因為輸出只是一串大致上依閱讀順序排列的文字；遇到多欄頁面時，順序就錯了。

這些投影片在知識庫所保存的來源副本中自行證明了這個論點，是目前最有力的證據。 簡報以截圖呈現遭破壞的輸出；我們再次解析時又對這些截圖做了 OCR，因此原始檔中有字面上無法閱讀的雜訊，正好包含失敗模式 1、2、5。這些內容不可作為數據引用——見Beyond RAG: Building Agentic Document Workflows with LlamaIndex中的解析注意事項——但這個示範經過一輪來回仍完整保留。

修正堆疊：空間文字 → Markdown → 結構對齊分塊#

空間文字是缺少的基本原語。「PDF 並非真正由文字字串組成，而是 2D 畫布上依空間定位的 token 集合——每個 token 都有 x、y、寬度、高度、字型與樣式。」解析時保留座標，下游每一層便都能繼續判讀版面：依 y 分組 → 列，依 x 分組 → 欄，依區域分組 → 章節。它帶來的好處以能力而非品質描述：可還原的表格結構、無須 regex 變通法便能排除標頭／頁尾的區域篩選器、可解析至能反白標示的邊界框的引用，以及 VLM 交接——文字不足時，可回退到相同座標的頁面截圖。LiteParse（Apache 2.0、本機執行、不用 LLM、不用雲端）是參考實作。

交給下游的格式應是 Markdown。「空間文字保留幾何資訊；Markdown 保留結構」——標題階層、標題與表格格線相連、清單、錨定於對應位置的腳註，以及附說明文字的圖表。一份產物，三種用途：攤平後供舊式嵌入器使用、解析成樹狀結構以支援理解版面的分塊，以及轉譯給人閱讀。還有一個常被低估的原因：所有前沿模型都已接受 Markdown 訓練——語法本身就是訊號，因此不必透過提示工程解釋「這是一張表格」。

依結構分塊，不依長度。 2024 年的答案（512 個 token、重疊 50 個 token、遞迴分割器）被形容為*「總是錯——只是可以辯護的預設值；它假裝文件是一串字串。」* 2026 年的答案：一個章節就是一個區塊、一張表格就是一個區塊、一張圖表加上說明就是一個區塊，腳註則留在所錨定的位置。重點在於相依關係——唯有解析器保留結構，才能進行結構式分塊；因此這場演講把分塊從檢索段落移到了解析段落。這也解開痛點 6（特定性錯誤）：根本原因是語料只以單一粒度分塊一次，但問題的粒度範圍從「一個數字」到「整份報告」。

中繼資料是分塊策略的一半。 文件標題、章節路徑、頁碼、來源 URL、匯入時間戳記、權限、解析器版本、信心值——這些資訊讓區塊具備三種原本不具備的能力：檢索時以述詞而非向量篩選、綜合時提供使用者可點選的引用路徑，以及知道是哪個解析器產出結果後，便能重播任何歷史答案。

擷取或解析。 已知目標、不同文件的欄位都相同，而且下游需要的是資料列或表單欄位時，採用以結構描述為先的擷取（定義 Pydantic 模型，取得經驗證的型別化 JSON，每個欄位都附頁碼＋邊界框引用）。不知道目標、問題類型又有長尾時，則採用解析＋檢索。「多數真實系統兩者都用。」

解析是一個階段，不是單一步驟。 你會再次解析、用新結構描述重新擷取，也需要在解析器改進時回頭重跑，因此要儲存原始文件與每個中間產物，並讓解析具冪等性。附錄將原則推廣為所有項目都要版本化（解析器、提示、索引、結構描述）：「『我們星期二更換了解析器，星期三準確率掉了 8 個百分點』這種問題，只有在星期二使用的解析器仍可取得時，才能除錯。」

ParseBench，以及一張圖表如何推翻自己的說明文字#

LlamaIndex 的解析基準測試（2026，arXiv 2604.08538，約 2,000 個經人工驗證的企業頁面，作為 Hugging Face 資料集提供給開放權重模型使用，並以 Kaggle 競賽提供給前沿模型使用；兩者採用相同測試架構，因此數據可比較）。其設計選擇才是可移植的部分：依語意正確性評分，而非文字重疊，共五個面向，各自對應下游代理程式的需求——表格（結構化紀錄配對，還原列 × 欄）、圖表（精確資料點驗證：座標軸、數值、序列）、文字完整性（不得遺漏或幻覺）、文字樣式（以語意結構表示標題／清單／強調），以及邊界框定位（每個擷取元素都指回頁面區域）。演講對此提出的警告是正確的，值得牢記：「上線前先確認——實際數字會低於廠商報價。」

值得檢視成本與準確率的圖表，因為投影片文字誤讀了它。 文字聲稱「前沿 VLM（GPT-5 Mini、Haiku 4.5）落在 40% 出頭——價格昂貴，通用模型準確率」，並將 LlamaParse Agentic（84.9%，每頁約 1.2 美分）和 Cost-Effective（71.9%，每頁約 0.4 美分）定位為 Pareto 前沿。圖表（Fig. 5，約 14 種方法）顯示這兩個點如文字所述，同時也顯示 Gemini（高）在約 2.4 美分時接近 76%，Gemini Pro 在約 8.4 美分時接近 69%，GPT-5.4 則接近 62%。「40% 出頭」只適用於最便宜的前沿級別（GPT-mini 變體、非思考版 Haiku 4.5）。對廠商自家圖表較誠實的解讀是：一般前沿 VLM 在高設定下，準確率只比專用解析器低約 9 個百分點，但每頁成本約為其 2 倍——差距遠比文字描述的小，也正如模型進步，harness 隨之精簡所預測，差距會繼續縮小。修正後，演講的結構性論點仍成立，且值得保留：準確率與成本曲線的大部分區段都是平坦的；解析錯誤會在後續每個階段累積，因此邊際預算應花在上游。

代理程式層的落點：工作流程勝過鏈結#

對於「要如何串接代理程式確實讀得懂的文件」，演講提出的答案是 LlamaIndex Workflows——由事件驅動的圖形架構，其中型別化事件本身就是架構。相關討論見將代理程式工作結晶為工作流程，該文整理了工作流程形狀相關內容（型別化事件、宣告式扇出／扇入、HITL 作為持久事件而非例外、從事件串流自然取得的可觀測性），並納入 Malik 對代理程式工作何時應轉成工作流程的說明。深度研究的形式——拆解成子問題、平行扇出檢索、扇入後組合成附引用的答案，本文稱之為**「代理式檢索樹，而非迴圈」**——見深度研究代理程式。

這個知識庫就是論點的實例#

這層關聯直接得令人不自在，但值得記錄，因為它讓這場演講不只是建議，也是在描述此處已經運作的實務：

• 失敗模式 2 是此知識庫有記錄的解析缺陷。 _system/compiler-prompt.md 中的 table-collapse 與 table-shift 規則，描述的正是管線雜湊失敗——跨欄標籤將一組列合併到同一格，或列標籤滑進數值欄；稽核軌跡記錄了 wiki 唯一已知的錯誤數字是由位移造成。演講對下游的診斷（「頁碼正確、列錯；代理程式信心十足地從錯誤列取值」），與使用者端對同一失敗的描述完全一致。
• 日常慣例符合演講自己的建議。「從正文和圖表說明中引用數字；表格列要先核對才能採信」是結構會流失這個觀點的作業版本；這項看法是從八個可疑來源中有七個最後證實無誤，獨立推導而來。
• 圖片二階段規則是在編譯時執行的描述與索引流程，並使用人工水準的說明撰寫器。本文就是一個實例：痛點連鎖、CRAG 分支、平行扇出形狀與 ParseBench 成本曲線全都只存在於投影片圖片中；而上文 ParseBench 文字與圖表的落差，也只有實際檢視圖表才找得回來。
• 知識庫缺少的 canary，正是演講基準測試具備的能力。 canary-recall 事後抽樣正文 token；ParseBench 的邊界框定位面向，以及 LlamaExtract 每個欄位都提供的頁碼＋邊界框引用，則在擷取當下就把數值綁定到頁面區域——差別在於只能確認內容是否留存，或能指出它來自何處。逐層遺漏歸因在 L0 指出的也是同一個缺口。

關聯文章#

• 逐層遺漏歸因——同一種失敗在更高一層抽象中形式化。「OCR 遺失表格結構」是 Rajan 所列 L0（來源／匯入）層的第一項機制；本文則是實務工作者把這個項目展開成六種具名失敗及其下游後果。兩者互補：Rajan 提供方法——在管線每個邊界設置 canary 探針，就能精確計數 L0 流失，無須 judge；本文則提供機制，以及關鍵觀察：Rajan 的分層帳目雖然預測、卻未明說，L0 流失會系統性地被錯誤歸因到下游：表格攤平會呈現為 L5 上下文中段漏失，或 L7 解碼錯誤。Doulcet 說「解析是 12 項中的 1 項，卻會傳播到 7 項」，是對同一警訊的連鎖版本，也說明為何固定的層級順序有其必要
• LLM-as-Compiler Knowledge Base——語料中最有力的相反觀點，但兩者的分歧比表面看起來窄。Karpathy 的架構以編譯取代檢索；這場演講則主張，即使 100 萬 token 的上下文視窗免費，檢索仍會存在，因為它是稽核軌跡（「檢索提供引用紀錄，長上下文只提供感覺」）。不過，兩者都把同一種不可避免的風險放在同一處：編譯時流失的限制——「早期摘要移除來源中的細節，後續每個答案都帶著那個錯誤」——就是本文所說的結構流失，只是晚一層發生。編譯後的 wiki 一次付清、永久承擔解析成本；檢索管線則每次查詢都付出成本，但解析器改善時可以重新解析，這正是「解析是一個階段，不是單一步驟」所能做到，而編譯產物無法做到的事
• 深度研究代理程式——這條管線所支援的形式，也是最容易受其失敗影響的形式。DRACO 將事實準確性評為輸出端的弱項；本文指出評分看不見的上游原因，因為引用報告中遭遺漏或錯誤歸因的圖表，可能是在解析器而非規劃器階段出問題。兩者匯聚出的設計要點是：演講的深度研究工作流程在每一步都傳遞引用，理由與 DRACO 評分引用的原因相同；演講堅持區塊要能指回頁碼與邊界框，則是讓引用可驗證，而非裝飾
• 將代理程式工作結晶為工作流程——演講第五部分的落點。Malik 提供生命週期（代理程式探索何時應變成固定工作流程）；Doulcet 提供形狀（型別化事件作為契約、持久上下文、人工審查作為事件）。兩者從相反方向認同同一個邊界條件——Malik 以警告形式提出的 Type 3 接納條件是：「不該使用工作流程的情況：若任務只是針對單一文件進行一次問答，用函式就夠了」
• Agentic Prompt Injection——痛點 12 作為檢索管線問題的表述：「檢索出的內容是不可信輸入；把每個檢索區塊都當成使用者填寫的表單欄位。」 演講指出防禦措施應放在管線的哪些地方——在匯入時，而非綜合時移除或標記具有指令形狀的文字；在區塊上放置授權中繼資料，並於檢索時篩選，而非跨租戶共用索引；限制工具介面，確保能檢索的代理程式無法同時外洩資料；維護含有內嵌 payload 的紅隊文件語料庫，每次發布都像 eval 集一樣執行
• Context Lifecycle Management——同一個資訊保存問題，只是位於管線另一端。解析時的結構流失與壓縮時的濃縮流失都無聲無息、在追蹤記錄中都看不見；兩者的應對方式都是保留可復原的表示法，而非更小的表示法——匯入端保留含邊界框的空間文字，執行階段端則以穩定物件 ID 搭配 sidecar 儲存
• LLM-as-a-Judge——評估觀念轉變中的操作規則：「不要用同一個模型生成並評分；它會認同自己。」本文將其視為實務建議提出，該文則補上背後的稽核證據
• 模型進步，harness 隨之精簡——檢索側對同一趨勢的表述，演講也明確指出：隨著模型進步，邏輯逐漸移入代理程式迴圈，檢索層則變得更簡單（手寫 HyDE 與 multi-query 改寫被能評分並重試的代理程式吸收；CRAG 被 Search-R1 吸收到權重中）。相反的證據是：沒有精簡的是模型無法觸及的那一層——解析器是直接處理模型看不見之位元組的確定性軟體
• 驗證成為新瓶頸——說明邊界框定位為何是 ParseBench 中值得關注的面向：引用頁碼與區域的答案，人類幾秒內即可檢查；引用區塊 ID 的答案，則只能信任產生它的管線
• LlamaIndex——簡報的廠商、其解析／擷取／工作流程堆疊，以及其發布的基準測試
• FastContext——同一種解耦，只是換到另一個領域：將檢索／探索與解題分開，由探索器在可丟棄的視窗中承擔搜尋成本
• 豐裕時期的權限與稽核仍然重要——對稽核軌跡問題的回答：token 價格降低，只會消解本文長上下文論點中的成本因素；逐區塊治理與引用紀錄稽核屬於界線與紀錄機制，無法移進自己負責監督的視窗內
• 推理鏈中的檢索——更上一層，也是本文論點最有力之處。Search-o1 以模型讀取每份文件、抽出相關區塊並放入推理鏈，來處理嘈雜檢索；這個步驟假設文件以值得閱讀的文字形式送達，因此表格攤平後，即使成功抽取也會得到錯誤數值。該文也補充此處 Search-R1 註記在提示端的對應：觸發條件和查詢可以吸收到權重中，讀取文件的呼叫則不行
• 從試點到生產的落差——以刪減方式得出相同的剩餘結論。 Anthropic × Accenture（vendor-claim）建議企業架構師稽核檢索層是否「仍在解決當下問題，還是已經解決的問題」；因為分塊、傳送前摘要與分階段檢索，都是為了現代模型已不再面臨的上下文視窗限制而採取的權宜作法，同時也承認，若資料新鮮度或存取控制是主要需求，檢索仍有其價值。這和本文結論相同（長上下文沒有終結 RAG；成本、治理與稽核超越了原有限制），只是從相反方向出發，問的是該移除什麼，而非什麼留了下來。兩者認同剩餘部分，沒有分歧；但須注意，上下文視窗智慧區使兩者共享的前提更複雜，因為可用上下文遠低於宣稱的視窗大小

開放問題#

• 「解析錯誤會傳播到 12 個痛點中的 7 個」這項連鎖主張，能否經得起測量，而不只是斷言？逐層遺漏歸因提供了測量工具——canary 探針能精確計數 L0 流失，而（衝突 − 字面）探針對比可隔離下游行為損失——因此可證偽的版本是：固定語料，分別使用保留結構的解析器與純文字解析器解析，固定所有後續階段，並依層級歸因端對端失敗的差異。語料中沒有任何資料做過這件事。
• 專用解析器相對於一般前沿 VLM 的優勢，實際上縮小了多少？ParseBench Fig. 5（廠商執行的基準測試）顯示 LlamaParse Agentic 得分 84.9%，Gemini 高設定接近 76%，每頁成本約為 Gemini 的一半。如果模型進步，harness 隨之精簡在此也如其他領域一樣成立，那麼專用層只是目前 VLM 能力不足所需的暫時成本；如果邊界框定位與每頁成本可預測性具有結構性，它就不會消失。下次前沿 VLM 發布時以相同測試架構重跑，即可驗證。

已解決問題#

• 檢索的稽核軌跡論點，是否足以在真正便宜的長上下文情境中站得住腳？演講提出三個理由：成本、治理與可稽核性，只有成本會隨 token 價格變動。如果 100 萬 token 的視窗幾乎免費，逐區塊權限篩選與引用紀錄稽核能力，是否仍迫使系統保留檢索層——還是會變成可在視窗內解決的歸因問題？已回答：豐裕時期的權限與稽核仍然重要——只要相關需求存在，答案就是肯定，因為只有成本因素依 token 計價。治理以循環性方式持續存在：逐區塊權限篩選就是檢索邊界上的逐次呼叫授權，而執行措施不能放在自己負責監督的視窗內（「『模型答應會忽略』不是一道界線」正是安全性語料量測到的頻內崩潰）——無論價格如何，視窗都屬於錯誤的信任網域。可稽核性也持續存在，因為視窗內歸因是模型自述，但稽核需要模型之外產生的紀錄；若沒有選取動作，紀錄只會寫著「全部」，也就無法歸因：檢索正是讓引用紀錄具有實質內容的動作。適用範圍也有反向限制：只有在主體數 > 1 時，治理才要求檢索層；只有需要問責時，稽核才要求檢索層；本文「幾乎免費」前提過度樂觀估計的部分則是能力（上下文視窗智慧區提出的有效上限／拒答證據）——這是唯一仰賴當前模型限制、而非系統結構的因素。這項要求也適用於編譯式 wiki 這個競爭方案：編譯與檢索都是帶有紀錄的選取，而語料塞入視窗是稽核因素唯一能徹底排除的架構。

資料來源#

• Beyond RAG: Building Agentic Document Workflows with LlamaIndex — Pierre-Loic Doulcet（@hexapode，LlamaIndex），Beyond RAG: Building Agentic Document Workflows with LlamaIndex，AI Engineer Singapore 2026，116 張投影片／約 90 分鐘，2026-05-18 發布，並於 2026-05-25 經由 Jerry Liu（@jerryjliu0）的 X 串文發布，合併至同一原始檔（practitioner-opinion；直接廠商利益衝突——LlamaIndex 銷售 LlamaParse／LlamaCloud，並發布自家解析器領先的 ParseBench）。**此處的解析警告格外重要：**簡報刻意截取遭破壞的解析器輸出作為示範素材，我們的 docling 流程又對這些截圖做了 OCR，因此表格 3–5（DBS 年報擷取內容）及周邊雜亂文字刻意保留為無法閱讀的狀態——只可將它們引用為遭破壞的範例，不可用於引用數字。table-collapse 警告是誤報（議程列的原文是 2024 → 2026）；canary-recall 5/5。**已套用且為論點關鍵的圖片二階段檢視：**Glantz 的 12 個痛點管線圖、解析→檢索→綜合連鎖圖、bi-encoder／cross-encoder 連鎖圖、CRAG 評分與分支樹、描述與索引流程、結構化資料路由器、send_event／collect_events 扇出形狀、合約審查事件圖、持久 HITL 暫停，以及 ParseBench Fig. 5 都只存在於圖片中；上文記錄的 ParseBench 文字與圖表差異，只有檢視圖表才找得回來。Logo 牆的 OCR 雜訊（CCMCX、Opepsi、MIcheliN、tabst）是辨識錯誤，不是實體；重複的 9f98de06… 圖片是投影片模板背景
• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders — Deploying AI from pilot to production，Anthropic × Accenture，2026-09-11，38 頁，vendor-claim。本文只在考量 03 中引用其檢索架構稽核——文件唯一實質的技術建議。完整分析與證據限制見從試點到生產的落差