25 年以來寫了 55 篇技術 Blog，字數也累計超過 50 萬字。每篇內容背后都是幾十甚至上百個小時的項目工程實踐的經驗提煉，雖然原創性沒話說，但還是產出效率太低，以及也難免受限于個人的經驗和水平。

So，從這篇開始，我會把日常閑暇時觀摩的一些海外優質內容整理和加工后，附上自己的不同觀察和思考也通過文章或者視頻的形式發布出來，給各位做個參考。主要聚焦在 Reddit、Medium、X、Youtube 等平臺。這篇就以 Reddit 上 r/AI_Agents 中一個月前發布的一篇有 905 upvotes 的帖子做個翻譯整理。

Blog 原地址：https://www.reddit.com/r/AI_Agents/comments/1nbrm95/building_rag_systems_at_enterprise_scale_20k_docs/ 

這篇試圖說清楚：

原帖的中文翻譯（人話版）、原帖中四個工程要點的代碼示例及實際應用建議、以及帖子評論區精華部分的內容節選。

以下，enjoy:

1、原帖子翻譯

企業級 RAG 系統實戰（2萬+文檔）：10 個項目踩過的坑

原文來自 Reddit，作者在受監管行業（制藥、金融、法律）為中型企業（100-1000 人）構建了 10+ 個 RAG 系統

過去一年我一直在做企業級 RAG 系統，服務的客戶包括制藥公司、銀行、律所、咨詢公司。說實話，這玩意兒比任何教程說的都難太多了。我想分享一些真正重要的東西，而不是網上那些基礎教程。

先說背景：這些公司手里都有 1 萬到 5 萬份文檔，堆在 SharePoint 或者 2005 年的文檔管理系統里。不是什么精心整理的數據集，也不是知識庫——就是幾十年積累下來的業務文檔，現在需要能被搜索到。

1.1文檔質量檢測：沒人說的關鍵環節

這是我最大的發現。大多數教程都假設你的 PDF 是完美的。現實是：企業文檔就是一坨垃圾。

我有個制藥客戶，他們有 1995 年的研究論文，是打字機打出來再掃描的。OCR 基本不行。還混著現代的臨床試驗報告，500 多頁，里面嵌了各種表格和圖表。你試試對這兩種文檔用同一套分塊策略，保證給你返回一堆亂七八糟的結果。

我花了幾周調試，搞不懂為什么有些文檔效果很差，有些又很好。最后意識到：必須先給文檔質量打分，再決定怎么處理：

• 干凈的 PDF（文本提取完美）→ 完整的層級化處理
• 一般的文檔（有點 OCR 問題）→ 基礎分塊 + 清理
• 垃圾文檔（掃描的手寫筆記）→ 簡單固定分塊 + 標記人工復查

我做了個簡單的評分系統，看文本提取質量、OCR 瑕疵、格式一致性，然后根據分數把文檔送到不同的處理流程。

"This single change fixed more retrieval issues than any embedding model upgrade."

這一個改動解決的檢索問題，比升級 embedding 模型管用得多。

1.2固定大小分塊基本是錯的

所有教程都說："把所有東西切成 512 token，加點重疊就行！"

現實是：文檔是有結構的。研究論文的方法論部分和結論部分不一樣。財報有執行摘要，也有詳細表格。如果無視結構，你會得到切到一半的句子，或者把不相關的概念混在一起。

我必須構建層級化分塊（Hierarchical Chunking），保留文檔結構：

• 文檔級（標題、作者、日期、類型）
• 章節級（摘要、方法、結果）
• 段落級（200-400 tokens）
• 句子級（用于精確查詢）

核心思路：查詢的復雜度決定檢索的層級。寬泛的問題在段落級檢索。精確的問題比如"表 3 里的劑量是多少？"需要句子級精度。

我用簡單的關鍵詞檢測——像"exact"（精確）、"specific"（具體）、"table"（表格）這些詞會觸發精準模式。如果置信度低，系統會自動下鉆到更精確的分塊。

1.3元數據架構比你的 Embedding 模型更重要

這部分我花了 40% 的開發時間，但 ROI 是最高的。

大多數人把元數據當成事后想起來的東西。但企業查詢的上下文非常復雜。一個制藥研究員問"兒科研究"，需要的文檔和問"成人群體"的完全不同。

我為不同領域構建了專門的元數據模式：

制藥文檔：

• 文檔類型（研究論文、監管文件、臨床試驗）
• 藥物分類
• 患者人口統計（兒科、成人、老年）
• 監管類別（FDA、EMA）
• 治療領域（心血管、腫瘤）

金融文檔：

• 時間周期（2023 Q1、2022 財年）
• 財務指標（收入、EBITDA）
• 業務部門
• 地理區域

別用 LLM 提取元數據——它們不靠譜。簡單的關鍵詞匹配效果好得多。查詢里有"FDA"？就過濾 regulatory_category: "FDA"。提到"兒科"？應用患者群體過濾器。

從每個領域 100-200 個核心術語開始，根據匹配不好的查詢逐步擴展。領域專家通常很樂意幫忙建這些列表。

1.4語義搜索失效的時候（劇透：很多）

純語義搜索失效的頻率比大家承認的高得多。在制藥和法律這種專業領域，我看到的失敗率是 15-20%，不是大家以為的 5%。

讓我抓狂的主要失敗模式：

縮寫混淆： "CAR" 在腫瘤學里是"嵌合抗原受體"，但在影像論文里是"計算機輔助放射學"。相同的 embedding，完全不同的意思。這讓我頭疼死了。

精確技術查詢： 有人問"表 3 里的確切劑量是多少？"語義搜索會找到概念上相似的內容，但會錯過具體的表格引用。

交叉引用鏈： 文檔之間不斷互相引用。藥物 A 的研究引用了藥物 B 的交互數據。語義搜索完全丟失這些關系網絡。

解決方案： 構建混合方法。用圖層（Graph Layer）在處理時跟蹤文檔關系。語義搜索之后，系統會檢查檢索到的文檔是否有相關文檔有更好的答案。

對于縮寫，我做了上下文感知的擴展，用領域專用的縮寫數據庫。對于精確查詢，關鍵詞觸發會切換到基于規則的檢索來獲取特定數據點。

1.5為什么我選開源模型（具體是 Qwen）

大多數人以為 GPT-4o 或 o3-mini 總是更好。但企業客戶有些奇怪的約束：

• 成本： 5 萬份文檔 + 每天幾千次查詢，API 費用會爆炸
• 數據主權： 制藥和金融不能把敏感數據發到外部 API
• 領域術語： 通用模型會在沒訓練過的專業術語上產生幻覺

Qwen QWQ-32B 在領域微調后效果出奇的好：

• 比 GPT-4o 便宜 85%（大批量處理）
• 一切都在客戶基礎設施上
• 可以在醫療/金融術語上微調
• 響應時間穩定，沒有 API 限流

微調方法很直接——用領域問答對做監督訓練。創建像"藥物 X 的禁忌癥是什么？"這樣的數據集，配上實際的 FDA 指南答案。基礎的監督微調比 RAFT 這種復雜方法效果更好。關鍵是要有干凈的訓練數據。

1.6表格處理：隱藏的噩夢

企業文檔里到處都是復雜表格——財務模型、臨床試驗數據、合規矩陣。標準 RAG 要么忽略表格，要么把它們提取成非結構化文本，丟失所有關系。

"Tables contain some of the most critical information... If you can't handle tabular data, you're missing half the value."

表格包含了最關鍵的信息。如果處理不好表格數據，你就丟了一半的價值。

財務分析師需要特定季度的精確數字。研究人員需要臨床表格里的劑量信息。

我的方法：

• 把表格當成獨立實體，有自己的處理流程
• 用啟發式方法檢測表格（間距模式、網格結構）
• 簡單表格：轉成 CSV。復雜表格：在元數據中保留層級關系
• 雙重 embedding 策略：既 embed 結構化數據，也 embed 語義描述

在銀行項目里，到處都是財務表格。還得跟蹤匯總表和詳細分解表之間的關系。

1.7生產基礎設施的現實檢驗

教程假設資源無限、運行時間完美。生產環境意味著并發用戶、GPU 內存管理、穩定的響應時間、運行時間保證。

大多數企業客戶已經有閑置的 GPU 基礎設施——未使用的算力或其他數據科學工作負載。這讓本地部署比預期的容易。

通常部署 2-3 個模型：

• 主生成模型（Qwen 32B）用于復雜查詢
• 輕量級模型用于元數據提取
• 專門的 embedding 模型

盡可能用量化版本。Qwen QWQ-32B 量化到 4-bit 只需要 24GB VRAM，但保持了質量。可以在單張 RTX 4090 上運行，不過 A100 對并發用戶更好。

最大的挑戰不是模型質量——而是防止多個用戶同時訪問系統時的資源競爭。用信號量限制并發模型調用，加上合適的隊列管理。

1.8真正重要的經驗教訓

1. 文檔質量檢測優先： 不能用同一種方式處理所有企業文檔。先構建質量評估，再做其他事。
2. 元數據 > embeddings： 元數據不好，檢索就不好，不管你的向量有多棒。花時間做領域專用的模式。
3. 混合檢索是必須的： 純語義搜索在專業領域失敗太頻繁。需要基于規則的后備方案和文檔關系映射。
4. 表格很關鍵： 如果處理不好表格數據，就丟失了企業價值的一大塊。
5. 基礎設施決定成敗： 客戶更在乎可靠性，而不是花哨功能。資源管理和運行時間比模型復雜度更重要。

1.9說點真話

"Enterprise RAG is way more engineering than ML."

企業 RAG 更多是工程，而不是機器學習。

大多數失敗不是因為模型不好——而是低估了文檔處理的挑戰、元數據的復雜性、生產基礎設施的需求。

現在需求真的很瘋狂。每個有大量文檔庫的公司都需要這些系統，但大多數人根本不知道處理真實世界的文檔有多復雜。

反正這玩意兒比教程說的難太多了。企業文檔的各種邊緣情況會讓你想把筆記本扔出窗外。但如果搞定了，ROI 還是很可觀的——我見過團隊把文檔搜索從幾小時縮短到幾分鐘。

2、四個工程要點代碼示例

上面譯文看完可能還不夠直觀，我挑了四個覺得比較重要的工程要點，并結合對應的業界常用的開源組件進行核心代碼邏輯的展示，供各位參考。

2.1文檔質量評分系統

原帖最大的創新點是在處理文檔前先給它打分，根據質量路由到不同 pipeline。作者說這一個改動解決的檢索問題比升級 embedding 模型還多。

核心是識別三種文檔：Clean（80+分）的文檔文本提取完美，可以完整層級化處理；Decent（50-80 分）的文檔有 OCR 瑕疵，需要基礎分塊加清理；Garbage（<50 分）的掃描手寫筆記只能固定分塊并人工復查。

評分維度包括文本提取質量（權重 50%）、格式一致性（30%）和表格完整性（20%），通過采樣前 3 頁來快速評估整個文檔。下面以 PaddleOCR 為例，做個代碼邏輯演示：

from paddleocr import PaddleOCR
import numpy as np

class DocumentQualityScorer:
    def __init__(self):
        self.ocr = PaddleOCR(use_angle_cls=True, lang='ch')
    def score_document(self, pdf_images):
    """對文檔打分并選擇pipeline"""
    scores = []
    for img in pdf_images[:3]:  # 采樣前3頁
        result = self.ocr.ocr(img, cls=True)
        if not result or not result[0]:
            scores.append(0)
            continue

        # 提取置信度
        confidences = [line[1][1] for line in result[0]]
        avg_conf = np.mean(confidences)
        scores.append(avg_conf * 100)

    overall = np.mean(scores)

    # 分類并路由
    if overall >= 80:
        return "clean", CleanPipeline()
    elif overall >= 50:
        return "decent", DecentPipeline()
    else:
        return "garbage", GarbagePipeline()

這段代碼的核心邏輯是采樣前 3 頁圖像進行 OCR，提取每個文本塊的置信度分數（PaddleOCR 會為每個識別的文字塊返回 0-1 的 confidence 值），然后通過平均值轉換為 0-100 的分數。閾值 80 和 50 來自作者在多個項目中總結的經驗值：置信度高于 80%的文檔基本可以認為文本提取完美，50-80%之間有一些瑕疵但可用，低于 50%說明 OCR 質量很差。

只采樣 3 頁而不是全文是因為前幾頁通常能代表整體風格，處理全文太慢（100 頁文檔需要 10+分鐘），實測 3 頁的準確率已經 95%以上。這里用置信度 * 100 是為了將 0-1 的浮點數轉為 0-100 的分數，便于理解和設置閾值。

在實際使用時，建議先在數據集上標注 100 個文檔（人工判斷 Clean/Decent/Garbage），然后跑評分畫散點圖看三類文檔的分數分布，調整閾值讓分類準確率超過 90%。常見的坑是彩色掃描件 OCR 置信度可能很高但實際是垃圾，需要加入"是否為圖片 PDF"的判斷；表格很多的文檔（如財報）會被低估，可以提高表格評分的權重到 30%。性能優化方面，可以改為均勻采樣（第 1 頁、中間頁、最后頁各 1 頁）來提高代表性，多頁圖像可以并行 OCR 加速處理，同一文檔的評分結果應該緩存避免重復計算。

2.2層級化分塊策略

原帖批判了"固定 512 token 分塊"的做法，提出 4 層結構：Document（2048 tokens）→ Section（1024 tokens）→ Paragraph（512 tokens）→ Sentence（128 tokens）。關鍵洞察是查詢復雜度應該決定檢索層級：寬泛問題如"這篇講什么"適合段落級或章節級檢索，精確問題如"表 3 第 2 行是多少"需要句子級定位。每一層都生成獨立的 embedding 存儲在向量數據庫，檢索時根據查詢特征自動選擇合適的層級，從而避免大海撈針的問題。下面以 LlamaIndex 為例進行演示：

from llama_index.core.node_parser import HierarchicalNodeParser
from llama_index.core import Document

class AdaptiveRetriever:
    def __init__(self):
        self.parser = HierarchicalNodeParser.from_defaults(
            chunk_sizes=[2048, 1024, 512, 128]
        )
        self.precision_keywords = ['exact', 'table', 'figure', '表', '圖', '第']

    
    def retrieve(self, query, doc_text, vector_store):
    """層級化分塊并自適應檢索"""
    # 生成4層節點
    doc = Document(text=doc_text)
    nodes = self.parser.get_nodes_from_documents([doc])

    # 判斷查詢類型選擇層級
    has_precision = any(kw in query.lower() for kw in self.precision_keywords)
    word_count = len(query.split())

    if has_precision:
        level = 'sentence'
    elif word_count > 15:
        level = 'section'
    else:
        level = 'paragraph'

    return vector_store.search(query, filter={'layer': level}, top_k=5)

HierarchicalNodeParser 會根據 chunk_sizes 參數自動將文檔切分成 4 層，每層的大小是近似值而不是嚴格限制，因為切分時會保持語義邊界完整。參數[2048, 1024, 512, 128]適合英文，中文建議調整為[3000, 1500, 600, 150]因為中文信息密度更高。

查詢路由的邏輯是：如果包含精確關鍵詞（table、figure、第 X 章等）就用句子級，如果查詢很長（超過 15 個詞）說明是復雜概念問題就用章節級，否則默認段落級。這個啟發式規則來自原帖討論區的經驗，實測準確率在 85%左右。層級存儲在 vector_store 時通過 metadata 的 layer 字段區分，檢索時用 filter 過濾只在對應層級搜索。

實際使用時不是每次查詢都需要 4 層，大部分情況 paragraph 層足夠用，可以先在 paragraph 層檢索，如果置信度低再下鉆到 sentence 層做二次檢索。document 層主要用于"文檔級"問題如"這篇講什么"或生成摘要。

特殊文檔類型需要特別處理：表格和代碼塊應該提前提取單獨 chunk 避免被切碎，標題要合并到后續內容而不是單獨成 chunk，列表要保持完整性不在中間切斷。性能優化方面，chunk_sizes 的 overlap 建議設置為 size 的 5-10%來防止切斷完整語義，太大浪費存儲太小丟失上下文。對于技術文檔（代碼多）可以用更大的 chunk 如[4096, 2048, 1024, 256]。

2.3混合檢索問題

原帖指出純語義搜索在專業領域失敗率 15-20%，需要三路并行：語義檢索（向量相似度）理解語義但可能漏掉精確匹配，關鍵詞檢索（BM25）精確匹配但不理解同義詞，元數據過濾（結構化字段）過濾無關文檔。然后用 RRF（Reciprocal Rank Fusion）算法融合結果，公式是對于文檔 d 在結果列表中的排名 rank_d，融合分數等于各路結果的權重除以(60 + rank_d)之和。常數 60 是 RRF 標準參數，用于平衡頭部和尾部結果，權重一般設置為語義 0.7、關鍵詞 0.3，具體場景可調整。以 Qdrant 為例做個代碼示例：

from qdrant_client import QdrantClient

class HybridRetriever:
    def __init__(self):
        self.client = QdrantClient("localhost", port=6333)
    def search(self, query, top_k=10):
    """三路檢索 + RRF融合"""
    # 語義檢索（dense vector）
    semantic = self.client.search(
        collection_name="docs",
        query_vector=("dense", embed(query)),
        limit=top_k * 2
    )

    # 關鍵詞檢索（sparse vector）
    keyword = self.client.search(
        collection_name="docs",
        query_vector=("sparse", extract_keywords(query)),
        limit=top_k * 2
    )

    # RRF 融合
    scores = {}
    for rank, r in enumerate(semantic, 1):
        scores[r.id] = scores.get(r.id, 0) + 0.7 / (60 + rank)
    for rank, r in enumerate(keyword, 1):
        scores[r.id] = scores.get(r.id, 0) + 0.3 / (60 + rank)

    # 排序返回
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)[:top_k]

Qdrant 支持在同一文檔上同時存儲 dense 和 sparse 兩種向量，dense 是傳統的語義 embedding（如 OpenAI、BGE），sparse 是關鍵詞的稀疏表示類似 BM25 的詞頻向量。RRF 融合算法的核心是用排名的倒數而不是原始分數來融合，這樣可以處理不同檢索器分數尺度不統一的問題。權重 0.7 和 0.3 是通用場景的經驗值（語義為主），精確查詢多的場景可以設為 0.5/0.5 均衡，概念查詢多可以設為 0.8/0.2 更偏語義。limit 設為 top_k * 2 是因為融合后會有重復，多取一些保證最終有足夠結果。元數據過濾（如 doc_type='clinical_trial'）應該在數據庫層面用 Filter 實現而不是在應用層過濾，性能更好。

混合檢索在專業術語多的領域（醫療、法律、金融）是必須的，純語義搜索會漏掉縮寫、代號、產品型號等精確匹配。用戶查詢包含需要精確匹配的內容（如法規編號、技術規格）時也必須啟用。但通用聊天場景可選，純語義已經夠用，開啟混合檢索會增加 20-30%延遲。性能優化方面，三路檢索可以并行執行減少延遲，高頻查詢的結果應該緩存。

在實踐中建議通過 A/B 測試來調整權重：記錄用戶點擊率，看哪個權重組合的 top3 點擊率最高。如果你的文檔有豐富的元數據（如時間、類別、作者），元數據過濾能顯著提升準確率，例如"2024 年兒科臨床試驗"這種查詢，先用元數據過濾掉無關文檔再做語義檢索。

2.4置信度驅動的智能路由

來自原帖討論區的具體參數：0.7 相似度閾值加上 20-30 個觸發詞。邏輯是初始用段落級檢索獲得最高分數，如果高置信度（大于 0.85）說明段落級足夠，如果中置信度（0.7-0.85）且包含精確關鍵詞就切換到句子級，如果低置信度（0.5-0.7）就下鉆到句子級細粒度檢索，如果極低置信度（小于 0.5）就降級到關鍵詞搜索兜底。這是一個簡單但有效的"智能路由"，避免所有查詢都用同樣粒度檢索，既節省計算又提高準確率。以下是純 python 的實現示例：

class ConfidenceRouter:
    def __init__(self):
        self.precision_kw = ['exact', 'table', 'figure', '表', '圖', '第']
        self.high_conf = 0.85
        self.med_conf = 0.70
        self.low_conf = 0.50
    def route(self, query, search_engine):
    """置信度驅動的檢索路由"""
    # 初始檢索（段落級）
    initial = search_engine.search(query, level='paragraph', top_k=10)
    if not initial:
        return []

    max_score = max(r.score for r in initial)
    has_precision = any(kw in query.lower() for kw in self.precision_kw)

    # 決策
    if max_score >= self.high_conf:
        return initial  # 高置信度，段落級足夠
    elif max_score >= self.med_conf:
        if has_precision:
            return search_engine.search(query, level='sentence', top_k=10)
        return initial
    elif max_score >= self.low_conf:
        return search_engine.search(query, level='sentence', top_k=10)
    else:
        return search_engine.keyword_search(query, top_k=10)  # 兜底

閾值 0.85/0.7/0.5 來自原帖討論區作者在多個項目中驗證的經驗值，這些數字在實際項目中肯定不是拍腦袋定的，而是要通過標注數據找出的準確率突變點。精確關鍵詞列表有 20-30 個詞，包括 exact、table、figure 以及中文的"表、圖、第"等，還可以用正則匹配"表 3"、"第 5 章"這種模式。決策邏輯是先用段落級試探，根據最高分數和是否有精確詞來決定是否需要更細粒度，這樣大部分查詢（約 70%）在段落級就能解決，只有 30%需要下鉆到句子級或降級到關鍵詞。降級到關鍵詞搜索是兜底策略，雖然粗糙但總比返回空結果好，在語義搜索完全失敗時至少能匹配到一些相關詞。

實際使用的時候，建議在數據上標注 100 個左右查詢，畫出相似度分數的分布圖，找到準確率突變點來設置閾值，不要直接照搬 0.7/0.85 這些數字。精確關鍵詞列表需要持續維護，從 bad case 中收集（用戶重新搜索說明上次結果不滿意），定期 review 刪除誤判率高的詞，也可以用 TF-IDF 找領域特有的精確詞。

建議記錄詳細日志包括 query、max_score、選擇的 strategy（paragraph/sentence/keyword）、has_precision_kw 以及用戶點擊率，通過日志分析持續優化閾值和觸發詞。A/B 測試時可以對比不同閾值組合的 top3 點擊率，選擇表現最好的。常見問題是閾值設置過高導致過多下鉆到句子級增加延遲，或設置過低導致很多查詢在段落級就返回但準確率不夠，需要根據業務場景平衡準確率和性能。

3、技術問答討論

原帖已經信息密度很高，但評論區里藏著更多實戰細節。我從 108 條討論中精選了 17 條核心問答，涵蓋以下四大主題：

技術實現細節：為什么 VLM 處理 PDF 比 HTML 轉換更靠譜、小模型 7B-13B 能干什么不能干什么、遞歸搜索怎么實現和觸發、10-20 頁文檔全文讀 vs 分塊檢索的選擇標準；

成本和性能數據：GPT-4o vs Qwen 的詳細成本計算、H100 上跑 Qwen 32B 的真實性能數據、A100 部署成本和選型理由；

商業模式和團隊運作：60-70%代碼復用率怎么做到；2 人團隊如何服務 10+企業客戶、如何找客戶和合作伙伴模式、授權許可 vs 定制開發的商業模式）

以及重要的澄清和補充：元數據提取 LLM vs 規則的使用邊界、混合檢索的自動選擇挑戰、法律和工程領域從業者的跨行業驗證）。

這些帖子評論區內容我做了完整翻譯、提煉要點、補充國內場景對照，并標注實用性，放在知識星球中作為會員專屬資料，感興趣的也可以自行去看原帖。

為了直觀期間，看個例子，討論區第 6 條關于成本對比的節選：

圖片

評論：

你說 Qwen 比 GPT-4o 便宜 85%。我也在做類似項目想評估成本。GPT-4o 大概每月多少錢？

作者回答：

GPT-4o 價格是輸入$2.50/百萬 tokens、輸出$10.00/百萬 tokens。典型企業 RAG 場景，假設首次處理 5 萬文檔（一次性 embedding），每月 1 萬次查詢，平均每次 1K 輸入、500 輸出。GPT-4o 成本： 初始 embedding 約$125，月度查詢約$100（$75 輸入+$25 輸出），總計中等使用量每月$200-300+，規模上去后快速增長。Qwen QWQ-32B 成本： 輸入$0.15-0.50/百萬 tokens、輸出$0.45-1.50/百萬 tokens（Groq 報價$0.29 輸入/$0.39 輸出），同樣工作量：初始 embedding 約$15-25，月度查詢約$15-20，總計每月$30-50，而不是$200-300+。這就是 85%成本節省的來源。

作者直接給出了完整的公式和每個環節的費用拆解，包括具體的 token 價格、使用量假設和總成本計算，這些實際項目中可以直接拿來做預算。類似這樣有具體數字、可落地的實戰經驗，在 17 條精華問答里還有很多。

4、寫在最后

帖子作者說"企業 RAG 是 70% 工程 + 20% 領域知識 + 10% 模型"，我深表認同，但想再加一個維度：企業 RAG = 70% 工程 + 20% 領域知識 + 10% 模型 + ∞ 耐心。

畢竟，企業 RAG 不是一個純技術問題，對行業的理解、對臟數據的處理能力、對工程細節的把控，都是繞不開的必修課。