面向非ML工程師的RAG管道：領域專家如何建構檢索系統

最了解資料的人很少是建構檢索系統的人。心臟科醫生知道出院摘要中哪些部分對追蹤風險評估很重要。建築工程師知道工程量清單中哪些項目表明範圍蔓延。合規官知道監管文件中哪些條款預示著重大風險。但當需要建構一個檢索和呈現這些資訊的RAG管道時，這些領域專家退到一旁，將工作交給一位不具備他們專業知識的ML工程師。

這是當今企業AI應用的核心摩擦。面向非ML工程師的最佳RAG管道建構器在大多數組織中並不存在，因為工具假定使用者精通Python、有終端存取權限，並且熟悉嵌入模型、向量資料庫和分塊策略。結果是一個瓶頸：最接近問題的人要等待數週，讓ML團隊實現他們一個下午就能定義的東西——如果工具允許的話。

拖慢每個RAG專案的知識鴻溝

考慮一個我們在企業部署中反覆看到的真實模式。

一家中型律所的法務團隊想要在15年的合約檔案上建構一個檢索系統。他們需要系統在律師起草新協議時呈現相關的先例條款。律師們確切知道哪些條款類型重要、如何分類，以及什麼構成有意義的匹配而非表面匹配。

但律師們無法建構管道。他們撰寫需求文件。ML工程師閱讀後進行解讀，用LangChain建構管道，選擇分塊策略，選擇嵌入模型並部署。律師測試後發現某些條款類型的檢索品質不佳，提交回饋。ML工程師調整分塊參數。又一輪測試。又一輪回饋。整個週期需要六到八週。

瓶頸不是算力，不是模型品質，而是理解領域的人和理解工具的人之間的翻譯層。

這個模式在各產業重複出現：

臨床團隊審查病患筆記時，需要檢索系統能理解「提及的狀況」和「已診斷的狀況」之間的區別。沒有臨床培訓的ML工程師對兩者一視同仁。

土木工程師審查工程量清單時，需要檢索系統能區分標準項目和隱藏在修訂文件中的變更令。這種細微差別對領域外的人來說是不可見的。

金融分析師在財報電話會議記錄上建構檢索時，需要系統對前瞻性聲明和歷史業績摘要進行不同的權重處理。這種區別需要領域知識，再多的提示工程也無法替代。

在每種情況下，領域專家擁有判斷力，ML工程師擁有工具。專案停滯在兩者之間的鴻溝中。

為什麼傳統RAG工具將領域專家排斥在外

建構RAG管道的標準方法涉及多個步驟，每個步驟都需要程式設計知識：

文件攝取需要撰寫腳本來解析PDF、擷取文字、處理掃描文件的OCR以及管理中繼資料。大多數框架假定你會用Python來完成這些工作。

分塊需要選擇策略——固定大小、遞迴、語義——並調整分塊大小和重疊等參數。決策取決於文件類型，但實作需要程式碼。

嵌入需要選擇模型、設定模型並產生向量表示。一些框架對此進行了抽象，但設定仍然在程式碼或YAML檔案中進行。

檢索需要設置向量儲存、設定相似性搜尋參數，通常還需要實作帶關鍵字匹配的混合搜尋。同樣需要程式碼。

品質評估需要建構評估資料集、執行檢索測試以及計算召回率和精確率等指標。這個步驟經常被完全跳過，因為它需要最大的工程投入。

每個步驟單獨來看並非不可能的複雜。但合在一起，它們形成了一個只有能夠熟練撰寫和除錯Python的人才能建構和修改的管道。結果是，使用大多數現有工具，無程式碼建構RAG管道實際上是不可能的。

當領域專家可以直接建構時會發生什麼改變

這個轉變不是要降低技術門檻。而是要改變介面，讓擁有正確判斷力的人能夠做出正確的決策。

視覺化管道建構器——比如Ertas畫布——讓領域專家透過拖曳節點來建構RAG管道的每個階段。文件攝取、分塊策略、嵌入模型選擇、檢索設定和品質評估變成了可以連接、設定和測試的視覺化元件，無需撰寫任何Python程式碼。

以下是上述三個場景的實際效果：

法務團隊將合約檔案拖入攝取節點，選擇針對法律文件最佳化的分塊策略，並將其連接到嵌入節點。他們用已知答案的範例查詢測試檢索效果。當某些條款類型回傳不佳的結果時，他們直接調整分塊參數——更改重疊率、對附錄切換到語義分塊——然後重新執行測試。回饋迴圈從數週縮短到數小時。

臨床團隊在出院摘要上建構管道。他們使用Quality Scorer來識別哪些分塊產生了低信心度的檢索結果。他們發現包含藥物清單的分塊被匹配到了診斷查詢。他們調整分塊邊界，將藥物部分與診斷敘述分開。無需提交工單，無需諮詢ML工程師。

土木工程團隊設定跨越數百個工程量清單檔案和修訂記錄的專案文件檢索。他們設置中繼資料篩選器，使檢索能區分原始範圍和變更令。當Quality Scorer標記出某些專案階段的不一致結果時，他們細化中繼資料標記並重新評估——所有操作都在同一視覺化介面中完成。

Quality Scorer：領域專家真正能理解的回饋

建構無Python的RAG管道的最大障礙之一是評估。傳統評估需要撰寫腳本來計算檢索指標、建構黃金資料集並解讀統計輸出。

Ertas的Quality Scorer用視覺化、可解讀的回饋取代了這一切。在領域專家建構和測試管道之後，Quality Scorer向他們展示：

• 哪些查詢回傳高信心度結果，哪些沒有
• 哪些文件分塊被最頻繁檢索，哪些從未被呈現
• 管道在哪裡產生矛盾或低相關性的結果

這些回饋以領域專家能理解的術語呈現——不是F1分數和平均倒數排名，而是對哪些查詢有效、哪些無效以及可能原因的直白評估。醫生可以看著輸出說：「這個管道混淆了藥物副作用和已診斷的症狀」，然後相應地修正分塊策略。

誰應該擁有RAG管道

問題不在於領域專家能否建構RAG管道。有了合適的介面，他們顯然可以。問題在於組織是否願意重新調整所有權，讓擁有領域知識的人也能控制依賴這些知識的檢索系統。

當前的模式——領域專家定義需求，ML工程師實作——建立了一個引入延遲、誤解和不必要迭代的翻譯層。理解資料的人與檢索資料的系統之間的每一個中間步驟，都是品質下降的機會。

當律師可以建構和修改自己的合約檢索管道時，檢索品質會提高，因為做出分塊和設定決策的人真正理解文件。當臨床醫生可以調整病患筆記的索引方式時，系統反映的是臨床判斷而非工程師的近似推測。

這不是理論上的改進。將管道所有權轉移給領域專家的組織看到了更快的迭代週期、更高的領域特定查詢檢索準確率，以及技術團隊和非技術團隊之間更少的來回溝通。

無需ML背景即可開始

無需Python經驗建構RAG管道現在是一個實際可行的現實，而非未來的願景。使用視覺化管道建構器的過程遵循一個直接的順序：

1. 上傳您的文件 —— PDF、臨床筆記、合約、工程規範，您的領域產生的任何文件
2. 視覺化設定分塊 —— 選擇策略、調整參數、預覽文件如何被分割
3. 選擇嵌入模型 —— 從適合您文件類型和語言的預設選項中選擇
4. 用真實查詢測試 —— 執行您團隊實際提出的查詢，而非合成基準測試
5. 檢視Quality Scorer回饋 —— 識別薄弱環節並調整設定
6. 迭代 —— 根據領域特定的回饋，優化分塊、中繼資料和檢索設定

整個過程在視覺化畫布上完成。無需終端。無需套件管理器。無需除錯堆疊追蹤。

面向非ML工程師的最佳RAG管道建構器是尊重領域專家已有知識並消除阻礙他們直接應用這些知識的障礙的工具。資料屬於專家。檢索系統也應如此。