Embedding 文本切块时怎么避免把一个事实拆开

Embedding 切块最容易踩的坑，是按固定字符数一刀切：前半段留下“订单满 99 元”，后半段才出现“会员日除外”，向量检索命中了价格，却丢了限制条件。更稳妥的做法是先识别事实单元，把主体、条件、动作与结果、例外尽量放进同一个 chunk；只有单元超过模型输入限制时，才在句子或从句边界拆分，并用适量 overlap 衔接。

切分边界应由语义结构决定，固定长度只是容量约束。每个 chunk 还要保留标题路径、原文位置和事实类型，否则即使召回了正确片段，也很难恢复它适用的条件。

先按语义单元确定切分边界

先把文档解析成标题、段落、列表项和表格行，再判断每个单元是否表达了一个可独立引用的事实。一个完整事实通常至少包含主体和结论；如果“只有在”“除非”“不适用于”等条件另起一段，条件也应被视为事实的一部分。

下面的伪代码展示一个最小判断思路。它不是通用分词器，重点是把“结构边界优先”落实成可检查的规则：

# 先按结构单元收集文本，避免把条件句单独切走
units = parse_markdown_sections(document)
chunks = []

for unit in units:
    # 标题路径和事实正文一起保存，便于召回后解释来源
    text = unit.heading_path + "\n" + unit.body
    if token_count(text) 

超长事实怎么拆才不会丢掉条件

固定长度切分有一个合理用途：控制 embedding 模型的输入上限和索引成本。但它不应直接切断句子。Microsoft 的 Azure AI Search 文档把固定长度、按句子或结构切分、语义切分列为不同策略，并建议用 overlap 保留相邻片段的连续性；具体比例仍要根据文档形态和查询集评估。

实践中可以先固定 embedding 模型和问题集，设置一组较小的 overlap 基线。如果一个事实由“定义—条件—例外”组成，先尝试让它整体进入 chunk；实在过长时，将定义与条件放在同一片段，并把例外的关键短语重复到下一片段。不要为了保险把整段背景复制到每个 chunk，否则重复文本会挤占召回后的上下文预算。

中文资料还要注意列表和表格：表头是字段语义，单独的数值行通常不可独立理解。与其把表格按字符截断，不如把“字段名 + 当前行 + 适用条件”组成一个记录，再为它附上章节路径。

让 chunk 在召回时仍能追溯事实来源

向量只是文本的检索表示，不是事实的完整档案。建议每条记录至少保存 chunk_text、document_id、heading_path、start_offset、fact_type 和 embedding。这样召回后可以回到原文核对条件，也能在重排时优先保留同一事实链的定义和例外。

例如查询“会员日能否退款”时，单独命中“支持退款”的 chunk 并不够；重排阶段还应把同章节的会员日限制纳入上下文。可用下面的清单判断切块是否完成：

• 命中片段是否包含事实主体，而不是只有代词或半句条件？
• 限制条件、例外和适用时间是否能通过路径或相邻 chunk 找回？
• 回答上下文是否保留原文位置，方便人工复核？

用固定问题集验证事实是否被拆散

不要只看 chunk 数量或向量相似度。准备三类问题：直接询问事实主体的问题、同时包含条件的问题、需要跨段拼接的问题。每次只改变切分策略，记录答案所需片段是否被召回、相邻候选的公共文本比例、上下文长度和原文可追溯性。

如果低 overlap 组丢失了条件，再增加一档；如果高 overlap 组只是返回更多相邻片段，却没有提高问题覆盖，就应回头修正文档结构或标题，而不是继续加重叠。切块参数应该服务于事实完整性和可验证的检索结果。

常见问题

chunk 越大，事实就越完整吗？

不一定。过大的 chunk 会混入多个主题，向量表示被稀释，召回后也更难定位答案。优先保持一个语义单元完整，再用问题集选择容量。

overlap 越大越安全吗？

不一定。它能减少边界丢句，却会增加重复文本、索引量和上下文长度。应比较新增事实覆盖，而不是只看重叠比例。

为什么一定要保存 heading_path？

因为同一句结论可能在不同章节有不同条件。标题路径能帮助重排、回答和人工复核恢复它的适用范围。

判断切块是否合格，可以记住一句话：先让事实完整，再让长度合适，最后让来源可追溯。这样调 embedding 和 RAG 参数时，问题才不会被错误地归因给模型本身。