医学论文与法律条文切块

这道题其实问的是，在专业领域里，怎么在保留语义完整性和控制检索成本之间做取舍。核心原则很简单：检索出来的chunk要能独立回答用户的问题，而不是让模型去拼图。

先说通用的[[分块]]策略。最常见的是固定长度，具体长度作为候选变量；它的优点是快，但专业领域不能直接照搬，因为它很容易把一句话、一个公式或者一个条款拦腰截断，导致检索出来的信息不完整。真正落地时，我会根据文档结构来选。如果文档层级清晰，比如技术手册或者法律条文，我会用结构感知分块，直接按Markdown标题、或者按"第X条"这种自然边界切，这样每个chunk本身就是一个完整的语义单元。如果文档内容比较混杂，比如一篇综述里既有方法又有结论，主题经常跳，那我会用语义分块，靠[[Embedding]]相似度检测主题边界，在内容变化大的地方断开。

但说实话，实际项目里很少只用一种策略，通常是混合的。比如先按标题切出大段落，再在段落内部用语义分块做二次切分，这样既保留了宏观结构，又照顾了微观主题变化。

具体到专业领域，处理方式要更细致。拿法律条文来说，核心就是绝对不能截断条款。我会以"第X条"为硬边界，每一条作为一个独立chunk，同时把所属的章节标题、上下文也带进去，比如"《民法典》第三编 合同 第XXX条"，这样检索时才能准确匹配。医学文献就不同了，它通常是IMRAD结构，也就是引言、方法、结果、讨论，我会按这个结构切，每个部分单独成块。但表格要特殊处理，因为表格里的信息密度很高，我会把表头加一行关键数据作为一个独立chunk，否则模型很难理解表格里的内容。

这里有个常见的坑：chunk边界上的关键信息很容易丢失。所以我会把零重叠、短窗口和较长窗口放进同一评测集，检查前后块共享边界内容是否真的改善证据完整性，这样就算一句关键描述刚好在边界上，两个chunk里都能找到它。

再说chunk大小。chunk大小没有通用范围，要同时看文档结构、Embedding输入限制、查询类型与LLM上下文预算，并在同一评测集上比较多组候选。上线前我会做召回测试，拿真实用户query去跑，看top-k里能不能覆盖答案来源，如果召回率低，就调小chunk或者加大重叠。

所以整体上，我更倾向把chunk策略看成检索质量的基础设施，它不是一次设定就完事的，需要根据文档类型、查询场景和模型能力持续调优。如果面试官想问，我可以再聊聊怎么用[[Rerank]]来提升召回后的排序质量，或者怎么评估chunk策略的好坏。