RAG 文档切片里的 Markdown 表格为什么会失真：用 AST 保留结构化上下文

RAG 知识库里最容易被低估的一类数据是 Markdown 表格。把文档按换行或固定字符数直接切开后，表头可能落在上一块，数据行落在下一块，向量检索虽然能召回“退款时限”几个词，模型却不知道这些数字对应哪个渠道。遇到这种情况，问题通常不在模型，而在切片已经丢了结构关系。

表格切片失真的核心原因是把结构化的表格当成了普通纯文本做硬切割，丢失了表头和行数据的绑定关系，用 Markdown AST 先识别节点再做切片，给每段拆分后的行都补全表头、表格标题和来源锚点，就能解决大部分召回后答案错位的问题。

问题现场：为什么召回了关键词，答案仍然对不上

假设知识库里有一张“渠道退款规则”表：

如果切片恰好从第二行开始，召回文本可能只剩“账户中心、即时、仅限可用余额”。用户问“余额退款多久到账”时，模型也许能猜出答案，但它无法确认这行属于哪张表，更无法给出稳定的来源位置。换一份文档，猜测就可能变成错误结论。

先定位切片边界：表格是一个结构节点，不是一堆换行

处理 Markdown 时，先把标题、段落、列表和表格识别成 AST 节点，再决定如何切分。表格节点至少需要保存四类信息：

这里的原则是“先保护语义，再控制长度”。普通段落可以按 token 窗口做滑动切片，表格则先按完整行分组；只有单行本身超过窗口时，才进入单元格级降级路径。

用 Markdown AST 给每一行补回表头与来源

下面的示例使用 Python 的 Markdown AST 思路表达切片逻辑。实际项目可以把 parse_table_rows 接到现有 Markdown 解析器，关键不在库名，而在输出结果必须保留“表头 + 当前行 + 来源”这三个部分。

def build_table_chunks(title, table_title, headers, rows, source, max_chars=520):
    prefix = f"文档：{title}\n表格：{table_title}\n表头：" + " | ".join(headers)
    chunks = []
    current = []
    current_size = len(prefix)

    for row_no, row in enumerate(rows, start=1):
        line = "行{}：".format(row_no) + " | ".join(row)
        if current and current_size + len(line) + len(source) > max_chars:
            chunks.append(prefix + "\n" + "\n".join(current) + "\n来源：" + source)
            current = []
            current_size = len(prefix)
        current.append(line)
        current_size += len(line) + 1

    if current:
        chunks.append(prefix + "\n" + "\n".join(current) + "\n来源：" + source)
    return chunks

每个块都重复表头，看起来会增加少量文本，但这部分重复是有意的。检索阶段召回的是独立文本块，不应该假设模型还能同时拿到它的前一个兄弟节点。source 可以是文件路径、章节编号或网页锚点，不建议只写一个无法定位的文档名称。

表头继承不是复制整篇文档

继承范围要控制在表格自身：文档标题、表格标题和表头可以放进每个块，上一段普通正文不应无限向后拼接。上下文过宽会稀释向量表示，过窄又会让字段失去含义。工程上可以把文档标题和表格标题作为稳定前缀，再按实际召回效果调数据行数量。

长表格怎么处理：先保行，再处理超长单元格

长表格最常见的错误是为了凑固定长度，把一行拆成上下两块。建议按下面的顺序处理：

1. 计算“表头前缀 + 一整行”的长度，能放入当前块就继续追加。
2. 放不下时结束当前块，从下一行开始新块，并再次附加同一份表头。
3. 如果单行本身超过上限，优先保留关键字段和来源，再按单元格拆分，并加上“同一行”的标识。
4. 记录原始行号，方便检索结果回链和人工复核。

不要把“超过窗口”直接当作截断理由。产品说明、价格规则和权限矩阵里，长单元格往往包含限制条件；截掉后半句，答案可能只剩一个看似合理但不完整的数字。

验收切片质量：用四个问题代替只看相似度

切片完成后，可以用一组固定问句检查结构是否还在。每个问题都要能追溯到明确的表格行：

OpenAI Vector Stores API 文档里把自动切片默认值描述为 800 token、400 token overlap，并允许配置静态切片。这个参数只规定长度策略，不会替你理解 Markdown 表格的表头继承关系，所以自定义摄取层仍然需要做结构化处理。

常见问题

Markdown 表格一定要单独做一种切片器吗？

不一定要另起一套系统，但摄取流程至少要识别表格节点，并保证表头、数据行和来源信息不会被普通换行切断。

每个切片都重复表头，会不会浪费向量空间？

会增加少量重复文本，但通常比丢失字段语义更可控。可以压缩表头写法，或只保留表格标题和字段名，不建议为了省字符彻底删除。

表格切片的长度应该设置多少？

没有脱离模型和语料的固定答案。先保证完整行，再用真实问题集比较召回率、答案准确性和上下文长度；长度参数应服从语义边界，而不是反过来切断语义。

只做向量检索，不做关键词检索可以吗？

表格里的编号、版本号、字段名和短数字很适合关键词或混合检索。对这类精确值，单靠向量相似度容易召回相近但不相同的行。

把表格当成结构数据，RAG 才能稳定回答

Markdown 表格的价值不只在视觉排版，它还携带字段和值之间的关系。先用 AST 识别表格，再按完整行生成带表头和来源的独立块，最后用字段归属、行完整性和来源回溯做验收，切片才真正服务于问答。固定窗口仍然有用，但它应该负责控制体积，而不是决定哪里可以切断语义。