<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Enterprise RAG on GuanLin's Latent Space</title><link>https://blog.my-techcore.com/tags/enterprise-rag/</link><description>Recent content in Enterprise RAG on GuanLin's Latent Space</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>© 2026 GuanLin's Latent Space. All rights reserved.</copyright><lastBuildDate>Fri, 29 May 2026 20:00:00 +0800</lastBuildDate><atom:link href="https://blog.my-techcore.com/tags/enterprise-rag/index.xml" rel="self" type="application/rss+xml"/><item><title>Naive RAG 已死？Advanced RAG 不是換模型——四篇論文的架構思考</title><link>https://blog.my-techcore.com/posts/advanced-rag-new-standard-overview/</link><pubDate>Fri, 29 May 2026 20:00:00 +0800</pubDate><guid>https://blog.my-techcore.com/posts/advanced-rag-new-standard-overview/</guid><description>&lt;blockquote>&lt;p>這篇文章是四篇技術解析系列的入口，包含完整的論文對比框架與工程實踐建議。如果想把這些技術真正用在工作上，歡迎繼續讀下去，並點開各篇連結。&lt;/p>&lt;/blockquote>&lt;hr>

&lt;h2 class="relative group">一個讓人好奇的問題
 &lt;div id="一個讓人好奇的問題" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e4%b8%80%e5%80%8b%e8%ae%93%e4%ba%ba%e5%a5%bd%e5%a5%87%e7%9a%84%e5%95%8f%e9%a1%8c" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>
&lt;p>有沒有想過，公司現在跑的 RAG 系統，在「真實文件」上的準確率是多少？&lt;/p>
&lt;p>指的不是乾淨的 Wikipedia 段落，也不是精心挑選的 benchmark，是企業實際業務文件：財務年報、法規手冊、技術規格書、會議記錄。這些文件通常同時包含大量文字敘述、多層次的表格、過時的數據，以及時間敏感的政策資訊。&lt;/p>
&lt;p>我最近閱讀了四篇 2025–2026 年發表的頂尖 RAG 論文，得到了一個有點驚訝的答案。&lt;/p>
&lt;p>&lt;strong>傳統 RAG 在真實異質文件上的 HiT@1，可以低到 1.59%。&lt;/strong>&lt;/p>
&lt;p>這不是劣質系統。這是企業通用的標準向量搜尋方法，套用在包含層級表格的真實文件上的表現。&lt;/p>
&lt;p>這四篇論文，從四個不同維度回答了「為什麼會這樣」，以及「我們應該怎麼做」：&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>論文&lt;/th>
 &lt;th>核心問題&lt;/th>
 &lt;th>解法方向&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;strong>TableRAG&lt;/strong>（Huawei Cloud, arXiv 2506.10380）&lt;/td>
 &lt;td>表格被拍扁後，跨列計算完全失準&lt;/td>
 &lt;td>讓資料庫直接計算，取代 LLM 語意猜測&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>MixRAG&lt;/strong>（BIT/Zhejiang, KDD 2026）&lt;/td>
 &lt;td>層級表格的行列語意在向量化時消失&lt;/td>
 &lt;td>H-RCL 層級表示法保留結構路徑&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>UniversalRAG&lt;/strong>（KAIST, arXiv 2504.20734）&lt;/td>
 &lt;td>不同模態強迫共享 Embedding 空間導致偏差&lt;/td>
 &lt;td>模態感知路由 + 粒度動態選擇&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>MRAG&lt;/strong>（NTU/NYU, arXiv 2412.15540）&lt;/td>
 &lt;td>日期匹配不等於時間推理，現有系統幾乎不懂&lt;/td>
 &lt;td>語意分數 × 時序計分規則的混合排名&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>這篇文章是這四篇RAG系列的入口，主要是為了先建立一個全局視野：&lt;strong>Advanced RAG 到底在解決什麼問題，這四篇論文各自站在哪個位置，它們合在一起說了什麼。&lt;/strong>&lt;/p></description></item><item><title>時間推理是 RAG 的弱點——MRAG 如何用計分規則解決時序問題</title><link>https://blog.my-techcore.com/posts/mrag-deep-dive/</link><pubDate>Fri, 29 May 2026 18:00:00 +0800</pubDate><guid>https://blog.my-techcore.com/posts/mrag-deep-dive/</guid><description>&lt;blockquote>&lt;p>這篇文章是「Advanced RAG 架構思考」系列的第四篇技術解析，對應的綜述概覽在&lt;a href="https://blog.my-techcore.com/posts/advanced-rag-new-standard-overview/" >這裡&lt;/a>。本篇聚焦 MRAG（arXiv:2412.15540），完整拆解 TEMPRAGEVAL benchmark 的設計動機、MRAG 三模組架構，以及時序計分規則的具體實現邏輯。&lt;/p>&lt;/blockquote>&lt;hr>

&lt;h2 class="relative group">前言
 &lt;div id="前言" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%89%8d%e8%a8%80" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>
&lt;p>「2021 年 5 月 6 日，英國首相是誰？」&lt;/p>
&lt;p>正確答案是 Boris Johnson。他在 2019 年 7 月 24 日就任，2022 年 9 月才離職。所以 2021 年 5 月 6 日，他確實在任。&lt;/p>
&lt;p>但如果你的 RAG 系統去搜尋這個問題，它很可能找到 Nicola Sturgeon 的相關文件——因為她在 2021 年 5 月 6 日蘇格蘭議會選舉中獲勝的新聞，正好包含「2021 年 5 月 6 日」這個精確日期，而 RAG 系統的日期匹配機制把它識別為「高度相關的文件」。&lt;/p>
&lt;p>系統輸出：「Nicola Sturgeon」。&lt;/p>
&lt;p>這是一個自信、清晰、完全錯誤的答案。更麻煩的是，如果你不知道正確答案，你很難判斷它是錯的——畢竟它提供了一個「真實事件」（Sturgeon 確實在那天贏得選舉）作為依據。&lt;/p></description></item><item><title>H-RCL 如何讓向量搜尋讀懂層級表格——MixRAG 框架深度解析</title><link>https://blog.my-techcore.com/posts/mixrag-deep-dive/</link><pubDate>Fri, 22 May 2026 14:00:00 +0800</pubDate><guid>https://blog.my-techcore.com/posts/mixrag-deep-dive/</guid><description>&lt;blockquote>&lt;p>這篇文章是「Advanced RAG 架構思考」系列的第二篇技術解析，對應的綜述概覽在&lt;a href="https://blog.my-techcore.com/posts/advanced-rag-new-standard-overview/" >這裡&lt;/a>。本篇聚焦 MixRAG（KDD 2026, arXiv:2504.09554），說明 H-RCL 表示法的數學定義、DocRAGLib 資料集、雙階段檢索設計，以及為什麼這一篇和 TableRAG 解決的是不同的問題。&lt;/p>&lt;/blockquote>&lt;hr>

&lt;h2 class="relative group">前言：同樣是表格問題，但不一樣
 &lt;div id="前言同樣是表格問題但不一樣" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%89%8d%e8%a8%80%e5%90%8c%e6%a8%a3%e6%98%af%e8%a1%a8%e6%a0%bc%e5%95%8f%e9%a1%8c%e4%bd%86%e4%b8%8d%e4%b8%80%e6%a8%a3" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>
&lt;p>讀完 TableRAG 之後，你可能會想：「好，我把表格放進 SQL 資料庫，問計算問題就交給 SQL，問題不就解決了？」&lt;/p>
&lt;p>MixRAG 說：還沒。&lt;/p>
&lt;p>TableRAG 解決的是「&lt;strong>計算&lt;/strong>」問題——如何在完整表格上執行精確計算。但 MixRAG 解決的是「&lt;strong>檢索&lt;/strong>」問題——當文件庫裡有 2,178 份文件，每份文件都包含文字和多張層級表格時，你怎麼找到「這個問題應該從哪份文件的哪張表格回答」？&lt;/p>
&lt;p>這是 RAG 中的&lt;strong>文件選擇&lt;/strong>問題，不是問答問題。而且在加入層級表格之後，這個選擇問題變得格外困難。&lt;/p>
&lt;p>MixRAG 是在 KDD 2026 上發表出來的，它的核心貢獻可以分三層理解：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>DocRAGLib&lt;/strong>：第一個真正包含層級表格的異質文件 RAG benchmark&lt;/li>
&lt;li>&lt;strong>H-RCL 表示法&lt;/strong>：讓層級表格在向量化後保留結構語意&lt;/li>
&lt;li>&lt;strong>三模組框架&lt;/strong>：從資料表示到跨模態檢索到多步推理的完整架構&lt;/li>
&lt;/ol>
&lt;hr>

&lt;h2 class="relative group">核心問題：為什麼層級表格特別難
 &lt;div id="核心問題為什麼層級表格特別難" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e6%a0%b8%e5%bf%83%e5%95%8f%e9%a1%8c%e7%82%ba%e4%bb%80%e9%ba%bc%e5%b1%a4%e7%b4%9a%e8%a1%a8%e6%a0%bc%e7%89%b9%e5%88%a5%e9%9b%a3" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>
&lt;p>在進入 H-RCL 的細節之前，必須先理解「層級表格（Hierarchical Table）」的特殊性。&lt;/p></description></item><item><title>一個 RAG 搞定文字、圖片、表格與影片——UniversalRAG 模態路由設計深度解析</title><link>https://blog.my-techcore.com/posts/universalrag-deep-dive/</link><pubDate>Fri, 15 May 2026 16:00:00 +0800</pubDate><guid>https://blog.my-techcore.com/posts/universalrag-deep-dive/</guid><description>&lt;blockquote>&lt;p>這篇文章是「Advanced RAG 架構思考」系列的第三篇技術解析，對應的綜述概覽在&lt;a href="https://blog.my-techcore.com/posts/advanced-rag-new-standard-overview/" >這裡&lt;/a>。本篇聚焦 UniversalRAG（arXiv:2504.20734），解析模態差距問題的理論基礎、模態路由的設計邏輯，以及在 10 個 benchmark 上的全面驗證。&lt;/p>&lt;/blockquote>&lt;hr>

&lt;h2 class="relative group">前言：一個問題，三種可能的答案來源
 &lt;div id="前言一個問題三種可能的答案來源" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%89%8d%e8%a8%80%e4%b8%80%e5%80%8b%e5%95%8f%e9%a1%8c%e4%b8%89%e7%a8%ae%e5%8f%af%e8%83%bd%e7%9a%84%e7%ad%94%e6%a1%88%e4%be%86%e6%ba%90" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>
&lt;p>給你一個問題：「USNS Carl Brashear 軍艦下水典禮上懸掛的是什麼顏色的氣球？」&lt;/p>
&lt;p>這個問題的答案，不在任何文字段落裡。答案在一張典禮現場的&lt;strong>照片&lt;/strong>裡——紅色、白色和藍色。&lt;/p>
&lt;p>如果你的 RAG 系統只有文字語料庫，它會努力搜尋、找到一些關於這艘船的文字描述，然後告訴你「藍色和金色的氣球」（海軍傳統顏色的語意聯想），或者直接說「文件中找不到相關資訊」。&lt;/p>
&lt;p>如果你的系統有圖片語料庫，但架構是「把圖片和文字都放進同一個 Embedding 空間」呢？可能更糟——因為&lt;strong>模態差距（Modality Gap）&lt;/strong>，文字查詢會偏向文字結果，圖片的正確答案反而被壓制在排名後面。&lt;/p>
&lt;p>這就是 KAIST 的 UniversalRAG（arXiv:2504.20734）試圖解決的問題。&lt;/p>

&lt;figure>
 &lt;img class="my-0 rounded-md" src="https://blog.my-techcore.com/images/diagrams/04-universalrag-intro.svg" alt="三種 RAG 架構對比" />
 
 &lt;figcaption>同一個問題，三種架構給出不同結果&lt;/figcaption>
 &lt;/figure>
&lt;hr>

&lt;h2 class="relative group">核心挑戰：模態差距的本質
 &lt;div id="核心挑戰模態差距的本質" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e6%a0%b8%e5%bf%83%e6%8c%91%e6%88%b0%e6%a8%a1%e6%85%8b%e5%b7%ae%e8%b7%9d%e7%9a%84%e6%9c%ac%e8%b3%aa" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>

&lt;figure>
 &lt;img class="my-0 rounded-md" src="https://blog.my-techcore.com/images/diagrams/04-universalrag-routing.svg" alt="統一 Embedding 空間的模態差距問題 vs. UniversalRAG 的模態感知路由" />
 
 &lt;figcaption>左：統一 Embedding 方法偏向文字結果。右：UniversalRAG 路由器分配到正確模態空間（Modality Acc 95.28%）&lt;/figcaption>
 &lt;/figure>
&lt;p>UniversalRAG 的最重要貢獻之一，是把「模態差距」這個現象做了精確的理論和實驗驗證。&lt;/p></description></item><item><title>SQL 才是 RAG 操作表格的正確選項——TableRAG 框架解析</title><link>https://blog.my-techcore.com/posts/tablerag-deep-dive/</link><pubDate>Fri, 08 May 2026 12:00:00 +0800</pubDate><guid>https://blog.my-techcore.com/posts/tablerag-deep-dive/</guid><description>&lt;blockquote>&lt;p>這篇文章是「Advanced RAG 架構解析」系列的第一篇技術解析，對應的綜述概覽在&lt;a href="https://blog.my-techcore.com/posts/advanced-rag-new-standard-overview/" >這裡&lt;/a>。本篇聚焦 TableRAG（arXiv:2506.10380），逐步拆解它的架構設計、HeteQA benchmark 數據，以及工程實踐中值得借鑒的設計方式。&lt;/p>&lt;/blockquote>&lt;hr>

&lt;h2 class="relative group">前言
 &lt;div id="前言" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%89%8d%e8%a8%80" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>
&lt;p>某人問 RAG 系統：「2008 年由 Activision 發行且仍在上架的遊戲，占全部仍在上架遊戲的百分比是多少？」&lt;/p>
&lt;p>系統回答：&lt;strong>50%&lt;/strong>。&lt;/p>
&lt;p>正確答案是：&lt;strong>20%&lt;/strong>。&lt;/p>
&lt;p>這個錯誤不是因為模型不夠聰明，也不是因為向量搜尋失效——相關的表格確實被找到了。問題在於：RAG 只找到了「部分表格片段」，然後讓 LLM 在這殘缺的資料上估算百分比。LLM 盡力了，但它總不可能從片段資料算出全局正確的統計數字。&lt;/p>
&lt;p>這就是 Huawei Cloud 在 TableRAG（arXiv:2506.10380）論文中，為所有現有 RAG 方法找出的根本性缺陷，他們稱這為「&lt;strong>缺乏全局視角（Lack of Global View）&lt;/strong>」。&lt;/p>
&lt;p>這篇文章會拆解 TableRAG 的架構設計，分析它在三個 benchmark 上的數據表現，探討實驗告訴我們的事，並思考這框架在真實工程場景中的落地意義。&lt;/p>
&lt;hr>

&lt;h2 class="relative group">核心問題：為什麼 Naive RAG 操作表格會失敗
 &lt;div id="核心問題為什麼-naive-rag-操作表格會失敗" class="anchor">&lt;/div>
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e6%a0%b8%e5%bf%83%e5%95%8f%e9%a1%8c%e7%82%ba%e4%bb%80%e9%ba%bc-naive-rag-%e6%93%8d%e4%bd%9c%e8%a1%a8%e6%a0%bc%e6%9c%83%e5%a4%b1%e6%95%97" aria-label="">#&lt;/a>
 &lt;/span>
 
&lt;/h2>
&lt;p>TableRAG 論文一開頭就點出現有 RAG 方法處理表格時的兩個根本問題，先弄懂這兩點，後面的設計才看得比較懂。&lt;/p></description></item></channel></rss>