RAG 準確率取決於文件類型

企業導入 AI 問答系統前的工程現實

供應商演示時，AI 問答系統的準確率通常超過九成。這個數字本身並無問題，問題在於：它是在什麼文件上測試出來的？

準確率不是單一指標。它高度依賴文件結構、切割方式，以及用戶提問的形式。同一套系統，放在不同的文件環境下，表現可以相差極大。

文件類型決定了準確率的上限

實際企業環境中，文件通常屬於三種結構類型之一，各自需要不同的處理方式。

清單型文件（例如：產品規格表、價目表、條款細則）

這類文件的特徵是：資訊密度高，每一行都有獨立意義，段落之間沒有敘述性連接。若按段落切割，容易將相關條目分開，導致檢索時只取回部分資訊。對於篇幅可控的清單型文件，較可靠的做法是整份注入上下文，而非切割後檢索。

段落型文件（例如：操作手冊、合規政策、產品說明書）

這類文件按章節組織，每個段落有明確主題邊界。按段落切割後建立向量索引，通常能取得較好的檢索準確率——前提是段落本身結構清晰，且每段主題不過於分散。

語意型文件（例如：電郵內文、會議記錄、客戶往來訊息）

這類文件的主題邊界不依賴格式，而依賴語意轉折。單純按字數或換行切割，常常將同一個討論事項分割到不同片段，或將無關話題合併在一個向量中。按語意邊界切割的工程成本較高，但在此類文件上是必要的。

三種類型同時存在於同一個企業的知識庫中，是常態，不是例外。一套針對單一文件類型優化的切割策略，套用到混合環境後，準確率通常會顯著下滑。

向量搜尋的一個根本限制

RAG 系統的工作原理，是將用戶的提問轉換成向量，在文件庫中尋找語意最接近的片段，再交給語言模型生成答案。這個機制的設計前提是：用戶提問的語意，與文件中的相關內容語意相近。

這個前提在很多情況下成立，但有一類情況會系統性失效：開放式問題。當用戶問「這份合約有什麼需要注意的地方？」時，這個問題本身沒有特定語意錨點。向量搜尋無法判斷「需要注意的地方」對應文件中的哪些段落——因為文件從未用這個角度組織過。系統可能回傳一個語意接近但實際上不相關的段落，語言模型再以此生成一個聽起來合理、但資訊基礎錯誤的答案。

這不是模型的失誤，而是向量檢索在開放式查詢下的結構性限制。識別哪些類型的提問屬於這個盲區，是系統設計的一部分，而非事後修補的問題。

電郵與混合文件環境：最接近真實業務的場景

許多香港企業的業務知識，實際上分散在以下幾個地方：Gmail 收件箱中的客戶往來電郵；以 PDF 傳送的報價單、合約、核數報告；以附件形式接收的 Excel 報表或 Word 文件；部門之間的 WhatsApp 訊息記錄。這個組合幾乎是香港中小企的標準現實。問題在於，每一種來源的結構都不相同，處理方式也各有差異。

以電郵為例：Gmail 提供 Google Apps Script 介面，可以自動化附件提取、郵件正文解析，以及與後端系統的整合。但電郵正文屬於語意型文件，切割策略需要對應處理；附件若為 PDF，又涉及 PDF 解析的準確率問題（掃描版 PDF 與原生 PDF 的處理成本差距可以相差數倍）。將這些來源整合到同一個可查詢系統，需要為每種文件類型制定獨立的攝入流程，而非一個通用管道。供應商提案中若只有一種「AI問答系統」而未說明各文件類型的處理策略，是值得追問的缺口。

評估準確率之前，先確認測試條件

在洽談 AI 問答系統之前，以下四個問題能幫助你判斷供應商提供的準確率數字是否適用於你的環境：

一、測試文件的類型是什麼？若演示使用的是結構整齊的政策文件，而你的實際環境以電郵和混合 PDF 為主，兩者的準確率不具可比性。

二、切割策略是否針對你的文件類型設計？要求供應商說明對清單型、段落型、語意型文件分別使用什麼切割邏輯，以及混合環境下如何處理。

三、開放式問題的覆蓋範圍是什麼？要求以你的實際業務問題測試，而非供應商預設的示範問題。

四、電郵和附件的攝入流程是否已納入設計？若你的業務大量依賴 Gmail 往來，要確認系統能處理電郵正文、PDF 附件，以及不同附件格式的混合情況。

準確率九成的承諾，只有在你的文件上測出來，才算數。如需了解 RAG 與 Fine-tuning 的決策框架，可參考RAG vs Fine-tuning 企業決策指南；如需了解 Gmail PDF 自動化流程，可參考Gmail PDF 自動化：以 Google Apps Script 將市場報告送達決策者。