文档为什么要做语义切分，chunk 大小怎样确定？

题型：追问 · 不要给固定数字，要给选择依据和验证方式。

建议回答

chunk 太大时主题混杂、向量表达被稀释并浪费上下文；太小时信息不完整、命中后难以回答，还会增加向量数量和存储成本。我的策略是先按标题、段落、列表、表格和页码等结构边界切分，再根据 Token 上限做合并或二次拆分，并保留适量 overlap、父子关系和来源元数据。

大小要结合文档类型和问题粒度确定。例如规章条款适合按条款，维修手册适合保留步骤与前置条件，表格需要表头和行语义一起保留。最终通过 Recall@K、引用完整性、平均上下文 Token 和入库规模在业务评估集上选择。

进一步追问

• PDF 跨页段落、表格和图片 OCR 怎么处理？
• 父子 chunk 如何兼顾召回粒度与回答上下文？
• 文档更新后怎样稳定定位变化的 chunk？

易错点

• overlap 不是越大越好，会造成重复召回。
• 仅按字符数切分容易破坏中文语义、表格和编号结构。