[Bug] Default delimiter varies across 11 sites; parser_config.get defaults diverge per file type, producing different chunk counts for Engli

快速结论：该问题通常出现在 RAGFlow 对英文文本进行切分（chunking）时，默认分隔符在不同文件类型之间不一致，导致同一段英文文本在 docx、image、email 等类型下切出的 chunk 数量与 txt/markdown 不同。优先排查并统一 parser_config.delimiter 的默认值来源，尤其是缺失 ; 的默认集。

适用环境：RAGFlow v0.27.0（commit ec9c08d80，tag v0.27.0）。受影响文件包括 rag/app/naive.py、deepdoc/parser/txt_parser.py、rag/app/email.py、rag/app/book.py、rag/nlp/__init__.py，以及前端 web/src/components/chunk-method-dialog/use-default-parser-values.ts、web/src/pages/dataset/dataset-setting/index.tsx、web/src/components/delimiter-form-field.tsx。Issue 未记录操作系统、Python、CUDA、显卡或 PyTorch 版本。

最快修复方案：Issue 中已有合并的修复 PR #18638（Option A）：在 rag/nlp/delim.py 中新增单一常量 DEFAULT_DELIMITER = "\n!?;。；？"，并让 rag/app/naive.py 中 5 个主要解析器（docx、txt、markdown、image、naive_merge+images）以及 rag/app/email.py 的 parser_config.get("delimiter", ...) 调用点引用该常量；book.py 保持其自身默认值不变。

注意事项：该修复改变了 docx、image、email 三种文件类型的实际切分结果（补回 ;），属于已发布行为变更；book.py 的中文默认值被有意保留，不属于漂移。若你不在 v0.27.0 或未合并该 PR，此方案不一定直接适用。

问题场景

用户在 RAGFlow v0.27.0 中对英文文本执行解析/切分，尤其是在 docx、image、email 等类型的解析路径下。当用户已设置 parser_config 但未填写 delimiter 字段时，代码会落到 parser_config.get("delimiter", ...) 的默认值。由于各文件类型的默认值不同，同一段英文文本会得到不同的 parsed_dels，从而产生不同的 chunk 数量。

Issue 中给出的典型现象：一段类似 “The rain; the sun; the wind” 的英文段落，在缺失 ; 的默认值下会被解析成一个过大的 chunk，而不是按分号拆分。该 Issue 主要覆盖默认值的漂移，它明确不覆盖 #18552 中的 custom delimiter 周边 bug。

报错原文

[Bug] Default delimiter varies across 11 sites; parser_config.get defaults diverge per file type, producing different chunk counts for English text

The default delimiter for `parser_config.delimiter` is set in at least 11 places across the codebase, with 4 distinct values.
The shipped defaults diverge by callback site, and the divergence is large enough to produce a real chunk-count difference for the same input text.
There is no single source of truth.

原因分析

最可能的原因是默认分隔符在代码库中存在多个来源、多套取值，缺少单一事实来源（single source of truth）。Issue 将 11 处默认值归为三类：

UI 默认值（用户看到并提交的值）：3 处均为 '\n'，即 parsed_dels 为 ['\n']（1 个）。
Python 函数签名默认值：rag/nlp/__init__.py 中 3 个函数为 '\n。；！？'（5 个，仅中文标点）；deepdoc/parser/txt_parser.py 中 2 处为 '\n!?;。；！？'（8 个，完整集）。这些仅在未传入 parser_config 时触发，生产路径 rag/svr/task_executor.py:360 始终传入 parser_config，因此对真实用户不可达，但它们体现了维护者对默认值的不同心智模型。
parser_config.get 默认值（真正会交付给用户的）：txt、markdown 为 '\n!?;。；！？'（8 个，含 ;）；docx、image 为 '\n!?。；！？'（7 个，缺 ;）；email 为 '\n!?。；！？'（7 个，缺 ;）；book 为 '\n。；！？'（5 个，仅中文标点）。

因此，英文标点 ; 在 docx、image、email 三类文件类型中被遗漏，是用户可感知的直接症状。Issue 讨论倾向于认为除中文场景外，这些差异是非预期的漂移，最终选定 8 字符集 "\n!?;。；？" 作为统一默认值，并通过常量收敛调用点。

环境排查

确认 RAGFlow 版本是否为 v0.27.0（commit ec9c08d80）。
确认受影响代码文件中 parser_config.get("delimiter", ...) 的默认值是否仍为分散字面量。
确认是否存在 rag/nlp/delim.py 及常量 DEFAULT_DELIMITER（若已合并 PR #18638 则存在）。
确认 book.py 是否仍保留其自身默认值 '\n。；？'（有意保留，非漂移）。
确认用户提交的 parser_config 中是否确实缺少 delimiter 字段（若用户显式传值，则不会命中默认值）。
Issue 未提供 Python、CUDA、PyTorch、显卡或操作系统版本，这些不在已验证范围内，无需据此推断。

解决步骤

按 PR #18638（Option A）在 rag/nlp/delim.py 中新增常量 DEFAULT_DELIMITER = "\n!?;。；？"。
将 rag/app/naive.py 中 docx、txt、markdown、image 以及 naive_merge+images 这 5 个主解析器的 parser_config.get("delimiter", ...) 调用点改为引用该常量，而不是各自的字面量。
将 rag/app/email.py 中对应调用点改为引用同一常量。
rag/app/book.py 保持其原有默认值 '\n。；？' 不变——Issue 明确将其视为面向中文文本受众的有意选择，不属于漂移。
可优先尝试：在 test/unit_test/rag/nlp/test_default_delimiter_constant.py 中加入回归测试，包括常量值校验、以 AST 遍历方式校验 5 个主解析器调用点均引用常量（防止未来再次复制粘贴）、book.py 保持自身默认值的回归保护，以及行为测试：一段 250 字符、含 20 个分号的段落，在 chunk_token_num=8 下应产生 > 5 个 chunk（修复前为 1 个）。
运行 ruff check 与 ruff format --check 确认干净。

注意：Issue 讨论中提到，book.py 的中文默认值与 docx/image/email 是否补 ; 属于会改变已交付切分行为的语义层决策，需要一次性明确定值，而不是让它反向漂移。

验证方法

按 PR #18638 的说明，应用修复后：6 个回归测试应全部通过；ruff check 与 ruff format --check 无告警。行为层面可用一段 250 字符、含 20 个分号的英文段落，在 chunk_token_num=8 下解析，修复前只得到 1 个 chunk，修复后应得到多于 5 个 chunk。也可直接核对 docx、image、email 三类文件类型在未填写 delimiter 时解析出的 parsed_dels 是否已包含 ;。