AI知識(shí)庫(kù)：解析、分塊與RAG實(shí)戰(zhàn))
這幾年做企業(yè)知識(shí)庫(kù)項(xiàng)目我接觸最多的不是各種炫酷的 AI 框架而是散落在共享盤、郵箱附件和桌面文件夾里的 Office 文檔。Word 里的方案、Excel 里的報(bào)價(jià)、PPT 里的匯報(bào)這些文件占了企業(yè)知識(shí)的絕大部分。很多團(tuán)隊(duì)上來(lái)就想著買大模型、搭平臺(tái)結(jié)果卡在第一步——怎么把幾千份 docx、xlsx、pptx 變成 AI 能讀、能查、能從里面找出答案的數(shù)據(jù)。先說(shuō)結(jié)論用 Office 文檔直接構(gòu)建企業(yè) AI 知識(shí)庫(kù)完全可行核心不是模型而是文檔解析和數(shù)據(jù)清洗。RAG 這條技術(shù)路線之所以被廣泛采用正是因?yàn)樗芾@過(guò)微調(diào)的成本先把文檔切塊、向量化再在問(wèn)答時(shí)檢索相關(guān)內(nèi)容丟給大模型。Dify、RAGFlow、FastGPT 這些開源平臺(tái)以及 Qdrant、Milvus 這類向量庫(kù)都能把整條鏈路串起來(lái)。這篇文章我會(huì)把從 Office 原始文件到可問(wèn)答知識(shí)庫(kù)的完整過(guò)程拆開講包括格式轉(zhuǎn)換、分塊策略、向量化方案、權(quán)限設(shè)計(jì)以及我實(shí)際踩過(guò)的坑。適合正在做企業(yè)知識(shí)庫(kù)的研發(fā)、運(yùn)維和產(chǎn)品同學(xué)也適合想用工具搭建內(nèi)部問(wèn)答系統(tǒng)的業(yè)務(wù)團(tuán)隊(duì)。1. 為什么不能直接把 Office 文檔扔給大模型1.1 問(wèn)題先從兩種“格式世界觀”談起Office 文檔在本質(zhì)上分為兩類。一類是 docx、xlsx、pptx它們從 Office 2007 開始采用 OOXML 標(biāo)準(zhǔn)本質(zhì)是一個(gè) Zip 壓縮包里面有若干 XML 文件描述文檔結(jié)構(gòu)、樣式、批注、修訂記錄。另一類是 doc、xls、ppt 老格式屬于 OLE 復(fù)合文檔亂一點(diǎn)但也不是不能解析。問(wèn)題在于文件對(duì)你來(lái)說(shuō)是文檔對(duì)模型來(lái)說(shuō)是“二進(jìn)制流”。把 50 頁(yè)的方案書直接拼進(jìn) Prompt送入模型的上下文窗口這既不現(xiàn)實(shí)也很浪費(fèi)。模型上下文長(zhǎng)度是有限的幾百萬(wàn) token 的上下文窗口產(chǎn)品也存在但企業(yè)文檔動(dòng)輒幾百上千頁(yè)全量塞進(jìn)去的成本極高。更重要的是模型回答問(wèn)題的前提是“找得到證據(jù)”不是“背誦全文”。這也正是 RAG 的意義。RAG 是 Retrieval-Augmented Generation檢索增強(qiáng)生成的縮寫先把你所有的 Office 文檔切成小塊轉(zhuǎn)成向量存儲(chǔ)到向量數(shù)據(jù)庫(kù)用戶提問(wèn)時(shí)系統(tǒng)在向量庫(kù)里檢索最相關(guān)的幾個(gè)片段再讓大模型基于這些片段生成答案。這樣既突破上下文長(zhǎng)度限制也能在回答里附上出處讓答案有據(jù)可查。1.2 直接把文檔喂給模型的三個(gè)硬傷如果跳過(guò)解析清洗直接拿原始文檔做向量化通常會(huì)出現(xiàn)三種情況。第一文本提取不全。Word 里文字在文本框、頁(yè)眉頁(yè)腳、批注里PPT 里的內(nèi)容散落在各種形狀、備注、圖表數(shù)據(jù)源中Excel 里的數(shù)據(jù)藏在多個(gè) Sheet、合并單元格、透視表結(jié)果里。常規(guī)的簡(jiǎn)單提取方案會(huì)漏掉大量?jī)?nèi)容導(dǎo)致檢索時(shí)找不到答案。第二多級(jí)信息折疊。Word 的標(biāo)題層級(jí)標(biāo)題 1、標(biāo)題 2、正文、Excel 的單元格坐標(biāo)邏輯、PPT 的頁(yè)面順序這些結(jié)構(gòu)信息在簡(jiǎn)單提取后全部丟失。檢索時(shí)能拼出來(lái)的都是“詞語(yǔ)碎片”沒(méi)法形成上下文。第三掃描件的問(wèn)題。如果這些 Office 文檔是從紙質(zhì)文件掃描成 PDF 后轉(zhuǎn)成 Word 的那么文檔里根本沒(méi)有文本層全是圖片。不經(jīng)過(guò) OCR光學(xué)字符識(shí)別就入庫(kù)AI 能看到的只是“一張圖”檢索自然失敗。所以構(gòu)建 AI 知識(shí)庫(kù)的第一課不是學(xué)大模型而是先處理文檔格式。用一句行業(yè)里的話說(shuō)垃圾進(jìn)垃圾出。文檔解析的質(zhì)量決定了知識(shí)庫(kù)回答的上限。2. 文檔解析是知識(shí)庫(kù)質(zhì)量的第一道閘門2.1 工具選型別在這上面盲目造輪子解析 Office 文檔的成熟方案很多我的建議是優(yōu)先用現(xiàn)成工具只有特殊需求才自己寫代碼。工具適用場(chǎng)景優(yōu)勢(shì)注意點(diǎn)LibreOffice全格式轉(zhuǎn)換批量 docx 轉(zhuǎn) docx / PDF / HTML免費(fèi)開源、命令行支持、自帶過(guò)濾規(guī)則轉(zhuǎn)換效果依賴原文檔排版習(xí)慣需配置字體環(huán)境pandocWord 轉(zhuǎn) Markdown、HTML輕量、保留標(biāo)題層級(jí)和列表結(jié)構(gòu)對(duì)復(fù)雜表格、批注支持有限會(huì)丟樣式Apache Tika服務(wù)化解析支持 docx、xlsx、pptx、PDF自動(dòng)識(shí)別格式REST API 易集成對(duì)中文支持不錯(cuò)但表格結(jié)構(gòu)提取比較粗糙python-docx / openpyxl / python-pptx編程方式細(xì)粒度控制可以按段落、單元格、形狀逐一路由處理需要自己處理邊界情況代碼量相對(duì)大MarkItDown微軟開源的文檔轉(zhuǎn) Markdown 工具對(duì) Office 系列友好適合做 RAG 預(yù)處理依賴外部的轉(zhuǎn)換器首次使用需完整安裝個(gè)人使用比較多的是 LibreOffice python-docx 的組合。批量處理時(shí)用 LibreOffice 把 doc 統(tǒng)一轉(zhuǎn)成 docx再用 python-docx 按段落級(jí)別結(jié)構(gòu)提取如果文檔排版很亂就先用 LibreOffice 轉(zhuǎn) PDF再用解析庫(kù)從 PDF 提取版面。這樣能通過(guò)轉(zhuǎn) PDF 獲得相對(duì)穩(wěn)定的布局再按頁(yè)面切塊適合保真要求高的場(chǎng)景。如果項(xiàng)目工期緊直接用 Dify 或 RAGFlow 內(nèi)置的文檔解析器也能跑通。但現(xiàn)在很多平臺(tái)對(duì) Office 的解析深度一般復(fù)雜表格和文本框照樣歪。用來(lái)做 demo 可以生產(chǎn)環(huán)境建議至少抽幾個(gè)復(fù)雜文檔做對(duì)比測(cè)試。2.2 從 Word 文檔里提取“有結(jié)構(gòu)”的文本W(wǎng)ord 提取的核心是結(jié)構(gòu)不是字符。下面是一段我用 python-docx 提取標(biāo)題層級(jí)和正文的簡(jiǎn)化代碼可以處理標(biāo)題 13、正文、表格單元格內(nèi)的文字。from docx import Document from docx.table import Table from docx.text.paragraph import Paragraph def iter_block_items(parent): 按文檔順序遍歷段落和表格 from docx.oxml.ns import qn parent_elm parent.element.body for child in parent_elm.iterchildren(): if child.tag qn(w:p): yield Paragraph(child, parent) elif child.tag qn(w:tbl): yield Table(child, parent) doc Document(方案書.docx) for block in iter_block_items(doc): if isinstance(block, Paragraph): style block.style.name if block.style else text block.text.strip() if not text: continue if style.startswith(Heading 1): print(f# {text}) elif style.startswith(Heading 2): print(f## {text}) elif style.startswith(Heading 3): print(f### {text}) else: print(text) else: # 表格塊逐行逐單元格提取并在前面加 markdown 表格分隔 print(| | .join(cell.text.strip() for cell in block.rows[0].cells) |) print(| |.join([---] * len(block.rows[0].cells)) |) for row in block.rows[1:]: print(| | .join(cell.text.strip() for cell in row.cells) |)注意這里兩個(gè)細(xì)節(jié)一是用iter_block_items按文檔實(shí)際順序遍歷而不是先遍歷所有段落再遍歷所有表格否則文檔里的圖表順序會(huì)錯(cuò)亂二是把 Word 表格直接轉(zhuǎn)成 Markdown 表格格式這樣后續(xù)分塊時(shí)能保持單元格之間的對(duì)應(yīng)關(guān)系。我見過(guò)不少項(xiàng)目用doc.paragraphs提取結(jié)果表格里的關(guān)鍵數(shù)據(jù)全部丟光問(wèn)答系統(tǒng)對(duì)著合同“告訴我有多少金額”直接答不出來(lái)。另外頁(yè)碼和標(biāo)題信息建議拼進(jìn)文本開頭作為文檔來(lái)源標(biāo)記例如在每段前面加“第 3 節(jié)項(xiàng)目預(yù)算”這樣的前綴。這樣檢索結(jié)果里能直接知道引文出處也方便做引用溯源。2.3 Excel 數(shù)據(jù)要按“語(yǔ)義塊”而不是按行切Excel 的處理思路和 Word 不一樣。Word 是流式閱讀的Excel 是表格式的每一行只是一個(gè)記錄單獨(dú)切一行檢索往往沒(méi)有意義。比如一張銷售明細(xì)表第一行是“客戶名稱、產(chǎn)品、金額、日期”單獨(dú)把“北京公司 100 萬(wàn)”做成向量丟失了“這是哪個(gè)項(xiàng)目的收入”這個(gè)上下文。更合理的做法是按 Sheet 和表格區(qū)域聚合。我的做法是先提取 Sheet 名稱和表頭再把表格轉(zhuǎn)成行列結(jié)構(gòu)按“Sheet 名 表頭 若干行”作為一個(gè)語(yǔ)義塊。如果表格特別長(zhǎng)比如上千行的臺(tái)賬可以按 100200 行切一塊同時(shí)把表頭和 Sheet 名拼到每塊前面。import openpyxl wb openpyxl.load_workbook(報(bào)價(jià)明細(xì).xlsx, data_onlyTrue) for ws in wb.worksheets: rows list(ws.iter_rows(values_onlyTrue)) if not rows: continue header | .join([str(c) if c else for c in rows[0]]) block_lines [fSheet: {ws.title}, f表頭: {header}] chunk_size 100 for i in range(1, len(rows), chunk_size): chunk rows[i:ichunk_size] lines block_lines [ | .join(str(c) if c else for c in row) for row in chunk] chunk_text \n.join(lines) # 這里把 chunk_text 交給 embedding 入庫(kù)即可data_onlyTrue很關(guān)鍵它會(huì)返回緩存的計(jì)算結(jié)果而不是公式字符串。如果你的 Excel 里有大量公式不加這個(gè)參數(shù)提取出來(lái)的一堆“SUM(A1:A10)”對(duì) AI 毫無(wú)意義。另外合并單元格會(huì)讓某些行出現(xiàn) None提取時(shí)可以把上一條非空值前向填充當(dāng)然你也可以用 openpyxl 的merged_cells屬性在提取時(shí)精確處理。2.4 PPT 內(nèi)容要同時(shí)抓幻燈片和備注PPT 是企業(yè)知識(shí)庫(kù)里最容易被忽略又最“痛”的格式。它的文本分布在標(biāo)題框、內(nèi)容框、圖表、SmartArt 內(nèi)部和備注區(qū)尤其備注區(qū)的演講者提示往往藏著真正的干貨比如項(xiàng)目背景、口徑說(shuō)明、關(guān)鍵結(jié)論這些才是問(wèn)答系統(tǒng)里價(jià)值很高的素材。python-pptx 提取時(shí)要注意遍歷所有slide.shapes對(duì)shape.has_text_frame的取文本對(duì)shape.shape_type MSO_SHAPE_TYPE.TABLE的取表格對(duì)shape.has_chart的取圖表系列名稱和值。每張幻燈片建議單獨(dú)作為一個(gè)塊并加上頁(yè)碼和標(biāo)題作為前綴。from pptx import Presentation from pptx.enum.shapes import MSO_SHAPE_TYPE def extract_slide_text(shape): texts [] if shape.shape_type MSO_SHAPE_TYPE.TABLE: for row in shape.table.rows: texts.append( | .join(cell.text.strip() for cell in row.cells)) elif shape.has_text_frame: texts.append(shape.text_frame.text.strip()) return \n.join(t for t in texts if t) prs Presentation(季度匯報(bào).pptx) for idx, slide in enumerate(prs.slides, 1): slide_texts [] for shape in slide.shapes: t extract_slide_text(shape) if t: slide_texts.append(t) full_text f[Slide {idx}]\n \n.join(slide_texts) if slide.has_notes_slide: notes slide.notes_slide.notes_text_frame.text.strip() full_text f\n[備注]\n{notes} # full_text 進(jìn)入分塊流程這條代碼在實(shí)際項(xiàng)目中幫了不少忙。很多匯報(bào) PPT 的標(biāo)題是“公司戰(zhàn)略”備注里卻寫“此處強(qiáng)調(diào)要聚焦三大業(yè)務(wù)線”如果沒(méi)有備注知識(shí)庫(kù)永遠(yuǎn)回答不了“公司戰(zhàn)略的重點(diǎn)是什么”。當(dāng)然后續(xù)要給不同來(lái)源的內(nèi)容打標(biāo)簽比如在 metadata 里記錄source_typeslide或source_typenotes便于權(quán)限控制和過(guò)濾。2.5 掃描 PDF 轉(zhuǎn)來(lái)的“假 Word”要先過(guò) OCR再?gòu)?qiáng)調(diào)一次如果文檔是掃描件轉(zhuǎn)的不管它是 PDF 還是 Word里面基本沒(méi)有文本層。這時(shí)候必須接 OCR。OCR 工具的選擇我體驗(yàn)下來(lái)比較推薦 PaddleOCR中文識(shí)別效果在開源方案里比較能打如果團(tuán)隊(duì)里有人力做調(diào)優(yōu)也可以試試 Tesseract但中文模型的效果需要自己標(biāo)注。在知識(shí)庫(kù)場(chǎng)景里OCR 建議做得“穩(wěn)”不追求把每個(gè)字符都認(rèn)準(zhǔn)而是把版面結(jié)構(gòu)認(rèn)出來(lái)標(biāo)題、段落、表格區(qū)域。這樣后續(xù)分塊才能保留閱讀順序。實(shí)操時(shí)我習(xí)慣先把掃描 PDF 按頁(yè)面轉(zhuǎn)成圖片再用 PaddleOCR 的ocr接口識(shí)別并把每行結(jié)果按 y 坐標(biāo)排序從上到下拼成文本塊。這里有個(gè)細(xì)節(jié)表格行容易被識(shí)別成“一條橫線”要單獨(dú)把表格區(qū)域的識(shí)別結(jié)果按單元格坐標(biāo)重組否則表格數(shù)據(jù)會(huì)徹底亂掉。如果你的掃描件數(shù)量不大直接人工校對(duì)幾個(gè)關(guān)鍵表格比在代碼里調(diào)半天正則靠譜得多。3. 分塊、向量化與入庫(kù)搭起知識(shí)庫(kù)的骨架3.1 分塊策略別照抄網(wǎng)上參數(shù)先看文檔類型解析完成之后下一步是分塊。網(wǎng)上到處是“chunk_size512, overlap50”的建議直接照抄往往效果一般。分塊的本質(zhì)是找到一個(gè)平衡點(diǎn)塊太小檢索時(shí)上下文不夠模型看不懂說(shuō)的是什么塊太大一個(gè)塊里混著好幾個(gè)主題檢索召回相關(guān)性下降大模型的注意力也被稀釋。我自己的實(shí)踐經(jīng)驗(yàn)是分三類處理一是段落式內(nèi)容如 Word 方案、合同條款、制度文件按標(biāo)題層級(jí)天然劃分先按標(biāo)題 1標(biāo)題 2 切塊如果某個(gè)二級(jí)標(biāo)題下的內(nèi)容過(guò)長(zhǎng)再按 8001000 字拆分子塊并讓重疊部分包含前一個(gè)子塊的結(jié)尾通常 overlap 設(shè)在 10%15%。二是表格型內(nèi)容如 Excel 報(bào)價(jià)單、臺(tái)賬表頭和 Sheet 名必須跟數(shù)據(jù)塊綁定再按行數(shù)切塊塊與塊之間不需要 overlap否則重復(fù)記錄會(huì)干擾精確檢索。三是 PPT 型內(nèi)容按幻燈片整頁(yè)作為塊備注頁(yè)和正文合并。如果某頁(yè)文字特別多可以按內(nèi)容框拆成兩到三個(gè)子塊但仍保留頁(yè)碼信息。一段合格的塊看起來(lái)長(zhǎng)這樣 來(lái)源方案書_v3.docx 章節(jié)項(xiàng)目總體架構(gòu)標(biāo)題1 內(nèi)容本方案建議采用微服務(wù)架構(gòu)將系統(tǒng)拆分為用戶服務(wù)、訂單服務(wù)、支付服務(wù)等核心模塊。各服務(wù)通過(guò)消息隊(duì)列異步通信......后續(xù)正文這段文本里既有來(lái)源信息又有結(jié)構(gòu)標(biāo)題還有正文檢索時(shí)能直接理解為“這句話來(lái)自方案的哪個(gè)章節(jié)”問(wèn)答中就能帶著出處返回。還要提醒一個(gè)隱藏問(wèn)題中文和英文字符的 chunk 計(jì)算方式不一樣。很多國(guó)外框架的 tokenizer 是按英文單詞估算的Chinese 一句話可能十幾個(gè)字就算成十幾個(gè) token。建議用真實(shí)驗(yàn)證不要把理論 chunk_size 當(dāng)成硬性指標(biāo)而是看塊內(nèi)的實(shí)際 token 數(shù)超過(guò)模型 token 上限就要縮小。3.2 向量化模型選型中文場(chǎng)景下優(yōu)先級(jí)要調(diào)整分完塊之后就要對(duì)每個(gè)塊做向量化。這一步把文本變成一串浮點(diǎn)數(shù)向量檢索時(shí)通過(guò)余弦相似度計(jì)算哪個(gè)塊跟用戶問(wèn)題最接近。Embedding 模型的選型我認(rèn)為要考慮三個(gè)維度中文語(yǔ)義理解能力、向量維度、部署成本?，F(xiàn)在常見的選擇包括模型中文效果維度說(shuō)明BGE-M3優(yōu)秀1024 / 512 可配支持中英混合適合知識(shí)庫(kù)本地部署可控text-embedding-3-small良好1536云端服務(wù)接入簡(jiǎn)單成本較低text-embedding-3-large更好3072強(qiáng)語(yǔ)義理解但存儲(chǔ)開銷和費(fèi)用更高M(jìn)3E / bge-large-zh良好1024中文優(yōu)化離線可用老牌選擇Ollama embedding 模型一般不定本地部署友好但中文詞典覆蓋有限需測(cè)試實(shí)戰(zhàn)中文檔量大、中文為主、又對(duì)數(shù)據(jù)隱私有要求的企業(yè)優(yōu)先考慮 BGE-M3 或 bge-large-zh本地部署接入 Dify 或 LangChain 都很順。如果對(duì)云端不敏感先用 text-embedding-3-small 跑通再根據(jù)實(shí)際效果升級(jí)。向量維度的選擇不只是模型本身的參數(shù)還影響向量庫(kù)的存儲(chǔ)和檢索性能維度太高單條查詢變慢索引內(nèi)存也膨脹。向量庫(kù)選型方面小規(guī)模知識(shí)庫(kù)少于 100 萬(wàn)塊用 Qdrant 或 pgvector 就夠支持 Docker 部署配置簡(jiǎn)單。百萬(wàn)級(jí)別以上再考慮 Milvus。如果團(tuán)隊(duì)已經(jīng)有 Elasticsearch 基礎(chǔ)設(shè)施也可以直接用它存向量利用已有的權(quán)限和運(yùn)維生態(tài)。3.3 用 Dify 搭建知識(shí)庫(kù)流水線不要覺(jué)得只有寫代碼才能搭知識(shí)庫(kù)。現(xiàn)在到了 2025 年Dify、RAGFlow、FastGPT 這類開源平臺(tái)把鏈路做得很完整。下面是我比較推薦的一個(gè) Dify 搭建路徑。第一步創(chuàng)建一個(gè)知識(shí)庫(kù)應(yīng)用。第二步接入文檔源把第二步解析好的文本或其他格式文件傳進(jìn)去。第三步在設(shè)置里選好 Embedding 模型。第四步設(shè)置分塊規(guī)則Dify 支持自定義 Segmentation 模式直接填 chunk_size 和 overlap。第五步綁定到 Chatflow讓用戶提問(wèn)時(shí)先檢索知識(shí)庫(kù)再調(diào)對(duì)話模型。需要注意一點(diǎn)在 Dify 里不要偷懶把 Office 文件直接上傳它的內(nèi)置解析器雖然方便但對(duì)復(fù)雜版式和表格處理能力一般。更穩(wěn)的做法是保證自己在外部完成了解析清洗再導(dǎo)入寧可靠前一步優(yōu)化也別讓知識(shí)庫(kù)出現(xiàn)壞數(shù)據(jù)。如果你追求數(shù)據(jù)庫(kù)級(jí)可控“連接外部知識(shí)庫(kù)”也是 Dify 支持的方向。可以把 Qdrant 或 pgvector 作為外部向量庫(kù)Dify 做編排檢索時(shí)先查外部庫(kù)再拼裝上下文。這樣便于已有業(yè)務(wù)的團(tuán)隊(duì)復(fù)用現(xiàn)有數(shù)據(jù)也可以避免頻繁遷庫(kù)。3.4 Metadata 設(shè)計(jì)決定你能不能做權(quán)限和溯源分塊之后每一塊一定要帶上 metadata 字段元數(shù)據(jù)是知識(shí)庫(kù)的靈魂。沒(méi)有 metadata你的知識(shí)庫(kù)就是一堆無(wú)差別文本后續(xù)想做權(quán)限隔離、引用溯源、更新時(shí)間過(guò)濾全都做不了。推薦至少包含這些字段doc_id文檔唯一編碼建議用哈希值便于底層查重doc_name便于展示的來(lái)源名source_typeword/excel/ppt/pdfsection_path章節(jié)路徑例如“項(xiàng)目總體架構(gòu) / 技術(shù)方案”page_no如果有頁(yè)碼則保留chunk_index塊序號(hào)便于按順序重排updated_at文檔更新時(shí)間permission_tags部門標(biāo)簽或密級(jí)標(biāo)簽用于權(quán)限過(guò)濾權(quán)限這塊很多企業(yè)會(huì)犯一個(gè)錯(cuò)誤向量庫(kù)只做檢索權(quán)限放在應(yīng)用層。但權(quán)限必須同時(shí)落在文檔級(jí)別和 chunk 級(jí)別。簡(jiǎn)單做法是給每個(gè)塊打上dept標(biāo)簽檢索時(shí)把用戶所屬部門作為過(guò)濾條件傳給向量庫(kù)做filter參數(shù)而不僅僅是返回結(jié)果后再過(guò)濾否則底層數(shù)據(jù)泄露誰(shuí)都攔不住。3.5 增量更新與知識(shí)庫(kù)的“新陳代謝”企業(yè)文檔每天都在變昨天上傳的方案第二天就更新了達(dá)成了一個(gè)錯(cuò)誤版本。如果不處理知識(shí)庫(kù)永遠(yuǎn)“活在昨天”。增量更新的常見方案是在文檔入庫(kù)時(shí)記錄文檔的doc_id和content_hash每次掃描文件時(shí)先比哈希哈希變了就刪除舊 chunks重新解析入庫(kù)完全新增的文檔直接入庫(kù)。這個(gè)邏輯可以用 Airflow、Prefect 或者定時(shí)腳本實(shí)現(xiàn)。還有一個(gè)容易忽略的操作清理已刪除文檔。共享盤里文件可能移動(dòng)了路徑、改了名字如果只按“新增”邏輯跑舊版本殘留會(huì)讓檢索結(jié)果重復(fù)甚至沖突。我建議每次同步前先遍歷一遍源頭目錄生成當(dāng)前文件清單跟庫(kù)里的 doc_id 對(duì)比把缺席文檔的所有 chunks 一次性刪除。這步雖然簡(jiǎn)單卻能讓知識(shí)庫(kù)保持干凈的狀態(tài)避免用戶搜到半年前的過(guò)時(shí)信息。4. 實(shí)操過(guò)程從 Office 文件到可問(wèn)答知識(shí)庫(kù)的完整鏈路4.1 環(huán)境準(zhǔn)備與依賴安裝基于常見實(shí)踐的補(bǔ)充這里給出一個(gè)可復(fù)現(xiàn)的最小方案使用 Python Dify Qdrant 或本地向量模型。假設(shè)你有基礎(chǔ) Python 環(huán)境建議用 conda 或 venv 建一個(gè)獨(dú)立環(huán)境。mkdir office-kb cd office-kb python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate需要安裝的庫(kù)見下面的 requirements.txt都是常用庫(kù)版本號(hào)建議根據(jù)網(wǎng)絡(luò)實(shí)際可用情況安裝最新穩(wěn)定版。libreoffice-convert # 如果需要批量轉(zhuǎn)格式可自行安裝對(duì)應(yīng)轉(zhuǎn)換器 python-docx openpyxl python-pptx pandas pypdf2 paddleocr # OCR 需要?jiǎng)t裝對(duì)依賴較高請(qǐng)注意libreoffice-convert依賴系統(tǒng)安裝 LibreOffice。裝完以后可以用一個(gè)簡(jiǎn)單的命令行測(cè)試libreoffice --headless --convert-to pdf 方案書.docx --outdir ./pdf_output4.2 從文件目錄批量解析入庫(kù)的核心代碼下面這段代碼可以算是一個(gè)迷你版的文檔入庫(kù)腳本骨架基于我平時(shí)的處理習(xí)慣整理。它做三件事遍歷目錄、按擴(kuò)展名分流解析、組裝 metadata 交給后面分塊。import hashlib from pathlib import Path from docx import Document from pptx import Presentation import openpyxl def get_file_hash(path: Path) - str: h hashlib.sha256() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) return h.hexdigest() def extract_docx(path: Path): doc Document(path) blocks [] # 這里復(fù)用前面 iter_block_items 的邏輯輸出按結(jié)構(gòu)拼接的文本 return \n.join(blocks) def extract_pptx(path: Path): prs Presentation(path) slides [] # 復(fù)用前面的逐頁(yè)提取邏輯記錄 slide 序號(hào)和備注 return \n.join(slides) def extract_xlsx(path: Path): wb openpyxl.load_workbook(path, data_onlyTrue) sheets [] # 這里復(fù)用前文 Sheet 表頭 數(shù)據(jù)塊 的邏輯 return \n.join(sheets) def process_folder(folder: Path): for ext, func in {.docx: extract_docx, .pptx: extract_pptx, .xlsx: extract_xlsx}.items(): for file in folder.rglob(f*{ext}): # 1. 計(jì)算哈希 content_hash get_file_hash(file) # 2. 解析文本 text func(file) # 3. 分塊和向量化這里暫用占位邏輯 yield { doc_id: content_hash, doc_name: file.name, source_type: ext.replace(., ), text: text, updated_at: file.stat().st_mtime, } for item in process_folder(Path(企業(yè)文檔)): # 接入向量庫(kù)或 Dify API 的寫入函數(shù) pass這段代碼的真正價(jià)值是幫你把“文件系統(tǒng)”和“知識(shí)庫(kù)”建立映射。后續(xù)不管用了多少次、改了多少文件都能通過(guò) doc_id 精準(zhǔn)刪除重建而不是簡(jiǎn)單清空重來(lái)。如果你的團(tuán)隊(duì)更喜歡低代碼方式Dify 的文檔導(dǎo)入功能可以省掉這段 Python。把解析腳本作為前置清洗模塊也是后面做生產(chǎn)級(jí)知識(shí)庫(kù)的必經(jīng)之路我建議兩者結(jié)合低代碼平臺(tái)跑流程Python 腳本做特殊文檔的精處理。4.3 RAG 問(wèn)答驗(yàn)證不只看“答得出來(lái)”還要看“引用對(duì)沒(méi)有”知識(shí)庫(kù)搭好后別急著宣告成功。先用指定測(cè)試集驗(yàn)證效果。我的習(xí)慣是從三個(gè)角度出題事實(shí)查詢類“2024 年第二季度華東區(qū)的銷售額是多少”對(duì)應(yīng)表格型知識(shí)要求答案有準(zhǔn)確的數(shù)字和出處?？偨Y(jié)歸納類“公司今年的三大戰(zhàn)略重點(diǎn)分別是什么”對(duì)應(yīng) PPT 和 Word 標(biāo)題體系需要模型跨多個(gè)塊綜合。流程制度類“報(bào)銷流程需要哪些審批節(jié)點(diǎn)”對(duì)應(yīng)制度文檔需要引用原文條款。把這三類問(wèn)題分別跑一遍按照回答準(zhǔn)確率、引用正確率、拒絕回答率三個(gè)指標(biāo)打分。正常來(lái)說(shuō)準(zhǔn)確率低于 60% 說(shuō)明文檔解析或分塊有明顯問(wèn)題先不要急著換模型而是回去看是不是表格丟了、標(biāo)題層級(jí)壞了、OCR 亂碼了。調(diào)試時(shí)我推薦一個(gè)“檢索前置”的小技巧在 Dify 或 LangChain 的調(diào)試界面里先不看大模型的最終回答先看檢索返回了哪些 chunk。如果返回的 chunk 本身不是相關(guān)內(nèi)容那后面大模型回答不可能靠譜如果 chunk 相關(guān)但回答不對(duì)那是 Prompt 或語(yǔ)義理解的問(wèn)題。這條經(jīng)驗(yàn)基本能定位 80% 的知識(shí)庫(kù)問(wèn)題。4.4 從“能答”到“答得好”的 Prompt 調(diào)優(yōu)不要迷信模型能力Prompt 往往決定知識(shí)庫(kù)的最終體驗(yàn)。下面是一個(gè)比較實(shí)用的 RAG 問(wèn)答提示詞模板適合在 Chatflow 里使用你是企業(yè)內(nèi)部知識(shí)庫(kù)助手。請(qǐng)僅根據(jù)下面提供的【參考資料】回答問(wèn)題。 如果參考資料中沒(méi)有明確信息請(qǐng)直接回復(fù)“知識(shí)庫(kù)中未找到相關(guān)信息”不要猜測(cè)。 【參考資料】 {context} 【用戶問(wèn)題】 {question} 要求 1. 答案中涉及的制度條款、數(shù)字、流程步驟必須在回答末尾標(biāo)注來(lái)源文件名和段落標(biāo)題。 2. 如果問(wèn)題與參考資料無(wú)關(guān)回復(fù)“這個(gè)問(wèn)題不在我的知識(shí)范圍內(nèi)”。這個(gè)模板看起來(lái)很簡(jiǎn)單但它強(qiáng)制模型“沒(méi)有資料就承認(rèn)不知道”可以避免一本正經(jīng)地胡說(shuō)八道。實(shí)際使用中你還可以根據(jù)企業(yè)特點(diǎn)追加“如果涉及金額必須保留兩位小數(shù)”“回答時(shí)先給出結(jié)論再給出依據(jù)”等約束。Prompt 是在知識(shí)庫(kù)數(shù)據(jù)質(zhì)量過(guò)關(guān)之后性價(jià)比最高的調(diào)優(yōu)手段。5. 常見問(wèn)題與排查技巧實(shí)錄5.1 明明有答案檢索卻一直召回不到出現(xiàn)這個(gè)現(xiàn)象十有八九是分塊粒度或結(jié)構(gòu)信息丟了。我遇到過(guò)最典型的例子客戶上線一個(gè)合同知識(shí)庫(kù)測(cè)試問(wèn)“違約金條款是什么”模型總是答不上來(lái)。排查后發(fā)現(xiàn)原合同的章節(jié)被排版成分頁(yè)符隔開解析時(shí)把“違約責(zé)任”和正文拆成了兩個(gè)塊檢索時(shí)“違約金”這三個(gè)字只在標(biāo)題塊里出現(xiàn)正文塊沒(méi)有關(guān)鍵詞兩個(gè)塊都只能算低相關(guān)最終被 Top-K 截?cái)唷＝鉀Q辦法一是讓分塊把標(biāo)題和正文放在同一個(gè)塊里可以通過(guò) Python 解析時(shí)對(duì)上游塊做“標(biāo)題繼承”遇到標(biāo)題 1 時(shí)把它存為當(dāng)前 section直到遇到下一個(gè)標(biāo)題才替換。在分塊時(shí)把這個(gè) section 拼到每個(gè) chunk 的前綴里。這樣每個(gè)子塊都能帶著章節(jié)上下文檢索召回會(huì)穩(wěn)很多。另一個(gè)原因是 Embedding 模型對(duì)長(zhǎng)文本概括能力一般。檢索詞集中在某個(gè)段落但那個(gè)段落被截?cái)嗟搅硪粋€(gè)塊里。這時(shí)可以適度提高 chunk_size或者調(diào)整 overlap。我的經(jīng)驗(yàn)是overlap 最少要有百字級(jí)別的語(yǔ)義銜接不能只重復(fù)最后兩句話。5.2 Excel 表格“看得見字但一回答問(wèn)題就是錯(cuò)的”Excel 入庫(kù)經(jīng)常出現(xiàn)三種問(wèn)題一是列頭丟了分塊時(shí)只取數(shù)據(jù)行不取表頭二是合并單元格沒(méi)處理導(dǎo)致數(shù)據(jù)對(duì)應(yīng)錯(cuò)列三是多 Sheet 之間共享一個(gè)表頭但語(yǔ)義完全不同比如“一月數(shù)據(jù)”和“二月數(shù)據(jù)”結(jié)構(gòu)相同單獨(dú)檢索時(shí)模型不知道數(shù)字屬于哪個(gè)月。給這些表格數(shù)據(jù)加“字段前綴”是個(gè)好做法。我在 excel 塊生成文本時(shí)會(huì)把“Sheet 名 表頭 日期范圍”放在每塊的最前面例如數(shù)據(jù)來(lái)源2024年銷售臺(tái)賬.xlsx / Sheet華東大區(qū) 表頭客戶名稱 | 產(chǎn)品 | 金額(元) | 合同日期 | 負(fù)責(zé)人 數(shù)據(jù)杭州某某公司 | A系列 | 120000 | 2024-03-05 | 張三這樣模型看到每行數(shù)據(jù)時(shí)就知道它的字段語(yǔ)義。如果表頭和數(shù)據(jù)行被分塊切開這個(gè)前綴還能在多個(gè)塊里重復(fù)出現(xiàn)保證塊之間信息一致。5.3 PPT 記錄了很多內(nèi)容但檢索時(shí)“看不到重點(diǎn)”PPT 這類版式文檔最大的問(wèn)題是“一句話被拆在多個(gè)文本框里”比如標(biāo)題是一個(gè)文本框副標(biāo)題是另一個(gè)文本框旁邊還有個(gè)圖標(biāo)里的文字。如果只按文本框逐個(gè)提取原本一個(gè)完整觀點(diǎn)被拆成三四個(gè)塊檢索時(shí)每個(gè)塊都很短相關(guān)性得分不高。解決辦法是把同一頁(yè)內(nèi)所有文本框的內(nèi)容合并成一個(gè)塊通過(guò)形狀的坐標(biāo)left、top判斷閱讀順序再按位置排序拼接。還有一種更省事的辦法利用 PPT 的分頁(yè)符天然切塊把一頁(yè)的全部文本作為一個(gè)塊。這樣即使頁(yè)面里有多個(gè)形狀也可以保證信息完整。多年的經(jīng)驗(yàn)提醒做 PPT 知識(shí)庫(kù)時(shí)不要把“頁(yè)標(biāo)題”當(dāng)成塊的唯一索引。很多企業(yè) PPT 標(biāo)題習(xí)慣寫成“項(xiàng)目概覽”“核心亮點(diǎn)”這類雷同詞如果檢索只看標(biāo)題多個(gè)塊高度相似無(wú)法區(qū)分。必須在塊內(nèi)附帶一兩句頁(yè)面正文的關(guān)鍵詞讓檢索命中正文內(nèi)容。5.4 大量文件入庫(kù)時(shí)檢索結(jié)果出現(xiàn)重復(fù)或沖突如果你發(fā)現(xiàn)同一個(gè)知識(shí)點(diǎn)被返回了好幾份而且內(nèi)容互相矛盾基本可以斷定庫(kù)里存在舊版本殘留。前面提到的內(nèi)容哈希方案就是為解決這個(gè)問(wèn)題而設(shè)的。掃描時(shí)比對(duì)每個(gè)文檔的 SHA-256只要文件內(nèi)容變了就把舊 doc_id 對(duì)應(yīng)的所有 chunks 刪掉再用新的文本重新生成向量。這個(gè)方案也有條件解析前的“原始文本”和入庫(kù)后的“向量塊”必須能通過(guò) doc_id 做反查。所以建議在上游就維護(hù)一個(gè)簡(jiǎn)易的 document registry 表記錄 doc_id、文件路徑、content_hash、pages、chunk_count。任何同步任務(wù)跑完先檢查這個(gè)表有沒(méi)有異常再調(diào)問(wèn)答測(cè)試。5.5 權(quán)限泄露是知識(shí)庫(kù)的高危場(chǎng)景很多企業(yè)覺(jué)得 RAG 知識(shí)庫(kù)是個(gè)內(nèi)部應(yīng)用不設(shè)防。但實(shí)際中除非文檔都是全公司公開級(jí)否則一定要帶權(quán)限控制。這里再?gòu)?qiáng)調(diào)一遍權(quán)限一定要下推到 chunk 層不是只在業(yè)務(wù)層過(guò)濾。以 Dify 為例如果直接用外部知識(shí)庫(kù) API可以在檢索參數(shù)里加入filter比如dept in [tech, hr]。這樣每個(gè)用戶的查詢請(qǐng)求都帶過(guò)濾條件檢索階段就排除無(wú)權(quán)訪問(wèn)的塊。如果用戶想通過(guò)越權(quán)提問(wèn)套取其他部門的東西向量庫(kù)返回的結(jié)果天然不含高密級(jí)內(nèi)容安全面就小了很多。至于權(quán)限標(biāo)簽怎么來(lái)文件系統(tǒng)里通常有文件夾結(jié)構(gòu)或文件命名規(guī)則合理映射到部門標(biāo)簽即可。寫在最后的一點(diǎn)體會(huì)做了這么多企業(yè)知識(shí)庫(kù)項(xiàng)目我的一個(gè)強(qiáng)烈感受是技術(shù)本身已經(jīng)不是瓶頸瓶頸在于團(tuán)隊(duì)是否愿意在文檔治理上花功夫。Office 文檔構(gòu)建 AI 知識(shí)庫(kù)最容易出彩的環(huán)節(jié)不是大模型選了多強(qiáng)而是解析清洗做到位分塊設(shè)計(jì)貼合業(yè)務(wù)。我自己也多次被現(xiàn)實(shí)教育剛開始總覺(jué)得模型聰明一點(diǎn)就能解決一切后來(lái)發(fā)現(xiàn)讓結(jié)構(gòu)化的 Office 文檔以正確的姿勢(shì)進(jìn)入知識(shí)庫(kù)遠(yuǎn)比切換更貴的模型更有效。如果你正在設(shè)計(jì)新的知識(shí)庫(kù)系統(tǒng)我建議先找一個(gè)最小的業(yè)務(wù)場(chǎng)景試點(diǎn)挑一個(gè)目錄幾百份合同或幾十份項(xiàng)目總結(jié)從解析到問(wèn)答完整跑通再慢慢擴(kuò)大到全公司。別一上來(lái)就想把共享盤幾萬(wàn)份文件一股腦灌進(jìn)去那樣既難以保證質(zhì)量也難以及時(shí)發(fā)現(xiàn)數(shù)據(jù)問(wèn)題。先拿一套“能答對(duì)有出處的問(wèn)題”作為驗(yàn)收標(biāo)準(zhǔn)再逐步擴(kuò)展覆蓋范圍這是我認(rèn)為最穩(wěn)妥、也最容易出效果的實(shí)施路徑。 從Office文檔到企業(yè)AI知識(shí)庫(kù)：解析、分塊與RAG實(shí)戰(zhàn)
這幾年做企業(yè)知識(shí)庫(kù)項(xiàng)目我接觸最多的不是各種炫酷的 AI 框架而是散落在共享盤、郵箱附件和桌面文件夾里的 Office 文檔。Word 里的方案、Excel 里的報(bào)價(jià)、PPT 里的匯報(bào)這些文件占了企業(yè)知識(shí)的絕大部分。很多團(tuán)隊(duì)上來(lái)就想著買大模型、搭平臺(tái)結(jié)果卡在第一步——怎么把幾千份 docx、xlsx、pptx 變成 AI 能讀、能查、能從里面找出答案的數(shù)據(jù)。先說(shuō)結(jié)論用 Office 文檔直接構(gòu)建企業(yè) AI 知識(shí)庫(kù)完全可行核心不是模型而是文檔解析和數(shù)據(jù)清洗。RAG 這條技術(shù)路線之所以被廣泛采用正是因?yàn)樗芾@過(guò)微調(diào)的成本先把文檔切塊、向量化再在問(wèn)答時(shí)檢索相關(guān)內(nèi)容丟給大模型。Dify、RAGFlow、FastGPT 這些開源平臺(tái)以及 Qdrant、Milvus 這類向量庫(kù)都能把整條鏈路串起來(lái)。這篇文章我會(huì)把從 Office 原始文件到可問(wèn)答知識(shí)庫(kù)的完整過(guò)程拆開講包括格式轉(zhuǎn)換、分塊策略、向量化方案、權(quán)限設(shè)計(jì)以及我實(shí)際踩過(guò)的坑。適合正在做企業(yè)知識(shí)庫(kù)的研發(fā)、運(yùn)維和產(chǎn)品同學(xué)也適合想用工具搭建內(nèi)部問(wèn)答系統(tǒng)的業(yè)務(wù)團(tuán)隊(duì)。1. 為什么不能直接把 Office 文檔扔給大模型1.1 問(wèn)題先從兩種“格式世界觀”談起Office 文檔在本質(zhì)上分為兩類。一類是 docx、xlsx、pptx它們從 Office 2007 開始采用 OOXML 標(biāo)準(zhǔn)本質(zhì)是一個(gè) Zip 壓縮包里面有若干 XML 文件描述文檔結(jié)構(gòu)、樣式、批注、修訂記錄。另一類是 doc、xls、ppt 老格式屬于 OLE 復(fù)合文檔亂一點(diǎn)但也不是不能解析。問(wèn)題在于文件對(duì)你來(lái)說(shuō)是文檔對(duì)模型來(lái)說(shuō)是“二進(jìn)制流”。把 50 頁(yè)的方案書直接拼進(jìn) Prompt送入模型的上下文窗口這既不現(xiàn)實(shí)也很浪費(fèi)。模型上下文長(zhǎng)度是有限的幾百萬(wàn) token 的上下文窗口產(chǎn)品也存在但企業(yè)文檔動(dòng)輒幾百上千頁(yè)全量塞進(jìn)去的成本極高。更重要的是模型回答問(wèn)題的前提是“找得到證據(jù)”不是“背誦全文”。這也正是 RAG 的意義。RAG 是 Retrieval-Augmented Generation檢索增強(qiáng)生成的縮寫先把你所有的 Office 文檔切成小塊轉(zhuǎn)成向量存儲(chǔ)到向量數(shù)據(jù)庫(kù)用戶提問(wèn)時(shí)系統(tǒng)在向量庫(kù)里檢索最相關(guān)的幾個(gè)片段再讓大模型基于這些片段生成答案。這樣既突破上下文長(zhǎng)度限制也能在回答里附上出處讓答案有據(jù)可查。1.2 直接把文檔喂給模型的三個(gè)硬傷如果跳過(guò)解析清洗直接拿原始文檔做向量化通常會(huì)出現(xiàn)三種情況。第一文本提取不全。Word 里文字在文本框、頁(yè)眉頁(yè)腳、批注里PPT 里的內(nèi)容散落在各種形狀、備注、圖表數(shù)據(jù)源中Excel 里的數(shù)據(jù)藏在多個(gè) Sheet、合并單元格、透視表結(jié)果里。常規(guī)的簡(jiǎn)單提取方案會(huì)漏掉大量?jī)?nèi)容導(dǎo)致檢索時(shí)找不到答案。第二多級(jí)信息折疊。Word 的標(biāo)題層級(jí)標(biāo)題 1、標(biāo)題 2、正文、Excel 的單元格坐標(biāo)邏輯、PPT 的頁(yè)面順序這些結(jié)構(gòu)信息在簡(jiǎn)單提取后全部丟失。檢索時(shí)能拼出來(lái)的都是“詞語(yǔ)碎片”沒(méi)法形成上下文。第三掃描件的問(wèn)題。如果這些 Office 文檔是從紙質(zhì)文件掃描成 PDF 后轉(zhuǎn)成 Word 的那么文檔里根本沒(méi)有文本層全是圖片。不經(jīng)過(guò) OCR光學(xué)字符識(shí)別就入庫(kù)AI 能看到的只是“一張圖”檢索自然失敗。所以構(gòu)建 AI 知識(shí)庫(kù)的第一課不是學(xué)大模型而是先處理文檔格式。用一句行業(yè)里的話說(shuō)垃圾進(jìn)垃圾出。文檔解析的質(zhì)量決定了知識(shí)庫(kù)回答的上限。2. 文檔解析是知識(shí)庫(kù)質(zhì)量的第一道閘門2.1 工具選型別在這上面盲目造輪子解析 Office 文檔的成熟方案很多我的建議是優(yōu)先用現(xiàn)成工具只有特殊需求才自己寫代碼。工具適用場(chǎng)景優(yōu)勢(shì)注意點(diǎn)LibreOffice全格式轉(zhuǎn)換批量 docx 轉(zhuǎn) docx / PDF / HTML免費(fèi)開源、命令行支持、自帶過(guò)濾規(guī)則轉(zhuǎn)換效果依賴原文檔排版習(xí)慣需配置字體環(huán)境pandocWord 轉(zhuǎn) Markdown、HTML輕量、保留標(biāo)題層級(jí)和列表結(jié)構(gòu)對(duì)復(fù)雜表格、批注支持有限會(huì)丟樣式Apache Tika服務(wù)化解析支持 docx、xlsx、pptx、PDF自動(dòng)識(shí)別格式REST API 易集成對(duì)中文支持不錯(cuò)但表格結(jié)構(gòu)提取比較粗糙python-docx / openpyxl / python-pptx編程方式細(xì)粒度控制可以按段落、單元格、形狀逐一路由處理需要自己處理邊界情況代碼量相對(duì)大MarkItDown微軟開源的文檔轉(zhuǎn) Markdown 工具對(duì) Office 系列友好適合做 RAG 預(yù)處理依賴外部的轉(zhuǎn)換器首次使用需完整安裝個(gè)人使用比較多的是 LibreOffice python-docx 的組合。批量處理時(shí)用 LibreOffice 把 doc 統(tǒng)一轉(zhuǎn)成 docx再用 python-docx 按段落級(jí)別結(jié)構(gòu)提取如果文檔排版很亂就先用 LibreOffice 轉(zhuǎn) PDF再用解析庫(kù)從 PDF 提取版面。這樣能通過(guò)轉(zhuǎn) PDF 獲得相對(duì)穩(wěn)定的布局再按頁(yè)面切塊適合保真要求高的場(chǎng)景。如果項(xiàng)目工期緊直接用 Dify 或 RAGFlow 內(nèi)置的文檔解析器也能跑通。但現(xiàn)在很多平臺(tái)對(duì) Office 的解析深度一般復(fù)雜表格和文本框照樣歪。用來(lái)做 demo 可以生產(chǎn)環(huán)境建議至少抽幾個(gè)復(fù)雜文檔做對(duì)比測(cè)試。2.2 從 Word 文檔里提取“有結(jié)構(gòu)”的文本W(wǎng)ord 提取的核心是結(jié)構(gòu)不是字符。下面是一段我用 python-docx 提取標(biāo)題層級(jí)和正文的簡(jiǎn)化代碼可以處理標(biāo)題 13、正文、表格單元格內(nèi)的文字。from docx import Document from docx.table import Table from docx.text.paragraph import Paragraph def iter_block_items(parent): 按文檔順序遍歷段落和表格 from docx.oxml.ns import qn parent_elm parent.element.body for child in parent_elm.iterchildren(): if child.tag qn(w:p): yield Paragraph(child, parent) elif child.tag qn(w:tbl): yield Table(child, parent) doc Document(方案書.docx) for block in iter_block_items(doc): if isinstance(block, Paragraph): style block.style.name if block.style else text block.text.strip() if not text: continue if style.startswith(Heading 1): print(f# {text}) elif style.startswith(Heading 2): print(f## {text}) elif style.startswith(Heading 3): print(f### {text}) else: print(text) else: # 表格塊逐行逐單元格提取并在前面加 markdown 表格分隔 print(| | .join(cell.text.strip() for cell in block.rows[0].cells) |) print(| |.join([---] * len(block.rows[0].cells)) |) for row in block.rows[1:]: print(| | .join(cell.text.strip() for cell in row.cells) |)注意這里兩個(gè)細(xì)節(jié)一是用iter_block_items按文檔實(shí)際順序遍歷而不是先遍歷所有段落再遍歷所有表格否則文檔里的圖表順序會(huì)錯(cuò)亂二是把 Word 表格直接轉(zhuǎn)成 Markdown 表格格式這樣后續(xù)分塊時(shí)能保持單元格之間的對(duì)應(yīng)關(guān)系。我見過(guò)不少項(xiàng)目用doc.paragraphs提取結(jié)果表格里的關(guān)鍵數(shù)據(jù)全部丟光問(wèn)答系統(tǒng)對(duì)著合同“告訴我有多少金額”直接答不出來(lái)。另外頁(yè)碼和標(biāo)題信息建議拼進(jìn)文本開頭作為文檔來(lái)源標(biāo)記例如在每段前面加“第 3 節(jié)項(xiàng)目預(yù)算”這樣的前綴。這樣檢索結(jié)果里能直接知道引文出處也方便做引用溯源。2.3 Excel 數(shù)據(jù)要按“語(yǔ)義塊”而不是按行切Excel 的處理思路和 Word 不一樣。Word 是流式閱讀的Excel 是表格式的每一行只是一個(gè)記錄單獨(dú)切一行檢索往往沒(méi)有意義。比如一張銷售明細(xì)表第一行是“客戶名稱、產(chǎn)品、金額、日期”單獨(dú)把“北京公司 100 萬(wàn)”做成向量丟失了“這是哪個(gè)項(xiàng)目的收入”這個(gè)上下文。更合理的做法是按 Sheet 和表格區(qū)域聚合。我的做法是先提取 Sheet 名稱和表頭再把表格轉(zhuǎn)成行列結(jié)構(gòu)按“Sheet 名 表頭 若干行”作為一個(gè)語(yǔ)義塊。如果表格特別長(zhǎng)比如上千行的臺(tái)賬可以按 100200 行切一塊同時(shí)把表頭和 Sheet 名拼到每塊前面。import openpyxl wb openpyxl.load_workbook(報(bào)價(jià)明細(xì).xlsx, data_onlyTrue) for ws in wb.worksheets: rows list(ws.iter_rows(values_onlyTrue)) if not rows: continue header | .join([str(c) if c else for c in rows[0]]) block_lines [fSheet: {ws.title}, f表頭: {header}] chunk_size 100 for i in range(1, len(rows), chunk_size): chunk rows[i:ichunk_size] lines block_lines [ | .join(str(c) if c else for c in row) for row in chunk] chunk_text \n.join(lines) # 這里把 chunk_text 交給 embedding 入庫(kù)即可data_onlyTrue很關(guān)鍵它會(huì)返回緩存的計(jì)算結(jié)果而不是公式字符串。如果你的 Excel 里有大量公式不加這個(gè)參數(shù)提取出來(lái)的一堆“SUM(A1:A10)”對(duì) AI 毫無(wú)意義。另外合并單元格會(huì)讓某些行出現(xiàn) None提取時(shí)可以把上一條非空值前向填充當(dāng)然你也可以用 openpyxl 的merged_cells屬性在提取時(shí)精確處理。2.4 PPT 內(nèi)容要同時(shí)抓幻燈片和備注PPT 是企業(yè)知識(shí)庫(kù)里最容易被忽略又最“痛”的格式。它的文本分布在標(biāo)題框、內(nèi)容框、圖表、SmartArt 內(nèi)部和備注區(qū)尤其備注區(qū)的演講者提示往往藏著真正的干貨比如項(xiàng)目背景、口徑說(shuō)明、關(guān)鍵結(jié)論這些才是問(wèn)答系統(tǒng)里價(jià)值很高的素材。python-pptx 提取時(shí)要注意遍歷所有slide.shapes對(duì)shape.has_text_frame的取文本對(duì)shape.shape_type MSO_SHAPE_TYPE.TABLE的取表格對(duì)shape.has_chart的取圖表系列名稱和值。每張幻燈片建議單獨(dú)作為一個(gè)塊并加上頁(yè)碼和標(biāo)題作為前綴。from pptx import Presentation from pptx.enum.shapes import MSO_SHAPE_TYPE def extract_slide_text(shape): texts [] if shape.shape_type MSO_SHAPE_TYPE.TABLE: for row in shape.table.rows: texts.append( | .join(cell.text.strip() for cell in row.cells)) elif shape.has_text_frame: texts.append(shape.text_frame.text.strip()) return \n.join(t for t in texts if t) prs Presentation(季度匯報(bào).pptx) for idx, slide in enumerate(prs.slides, 1): slide_texts [] for shape in slide.shapes: t extract_slide_text(shape) if t: slide_texts.append(t) full_text f[Slide {idx}]\n \n.join(slide_texts) if slide.has_notes_slide: notes slide.notes_slide.notes_text_frame.text.strip() full_text f\n[備注]\n{notes} # full_text 進(jìn)入分塊流程這條代碼在實(shí)際項(xiàng)目中幫了不少忙。很多匯報(bào) PPT 的標(biāo)題是“公司戰(zhàn)略”備注里卻寫“此處強(qiáng)調(diào)要聚焦三大業(yè)務(wù)線”如果沒(méi)有備注知識(shí)庫(kù)永遠(yuǎn)回答不了“公司戰(zhàn)略的重點(diǎn)是什么”。當(dāng)然后續(xù)要給不同來(lái)源的內(nèi)容打標(biāo)簽比如在 metadata 里記錄source_typeslide或source_typenotes便于權(quán)限控制和過(guò)濾。2.5 掃描 PDF 轉(zhuǎn)來(lái)的“假 Word”要先過(guò) OCR再?gòu)?qiáng)調(diào)一次如果文檔是掃描件轉(zhuǎn)的不管它是 PDF 還是 Word里面基本沒(méi)有文本層。這時(shí)候必須接 OCR。OCR 工具的選擇我體驗(yàn)下來(lái)比較推薦 PaddleOCR中文識(shí)別效果在開源方案里比較能打如果團(tuán)隊(duì)里有人力做調(diào)優(yōu)也可以試試 Tesseract但中文模型的效果需要自己標(biāo)注。在知識(shí)庫(kù)場(chǎng)景里OCR 建議做得“穩(wěn)”不追求把每個(gè)字符都認(rèn)準(zhǔn)而是把版面結(jié)構(gòu)認(rèn)出來(lái)標(biāo)題、段落、表格區(qū)域。這樣后續(xù)分塊才能保留閱讀順序。實(shí)操時(shí)我習(xí)慣先把掃描 PDF 按頁(yè)面轉(zhuǎn)成圖片再用 PaddleOCR 的ocr接口識(shí)別并把每行結(jié)果按 y 坐標(biāo)排序從上到下拼成文本塊。這里有個(gè)細(xì)節(jié)表格行容易被識(shí)別成“一條橫線”要單獨(dú)把表格區(qū)域的識(shí)別結(jié)果按單元格坐標(biāo)重組否則表格數(shù)據(jù)會(huì)徹底亂掉。如果你的掃描件數(shù)量不大直接人工校對(duì)幾個(gè)關(guān)鍵表格比在代碼里調(diào)半天正則靠譜得多。3. 分塊、向量化與入庫(kù)搭起知識(shí)庫(kù)的骨架3.1 分塊策略別照抄網(wǎng)上參數(shù)先看文檔類型解析完成之后下一步是分塊。網(wǎng)上到處是“chunk_size512, overlap50”的建議直接照抄往往效果一般。分塊的本質(zhì)是找到一個(gè)平衡點(diǎn)塊太小檢索時(shí)上下文不夠模型看不懂說(shuō)的是什么塊太大一個(gè)塊里混著好幾個(gè)主題檢索召回相關(guān)性下降大模型的注意力也被稀釋。我自己的實(shí)踐經(jīng)驗(yàn)是分三類處理一是段落式內(nèi)容如 Word 方案、合同條款、制度文件按標(biāo)題層級(jí)天然劃分先按標(biāo)題 1標(biāo)題 2 切塊如果某個(gè)二級(jí)標(biāo)題下的內(nèi)容過(guò)長(zhǎng)再按 8001000 字拆分子塊并讓重疊部分包含前一個(gè)子塊的結(jié)尾通常 overlap 設(shè)在 10%15%。二是表格型內(nèi)容如 Excel 報(bào)價(jià)單、臺(tái)賬表頭和 Sheet 名必須跟數(shù)據(jù)塊綁定再按行數(shù)切塊塊與塊之間不需要 overlap否則重復(fù)記錄會(huì)干擾精確檢索。三是 PPT 型內(nèi)容按幻燈片整頁(yè)作為塊備注頁(yè)和正文合并。如果某頁(yè)文字特別多可以按內(nèi)容框拆成兩到三個(gè)子塊但仍保留頁(yè)碼信息。一段合格的塊看起來(lái)長(zhǎng)這樣 來(lái)源方案書_v3.docx 章節(jié)項(xiàng)目總體架構(gòu)標(biāo)題1 內(nèi)容本方案建議采用微服務(wù)架構(gòu)將系統(tǒng)拆分為用戶服務(wù)、訂單服務(wù)、支付服務(wù)等核心模塊。各服務(wù)通過(guò)消息隊(duì)列異步通信......后續(xù)正文這段文本里既有來(lái)源信息又有結(jié)構(gòu)標(biāo)題還有正文檢索時(shí)能直接理解為“這句話來(lái)自方案的哪個(gè)章節(jié)”問(wèn)答中就能帶著出處返回。還要提醒一個(gè)隱藏問(wèn)題中文和英文字符的 chunk 計(jì)算方式不一樣。很多國(guó)外框架的 tokenizer 是按英文單詞估算的Chinese 一句話可能十幾個(gè)字就算成十幾個(gè) token。建議用真實(shí)驗(yàn)證不要把理論 chunk_size 當(dāng)成硬性指標(biāo)而是看塊內(nèi)的實(shí)際 token 數(shù)超過(guò)模型 token 上限就要縮小。3.2 向量化模型選型中文場(chǎng)景下優(yōu)先級(jí)要調(diào)整分完塊之后就要對(duì)每個(gè)塊做向量化。這一步把文本變成一串浮點(diǎn)數(shù)向量檢索時(shí)通過(guò)余弦相似度計(jì)算哪個(gè)塊跟用戶問(wèn)題最接近。Embedding 模型的選型我認(rèn)為要考慮三個(gè)維度中文語(yǔ)義理解能力、向量維度、部署成本?，F(xiàn)在常見的選擇包括模型中文效果維度說(shuō)明BGE-M3優(yōu)秀1024 / 512 可配支持中英混合適合知識(shí)庫(kù)本地部署可控text-embedding-3-small良好1536云端服務(wù)接入簡(jiǎn)單成本較低text-embedding-3-large更好3072強(qiáng)語(yǔ)義理解但存儲(chǔ)開銷和費(fèi)用更高M(jìn)3E / bge-large-zh良好1024中文優(yōu)化離線可用老牌選擇Ollama embedding 模型一般不定本地部署友好但中文詞典覆蓋有限需測(cè)試實(shí)戰(zhàn)中文檔量大、中文為主、又對(duì)數(shù)據(jù)隱私有要求的企業(yè)優(yōu)先考慮 BGE-M3 或 bge-large-zh本地部署接入 Dify 或 LangChain 都很順。如果對(duì)云端不敏感先用 text-embedding-3-small 跑通再根據(jù)實(shí)際效果升級(jí)。向量維度的選擇不只是模型本身的參數(shù)還影響向量庫(kù)的存儲(chǔ)和檢索性能維度太高單條查詢變慢索引內(nèi)存也膨脹。向量庫(kù)選型方面小規(guī)模知識(shí)庫(kù)少于 100 萬(wàn)塊用 Qdrant 或 pgvector 就夠支持 Docker 部署配置簡(jiǎn)單。百萬(wàn)級(jí)別以上再考慮 Milvus。如果團(tuán)隊(duì)已經(jīng)有 Elasticsearch 基礎(chǔ)設(shè)施也可以直接用它存向量利用已有的權(quán)限和運(yùn)維生態(tài)。3.3 用 Dify 搭建知識(shí)庫(kù)流水線不要覺(jué)得只有寫代碼才能搭知識(shí)庫(kù)。現(xiàn)在到了 2025 年Dify、RAGFlow、FastGPT 這類開源平臺(tái)把鏈路做得很完整。下面是我比較推薦的一個(gè) Dify 搭建路徑。第一步創(chuàng)建一個(gè)知識(shí)庫(kù)應(yīng)用。第二步接入文檔源把第二步解析好的文本或其他格式文件傳進(jìn)去。第三步在設(shè)置里選好 Embedding 模型。第四步設(shè)置分塊規(guī)則Dify 支持自定義 Segmentation 模式直接填 chunk_size 和 overlap。第五步綁定到 Chatflow讓用戶提問(wèn)時(shí)先檢索知識(shí)庫(kù)再調(diào)對(duì)話模型。需要注意一點(diǎn)在 Dify 里不要偷懶把 Office 文件直接上傳它的內(nèi)置解析器雖然方便但對(duì)復(fù)雜版式和表格處理能力一般。更穩(wěn)的做法是保證自己在外部完成了解析清洗再導(dǎo)入寧可靠前一步優(yōu)化也別讓知識(shí)庫(kù)出現(xiàn)壞數(shù)據(jù)。如果你追求數(shù)據(jù)庫(kù)級(jí)可控“連接外部知識(shí)庫(kù)”也是 Dify 支持的方向。可以把 Qdrant 或 pgvector 作為外部向量庫(kù)Dify 做編排檢索時(shí)先查外部庫(kù)再拼裝上下文。這樣便于已有業(yè)務(wù)的團(tuán)隊(duì)復(fù)用現(xiàn)有數(shù)據(jù)也可以避免頻繁遷庫(kù)。3.4 Metadata 設(shè)計(jì)決定你能不能做權(quán)限和溯源分塊之后每一塊一定要帶上 metadata 字段元數(shù)據(jù)是知識(shí)庫(kù)的靈魂。沒(méi)有 metadata你的知識(shí)庫(kù)就是一堆無(wú)差別文本后續(xù)想做權(quán)限隔離、引用溯源、更新時(shí)間過(guò)濾全都做不了。推薦至少包含這些字段doc_id文檔唯一編碼建議用哈希值便于底層查重doc_name便于展示的來(lái)源名source_typeword/excel/ppt/pdfsection_path章節(jié)路徑例如“項(xiàng)目總體架構(gòu) / 技術(shù)方案”page_no如果有頁(yè)碼則保留chunk_index塊序號(hào)便于按順序重排updated_at文檔更新時(shí)間permission_tags部門標(biāo)簽或密級(jí)標(biāo)簽用于權(quán)限過(guò)濾權(quán)限這塊很多企業(yè)會(huì)犯一個(gè)錯(cuò)誤向量庫(kù)只做檢索權(quán)限放在應(yīng)用層。但權(quán)限必須同時(shí)落在文檔級(jí)別和 chunk 級(jí)別。簡(jiǎn)單做法是給每個(gè)塊打上dept標(biāo)簽檢索時(shí)把用戶所屬部門作為過(guò)濾條件傳給向量庫(kù)做filter參數(shù)而不僅僅是返回結(jié)果后再過(guò)濾否則底層數(shù)據(jù)泄露誰(shuí)都攔不住。3.5 增量更新與知識(shí)庫(kù)的“新陳代謝”企業(yè)文檔每天都在變昨天上傳的方案第二天就更新了達(dá)成了一個(gè)錯(cuò)誤版本。如果不處理知識(shí)庫(kù)永遠(yuǎn)“活在昨天”。增量更新的常見方案是在文檔入庫(kù)時(shí)記錄文檔的doc_id和content_hash每次掃描文件時(shí)先比哈希哈希變了就刪除舊 chunks重新解析入庫(kù)完全新增的文檔直接入庫(kù)。這個(gè)邏輯可以用 Airflow、Prefect 或者定時(shí)腳本實(shí)現(xiàn)。還有一個(gè)容易忽略的操作清理已刪除文檔。共享盤里文件可能移動(dòng)了路徑、改了名字如果只按“新增”邏輯跑舊版本殘留會(huì)讓檢索結(jié)果重復(fù)甚至沖突。我建議每次同步前先遍歷一遍源頭目錄生成當(dāng)前文件清單跟庫(kù)里的 doc_id 對(duì)比把缺席文檔的所有 chunks 一次性刪除。這步雖然簡(jiǎn)單卻能讓知識(shí)庫(kù)保持干凈的狀態(tài)避免用戶搜到半年前的過(guò)時(shí)信息。4. 實(shí)操過(guò)程從 Office 文件到可問(wèn)答知識(shí)庫(kù)的完整鏈路4.1 環(huán)境準(zhǔn)備與依賴安裝基于常見實(shí)踐的補(bǔ)充這里給出一個(gè)可復(fù)現(xiàn)的最小方案使用 Python Dify Qdrant 或本地向量模型。假設(shè)你有基礎(chǔ) Python 環(huán)境建議用 conda 或 venv 建一個(gè)獨(dú)立環(huán)境。mkdir office-kb cd office-kb python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate需要安裝的庫(kù)見下面的 requirements.txt都是常用庫(kù)版本號(hào)建議根據(jù)網(wǎng)絡(luò)實(shí)際可用情況安裝最新穩(wěn)定版。libreoffice-convert # 如果需要批量轉(zhuǎn)格式可自行安裝對(duì)應(yīng)轉(zhuǎn)換器 python-docx openpyxl python-pptx pandas pypdf2 paddleocr # OCR 需要?jiǎng)t裝對(duì)依賴較高請(qǐng)注意libreoffice-convert依賴系統(tǒng)安裝 LibreOffice。裝完以后可以用一個(gè)簡(jiǎn)單的命令行測(cè)試libreoffice --headless --convert-to pdf 方案書.docx --outdir ./pdf_output4.2 從文件目錄批量解析入庫(kù)的核心代碼下面這段代碼可以算是一個(gè)迷你版的文檔入庫(kù)腳本骨架基于我平時(shí)的處理習(xí)慣整理。它做三件事遍歷目錄、按擴(kuò)展名分流解析、組裝 metadata 交給后面分塊。import hashlib from pathlib import Path from docx import Document from pptx import Presentation import openpyxl def get_file_hash(path: Path) - str: h hashlib.sha256() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) return h.hexdigest() def extract_docx(path: Path): doc Document(path) blocks [] # 這里復(fù)用前面 iter_block_items 的邏輯輸出按結(jié)構(gòu)拼接的文本 return \n.join(blocks) def extract_pptx(path: Path): prs Presentation(path) slides [] # 復(fù)用前面的逐頁(yè)提取邏輯記錄 slide 序號(hào)和備注 return \n.join(slides) def extract_xlsx(path: Path): wb openpyxl.load_workbook(path, data_onlyTrue) sheets [] # 這里復(fù)用前文 Sheet 表頭 數(shù)據(jù)塊 的邏輯 return \n.join(sheets) def process_folder(folder: Path): for ext, func in {.docx: extract_docx, .pptx: extract_pptx, .xlsx: extract_xlsx}.items(): for file in folder.rglob(f*{ext}): # 1. 計(jì)算哈希 content_hash get_file_hash(file) # 2. 解析文本 text func(file) # 3. 分塊和向量化這里暫用占位邏輯 yield { doc_id: content_hash, doc_name: file.name, source_type: ext.replace(., ), text: text, updated_at: file.stat().st_mtime, } for item in process_folder(Path(企業(yè)文檔)): # 接入向量庫(kù)或 Dify API 的寫入函數(shù) pass這段代碼的真正價(jià)值是幫你把“文件系統(tǒng)”和“知識(shí)庫(kù)”建立映射。后續(xù)不管用了多少次、改了多少文件都能通過(guò) doc_id 精準(zhǔn)刪除重建而不是簡(jiǎn)單清空重來(lái)。如果你的團(tuán)隊(duì)更喜歡低代碼方式Dify 的文檔導(dǎo)入功能可以省掉這段 Python。把解析腳本作為前置清洗模塊也是后面做生產(chǎn)級(jí)知識(shí)庫(kù)的必經(jīng)之路我建議兩者結(jié)合低代碼平臺(tái)跑流程Python 腳本做特殊文檔的精處理。4.3 RAG 問(wèn)答驗(yàn)證不只看“答得出來(lái)”還要看“引用對(duì)沒(méi)有”知識(shí)庫(kù)搭好后別急著宣告成功。先用指定測(cè)試集驗(yàn)證效果。我的習(xí)慣是從三個(gè)角度出題事實(shí)查詢類“2024 年第二季度華東區(qū)的銷售額是多少”對(duì)應(yīng)表格型知識(shí)要求答案有準(zhǔn)確的數(shù)字和出處?？偨Y(jié)歸納類“公司今年的三大戰(zhàn)略重點(diǎn)分別是什么”對(duì)應(yīng) PPT 和 Word 標(biāo)題體系需要模型跨多個(gè)塊綜合。流程制度類“報(bào)銷流程需要哪些審批節(jié)點(diǎn)”對(duì)應(yīng)制度文檔需要引用原文條款。把這三類問(wèn)題分別跑一遍按照回答準(zhǔn)確率、引用正確率、拒絕回答率三個(gè)指標(biāo)打分。正常來(lái)說(shuō)準(zhǔn)確率低于 60% 說(shuō)明文檔解析或分塊有明顯問(wèn)題先不要急著換模型而是回去看是不是表格丟了、標(biāo)題層級(jí)壞了、OCR 亂碼了。調(diào)試時(shí)我推薦一個(gè)“檢索前置”的小技巧在 Dify 或 LangChain 的調(diào)試界面里先不看大模型的最終回答先看檢索返回了哪些 chunk。如果返回的 chunk 本身不是相關(guān)內(nèi)容那后面大模型回答不可能靠譜如果 chunk 相關(guān)但回答不對(duì)那是 Prompt 或語(yǔ)義理解的問(wèn)題。這條經(jīng)驗(yàn)基本能定位 80% 的知識(shí)庫(kù)問(wèn)題。4.4 從“能答”到“答得好”的 Prompt 調(diào)優(yōu)不要迷信模型能力Prompt 往往決定知識(shí)庫(kù)的最終體驗(yàn)。下面是一個(gè)比較實(shí)用的 RAG 問(wèn)答提示詞模板適合在 Chatflow 里使用你是企業(yè)內(nèi)部知識(shí)庫(kù)助手。請(qǐng)僅根據(jù)下面提供的【參考資料】回答問(wèn)題。 如果參考資料中沒(méi)有明確信息請(qǐng)直接回復(fù)“知識(shí)庫(kù)中未找到相關(guān)信息”不要猜測(cè)。 【參考資料】 {context} 【用戶問(wèn)題】 {question} 要求 1. 答案中涉及的制度條款、數(shù)字、流程步驟必須在回答末尾標(biāo)注來(lái)源文件名和段落標(biāo)題。 2. 如果問(wèn)題與參考資料無(wú)關(guān)回復(fù)“這個(gè)問(wèn)題不在我的知識(shí)范圍內(nèi)”。這個(gè)模板看起來(lái)很簡(jiǎn)單但它強(qiáng)制模型“沒(méi)有資料就承認(rèn)不知道”可以避免一本正經(jīng)地胡說(shuō)八道。實(shí)際使用中你還可以根據(jù)企業(yè)特點(diǎn)追加“如果涉及金額必須保留兩位小數(shù)”“回答時(shí)先給出結(jié)論再給出依據(jù)”等約束。Prompt 是在知識(shí)庫(kù)數(shù)據(jù)質(zhì)量過(guò)關(guān)之后性價(jià)比最高的調(diào)優(yōu)手段。5. 常見問(wèn)題與排查技巧實(shí)錄5.1 明明有答案檢索卻一直召回不到出現(xiàn)這個(gè)現(xiàn)象十有八九是分塊粒度或結(jié)構(gòu)信息丟了。我遇到過(guò)最典型的例子客戶上線一個(gè)合同知識(shí)庫(kù)測(cè)試問(wèn)“違約金條款是什么”模型總是答不上來(lái)。排查后發(fā)現(xiàn)原合同的章節(jié)被排版成分頁(yè)符隔開解析時(shí)把“違約責(zé)任”和正文拆成了兩個(gè)塊檢索時(shí)“違約金”這三個(gè)字只在標(biāo)題塊里出現(xiàn)正文塊沒(méi)有關(guān)鍵詞兩個(gè)塊都只能算低相關(guān)最終被 Top-K 截?cái)唷＝鉀Q辦法一是讓分塊把標(biāo)題和正文放在同一個(gè)塊里可以通過(guò) Python 解析時(shí)對(duì)上游塊做“標(biāo)題繼承”遇到標(biāo)題 1 時(shí)把它存為當(dāng)前 section直到遇到下一個(gè)標(biāo)題才替換。在分塊時(shí)把這個(gè) section 拼到每個(gè) chunk 的前綴里。這樣每個(gè)子塊都能帶著章節(jié)上下文檢索召回會(huì)穩(wěn)很多。另一個(gè)原因是 Embedding 模型對(duì)長(zhǎng)文本概括能力一般。檢索詞集中在某個(gè)段落但那個(gè)段落被截?cái)嗟搅硪粋€(gè)塊里。這時(shí)可以適度提高 chunk_size或者調(diào)整 overlap。我的經(jīng)驗(yàn)是overlap 最少要有百字級(jí)別的語(yǔ)義銜接不能只重復(fù)最后兩句話。5.2 Excel 表格“看得見字但一回答問(wèn)題就是錯(cuò)的”Excel 入庫(kù)經(jīng)常出現(xiàn)三種問(wèn)題一是列頭丟了分塊時(shí)只取數(shù)據(jù)行不取表頭二是合并單元格沒(méi)處理導(dǎo)致數(shù)據(jù)對(duì)應(yīng)錯(cuò)列三是多 Sheet 之間共享一個(gè)表頭但語(yǔ)義完全不同比如“一月數(shù)據(jù)”和“二月數(shù)據(jù)”結(jié)構(gòu)相同單獨(dú)檢索時(shí)模型不知道數(shù)字屬于哪個(gè)月。給這些表格數(shù)據(jù)加“字段前綴”是個(gè)好做法。我在 excel 塊生成文本時(shí)會(huì)把“Sheet 名 表頭 日期范圍”放在每塊的最前面例如數(shù)據(jù)來(lái)源2024年銷售臺(tái)賬.xlsx / Sheet華東大區(qū) 表頭客戶名稱 | 產(chǎn)品 | 金額(元) | 合同日期 | 負(fù)責(zé)人 數(shù)據(jù)杭州某某公司 | A系列 | 120000 | 2024-03-05 | 張三這樣模型看到每行數(shù)據(jù)時(shí)就知道它的字段語(yǔ)義。如果表頭和數(shù)據(jù)行被分塊切開這個(gè)前綴還能在多個(gè)塊里重復(fù)出現(xiàn)保證塊之間信息一致。5.3 PPT 記錄了很多內(nèi)容但檢索時(shí)“看不到重點(diǎn)”PPT 這類版式文檔最大的問(wèn)題是“一句話被拆在多個(gè)文本框里”比如標(biāo)題是一個(gè)文本框副標(biāo)題是另一個(gè)文本框旁邊還有個(gè)圖標(biāo)里的文字。如果只按文本框逐個(gè)提取原本一個(gè)完整觀點(diǎn)被拆成三四個(gè)塊檢索時(shí)每個(gè)塊都很短相關(guān)性得分不高。解決辦法是把同一頁(yè)內(nèi)所有文本框的內(nèi)容合并成一個(gè)塊通過(guò)形狀的坐標(biāo)left、top判斷閱讀順序再按位置排序拼接。還有一種更省事的辦法利用 PPT 的分頁(yè)符天然切塊把一頁(yè)的全部文本作為一個(gè)塊。這樣即使頁(yè)面里有多個(gè)形狀也可以保證信息完整。多年的經(jīng)驗(yàn)提醒做 PPT 知識(shí)庫(kù)時(shí)不要把“頁(yè)標(biāo)題”當(dāng)成塊的唯一索引。很多企業(yè) PPT 標(biāo)題習(xí)慣寫成“項(xiàng)目概覽”“核心亮點(diǎn)”這類雷同詞如果檢索只看標(biāo)題多個(gè)塊高度相似無(wú)法區(qū)分。必須在塊內(nèi)附帶一兩句頁(yè)面正文的關(guān)鍵詞讓檢索命中正文內(nèi)容。5.4 大量文件入庫(kù)時(shí)檢索結(jié)果出現(xiàn)重復(fù)或沖突如果你發(fā)現(xiàn)同一個(gè)知識(shí)點(diǎn)被返回了好幾份而且內(nèi)容互相矛盾基本可以斷定庫(kù)里存在舊版本殘留。前面提到的內(nèi)容哈希方案就是為解決這個(gè)問(wèn)題而設(shè)的。掃描時(shí)比對(duì)每個(gè)文檔的 SHA-256只要文件內(nèi)容變了就把舊 doc_id 對(duì)應(yīng)的所有 chunks 刪掉再用新的文本重新生成向量。這個(gè)方案也有條件解析前的“原始文本”和入庫(kù)后的“向量塊”必須能通過(guò) doc_id 做反查。所以建議在上游就維護(hù)一個(gè)簡(jiǎn)易的 document registry 表記錄 doc_id、文件路徑、content_hash、pages、chunk_count。任何同步任務(wù)跑完先檢查這個(gè)表有沒(méi)有異常再調(diào)問(wèn)答測(cè)試。5.5 權(quán)限泄露是知識(shí)庫(kù)的高危場(chǎng)景很多企業(yè)覺(jué)得 RAG 知識(shí)庫(kù)是個(gè)內(nèi)部應(yīng)用不設(shè)防。但實(shí)際中除非文檔都是全公司公開級(jí)否則一定要帶權(quán)限控制。這里再?gòu)?qiáng)調(diào)一遍權(quán)限一定要下推到 chunk 層不是只在業(yè)務(wù)層過(guò)濾。以 Dify 為例如果直接用外部知識(shí)庫(kù) API可以在檢索參數(shù)里加入filter比如dept in [tech, hr]。這樣每個(gè)用戶的查詢請(qǐng)求都帶過(guò)濾條件檢索階段就排除無(wú)權(quán)訪問(wèn)的塊。如果用戶想通過(guò)越權(quán)提問(wèn)套取其他部門的東西向量庫(kù)返回的結(jié)果天然不含高密級(jí)內(nèi)容安全面就小了很多。至于權(quán)限標(biāo)簽怎么來(lái)文件系統(tǒng)里通常有文件夾結(jié)構(gòu)或文件命名規(guī)則合理映射到部門標(biāo)簽即可。寫在最后的一點(diǎn)體會(huì)做了這么多企業(yè)知識(shí)庫(kù)項(xiàng)目我的一個(gè)強(qiáng)烈感受是技術(shù)本身已經(jīng)不是瓶頸瓶頸在于團(tuán)隊(duì)是否愿意在文檔治理上花功夫。Office 文檔構(gòu)建 AI 知識(shí)庫(kù)最容易出彩的環(huán)節(jié)不是大模型選了多強(qiáng)而是解析清洗做到位分塊設(shè)計(jì)貼合業(yè)務(wù)。我自己也多次被現(xiàn)實(shí)教育剛開始總覺(jué)得模型聰明一點(diǎn)就能解決一切后來(lái)發(fā)現(xiàn)讓結(jié)構(gòu)化的 Office 文檔以正確的姿勢(shì)進(jìn)入知識(shí)庫(kù)遠(yuǎn)比切換更貴的模型更有效。如果你正在設(shè)計(jì)新的知識(shí)庫(kù)系統(tǒng)我建議先找一個(gè)最小的業(yè)務(wù)場(chǎng)景試點(diǎn)挑一個(gè)目錄幾百份合同或幾十份項(xiàng)目總結(jié)從解析到問(wèn)答完整跑通再慢慢擴(kuò)大到全公司。別一上來(lái)就想把共享盤幾萬(wàn)份文件一股腦灌進(jìn)去那樣既難以保證質(zhì)量也難以及時(shí)發(fā)現(xiàn)數(shù)據(jù)問(wèn)題。先拿一套“能答對(duì)有出處的問(wèn)題”作為驗(yàn)收標(biāo)準(zhǔn)再逐步擴(kuò)展覆蓋范圍這是我認(rèn)為最穩(wěn)妥、也最容易出效果的實(shí)施路徑。