大家好，我是九歌AI。

在Reddit的AI_Agents版本刷到一個帖子，講的RAG系統在企業中的落地，覺得寫的不錯，翻譯共享給大家，英文原文直接讓DeepSeek翻譯后有些生硬，手動潤色了一下。

配圖：Google Nano Banana

【原貼】

Building RAG systems at enterprise scale (20K+ docs): lessons from 10+ enterprise implementations

【譯文】

背景與分享

過去一年，我們團隊一直為中型企業（100-1000人規模）搭建RAG系統，尤其是在制藥、金融、法律等強監管領域。實際落地后發現，真實項目的復雜度遠超傳統教程和理論介紹。

迄今為止，我們已經服務了超過10家中大型客戶，積累了不少“踩坑”與“填空”的經驗。今天就想和大家聊聊那些真正影響項目成敗的關鍵因素。

因素1：文檔質量

很多教程都假設PDF文本清晰、格式規范，但現實往往截然不同。企業文檔來源復雜、形態各異，有的甚至是上世紀九十年代的掃描件，OCR識別錯誤率高；而同一批文檔里又夾雜著帶有復雜圖表和表格的現代報告。如果統一用一種方式處理，效果肯定會大打折扣。

我們曾耗費大量時間排查為什么某些文檔檢索效果極差，后來才意識到：必須在對文檔做任何處理之前，先對它們的“質量”做分類。

于是我們設計了一套簡單的質量評估機制：

• 高質量PDF（文字提取準確）：應用更精細的解析策略
• 普通文檔（存在少量OCR錯誤）：常規分塊 + 文本清洗
• 低質量文檔（如掃描潦草的手寫體）：簡單分塊，并標記需人工復核

僅這一個改動，就比后續調整模型帶來的提升更明顯。

因素2：文本分塊大小

常見教程動不動就說“切成512 token，加點重疊就行”。但真實文檔是有結構的——研究論文、財務報告、合規文件，每一類都有其內在的章節邏輯和內容組織。機械分塊很容易把句子切斷、把不同主題的內容混在一起，導致檢索效果下降。

我們現在改用層次化分塊，尊重文檔原有結構：

• 文檔級：標題、作者、日期、類型等
• 章節級：摘要、方法、結果、討論…
• 段落級：200–400 token
• 句子級：應對高精度問答

一個實用技巧：根據查詢語句的復雜度動態選擇檢索層級。像“請總結”這樣的寬泛提問，用段落級即可；而“表3中的具體數值是多少”則需定位到句子甚至表格內部。我們通過檢測查詢中的關鍵詞（如“具體”“精確”“表X”等）自動切換檢索模式。

因素3：元數據設計

如果說我從這些項目中學到了一件事，那就是：沒有好的元數據，再好的模型也發揮不出價值。

企業查詢往往帶有強烈的場景屬性。比如“兒科研究”和“老年用藥”涉及的文件完全不同。因此我們花大量時間與客戶一起設計定制化的元數據體系：

• 制藥場景：文檔類型、藥物分類、人群年齡段、監管機構、治療領域…
• 金融場景：時間周期、財務指標（收入、利潤等）、業務線、地區…

一個小建議：盡量別用大模型直接提取元數據——效果不穩定。簡單關鍵詞匹配或者規則方法，很多時候更靠譜。比如查詢中出現“FDA”，我們就自動篩選 regulatory_category = "FDA"。

因素4：語義搜索

在專業化領域中，純語義搜索的失敗率比想象中更高（我們觀察到15%–20%），尤其容易出現以下問題：

• 術語/縮寫歧義：例如“CAR”在不同學科代表完全不同的概念
• 精確查詢失效：比如“請找出Table 3中第二行的數據”，語義搜索容易返回相似內容而非具體答案
• 文檔間引用丟失：很多文檔需互相參照才完整，但語義檢索難以建立這種關聯

我們的應對策略是“混合檢索”：

• 建立圖結構維護文檔間關系
• 語義檢索后追加關聯文檔檢索
• 專業術語詞典+規則化解歧
• 關鍵數據查詢走專用檢索通道

因素5：開源大模型

雖然像GPT-4這樣的API模型效果強大，但企業項目有很多隱藏限制：

• 成本：文檔量大了之后API調用費用非?？捎^
• 數據合規：金融、醫療等行業不允許數據出境
• 專業術語：通用模型容易在領域專有名詞上“幻覺”或錯誤

Qwen-32B經過領域微調后，表現出色：

• 成本約為GPT-4的1/5
• 支持本地部署，滿足合規要求
• 可針對專業術語做定向優化
• 響應穩定，不受外部限流影響

微調方法其實不復雜：我們使用高質量的領域問答對，做有監督微調。關鍵是要保證訓練數據干凈、匹配真實場景。

因素6：攻克表格

企業文檔充斥大量表格：財務報表、臨床試驗數據、合規條款對照表……傳統RAG要么直接跳過表格，要么把它們轉成純文本丟失了所有結構信息——而這部分又常常是文檔中的核心內容。

我們現在這樣處理：

• 獨立檢測和提取表格
• 按復雜度分級處理：簡單表格轉CSV，復雜表格保留層次結構
• 為表格內容單獨建立檢索索引
• 同時支持“語義查詢”和“精確定位”

因素7：工程能力

模型算法雖重要，但真正決定項目成敗的往往是工程實現：

• 并發請求的管理
• GPU內存與推理效率的平衡
• 系統穩定性和響應延遲

很多客戶已有現成的GPU資源，反而本地化部署比云方案更順暢。我們通常部署2–3個模型分別處理生成、嵌入和元數據提取，并通過量化、批處理等方式優化資源使用。

干貨總結

1. 先做文檔質量分級，再設計處理流程

2. 元數據設計 > 模型選型

3. 混合檢索 > 純語義檢索

4. 必須處理好表格

5. 工程穩定性決定項目成敗

肺腑之言

企業級RAG的真正難點，大多不在模型本身，而在于文檔預處理、領域知識融入和系統穩定性保障。現在很多企業都有強烈的需求，但往往低估了實現的復雜性。

雖然過程中會遇到無數意想不到的坑，但一旦系統真正運轉起來，帶來的效率提升是巨大的——從“反復翻文檔”變成“一鍵獲取答案”，這對專業團隊來說價值非凡。

本文轉載自?????九歌AI大模型?????  作者：九歌AI