表格数据是业务场景中最常见的信息载体之一，Excel报表、CSV导出文件、数据库查询结果集都是典型代表。与一般的文本段落不同，表格具有强结构约束：每一列有独立的语义类型，每一行是一条记录，单元格之间通过行号和列名建立关联。如果直接把一个CSV文件读成字符串，再按固定长度切片存入向量库，检索时返回的片段很可能是残缺的行或者只有数值没有列名，生成模型无法正确理解这些数字到底代表什么。表格RAG要解决的核心问题就是：如何对结构化表格进行合理的索引和检索，使得大模型在看到检索结果时能准确回答涉及行、列、条件筛选、聚合计算等问题。
以一个员工信息表为例，列包括姓名、部门、入职日期、月薪、绩效评分。用户问“研发部绩效评分高于4.5的员工有哪些”，如果文本块切分不当，向量检索可能会返回包含“4.5”这个数字的无关片段，而无法把“研发部”与“绩效评分”两个列条件组合起来。表格RAG需要在索引构建时显式地把列名和单元格值绑定，并保证检索单元包含完整的行上下文。常见做法包括按行生成自然语言描述、把表格转为Markdown格式并保留表头、使用专门的表格嵌入模型等。
表格解析与行级文本化策略
第一步是从Excel或CSV文件中提取出标准化的表格对象。CSV文件可以用Python标准库csv模块读取，Excel则需要openpyxl或pandas。读入后得到一个二维列表或DataFrame，表头是第一行，后续每行是一条记录。这里有一个关键决策：多大粒度的数据作为一个检索单元？实践中以“行”为基本单位效果最好，因为用户查询通常针对的是符合某些条件的记录，而不是单个单元格。每个检索单元应当包含该行的所有列名和对应值，这样向量化时才能捕捉到列语义。
最简单直接的文本化方式是把每一行格式化为“列名: 值”的键值对列表，例如“姓名: 张三；部门: 研发部；月薪: 25000；绩效评分: 4.8”。这种格式保留了列名和值的对应关系，生成模型看到后可以明确知道4.8是绩效评分而不是其他数字。但这种方式在列数很多时会变得冗长，而且丢失了表格中可能存在的空值、单位、数据类型等元信息。一种改进方案是只在值前面加上列名简称，并用统一分隔符连接，同时单独存储一份完整的表头字典供查询时参考。
另一种流行的做法是把表格整体转换为Markdown表格文本，然后按行分割。Markdown表格自带表头行和分隔行，每行数据用竖线分隔，生成模型和大模型预训练语料中的表格格式一致，理解起来更自然。例如：
# 将二维列表转为Markdown表格字符串
def rows_to_markdown(header, rows):
lines = []
# 表头
lines.append('| ' + ' | '.join(header) + ' |')
# 分隔行
lines.append('|' + '---|' * len(header))
# 数据行
for row in rows:
lines.append('| ' + ' | '.join(str(cell) for cell in row) + ' |')
return '\n'.join(lines)
header = ['姓名','部门','月薪','绩效评分']
rows = [['张三','研发部','25000','4.8'], ['李四','市场部','18000','4.2']]
print(rows_to_markdown(header, rows))
Markdown格式的优势在于经过大量训练数据的洗礼，大模型对它的解析能力很强；缺点则是Markdown表格的每一行在文本向量模型看来仍然是一个长字符串，列间分隔符和竖线可能会干扰相似度计算。因此需要配合一定的后处理，例如去除分隔行、只保留内容行，同时把表头信息附加到每一行的前面或后面。
构建表格索引与向量化方案
有了行级文本化结果之后，下一步是选择嵌入模型并建立向量索引。对于表格数据，普通的句子嵌入模型（如all-MiniLM-L6-v2）在键值对格式上表现尚可，但当列数较多、数值型字段占比较大时，语义信息容易被稀释。一个更稳的做法是使用针对表格微调过的模型，例如Google的tapas系列，或者使用支持表格上下文的BGE系列模型。如果出于工程简单考虑，继续用通用嵌入模型也没问题，但要把列名写得足够清晰，例如把“月薪”写成“员工月薪（单位元）”，把“绩效评分”写成“绩效评分（满分5分）”，这样向量空间中数值和单位的对应关系会更明确。
索引结构方面，除了传统的向量库（如FAISS、Chroma），还可以采用混合索引：既存储行文本的向量，也把每行的关键字段（如部门、日期）抽取出来建立倒排索引。查询时先用倒排索引过滤，再在候选集合里做向量相似度排序。这种策略特别适合带有明确筛选条件的查询，比如“2024年入职的研发部员工平均月薪是多少”，倒排索引可以快速定位到部门等于研发部且入职日期在2024年的行，向量检索只需在这些行内部进一步确认与查询的语义相似度。
下面给出一个使用Chroma构建行级索引的最小示例，展示如何把DataFrame每一行编码成向量并存入：
import pandas as pd
import chromadb
from chromadb.utils import embedding_functions
# 准备数据
df = pd.DataFrame({
'姓名': ['张三','李四','王五'],
'部门': ['研发部','市场部','研发部'],
'月薪': [25000, 18000, 22000],
'绩效评分': [4.8, 4.2, 4.6]
})
# 行级文本化：列名+值拼接
def row_to_text(row, headers):
parts = []
for h in headers:
parts.append(f'{h}: {row[h]}')
return '；'.join(parts)
headers = list(df.columns)
documents = [row_to_text(row, headers) for _, row in df.iterrows()]
ids = [f'row_{i}' for i in range(len(documents))]
metadatas = [{'部门': row['部门'], '绩效评分': row['绩效评分']} for _, row in df.iterrows()]
# 初始化Chroma客户端和嵌入函数
client = chromadb.Client()
sentence_transformer_ef = embedding_functions.SentenceTransformerEmbeddingFunction(
model_name='all-MiniLM-L6-v2'
)
collection = client.create_collection(
name='employee_table',
embedding_function=sentence_transformer_ef,
metadata={'hnsw:space': 'cosine'}
)
# 写入
collection.add(documents=documents, ids=ids, metadatas=metadatas)
# 查询
query_text = '研发部绩效评分高于4.5的员工'
results = collection.query(query_texts=[query_text], n_results=2)
print(results['documents'])
元数据metadatas的加入使得后续可以进行过滤查询。比如在Chroma里可以用where条件限制部门等于研发部，等价于先用倒排索引缩小范围，再计算向量相似度。这种二阶段检索在实际表格RAG系统中非常常用，能够显著提升准确率，避免因为向量空间中的相似度误导而返回其他部门的记录。
查询改写与表格感知的生成策略
即使用户的原始查询比较口语化，例如“帮我看看研发部谁绩效最好”，在进入向量检索引擎之前也需要进行查询改写。改写目标是把条件明确化、列名对齐。可以用一个小型LLM先做查询解析，抽取意图、过滤条件和目标列。比如将上面这句话改写成标准形式：“查询部门=研发部的所有行，按绩效评分降序排列，取第一名”。改写后的查询同时支持倒排过滤和向量检索，检索结果也更容易被后续生成模型利用。
拿到检索出来的行级文本之后，生成模型需要知道这些行来自同一张表，而且列名是一致的。因此在构造提示词时，不要把检索结果打散混在自然语言里，而应该先把表头列出，再把每一行作为上下文按顺序附上。例如：
context = '''
表名：员工信息表
列名：姓名、部门、入职日期、月薪、绩效评分
检索到的行：
1. 姓名: 张三；部门: 研发部；入职日期: 2023-03-15；月薪: 25000；绩效评分: 4.8
2. 姓名: 王五；部门: 研发部；入职日期: 2022-07-01；月薪: 22000；绩效评分: 4.6
'''
prompt = f'根据以下表格上下文回答问题：\n{context}\n\n问题：研发部绩效评分高于4.5的员工有哪些？'
当涉及跨行聚合计算（比如求平均月薪）时，生成模型本身并不擅长精确计算，最好在代码层面先完成计算，把计算结果作为附加信息插入提示词。一个完善的表格RAG系统通常会把检索结果交给一个可执行代码的Agent，让它生成Pandas代码在本地跑出聚合值，再用自然语言组织答案。这样做也避免了因向量检索遗漏某几行导致计算结果错误的问题。
另一个需要注意的细节是空值和日期格式。CSV中空单元格读进来可能变成空字符串或NaN，直接文本化会出现“月薪: ”这样的断片。应该在处理时统一替换为明确的占位符，比如“空”或“未填写”。日期格式同样如此，“2024/1/5”和“01-05-2024”字符串形式差异很大，如果原表没有统一格式，最好在解析阶段就规范化为ISO格式，保证后续比较和排序的一致。
表格RAG的进阶优化方向
对于大型表格（几十列、几十万行），行级向量化的存储和查询开销会急剧上升。此时可以考虑两级索引：先用轻量级的关键列（比如部门、日期范围）建立传统数据库索引或布隆过滤器，再用向量库只存储那些经过初筛的行。另一个思路是表格摘要化：对每一列单独生成摘要向量（比如该列的所有取值分布、类型、含义描述），用户查询先匹配列摘要，再决定读取哪些行的数据。再进一步的方案是用图结构表示表格之间的关系——多个Sheet之间通过外键关联时，把关联路径也纳入检索范围，支持跨表问答。
模型选择上，如果业务场景对表格理解要求极高，可以自行微调一个嵌入模型。训练数据用“查询-相关行”的配对，让模型学习到数值范围查询和列名组合的语义。这种方案前期投入较大，但长期收益明显。对于大多数中小规模的应用，沿用通用嵌入模型加上合理的行级文本化已经能满足大部分查询。
此外，表格中的敏感信息脱敏也是工业落地时不能忽视的一环。行文本在存入向量库之前应该经过脱敏处理，比如身份证号、手机号替换为掩码，同时保留脱敏映射关系以便在最终答案中还原。这个环节可以放在解析层完成，与RAG管线解耦。
说到底，表格RAG没有一套放之四海而皆准的模板。表结构复杂度、查询类型分布、数据规模、延迟要求都会影响方案设计。但核心原则是明确的：保留列名与值的绑定关系，以行为检索单元，结合过滤与向量两种检索机制，查询时先改写再检索，生成时把表头与行上下文完整呈现。抓住这些，处理Excel和CSV数据就能少走很多弯路。