RAG处理表格数据——Table RAG让我把Excel变成了知识库

标准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构建Table RAG

先看最核心的表格解析和索引构建：

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表达能力的限制。

落地过程中的三个典型技术坑

坑1：Excel合并单元格。 很多财务表格有合并单元格，pandas读进来全是NaN。解决方案：用openpyxl先做预处理，把合并单元格的值填充到每一行。

坑2：大表格token爆炸。 一个5000行的表格，全塞进prompt直接超token限制。解决方案：先做行级过滤（WHERE条件），只把相关行喂给LLM。

坑3：数值精度丢失。 LLM偶尔会把127.5万理解成127万或128万。解决方案：在prompt里明确要求"保留一位小数"，并在response里做格式校验。

效果对比：从38%到87%的准确率跃升

方案	准确率	幻觉率
标准RAG（文本分块）	38%	22%
Table RAG（多粒度索引）	72%	8%
Table RAG + Text2SQL分流	87%	3%

从38%到87%，核心就做了两件事：保留表格结构信息，精确查询走SQL。

不同规模与查询模式下的选型建议

如果你也要处理表格数据的RAG：

• 表格少于5个、行数<1000： 直接把整个表格塞进prompt，不需要RAG
• 表格中等规模、查询以模糊分析为主： 用LlamaIndex的Table RAG方案
• 表格大、查询以精确查找为主： Text2SQL优先，RAG兜底
• 混合场景： 像我上面写的，做查询类型分流

💡 一句话带走：表格RAG的命门不是向量模型选型，而是保留结构——结构丢了，检索再准也是白搭。

JOTO 企业落地观察

• 企业部署Table RAG时，首要取舍不是模型能力，而是是否接受将原始表格数据转化为结构化中间表示——这直接影响后续索引构建成本与实时性保障能力。
• 当企业存在大量历史Excel且缺乏统一数据库时，Table RAG的“多粒度索引”本质是在弥补数据治理缺失；团队需评估：是投入工程资源适配RAG，还是优先推动数据入湖标准化。
• Text2SQL与向量检索的分流逻辑，对企业RAG知识工程提出了新要求：必须为每张业务表维护可机读的schema元数据，否则LLM无法完成查询路由决策。
• 财务类场景对数值精度敏感，Table RAG方案中嵌入的格式校验与prompt约束，属于AI安全治理的前置实践——它不依赖模型本身，而靠工程化规则兜底。