我以為 AI 搞知識庫很簡單，直到我開始真的做
整理版優先睇
數據準備決定 RAG 系統上限，四個常見坑同解決方法
作者分享自己由跑通 RAG Demo 到真實業務嘅經歷，發現準確率得 40%，反直覺咁體會到系統上限唔係由模型決定，而係由數據準備決定。佢總結咗四個最常見嘅陷阱同解決方案，強調底層數據質量先係真正嘅樽頸。
第一個陷阱係 PDF 解析：用 PyPDF 讀雙欄文件會搞到內容交叉混排，AI 拎到嘅係一堆亂碼。解決方法係用專門工具（如 Docling）處理複雜佈局，同埋一定要親眼睇解析後嘅原始文本。第二個陷阱係按字數切塊：一句完整結論會被切成兩截，令上下文失效。正確做法係按文檔結構（標題、段落）切，再加麵包屑標記保留出處。第三個陷阱係純向量檢索：對專有名詞同數字會語義漂移，精確匹配失效。解法係混合檢索，用 BM25 做關鍵詞匹配加上向量檢索，實測召回率提升 30%。第四個陷阱係表格：非結構化文本處理會搞到行列關係消失，正確做法係將表格獨立處理成 Markdown 或 JSON。
最後作者覆盤時間分配：數據清洗只用咗 10% 時間，但帶嚟嘅提升係調模型同寫 Prompt 加埋嘅三倍。所以佢而家嘅優先級係：數據清洗質量 > Chunking 策略 > 檢索策略 > Prompt > 模型。底層數據嘅質量決定咗天花板，而唔係頂層嘅花巧嘢。
- PDF 解析要用專門工具（如 Docling），避免雙欄混排，而且一定要檢查原始文本。
- Chunking 應該按文檔結構（標題、段落）切，再加麵包屑保留上下文，唔好按字數亂切。
- 純向量檢索對專有名詞同數字會語義漂移，要用 BM25 加向量做混合檢索，召回率提升 30%。
- 表格要獨立處理，轉成 Markdown 或 JSON，唔可以混入普通文本 chunk。
- 數據準備嘅投入回報最高：10% 時間帶嚟嘅提升係調模型同寫 Prompt 加埋嘅三倍。
Docling
IBM 開源 PDF 解析工具，專門處理複雜佈局，解決雙欄混排問題。
PDF 解析：雙欄文件嘅隱形陷阱
多數人搭 RAG 系統第一步就係用 PyPDF 讀 PDF，切完存向量庫，跑完 demo 覺得好順。但一用到真實業務，尤其係雙欄排版嘅文件，準確率就暴跌。
RAG 系統的上限，不是模型決定的，係數據準備決定的
作者試過畀一份雙欄報告，AI 畀出嘅回答數據對唔上，原來係解析後左欄右欄交叉混排。人眼一睇就知廢，但 AI 唔會知。
雙欄 PDF 被讀成了交叉混排
後來換咗 Docling（IBM 開源工具）先解決到。教訓係：PDF 解析唔係「能跑通」就算，要真係去睇解析後嘅原始文本係咩樣。
PDF 解析唔係能跑通就算完，要真係去睇解析後的原始文本
Chunking：按字數切係畀 AI 食碎片
Chunking 係必做步驟，但好多人求其按字數切：每 500 字一塊，重疊 50 字。呢個做法有一個致命問題——完全唔理內容喺邊度斷。
一個完整的結論被切成了兩塊
結果前一塊有結論冇原因，後一塊有原因冇結論，兩塊分開召回都冇意義，又冇人會合返埋。
按文檔結構切——按標題、段落切
作者建議利用人類已經標註好嘅語義邊界，即係標題同段落。另外要喺每個 chunk 開頭加一串麵包屑，標明文檔名 > 一級標題 > 二級標題，咁召回時上下文唔會丟。
每個 chunk 開頭加一串麵包屑：[文檔名 > 一級標題 > 二級標題]
檢索策略：純向量檢索嘅死穴
向量檢索靠語義相似，你問「點樣提升性能」，佢會揾到「優化速度」嘅段落。聽落好勁，但佢對精確嘅專有名詞、產品型號、數字會語義漂移。
精確的專有名詞、產品型號、數字，向量檢索會『語義漂移』
例如你問「GPT-4o 嘅 context window 係幾多」，向量檢索可能畀你一堆「大模型上下文長度」嘅泛泛描述，揾唔到精確數字。
BM25（關鍵詞匹配）+ 向量檢索，兩路並行
解法係混合檢索：BM25 負責精確，向量負責語義，結果融合。實測召回率可以提升 30% 左右。可惜多數教程只教向量檢索，省略咗 BM25 部分。
召回率能提升 30% 左右
表格：非結構化數據最難搞嘅嘢
文本非結構化仲算易處理，但表格係真正嘅噩夢。一張有行列關係嘅表，經過多數 PDF 解析器之後會變成一串「產品A 價格100 庫存500 產品B 價格200 庫存300」。
行列關係完全消失
LLM 拎到呢串文字，根本唔知「100」對應「產品A」定係「價格」。作者見過有人用呢種方式做財務知識庫，最後要手動核對，仲慢過直接查表。
表格要單獨處理，轉成 Markdown 表格或 JSON 格式
正確做法係將表格獨立處理，唔好混入普通文本 chunk，咁先保留到行列關係。
時間分配覆盤：10% 嘅投入換來三倍回報
作者覆盤自己嘅時間分配：調模型參數花 20%，寫 Prompt 花 30%，數據清洗同 chunking 策略只花 10%。但結果呢？數據嗰 10% 帶嚟嘅提升，係前面 50% 嘅三倍。
數據那 10% 帶來的提升，是前面 50% 的三倍
所以作者而家嘅優先級好清楚：數據清洗 > Chunking > 檢索 > Prompt > 模型。唔係話模型唔重要，而係喺多數真實場景入面，底層數據先係樽頸。
大部分人行 RAG 系統嘅起點係咁樣嘅：
揾個教程，駁埋 LLM，將文件掉入去，跑通 demo，覺得好順滑。
然後用喺真實業務上——準確率得 40%。
我都係咁樣過嚟。
搞咗一段時間之後，我發現咗一件反直覺嘅事：
RAG 系統嘅上限，唔係由模型決定嘅，而係由數據準備決定嘅。
個個都喺度卷模型、卷 Prompt，但係真正搞冧個項目嘅，係最上游嗰步——你餵俾 AI 嘅「知識」本身，就已經亂曬籠。
第一個坑：PDF 解析，你以為搞掂咗，其實冇
我最開始用嘅係最常見嘅方案：直接用 PyPDF 將 PDF 讀成文字，然後切塊，存入向量庫。
跑通咗，demo 好靚。
直到有人拎咗一份雙欄排版嘅報告嚟試——AI 畀出嘅答案裏面，數據對唔上，上下文亂曬，好似亂咁噏。
我去睇原始解析結果，先發現問題：
雙欄 PDF 被讀成「左欄第一行 + 右欄第一行 + 左欄第二行 + 右欄第二行……」
兩欄內容完全交叉混埋一齊。對人眼嚟講一睇就知係廢嘅，但 AI 拎到嘅就係呢串文字，佢唔知。
後來換咗 Docling（IBM 出嘅開源工具），專處理複雜佈局，雙欄問題解決咗。
但係教訓係：PDF 解析唔係「跑得通」就算完，要真係去睇解析後嘅原始文字係咩樣。
大部份人 skip 咗呢步。
第二個坑：按字數切塊，係喺度餵碎片俾 AI
Chunking——將文件切做細塊存入向量庫——呢步大家都知要做。
但係點樣切，好多人冇認真諗過。
最常見嘅做法係按字數切：每 500 字一塊，相鄰嘅塊重疊 50 個字。
簡單，夠用，但係有一個致命問題：佢完全唔理你嘅內容喺邊度斷開。
我遇過咁樣嘅情況：一個完整嘅結論——「A 方案喺高併發場景下優於 B 方案，原因係……」——被切開咗兩塊。
前塊有結論，冇原因。後塊有原因，冇結論。
兩塊單獨召回，都冇意義。合埋一齊又冇人會將佢哋拼返埋。
正確嘅做法係按文件結構切——按標題、段落切，而唔係按字數切。
文件作者寫標題嘅時候，本來就係做緊語義分割。你按結構切，係利用人類已經標註好嘅語義邊界。
另外，每個 chunk 開頭加一串麪包屑（breadcrumb）：[文檔名 > 一級標題 > 二級標題]——召回嘅時候上下文唔會丟。
第三個坑：純向量檢索，專有名詞係佢嘅死穴
向量檢索嘅原理係語義相似——你問「點樣提升性能」，佢揾到講「優化速度」嘅段落，因為語義相近。
聽落好勁，實際上有一個大坑：
精確嘅專有名詞、產品型號、數字，向量檢索會出現「語義漂移」。
你問「GPT-4o 嘅 context window 係幾多」，向量檢索可能畀你一堆「大模型上下文長度」嘅泛泛描述，就係揾唔到嗰個精確數字。
因為 embedding 模型將「GPT-4o」同「大模型」壓到相近嘅向量空間，精確匹配反而冇咗。
解法係混合檢索：BM25（關鍵詞匹配）+ 向量檢索，兩路並行，結果融合。
BM25 負責精確，向量負責語義，互補。
實測召回率可以提升大約 30%。
但係幾乎冇人喺真實產品入面做咗呢步——因為多數教程淨係教向量檢索，BM25 嘅部分被省略咗。
第四個坑：表格，係非結構化數據入面最難搞嘅嘢
呢個好多人冇意識到。
文字嘅非結構化，仲算易處理——分段、切塊、存向量，基本流程行得通。
表格係真正嘅惡夢。
一張有行列關係嘅表，經過大部份 PDF 解析器處理之後，變成咁樣：
產品A 價格100 庫存500 產品B 價格200 庫存300
行列關係完全消失。LLM 拎到呢串文字，根本唔知「100」對應嘅係「產品A」定係「價格」。
我見過有人用呢種方式做財務知識庫，AI 畀出嘅數字對唔上，最後手動核對花咗比直接查表更多嘅時間。
正確做法：表格要單獨處理，轉成 Markdown 表格或者 JSON 格式，唔可以混入普通文字 chunk 入面。
最後講一件真係令我改變思路嘅事
做咗一段時間之後，我覆盤咗一下時間分配：
調模型參數用咗 20% 嘅時間，寫 Prompt 用咗 30% 嘅時間，數據清洗同 chunking 策略用咗 10% 嘅時間。
結果呢？數據嗰 10% 帶嚟嘅提升，係前面 50% 嘅三倍。
所以而家我嘅優先級係：
數據清洗質量 > Chunking 策略 > 檢索策略 > Prompt > 模型
唔係話模型唔重要，而係話喺大部份真實場景入面，底層數據嘅質量決定咗天花板，而唔係模型。
個個都喺度卷最頂層，底層冇人認真做。
呢啲係我花咗唔少時間同失敗先學到嘅嘢。
我係專注 AI Agent 深度實踐嘅努力撞蘑菇AI，致力分享真實可用嘅 AI 使用經驗同工作流探索，歡迎你同我一齊將 AI 玩到明，如果內容對你有幫助，歡迎關注、點讚、轉發。
大多數人搭 RAG 系統的起點是這樣的：
找個教程，接上 LLM，把文件扔進去，跑通 demo，感覺很絲滑。
然後用在真實業務上——準確率 40%。
我也是這麼過來的。
折騰了一段時間之後，我發現了一件反直覺的事：
RAG 系統的上限，不是模型決定的，是數據準備決定的。
所有人都在卷模型、卷 Prompt，但真正把項目做爛的，是最上游那一步——你餵給 AI 的"知識"本身，就是一坨亂的。
第一個坑：PDF 解析，你以為解決了，其實沒有
我最開始用的是最常見的方案：直接用 PyPDF 把 PDF 讀成文本，然後切塊，存向量庫。
跑通了，demo 很好看。
直到有人拿一份雙欄排版的報告來測——AI 給出的回答裏，數據對不上，上下文混亂，像是在胡說。
我去看原始解析結果，才發現問題：
雙欄 PDF 被讀成了"左欄第一行 + 右欄第一行 + 左欄第二行 + 右欄第二行……"
兩欄內容完全交叉混排。對人眼來說一眼看出是廢的，但 AI 拿到的就是這串文字，它不知道。
後來換了 Docling（IBM 出的開源工具），專門處理複雜佈局，雙欄問題解決了。
但教訓是：PDF 解析不是"能跑通"就算完，要真的去看解析後的原始文本是什麼樣的。
大多數人跳過了這一步。
第二個坑：按字數切塊，是在給 AI 喂碎片
Chunking——把文檔切成小塊存進向量庫——這一步大家都知道要做。
但怎麼切，很多人沒認真想過。
最常見的做法是按字數切：每 500 個字一塊，相鄰塊重疊 50 個字。
簡單，夠用，但有一個致命問題：它完全不管你的內容在哪裏斷。
我遇到過這樣的情況：一個完整的結論——"A 方案在高併發場景下優於 B 方案，原因是……"——被切成了兩塊。
前一塊有結論，沒原因。後一塊有原因，沒結論。
兩塊單獨召回，都沒意義。合起來沒人會把它們拼回去。
正確的做法是按文檔結構切——按標題、段落切，而不是按字數切。
文檔作者寫標題的時候，本來就是在做語義分割。你按結構切，是在利用人類已經標註好的語義邊界。
另外，每個 chunk 開頭加一串麪包屑：[文檔名 > 一級標題 > 二級標題]——召回的時候上下文不會丟。
第三個坑：純向量檢索，專有名詞是它的死穴
向量檢索的原理是語義相似——你問"如何提升性能"，它能找到說"優化速度"的段落，因為語義相近。
聽起來很強，實際上有一個大坑：
精確的專有名詞、產品型號、數字，向量檢索會"語義漂移"。
你問"GPT-4o 的 context window 是多少"，向量檢索可能給你一堆"大模型上下文長度"的泛泛描述，就是找不到那個精確數字。
因為 embedding 模型把"GPT-4o"和"大模型"壓到了相近的向量空間，精確匹配反而丟了。
解法是混合檢索：BM25（關鍵詞匹配）+ 向量檢索，兩路並行，結果融合。
BM25 負責精確，向量負責語義，互補。
實測召回率能提升 30% 左右。
但幾乎沒有人在真實產品裏做了這一步——因為多數教程只教向量檢索，BM25 的部分被省掉了。
第四個坑：表格，是非結構化數據裏最難的東西
這個很多人沒意識到。
文本的非結構化，還算好處理——分段、切塊、存向量，基本流程能跑。
表格是真正的噩夢。
一張有行列關係的表，經過大多數 PDF 解析器處理之後，變成這樣：
產品A 價格100 庫存500 產品B 價格200 庫存300
行列關係完全消失。LLM 拿到這串文字，根本不知道"100"對應的是"產品A"還是"價格"。
我見過有人用這種方式做財務知識庫，AI 給出的數字對不上，最後手動核對花了比直接查表更多的時間。
正確做法：表格要單獨處理，轉成 Markdown 表格或 JSON 格式，不能混進普通文本 chunk 裏。
最後說一件讓我真正改變思路的事
做了一段時間之後，我覆盤了一下時間分配：
調模型參數花了 20% 的時間，寫 Prompt 花了 30% 的時間，數據清洗和 chunking 策略花了 10% 的時間。
結果呢？數據那 10% 帶來的提升，是前面 50% 的三倍。
所以現在我的優先級是：
數據清洗質量 > Chunking 策略 > 檢索策略 > Prompt > 模型
不是說模型不重要，是說在大多數真實場景裏，底層數據的質量決定了天花板，而不是模型。
大家都在卷最頂層，底層沒人認真做。
這是我花了不少時間和失敗才學到的東西。
我是專注 AI Agent深度實踐的努力撞蘑菇AI，致力於分享真實可用的 AI 使用經驗與工作流探索，歡迎你和我一起把 AI 玩明白，如果內容對你有幫助，歡迎關注、點贊、轉發。