北京
過去一年里，我一直在為受監(jiān)管領(lǐng)域的中型企業(yè)（員工 100–1000 人）搭建 RAG 系統(tǒng)，說實話，這比任何教程里看起來都難。目前已服務(wù) 10 多家客戶——制藥公司、銀行、律所、咨詢公司。想分享一下真正關(guān)鍵的經(jīng)驗，而不是網(wǎng)上那些千篇一律的基礎(chǔ)信息。
快速背景：這些公司大多有 1 萬到 5 萬+ 份文檔，被困在 SharePoint 地獄或 2005 年的文檔管理系統(tǒng)里。不是干凈的數(shù)據(jù)集，也不是精心策劃的知識庫——只是幾十年積累下來的業(yè)務(wù)文檔，卻必須能被搜索。
文檔質(zhì)量檢測：沒人談?wù)摰年P(guān)鍵環(huán)節(jié)
這對我來說是最震撼的發(fā)現(xiàn)。大多數(shù)教程都默認你的 PDF 完美無缺?，F(xiàn)實是：企業(yè)文檔就是垃圾堆。
我曾服務(wù)一家藥企，他們的研究論文最早可追溯到 1995 年，全是打字稿的掃描件，OCR 幾乎失效。又混雜著現(xiàn)代 500 多頁的臨床試驗報告，里面嵌著表格和圖表。想用同一套分塊策略處理這兩種文檔？等著看系統(tǒng)給你返回一堆胡言亂語吧。
花了好幾周調(diào)試，為什么某些文檔返回的結(jié)果極差，而另一些卻完全正常。最終意識到，必須在處理前先給文檔質(zhì)量打分：
干凈的 PDF（文本提取完美）：完整層級處理
尚可的文檔（存在少量 OCR 偽影）：基礎(chǔ)分塊并附帶清理
垃圾文檔（掃描的手寫筆記）：簡單固定分塊 + 人工審核標記
我們構(gòu)建了一套簡單的評分體系，評估文本提取質(zhì)量、OCR 偽影和格式一致性，并按得分把文檔路由到不同的處理流水線。僅此一項改進，比任何嵌入模型升級都解決了更多檢索問題。
為什么固定長度分塊基本不靠譜
所有教程都在說：“直接按 512 token 重疊分塊！”
現(xiàn)實：文檔有結(jié)構(gòu)。論文的方法論章節(jié)和結(jié)論完全不同，財報的執(zhí)行摘要和明細表也各有特點。一旦忽略結(jié)構(gòu)，就會得到半截句子或把無關(guān)概念硬拼在一起的塊。
必須構(gòu)建保留文檔結(jié)構(gòu)的分層切塊：
文檔級（標題、作者、日期、類型）
章節(jié)級（摘要、方法、結(jié)果）
段落級（200–400 個 token）
句子級用于精確查詢
關(guān)鍵洞察：查詢的復(fù)雜度應(yīng)決定檢索的層級。寬泛的問題停留在段落級。像“表3中的確切劑量是多少？”這類精確內(nèi)容需要句子級的精度。
我使用簡單的關(guān)鍵詞檢測——“exact”、“specific”、“table”等詞會觸發(fā)精確模式。如果置信度低，系統(tǒng)會自動下沉到更精細的片段。
元數(shù)據(jù)架構(gòu)比你的嵌入模型更重要
這是我投入 40% 開發(fā)時間的地方，也是所有工作中 ROI 最高的部分。
大多數(shù)人把元數(shù)據(jù)當作事后才考慮的東西。但企業(yè)查詢的上下文極其復(fù)雜。一位制藥研究員查詢“兒科研究”時，所需的文檔與查詢“成人人群”的人完全不同。
構(gòu)建了領(lǐng)域?qū)俚脑獢?shù)據(jù)模式：
針對制藥文檔：
文檔類型（研究論文、監(jiān)管文件、臨床試驗）
藥物分類
患者人口統(tǒng)計學（兒科、成人、老年）
監(jiān)管類別（FDA、EMA）
治療領(lǐng)域（心臟病學、腫瘤學）
對于金融文檔：
時間段（2023 年第一季度、2022 財年）
財務(wù)指標（收入、EBITDA）
業(yè)務(wù)板塊
地理區(qū)域
避免用 LLMs 做元數(shù)據(jù)提取——它們極其不穩(wěn)定。簡單的關(guān)鍵詞匹配效果好得多。查詢里包含“FDA”？就按 regulatory_category: "FDA" 過濾。提到“pediatric”？就應(yīng)用患者人群過濾。
每個領(lǐng)域先準備 100–200 個核心術(shù)語，再根據(jù)匹配不佳的查詢逐步擴充。領(lǐng)域?qū)＜彝ǔ：軜芬鈳兔φ磉@些列表。
當語義搜索失敗時（劇透：經(jīng)常失?。?/strong>
純語義搜索的失敗率遠高于人們愿意承認的程度。在制藥和法律等專業(yè)領(lǐng)域，我看到的失敗率是 15–20%，而不是大家默認的 5%。
把我逼瘋的主要失敗模式：
縮寫混淆： “CAR”在腫瘤學里指“Chimeric Antigen Receptor”，在影像論文里卻指“Computer Aided Radiology”。嵌入向量相同，含義卻完全不同。這問題一直讓我頭疼。
精確技術(shù)查詢： 有人提問“表 3 中的確切劑量是多少？”語義搜索能找到概念上相似的內(nèi)容，卻遺漏了具體的表格引用。
交叉引用鏈： 文檔之間不斷相互引用。藥物 A 的研究引用了藥物 B 的相互作用數(shù)據(jù)。語義搜索完全遺漏了這些關(guān)系網(wǎng)絡(luò)。
解決方案： 采用混合架構(gòu)。在文檔處理階段用圖結(jié)構(gòu)記錄文檔間關(guān)系；語義搜索后，系統(tǒng)會檢查已召回文檔是否關(guān)聯(lián)到含有更優(yōu)答案的其他文檔。
對于縮寫詞，我借助領(lǐng)域?qū)倏s寫庫做上下文感知展開；遇到精確查詢，關(guān)鍵詞觸發(fā)器會切換到基于規(guī)則的檢索，直接定位特定數(shù)據(jù)點。
為何我選擇開源模型（具體是 Qwen）
多數(shù)人默認 GPT-4o 或 o3-mini 永遠更強。但企業(yè)客戶總有各種奇怪限制：
成本： 當文檔超過 5 萬份、每日查詢達數(shù)千次時，API 費用會飆升
數(shù)據(jù)主權(quán)： 制藥和金融企業(yè)無法將敏感數(shù)據(jù)發(fā)送到外部 API
領(lǐng)域術(shù)語： 通用模型在遇到未訓練過的專業(yè)術(shù)語時會產(chǎn)生幻覺
經(jīng)過領(lǐng)域特定微調(diào)后，Qwen QWQ-32B 的表現(xiàn)出乎意料地好：
比 GPT-4o 處理大批量任務(wù)便宜 85%
全部數(shù)據(jù)留在客戶本地基礎(chǔ)設(shè)施
可針對醫(yī)療/金融術(shù)語進行微調(diào)
響應(yīng)時間穩(wěn)定，無 API 速率限制
微調(diào)方法很簡單——用領(lǐng)域問答對做監(jiān)督訓練。我們構(gòu)建的數(shù)據(jù)集形如“藥物 X 的禁忌癥有哪些？”并配上 FDA 指南中的真實答案?；A(chǔ)的監(jiān)督微調(diào)效果比 RAFT 這類復(fù)雜方法更好，關(guān)鍵在于訓練數(shù)據(jù)要干凈。
表格處理：隱藏的噩夢
企業(yè)文檔里滿是復(fù)雜表格——財務(wù)模型、臨床試驗數(shù)據(jù)、合規(guī)矩陣。標準 RAG 要么直接忽略表格，要么把表格當無結(jié)構(gòu)文本抽取，導(dǎo)致所有關(guān)系信息丟失。
表格往往包含最關(guān)鍵的信息。金融分析師需要特定季度的精確數(shù)字，研究人員需要臨床表格中的劑量信息。如果處理不了表格數(shù)據(jù)，你就損失了一半價值。
我的做法：
將表格視為獨立實體，擁有專屬處理流程
利用啟發(fā)式規(guī)則檢測表格（間距模式、網(wǎng)格結(jié)構(gòu)）
簡單表格：轉(zhuǎn)為 CSV；復(fù)雜表格：在元數(shù)據(jù)中保留層級關(guān)系
雙重嵌入策略：同時嵌入結(jié)構(gòu)化數(shù)據(jù)和語義描述
在銀行項目中，金融表格無處不在。還必須追蹤匯總表與詳細明細表之間的關(guān)系。
生產(chǎn)基礎(chǔ)設(shè)施現(xiàn)實檢驗
教程假設(shè)資源無限、服務(wù)永遠在線。而生產(chǎn)環(huán)境意味著并發(fā)用戶、GPU 內(nèi)存管理、響應(yīng)時間一致性和可用性保障。
大多數(shù)企業(yè)客戶手頭已有閑置的 GPU 基礎(chǔ)設(shè)施——未使用的算力或用于其他數(shù)據(jù)科學任務(wù)。這讓本地部署比預(yù)期更容易。
通常部署 2–3 個模型：
主生成模型（Qwen 32B）用于處理復(fù)雜查詢
輕量級元數(shù)據(jù)提取模型
專用嵌入模型
盡可能使用量化版本。Qwen QWQ-32B 量化到 4 位僅需 24GB 顯存，同時保持質(zhì)量。單張 RTX 4090 即可運行，但并發(fā)用戶多時 A100 更佳。
最大的挑戰(zhàn)不是模型質(zhì)量，而是防止多用戶同時訪問時的資源爭用。使用信號量限制并發(fā)模型調(diào)用，并做好隊列管理。
真正關(guān)鍵的經(jīng)驗教訓
1. 先檢測文檔質(zhì)量： 不能對所有企業(yè)文檔一視同仁。先建立質(zhì)量評估，再做其他。
2. 元數(shù)據(jù) > 嵌入： 元數(shù)據(jù)差，無論向量多好，檢索也差。花時間做領(lǐng)域?qū)Ｓ媚Ｊ健?/p>
3. 混合檢索是必須的： 在專業(yè)領(lǐng)域，純語義搜索經(jīng)常失敗。需要基于規(guī)則的回退和文檔關(guān)系映射。
4. 表格至關(guān)重要： 如果你無法正確處理表格數(shù)據(jù)，就會錯失大量企業(yè)價值。
5. 基礎(chǔ)設(shè)施決定成?。?/strong> 客戶更看重可靠性，而不是花哨的功能。資源管理和正常運行時間比模型復(fù)雜度更重要。
實話實說
企業(yè)級 RAG 更多是工程問題，而非 ML 問題。大多數(shù)失敗并非源于模型不佳，而是低估了文檔處理挑戰(zhàn)、元數(shù)據(jù)復(fù)雜性以及生產(chǎn)基礎(chǔ)設(shè)施需求。
需求現(xiàn)在簡直瘋狂。但凡擁有大量文檔倉庫的公司都需要這類系統(tǒng)，但大多數(shù)人根本不知道面對真實文檔時有多復(fù)雜。
總之，這比教程里看起來難得多。企業(yè)文檔里的各種邊緣情況會讓你想把筆記本扔出窗外。但一旦跑通，ROI 相當可觀——見過團隊把文檔搜索從幾小時縮到幾分鐘。
幾天前發(fā)在 LLMDevs 上，很多人覺得這個技術(shù)拆解有用，所以也在這里分享給更廣泛的 AI 社區(qū)！
QA
Q：你用的是什么技術(shù)棧？ A：其實每個項目略有不同，但我的常用棧是：Python、Ollama、vLLM、React/Next.js、Qdrant、Nomic Embeddings、PyMuPDF、Tesseract、PostgreSQL。
Q：好奇你用了哪些庫——我們也在給 HR 和 IT 部門做類似的事，PDF 處理絕對是 80% 的坑。目前混用一堆工具。我試了 PyMUPDF，糾偏和畫質(zhì)修復(fù)效果不錯，但跑得太久，根本沒法讓用戶邊等邊分析。有興趣私聊——我們可能會碰到金融和制藥場景，現(xiàn)在沒精力深耕，以后也許得把活兒轉(zhuǎn)出去。 A：處理 PDF 我采用“組合拳”，不押寶在單一庫上。PyMUPDF 提取文本和基礎(chǔ)版面識別還行，但性能確實拉胯，實時場景根本扛不住。我的常規(guī)組合：pymupdf 做初篩提取，pdfplumber 負責表格定位，復(fù)雜表格再讓 camelot 當備胎。可說實話，它們都會在某些文檔上翻車，所以我把疑難雜癥直接扔給 VLM 繼續(xù)啃。
為了解決性能問題，我把所有 PDF 處理都放在文檔攝取階段完成，而不是在查詢時進行。用戶無需等待 PDF 解析——解析在文檔上傳時就在后臺完成。查詢階段只做向量搜索和生成，速度要快得多。糾偏和質(zhì)量修復(fù)雖然重要，但開銷很大，我只對那些初次質(zhì)量評分未通過的文檔應(yīng)用這些修正。大多數(shù)企業(yè) PDF 足夠干凈，不需要重度預(yù)處理。
HR 和 IT 文檔的挑戰(zhàn)可能與制藥行業(yè)不同——格式更雜、結(jié)構(gòu)更缺乏標準化。但原則一樣：先檢測質(zhì)量，再路由到合適的處理流水線。
Q：你如何給文檔做質(zhì)量評分？ A：我在文檔攝取階段會結(jié)合使用一些簡單指標：
文本提取質(zhì)量：隨機抽取部分段落，統(tǒng)計可識別單詞與亂碼字符的比例。干凈的 PDF 可讀文本比例在 95% 以上，OCR 偽影會表現(xiàn)為奇怪的字符組合。
結(jié)構(gòu)一致性：檢查是否有正確的段落換行、統(tǒng)一的間距、可識別的標題。掃描文檔往往間距不規(guī)則或行被合并。
字符模式分析：留意常見 OCR 錯誤，如把 “rn” 識別成 “m”，或文本中隨機散布特殊字符。布局檢測成功率：嘗試識別標題、段落、表格等基本文檔元素。如果解析庫無法檢測到任何結(jié)構(gòu)，大概率是低質(zhì)量掃描。
我按 0–10 分打分并設(shè)定閾值——低于 4 分的直接走固定大小分塊，并標記人工復(fù)核；4–6 分做基礎(chǔ)處理加清理；7 分以上才啟用完整層級處理。方法很粗糙，但能攔住那些明顯“越 sophisticated 越垃圾”的文檔。每篇在入庫時耗時約 30 秒，離線跑完全可接受。評分不完美，卻省得我浪費時間給壓根沒結(jié)構(gòu)的文檔硬抽意義。
Q： 感謝所有細節(jié)，提供了很多洞見和啟發(fā)。雖然這么說有點瘋狂，但向量嵌入其實沒那么神。它們非?！班须s”，語義相似性本質(zhì)上只是統(tǒng)計相似性，兩個片段可能相似卻毫無關(guān)聯(lián)。更糟糕的是，一份關(guān)于人類癌癥的文件和一份關(guān)于豬癌癥的文件，語義相似性會愉快地把兩個文檔的片段混在一起，給出一個完全錯誤的答案。
我認為你強調(diào)的關(guān)鍵在于：面對非結(jié)構(gòu)化數(shù)據(jù)，你越是能把它結(jié)構(gòu)化，就越能借助這些結(jié)構(gòu)精準定位相關(guān)文檔和段落。這沒有向量嵌入那么“性感”，但速度快且有效。早在向量嵌入出現(xiàn)之前，我們靠數(shù)據(jù)庫和網(wǎng)頁搜索就已經(jīng)做得不錯了。并非每把工具都是（語義）錘子。
我有一個問題：您能否分享一些關(guān)于本地查詢與全局查詢的細節(jié)或想法？這兩類查詢需要不同的搜索策略，那么您是如何判斷一條查詢是本地還是全局的呢？
例如，“給我所有與 XYZ 相關(guān)的結(jié)果”屬于局部查詢，因為它專門針對 XYZ，通常只需查找包含 XYZ 的片段即可找到；而“這份文檔的關(guān)鍵要點是什么？”則是全局查詢，因為查詢本身沒有特定指向，需要采用不同的搜索策略。
A：
你說得很對，向量嵌入確實充滿噪聲，癌癥的例子非常貼切——語義相似性可能在完全不同的語境之間建立危險的錯誤關(guān)聯(lián)。豬與人癌癥的問題恰恰說明了在運行語義搜索之前，元數(shù)據(jù)過濾為何至關(guān)重要。
對于局部與全局查詢的識別，我使用了一些在實踐中效果不錯的簡單啟發(fā)式規(guī)則：
本地查詢指示符：具體實體名稱、日期、數(shù)字、“查找所有”“給我看”“……做了什么”等短語、專有名詞、技術(shù)術(shù)語。這些通常映射到特定分塊或文檔段落。
全局查詢指標：像“總結(jié)”“概覽”“關(guān)鍵要點”“主要主題”“比較”“分析”這類詞。這些需要文檔級或跨文檔的綜合。
我還會看查詢長度——更長的查詢往往更具體/局部，短的則更全局?！癉rug X 在 II 期試驗中的副作用是什么？”顯然是局部的。“主要發(fā)現(xiàn)是什么？”是全局的。
對于全局查詢，我會檢索更廣泛的上下文——比如取前 20 個片段而不是 5 個，或者拉取章節(jié)級片段而非段落級。有時我會先進行文檔級摘要，再從摘要中作答。
檢測并不完美，但能抓住大多數(shù)情況。拿不準時，我默認用本地搜索，因為它更快，用戶若想全局分析，通常也能重新表述。沒錯，我們確實被向量嵌入的炒作帶偏了。在把問題復(fù)雜化、引入語義相似度之前，關(guān)鍵詞搜索加結(jié)構(gòu)化過濾就已經(jīng)能很好地解決大多數(shù)文檔檢索需求。
Q：你現(xiàn)有的知識和技術(shù)棧能在多大程度上加速類似未來項目的開發(fā)？比如，一家大型汽車零部件供應(yīng)商想要一個 RAG 系統(tǒng)，你估計有多少比例的工作可以復(fù)用？
A：你說得有點道理，但關(guān)鍵在于——如果這是一個純文本系統(tǒng)，或者我已經(jīng)針對某個特定用例/需求搭建過，那就不算難。我可以復(fù)用 90% 的代碼直接交付，目前我就是按授權(quán)模式這么做的?？杉幢阄易焐险f“不難”，作為企業(yè)他們依舊不知道怎樣讓這套系統(tǒng)支撐 2 萬篇文檔或更大規(guī)模的信息。這種深度領(lǐng)域知識我恰好掌握，他們才愿意為此付高價。
但情況并非總是如此。有些公司擁有老舊文檔，有些客戶希望連接包含數(shù)百萬條記錄的數(shù)據(jù)庫，有些則需要模型成為能夠理解圖像、圖表、示意圖的視覺語言模型（VLM），并且仍然是開放權(quán)重的模型。這只是冰山一角——定制化需求有時簡直瘋狂。
但總的來說，核心思路是：一旦我為某個客戶找到了解決方案，就會把同樣的領(lǐng)域知識或方法沿用到下一個客戶身上。所以策略沒錯，我確實在大量復(fù)用已有成果，不過僅限于那些我已經(jīng)解決的問題——而這類問題現(xiàn)在已經(jīng)很多了。
Q：我有一個關(guān)于表格的問題：如果把表格讀出來后，在數(shù)據(jù)集里直接轉(zhuǎn)成 JSON 結(jié)構(gòu)會怎樣？我在簡單表格上試過，效果還不錯。
關(guān)于文檔內(nèi)容，你有沒有做過“上下文增強”？比如刻意在文本里重復(fù)一些關(guān)鍵詞，或者給一段/一章內(nèi)容人工生成10組問答？我不確定在面對真實客戶數(shù)據(jù)時這么做是否合規(guī)，甚至是否道德，但在我自己的實驗里，這些做法確實帶來了不錯的效果。 A： 把表格轉(zhuǎn)成 JSON 對結(jié)構(gòu)簡單、行列清晰的表格確實靠譜。JSON 能更好地保留鍵值關(guān)系，你可以同時嵌入 JSON 結(jié)構(gòu)和一段自然語言描述，說明這張表到底包含什么。財務(wù)數(shù)據(jù)、規(guī)格參數(shù)等需要保留關(guān)系的表格都適用。缺點是，一旦表格出現(xiàn)合并單元格、多級表頭或布局不規(guī)則，JSON 就會變得很亂；這種時候我通常回退到保留視覺結(jié)構(gòu)，或者直接上 VLM 提取。
在內(nèi)容增強方面，我避免人為重復(fù)關(guān)鍵詞或從客戶數(shù)據(jù)中生成合成問答對。這種做法像是數(shù)據(jù)操控，可能引入偏差或不準確之處，尤其是企業(yè)客戶不希望原始內(nèi)容被改動。相反，我專注于在預(yù)處理階段豐富元數(shù)據(jù)和文檔關(guān)系，例如提取關(guān)鍵實體、標記內(nèi)容類型、構(gòu)建引用圖譜。這樣可以在不改變源材料的前提下提升檢索效果。
Q&A 生成方法或許適用于訓練數(shù)據(jù)或知識庫這類可以驗證準確性的場景，但面對真實客戶文檔時，我會謹慎對待添加合成內(nèi)容，以免用戶誤將其當作原始信息。
Q：你們?nèi)绾翁幚砦臋n生命周期問題？比如排除過時或舊版本？ A：文檔生命周期管理絕對是那種看起來簡單、真到大規(guī)模落地就復(fù)雜的事情。大多數(shù)客戶對文檔沒有像樣的版本控制，所以我只能基于文件名模式和內(nèi)容哈希做簡單去重。一旦看到“Financial_Report_Q3_2023_v2.pdf”和“Financial_Report_Q3_2023_final.pdf”，就標記出來人工確認哪個才是最新版。
對于監(jiān)管文檔，我會在元數(shù)據(jù)中記錄發(fā)布日期和監(jiān)管狀態(tài)。2015 年的 FDA 指南可能被 2023 年版本取代，但有時兩者在歷史背景下都有參考價值，這通常需要領(lǐng)域?qū)＜遗袛?。我還實現(xiàn)了簡單的“陳舊性”檢測——超過 2 年未被訪問或引用的文檔會被標記待審。但我會謹慎避免自動刪除，因為企業(yè)客戶對信息丟失極度敏感。
最棘手的部分是文檔關(guān)系發(fā)生變化時。如果某項臨床研究被更新，所有引用它的報告可能都需要重新處理，以更新其元數(shù)據(jù)連接。我的大多數(shù)客戶最終都會指派專人管理文檔工作流，而不是試圖完全自動化。他們會按季度審查，將文檔標記為已歸檔、已取代或當前有效。雖然不夠優(yōu)雅，但比構(gòu)建復(fù)雜的自動化生命周期規(guī)則效果更好。
當客戶擁有合適的文檔管理系統(tǒng)時，版本控制會變得更容易，但大多數(shù)人仍在處理幾十年間被扔進 SharePoint 文件夾的文件。
Q：我曾遇到這樣的情況：客戶要求我們?yōu)閼?yīng)用構(gòu)建一個 RAG，其數(shù)據(jù)源是關(guān)系型數(shù)據(jù)庫，里面存有每個人的項目詳情、工作團隊信息等類似內(nèi)容。于是我們手動為每個人的數(shù)據(jù)生成一段模板（摘要），再上傳到 Qdrant。實際上，我們 RAG 的檢索準確率只有 50%，采用的是純稠密嵌入方案。從表數(shù)據(jù)生成摘要，這種做法合適嗎？ A：50% 的檢索準確率相當?shù)停艺J為手動摘要方式可能是問題之一。對于項目詳情、團隊信息等結(jié)構(gòu)化數(shù)據(jù)庫內(nèi)容，生成敘述性摘要往往會丟失人們實際查詢的精確可檢索要素。當有人提問“找出 2023 年 John 與營銷團隊合作的所有項目”時，需要的是姓名、部門和日期的精確匹配——而不是散文式描述。
我會改用混合方案：把結(jié)構(gòu)化數(shù)據(jù)保留為結(jié)構(gòu)化元數(shù)據(jù)（人名、項目 ID、團隊名、日期、技能），用于精確過濾；再對描述性內(nèi)容（項目描述、角色摘要、成就）做向量化。于是檢索流程變成：先用結(jié)構(gòu)化條件過濾（team=marketing，year=2023），再在這些結(jié)果里做語義搜索，回答概念性查詢。
純稠密向量在結(jié)構(gòu)化數(shù)據(jù)上表現(xiàn)吃力，因為它試圖學習員工 ID 與項目代號之間的“語義關(guān)系”，而這些標識符本身并無語義意義。此外，用戶對結(jié)構(gòu)化數(shù)據(jù)的查詢方式也與文檔不同：他們要的是“所有參與過移動項目的開發(fā)者”或“預(yù)算超 10 萬的項目”——可過濾的硬條件夾雜少量語義概念。
若想在模板法里見效，就得用更一致的結(jié)構(gòu)化字段，但說實話，把結(jié)構(gòu)化數(shù)據(jù)單獨當元數(shù)據(jù)字段，對絕大多數(shù)查詢都更靠譜。
Q：這簡直是一座寶庫。我對所謂的企業(yè)級 RAG 還只是淺嘗輒止，遠未考慮到并發(fā)使用、基礎(chǔ)設(shè)施、可靠性等問題?！氨砀駭?shù)據(jù)”和“技術(shù)圖表”已被證明是最具挑戰(zhàn)性和吸引力的部分之一。原生 RAG 很快就暴露出局限性，至少在我這里是這樣。
不知道你是否遇到過需要解讀并理解非文本內(nèi)容（表格除外）的場景？又是如何解決的？當然，一種思路是用圖文生成模型為圖像生成描述，但目前速度相當慢，尤其在做本地部署時。
此外，你是否遇到過這種情況：并非處理靜態(tài)文檔集，而是面對高度動態(tài)的文檔集，例如新發(fā)布文檔或其他持續(xù)頻繁更新的資料？
A： 對于表格以外的非文本內(nèi)容，我處理過技術(shù)示意圖、圖表和流程圖。正如你所說，圖像轉(zhuǎn)文本生成速度很慢，因此我會有選擇地使用。對于在多個文檔中反復(fù)出現(xiàn)的示意圖，我會一次性處理并復(fù)用其描述。對于一次性圖像，有時我會直接接受它們無法被檢索的事實，轉(zhuǎn)而聚焦在周圍的文本上下文上。
VLM 在技術(shù)圖表上的表現(xiàn)優(yōu)于通用圖像描述模型，能更準確地理解流程圖、網(wǎng)絡(luò)拓撲和流程工作流。但你說得對，本地部署確實存在性能權(quán)衡——準確性與速度之間需要取舍。
對于動態(tài)文檔集，我采用增量更新管道而非全量重處理。新文檔先經(jīng)過質(zhì)量評分，再走同一處理流程。難點在于處理文檔間的關(guān)聯(lián)——若某技術(shù)規(guī)范被更新，我得找出所有引用它的文檔，并視情況刷新其元數(shù)據(jù)。
我還會追蹤文檔的“新鮮度”，并在相關(guān)文檔可能過期時發(fā)出提醒。比如產(chǎn)品手冊已更新，但故障排查指南仍引用舊版本號，用戶瀏覽這些可能失效的信息時會收到警告。
版本管理在動態(tài)文檔集中變得至關(guān)重要。我會維護一份簡單的文檔血緣記錄，讓用戶知道他們看到的是當前信息還是已被取代的信息。雖然不完美，但能捕捉到大多數(shù)因文檔更新導(dǎo)致知識庫不一致的情況。與靜態(tài)文檔集相比，頻繁更新時基礎(chǔ)設(shè)施需求確實會更復(fù)雜。
Q： 太厲害了。從你其他的回復(fù)來看，似乎只有你自己、你兄弟和 Claude Code 三個人，這更令人驚嘆。這簡直就是生成式 AI 把生產(chǎn)力放大 20 倍的活例子。
那么，你們是如何判斷哪些技術(shù)圖紙、流程圖該被處理、哪些不該呢？這得從用戶視角出發(fā)，具備深度洞察、領(lǐng)域知識，還得懂相關(guān)性。是讓客戶替你們挑嗎？否則我真好奇你們怎么規(guī)模化——光這一步就能把團隊拖垮。我是產(chǎn)品經(jīng)理（還能寫點代碼，現(xiàn)在基本靠“氛圍編程”），外加 1 個人，正試圖吞進 30 份文檔（平均 300 頁/份），全是硬核技術(shù)資料。注意，這些文檔我熟得不能再熟，就是我的產(chǎn)品，可連 20% 的標注我都搞不完。所以我才琢磨：能不能讓 AI 先打個相關(guān)性分？
至于處理文檔的增量更新，這是個有趣的做法。如果你有空，很想了解你是怎么做的。我為了“圍繞”文檔差異做語義分塊而絞盡腦汁，結(jié)果并不美好。我意識到，如果同一文檔兩個版本之間的差異高度集中，這方法或許可行；可一旦改動四處散落，最終狀態(tài)就會一團糟，或者分塊邏輯得塞進大量啟發(fā)式規(guī)則。
A：沒錯，它絕對是個放大器！
因此，對于技術(shù)圖表，我不會自己拍板。在最初與客戶對接時，我會和他們的領(lǐng)域?qū)＜乙黄?，確定哪些類型的可視化內(nèi)容真正可被檢索，哪些只是參考資料。比如在制藥行業(yè)，工藝流程圖至關(guān)重要，而公司 Logo 則無關(guān)緊要。專家們清楚他們的團隊實際會查詢什么。
我還會建立抽樣流程——先處理大約10%的圖表，看看效果如何，再逐步擴大?？蛻艨梢詫忛喗Y(jié)果，告訴我該聚焦哪些類型。這比瞎猜高效得多。
針對你那 30 份文檔的挑戰(zhàn)，完全可以用 AI 做相關(guān)性打分。先用輕量模型給圖表分類——流程圖、照片、圖表——再按最可能包含可查詢信息的標準排優(yōu)先級。不完美，但比人工標注強。
增量更新確實麻煩，你說得對。我避免在差異上做“聰明”的語義分塊。相反，我按文檔章節(jié)追蹤，一旦某節(jié)有變動就整塊重分。如果技術(shù)規(guī)范更新了第4.2節(jié)，我就把整節(jié)重新處理，而不是試圖修補單個塊。
對于零散的改動，我干脆接受“有些文檔必須整體重新處理”這一事實。試圖在隨機編輯周圍維持分塊邊界，帶來的問題遠比它解決的要多。有時候，最樸素的“拿不準就整篇重跑”反而比那些在邊界情況里會崩盤的復(fù)雜啟發(fā)式規(guī)則更靠譜。
Q：個人用的 OCR 解析器或把 PDF 喂給 LLM 端點，目前最好的 OCR 技術(shù)棧是什么？這些 PDF 大多是純文本報告，不含表格。
A： 對于不含表格、以文字為主的 PDF，越簡單越好。Tesseract 加一些基礎(chǔ)預(yù)處理就能勝任，而且完全免費。若處理掃描件，先跑一遍圖像增強——去歪斜、降噪、調(diào)對比。遇到質(zhì)量參差不齊的掃描，想提高識別率，PaddleOCR 通常比 Tesseract 更穩(wěn)，依舊是開源，可本地運行。
如果你想要更強大的方案，AWS Textract、Google Document AI 和 Azure Document 都是可靠的云選項，但會增加成本和延遲。只有在處理質(zhì)量極差的掃描件或需要超高準確率時才值得使用。
預(yù)處理時，用 OpenCV 先清理圖像再 OCR，效果提升顯著。大多數(shù) OCR 失敗并非引擎問題，而是圖像質(zhì)量太差。
既然你最終還是要把內(nèi)容送進 LLM 端點，就沒必要追求完美的文本提取——大多數(shù)現(xiàn)代 LLM 都能輕松應(yīng)對輕微的 OCR 偽影。把重點放在把大體內(nèi)容弄對，而不是像素級精確。
整個流程在大多數(shù)情況下都可以本地運行，只需 tesseract 加上基礎(chǔ)的圖像預(yù)處理即可。只有當你持續(xù)遇到特定文檔類型的質(zhì)量問題時，才考慮升級到更復(fù)雜的方案。
Q：你們是如何評估 RAG 系統(tǒng)的？最終準確率是多少？（比如金融場景）同樣這個場景，你們向客戶收了多少錢？（用了多少個工作日？）
A： 為進行評估，我與領(lǐng)域?qū)＜液献鳎瑸榻鹑诳蛻魟?chuàng)建了黃金問題集——約 150 個已知正確答案的測試查詢。同時追蹤檢索準確率（是否找到了正確文檔？）和答案質(zhì)量（回答是否有用？）。
最終測試集準確率約為87%，其余13%多為文檔信息沖突或查詢過于模糊的邊界情況。用戶對該性能水平表示滿意。
無法透露具體報價，但金額在 10 萬美元以上，總耗時約 3–4 個月。第四個月主要用于測試與打磨，實際開發(fā)約 3 個月。對一些人來說可能顯得不現(xiàn)實，但我復(fù)用了之前項目約 50–60% 的代碼，甚至可能更多。
Q：感謝你的精彩分析；我們也在同一領(lǐng)域工作，但認為只要有概念建模支撐，LLMs 在元數(shù)據(jù)提取方面表現(xiàn)相當不錯。
看起來你完全用基于關(guān)鍵詞的方法取代了實體識別與鏈接；你持反對立場的依據(jù)是什么？最終是得到類似在扁平關(guān)鍵詞列表上的 bm25f，還是仍然保留結(jié)構(gòu)化的元數(shù)據(jù)模式？
A：基于關(guān)鍵詞的方法源于對專業(yè)領(lǐng)域命名實體識別（NER）不一致的挫敗感。當我嘗試對制藥文檔進行實體識別時，它會遺漏領(lǐng)域特定術(shù)語或?qū)⑵溴e誤分類。例如，“CAR-T therapy”可能被標記為汽車研究，而不是“嵌合抗原受體 T 細胞”療法。訓練領(lǐng)域?qū)Ｓ玫?NER 模型是一條我不想深陷的“兔子洞”。
概念建模在這里確實能派上用場——如果你的領(lǐng)域有強大的本體論，實體鏈接就會更可靠。我的客戶沒有這些框架，所以我采用了更簡單且始終有效的方法。
對于元數(shù)據(jù)模式，我采用結(jié)構(gòu)化而非扁平關(guān)鍵詞列表。每份文檔都打上分層元數(shù)據(jù)標簽，如 document_type: "clinical_trial"、therapeutic_area: "oncology"、patient_population: "pediatric" 等。這樣我就能在語義搜索前先進行結(jié)構(gòu)化過濾。
這不如帶實體關(guān)系的正規(guī)知識圖譜那么高級，但更易維護和調(diào)試。檢索失敗時，我能迅速判斷是元數(shù)據(jù)過濾問題還是語義搜索問題。在結(jié)構(gòu)化元數(shù)據(jù)字段上做 BM25F 對精確匹配效果很好，再疊加向量搜索處理概念性查詢。這種混合方案既能抓住精確術(shù)語搜索，也能覆蓋更寬泛的語義查詢。
來源：https://www.reddit.com/r/LocalLLaMA/comments/1ned2ai/building_rag_systems_at_enterprise_scale_20k_docs/
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
