结构化数据进RAG，为什么Text-to-SQL不够用？

把数据库接进RAG系统，很多人第一反应是上Text-to-SQL：让模型把自然语言问题翻译成SQL，查完再回答。这条路看起来最直接，但在结构化数据的场景里，它经常不够用。 Nabarun Bandyopadhyay在关于RAG系统中结构化数据分块策略的讨论里，把这个问题单独拎了出来。Text-to-SQL的短板，恰恰出在"翻译"这个动作本身。翻译这一步，丢掉了什么自然语言到SQL的转换，本质是一次语义压缩。用户问的是一件事，SQL查的是另一件事，中间靠模型猜。表结构越复杂，猜错的概率越高。字段名、表关系、聚合口径，任何一处理解偏差，都会让查询结果偏离原意，而系统往往不会报错——它会返回一个看起来合理的答案。结构化数据的价值在于精确，Text-to-SQL却在这条链路上引入了一层不确定。分块策略为什么绕不开结构化数据不像长文档那样可以按段落切。表、行、字段之间有强关联，切得太碎会丢失上下文，切得太整又超出模型的上下文窗口。这正是分块策略要解决的问题：在保留结构关系的前提下，把数据拆成模型能消化的单元。 Text-to-SQL跳过了这一步，直接把整张表交给模型去理解。数据量小的时候看不出问题，一旦表多、字段多、关系复杂，模型对结构的把握就会迅速下降。两条路的分工结构化数据的检索，需要的是"先定位、再取数"，而不是"先翻译、再执行"。分块策略负责把结构化数据组织成可检索的单元，保留字段与行之间的关联； Text-to-SQL负责精确查询，适合目标明确、表结构简单的场景；两者不是替代关系，而是各自覆盖不同的数据形态和问题类型。把Text-to-SQL当成结构化数据进RAG的通用方案，等于用一把钥匙开所有的锁。它在简单场景里够快够准，在复杂结构面前却容易失手。真正需要先想清楚的，是数据该怎么切、切完之后怎么被检索到——这一步做对了，后面的查询才有意义。特别