RAG表格数据导入与查询实战：CSV/Excel处理及LlamaHub连库方案

做 RAG 的朋友十有八九会踩到同一个坎：PDF 好说，网页好说，一到表格数据就开始离谱。问它 Excel 里某个季度销售额，它一本正经给你编一个数字；问 CSV 文件里有没有某个客户，它反问你“大概是在哪一列”。这不是模型不行，而是我们喂数据的方式有问题。表格、CSV、数据库这类结构化数据，在 RAG 里的导入和解析完全不是纯文本那套玩法。

今天这篇是系列第三篇，主要聊清楚三件事：CSV 怎么导入、Excel 怎么处理、以及通过 LlamaHub 直连数据库的实战方案。内容基于我自己跑过的几个项目整理，工具以 LlamaIndex 和 LangChain 为主，但思路对任何 RAG 框架都通用。适合已经跑通基础 RAG、准备把表格数据纳入知识库的团队和个人。

1. 表格数据进 RAG 的根本痛点

1.1 为什么表格数据是RAG的“重灾区”

纯文本的切分规则是“按语义块拆”，段落、句子、章节都有天然边界。但表格不一样，一个表格的最小语义单元是“字段名 + 单元格”，而不是一整个段落。如果你把 CSV 当成纯文本一整块塞进去，向量化之后的结果就是一坨混合向量，问“哪个产品销售额最高”的时候，检索出来的可能是某一行含有“产品名”三个字，但跟具体数值完全不相干。

更麻烦的是表格还自带行列关系。同样一句话“2023年华东区销售额是 120 万”，放在表格里可能拆成“年份”“区域”“指标”“数值”四列，字面上根本找不到完整句子。LLM 不是不能理解表格，而是需要你把表格还原成它有“空间感”的格式。这也是为什么很多人的表格 RAG 问起来答非所问——不是模型笨，是数据形态没转换对。

我见过的项目里，表格类数据占整个知识库的比重可能不大，但使用频率极高。业务方最常问的就是“上个月某 SKU 在华南区的退货率是多少”这种结构化查询。这类问题恰恰是纯文本 RAG 的盲区。所以表格导入这一关，必须从底层设计上想清楚：你要的不是“原文检索”，而是“结构可查”。

1.2 三种典型处理思路：转文本、转Markdown、查询接口

基于上面的痛点，表格数据进 RAG 基本有三种路线：

路线一：转成自然语言文本。每一行数据展开成一句话或一段描述，比如“2023年华东区销售额为120万元”。这种方式适合数据量小、字段少、查询模式相对固定的场景。优点是简单，缺点是信息密度低，大表展开后 token 消耗和向量数量会成倍膨胀。

路线二：转成 Markdown 表格。保留原始行列结构，再用 Markdown 语法表达。LLM 对 Markdown 表格的理解能力比纯文本强很多，而且支持按行分割、保留列名。这是目前中小型表格最推荐的方案，兼顾表达完整性和切分可行性。

路线三：不存文档，直接连数据库。把 RAG 里的“检索”变成“查询”。用户问问题，系统先解析出 SQL，再去数据库里查，最后把结果喂给 LLM 生成回答。这种方案叫 Text-to-SQL，它绕过了向量化，从根源上解决了结构化数据的精度问题，代价是需要额外处理数据库连接、权限和安全。

我实际做项目时，往往是三条路线混用：几百行的小配置表转 Markdown，几万行的明细表连库查询，而那种用来给模型做参考的字段说明文档直接转自然语言。先摸清数据特点再决定手法，别上来就一把梭。

2. 基础篇：CSV 文件导入的完整流程

2.1 加载 CSV 的两种主流方式（pandas + LlamaIndex/ LangChain）

CSV 是表格数据里最“老实”的格式，没有格式、没有公式、也没有隐藏列，但恰恰因为太简单，很多人随手一读就出问题。先说加载方式。

第一种是直接用框架自带的 Reader。LlamaIndex 里有SimpleCSVReader和CSVReader，LangChain 里有CSVLoader。这些 Reader 会把 CSV 的每一行转成一个 Document，列名保留在 content 里。优点是一行代码搞定，缺点是细粒度控制弱——比如你想跳过表头、自定义分隔符、处理空值，都得绕到源码里改。

第二种是自己用 pandas 读，再手动转成 Document。这种方式更适合“脏数据”多的场景。我先用pd.read_csv把文件读进来，设置好encoding、sep、skiprows、dtype这些参数，清洗完再转。代码看起来多几行，但每一步都在掌控之内。

我这里强烈建议，只要 CSV 不是那种非常干净的标准表，都走 pandas 路线。尤其是从业务系统导出的 CSV，经常带 BOM 头、单元格里有换行符、数字列混着文本，直接用框架内置 Reader 很容易把换行符当成真实换行，导致列错位。pandas 至少能让你在写入向量库之前看一眼df.info()和df.head()。

2.2 表格内容怎么切分才不破坏语义

切分是表格 RAG 的生死线。纯文本切坏了大不了丢半句话，表格切坏了直接行列错乱，检索出来的结果连列名都对不上。

我的原则是：切分粒度最小到“行”，最大到“批”，绝对不按字符数硬切。具体来说，TextSplitter里的chunk_size=500这种参数对表格毫无意义，因为你不知道第 500 个字符落在哪一行哪个列。正确做法是按行分组。

假设你有 5000 行 CSV，每一行的字段有“日期、区域、SKU、销售额”。如果把整表塞进一个 Document，检索时命中率高但上下文太大，LLM 可能忽略细节；如果按单行切，每行是一个独立 Document，检索精度高，但用户问“某区域整体销售额”时，向量检索只能捞回几行，凑不齐全量数据。

所以我通常选择“按 20~50 行一组切块”，组内保留完整的表头，组间允许少量重叠。为什么是 50？因为普通 CSV 一行平均 100 个字符左右，50 行就是 5000 字符，落在大多数模型 4K 上下文能接受的范围内。如果某行字段特别长（比如描述性文本列），那就取 20 行一组，切分参数根据实际数据量调。

还有一个小技巧：在每一组前面加一行“这段数据来自文件 xx.csv，表头为：字段A、字段B、字段C”。这行前缀能显著提升向量召回时对表格结构的识别率。我测试过，加这行前缀后，问“销售额最高的五个 SKU”这类问题，命中准确率能提升十几个百分点。

2.3 实战代码：CSV转文档并写入向量库

下面是一套我常用的 CSV 导入完整流程，基于 LlamaIndex + Chroma。这套流程也适用于其他向量库，只要替换VectorStore即可。

import pandas as pd from llama_index.core import Document from llama_index.core.node_parser import SimpleNodeParser from llama_index.core import VectorStoreIndex, StorageContext from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 1. 读取 CSV，处理编码和脏数据 df = pd.read_csv("sales_data.csv", encoding="utf-8-sig") # 数据清洗：去空行、统一列名、兜底填充 df = df.dropna(how="all") df.columns = [str(c).strip() for c in df.columns] # 把 NaN 转成空字符串，避免切片时报错 df = df.fillna("") # 2. 转换行数据为文档，按批次分组 chunk_size = 50 documents = [] for start in range(0, len(df), chunk_size): batch = df.iloc[start:start + chunk_size] # 把 batch 转成 Markdown 表格文本 md_text = batch.to_markdown(index=False) # 给每段加一个结构说明前缀，增强检索效果 header_line = f"以下是文件 sales_data.csv 的部分数据，包含字段：{', '.join(df.columns)}。\n" doc = Document(text=header_line + md_text, metadata={"source": "sales_data.csv", "start_row": start, "end_row": min(start + chunk_size, len(df)) - 1}) documents.append(doc) # 3. 解析节点并写入向量库 parser = SimpleNodeParser.from_defaults(chunk_size=1024, chunk_overlap=20) nodes = parser.get_nodes_from_documents(documents) # 初始化 Chroma client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection("sales_data") vector_store = ChromaVectorStore(chroma_collection=collection) storage_context = StorageContext.from_defaults(vector_store=vector_store) # 构建索引 index = VectorStoreIndex(nodes, storage_context=storage_context) print("CSV 导入完成，共写入", len(nodes), "个节点")

这套代码里有几个细节值得展开说一下。

第一，to_markdown(index=False)需要 pandas 的tabulate依赖，如果你不想装，可以手写字符串拼接。但 Markdown 表格对 LLM 的理解确实比纯逗号分隔友好，我建议装上。

第二，SimpleNodeParser的chunk_size这里设 1024 是因为前面已经按行分块了，节点解析时会尽量保留文档结构。如果解析器发现某个 Document 还是超长，它会继续切，但因为每个 Document 已经是独立表格块，切割时会尽可能在语义边界断开。

第三，metadata 里记录了start_row和end_row，这个很有用。后续问答阶段可以根据召回节点的行号范围去原始 DataFrame 里做二次确认，或者直接返回“数据来自第 100~150 行”这样的回答，业务方更容易信服。

3. Excel 导入：多Sheet、公式与格式的坑

3.1 用 openpyxl 和 pandas 处理 Excel

Excel 比 CSV 多出的麻烦全在格式上。一个.xlsx文件里可能有多个 Sheet，每个 Sheet 还有合并单元格、填充色、公式、数据验证，甚至还有图表和图片。而 RAG 真正需要的是 Sheet 里的表格数据，不是视觉效果。

处理 Excel 我基本只用两个库：pandas和openpyxl。pandas 负责读数据，pd.read_excel底层虽然依赖openpyxl，但用起来更符合 DataFrame 的习惯；openpyxl负责处理 pandas 读不出来的那些东西，比如公式缓存值、合并单元格、部分格式信息。

这里有个大坑：pd.read_excel默认读的是单元格的缓存值，也就是 Excel 保存文件时最后计算出来的结果。如果你手里的 xlsx 是从另一个系统导出的，公式计算完才保存，那没问题；但如果是一个半成品文件，单元格里写的是=SUM(A1:A10)而 Excel 还没来得及自动重算，pandas 读出来的就是None或者公式字符串本身。你拿这种数据去建索引，用户问“合计是多少”，模型说“无法确定”。

所以我的习惯是：如果 Excel 里有公式，先用openpyxl加载并把data_only=True打开，看看缓存值是否存在。如果不存在，宁可让业务方先导出成 CSV 再导入，也不要用一个充满公式单元格的文件去建知识库，否则后面全是坑。

3.2 多Sheet与合并单元格的处理策略

多 Sheet 的处理要说简单也简单，遍历一下就行，但要注意每个 Sheet 的数据结构可能完全不同。第一个 Sheet 是“销售明细”，列名是日期、区域、金额；第二个 Sheet 是“产品目录”，列名是 SKU、名称、供应商。如果你把两个 Sheet 无脑拼成一个大 DataFrame，列名冲突会直接毁掉整个索引。

我建议每个 Sheet 独立建一个 Document 前缀，或者更稳妥的做法是每个 Sheet 生成独立的索引。哪怕你最后把它们放进同一个向量库，也要在 metadata 里标记sheet_name和source_file，检索时才能按文件筛。

合并单元格就更麻烦。Excel 合并单元格在 pandas 里读出来之后，只有左上角那个单元格有值，其余是 NaN。比如一个区域有多行数据，区域名合并到一行里，其余行其实是空，但语义上它们都归属这个区域。如果直接fillna("")，就会丢失归属关系。

处理办法是先横向填充（ffill），把合并单元格的值向下复制到同一区域的所有行。但要注意，ffill会误伤原本就真的是空白的数据列。所以只能对已知需要填充的列设置ffill方向，或者干脆根据 Excel 的 merged_cells 信息把值填回去。用 openpyxl 可以拿到ws.merged_cells.ranges，然后遍历合并范围，将值填到所有被合并的单元格。代码不算多，但能救命。

from openpyxl import load_workbook wb = load_workbook("data.xlsx", data_only=True) ws = wb["明细"] # 合并单元格填值 for merge in ws.merged_cells.ranges: top_left = merge.start_cell value = top_left.value for row in ws.iter_rows(min_row=merge.min_row, max_row=merge.max_row, min_col=merge.min_col, max_col=merge.max_col): for cell in row: cell.value = value

这段代码跑完之后，再把ws转成 pandas DataFrame 就不会有空值了。如果你有几十个 Sheet，可以用循环批量处理，注意data_only=True是取缓存值，前面说过的公式问题依然存在。

3.3 实战代码：Excel 转结构化文档

下面是我的 Excel 导入完整代码，处理了多 Sheet 和合并单元格，并统一输出为 Markdown 文档节点。

import pandas as pd from openpyxl import load_workbook from llama_index.core import Document, VectorStoreIndex from llama_index.core.node_parser import SimpleNodeParser def excel_to_documents(path: str): # Step 1: 用 openpyxl 处理合并单元格，并读取缓存值 wb = load_workbook(path, data_only=True) documents = [] for sheet_name in wb.sheetnames: ws = wb[sheet_name] # 1. 填充合并单元格 merged_filled_rows = [] for merge in ws.merged_cells.ranges: top_left_value = merge.start_cell.value for row in ws.iter_rows(min_row=merge.min_row, max_row=merge.max_row, min_col=merge.min_col, max_col=merge.max_col): for cell in row: cell.value = top_left_value # 2. 取出所有行的原始值 rows = [] for row in ws.iter_rows(values_only=True): rows.append(row) # 3. 转成 DataFrame，第一行作为列名，并清理空行 if not rows: continue header = rows[0] data = rows[1:] df = pd.DataFrame(data, columns=header) df = df.dropna(how="all").fillna("") # 4. 按 Sheet 切块，每 30 行一个文档 chunk_size = 30 for start in range(0, len(df), chunk_size): batch = df.iloc[start:start + chunk_size] md_text = batch.to_markdown(index=False) doc = Document( text=f"以下来自 Excel 文件 {path} 的 Sheet「{sheet_name}」，字段为 {list(df.columns)}。\n{md_text}", metadata={ "source": path, "sheet_name": sheet_name, "start_row": start } ) documents.append(doc) return documents # 使用 docs = excel_to_documents("业务数据.xlsx") parser = SimpleNodeParser.from_defaults() nodes = parser.get_nodes_from_documents(docs) print(f"生成 {len(docs)} 个文档，解析为 {len(nodes)} 个节点")

这里有个容易被忽略的点：iter_rows(values_only=True)时，如果你没有先处理合并单元格，那么合并区域里非左上角的单元格全部会是None。所以我上面在处理完合并之后立刻从 sheet 取值，顺序不能乱。

还有列名的处理。有些 Sheet 的第一行不是标题而是说明文字，比如“销售数据导出日期：2024-01-01”，这时候rows[0]会被误当成列名。我一般会根据第一行内容判断一下，如果第一行包含“日期”“时间”“导出”这类词，就要手动跳过到第二行。你可以写个小函数检测第一行的单元格值是否都像标题，或者直接让业务方保证文件第一行是表头。实操中后者更省心。

4. LlamaHub 连库实战：SQL 数据库接入 RAG

4.1 为什么需要连数据库而不是导出CSV

很多人会问：既然 CSV 和 Excel 能导入，为什么要费劲去连数据库？直接用 SQL 导出 CSV 再导入不也一样吗？表面看是一样的，但实际用起来差很多。

第一是数据时效性。数据库里的数据是实时变化的，你今天导出的 CSV 到明天就过时了。RAG 场景下用户问“上个月的销售额”，你导出时是月初，等月中他再问，答案还停留在月初的数据，系统却以为这是最新状态，这就成了“一本正经地胡说八道”。连库查询则每次实时取数，不存在过期问题。

第二是数据量。几十万行的数据库表，全量导出成 CSV 再向量化，时间和存储成本都很高。而连库查询走的是精确检索，不需要建向量，查询速度比向量相似度检索还快。尤其适合那些“答案必须精确”的业务场景，比如报表系统、订单系统。

第三是权限控制。数据库你可以在连接层面设置只读账号、限制表权限、限制返回行数；CSV 文件一旦导入向量库，谁拿到向量库谁就看到了所有数据。从数据安全角度，敏感业务数据根本不该导出成文件。

所以我现在的做法是：把静态的知识类表格（比如产品目录、操作手册里的参数表）向量化，把动态的业务数据表放在数据库里做 Text-to-SQL 查询。一静一动，各自发挥优势。

4.2 LlamaHub 里的数据库加载器与工具链

LlamaHub 是 LlamaIndex 的加载器生态，里面有大量数据源对应的 Reader。数据库相关的主要是llama-index-readers-database，它封装了 SQLAlchemy，可以连接多种数据库，包括 SQLite、MySQL、PostgreSQL、SQL Server 等。

但连数据库这件事，我认为核心不只是“加载数据”，而是怎么把“自然语言问题”转成“SQL 查询”。这就要用到 LlamaIndex 的SQLDatabase和NLSQLTableQueryEngine（自然语言 SQL 查询引擎）。这套工具链的逻辑是：

• 先连接数据库，扫描表结构和元数据；
• 当用户提问时，根据表结构生成 SQL 候选；
• 执行 SQL 得到结果；
• 把结果和表结构作为上下文交给 LLM 生成回答。

听起来很美好，但实际使用有几个必要条件：表结构要清晰、字段命名要规范、涉及 join 的多表查询要提前定义好关系。如果你的数据库有一堆col1、col2、fk_xxx这种字段名，LLM 生成 SQL 的效果会很差，因为模型根本猜不到col1是日期还是金额。

所以连库之前，我一般会先做一次“模式增强”：给重要表写一段描述，说明这张表是干什么的，每个字段代表什么含义，可能的枚举值有哪些。这些描述可以存成 JSON 或 Markdown，之后塞进 system prompt 或者作为表结构的补充信息给 LLM 参考。

4.3 实战：用 SQLDatabase 连接 MySQL 并构建查询引擎

下面用 LlamaIndex 自带的SQLDatabase连接 MySQL，构建一个自然语言查询引擎。你需要先装好依赖：

pip install llama-index llama-index-readers-database pymysql sqlalchemy

然后写代码：

from sqlalchemy import create_engine from llama_index.core import SQLDatabase from llama_index.core.query_engine import NLSQLTableQueryEngine # 1. 创建数据库连接，生产环境建议用环境变量保存凭证 user = "rag_query" password = "your_password" host = "127.0.0.1" port = 3306 database = "sales" engine = create_engine( f"mysql+pymysql://{user}:{password}@{host}:{port}/{database}", pool_pre_ping=True ) # 2. 包装成 SQLDatabase 对象 sql_database = SQLDatabase( engine, include_tables=["order_detail", "product_info", "region_info"], sample_rows_in_table_info=2, ) # 3. 构建自然语言查询引擎 query_engine = NLSQLTableQueryEngine( sql_database=sql_database, verbose=True, ) # 4. 查询 response = query_engine.query("2024年3月华东区销量最高的前5个SKU是什么？") print(response)

这里几个参数要重点解释。

include_tables限定可查询的表，这是我强烈建议加的。如果你不填，系统会扫描所有表，包括日志表、临时表、配置表，LLM 在生成 SQL 时会被无关表干扰，甚至选错表。

sample_rows_in_table_info=2表示在 prompt 中带上每张表的 2 行样本数据。这个很有用，LLM 可以通过样本推断字段的数据类型和格式，比如日期字段是"2024-03-01"还是"2024年3月1日"。但样本不要带太多，否则 prompt 太长，影响生成效率。

另外，NLSQLTableQueryEngine的每次查询会先看表结构，再生成 SQL。如果你加的数据库表特别多，这个过程会比较慢。解法是先用SQLTableRetrieverQueryEngine（通过自然语言检索相关表）替代全表扫描，但它配置起来更复杂，先跑通简单的再优化。

4.4 安全与性能：只读、分页、防注入

连库查询最怕的不是答错，而是搞挂业务系统。我见过有人用默认管理员账号直接连生产库，结果用户问“删除所有订单”，LLM 生成了一条DELETE语句，还好平台有拦截，否则数据全没了。所以连库 RAG 的安全底线必须在一开始就设好。

第一，数据库账号必须最小化权限。最好新建一个只读账号，只授予SELECT权限，禁止INSERT、UPDATE、DELETE、DROP、ALTER。如果是 MySQL，可以这样建：

CREATE USER 'rag_query'@'%' IDENTIFIED BY 'strong_password'; GRANT SELECT ON sales.* TO 'rag_query'@'%';

第二，SQL 语句要限制返回行数。LLM 生成的 SQL 可能会漏掉 LIMIT，导致一次返回几十万行，拖垮网络和内存。可以在连接层或者查询引擎层做兜底，比如在create_engine里面执行 SQL 时给它包一层：

from sqlalchemy import event @event.listens_for(engine, "before_cursor_execute") def limit_sql(conn, cursor, statement, parameters, context, executemany): # 如果语句不是分页查询，追加 LIMIT 100 lower_stmt = statement.strip().lower() if lower_stmt.startswith("select") and "limit" not in lower_stmt: if ";" in statement: statement = statement.replace(";", " LIMIT 100;") else: statement += " LIMIT 100" cursor._execution_context = context

这个 hack 不优雅，但非常实用。更严谨的做法是在写 NLSQL 引擎时用自定义 prompt 要求 LLM 必须带 LIMIT，或者用数据库代理层做 SQL 审计。

第三，防注入。虽然这是 LLM 生成的 SQL，还是建议把所有表名和列名限制在预定义的白名单里。include_tables已经筛了表，列名可以通过sql_database.table_info校验。如果业务要求严格，可以再接一个 SQL 解析器，拦截非 SELECT 语句和危险表名。

性能方面，如果数据库本身很大，不要直接对原表做查询，可以建一个独立的只读副本，或者物化视图。RAG 查询频率通常不高，但最怕 LLM 生成的 SQL 带全表扫描和四个表 join。我给客户做的时候，习惯在连接参数里设置pool_size=5、max_overflow=2，防止瞬时并发把数据库连接池打爆。

5. 常见问题与排查实录

5.1 表格导入后问答“睁眼瞎”的排查

“我明明导入了 CSV，为什么问它里面的数据，它说没有？”这是后台收到最多的吐槽。通常有四个环节出错：

第一步看向量库。有没有真的写入节点？用 Chroma 的话可以查一下collection.count()，如果为 0，说明是在解析或写入阶段出了问题，多半是文档生成了空文本或者编码错误。

第二步看检索召回。直接打印retriever.retrieve(question)的结果，看召回节点里有没有和表格相关的文本。如果召回了无关节点，说明查询向量和表格向量不在一个空间，大概率是表格转文本的方式不对。比如你只用逗号分隔的原始文本而没有 Markdown 结构，语义表达就很弱。

第三步看生成阶段的上下文。把最终送入 LLM 的 prompt 打开，看检索到的表格有没有被大模型忽略。有时候召回了，但节点太多，表格信息被前面的 PDF 文本冲掉了。这时候需要调低 top_k，或者用 metadata filter 强制只在表格索引里检索。

第四步看问题本身。不是所有问题都适合表格 RAG。问“总销售额最高的月份”是检索问题，但问“3月和4月相比增长率是多少”是计算问题，需要 LLM 结合多个节点做数值运算。如果你用的是小模型，算力不够就会瞎编。这种情况要么换更强的模型，要么走数据库查询路线。

5.2 编码与格式问题速查表

表格导入的异常，我整理成了一张速查表，几乎覆盖了九成的实际问题。新手照着排查就行。

这些问题的共性是你对数据格式做了隐式假设。表格数据的格式坑不会因为向量库先进就消失，反而会因为“向量化之后看不出原始格式”而更难排查。所以我每接一批数据都会先写一个数据质量报告，输出行列数、空值比例、列名、前几行样本，预览确认无误再进索引。

5.3 混合表格（图文、多层表头）的兜底方案

还有一类表格，既不是纯 CSV 也不是规整的 Excel，而是 PDF 里转过来的、扫描件里的、带图片的“伪表格”。PDF 表格提取在 RAG 里是另一个深坑，很多开源库提取出来的表格行列错位、单元格里有乱码。遇到这种，我的兜底方案是分三层递进。

第一层，如果能拿到原始数据文件，直接找文件源，不要用 PDF。这是最有效的方案，业务方的“最终版”PDF 通常只是给人看的，原始 Excel 或数据库才是有数据价值的。

第二层，PDF 提取后用规则修正。用pdfplumber或Camelot提取表格，然后写校验规则：列数是否一致、数值单元格是否为数字、日期是否符合格式。把不符合规则的单元格标记出来，宁可丢弃那一行，也不要留着错位的行污染索引。

第三层，实在修不了的表格，走“文档截图 + OCR 文本 + 人工标注”的组合。就是把这个表格区域截图保存，OCR 成文本作为检索内容，图片作为展示。这种方案不追求完全结构化，只要求问答时有线索。我在做某个人力资源项目时，几十份员工福利 PDF 表格就是这么处理的，效果不算完美，但至少能回答“某个岗位的福利有哪些”这种粗粒度问题。

多层表头（比如“上半年”下面再分“1月”“2月”）的处理思路是扁平化。把两层表头拼接成一层，例如“上半年_1月”“上半年_2月”，这样既保留层级语义，又符合 DataFrame 的 column 要求。拼接规则可以用"_".join处理，要是嫌翻译成英文不好理解，直接保留中文拼接也行。关键是不要保留嵌套结构，因为大多数 RAG 链路不支持多层表头。

做 RAG 数据导入，我一直觉得“先脏后净”是被动挨打的玩法。正确顺序是先做数据勘察，再设计导入方案，然后才写代码。表格和数据库这块尤其如此——CSV 的编码、Excel 的合并单元格、数据库的权限，任何一个环节不提前考虑，后面都要花十倍时间补救。

拿我自己来说，现在新项目里的表格数据，第一选择永远是数据库直连，查不出来或者没必要查的才转成 CSV/Excel 做向量化。而向量化时，也用固定的“表头前缀 + Markdown 表格”模板，切分时宁可多切几段也不跨越多个表。这些习惯说不上多高级，但真能让踩坑次数直线下降。

如果你正在做表格类 RAG，建议先挑一个几十行的真实表格跑通全流程，把 CSV 和 Excel 的导入都试一遍，再加一个 SQLite 数据库连一遍，之后再上大表和生产库。这比你直接拿十万行数据硬灌进向量库要靠谱得多。下一篇我准备聊聊 PDF 表格提取的详细技巧，以及如何把提取结果整合进现有的 RAG 管线。到时候见。