背景：基于一次从“21 种通用分块策略”出发，尝试抽象一套可通用于不同文档/领域的 RAG 文本分块体系的探索。实践后结论：21 条更像“策略原型 (Archetypes)”的知识清单，而非可以直接普适落地的齐全方法集。
1. 初始目标
希望用一个“通用策略列表（21 种）”来覆盖企业知识库、技术文档、合同、小说、日志、表格、API 说明、多模态等不同场景的 RAG 分块需求，并构建：
- 可配置的策略管线 (Pipeline)
- 多层级（快速上线 → 结构增强 → 语义增强 → 智能生成）
- 指标闭环与回退机制
初始假设
- 只要枚举足够多的“分块方法”，即可通过排序或组合达到普适性。
- 所有文档类型都可以先走“通用策略 → 组装 plan → 部署”。
- 复杂策略（语义/LLM）只是在成本上的增强，并不改变结构抽象。
结论：以上假设部分失效，尤其是第 1、2 点。
2. 21 条策略列表（原始“概念层”）
- 行 (Naive)
- 固定窗口
- 滑动窗口
- 句子
- 段落
- 页面
- 结构化（HTML/JSON/日志/CSV）
- 标题/小节结构
- 关键词边界
- 实体 (NER)
- Token 长度控制
- 主题聚类
- 表格感知
- 内容类型感知（代码/列表/引用）
- 上下文增强（摘要/注释）
- 语义相似归并
- 递归分块（分层长度控制）
- 动态嵌入聚合
- LLM Agent 自主切分
- 分层（章节→节→段）
- 模态感知（文字/图片/表格）
(H) Hybrid 混合编排
发现：它们描述的是“手段类型”而不是“直接可复用的策略实现”。
3. 分层与演进（提炼：依赖维度）
| 层级 | 描述 | 示例原型 | 价值 | 局限 |
|---|---|---|---|---|
| Tier0 纯规则 | 无外部模型 | 行/窗口/句/段/关键词/递归 | 快速上线 | 不理解语义/边界粗糙 |
| Tier1 结构感知 | 解析格式/布局 | 标题/表格/内容类型/层级 | 保留结构语义 | 需解析器 & 领域适配 |
| Tier2 语义增强 | 嵌入/NER/聚类 | 实体/主题/语义合并/动态聚合 | 减少碎片 & 语义集中 | 成本↑ 调参复杂 |
| Tier3 生成/智能 | LLM / 多模态 | 摘要增强/Agent/多模态 | 自适应 & 高压缩 | 成本+不确定性 |
现实：领域策略不是单纯“进入更高层”，而是“在一个层内插入特化规则”。
4. 已实际落地的部分 (本次尝试结果)
已实现的最小可用模块：langchain4j-spring-ai-rag-chunk (Tier0)。
实现的 8 个策略/控制器：
- LINE (
LineChunker) - FIXED_WINDOW (
FixedWindowChunker) - SLIDING_WINDOW (
SlidingWindowChunker) - SENTENCE (
SentenceChunker) - PARAGRAPH (
ParagraphChunker) - KEYWORD (
KeywordChunker) - PAGE (
PageChunker) - RECURSIVE_LENGTH (
RecursiveLengthController)
配套：模型类（RawDocument/Chunk/ChunkContext）、Pipeline、若干测试用例。
未进入实现（但原先规划有）：章节结构解析、短段合并、对话聚合、结构/表格解析、语义/NER、Agent 等。
5. 遭遇的核心问题 & 认知更新
| 问题 | 表现 | 认知更新 |
|---|---|---|
| “通用列表”难直接复用 | 尝试将小说、合同、API 用同一组策略顺序描述时需大量条件分支 | 需要“原型 + 领域特化”两层抽象 |
| 策略粒度不一致 | 有的描述“切分方式”，有的是“后处理”或“合并规则” | 需要拆分：边界检测 / 合并 / 后处理 / 长度控制 四类角色 |
| 配置爆炸 | 21+ 策略平铺会形成过多组合 | 应由 Planner 决定最小可行链条，且 domain override |
| 语义策略门槛 | 嵌入/NER 引入后：缓存、批量、阈值调参复杂 | 不应与基础规则耦合，应延迟加载能力 (capability gating) |
| LLM 参与不稳定 | Agent 切分设计 JSON 容错、成本评估困难 | 仅在结构置信度低 + 长文 + 预算允许时触发 |
| 通用句法欠缺 | 中文长段/对话结构远超简单标点策略 | 需要针对对话/章节/场景的特化模块 |
6. 放弃“单层完全通用”后的新模型
新的认知方式：
- 21 条 = 策略原型分类表 (Strategy Archetype Catalog)
- 领域特化 (Specialization) = 原型 + 领域知识（正则 / 触发词 / 词典 / 结构标记）
- 执行链 (Plan) = 按文档 profile 选择最小必要原型 + 领域特化
- 能力门控 (Capability Gating) = tokenizer / embedding / ner / llm 可选注入
- 质量闭环 = 指标 (长度/碎片/重复/实体完整) + 回退 (fallback)
7. 示例：网络玄幻小说的“特化”映射
| 原型 | 特化策略 | 触发/规则 | 目的 |
|---|---|---|---|
| 标题结构 (#8) | CHAPTER_HEADING | ^第[一二三四五六七八九十百千万0-9]+章 | 章节层级根 |
| 段落 (#5) | SHORT_PARAGRAPH_MERGE | 段长 < 阈值 → 合并邻近 | 降低碎片 |
| 句子 (#4) | DIALOGUE_MERGE | 连续引号行聚合 (最大字数/轮次) | 保持对白语境 |
| 语义合并 (#16) | SCENE_BOUNDARY | 触发词 + 相似度跌落 | 场景组织 |
| 上下文增强 (#15) | SCENE_SUMMARY | LLM 摘要 | 快速检索二跳 |
| 递归 (#17) | LENGTH_CONTROLLER | 超过 hardMax 继续切 | 保持成本 |
当前我们仅实现了可用于“临时替代”的：SENTENCE + PARAGRAPH + FIXED_WINDOW + RECURSIVE_LENGTH。
8. 为什么“继续堆通用策略”性价比低
- 新增策略 → 需要语义/格式特征 → 又需领域判断 → 再写条件分支 → 回退复杂度指数增长。
- 真正的问题是“领域结构差异”，不是“策略不够多”。
- 成本最高的是错误切分（碎片化、跨语义），而不是“还少几个策略名字”。
9. 精简的基础使用建议（当前能力）
| 文档类型 | 推荐 Tier0 组合 | 备注 |
|---|---|---|
| 小说（临时） | SENTENCE → FIXED_WINDOW → RECURSIVE_LENGTH | 等待章节/对白特化补齐 |
| FAQ/短问答 | PARAGRAPH 或 LINE → RECURSIVE_LENGTH | 去除空行 + 过滤无效行 |
| 长说明文 | PARAGRAPH → SENTENCE(大粒度合并) → FIXED_WINDOW | 句子 joinThreshold 提高 |
| 粗糙日志 | LINE → FIXED_WINDOW | 行即事件（后续可结构化） |
| 含页 PDF 文本 | PAGE → PARAGRAPH → FIXED_WINDOW | 需要保持页码引用 |
10. 暂停本次“通用覆盖”尝试的理由
- 已验证：没有“无需特化即可表现优秀”的一条龙方案。
- 基础模块可稳定支撑进一步特化开发；无需先把所有原型写成半成品。
- 继续抽象会引入过多“名义策略”而未提升实际可用性。
决策：终止“21 条直接落地通用”路径，转向“原型 + 领域特化 + 增量演进”。
11. 经验教训 & 可复用结论
| 经验 | 结论 | 建议 |
|---|---|---|
| 不加区分地枚举策略 | 快速变成策略清单墙纸 | 先确定领域用例 → 逆推需要的原型 |
| 过早引入高级策略 | 成本高 & 价值不确定 | 先验证结构保持 & 长度分布 |
| 忽视元数据结构 | 后面难加层级/回退 | 早期就为 ChunkMetadata 预留扩展键 |
| 混合语义+结构逻辑 | 代码耦合难测试 | 通过 capability & planner 解耦 |
| 无指标无法判断改进 | 主观分块优劣难量化 | 最少收集：avg_len / short_ratio / overlap_waste |
12. 后续可选方向（若恢复推进）
优先层级：
- 特化：ChapterHeadingChunker, DialogueMergeChunker, ShortParagraphMergeChunker
- 元数据增强：strategy_version, plan_signature, specialization 字段
- Metrics：avg_len, max_len, short_ratio, redundancy_ratio
- 结构层 (Tier1)：Heading / Table（技术文档或合同再选）
- 语义层 (Tier2)：SceneBoundary (novel) / ClauseNER (contract)
- 生成层 (Tier3)：场景摘要 / 条款释义（按 ROI 决策）
13. 若完全停留在 Tier0 的风险
| 风险 | 影响 | 补救（最小特化） |
|---|---|---|
| 小说对白碎片化 | QA 指代断裂 | 对话聚合 |
| 合同条款被截断 | 法务问答失准 | 条款正则切 |
| 表格被切坏 | 数值语境丢失 | 表格整体抽取 |
| 主题漂移块 | 召回噪声 | 短段合并 + 语义合并 |
14. 结论（One-Liner）
“通用 21 策略”不是最终实现蓝图，而是“分块手段原型目录”；有效落地必须通过“领域特化 + 渐进增强 + 指标闭环”路线推进，本次尝试已完成 Tier0 基础并明确转向新的认知模型。
15. 附：本次实现产物清单
| 模块 | 路径 | 内容 |
|---|---|---|
| Tier0 代码 | langchain4j-spring-ai-rag-chunk | 8 个基础策略 + Pipeline + 测试 |
| 文档 v1.0/v1.1 | RAG分块策略实现.md / RAG分块策略实现规划 (rev) | 原型 + 分层 + v1.1 补充 |
| 当前总结 | 本文件 | 尝试回顾与方向调整 |
16. 推荐的“重新出发”最小脚本 (示例)
ChunkPipeline pipeline = ChunkPipeline.builder()
.add(ParagraphChunker.of(180))
.add(FixedWindowChunker.of(650, 90))
.add(new RecursiveLengthController(800, 650, 90))
.build();
作为小说/长说明文的过渡方案；再按需要逐步替换/插入特化策略。
17. 结束语
尝试终止 ≠ 失败，而是完成了“从模糊列举 → 可执行骨架 → 明确边界”的学习闭环。后续若再推进，可直接以“领域特化任务”切入，避免重新陷入泛化抽象泥潭。
扫一扫
7038
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
