將內(nèi)容上傳至知識庫后，要對內(nèi)容進行分段與數(shù)據(jù)清洗。該階段是內(nèi)容的預處理與數(shù)據(jù)結構化過程，長文本將會被劃分為多個內(nèi)容分段。

1 分段

由于LLM的上下文窗口有限，無法一次性處理和傳輸整個知識庫的內(nèi)容，因此需對文檔 中的長文本分段為內(nèi)容塊。即便部分大模型已支持上傳完整的文檔文件，但實驗表明，檢索效率依然弱于檢索單個內(nèi)容分段。

LLM能否精準回答出知識庫中內(nèi)容，關鍵在知識庫對內(nèi)容塊的檢索與召回效果。類似在手冊中查找關鍵章節(jié)即可快速得到答案，而無需逐字逐句分析整個文檔。

經(jīng)分段后，知識庫能基于用戶問題，采用分段 TopK 召回模式，召回與問題高度相關的內(nèi)容塊，補全關鍵信息從而提高回答精準性。

進行問題與內(nèi)容塊的語義匹配時，合理分段大小很關鍵，能幫助模型準確找到與問題最相關內(nèi)容，減少噪音信息。

Dify 提供 “通用分段” 和 “父子分段” 兩種分段模式，分別適應不同類型的文檔結構和應用場景，滿足不同的知識庫檢索和召回的效率與準確性要求。

2 清洗

為保證文本召回效果，通常需在將數(shù)據(jù)錄入知識庫之前便對其進行清理。如文本內(nèi)容中存在無意義字符或空行，可能影響問題回復質(zhì)量，需清洗。

LLM收到用戶問題后，能否精準回答知識庫中內(nèi)容，取決知識庫對內(nèi)容塊的檢索和召回效果。匹配與問題相關度高的文本分段對 AI 應用生成準確且全面的回應至關重要。

好比智能客服，僅需幫助 LLM 定位至工具手冊的關鍵章節(jié)內(nèi)容塊即可快速得到用戶問題的答案，而無需重復分析整個文檔。在節(jié)省分析過程中所耗費的 Tokens 的同時，提高 AI 應用的問答質(zhì)量。

ETL

RAG生產(chǎn)級應用，為獲得更好的數(shù)據(jù)召回效果，需對多源數(shù)據(jù)進行預處理和清洗，即ETL。為增強非結構化/半結構化數(shù)據(jù)的預處理能力，Dify支持可選 ETL 方案：

• Dify ETL
• Unstructured ETL 。Unstructured 能高效提取并轉換你的數(shù)據(jù)為干凈的數(shù)據(jù)用于后續(xù)的步驟。

Dify版本的 ETL 方案：

• SaaS版不可選，默認Unstructured ETL
• 社區(qū)版可選，默認Dify ETL ，可通過環(huán)境變量開啟 Unstructured ETL

文件解析支持格式的差異：

不同的 ETL 方案在文件提取效果的方面也存在差異，想了解更多關于 Unstructured ETL 的數(shù)據(jù)處理方式，請參考官方文檔。

3 分段模式

知識庫支持兩種分段模式：通用模式與父子模式。首次創(chuàng)建知識庫，推薦父子模式。

選定分段模式并完成知識庫的創(chuàng)建后，后續(xù)無法變更。

知識庫內(nèi)新增的文檔也將遵循同樣的分段模式。

3.1 通用模式

系統(tǒng)按用戶自定義規(guī)則將內(nèi)容拆分為獨立的分段。當用戶輸入問題后，系統(tǒng)自動分析問題中的關鍵詞，并計算關鍵詞與知識庫中各內(nèi)容分段的相關度。根據(jù)相關度排序，選取最相關的內(nèi)容分段并發(fā)送給 LLM，輔助其處理與更有效地回答。

該模式下，需根據(jù)不同的文檔格式或場景要求，參考以下設置項，手動設置文本的分段規(guī)則。

① 分段標識符

默認 \n，即按文章段落分塊。可遵循正則表達式自定義分塊規(guī)則，系統(tǒng)將在文本出現(xiàn)分段標識符時自動執(zhí)行分段。例如 的含義是按照句子進行分段。

不同語法的文本分段效果：

② 分段最大長度

指定分段內(nèi)的文本字符數(shù)最大上限，超出該長度時將強制分段。默認值為 500 Tokens，分段長度的最大上限為 4000 Tokens。

③ 分段重疊長度

對數(shù)據(jù)進行分段時，段與段之間存在一定重疊部分。這種重疊可幫助提高信息的保留和分析的準確性，提升召回效果。建議設置為分段長度 Tokens 數(shù)的 10-25%。

④ 文本預處理規(guī)則

過濾知識庫內(nèi)部分無意義的內(nèi)容。提供以下選項：

• 替換連續(xù)的空格、換行符和制表符
• 刪除所有 URL 和郵件地址

配置完成后，點擊“預覽區(qū)塊”即可查看分段后的效果。可直觀看到每個區(qū)塊的字符數(shù)。如重新修改分段規(guī)則，需重新點擊按鈕以查看新的內(nèi)容分段。

若同時批量上傳多個文檔，輕點頂部的文檔標題，快速切換并查看其它文檔的分段效果。

分段規(guī)則設置完成后，接下來需指定索引方式。支持“高質(zhì)量索引”和“經(jīng)濟索引”，詳細說明請參考設定索引方法。

3.2 父子模式

父子模式采用雙層分段結構來平衡檢索的精確度和上下文信息，兼得：

• 精準匹配
• 全面的上下文信息

父區(qū)塊（Parent-chunk）保持較大的文本單位（如段落），提供豐富上下文信息

子區(qū)塊（Child-chunk）是較小的文本單位（如句子），用于精確檢索。系統(tǒng)先通過子區(qū)塊進行精確檢索以確保相關性，然后獲取對應的父區(qū)塊來補充上下文信息，從而在生成響應時既保證準確性又能提供完整的背景信息。你可以通過設置分隔符和最大長度來自定義父子區(qū)塊的分段方式。

如AI智能客服場景，用戶輸入的問題將定位至解決方案文檔內(nèi)某具體句子，再將該句子所在的段落或章節(jié)，聯(lián)同發(fā)送至 LLM，補全該問題的完整背景信息，給出更精準回答。

3.2.0 實現(xiàn)原理

① 子分段匹配查詢

• 將文檔拆分為較小、集中的信息單元（如一句話），更精準匹配用戶所輸入的問題
• 子分段快速提供與用戶需求最相關的初步結果

② 父分段提供上下文

• 將包含匹配子分段的更大部分（如段落、章節(jié)甚至整個文檔）視作父分段并提供給LLM
• 父分段為LLM提供完整背景信息，避免遺漏重要細節(jié)，助 LLM 輸出更貼合知識庫內(nèi)容的回答

該模式下，需根據(jù)不同文檔格式或場景要求，手動分別設置父子分段的分段規(guī)則。

3.2.1 父分段

分段選項：

段落

根據(jù)預設的分隔符規(guī)則和最大塊長度將文本拆分為段落。每個段落視為父分段，適用于文本量較大，內(nèi)容清晰且段落相對獨立的文檔。支持以下設置項：

• 分段標識符，默認值為 \n，即按照文本段落分段?？勺裱齽t表達式自定義分塊規(guī)則，系統(tǒng)將在文本出現(xiàn)分段標識符時自動執(zhí)行分段。
• 分段最大長度，指定分段內(nèi)的文本字符數(shù)最大上限，超出該長度時將強制分段。默認值為 500 Tokens，分段長度的最大上限為 4000 Tokens；

全文

不進行段落分段，而直接將全文視為單一父分段。出于性能原因，僅保留文本內(nèi)的前 10000 Tokens 字符，適用于文本量較小，但段落間互有關聯(lián)，需完整檢索全文的場景。

父子模式下的段落和全文預覽：

3.2.2 子分段

子分段文本在父文本分段基礎上，由分隔符規(guī)則切分而成，用于查找和匹配與問題關鍵詞最相關和直接的信息。如果使用默認的子分段規(guī)則，呈現(xiàn)的分段效果：

• 當父分段為段落時，子分段對應各段落中的單個句子
• 父分段為全文時，子分段對應全文中各單獨的句子

在子分段內(nèi)填寫以下分段設置：

• 分段標識符，默認值為 ，即按照句子進行分段?？勺裱齽t表達式自定義分塊規(guī)則，系統(tǒng)將在文本出現(xiàn)分段標識符時自動執(zhí)行分段。
• 分段最大長度，指定分段內(nèi)的文本字符數(shù)最大上限，超出該長度時將強制分段。默認值為 200 Tokens，分段長度的最大上限為 4000 Tokens；

還可用文本預處理規(guī)則過濾知識庫內(nèi)部分無意義的內(nèi)容：

• 替換連續(xù)的空格、換行符和制表符
• 刪除所有 URL 和電子郵件地址

配置完成后，點擊“預覽區(qū)塊”即可查看分段后的效果。你可以查看父分段的整體字符數(shù)。背景標藍的字符為子分塊，同時顯示當前子段的字符數(shù)。

如果重新修改了分段規(guī)則，需要重新點擊“預覽區(qū)塊”按鈕以查看新的內(nèi)容分段。若同時批量上傳了多個文檔，輕點頂部的文檔標題，快速切換至其它文檔并預覽內(nèi)容的分段效果。

父子分段模式：

為確保內(nèi)容檢索的準確性，父子分段模式僅支持使用“高質(zhì)量索引”。

3.3 模式區(qū)別

內(nèi)容區(qū)塊的分段形式：

• 通用模式的分段結果為多個獨立的內(nèi)容分段
• 父子模式采用雙層結構進行內(nèi)容分段，即單個父分段的內(nèi)容（文檔全文或段落）內(nèi)包含多個子分段內(nèi)容（句子）

不同分段方式影響 LLM 對知識庫內(nèi)容的檢索效果。相同文檔中，采用父子檢索提供的上下文信息更全面，且精準度方面也保持較高水平，遠優(yōu)于傳統(tǒng)的單層通用檢索方式。

通用模式與父子模式的內(nèi)容檢索效果對比。

本文已收錄在Github，關注我，緊跟本系列專欄文章，咱們下篇再續(xù)！

• ?? 魔都架構師 | 全網(wǎng)30W+技術追隨者
• ?? 大廠分布式系統(tǒng)/數(shù)據(jù)中臺實戰(zhàn)專家
• ?? 主導交易系統(tǒng)億級流量調(diào)優(yōu) & 車聯(lián)網(wǎng)平臺架構
• ?? AIGC應用開發(fā)先行者 | 區(qū)塊鏈落地實踐者
• ?? 以技術驅動創(chuàng)新，我們的征途是改變世界！
• ?? 實戰(zhàn)干貨：編程嚴選網(wǎng)

本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！