Dify 社群提出中文分隔符修補，處理 RAG 切塊時的編碼錯誤

Dify 社群於 11 月 4 日提交修補提案 #45535，指出 RAG 固定分隔符的初始化流程會破壞非 ASCII 字元。相關回報以標示為 1.18.0 的原始碼自架環境為例：指定中文句號「。」後，三句短文仍被保留成同一塊。截至查核時，提案仍開放中，尚未取得維護者核准或合併。問題回報

問題出在分隔符的跳脫處理。程式原本透過 unicode_escape，將使用者輸入的反斜線加 n 轉為真正換行；但同一處理也套用到直接輸入的 Unicode 字元，使中文句號變成另一串字元，無法匹配原文。作者提出的修改是先用 isascii() 判斷，僅對 ASCII 分隔符執行解碼，其餘保留原值，並新增測試檢查中文分隔及既有換行行為。修補提案

影響範圍需要收斂。問題串的自動化回覆指出，超過長度門檻的文字仍可能進入遞迴切分，因此長文可能掩蓋錯誤；目前公開案例支持的是固定分隔符失效，不能延伸成整套中文切塊停擺。該回覆也提醒，若分隔符同時包含 Unicode 與跳脫序列，整段略過解碼會留下未展開的序列，這仍是審查應確認的語義邊界。問題討論

對中文知識庫而言，切塊邊界會決定哪些內容一起被檢索、送入模型。Dify 官方文件說明，一般模式直接回傳命中的區塊，父子模式則以子塊匹配、回傳父塊提供上下文。因此，分隔行為偏離設定可能改變檢索粒度；這是工程上的風險推論，目前沒有公開召回率或回答品質數據可量化影響。官方切塊文件

工程團隊可先用低於長度門檻的中文短文檢查實際分段，再加入長文、表情符號與混合跳脫序列，核對區塊內容及邊界。後續應追蹤維護者審查與正式版本收錄情況，並在修補後比較既有索引的分段結果，決定是否需要重新處理文件。