查询结果很大时，怎么交给大模型做数据解读？

简化版

不要把整份结果原样塞给模型，而是先由代码压缩成一份结构化摘要再交给模型解读：总行数、字段列表、少量样本行（比如前 10 行），以及由代码算好的统计量（合计、均值、最大值、最小值，必要时加分组汇总和同比环比）。数字由代码算、模型只负责「讲」，既省 Token，又避免模型心算出错。还有一个容易忽略的点：如果查询加了行数上限，在截断后的结果上算出的合计并不是全量合计，总量类指标要在 SQL 里聚合出来。

详细版

结果摘要的典型结构：

{
  "rowCount": 31,
  "fields": ["pay_date", "sales_amount"],
  "sampleRows": [
    {"pay_date": "2026-08-01", "sales_amount": 12800.50},
    {"pay_date": "2026-08-02", "sales_amount": 13240.00}
  ],
  "numericStats": {
    "sales_amount": {"sum": 402350.8, "avg": 12979.06, "min": 8760.0, "max": 21500.0}
  }
}

分工原则：

工作	交给谁	原因
计数、求和、均值、最值、排序	代码或 SQL	准确、可复现，模型心算大数容易错
选哪些样本行展示	代码	规则固定，比如前 N 行、首尾各几行、最大最小值所在行
描述趋势、指出异常、给业务建议	模型	语言组织和业务理解是模型擅长的

完整版教学

一、为什么不能把整份结果直接给模型

一份查询结果交给模型之前，先算三笔账：

Token 账：   1000 行 × 5 列，每行约 40 个 Token → 约 4 万 Token，一次解读就很贵
注意力账：  长上下文中间的内容最容易被忽略，第 500 行的异常值很可能被漏看
准确性账：  让模型对 1000 个数求和、求均值，心算出错的概率很高

所以「给模型看数据」的正确方式不是给它看全部，而是给它看被整理好的关键信息。这和人看报表一样：分析师先看汇总表和几条典型记录，而不是逐行读明细。

二、摘要要包含哪几部分

部分	内容	作用
规模	总行数	让模型知道结论覆盖多少数据，避免把 10 行样本当成全部
结构	字段名列表（最好附字段含义）	知道每一列是什么
样本	前 10 行，或首尾各几行	感受数据形态和数量级
统计	数值列的合计、均值、最大值、最小值	给出准确的核心数字
扩展	分组汇总、占比、环比、极值所在行	按分析意图补充

样本行的选取可以按意图调整：排行类问题取前几名，趋势类问题取首尾几行，异常类问题把最大值、最小值所在的行也放进去。

三、数字由代码算，模型只负责「讲」

一个具体例子。用户问「8 月每日销售额怎么样」，查询返回 31 行：

代码算好：合计 402350.8，日均 12979.06，最高 21500.0（8 月 15 日），最低 8760.0（8 月 3 日）
模型输出：8 月销售额合计约 40.2 万元，日均约 1.3 万元；8 月 15 日达到峰值 2.15 万元，
          明显高于日均，可能与当日促销有关；8 月 3 日为低点……

模型用到的每一个数字都来自摘要，它只做组织语言、归纳趋势、提出假设这类工作。如果让模型自己从 31 行里求和，算成 40.8 万或者 39.6 万都有可能，而且看不出来。

记忆钩子：模型负责「讲」，代码负责「算」。给模型的数字都应该是算好的。

四、截断结果上的统计不等于全量统计

Text-to-SQL 通常会给查询补一个行数上限，比如 limit 100。这时要特别注意：

用户问：「列出所有订单」          → 实际 5000 行，只返回前 100 行
代码在 100 行上求和              → 得到的是这 100 单的金额合计，不是全部订单的
模型据此解读「订单总额为 xx 万」  → 结论是错的

规避方法有三个：

总量类问题在 SQL 里聚合：问「总销售额」时生成 sum(pay_amount)，而不是查明细再在代码里加；
摘要里标明是否被截断：返回行数等于上限时，标记「结果已截断」，并提示模型结论只针对返回的部分；
分开统计：需要既展示明细又给总量时，额外执行一条聚合查询拿到全量数字。

五、解读 Prompt 要约束什么

摘要交给模型之后，Prompt 要约束输出的结构和边界：

请根据用户问题和查询结果摘要生成数据解读，包含：
  核心结论、关键数据、异常点、业务建议。
要求：只使用摘要中出现的数字，不要自行计算或编造；
      结果已截断时，说明结论只针对返回的数据。

结构化的小标题让解读易读，也方便前端渲染成 Markdown；「只用摘要中的数字」这条约束，是防止模型在解读阶段自己编数的关键。

六、推荐追问：把解读变成下一次分析

解读的结尾可以顺带给出几个值得继续追问的问题，比如「是否按城市进一步拆分？」「是否看最近一段时间的趋势变化？」。推荐追问适合单独调用、单独约束格式：解读是一段自然语言长文本，追问需要一个 JSON 数组方便前端逐条展示，两种格式放在同一次调用里容易互相干扰。追问生成失败时，给出几条通用的兜底问题，不影响解读本身的展示。

七、摘要要能复用

同一份摘要会被多个环节使用：图表推荐、数据解读、推荐追问、多步分析后的报告汇总。所以摘要应该生成一次、保存下来，后续环节直接读取；查询结果变了（重新执行、SQL 被纠错），摘要要随之作废重算。报告环节把每一步的摘要和解读汇总起来，比重新拼接原始结果要轻得多。

八、常见误区与追问

误区：把全部查询结果交给模型最准确。 行数一多 Token 成本飙升，中间的数据容易被忽略，模型心算也会出错，应该先压缩成摘要。
误区：让模型自己从结果里算合计和均值。 大数心算容易错且无法察觉，统计量应该由代码或 SQL 算好再交给模型。
误区：在带 limit 的结果上求和就是总量。 截断后的统计只代表返回的部分，总量要在 SQL 里聚合，或单独执行一条聚合查询。
误区：样本行随便取前几行就行。 不同意图需要不同样本，异常分析要带上极值所在行，趋势分析要带首尾。
误区：解读和推荐追问放在一次调用里更省。 两者输出格式不同，混在一起容易格式错乱，分开调用更稳，追问失败还能单独兜底。
追问：怎么防止模型在解读里编造数字？ Prompt 要求只用摘要中的数字，并在展示时把关键数字和摘要比对，对不上的以摘要为准。
追问：摘要要不要保存？ 要，图表、解读、追问、报告都会复用；查询结果变了摘要要作废重算。

九、加强记忆

大结果不能原样给模型：Token 贵、中间内容被忽略、心算会错。先由代码压缩成摘要：总行数、字段列表、样本行和算好的统计量，按意图补分组、占比和极值行。分工是代码算、模型讲，模型用的每个数字都来自摘要。特别小心行数上限：截断后的合计不是全量合计，总量要在 SQL 里聚合，摘要里还要标明是否截断。解读 Prompt 约束结构和「只用摘要中的数字」，推荐追问单独调用、单独兜底；摘要生成一次保存复用，结果变了就重算。

项目实战落地

项目里怎么做的

《AI Agent数据分析平台》用 buildResultSummary 把查询结果压成一个 JSON 摘要：rowCount（行数）、fields（字段列表）、sampleRows（最多前 10 行）、numericStats（逐列判断是否为数值，计算合计、平均值、最小值和最大值），保存到分析记录的 result_summary。

数据解读：「数据解读」模板把 {userQuestion} 和 {resultSummary} 交给模型，要求输出核心结论、关键数据、异常点和业务建议；解读原文存进 data_insight，前端按 Markdown 渲染，渲染前先做 HTML 转义，防止模型输出里的标签被浏览器执行；
推荐追问：单独再调一次模型，要求只返回 3 个追问组成的 JSON 数组，存进 recommended_questions；这次调用出错时，返回三条固定的兜底问题（按城市拆分、看最近趋势、对比不同分类）；
按需补齐摘要：用户没点过「图表」、直接点「解读」时，后端会先走一遍图表推荐，顺带生成摘要，再做解读。

为什么这样取舍

摘要复用：图表推荐、数据解读和后续的分析报告都读同一份 result_summary，不必各自重新处理原始结果。
解读和追问分开调用：一个要长文本，一个要 JSON 数组，分开后格式互不干扰，追问失败也不影响解读展示。
结果失效：重新生成 SQL、纠错或重新执行时，旧的摘要、解读和追问会被一起清空，必须基于新结果重新生成。

面试官还会追问

推荐追问模型有时返回 JSON 数组，有时返回一行一个问题的普通文本，前端怎么兼容这两种格式？
某一列有几行是空值，numericStats 里的平均值是按总行数除，还是只按有数值的行数除？

学完《AI Agent数据分析平台》，上面这些追问你都会迎刃而解。

简化版

详细版