表格数据切片：RAG中语义保真的结构化预处理方法

1. 项目概述：为什么表格数据切片不是“切一切”那么简单

你有没有试过把一份Excel销售报表、一张数据库导出的客户清单，或者一个CSV格式的医疗检测结果表，直接喂给RAG（检索增强生成）系统或企业级搜索服务？我试过——结果很典型：检索召回率低得离谱，生成回答张冠李戴，甚至把“2023年Q3华东区销售额”错配成“2022年华北区退货率”。问题不在模型，也不在向量库，而在于我们根本没处理好 输入数据的原始形态 。表格数据天然具备强结构、高密度、跨行跨列语义关联等特征，它和纯文本有本质区别：一段新闻稿可以按句子切分，但一张含12列、87行、带合并单元格和多级表头的财务明细表，你按行切？按列切？还是按“逻辑区块”切？切错了，语义就断了，检索就废了。

这就是“Chunking Tabular Data for RAG and Search Systems”这个标题背后的真实战场——它不是教你怎么调用 text_splitter ，而是直面一个被大量RAG教程刻意绕开的硬核问题： 如何让非自然语言的数据，在向量化之前，先完成一次语义保真的结构化预组织 。核心关键词“Chunking”在这里不是简单的字符截断，而是“语义单元识别+结构上下文锚定+检索意图对齐”的三重操作；“Tabular Data”特指具有行列坐标、字段类型、空值模式、表头层级等显式结构约束的数据；而“RAG and Search Systems”则框定了它的落地场景——必须服务于 高精度、低延迟、可解释的检索响应 ，不是为生成而切，是为“找得准”而切。适合谁？不是刚学LangChain的新手，而是已经跑通基础RAG pipeline、正卡在“为什么我的知识库搜不到关键数字”的算法工程师、搜索架构师、或负责将BI报表接入AI助手的数据产品负责人。这篇文章，就是我把过去三年在金融风控、医疗知识图谱、工业设备手册搜索三个场景中，踩过的27个坑、验证过的11种切法、以及最终沉淀出的一套可审计、可复现、可AB测试的表格切片方法论，原原本本掏出来给你看。

2. 核心思路拆解：为什么传统文本切分器在表格面前集体失效

2.1 传统切分逻辑的三大结构性失配

几乎所有主流RAG框架（LlamaIndex、LangChain、Haystack）默认的文本切分器，都基于自然语言的统计规律设计：按标点、按句子、按段落、按token数。但表格数据完全不遵循这套规则。我拿一份真实的银行对公客户交易流水表（含日期、交易类型、对手户名、金额、币种、摘要、渠道、状态8个字段，共1426行）做过对照实验，结果触目惊心：

• 按字符数切（512 token） ：一行完整交易记录平均占187 token，但切片会粗暴地把“2023-09-15|转账|XX科技有限公司|¥1,250,000.00|CNY|支付服务器采购款|网银|成功”从“支付服务器采购款|网银|成功”中间劈开。向量嵌入后，“采购款”和“服务器”失去关联，“网银”和“成功”被孤立，检索“服务器采购付款渠道”时，系统根本无法建立字段间映射。
• 按行切（每行一chunk） ：看似合理，但实际破坏了表头语义。第1行是表头“日期|交易类型|...”，第2行是首条数据。当切片为“日期|交易类型|对手户名|金额|币种|摘要|渠道|状态”，其向量表征的是“字段定义”，而非“业务事实”；而“2023-09-15|转账|XX科技有限公司|¥1,250,000.00|CNY|支付服务器采购款|网银|成功”表征的是“单笔事实”。两者在向量空间距离极远，导致检索时表头和数据无法协同召回。
• 按段落切（空行分隔） ：表格里哪来的空行？强行插入空行等于伪造结构，且无法处理合并单元格（如“华东大区”跨A1:A5）、冻结窗格、多级表头（“2023年业绩”下分“Q1”“Q2”子表头）等真实业务表必备元素。

提示：这不是参数调优问题，是范式错配。就像试图用菜刀切电路板——刀再快，也解决不了焊点定位问题。

2.2 表格切片的本质：从“文本分割”升维到“结构解析”

真正有效的表格切片，必须完成三个跃迁：
第一，从线性序列到二维坐标系 。文本是1D的，表格是2D的。切片决策必须同时考虑行索引（row_id）和列索引（col_id），例如“第3行第5列”的值“CNY”，其语义不仅取决于自身，更取决于第1行第5列的表头“币种”，以及同列其他行的值分布（是否全为CNY/USD/GBP）。因此，任何切片方案必须保留原始行列坐标信息，不能只存“内容字符串”。
第二，从内容裸露到结构锚定 。单纯存储“¥1,250,000.00”毫无意义，必须绑定其结构上下文：“该值位于[表名:对公流水][表头:金额][数据类型:decimal(18,2)][单位:人民币][所在行:2023-09-15交易][关联字段:对手户名为XX科技有限公司]”。这要求切片输出不仅是文本块，更是带Schema元数据的结构化对象。
第三，从静态切分到意图驱动 。不同搜索场景需要不同粒度：查“某客户所有交易”需按客户ID聚合行；查“某笔交易详情”需保留单行全字段；查“各币种交易总额”需提取“币种”+“金额”列组合。切片策略必须能根据下游检索Query的意图动态适配，而非一套规则走天下。

2.3 我们最终采用的混合分层策略：Table-Schema-Aware Chunking（TSAC）

基于上述认知，我们放弃“一刀切”的通用切分器，构建了四层递进式切片框架：

1. Schema层 ：解析原始表格，提取表名、字段名、字段类型（string/number/date/boolean）、空值率、唯一值分布、主键候选列。这是所有后续切片的元数据基石。
2. Block层 ：将表格按语义区块划分，而非物理行列。识别表头区（Header Block）、数据区（Data Block）、脚注区（Footer Block）、合并单元格组（Merged Cell Group）。例如，一个带“汇总”行的销售表，“汇总”行及其上方数据行构成一个独立Block。
3. Entity层 ：在Data Block内，按业务实体聚合行。若存在明确主键（如客户ID、订单号），则以主键值为单位聚合所有相关行；若无主键，则基于字段相似度（如“摘要”列文本聚类）或时间序列连续性（如连续7天的日报）进行软聚合。
4. Field-Context层 ：对每个Entity Block，生成两类切片：a) 全字段切片 （含所有列值，用于精确匹配）；b) 关键字段切片 （仅含高区分度字段，如ID+金额+日期，用于快速过滤）。所有切片均注入Schema元数据（字段名、类型、位置坐标）。

这套策略不是理论空想。在医疗知识库项目中，我们将一份含327个检验指标的《临床检验报告单》（PDF转表格，含多级表头和跨页合并单元格）用TSAC处理后，针对Query“患者肌酐值异常的可能病因”，检索准确率从41%提升至89%，且返回结果自动标注“肌酐值来源：血清生化检验-肾功能模块-第3行第2列”。

3. 核心细节解析与实操要点：从解析到嵌入的全链路陷阱

3.1 表格解析：OCR与格式转换的隐性损耗必须可控

原始表格来源五花八门：数据库导出CSV、Excel文件、PDF扫描件、网页HTML Table。不同来源的解析难度天差地别，而解析错误会100%传导至切片质量。

• CSV/TSV ：看似最简单，实则暗藏杀机。我遇到过最棘手的案例：一份用分号 ; 作分隔符的CSV，但“摘要”字段内含未转义的 ; （如“采购;服务器”），标准 csv.reader 直接将其拆成两列，导致整行字段错位。解决方案是强制指定 quotechar='"' 并启用 skipinitialspace=True ，但更稳妥的是用 pandas.read_csv 配合 engine='python' （虽慢但容错强），并预先扫描前100行做分隔符探测（ csv.Sniffer().sniff() ）。
• Excel (.xlsx/.xls) ： openpyxl 比 xlrd 支持新格式更好，但要注意： openpyxl 默认不读取公式计算结果，只读单元格原始值。若表格含 =SUM(C2:C10) ，你拿到的是字符串"=SUM(C2:C10)"而非数值。必须设置 data_only=True 。另外，合并单元格处理是重灾区—— openpyxl 的 merged_cells 属性返回的是坐标范围（如 B2:D4 ），需手动将该范围内所有单元格值统一设为左上角单元格值，并标记 is_merged=True 。
• PDF表格 ：这是最痛的环节。 tabula-py 对规整表格效果好，但遇到斜线表头、手写批注、阴影底纹就会崩溃； camelot 依赖OpenCV，对扫描件清晰度敏感； pdfplumber 最灵活，可获取每个字符的精确坐标，但需自己写逻辑判断行列边界。我们的经验是： 永远用 pdfplumber 做底层解析，再用规则引擎补全结构 。例如，先提取所有文本及其(x,y)坐标，按y坐标聚类出“行”，再按x坐标聚类出“列”，最后用“文本长度+字体大小+是否加粗”判断表头行。曾有一个PDF，表头“检验项目”和“结果”之间有2px空白， tabula 直接当成两列，而 pdfplumber 通过坐标分析，精准识别出这是同一行下的两个字段。

注意：无论哪种解析，必须做 结构校验 。解析后立即检查：1) 所有行的列数是否一致（允许表头行列数>数据行，但数据行间必须一致）；2) 合并单元格是否已展开（展开后行数应增加）；3) 数值型字段是否真能转为float/int（用 pd.to_numeric(..., errors='coerce') ，检查NaN率）。校验失败则中断流程，人工介入——宁可停机，不可污染向量库。

3.2 Schema推断：别信“自动识别”，要亲手验算

很多工具号称“自动推断Schema”，但实际业务表充满陷阱。例如，一个“电话号码”列，前1000行是11位手机号，第1001行是“待确认”，第1002行是“—”（长划线），自动推断会标为 string ，但实际业务中“待确认”和“—”是特殊状态码，需单独建枚举字段。我们的Schema推断流程强制包含三步：

1. 基础类型扫描 ：对每列采样1000行（或全量，若<1000），用正则匹配常见模式：
   • ^\d{4}-\d{2}-\d{2}$ → date
   • ^\d+(\.\d+)?$ → number （再细分 int / float ）
   • ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ → email
   • 其余 → string
2. 业务语义标注 ：人工配置字段映射表（YAML格式），例如：

   "联系电话": 
     type: string
     business_role: contact_phone
     null_values: ["-", "N/A", "待确认"]
   "交易状态":
     type: string
     business_role: status_enum
     enum_values: ["成功", "失败", "处理中", "已撤回"]
   

   此表是团队知识沉淀，每次新增表格必更新。
3. 统计验证 ：对 number 列计算 std （标准差），若接近0（如所有值都是100.00），则降级为 category ；对 string 列计算 nunique()/len() （唯一值占比），若>0.95且长度集中在10-15位，大概率是ID，标记为 id 。

这套流程让我们在金融反洗钱项目中，成功识别出一份“交易流水”表里隐藏的“风险等级”字段——它被命名为 flag_3 ，自动推断为 string ，但统计发现其值只有“A/B/C/D”四种，且与后续风控模型强相关，及时修正为 risk_level_enum 。

3.3 Block识别：用坐标和语义双引擎定位逻辑区块

Block识别是TSAC的核心难点。我们开发了一个轻量级规则引擎，结合物理坐标和文本语义：

• 表头Block识别 ：

  • 坐标规则：y坐标最小的1-3行，且该行所有单元格字体加粗、字号大于下一行。
  • 语义规则：该行文本包含“序号”、“ID”、“名称”、“日期”、“金额”等高频表头词，或符合“名词+名词”结构（如“客户姓名”、“交易时间”）。
  • 冲突解决：若坐标规则选出第1行，语义规则选出第1-2行（因第2行有“小计”“合计”等次级表头），则合并为Header Block。

• 数据Block识别 ：

  • 坐标规则：y坐标介于Header Block最大y和Footer Block最小y之间，且行高相近（标准差<行高均值10%）。
  • 语义规则：该行至少50%的单元格能被Schema中的 number 或 date 正则匹配。

• 合并单元格Group识别 ：

  • 坐标规则： openpyxl 的 merged_cells 返回的每个范围，即为一个Group。
  • 语义规则：若Group内所有单元格文本相同，且位于Header Block，则视为“跨列表头”；若位于Data Block且文本为“合计”“总计”，则视为“汇总行”，单独切为Footer Block。

实战中，我们处理一份带“部门汇总”和“个人明细”双层级的HR考勤表时，此引擎精准分离出：1个Header Block（含“部门”“姓名”“出勤天数”等），3个Department Group（每个Group含1行部门汇总+若干行个人明细），1个全局Footer Block（含“全公司总出勤率”）。没有这个分离，切片必然混淆部门级和员工级语义。

4. 实操过程与核心环节实现：从代码到生产环境的完整闭环

4.1 工具链选型：为什么我们弃用LangChain内置切分器，自研TSAC Pipeline

LangChain的 RecursiveCharacterTextSplitter 或 MarkdownHeaderTextSplitter ，设计初衷是处理文档，不是表格。它们缺乏：

• 行列坐标追踪能力；
• Schema元数据注入接口；
• Block级语义聚合逻辑；
• 对合并单元格、多级表头的原生支持。

我们最终选择 Pandas + OpenPyXL + PdfPlumber + 自研TSAC Core 的技术栈，原因如下：

整个Pipeline代码量仅320行（不含测试），但覆盖了95%的业务表格场景。关键不是代码多，而是每个模块都有明确的输入输出契约和失败熔断机制。

4.2 TSAC Pipeline核心代码实现（Python）

以下为 ChunkGenerator 核心逻辑，已脱敏并注释关键决策点：

from typing import List, Dict, Any, Optional
import pandas as pd

class ChunkGenerator:
    def __init__(self, schema: Dict[str, Any], block_data: pd.DataFrame, 
                 block_type: str = "data", table_name: str = "unknown"):
        """
        初始化切片器
        :param schema: 字段Schema字典，如 {"amount": {"type": "number", "business_role": "transaction_amount"}}
        :param block_data: 当前Block的DataFrame（已展开合并单元格）
        :param block_type: Block类型，"header"/"data"/"footer"
        :param table_name: 表名，用于元数据追溯
        """
        self.schema = schema
        self.block_data = block_data
        self.block_type = block_type
        self.table_name = table_name
    
    def generate_chunks(self) -> List[Dict[str, Any]]:
        """主切片方法，返回结构化切片列表"""
        chunks = []
        
        # Header Block：生成字段定义切片
        if self.block_type == "header":
            for col_idx, col_name in enumerate(self.block_data.columns):
                if col_name in self.schema:
                    chunk = {
                        "content": f"字段：{col_name} | 类型：{self.schema[col_name]['type']} | 业务角色：{self.schema[col_name].get('business_role', 'N/A')}",
                        "metadata": {
                            "table_name": self.table_name,
                            "block_type": "header",
                            "field_name": col_name,
                            "schema": self.schema[col_name],
                            "row_range": [0, 0],  # Header只占1行
                            "col_range": [col_idx, col_idx]
                        }
                    }
                    chunks.append(chunk)
            return chunks
        
        # Data Block：按Entity聚合切片
        if self.block_type == "data":
            # 步骤1：识别主键列（优先业务主键，其次唯一值率>0.99的string列）
            primary_key_col = self._identify_primary_key()
            
            # 步骤2：若找到主键，按主键值分组；否则按行切（兜底）
            if primary_key_col:
                grouped = self.block_data.groupby(primary_key_col, dropna=False)
                for pk_value, group_df in grouped:
                    # 生成全字段切片
                    full_content = self._build_full_content(group_df)
                    chunks.append(self._create_chunk(
                        content=full_content,
                        metadata={
                            "table_name": self.table_name,
                            "block_type": "data",
                            "entity_id": str(pk_value),
                            "chunk_type": "full_fields",
                            "row_count": len(group_df),
                            "primary_key_col": primary_key_col
                        }
                    ))
                    
                    # 生成关键字段切片（仅ID+金额+日期，用于快速过滤）
                    key_fields = self._extract_key_fields(group_df)
                    if key_fields:
                        chunks.append(self._create_chunk(
                            content=key_fields,
                            metadata={
                                "table_name": self.table_name,
                                "block_type": "data",
                                "entity_id": str(pk_value),
                                "chunk_type": "key_fields",
                                "row_count": len(group_df),
                                "primary_key_col": primary_key_col
                            }
                        ))
            else:
                # 兜底：逐行切片，但注入完整Schema元数据
                for idx, row in self.block_data.iterrows():
                    row_content = self._build_row_content(row)
                    chunks.append(self._create_chunk(
                        content=row_content,
                        metadata={
                            "table_name": self.table_name,
                            "block_type": "data",
                            "row_index": idx,
                            "chunk_type": "single_row",
                            "schema_snapshot": self.schema  # 快照式注入，避免后期变更影响
                        }
                    ))
            return chunks
        
        # Footer Block：生成汇总描述切片
        if self.block_type == "footer":
            footer_content = "汇总信息：" + " | ".join([f"{k}: {v}" for k, v in self.block_data.iloc[0].items()])
            return [self._create_chunk(
                content=footer_content,
                metadata={"table_name": self.table_name, "block_type": "footer"}
            )]
        
        return chunks
    
    def _identify_primary_key(self) -> Optional[str]:
        """识别主键列：业务主键 > 高唯一值率string列"""
        # 优先检查schema中标记的business_role为"id"的列
        for col_name, col_info in self.schema.items():
            if col_info.get("business_role") == "id":
                if col_name in self.block_data.columns:
                    return col_name
        
        # 其次检查唯一值率
        for col_name in self.block_data.columns:
            if self.block_data[col_name].dtype == "object":
                unique_ratio = self.block_data[col_name].nunique() / len(self.block_data)
                if unique_ratio > 0.99 and len(str(self.block_data[col_name].iloc[0])) > 5:
                    return col_name
        return None
    
    def _build_full_content(self, df: pd.DataFrame) -> str:
        """构建全字段内容字符串，格式：字段名: 值 | 字段名: 值 ..."""
        rows = []
        for _, row in df.iterrows():
            field_pairs = []
            for col_name in df.columns:
                val = row[col_name]
                # 处理NaN和特殊空值
                if pd.isna(val) or val in ["", "-", "N/A", "NULL"]:
                    val_str = "NULL"
                else:
                    val_str = str(val).strip()
                field_pairs.append(f"{col_name}: {val_str}")
            rows.append(" | ".join(field_pairs))
        return "\n".join(rows)
    
    def _create_chunk(self, content: str, metadata: Dict[str, Any]) -> Dict[str, Any]:
        """创建标准化切片字典"""
        return {
            "content": content[:2000],  # 防止超长，2000字符足够覆盖多数业务实体
            "metadata": metadata,
            "embedding_input": content[:2000]  # 向量嵌入的原始输入
        }

# 使用示例
# schema = load_schema("sales_report.yaml")
# block_data = parse_pdf_table("report.pdf", block_type="data")
# generator = ChunkGenerator(schema, block_data, "data", "sales_report_2023_q3")
# chunks = generator.generate_chunks()

这段代码的关键设计哲学是： 不追求“全自动”，而追求“可干预、可审计、可回溯” 。例如 _identify_primary_key 方法，它不会强行猜测，而是按明确优先级（业务标记 > 统计特征）决策； _create_chunk 中强制截断 content 到2000字符，是因为我们实测过，超过此长度的chunk在text-embedding-3-large模型上，embedding质量开始下降（余弦相似度波动增大），这是用真实AB测试数据换来的经验值，不是拍脑袋。

4.3 生产环境部署：如何让TSAC Pipeline扛住每天10万张表格

在金融客户项目中，我们需处理每日从核心系统导出的10万+张对账单（每张约200行）。单机跑TSAC肯定崩，我们采用“解析-切片-嵌入”三级异步流水线：

1. 解析层（Parser Worker） ：

   • 使用Celery + Redis，Worker进程专责解析。每个Worker启动时加载 openpyxl 和 pdfplumber ，预热解析引擎。
   • 对PDF文件，先用 pdfplumber 提取文本和坐标，缓存为 .pkl 文件（避免重复解析）；对Excel，直接用 openpyxl 流式读取，不加载全表到内存。
   • 解析失败的文件（如密码保护PDF、损坏Excel）自动转入 failed_parsing 队列，由监控告警，人工处理。

2. 切片层（Chunker Worker） ：

   • 接收解析后的DataFrame和Schema，运行TSAC Pipeline。
   • 关键优化： _build_full_content 方法中，对长文本字段（如“摘要”）做智能截断——不是简单取前100字符，而是用 jieba 分词后，保留前5个核心名词+动词（如“支付|服务器|采购|款|网银”），再拼接。实测使chunk语义密度提升40%，且长度稳定在300-800字符。

3. 嵌入层（Embedder Worker） ：

   • 使用 text-embedding-3-large API，但做了两点关键改造：
     a) Batch Embedding ：将100个chunk打包成一个API请求（官方支持max 2048 tokens/request），而非逐个调用，QPS从12提升至156；
     b) Fallback Cache ：对 content 做MD5哈希，查Redis缓存。相同内容（如固定表头、通用脚注）复用历史embedding，日均节省37% API调用。

整套流水线在4台16C32G服务器上，稳定支撑日均12.7万张表格处理，平均端到端延迟<8.2秒。最深的教训是： 不要在切片层做嵌入 。早期我们把 generate_chunks 和 embed 写在一起，导致一个Worker既CPU密集（切片）又IO密集（API调用），资源争抢严重。拆分成独立Worker后，CPU和IO资源可分别水平扩展，稳定性翻倍。

5. 常见问题与排查技巧实录：那些文档里绝不会写的血泪经验

5.1 “为什么我的表格切片后，检索总是召回无关行？”——坐标元数据丢失的隐形杀手

现象 ：一份含“客户ID”“产品名称”“购买日期”“金额”的销售表，Query“张三购买的iPhone价格”，系统召回了“李四购买的MacBook价格”。

根因排查 ：我们抓取了召回的chunk内容，发现是 {"content": "客户ID: 1002 | 产品名称: MacBook Pro | 购买日期: 2023-08-10 | 金额: ¥15,999.00", "metadata": {...}} 。问题来了——这个chunk的 metadata 里， customer_id 字段是空的！原来，在 _build_full_content 中，我们用了 str(row[col_name]) ，而 row["客户ID"] 是 numpy.int64 类型， str() 后变成 "1002" ，但 metadata 中 "customer_id" 键是硬编码的，没从 row 里动态取值。

解决方案 ：在 _create_chunk 前，强制从 row 中提取关键字段注入 metadata ：

# 在 _create_chunk 调用前
metadata["customer_id"] = str(row.get("客户ID", ""))  # 动态提取，非硬编码
metadata["product_name"] = str(row.get("产品名称", ""))

实操心得：所有 metadata 字段必须来自 row 或 df 的实时计算，绝不硬编码。我们后来加了一条CI检查： grep -r "metadata.*:" code/ | grep -v "row\[" ，凡匹配到即报错。这条规则拦截了73%的元数据错误。

5.2 “合并单元格切片后，为什么表头和数据对不上？”——展开逻辑的魔鬼细节

现象 ：一份带“华东大区”合并单元格（覆盖A1:A5）的销售表，切片后，“华东大区”只出现在第1行chunk里，第2-5行chunk的 metadata 中 region 字段为空。

根因 ： openpyxl 的 merged_cells 返回 <MergeCell A1:A5> ，但我们只把 ws['A1'].value 赋给了第1行，没同步到第2-5行。

正确展开逻辑 （OpenPyXL）：

# 获取所有合并单元格范围
merged_ranges = list(ws.merged_cells.ranges)
for merged_cell in merged_ranges:
    # 获取合并区域左上角值
    top_left_cell = ws.cell(merged_cell.min_row, merged_cell.min_col)
    value = top_left_cell.value
    
    # 将值赋给合并区域内所有单元格（注意：openpyxl中cell是1-indexed）
    for row in range(merged_cell.min_row, merged_cell.max_row + 1):
        for col in range(merged_cell.min_col, merged_cell.max_col + 1):
            # 跳过左上角（已存在），只设其他单元格
            if not (row == merged_cell.min_row and col == merged_cell.min_col):
                ws.cell(row, col).value = value

关键点 ：必须遍历 min_row 到 max_row ， min_col 到 max_col ，且 cell 索引从1开始（不是0）。我们曾因用 range(0,5) 导致越界，静默失败。

5.3 “为什么PDF表格解析后，列顺序完全乱了？”——坐标聚类的阈值陷阱

现象 ： pdfplumber 解析出的文本块，x坐标是 [120.5, 121.2, 120.8, 245.3, 246.1...] ，我们按x坐标聚类分列，结果把本该同列的“120.5”和“121.2”分到不同列，因为聚类阈值设成了5.0（认为>5.0才属新列）。

真相 ：这是扫描件分辨率问题。原PDF是300dpi，扫描后变成150dpi，字符x坐标偏移放大。实测发现，同列文本x坐标差值的95%分位数是2.3，不是5.0。

排查技巧 ：

1. 先用 pdfplumber 打开PDF， page.extract_words() 获取所有单词及其 x0 ；
2. 计算所有 x0 的差值分布： np.diff(np.sort(x0_list)) ；
3. 取 np.percentile(diff_list, 95) 作为列间距阈值。
   我们为此写了个 calibrate_column_threshold.py 脚本，每次新PDF类型上线前必跑，阈值从不硬编码。

5.4 “TSAC切片后，向量检索准确率还是不高，怎么办？”——超越切片的系统级调优

切片只是起点，准确率还受三重影响：

我们最终的黄金组合是：TSAC切片 + 数值标准化Embedding + Metadata Filter检索 + Cross-Encoder重排。这套组合在医疗问答场景中，将“某药物禁忌症”的答案准确率从68%推高到92%。

6. 实战效果对比与业务价值：从技术指标到老板关心的ROI

在交付给某大型保险公司的“保全业务知识库”项目中，我们用TSAC替代原有简单按行切分方案，效果不是“有所提升”，而是质变：