AI查表,先问它看到了什么

自然语言查数很快，但大模型往往只看表头和小样本，真正扫全表的是它生成的代码。核对 schema、样本和生成逻辑，比单纯相信秒出的数字更重要。

运营总监把 CSV 往群里一丢：「帮我看看华东掉量是不是某几个 SKU 拖的。」半分钟出数，表格还挺像样。你嘴上夸快，心里其实在想另一件事：它到底看了哪些行？

这两年「自然语言查数」「Talk to your data」类产品很多。PandasAI 是其中一个典型样本——开源、接 pandas，问一句就能出表、出图。同类思路还有 Text-to-SQL、各种「把问题转成 Python/SQL 再执行」的方案。机制大同小异，堵心点也大同小异：算得快，但黑箱；数字像真的，可你不知道依据是什么。

本文只讲这一件事：AI 查表时，模型实际「看到」什么；真正扫全表的是谁；大数据场景下「会不会漏掉关键行」该怎么想。不讲上手教程，也不把 PandasAI 当成唯一代表。

先把流程摊开。以 PandasAI 为例，官方 v3 文档（NL Layer 页）写得很直白：当你对 DataFrame 调用 .chat() 时，系统会把「你的问题、表头、以及 5～10 行样本」一并交给大模型；大模型据此生成 Python 或 SQL；代码在本地执行，结果再返回给你。

也就是说，LLM 这一步并不逐行「读」整张表。它拿到的是结构信息加一小撮预览，然后写一段程序，让 pandas 或 DuckDB 在你机器上对完整 DataFrame 跑一遍。

数据科学家 Andres Vourakis 在 2025 年 8 月的实测文章《Testing the Limits of PandasAI (Part 1)》里，把同样的事拆成五步：输入问题 → 收集列名、少量 preview 行和元数据拼进 prompt → LLM 输出代码 → 校验 → 本地执行。

换句话说，瓶颈往往在「大模型往返 + 代码写没写对」，不在「两百万行上传要多久」。Vourakis 用 5K、10K、20K 三档行数做 benchmark，平均响应时间都在 24～26 秒左右，量级差不多。行数翻几倍，端到端耗时并没有跟着线性涨——因为全表本来就没进 LLM。

老版本文档（ReadTheDocs / PyPI 的 Privacy & Security 章节）还补充了一个细节：默认送进 prompt 的不只是 df.head()，还会做随机化——敏感字段用随机值替换，非敏感数据可能 shuffle；目的是让模型感知列类型和取值形态，同时降低明文外泄风险。若打开 enforce_privacy = True，文档原意是「不再发送 head，只发列名等元数据」。GitHub issue #1074 里有人反馈：某些版本 verbose 日志里仍能看到 samples 字段，维护者回复称数值可能是随机化后的，不等于真实行——这也说明一件事：隐私模式和默认模式，LLM 侧信息量差一截，写代码时的线索也差一截。

可以这么理解分工：模型像只看了书的目录和扉页几页，真正翻完每一页的是它写下来的那段代码。PandasAI 早期 API 文档（pandasai-docs ReadTheDocs）也用了几乎同样的表述：「A pandas dataframe metadata i.e df.head() and prompt is passed on to chosen LLMs API end point to generate a Python code… The resultant python code is run on actual data.」

所以你问「它看了哪些行」——严格说，模型没有「看」两百多万行里的每一行；它看了样本和表头，然后赌自己写的代码能覆盖你要的答案。

堵心点在这里。很多人默认：既然最后是对全表执行，就不存在漏行。这个推理只对了一半。

第一层：不是 LLM 逐行看漏，是样本误导写错代码。默认模式下，模型靠 preview 行猜数据长什么样——日期格式、空值比例、某列是编码还是明文、华东到底写在 region 还是 area 列。preview 若是均匀随机抽样，问题还少一点；若恰好都是正常 SKU、没有掉量那几条，或者 head 恰好是某一个大客户，模型可能写出「语法正确、逻辑跑偏」的代码。代码照样跑全表，照样很快出数——漏的不是行，是条件。

第二层：问题太宽，代码一次扛太多。同文还写：别把「算各 segment 平均购买额并画分布」塞进一句里，拆成两步更稳——「Keep queries focused.」复杂多问合一，LLM 容易误解意图，生成的代码漏 filter、漏 groupby、或 chart 与 aggregate 搅在一起。执行仍覆盖全表，答案却可能答非所问。

第三层：privacy 模式与「你以为它看见过真实分布」之间的错位。enforce_privacy 打开后，外发数据更少，合规上更安心，但模型写代码的线索也更少。YouTube 上 PandasAI 社区讲解（频道视频 Chat with your Pandas Data Conveniently and Privately）提到：enforce_privacy=True 时「just literally sending the column names」；结果仍可能正确，前提是列名自解释、问题简单。反过来说，列名是内部缩写、业务口径藏在人脑子里，privacy 模式下模型几乎是在盲写——全表执行不会少跑一行，却可能从第一行 filter 就筛错集合。

同类 Text-to-SQL 工具也是：模型看 schema 和少量样例，SQL 在库里跑全表。机制不同，信任错位相同。

标题里的「先问」，不是抬杠，是核对上下文。具体可以这样做：

看 schema。列名、类型、行数各是多少？和你在 Excel 里打开的是同一张表吗？Vourakis 在 Part 2 里谈 semantic layer，核心也是：别指望模型从 amt_1 猜出「含税 GMV」——要么列名说人话，要么额外给字段说明。；看样本。若工具允许 verbose / 日志，prompt 里到底塞了几行 preview？是 head 还是随机样？enforce_privacy 开没开？issue #1074 的教训是：日志里出现 samples 不等于泄露真值，但你要分清「随机化样例」和「真实分布」。；看生成代码。PandasAI 可开 show_code 或 verbose，Text-to-SQL 工具也常能展开 SQL。filter 条件、join 键、日期边界是否和你业务口径一致？这一步比盯最终数字重要。全表执行发生了，但 WHERE 写错，漏的是业务上关键的那一段，不是物理行。；spot check。挑几条你知道答案的行或日，用同一口径手算或旧报表对照。AI 查数适合 exploration 和 sanity check，Vourakis 的 verdict 也是：「PandasAI shines when you already have a clean dataset and just want to explore it faster」——干净数据集 + 快速试探，不是免复核的生产终审。

经营里上 AI 查数，业务方迟早会问一句：「这数依据什么算的？」能答上来，比单纯快半分钟值钱。

AI 查表，快，多半快在「模型只处理一小包上下文 + 本地代码跑全表」这条链路上；快，不等于模型已经逐行审过你的大数据。

下次 CSV 丢进群里、数字秒出的时候，不妨先问一句——你刚才到底看到了什么？schema、样本、生成代码，三项对上了，再决定要不要把这个数转给老板。