Difyコミュニティが中国語の区切り文字を修正するパッチを提案、RAGのチャンク分割時のエンコーディングエラーに対応

Difyコミュニティは11月4日、RAGの固定区切り文字の初期化処理が非ASCII文字を破損させるとして、修正提案 #45535 を提出した。関連する報告では、バージョン表示が1.18.0のソースコードを使ったセルフホスト環境を例に挙げている。中国語の句点「。」を指定すると、3つの短文が同じチャンクにまとめられたままになるという。確認時点で提案はオープンのままで、メンテナーの承認もマージも行われていない。問題報告

問題は区切り文字のエスケープ処理にある。元のコードは unicode_escape を使い、ユーザー入力のバックスラッシュと n を実際の改行に変換していた。しかし、同じ処理が直接入力されたUnicode文字にも適用され、中国語の句点が別の文字列に変わり、原文と一致しなくなっていた。提案者は isascii() で判定し、ASCIIの区切り文字だけをデコードして、ほかの文字はそのまま保持する修正を提案している。また、中国語の区切り文字と既存の改行動作を確認するテストも追加する。修正提案

影響範囲は限定的に捉える必要がある。問題スレッドの自動応答によると、長さのしきい値を超えたテキストは再帰的な分割処理に入る可能性があり、長文ではエラーが表面化しないことがある。現時点で公開された事例が裏付けているのは固定区切り文字が機能しないことまでであり、中国語のチャンク分割機能全体が停止しているとまでは言えない。同じ応答は、区切り文字にUnicode文字とエスケープシーケンスの両方が含まれる場合、全体のデコードをスキップするとシーケンスが展開されずに残るとも指摘している。この点はレビューで確認すべき仕様上の境界だ。問題の議論

中国語のナレッジベースでは、チャンクの境界によって、どの内容がまとめて検索され、モデルに送られるかが決まる。Difyの公式ドキュメントによると、通常モードはヒットしたチャンクをそのまま返し、親子モードは子チャンクを照合して、コンテキストとして親チャンクを返す。そのため、区切り動作が設定と異なれば、検索粒度が変わる可能性がある。これはエンジニアリング上のリスクに関する推論であり、影響を定量化できる公開済みの再現率や回答品質のデータはない。公式チャンク分割ドキュメント

エンジニアリングチームはまず、長さのしきい値を下回る中国語の短文で実際の分割結果を確認し、その後、長文、絵文字、エスケープシーケンスが混在するケースを加えて、各チャンクの内容と境界を検証できる。今後はメンテナーのレビューと正式版への収録状況を追跡し、修正後に既存インデックスの分割結果を比較して、文書を再処理する必要があるか判断する。