上周有个朋友找我帮忙。
他们公司做财务分析，几十个Excel表格堆在共享盘里。老板说”搞个AI助手，我问什么它能直接查表回答”。
他想当然地用了标准RAG流程：把Excel转成文本 → 分块 → 向量检索 → 丢给LLM。
结果呢？问”2024年Q3华东区销售额”，返回的是2023年Q2华北区的数据。问”毛利率最高的产品线”，LLM直接开始编。
表格数据搞RAG，这是公认的坑。纯文本分块会把表格结构彻底打散——一行数据被切成两半，列名和值分到不同的chunk里，检索出来的东西就是垃圾。
后来我换了Table RAG方案，准确率从不到40%拉到85%以上。今天把整个过程拆开讲。
标准RAG为什么处理不了表格
先说清楚问题出在哪。
表格数据有结构——行、列、单元格之间有明确的关联关系。”华东区”对应”Q3″对应”销售额127万”，三者是一个整体。
标准RAG的分块策略是按token数切的。一个500 token的chunk可能包含表格的15行半。第16行的”华东区”被切到了下一个chunk，但它对应的列名”Q3销售额”在上一个chunk里。
检索时，用户问”华东区Q3销售额”，向量相似度匹配到了包含”华东区”的chunk——但那个chunk里没有列名信息。LLM拿到了一堆数字，不知道哪个数字对应哪个列，只能猜。
猜错了，就是幻觉。
Table RAG的核心思路
Table RAG不是简单地把表格转文本，而是保留表格的结构信息，用多种粒度进行检索。
核心分三步：
1. 表格解析： 把Excel/CSV解析成结构化对象（行、列、数据类型），而不是一坨文本。
2. 多粒度索引： 为表格建立多个层级的索引——表级摘要、列级描述、行级数据。
3. 混合检索： 用户的query同时匹配文本索引和表格索引，把检索到的表格片段和文本一起喂给LLM。
实战：用LlamaIndex + pandas搞定
先看最核心的表格解析和索引构建：
import pandas as pd
from llama_index.core import Document, VectorStoreIndex
# 第一步：解析Excel
df = pd.read_excel(“financial_data.xlsx”)
# 生成表级摘要
table_summary = f”””
表名: {df.columns[0]}所在的财务数据表
行数: {len(df)}
列: {', '.join(df.columns.tolist())}
数据范围: {df.iloc[:, 0].min()} ~ {df.iloc[:, 0].max()}
“””
# 为每一列生成列级描述
column_summaries = []
for col in df.columns:
col_summary = f”列名: {col}, 类型: {df[col].dtype}, 示例值: {df[col].iloc[:3].tolist()}”
column_summaries.append(col_summary)
这段代码做了两件事：把表格结构化保留住，同时生成人类可读的摘要。
然后是关键的混合检索部分：
# 构建两个索引：文本索引 + 表格索引
text_docs = [Document(text=table_summary)]
table_docs = [Document(text=”n”.join(column_summaries))]
text_index = VectorStoreIndex.from_documents(text_docs)
table_index = VectorStoreIndex.from_documents(table_docs)
# 检索时，用LLM判断该查哪个索引
from llama_index.core.tools import QueryEngineTool
text_tool = QueryEngineTool.from_defaults(
query_engine=text_index.as_query_engine(),
description=”用于回答关于表格整体结构的问题”
)
table_tool = QueryEngineTool.from_defaults(
query_engine=table_index.as_query_engine(),
description=”用于回答具体数据查询问题”
)
这样LLM看到用户问题后，会自动判断是查结构信息还是查具体数据，然后路由到对应的检索器。
让LLM能”看懂”表格：Schema提示
光有索引还不够。LLM需要知道表格的schema才能理解检索结果。
我在prompt里注入了表格schema：
SCHEMA_PROMPT = f”””
你可以查询以下表格:
表名: financial_data
列定义:
– region (文本): 销售区域
– quarter (文本): 季度
– product (文本): 产品线
– revenue (数字): 营收(万元)
– margin (数字): 毛利率(%)
用户问题: {query}
相关数据: {retrieved_rows}
“””
这个schema提示至关重要。没有它，LLM拿到华东区, Q3, 产品A, 127, 35这样的一行数据，不知道127是营收还是利润。
精确查询用Text2SQL，模糊查询用向量检索
Table RAG最有用的一个技巧：区分精确查询和模糊查询，走不同的路径。
用户问”华东区Q3营收”——这是精确查询，用Text2SQL直接查数据库，100%准确。
用户问”哪个区域增长最快”——这是模糊查询，需要跨行计算，用向量检索找到相关数据后让LLM分析。
def smart_query(user_question: str):
# 用LLM判断查询类型
query_type = llm.predict(f”””
判断这个问题是精确查询还是模糊分析:
问题: {user_question}
只回答 “precise” 或 “fuzzy”
“””)
if query_type == “precise”:
# 走Text2SQL
sql = text2sql(user_question, table_schema)
result = execute_sql(sql)
return result
else:
# 走向量检索 + LLM推理
retrieved = table_index.retrieve(user_question)
return llm.predict(f”基于以下数据回答: {retrieved}”)
这个分流策略让准确率直接拉满。精确查询不再受向量检索的模糊性影响，模糊查询也不受SQL表达能力的限制。
我踩过的3个坑
坑1：Excel合并单元格。 很多财务表格有合并单元格，pandas读进来全是NaN。解决方案：用openpyxl先做预处理，把合并单元格的值填充到每一行。
坑2：大表格token爆炸。 一个5000行的表格，全塞进prompt直接超token限制。解决方案：先做行级过滤（WHERE条件），只把相关行喂给LLM。
坑3：数值精度丢失。 LLM偶尔会把127.5万理解成127万或128万。解决方案：在prompt里明确要求”保留一位小数”，并在response里做格式校验。
效果对比
我们实测了200个query：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
从38%到87%，核心就做了两件事：保留表格结构信息，精确查询走SQL。
选型建议
如果你也要处理表格数据的RAG：
- 表格少于5个、行数<1000：
直接把整个表格塞进prompt，不需要RAG - 表格中等规模、查询以模糊分析为主：
用LlamaIndex的Table RAG方案 - 表格大、查询以精确查找为主：
Text2SQL优先，RAG兜底 - 混合场景：
像我上面写的，做查询类型分流
完整代码我放在了GitHub上，包含表格解析、多粒度索引、Text2SQL分流的完整demo。
💡 一句话带走：表格RAG的命门不是向量模型选型，而是保留结构——结构丢了，检索再准也是白搭。
你做RAG的时候被表格数据卡过吗？是分块切碎了表格，还是LLM读不懂列名？说说你的场景，我帮你看看该用哪个方案。
https://teable.cn/
