過(guò)去一年里，我一直在為受監(jiān)管領(lǐng)域的中型企業(yè)（員工 100–1000 人）搭建 RAG 系統(tǒng)，說(shuō)實(shí)話，這比任何教程里看起來(lái)都難。目前已服務(wù) 10 多家客戶——制藥公司、銀行、律所、咨詢公司。想分享一下真正關(guān)鍵的經(jīng)驗(yàn)，而不是網(wǎng)上那些千篇一律的基礎(chǔ)信息。

快速背景：這些公司大多有 1 萬(wàn)到 5 萬(wàn)+ 份文檔，被困在 SharePoint 地獄或 2005 年的文檔管理系統(tǒng)里。不是干凈的數(shù)據(jù)集，也不是精心策劃的知識(shí)庫(kù)——只是幾十年積累下來(lái)的業(yè)務(wù)文檔，卻必須能被搜索。

文檔質(zhì)量檢測(cè)：沒(méi)人談?wù)摰年P(guān)鍵環(huán)節(jié)

這對(duì)我來(lái)說(shuō)是最震撼的發(fā)現(xiàn)。大多數(shù)教程都默認(rèn)你的 PDF 完美無(wú)缺?，F(xiàn)實(shí)是：企業(yè)文檔就是垃圾堆。

我曾服務(wù)一家藥企，他們的研究論文最早可追溯到 1995 年，全是打字稿的掃描件，OCR 幾乎失效。又混雜著現(xiàn)代 500 多頁(yè)的臨床試驗(yàn)報(bào)告，里面嵌著表格和圖表。想用同一套分塊策略處理這兩種文檔？等著看系統(tǒng)給你返回一堆胡言亂語(yǔ)吧。

花了好幾周調(diào)試，為什么某些文檔返回的結(jié)果極差，而另一些卻完全正常。最終意識(shí)到，必須在處理前先給文檔質(zhì)量打分：

• 干凈的 PDF（文本提取完美）：完整層級(jí)處理

• 尚可的文檔（存在少量 OCR 偽影）：基礎(chǔ)分塊并附帶清理

• 垃圾文檔（掃描的手寫筆記）：簡(jiǎn)單固定分塊 + 人工審核標(biāo)記

我們構(gòu)建了一套簡(jiǎn)單的評(píng)分體系，評(píng)估文本提取質(zhì)量、OCR 偽影和格式一致性，并按得分把文檔路由到不同的處理流水線。僅此一項(xiàng)改進(jìn)，比任何嵌入模型升級(jí)都解決了更多檢索問(wèn)題。

為什么固定長(zhǎng)度分塊基本不靠譜

所有教程都在說(shuō)：“直接按 512 token 重疊分塊！”

現(xiàn)實(shí)：文檔有結(jié)構(gòu)。論文的方法論章節(jié)和結(jié)論完全不同，財(cái)報(bào)的執(zhí)行摘要和明細(xì)表也各有特點(diǎn)。一旦忽略結(jié)構(gòu)，就會(huì)得到半截句子或把無(wú)關(guān)概念硬拼在一起的塊。

必須構(gòu)建保留文檔結(jié)構(gòu)的分層切塊：

• 文檔級(jí)（標(biāo)題、作者、日期、類型）

• 章節(jié)級(jí)（摘要、方法、結(jié)果）

• 段落級(jí)（200–400 個(gè) token）

• 句子級(jí)用于精確查詢

關(guān)鍵洞察：查詢的復(fù)雜度應(yīng)決定檢索的層級(jí)。寬泛的問(wèn)題停留在段落級(jí)。像“表3中的確切劑量是多少？”這類精確內(nèi)容需要句子級(jí)的精度。

我使用簡(jiǎn)單的關(guān)鍵詞檢測(cè)——“exact”、“specific”、“table”等詞會(huì)觸發(fā)精確模式。如果置信度低，系統(tǒng)會(huì)自動(dòng)下沉到更精細(xì)的片段。

元數(shù)據(jù)架構(gòu)比你的嵌入模型更重要

這是我投入 40% 開(kāi)發(fā)時(shí)間的地方，也是所有工作中 ROI 最高的部分。

大多數(shù)人把元數(shù)據(jù)當(dāng)作事后才考慮的東西。但企業(yè)查詢的上下文極其復(fù)雜。一位制藥研究員查詢“兒科研究”時(shí)，所需的文檔與查詢“成人人群”的人完全不同。

構(gòu)建了領(lǐng)域?qū)俚脑獢?shù)據(jù)模式：

針對(duì)制藥文檔：

• 文檔類型（研究論文、監(jiān)管文件、臨床試驗(yàn)）

• 藥物分類

• 患者人口統(tǒng)計(jì)學(xué)（兒科、成人、老年）

• 監(jiān)管類別（FDA、EMA）

• 治療領(lǐng)域（心臟病學(xué)、腫瘤學(xué)）

對(duì)于金融文檔：

• 時(shí)間段（2023 年第一季度、2022 財(cái)年）

• 財(cái)務(wù)指標(biāo)（收入、EBITDA）

• 業(yè)務(wù)板塊

• 地理區(qū)域

避免用 LLMs 做元數(shù)據(jù)提取——它們極其不穩(wěn)定。簡(jiǎn)單的關(guān)鍵詞匹配效果好得多。查詢里包含“FDA”？就按 regulatory_category: "FDA" 過(guò)濾。提到“pediatric”？就應(yīng)用患者人群過(guò)濾。

每個(gè)領(lǐng)域先準(zhǔn)備 100–200 個(gè)核心術(shù)語(yǔ)，再根據(jù)匹配不佳的查詢逐步擴(kuò)充。領(lǐng)域?qū)＜彝ǔ：軜?lè)意幫忙整理這些列表。

當(dāng)語(yǔ)義搜索失敗時(shí)（劇透：經(jīng)常失敗）

純語(yǔ)義搜索的失敗率遠(yuǎn)高于人們?cè)敢獬姓J(rèn)的程度。在制藥和法律等專業(yè)領(lǐng)域，我看到的失敗率是 15–20%，而不是大家默認(rèn)的 5%。

把我逼瘋的主要失敗模式：

縮寫混淆： “CAR”在腫瘤學(xué)里指“Chimeric Antigen Receptor”，在影像論文里卻指“Computer Aided Radiology”。嵌入向量相同，含義卻完全不同。這問(wèn)題一直讓我頭疼。

精確技術(shù)查詢： 有人提問(wèn)“表 3 中的確切劑量是多少？”語(yǔ)義搜索能找到概念上相似的內(nèi)容，卻遺漏了具體的表格引用。

交叉引用鏈： 文檔之間不斷相互引用。藥物 A 的研究引用了藥物 B 的相互作用數(shù)據(jù)。語(yǔ)義搜索完全遺漏了這些關(guān)系網(wǎng)絡(luò)。

解決方案： 采用混合架構(gòu)。在文檔處理階段用圖結(jié)構(gòu)記錄文檔間關(guān)系；語(yǔ)義搜索后，系統(tǒng)會(huì)檢查已召回文檔是否關(guān)聯(lián)到含有更優(yōu)答案的其他文檔。

對(duì)于縮寫詞，我借助領(lǐng)域?qū)倏s寫庫(kù)做上下文感知展開(kāi)；遇到精確查詢，關(guān)鍵詞觸發(fā)器會(huì)切換到基于規(guī)則的檢索，直接定位特定數(shù)據(jù)點(diǎn)。

為何我選擇開(kāi)源模型（具體是 Qwen）

多數(shù)人默認(rèn) GPT-4o 或 o3-mini 永遠(yuǎn)更強(qiáng)。但企業(yè)客戶總有各種奇怪限制：

• 成本： 當(dāng)文檔超過(guò) 5 萬(wàn)份、每日查詢達(dá)數(shù)千次時(shí)，API 費(fèi)用會(huì)飆升

• 數(shù)據(jù)主權(quán)： 制藥和金融企業(yè)無(wú)法將敏感數(shù)據(jù)發(fā)送到外部 API

• 領(lǐng)域術(shù)語(yǔ)： 通用模型在遇到未訓(xùn)練過(guò)的專業(yè)術(shù)語(yǔ)時(shí)會(huì)產(chǎn)生幻覺(jué)

經(jīng)過(guò)領(lǐng)域特定微調(diào)后，Qwen QWQ-32B 的表現(xiàn)出乎意料地好：

• 比 GPT-4o 處理大批量任務(wù)便宜 85%

• 全部數(shù)據(jù)留在客戶本地基礎(chǔ)設(shè)施

• 可針對(duì)醫(yī)療/金融術(shù)語(yǔ)進(jìn)行微調(diào)

• 響應(yīng)時(shí)間穩(wěn)定，無(wú) API 速率限制

微調(diào)方法很簡(jiǎn)單——用領(lǐng)域問(wèn)答對(duì)做監(jiān)督訓(xùn)練。我們構(gòu)建的數(shù)據(jù)集形如“藥物 X 的禁忌癥有哪些？”并配上 FDA 指南中的真實(shí)答案?；A(chǔ)的監(jiān)督微調(diào)效果比 RAFT 這類復(fù)雜方法更好，關(guān)鍵在于訓(xùn)練數(shù)據(jù)要干凈。

表格處理：隱藏的噩夢(mèng)

企業(yè)文檔里滿是復(fù)雜表格——財(cái)務(wù)模型、臨床試驗(yàn)數(shù)據(jù)、合規(guī)矩陣。標(biāo)準(zhǔn) RAG 要么直接忽略表格，要么把表格當(dāng)無(wú)結(jié)構(gòu)文本抽取，導(dǎo)致所有關(guān)系信息丟失。

表格往往包含最關(guān)鍵的信息。金融分析師需要特定季度的精確數(shù)字，研究人員需要臨床表格中的劑量信息。如果處理不了表格數(shù)據(jù)，你就損失了一半價(jià)值。

我的做法：

• 將表格視為獨(dú)立實(shí)體，擁有專屬處理流程

• 利用啟發(fā)式規(guī)則檢測(cè)表格（間距模式、網(wǎng)格結(jié)構(gòu)）

• 簡(jiǎn)單表格：轉(zhuǎn)為 CSV；復(fù)雜表格：在元數(shù)據(jù)中保留層級(jí)關(guān)系

• 雙重嵌入策略：同時(shí)嵌入結(jié)構(gòu)化數(shù)據(jù)和語(yǔ)義描述

在銀行項(xiàng)目中，金融表格無(wú)處不在。還必須追蹤匯總表與詳細(xì)明細(xì)表之間的關(guān)系。

生產(chǎn)基礎(chǔ)設(shè)施現(xiàn)實(shí)檢驗(yàn)

教程假設(shè)資源無(wú)限、服務(wù)永遠(yuǎn)在線。而生產(chǎn)環(huán)境意味著并發(fā)用戶、GPU 內(nèi)存管理、響應(yīng)時(shí)間一致性和可用性保障。

大多數(shù)企業(yè)客戶手頭已有閑置的 GPU 基礎(chǔ)設(shè)施——未使用的算力或用于其他數(shù)據(jù)科學(xué)任務(wù)。這讓本地部署比預(yù)期更容易。

通常部署 2–3 個(gè)模型：

• 主生成模型（Qwen 32B）用于處理復(fù)雜查詢

• 輕量級(jí)元數(shù)據(jù)提取模型

• 專用嵌入模型

盡可能使用量化版本。Qwen QWQ-32B 量化到 4 位僅需 24GB 顯存，同時(shí)保持質(zhì)量。單張 RTX 4090 即可運(yùn)行，但并發(fā)用戶多時(shí) A100 更佳。

最大的挑戰(zhàn)不是模型質(zhì)量，而是防止多用戶同時(shí)訪問(wèn)時(shí)的資源爭(zhēng)用。使用信號(hào)量限制并發(fā)模型調(diào)用，并做好隊(duì)列管理。

真正關(guān)鍵的經(jīng)驗(yàn)教訓(xùn)

1. 先檢測(cè)文檔質(zhì)量： 不能對(duì)所有企業(yè)文檔一視同仁。先建立質(zhì)量評(píng)估，再做其他。

2. 元數(shù)據(jù) > 嵌入： 元數(shù)據(jù)差，無(wú)論向量多好，檢索也差?；〞r(shí)間做領(lǐng)域?qū)Ｓ媚Ｊ健?/p>

3. 混合檢索是必須的： 在專業(yè)領(lǐng)域，純語(yǔ)義搜索經(jīng)常失敗。需要基于規(guī)則的回退和文檔關(guān)系映射。

4. 表格至關(guān)重要： 如果你無(wú)法正確處理表格數(shù)據(jù)，就會(huì)錯(cuò)失大量企業(yè)價(jià)值。

5. 基礎(chǔ)設(shè)施決定成敗： 客戶更看重可靠性，而不是花哨的功能。資源管理和正常運(yùn)行時(shí)間比模型復(fù)雜度更重要。

實(shí)話實(shí)說(shuō)

企業(yè)級(jí) RAG 更多是工程問(wèn)題，而非 ML 問(wèn)題。大多數(shù)失敗并非源于模型不佳，而是低估了文檔處理挑戰(zhàn)、元數(shù)據(jù)復(fù)雜性以及生產(chǎn)基礎(chǔ)設(shè)施需求。

需求現(xiàn)在簡(jiǎn)直瘋狂。但凡擁有大量文檔倉(cāng)庫(kù)的公司都需要這類系統(tǒng)，但大多數(shù)人根本不知道面對(duì)真實(shí)文檔時(shí)有多復(fù)雜。

總之，這比教程里看起來(lái)難得多。企業(yè)文檔里的各種邊緣情況會(huì)讓你想把筆記本扔出窗外。但一旦跑通，ROI 相當(dāng)可觀——見(jiàn)過(guò)團(tuán)隊(duì)把文檔搜索從幾小時(shí)縮到幾分鐘。

幾天前發(fā)在 LLMDevs 上，很多人覺(jué)得這個(gè)技術(shù)拆解有用，所以也在這里分享給更廣泛的 AI 社區(qū)！

QA

Q：你用的是什么技術(shù)棧？ A：其實(shí)每個(gè)項(xiàng)目略有不同，但我的常用棧是：Python、Ollama、vLLM、React/Next.js、Qdrant、Nomic Embeddings、PyMuPDF、Tesseract、PostgreSQL。

Q：好奇你用了哪些庫(kù)——我們也在給 HR 和 IT 部門做類似的事，PDF 處理絕對(duì)是 80% 的坑。目前混用一堆工具。我試了 PyMUPDF，糾偏和畫質(zhì)修復(fù)效果不錯(cuò)，但跑得太久，根本沒(méi)法讓用戶邊等邊分析。有興趣私聊——我們可能會(huì)碰到金融和制藥場(chǎng)景，現(xiàn)在沒(méi)精力深耕，以后也許得把活兒轉(zhuǎn)出去。 A：處理 PDF 我采用“組合拳”，不押寶在單一庫(kù)上。PyMUPDF 提取文本和基礎(chǔ)版面識(shí)別還行，但性能確實(shí)拉胯，實(shí)時(shí)場(chǎng)景根本扛不住。我的常規(guī)組合：pymupdf 做初篩提取，pdfplumber 負(fù)責(zé)表格定位，復(fù)雜表格再讓 camelot 當(dāng)備胎?？烧f(shuō)實(shí)話，它們都會(huì)在某些文檔上翻車，所以我把疑難雜癥直接扔給 VLM 繼續(xù)啃。

為了解決性能問(wèn)題，我把所有 PDF 處理都放在文檔攝取階段完成，而不是在查詢時(shí)進(jìn)行。用戶無(wú)需等待 PDF 解析——解析在文檔上傳時(shí)就在后臺(tái)完成。查詢階段只做向量搜索和生成，速度要快得多。糾偏和質(zhì)量修復(fù)雖然重要，但開(kāi)銷很大，我只對(duì)那些初次質(zhì)量評(píng)分未通過(guò)的文檔應(yīng)用這些修正。大多數(shù)企業(yè) PDF 足夠干凈，不需要重度預(yù)處理。

HR 和 IT 文檔的挑戰(zhàn)可能與制藥行業(yè)不同——格式更雜、結(jié)構(gòu)更缺乏標(biāo)準(zhǔn)化。但原則一樣：先檢測(cè)質(zhì)量，再路由到合適的處理流水線。

Q：你如何給文檔做質(zhì)量評(píng)分？ A：我在文檔攝取階段會(huì)結(jié)合使用一些簡(jiǎn)單指標(biāo)：

文本提取質(zhì)量：隨機(jī)抽取部分段落，統(tǒng)計(jì)可識(shí)別單詞與亂碼字符的比例。干凈的 PDF 可讀文本比例在 95% 以上，OCR 偽影會(huì)表現(xiàn)為奇怪的字符組合。

結(jié)構(gòu)一致性：檢查是否有正確的段落換行、統(tǒng)一的間距、可識(shí)別的標(biāo)題。掃描文檔往往間距不規(guī)則或行被合并。

字符模式分析：留意常見(jiàn) OCR 錯(cuò)誤，如把 “rn” 識(shí)別成 “m”，或文本中隨機(jī)散布特殊字符。布局檢測(cè)成功率：嘗試識(shí)別標(biāo)題、段落、表格等基本文檔元素。如果解析庫(kù)無(wú)法檢測(cè)到任何結(jié)構(gòu)，大概率是低質(zhì)量掃描。

我按 0–10 分打分并設(shè)定閾值——低于 4 分的直接走固定大小分塊，并標(biāo)記人工復(fù)核；4–6 分做基礎(chǔ)處理加清理；7 分以上才啟用完整層級(jí)處理。方法很粗糙，但能攔住那些明顯“越 sophisticated 越垃圾”的文檔。每篇在入庫(kù)時(shí)耗時(shí)約 30 秒，離線跑完全可接受。評(píng)分不完美，卻省得我浪費(fèi)時(shí)間給壓根沒(méi)結(jié)構(gòu)的文檔硬抽意義。

Q： 感謝所有細(xì)節(jié)，提供了很多洞見(jiàn)和啟發(fā)。雖然這么說(shuō)有點(diǎn)瘋狂，但向量嵌入其實(shí)沒(méi)那么神。它們非?！班须s”，語(yǔ)義相似性本質(zhì)上只是統(tǒng)計(jì)相似性，兩個(gè)片段可能相似卻毫無(wú)關(guān)聯(lián)。更糟糕的是，一份關(guān)于人類癌癥的文件和一份關(guān)于豬癌癥的文件，語(yǔ)義相似性會(huì)愉快地把兩個(gè)文檔的片段混在一起，給出一個(gè)完全錯(cuò)誤的答案。

我認(rèn)為你強(qiáng)調(diào)的關(guān)鍵在于：面對(duì)非結(jié)構(gòu)化數(shù)據(jù)，你越是能把它結(jié)構(gòu)化，就越能借助這些結(jié)構(gòu)精準(zhǔn)定位相關(guān)文檔和段落。這沒(méi)有向量嵌入那么“性感”，但速度快且有效。早在向量嵌入出現(xiàn)之前，我們靠數(shù)據(jù)庫(kù)和網(wǎng)頁(yè)搜索就已經(jīng)做得不錯(cuò)了。并非每把工具都是（語(yǔ)義）錘子。

我有一個(gè)問(wèn)題：您能否分享一些關(guān)于本地查詢與全局查詢的細(xì)節(jié)或想法？這兩類查詢需要不同的搜索策略，那么您是如何判斷一條查詢是本地還是全局的呢？

例如，“給我所有與 XYZ 相關(guān)的結(jié)果”屬于局部查詢，因?yàn)樗鼘ｉT針對(duì) XYZ，通常只需查找包含 XYZ 的片段即可找到；而“這份文檔的關(guān)鍵要點(diǎn)是什么？”則是全局查詢，因?yàn)椴樵儽旧頉](méi)有特定指向，需要采用不同的搜索策略。

A：

你說(shuō)得很對(duì)，向量嵌入確實(shí)充滿噪聲，癌癥的例子非常貼切——語(yǔ)義相似性可能在完全不同的語(yǔ)境之間建立危險(xiǎn)的錯(cuò)誤關(guān)聯(lián)。豬與人癌癥的問(wèn)題恰恰說(shuō)明了在運(yùn)行語(yǔ)義搜索之前，元數(shù)據(jù)過(guò)濾為何至關(guān)重要。

對(duì)于局部與全局查詢的識(shí)別，我使用了一些在實(shí)踐中效果不錯(cuò)的簡(jiǎn)單啟發(fā)式規(guī)則：

本地查詢指示符：具體實(shí)體名稱、日期、數(shù)字、“查找所有”“給我看”“……做了什么”等短語(yǔ)、專有名詞、技術(shù)術(shù)語(yǔ)。這些通常映射到特定分塊或文檔段落。

全局查詢指標(biāo)：像“總結(jié)”“概覽”“關(guān)鍵要點(diǎn)”“主要主題”“比較”“分析”這類詞。這些需要文檔級(jí)或跨文檔的綜合。

我還會(huì)看查詢長(zhǎng)度——更長(zhǎng)的查詢往往更具體/局部，短的則更全局。“Drug X 在 II 期試驗(yàn)中的副作用是什么？”顯然是局部的。“主要發(fā)現(xiàn)是什么？”是全局的。

對(duì)于全局查詢，我會(huì)檢索更廣泛的上下文——比如取前 20 個(gè)片段而不是 5 個(gè)，或者拉取章節(jié)級(jí)片段而非段落級(jí)。有時(shí)我會(huì)先進(jìn)行文檔級(jí)摘要，再?gòu)恼凶鞔稹?/p>

檢測(cè)并不完美，但能抓住大多數(shù)情況。拿不準(zhǔn)時(shí)，我默認(rèn)用本地搜索，因?yàn)樗欤脩羧粝肴址治?，通常也能重新表述。沒(méi)錯(cuò)，我們確實(shí)被向量嵌入的炒作帶偏了。在把問(wèn)題復(fù)雜化、引入語(yǔ)義相似度之前，關(guān)鍵詞搜索加結(jié)構(gòu)化過(guò)濾就已經(jīng)能很好地解決大多數(shù)文檔檢索需求。

Q：你現(xiàn)有的知識(shí)和技術(shù)棧能在多大程度上加速類似未來(lái)項(xiàng)目的開(kāi)發(fā)？比如，一家大型汽車零部件供應(yīng)商想要一個(gè) RAG 系統(tǒng)，你估計(jì)有多少比例的工作可以復(fù)用？

A：你說(shuō)得有點(diǎn)道理，但關(guān)鍵在于——如果這是一個(gè)純文本系統(tǒng)，或者我已經(jīng)針對(duì)某個(gè)特定用例/需求搭建過(guò)，那就不算難。我可以復(fù)用 90% 的代碼直接交付，目前我就是按授權(quán)模式這么做的?？杉幢阄易焐险f(shuō)“不難”，作為企業(yè)他們依舊不知道怎樣讓這套系統(tǒng)支撐 2 萬(wàn)篇文檔或更大規(guī)模的信息。這種深度領(lǐng)域知識(shí)我恰好掌握，他們才愿意為此付高價(jià)。

但情況并非總是如此。有些公司擁有老舊文檔，有些客戶希望連接包含數(shù)百萬(wàn)條記錄的數(shù)據(jù)庫(kù)，有些則需要模型成為能夠理解圖像、圖表、示意圖的視覺(jué)語(yǔ)言模型（VLM），并且仍然是開(kāi)放權(quán)重的模型。這只是冰山一角——定制化需求有時(shí)簡(jiǎn)直瘋狂。

但總的來(lái)說(shuō)，核心思路是：一旦我為某個(gè)客戶找到了解決方案，就會(huì)把同樣的領(lǐng)域知識(shí)或方法沿用到下一個(gè)客戶身上。所以策略沒(méi)錯(cuò)，我確實(shí)在大量復(fù)用已有成果，不過(guò)僅限于那些我已經(jīng)解決的問(wèn)題——而這類問(wèn)題現(xiàn)在已經(jīng)很多了。

Q：我有一個(gè)關(guān)于表格的問(wèn)題：如果把表格讀出來(lái)后，在數(shù)據(jù)集里直接轉(zhuǎn)成 JSON 結(jié)構(gòu)會(huì)怎樣？我在簡(jiǎn)單表格上試過(guò)，效果還不錯(cuò)。

關(guān)于文檔內(nèi)容，你有沒(méi)有做過(guò)“上下文增強(qiáng)”？比如刻意在文本里重復(fù)一些關(guān)鍵詞，或者給一段/一章內(nèi)容人工生成10組問(wèn)答？我不確定在面對(duì)真實(shí)客戶數(shù)據(jù)時(shí)這么做是否合規(guī)，甚至是否道德，但在我自己的實(shí)驗(yàn)里，這些做法確實(shí)帶來(lái)了不錯(cuò)的效果。 A： 把表格轉(zhuǎn)成 JSON 對(duì)結(jié)構(gòu)簡(jiǎn)單、行列清晰的表格確實(shí)靠譜。JSON 能更好地保留鍵值關(guān)系，你可以同時(shí)嵌入 JSON 結(jié)構(gòu)和一段自然語(yǔ)言描述，說(shuō)明這張表到底包含什么。財(cái)務(wù)數(shù)據(jù)、規(guī)格參數(shù)等需要保留關(guān)系的表格都適用。缺點(diǎn)是，一旦表格出現(xiàn)合并單元格、多級(jí)表頭或布局不規(guī)則，JSON 就會(huì)變得很亂；這種時(shí)候我通?；赝说奖Ａ粢曈X(jué)結(jié)構(gòu)，或者直接上 VLM 提取。

在內(nèi)容增強(qiáng)方面，我避免人為重復(fù)關(guān)鍵詞或從客戶數(shù)據(jù)中生成合成問(wèn)答對(duì)。這種做法像是數(shù)據(jù)操控，可能引入偏差或不準(zhǔn)確之處，尤其是企業(yè)客戶不希望原始內(nèi)容被改動(dòng)。相反，我專注于在預(yù)處理階段豐富元數(shù)據(jù)和文檔關(guān)系，例如提取關(guān)鍵實(shí)體、標(biāo)記內(nèi)容類型、構(gòu)建引用圖譜。這樣可以在不改變?cè)床牧系那疤嵯绿嵘龣z索效果。

Q&A 生成方法或許適用于訓(xùn)練數(shù)據(jù)或知識(shí)庫(kù)這類可以驗(yàn)證準(zhǔn)確性的場(chǎng)景，但面對(duì)真實(shí)客戶文檔時(shí)，我會(huì)謹(jǐn)慎對(duì)待添加合成內(nèi)容，以免用戶誤將其當(dāng)作原始信息。

Q：你們?nèi)绾翁幚砦臋n生命周期問(wèn)題？比如排除過(guò)時(shí)或舊版本？ A：文檔生命周期管理絕對(duì)是那種看起來(lái)簡(jiǎn)單、真到大規(guī)模落地就復(fù)雜的事情。大多數(shù)客戶對(duì)文檔沒(méi)有像樣的版本控制，所以我只能基于文件名模式和內(nèi)容哈希做簡(jiǎn)單去重。一旦看到“Financial_Report_Q3_2023_v2.pdf”和“Financial_Report_Q3_2023_final.pdf”，就標(biāo)記出來(lái)人工確認(rèn)哪個(gè)才是最新版。

對(duì)于監(jiān)管文檔，我會(huì)在元數(shù)據(jù)中記錄發(fā)布日期和監(jiān)管狀態(tài)。2015 年的 FDA 指南可能被 2023 年版本取代，但有時(shí)兩者在歷史背景下都有參考價(jià)值，這通常需要領(lǐng)域?qū)＜遗袛唷Ｎ疫€實(shí)現(xiàn)了簡(jiǎn)單的“陳舊性”檢測(cè)——超過(guò) 2 年未被訪問(wèn)或引用的文檔會(huì)被標(biāo)記待審。但我會(huì)謹(jǐn)慎避免自動(dòng)刪除，因?yàn)槠髽I(yè)客戶對(duì)信息丟失極度敏感。

最棘手的部分是文檔關(guān)系發(fā)生變化時(shí)。如果某項(xiàng)臨床研究被更新，所有引用它的報(bào)告可能都需要重新處理，以更新其元數(shù)據(jù)連接。我的大多數(shù)客戶最終都會(huì)指派專人管理文檔工作流，而不是試圖完全自動(dòng)化。他們會(huì)按季度審查，將文檔標(biāo)記為已歸檔、已取代或當(dāng)前有效。雖然不夠優(yōu)雅，但比構(gòu)建復(fù)雜的自動(dòng)化生命周期規(guī)則效果更好。

當(dāng)客戶擁有合適的文檔管理系統(tǒng)時(shí)，版本控制會(huì)變得更容易，但大多數(shù)人仍在處理幾十年間被扔進(jìn) SharePoint 文件夾的文件。

Q：我曾遇到這樣的情況：客戶要求我們?yōu)閼?yīng)用構(gòu)建一個(gè) RAG，其數(shù)據(jù)源是關(guān)系型數(shù)據(jù)庫(kù)，里面存有每個(gè)人的項(xiàng)目詳情、工作團(tuán)隊(duì)信息等類似內(nèi)容。于是我們手動(dòng)為每個(gè)人的數(shù)據(jù)生成一段模板（摘要），再上傳到 Qdrant。實(shí)際上，我們 RAG 的檢索準(zhǔn)確率只有 50%，采用的是純稠密嵌入方案。從表數(shù)據(jù)生成摘要，這種做法合適嗎？ A：50% 的檢索準(zhǔn)確率相當(dāng)?shù)停艺J(rèn)為手動(dòng)摘要方式可能是問(wèn)題之一。對(duì)于項(xiàng)目詳情、團(tuán)隊(duì)信息等結(jié)構(gòu)化數(shù)據(jù)庫(kù)內(nèi)容，生成敘述性摘要往往會(huì)丟失人們實(shí)際查詢的精確可檢索要素。當(dāng)有人提問(wèn)“找出 2023 年 John 與營(yíng)銷團(tuán)隊(duì)合作的所有項(xiàng)目”時(shí)，需要的是姓名、部門和日期的精確匹配——而不是散文式描述。

我會(huì)改用混合方案：把結(jié)構(gòu)化數(shù)據(jù)保留為結(jié)構(gòu)化元數(shù)據(jù)（人名、項(xiàng)目 ID、團(tuán)隊(duì)名、日期、技能），用于精確過(guò)濾；再對(duì)描述性內(nèi)容（項(xiàng)目描述、角色摘要、成就）做向量化。于是檢索流程變成：先用結(jié)構(gòu)化條件過(guò)濾（team=marketing，year=2023），再在這些結(jié)果里做語(yǔ)義搜索，回答概念性查詢。

純稠密向量在結(jié)構(gòu)化數(shù)據(jù)上表現(xiàn)吃力，因?yàn)樗噲D學(xué)習(xí)員工 ID 與項(xiàng)目代號(hào)之間的“語(yǔ)義關(guān)系”，而這些標(biāo)識(shí)符本身并無(wú)語(yǔ)義意義。此外，用戶對(duì)結(jié)構(gòu)化數(shù)據(jù)的查詢方式也與文檔不同：他們要的是“所有參與過(guò)移動(dòng)項(xiàng)目的開(kāi)發(fā)者”或“預(yù)算超 10 萬(wàn)的項(xiàng)目”——可過(guò)濾的硬條件夾雜少量語(yǔ)義概念。

若想在模板法里見(jiàn)效，就得用更一致的結(jié)構(gòu)化字段，但說(shuō)實(shí)話，把結(jié)構(gòu)化數(shù)據(jù)單獨(dú)當(dāng)元數(shù)據(jù)字段，對(duì)絕大多數(shù)查詢都更靠譜。

Q：這簡(jiǎn)直是一座寶庫(kù)。我對(duì)所謂的企業(yè)級(jí) RAG 還只是淺嘗輒止，遠(yuǎn)未考慮到并發(fā)使用、基礎(chǔ)設(shè)施、可靠性等問(wèn)題。“表格數(shù)據(jù)”和“技術(shù)圖表”已被證明是最具挑戰(zhàn)性和吸引力的部分之一。原生 RAG 很快就暴露出局限性，至少在我這里是這樣。

不知道你是否遇到過(guò)需要解讀并理解非文本內(nèi)容（表格除外）的場(chǎng)景？又是如何解決的？當(dāng)然，一種思路是用圖文生成模型為圖像生成描述，但目前速度相當(dāng)慢，尤其在做本地部署時(shí)。

此外，你是否遇到過(guò)這種情況：并非處理靜態(tài)文檔集，而是面對(duì)高度動(dòng)態(tài)的文檔集，例如新發(fā)布文檔或其他持續(xù)頻繁更新的資料？

A： 對(duì)于表格以外的非文本內(nèi)容，我處理過(guò)技術(shù)示意圖、圖表和流程圖。正如你所說(shuō)，圖像轉(zhuǎn)文本生成速度很慢，因此我會(huì)有選擇地使用。對(duì)于在多個(gè)文檔中反復(fù)出現(xiàn)的示意圖，我會(huì)一次性處理并復(fù)用其描述。對(duì)于一次性圖像，有時(shí)我會(huì)直接接受它們無(wú)法被檢索的事實(shí)，轉(zhuǎn)而聚焦在周圍的文本上下文上。

VLM 在技術(shù)圖表上的表現(xiàn)優(yōu)于通用圖像描述模型，能更準(zhǔn)確地理解流程圖、網(wǎng)絡(luò)拓?fù)浜土鞒坦ぷ髁?。但你說(shuō)得對(duì)，本地部署確實(shí)存在性能權(quán)衡——準(zhǔn)確性與速度之間需要取舍。

對(duì)于動(dòng)態(tài)文檔集，我采用增量更新管道而非全量重處理。新文檔先經(jīng)過(guò)質(zhì)量評(píng)分，再走同一處理流程。難點(diǎn)在于處理文檔間的關(guān)聯(lián)——若某技術(shù)規(guī)范被更新，我得找出所有引用它的文檔，并視情況刷新其元數(shù)據(jù)。

我還會(huì)追蹤文檔的“新鮮度”，并在相關(guān)文檔可能過(guò)期時(shí)發(fā)出提醒。比如產(chǎn)品手冊(cè)已更新，但故障排查指南仍引用舊版本號(hào)，用戶瀏覽這些可能失效的信息時(shí)會(huì)收到警告。

版本管理在動(dòng)態(tài)文檔集中變得至關(guān)重要。我會(huì)維護(hù)一份簡(jiǎn)單的文檔血緣記錄，讓用戶知道他們看到的是當(dāng)前信息還是已被取代的信息。雖然不完美，但能捕捉到大多數(shù)因文檔更新導(dǎo)致知識(shí)庫(kù)不一致的情況。與靜態(tài)文檔集相比，頻繁更新時(shí)基礎(chǔ)設(shè)施需求確實(shí)會(huì)更復(fù)雜。

Q： 太厲害了。從你其他的回復(fù)來(lái)看，似乎只有你自己、你兄弟和 Claude Code 三個(gè)人，這更令人驚嘆。這簡(jiǎn)直就是生成式 AI 把生產(chǎn)力放大 20 倍的活例子。

那么，你們是如何判斷哪些技術(shù)圖紙、流程圖該被處理、哪些不該呢？這得從用戶視角出發(fā)，具備深度洞察、領(lǐng)域知識(shí)，還得懂相關(guān)性。是讓客戶替你們挑嗎？否則我真好奇你們?cè)趺匆?guī)?；膺@一步就能把團(tuán)隊(duì)拖垮。我是產(chǎn)品經(jīng)理（還能寫點(diǎn)代碼，現(xiàn)在基本靠“氛圍編程”），外加 1 個(gè)人，正試圖吞進(jìn) 30 份文檔（平均 300 頁(yè)/份），全是硬核技術(shù)資料。注意，這些文檔我熟得不能再熟，就是我的產(chǎn)品，可連 20% 的標(biāo)注我都搞不完。所以我才琢磨：能不能讓 AI 先打個(gè)相關(guān)性分？

至于處理文檔的增量更新，這是個(gè)有趣的做法。如果你有空，很想了解你是怎么做的。我為了“圍繞”文檔差異做語(yǔ)義分塊而絞盡腦汁，結(jié)果并不美好。我意識(shí)到，如果同一文檔兩個(gè)版本之間的差異高度集中，這方法或許可行；可一旦改動(dòng)四處散落，最終狀態(tài)就會(huì)一團(tuán)糟，或者分塊邏輯得塞進(jìn)大量啟發(fā)式規(guī)則。

A：沒(méi)錯(cuò)，它絕對(duì)是個(gè)放大器！

因此，對(duì)于技術(shù)圖表，我不會(huì)自己拍板。在最初與客戶對(duì)接時(shí)，我會(huì)和他們的領(lǐng)域?qū)＜乙黄?，確定哪些類型的可視化內(nèi)容真正可被檢索，哪些只是參考資料。比如在制藥行業(yè)，工藝流程圖至關(guān)重要，而公司 Logo 則無(wú)關(guān)緊要。專家們清楚他們的團(tuán)隊(duì)實(shí)際會(huì)查詢什么。

我還會(huì)建立抽樣流程——先處理大約10%的圖表，看看效果如何，再逐步擴(kuò)大?？蛻艨梢詫忛喗Y(jié)果，告訴我該聚焦哪些類型。這比瞎猜高效得多。

針對(duì)你那 30 份文檔的挑戰(zhàn)，完全可以用 AI 做相關(guān)性打分。先用輕量模型給圖表分類——流程圖、照片、圖表——再按最可能包含可查詢信息的標(biāo)準(zhǔn)排優(yōu)先級(jí)。不完美，但比人工標(biāo)注強(qiáng)。

增量更新確實(shí)麻煩，你說(shuō)得對(duì)。我避免在差異上做“聰明”的語(yǔ)義分塊。相反，我按文檔章節(jié)追蹤，一旦某節(jié)有變動(dòng)就整塊重分。如果技術(shù)規(guī)范更新了第4.2節(jié)，我就把整節(jié)重新處理，而不是試圖修補(bǔ)單個(gè)塊。

對(duì)于零散的改動(dòng)，我干脆接受“有些文檔必須整體重新處理”這一事實(shí)。試圖在隨機(jī)編輯周圍維持分塊邊界，帶來(lái)的問(wèn)題遠(yuǎn)比它解決的要多。有時(shí)候，最樸素的“拿不準(zhǔn)就整篇重跑”反而比那些在邊界情況里會(huì)崩盤的復(fù)雜啟發(fā)式規(guī)則更靠譜。

Q：個(gè)人用的 OCR 解析器或把 PDF 喂給 LLM 端點(diǎn)，目前最好的 OCR 技術(shù)棧是什么？這些 PDF 大多是純文本報(bào)告，不含表格。

A： 對(duì)于不含表格、以文字為主的 PDF，越簡(jiǎn)單越好。Tesseract 加一些基礎(chǔ)預(yù)處理就能勝任，而且完全免費(fèi)。若處理掃描件，先跑一遍圖像增強(qiáng)——去歪斜、降噪、調(diào)對(duì)比。遇到質(zhì)量參差不齊的掃描，想提高識(shí)別率，PaddleOCR 通常比 Tesseract 更穩(wěn)，依舊是開(kāi)源，可本地運(yùn)行。

如果你想要更強(qiáng)大的方案，AWS Textract、Google Document AI 和 Azure Document 都是可靠的云選項(xiàng)，但會(huì)增加成本和延遲。只有在處理質(zhì)量極差的掃描件或需要超高準(zhǔn)確率時(shí)才值得使用。

預(yù)處理時(shí)，用 OpenCV 先清理圖像再 OCR，效果提升顯著。大多數(shù) OCR 失敗并非引擎問(wèn)題，而是圖像質(zhì)量太差。

既然你最終還是要把內(nèi)容送進(jìn) LLM 端點(diǎn)，就沒(méi)必要追求完美的文本提取——大多數(shù)現(xiàn)代 LLM 都能輕松應(yīng)對(duì)輕微的 OCR 偽影。把重點(diǎn)放在把大體內(nèi)容弄對(duì)，而不是像素級(jí)精確。

整個(gè)流程在大多數(shù)情況下都可以本地運(yùn)行，只需 tesseract 加上基礎(chǔ)的圖像預(yù)處理即可。只有當(dāng)你持續(xù)遇到特定文檔類型的質(zhì)量問(wèn)題時(shí)，才考慮升級(jí)到更復(fù)雜的方案。

Q：你們是如何評(píng)估 RAG 系統(tǒng)的？最終準(zhǔn)確率是多少？（比如金融場(chǎng)景）同樣這個(gè)場(chǎng)景，你們向客戶收了多少錢？（用了多少個(gè)工作日？）

A： 為進(jìn)行評(píng)估，我與領(lǐng)域?qū)＜液献?，為金融客戶?chuàng)建了黃金問(wèn)題集——約 150 個(gè)已知正確答案的測(cè)試查詢。同時(shí)追蹤檢索準(zhǔn)確率（是否找到了正確文檔？）和答案質(zhì)量（回答是否有用？）。

最終測(cè)試集準(zhǔn)確率約為87%，其余13%多為文檔信息沖突或查詢過(guò)于模糊的邊界情況。用戶對(duì)該性能水平表示滿意。

無(wú)法透露具體報(bào)價(jià)，但金額在 10 萬(wàn)美元以上，總耗時(shí)約 3–4 個(gè)月。第四個(gè)月主要用于測(cè)試與打磨，實(shí)際開(kāi)發(fā)約 3 個(gè)月。對(duì)一些人來(lái)說(shuō)可能顯得不現(xiàn)實(shí)，但我復(fù)用了之前項(xiàng)目約 50–60% 的代碼，甚至可能更多。

Q：感謝你的精彩分析；我們也在同一領(lǐng)域工作，但認(rèn)為只要有概念建模支撐，LLMs 在元數(shù)據(jù)提取方面表現(xiàn)相當(dāng)不錯(cuò)。

看起來(lái)你完全用基于關(guān)鍵詞的方法取代了實(shí)體識(shí)別與鏈接；你持反對(duì)立場(chǎng)的依據(jù)是什么？最終是得到類似在扁平關(guān)鍵詞列表上的 bm25f，還是仍然保留結(jié)構(gòu)化的元數(shù)據(jù)模式？

A：基于關(guān)鍵詞的方法源于對(duì)專業(yè)領(lǐng)域命名實(shí)體識(shí)別（NER）不一致的挫敗感。當(dāng)我嘗試對(duì)制藥文檔進(jìn)行實(shí)體識(shí)別時(shí)，它會(huì)遺漏領(lǐng)域特定術(shù)語(yǔ)或?qū)⑵溴e(cuò)誤分類。例如，“CAR-T therapy”可能被標(biāo)記為汽車研究，而不是“嵌合抗原受體 T 細(xì)胞”療法。訓(xùn)練領(lǐng)域?qū)Ｓ玫?NER 模型是一條我不想深陷的“兔子洞”。

概念建模在這里確實(shí)能派上用場(chǎng)——如果你的領(lǐng)域有強(qiáng)大的本體論，實(shí)體鏈接就會(huì)更可靠。我的客戶沒(méi)有這些框架，所以我采用了更簡(jiǎn)單且始終有效的方法。

對(duì)于元數(shù)據(jù)模式，我采用結(jié)構(gòu)化而非扁平關(guān)鍵詞列表。每份文檔都打上分層元數(shù)據(jù)標(biāo)簽，如 document_type: "clinical_trial"、therapeutic_area: "oncology"、patient_population: "pediatric" 等。這樣我就能在語(yǔ)義搜索前先進(jìn)行結(jié)構(gòu)化過(guò)濾。

這不如帶實(shí)體關(guān)系的正規(guī)知識(shí)圖譜那么高級(jí)，但更易維護(hù)和調(diào)試。檢索失敗時(shí)，我能迅速判斷是元數(shù)據(jù)過(guò)濾問(wèn)題還是語(yǔ)義搜索問(wèn)題。在結(jié)構(gòu)化元數(shù)據(jù)字段上做 BM25F 對(duì)精確匹配效果很好，再疊加向量搜索處理概念性查詢。這種混合方案既能抓住精確術(shù)語(yǔ)搜索，也能覆蓋更寬泛的語(yǔ)義查詢。

來(lái)源：https://www.reddit.com/r/LocalLLaMA/comments/1ned2ai/building_rag_systems_at_enterprise_scale_20k_docs/