1. 表格数据进 RAG为什么切片就废了先聊一个我踩过好几次的坑。做 RAG检索增强生成知识库大家第一步通常都是拿 PDF、Markdown 或者网页文档开刀文本一切、嵌入、建索引流程很顺。但等到想把 CSV、Excel 或者数据库里的结构化数据也塞进知识库时你会发现之前的通用分块招数完全失灵——不是检索效果差而是检索回来的内容根本没法看。举个例子你有一张用户订单表里面是订单号、用户名、商品名称、金额、下单时间。如果你按文本的方式把它切成一个个固定长度的小块一个 chunk 里可能只有半行记录或者把第一行的后半截和第二行的前半截裹在一起。用户问上个月金额最高的前五笔订单有哪些检索系统召回的是几个残缺的片段大模型看了也拼不出一张完整的表只能硬编一个答案给你。这事的根源在于表格数据的语义是躺在表头 行 列 单元格的结构关系里的不像连续文本那样可以顺着读。顶多靠上下句承接住意思。把表格当作纯文本分块等于先把数据的骨架拆散了再指望模型能还原出一张完整的表这从原理上就走不通。所以做表格与数据库导入时真正要解决的不是怎么加载文件而是怎么把结构信息无损地转递给嵌入模型和 LLM。这一篇我就拿 CSV、Excel 与 LlamaHub 连库实战来拆解这件事。文章不会讲太多名词重点是可落地的处理流程和我在项目里反复调过的参数、踩过的坑适合正在搭 RAG 知识库、尤其是知识库里需要包含业务表格数据的开发者参考。2. CSV 导入的隐藏成本编码、逗号与行基块设计CSV 看着最简单但真做进 RAG 管道的细节比想象中多。我在生产环境里换过三种导入方式最后稳定下来的方案是从纯文本解析升级到结构感知解析。2.1 pandas 读取时的两个约定UTF-8 与 dtype先用 pandas 读取 CSV这是最快的方式。但两个地方必须提前处理否则后面全是坑。第一个是编码。国内业务系统导出的 CSV十有七八是 GBK 或 GB18030 编码直接pd.read_csv(data.csv)大概率给你抛一个UnicodeDecodeError。稳妥的做法是先用二进制方式探测编码import chardet import pandas as pd with open(data.csv, rb) as f: raw f.read(10000) result chardet.detect(raw) df pd.read_csv(data.csv, encodingresult[encoding], dtypestr)第二处容易掉链子的是数字列。pandas 默认会把订单号 001这种字符串读成整数 1等你要拿原始值去 match 数据库里的记录时对不上排查半天才发现是类型转换的问题。所以一律用dtypestr读进来把格式化的权利留给自己等生成文本块时再按需转换。还有一个经常被忽略的CSV 单元格里的内容可能自带逗号和换行。不要自己用split(,)去解析会直接拆错字段pandas 和 Python 内置的csv模块都处理过引号转义和换行别重复造轮子。2.2 行基块row-based chunk的正确构造方式读完 DataFrame 后关键问题是怎么把它变成嵌入友好的文档块我试过整张表塞进一个 Document、一行塞一个 Document、几行合并塞一个 Document三种方式。实际验证下来整表一个 Document 太粗糙表一大检索命中率下降得很明显一次召回你拿到的是整张两万行的表的文本上下文塞不下一行一个 Document 太琐碎既没有上下文又容易和其他行语义重合同一个字段值在每行都会出现造成向量空间里大量冗余按业务行数组合比如 10~20 行一个块相对中庸检索时能召回一小段连续记录LLM 能从中归纳出模式又不会撑爆上下文。我自己常用的参数是row_group_size15左右同时把表头信息作为前缀写进每个块里。块内容大概长这样表名: user_orders 字段: 订单号, 用户名, 商品名称, 金额, 下单时间 数据: 12345, alice, 无线鼠标, 89.00, 2025-01-12 12346, bob, 机械键盘, 399.00, 2025-01-13 ...表头重复出现在每个块里会牺牲一点嵌入的存储空间但换来的是每个块在向量空间中自包含检索时即使只命中一个块LLM 也知道每个数字是什么意思。这一点在标题里写表格而不是文本时尤其关键——表头就是表格的语义锚点拆了锚点块内容就是无意义的数字串。提示如果你用的是 LlamaIndex可以直接继承CSVReader或PandasCSVReader然后定制row_group_size。这一步不要偷懒用默认的按行拆分。2.3 空值、脏数据与类型标记的预处理CSV 的脏数据分布比你想的严重。我在一个客户的数据文件里见过空值字段、-占位、全角逗号混入、金额列出现待确认这种文本。如果不洗数据后面检索到的块里会有大量无意义内容LLM 还可能把-当成减号去做计算。清洗逻辑我通常写在 Document 生成前空值统一填N/A不要在块里出现裸的空位全角逗号、全角括号统一转半角日期统一格式为YYYY-MM-DD方便后续 LLM 理解也方便如果走数据库链路时类型对齐数字列保留两位小数避免把浮点误差带进问答里关键列订单号、用户名如果全是N/A这些行直接丢弃不要留着稀释语义空间。这一层清洗不重几行代码的事但对最终问答质量的提升很直观。我第一次跑实验时偷懒跳过了清洗用户问退货订单里金额是 N/A 的有多少LLM 答得很含糊后来清洗完再检索答案就准确很多。3. Excel 的结构复杂度sheet、合并单元格与公式值处理 Excel 比 CSV 难一个数量级难点不在读取而在结构扁平化。3.1 sheet 拆分的必要性一个工作簿里常有多个 sheet明细表、汇总表、参数表、说明页。如果整个工作簿只生成一个 Document不同 sheet 的语义会互相污染。用户问参数表里的汇率是多少检索结果里混着明细表的一大段销售记录模型会茫然。我的做法是把每个 sheet 当成独立的 Document 来构建Document 的元数据里写入{source_file: xxx.xlsx, sheet_name: 参数表}。好处是不仅内容分开元数据也能帮检索做过滤——LlamaIndex 的 metadata filter 可以直接卡 sheet 维度。写入库之后你甚至可以在 query 转译时附加filtersheet_name 参数表这种对检索的精确控制是整文件一股脑灌进去永远做不到的。3.2 合并单元格与公式单元格pandas 的read_excel()读合并单元格时只有左上角有值右边和下边的单元格是 NaN。这在文本场景无所谓但在表格问答里就是信息丢失。比如一个跨五行的表头季度销售数据只在第一行有值后面四行全是 NaN如果不对齐语义就断了。处理办法有两条路一是直接用openpyxl读merged_cells属性把合并区域的值广播填充到所有单元格from openpyxl import load_workbook wb load_workbook(sales.xlsx) ws wb[Sheet1] for merge in ws.merged_cells.ranges: min_col merge.min_col min_row merge.min_row value ws.cell(min_row, min_col).value for row in ws.iter_rows(min_rowmerge.min_row, max_rowmerge.max_row, min_colmerge.min_col, max_colmerge.max_col): for cell in row: cell.value value二是不去展开但把合并结构写成文字描述比如合并单元格区域 B2:E2 的值为年度目标。这种方式适合简单场景能少写代码但对上层解析要求高。公式单元格是另一个隐蔽问题。openpyxl默认读公式本身比如SUM(C2:C10)你拿到的不是数值而是公式字符串。如果导入 RAG 时直接用这个值LLM 会一本正经地把SUM(C2:C10)当作实际数据去理解。解决方案是你得决定知识库里需要的是公式还是计算后的结果如果要保留原始业务逻辑就把公式单独提取作为字段说明不是数据行如果要做问答必须读取缓存的计算值。pandasread_excel读的是缓存值前提是这个文件被 Excel 程序打开保存过一次或生成工具写了缓存但 openpyxl 默认不是。实战中我的处理是优先用 pandas 读值用 openpyxl 读公式做校验两边一对比就知道哪些单元格有公式再把公式和值都写进块的元数据里。3.3 表头层级与面向问答的文本化模板多层表头比如两级列名2024年 / 一季度 / 1月这种在 Excel 里很常见。处理时不能简单地把表头 row 拍平否则二维信息被降成无层级的一维字符串检索时很难对上。我最终用一个文本化模板来解决表格: 门店销售统计表 Sheet: 区域明细 表头层级: 一级: 门店 | 2024年 | 2025年 二级: 门店名 | Q1, Q2, Q3, Q4 | Q1, Q2, Q3, Q4 数据行: 华东一店, 120, 140, 150, 160, 110, 130, 145, 155这里为了让 LLM 知道140 到底是哪个指标我会把扁平表头展开成带前缀的列名例如2024年_Q1_华东一店。这样每个单元格的语义在生成文本块时就已经锁定LLM 不需要去猜。表格问答的准确性在很大程度上不是靠检索算法而是靠进入向量库之前把语义显式化到每个字段名里。这一点我必须强调因为这是我在多个项目里反复验证过的结果。4. LlamaHub 连库实战从建连到自定义查询语句说完了文件类数据再讲数据库直连。LlamaHub 上的 DatabaseReader在某些版本里叫DatabaseReader是一个很适合快速接入的加载器底层用的是 SQLAlchemy因此 MySQL、PostgreSQL、SQLite、SQL Server 都可以连。我不建议你自己写数据库连接代码SQLAlchemy 已经帮你处理了连接池、驱动差异和事务边界这些脏活没必要重复造轮子。4.1 连接串与查询参数的指定方式DatabaseReader 的用法很简单核心就是两段配置数据库连接字符串Database URL查询 SQL 语句我建议你用一个独立的配置文件比如 YAML 或者环境变量来放连接字符串不要硬编码在代码里。下面是一个 PostgreSQL 的示例from llama_index.core import Document from llama_index.readers.database import DatabaseReader reader DatabaseReader( databasepostgresql://username:passwordlocalhost:5432/sales_db, ) documents reader.load_data( querySELECT order_id, user_name, product_name, amount, order_time FROM user_orders WHERE order_time 2025-01-01 ORDER BY order_time DESC LIMIT 5000 )这里有个重要的经验不要一次性加载整张表。把加载多少数据这个决策交给查询条件按时间范围或业务分区去拉数据这样导入过程可以重复执行而无负担。生产环境里数据是持续增长的全表加载除了慢还会让向量索引里的旧数据不断膨胀。你要做的不是把数据库复制一份到向量库里而是只把需要被检索到的问答知识抽出来。4.2 把表结构元数据注入 query 的实践直接 SELECT 原始数据然后分块在实践里效果只能算凑合。真正让我满意的是先取数据、再造知识块的二段式转换。数据库里一张表有多列但如果按行直接生成文本块和 PDF 里按行切是一样的每行数据会包含大量相对业务问答不重要的字段而且字段的可读性取决于列名是否足够语义化。真实业务的列名往往是a、b、c或拼音缩写模型看到sb也不知道是商品看到je也不知道是金额。所以数据库导入一定要做一次字段重命名 列注释注入SELECT order_id AS 订单号, user_name AS 用户名, product_name AS 商品名称, amount AS 订单金额(元), order_time AS 下单时间 FROM user_orders WHERE ...SQL 里写别名比在 Python 里写字典映射更直观也更好维护。你的查询 SQL 本身就是知识库的纲目别人接手时看到这串 SQL 就能明白这个知识库要回答什么类型的问题。除了字段语义表间关系也要写进块里。比如一个订单表和一个用户表你可以生成一个外键说明前缀块表名: user_orders 关联说明: user_orders.user_id - users.user_id 用途: 查询用户订单明细可按用户名筛选。这个说明块不参与行数据的合并但可以作为独立的 Document 注入索引也可以作为每条订单块的公共前缀。它的作用是让 LLM 在回答涉及关联查询的问题时知道表之间怎么 join这是单纯的行文本永远给不了的信息。4.3 自定义 SQL vs 全表拉取的取舍很多人一上手习惯SELECT * FROM table然后想交给 RAG 自己去理解。我实测下来这不是个好主意大表全量拉取会让 Document 数量爆炸向量索引的构建时间和存储成本都不可控无关字段会稀释语义检索时模型把不相干的列也当成上下文数据库列的注释和类型信息在被查询的瞬间就丢了除非你自己额外补。所以我定了一条原则在 SQL 阶段就完成选择而不是在建模阶段靠向量检索去过滤。如果你的数据形态是业务发生变化就新增列、改状态值那么再好的向量索引都不如把 SQL 条件写清楚。这一步不用舍不得——向量检索擅长的是语义召回不擅长的是过滤和聚合而 SQL 恰好是后者的标准答案。5. 三种数据形态的选型对比与应用场景分流到了这一步你可能会问文件类和数据库类到底用哪个我的回答是先看你的问答场景再定数据管道。5.1 CSV/Excel vs 直连数据库的决策矩阵维度CSV/Excel 静态文件数据库直连数据更新频率低适合一次性导入高适合持续同步问题类型偏这张表里有什么偏按条件统计、跨表关联实现成本低代码少中需要 SQLAlchemy 配置规模上限中等建议单表小于 5 万行高靠 SQL 分区拉取字段语义表头可直接阅读列名通常是代号需重命名适合场景报表、导出数据、离线数据集业务系统、订单、用户等实时库拿我做过的一个项目举例客户这边一部分运营数据是每周从 BI 系统导出成 Excel一部分业务主数据在 MySQL 里实时更新。前者我按 Excel 管道处理每周重跑一次导入后者我走 DatabaseReader 加增量时间窗口每天凌晨拉昨天的新数据。如果你把两者混在同一套管道里要么每周批处理跟不上实时性要么直连查询把历史报表也重复拉一遍两边都不讨好。5.2 单一文件内多表工作簿的处理顺序一个复杂工作簿里通常有多张逻辑表上面已经讲了 sheet 拆分。但在 LlamaIndex 的索引构建中这些 sheet 拆分后的 Document 默认会进入同一个索引。遇到这种情况我的处理顺序是先按 sheet 拆成独立 Document每个 Document 设置元数据sheet_name构建向量索引时在节点的元数据里保留这一字段查询时如果需要限定范围用MetadataFilters做过滤如果要跨 sheet 汇总就先做一次关键词检索召回多个 sheet 的块让 LLM 在生成阶段聚合。这个方法能处理 90% 的多表 Excel 场景。唯一要注意的是在检索时不要把多个不相关的 sheet 混进同一个上下文窗口否则 LLM 容易串表。测试下来召回前 3~5 个块就够了再多反而是噪声。5.3 什么时候该放弃向量检索、转投 Text-to-SQL最后聊一个我反复被问到的问题知识库里已经接入了数据库能不能直接让 LLM 写 SQL 查数据库别建向量索引了可以但要分清场景。Text-to-SQL 的优势是精确、实时、可解释它适合的问题是上个月华东区销量 Top 10 的商品有哪些。这类问题本质是结构化查询向量索引再好也答不精确。而 RAG 的向量检索擅长的是请解释退款政策中关于运费的规定这种非结构化语义。我在实际项目中常用的混合方案是先通过 Text-to-SQL 获取精确的结构化结果比如一条订单列表再将结果转成自然语言摘要文本最后把摘要文本拼接上召回的非结构化知识块一起交给 LLM 生成最终答案。第一步的 SQL 生成要传表结构元数据给 LLM包括表名、字段名、字段含义、主外键关系这一步和上面说的 DatabaseReader 的元数据注入思路一致。第二步其实是把数据库查询和RAG 检索在答案生成层做统一。这样既保住了结构化查询的精确性又利用了非结构化文档的语义召回能力。这套方案在复杂查询上还有坑比如多表 join 时 LLM 容易写错关联条件比如字段名歧义时吞吞吐吐。但如果你只是做连库 问答的入门项目我建议先从 DatabaseReader 开始把行文本块跑通再加一层 SQL 生成不要一上来就挑战全自动 Text-to-SQL 大而全的架构。6. 我在实际项目中总结的几条硬经验和最终建议写到这里我回想自己第一次做表格类 RAG 项目时的教训有三条如果当时有人告诉我能省一周的调参时间在这篇里一并分享第一元数据是表格 RAG 的命根子。无论是 sheet 名、列名还是表关联说明都要在 Document 进索引之前写入元数据。不要指望嵌入模型能自己从混乱的行文本里悟出结构信息语义补全的优先级永远是靠元数据而不是靠更大的模型。第二分块大小不是拍脑袋定的。我在 CSV 和 Excel 上都做过尝试行数太少会导致上下文语义碎片化行数太多会导致上下文中噪声过大尤其当业务字段很长时。建议你拿自己数据量的 30% 做一个对比实验分别测试 10、15、20 行每块用 10 个你最关心的业务问题去检索引擎里跑一遍肉眼对比召回的块内容是否贴题再定最终参数。这比什么默认 chunk_size512靠谱得多。第三数据库导入一定要做只导需要的。我见过同一个坑被踩好几次想省事直接SELECT *导全表结果索引库大得慢检索还一堆没用的列数据。后来改成按业务问题设计 SQL 视图把字段精简到最少效果立竿见影。知识库不是数据仓库的备份你导进去的是为了回答问题而准备的知识切片不是原始数据本身。如果你现在正卡在表格数据进 RAG 这个环节我的最简建议是先用 pandas 读 CSV 做行基分块跑通全流程再处理 Excel 的 sheet 和合并单元格最后再上 LlamaHub 连库。不要一上来直接追求 Text-to-SQL 那种复杂链路——先把最简单可靠的基础管道跑稳再逐步加高级特性。表格数据没有银弹每个变形都要对应一种工程处理但每一层处理都能实打实地反映在最终问答质量上。