数据分析智能体
典型题：设计一个能根据自然语言问题查询数据、生成 SQL、分析结果并输出图表或结论的数据分析 Agent。
面试官真正想看什么
业务说“上个月华东销售下降多少”时，Agent 需要先确认指标口径、时区和权限，再生成受限 SQL。结果为空、单位不一致或数据延迟时，系统应明确提示，而不是填一个漂亮的百分比。
- 你是否知道数据分析 Agent 最危险的是错查、越权和错解释。
- 你能不能把 SQL 生成、权限、执行、结果解释、可视化和审计分开。
- 你会不会限制写操作和高成本查询。
先问清楚
Q1：设计前先问什么？
参考答案
我会先问：
- 数据源是什么：数据库、数仓、BI、CSV、API。
- 用户是谁，权限是否不同。
- 是否允许生成并执行 SQL。
- 是否只读，还是允许写入。
- 输出是文字、表格还是图表。
- 对准确率、延迟、成本有什么要求。
最小架构
核心流程
Q2：数据分析 Agent 的最小闭环是什么？
参考答案
最小闭环是：
- 理解用户问题。
- 检索相关表结构和字段说明。
- 生成 SQL。
- 校验 SQL 是否只读、是否有权限、是否限制扫描量。
- 执行查询。
- 根据结果解释结论。
- 记录 SQL、耗时、成本和结果摘要。
Q3：为什么不能把全库 schema 都塞给模型？
参考答案
全库 schema 太长、噪声多，也可能泄露无权限表。更好的做法是先做 schema 检索，只给相关表、字段、指标定义和样例。
Q4：SQL 生成后为什么要校验？
参考答案
模型生成的 SQL 不可信。必须校验：
- 是否只读。
- 是否访问有权限的表。
- 是否包含危险语句。
- 是否有 limit。
- 是否扫描过大。
- 字段和表是否存在。
数据分析 Agent 不能让模型直接执行任意 SQL。
Q5：如何处理指标口径？
参考答案
指标口径要来自指标字典或语义层，而不是模型临时猜。比如“活跃用户”“收入”“转化率”必须有定义。模型生成 SQL 前要检索指标定义。
如果没有口径，应该追问用户或提示无法确定。
Q6：查询结果怎么解释？
参考答案
解释时要区分：
- 数据事实。
- 模型分析。
- 可能原因。
- 建议动作。
不能把相关性说成因果。比如“转化率下降”和“某活动上线”同时发生，不代表活动导致下降。
Q7：如何防止越权？
参考答案
权限要在 schema 检索和 SQL 执行层做：
- 用户只能看到有权表和字段。
- SQL 执行前做权限校验。
- 结果脱敏。
- 日志记录访问。
不要只在回答后做脱敏。
Q8：如何控制查询成本？
参考答案
限制扫描量、加 limit、禁止全表大查询、设置超时、对高成本查询要求确认。也可以先生成 explain plan 或估算成本。
Q9：如果 SQL 执行失败怎么办？
参考答案
把错误结构化回传给模型，让它修正。但要限制重试次数。权限错误不能重试，语法错误可以修复，表不存在要重新检索 schema。
Q10：数据分析 Agent 怎么评估？
参考答案
看：
- SQL 正确率。
- 结果解释正确率。
- 权限违规率。
- 高成本查询拦截率。
- 用户采纳率。
- 平均延迟和成本。
30 秒收口
我会把数据分析 Agent 拆成 schema 检索、SQL 生成、SQL 校验、只读执行、结果解释和审计。
核心边界是：模型可以生成 SQL，但不能绕过权限、成本和只读校验直接执行。本题常见扣分点
- 让模型直接执行 SQL。
- 不讲指标口径。
- 不讲权限和脱敏。
- 不限制扫描成本。
- 把相关性说成因果。
深入追问：把自然语言分析做成可控系统
数据分析 Agent 不是“让大模型会写 SQL”这么简单。面试时要把语义理解、指标口径、权限、SQL 安全、资源治理、结果解释和审计串起来，尤其要说明模型生成的内容在什么位置必须被确定性系统拦截。
Q11：需求澄清时，哪些问题会改变整体架构？
回答脉络
先确认用户和决策场景，再确认数据新鲜度、指标口径、交互方式、权限和风险。
完整参考答案
我会先问用户是业务分析师、管理者、客服还是普通员工，因为他们能访问的数据、容许的 SQL 复杂度和解释深度不同。然后问数据源是 OLTP、数仓、湖还是 BI 语义层，数据是否实时，允许的时间范围和最大扫描量是多少。还要确认问题是一次性探索、固定报表、持续监控还是自动触发业务动作。
输出方面要问是否需要 SQL、明细表、图表、结论和导出，是否允许用户修改 SQL。安全方面要确认是否存在租户隔离、行列级权限、个人信息和跨境限制。成功标准应包括 SQL 可执行且语义正确、结果解释正确、权限违规为零、P95 延迟、查询成本和用户采纳率。
这些答案决定是否采用同步查询、异步任务、语义层、预聚合、审批流甚至人工审核。不能一上来就假设“所有用户都能查全库”。
为什么这样设计、替代方案和扣分点
- 固定指标看板可以直接使用 BI 模板和参数查询，不必每次让模型生成 SQL；开放探索才需要自然语言到 SQL。
- 常见扣分点是没问数据新鲜度、指标定义、租户隔离和输出是否允许明细，最后设计成一个没有边界的数据库聊天机器人。
Q12：有几百张表和复杂指标时，Schema 检索怎么做？
回答脉络
不要把 DDL 当成完整语义。需要表、字段、指标、样例和关系的分层检索。
完整参考答案
我会为表、字段、指标定义、业务术语、常用查询和表关系建立可检索目录。用户问题先识别实体、时间、度量和过滤条件，再检索候选主题域和指标定义，最后拿到最小必要的表结构、字段描述、主外键关系、枚举值和脱敏样例。检索结果要带数据更新时间和权限标签。
例如“上月华东新客转化率”至少要明确“新客”的判定、“转化”的事件、“华东”的地区字段和时间时区，不能只因为字段名里有 new_user 和 conversion 就直接生成 SQL。若多个指标定义冲突，系统要追问或选择有版本的权威语义层。
表关系可以来自 catalog、血缘和历史查询，不建议仅靠字段名猜 join。对高频问题可以维护经审核的查询模板或语义模型，让 Agent 填参数而不是自由拼接全部 SQL。
为什么这样设计、替代方案和扣分点
- 表少、命名规范时，直接把相关 DDL 放进上下文足够；数百张表或指标口径复杂时必须有 catalog/semantic layer。
- 只做向量检索容易召回语义相似但不能 join 的表。常见扣分点是把 schema 检索等同于把全库 DDL 塞进 prompt，没有数据血缘、权限和口径。
Q13：SQL 生成、校验和执行的接口边界如何设计？
回答脉络
模型产出候选 SQL，解析器和查询网关做硬校验，数据库只接受受控请求。
完整参考答案
我会让模型返回结构化对象：用户意图、使用的指标、SQL、参数、假设、预期输出列和置信度。查询网关收到后先用 SQL parser 做 AST 校验，拒绝 INSERT、UPDATE、DELETE、DDL、存储过程和多语句；再做表列权限、租户过滤、参数类型、时间范围、limit、最大扫描量和超时检查。
通过静态检查后先执行 explain 或成本估算，超过预算就要求用户确认、改写为聚合查询或转异步数仓任务。真正执行使用只读账号、资源组和数据库端 row-level security；结果返回 query_id、SQL 版本、数据快照时间、行数、扫描字节、耗时和列 schema。模型只能看到允许的结果集，不能直接连接数据库。
为什么这样设计、替代方案和扣分点
- 低风险内部工具可以允许用户查看和修改 SQL，但执行路径仍要经过查询网关；生产库或高敏库必须只读、限时、隔离资源。
- 只用正则判断 SQL 很容易被注释、嵌套查询或方言绕过，应使用 parser/AST 加数据库权限。
- 常见扣分点是让模型直接执行字符串 SQL，或者把“只读”只写在 prompt 里。
Q14：如何保证指标口径、时间和单位不被模型悄悄猜错？
回答脉络
把口径作为可版本化的数据契约，生成 SQL 前强制绑定指标定义和歧义处理。
完整参考答案
我会维护指标字典，每个指标有名称、定义、计算公式、粒度、过滤条件、时间口径、单位、负责人、版本和生效时间。例如“收入”是含税支付金额、订单金额还是确认收入，“活跃用户”是登录还是产生核心事件，必须在元数据中写清楚。模型生成 SQL 时输出引用的 metric_id 和版本，执行前检查 SQL 是否实现了该指标的必要条件。
时间要明确自然语言解析规则，例如“上月”按业务时区的自然月还是过去 30 天；数据延迟要展示“截至数据时间”。百分比、金额和数量做单位归一化，避免把 0.15 显示为 15 元之类的错误。存在多种解释时先向用户确认，或者同时展示假设和两种结果，不能隐藏假设。
为什么这样设计、替代方案和扣分点
- 有成熟 dbt/语义层或 BI 指标中心时，优先复用其定义；没有时可以先用版本化 YAML/表维护，但不能依赖 prompt 记忆。
- 常见扣分点是只检查 SQL 语法，不检查指标公式、时间时区、数据新鲜度和单位。
Q15：如何做租户隔离、行列权限和敏感字段保护？
回答脉络
权限要在元数据检索、SQL 改写/校验、数据库执行和结果输出四层生效。
完整参考答案
用户身份先映射到租户、角色和数据 scope。Schema 检索阶段不向用户暴露无权表和敏感字段；SQL 网关再次校验访问对象，并把租户条件作为服务端约束注入或依赖数据库 row-level security，不能让模型自己决定是否加 tenant_id。数据库使用最小权限只读账号，列级敏感字段使用视图、脱敏函数或禁止访问。
结果返回前还要做小样本聚合保护、个人信息扫描和导出权限检查。例如只有两个人的分组结果可能反推出个人信息，应限制最小分组数或转人工审核。日志记录谁在什么时候访问了哪些表、指标、过滤范围、查询 ID 和策略版本，SQL 参数和结果按敏感级别脱敏。授权服务超时或 scope 不明确时 fail-closed。
为什么这样设计、替代方案和扣分点
- 只读数据集和低敏分析可以主要依靠数据库视图；多租户、合规数据必须服务端策略和数据库策略双重控制。
- 查询后再脱敏不能防止聚合推断和扫描无权数据。常见扣分点是只说“登录鉴权”，没有 row-level、column-level、导出和小群体风险。
Q16：查询失败、结果为空或结果很大时，系统怎样恢复？
回答脉络
把数据库错误结构化，有限修复；结果为空要先验证语义，结果过大要改成聚合或异步导出。
完整参考答案
查询服务返回错误码、是否可重试、数据库位置、执行阶段和安全原因。语法错误、字段不存在、方言不兼容可以把受控错误反馈给模型修正，最多重试 1 到 2 次；权限拒绝、危险 SQL、成本超限不能让模型反复尝试绕过。连接超时可以退避或切换只读副本，但写入、权限和策略错误不能重试。
结果为空时先检查时间范围、过滤值、时区、join 和数据新鲜度，向用户说明“没有数据”与“查询失败”的区别。结果行数过大时默认只展示摘要和前若干行，要求用户缩小范围，或提交异步导出任务；导出仍要重新鉴权、设置有效期和审计。查询超时后不能直接告诉用户“没有结果”。
为什么这样设计、替代方案和扣分点
- 探索分析可以允许模型自动修复一次 SQL；高敏生产环境更适合把 SQL 展示给用户确认。
- 常见扣分点是所有失败都重试、把空结果解释成业务结论、或将大结果集直接塞入模型上下文导致成本和隐私风险。
Q17：结果解释和图表生成如何避免统计误导？
回答脉络
先生成统计事实，再生成解释和可视化；区分描述性分析、相关性和因果推断。
完整参考答案
结果解释模块先基于结构化结果生成事实摘要，例如最大值、最小值、环比、同比、分组差异、样本量和缺失率，并保留计算过程。图表推荐根据字段类型和用户问题选择：时间趋势用折线，类别比较用条形，分布用直方图；禁止为了“好看”使用截断坐标、三维图或不适合的双轴。
模型可以提出可能原因，但必须标为假设，并说明数据没有证明因果。比如销售在活动后上升只能说“时间上同时发生”，不能断言活动导致增长，除非有实验或合适的因果设计。样本量太小、缺失严重、口径改变和数据延迟都要在回答中披露。
图表配置也要结构化并校验字段、单位、排序和聚合方式，前端使用可信渲染器，不执行模型返回的脚本。用户要的是决策建议时，回答应把事实、解释、限制和建议分段，避免把推测伪装成查询结果。
为什么这样设计、替代方案和扣分点
- 固定 KPI 看板适合预定义图表和审计；开放探索才让模型选择图表类型。
- 常见扣分点是只说“让模型生成图表”，没有统计校验、样本量、因果边界和前端脚本安全。
Q18：数据分析 Agent 的状态、缓存和异步任务怎么设计？
回答脉络
用状态机管理澄清、生成、校验、执行、解释和导出；缓存要绑定权限、语义版本和数据快照。
完整参考答案
一次分析可以有 created -> clarifying -> planning -> validating -> running -> interpreting -> completed，以及 failed、cancelled、expired。状态中保存问题、用户 scope、选定的 metric/schema 版本、SQL、查询 ID、数据快照时间、结果摘要、图表配置、成本和审计 ID。每一步有输入版本，模型重试不能覆盖已经通过权限校验的 SQL。
缓存分三类：schema/指标目录缓存，按版本和权限范围失效；SQL 计划或结果缓存，key 绑定规范化问题、参数、用户 scope、数据集版本和快照时间；模型 token 缓存，保持稳定系统提示和 schema 前缀，把变化问题放后面。实时订单或敏感明细不能做跨用户共享结果缓存。长查询和导出通过队列执行，用户可以取消，worker 重启后依靠 query_id 和幂等键恢复或查询执行状态。
为什么这样设计、替代方案和扣分点
- 一秒内完成的简单聚合可以同步；复杂 join、导出和大扫描必须异步。
- 常见扣分点是只说“保存聊天历史、加 Redis”，没有说明状态阶段、数据快照、权限 key、TTL 和取消恢复。
Q19：一次自然语言分析的成本怎么计算？
回答脉络
把模型、数据库、数据处理和用户行为成本放到同一个 trace 里，按意图统计。
完整参考答案
每次请求用 trace_id 记录意图识别、schema 检索、SQL 生成、修复、解释和图表生成的输入 token、输出 token、缓存输入 token、模型单价和重试次数；同时记录数据库扫描字节、CPU 时间、查询耗时、队列资源、导出流量、日志和存储成本。模型成本按普通输入、缓存输入和输出分别乘单价，不能把缓存 token 当作普通输入，更不能漏掉失败重试。
优化顺序是：先缩小 schema 和结果上下文，复用 schema/指标缓存，提高稳定前缀的 token cache 命中率，再对意图识别和简单解释路由到小模型；重复仪表盘用预计算结果，昂贵查询用预聚合或异步任务。高风险分析不能为了低价跳过 SQL 校验和结果复核。最终用“每个成功任务成本”而不是“每次请求成本”衡量，因为失败重试和转人工也有代价。
为什么这样设计、替代方案和扣分点
- 只做内部低频分析时模型成本可能不是瓶颈；大规模自助分析通常数据库扫描和导出更贵。
- 常见扣分点是只计算一次 LLM 调用，漏掉缓存 token、数据库资源、查询失败和用户反复追问。
Q20：如何设计离线评估，判断错在 SQL 还是解释？
回答脉络
构造问题、权限、指标和金标准查询的评估集，分层评估生成、执行、结果和解释。
完整参考答案
每个样本至少包含自然语言问题、用户身份和 scope、允许的数据 schema、指标版本、金标准 SQL 或等价结果、允许误差、预期图表类型和应拒答条件。SQL 层看执行成功率、语义等价准确率、结果数值误差、表列权限违规率和危险语句拦截率；结果层看空结果判断、聚合和单位；解释层看事实一致性、引用数据列、统计边界和因果表述。
要区分 exact-match 与 execution accuracy：SQL 写法不同但结果等价，不能简单判错；相反 SQL 能执行但口径错，不能判对。还要加入越权、提示注入、超大扫描、时区、NULL、重复 join、数据漂移和指标版本变化样本。线上看用户修改 SQL 的比例、采纳率、复问率、人工纠正率、成本和 P95。
为什么这样设计、替代方案和扣分点
- 小规模可以人工审核结果；规模扩大后可用数据库执行对比和规则评估，LLM 只辅助评价解释。
- 常见扣分点是只看 SQL 字符串匹配或“模型觉得答案正确”，没有权限样本、等价查询、数据时效和解释事实一致性。
Q21：如何灰度、设置门禁并快速回滚？
回答脉络
先影子执行和只读低风险灰度，再逐步扩大数据域；高风险导出和动作永远单独审批。
完整参考答案
模型、schema 检索、指标字典、SQL parser、策略、prompt 和图表模板都要版本化。新版本先在脱敏评估库执行，随后对真实问题 shadow：生成 SQL 但不真正访问敏感数据，或只在隔离副本执行并比较结果。第一阶段开放公开或低敏聚合，第二阶段开放普通只读分析，导出、高基数明细和跨租户分析保留审批。
灰度观察 SQL 语义正确率、危险 SQL 拦截率、权限违规率、空结果误判率、结果解释错误率、扫描成本、P95、失败率、用户采纳率和每个成功任务成本。出现越权、数据泄露、危险语句漏拦或成本异常时立即关闭自然语言执行入口，回退到固定报表/旧模型/旧指标版本。回滚必须记录正在运行的查询和导出任务，必要时撤销下载链接和停止 worker。
为什么这样设计、替代方案和扣分点
- 低风险只读分析可以 fail-open 为用户返回“暂不可用”；权限和数据泄露检查应 fail-closed。
- 常见扣分点是把所有指标平均后上线，没对权限和危险 SQL 设置硬门槛，也没说明如何处理已发出的导出任务。
Q22：什么时候应该不用 Agent，而是用语义层、BI 或固定报表？
回答脉络
把 Agent 的价值限定为开放探索和澄清，不把稳定问题复杂化。
完整参考答案
如果业务只需要十几个固定 KPI，最可靠的方案是指标语义层加参数化查询和 BI 图表；如果查询模式稳定但维度较多，可以让模型做自然语言解析和参数填充，SQL 仍来自审核过的模板。只有问题开放、表和指标需要动态选择、用户需要追问分析路径时，才使用 Agent 生成候选 SQL。
即便使用 Agent，我也会让指标定义、权限、SQL 校验、执行资源和图表渲染保持确定性，动态部分只负责理解问题、检索语义和提出候选方案。面试中主动说明“不是什么场景都用 Agent”，能体现对准确性、成本和治理的判断。