设计一个数据分析 Agent，核心架构是什么
配图（无描述）
1️⃣ 考察意图
面试官想看你能否设计一个端到端的数据分析 Agent 架构，而非简单的"LLM + SQL"。刁钻点在于：数据分析 Agent 涉及多个环节——需求理解、SQL 生成、结果解读、洞察发现，每个环节都有技术挑战。很多人只答"用户提问→LLM生成SQL→执行→返回结果"，但说不清 schema 理解、SQL 校验、结果可视化、多轮分析等工程细节。答好了能展示你对数据工程和 Agent 架构的深度理解。
2️⃣ 标准答
数据分析 Agent 的核心架构是"理解 → 生成 → 执行 → 洞察"四阶段完整流程：
1. 需求理解层
- 意图识别：判断用户需求类型——明细查询（"查上周销售额"）/ 聚合分析（"各品类月度趋势"）/ 异常检测（"为什么本周下降"）/ 预测分析（"下季度预估"）
- Schema 理解：用 RAG 检索数据库的 schema 信息（表结构、字段含义、关联关系）。将 schema 文档（如 dbt docs / 数据字典）做 embedding 索引，用户提问时检索相关表的定义
- 上下文管理：多轮分析中保留前序查询的上下文。如用户先问"上月销售额"再问"按品类拆分"→ Agent 理解"按品类拆分上月销售额"
2. SQL 生成层
- Text-to-SQL：用 LLM 将自然语言转为 SQL。关键技术：Schema 注入：将相关表的 DDL + 字段注释 + 示例数据注入 prompt
- Few-shot 示例：提供 3-5 个类似的"问题→SQL"示例
- SQL 方言适配：PostgreSQL/MySQL/Hive/ClickHouse 语法差异 SQL 校验：生成后用 sqlglot 做语法检查 + explain plan 验证执行计划合理性。校验失败时反馈错误给 LLM 重新生成（最多 3 轮）安全约束：只允许 SELECT，禁止 DDL/DML。设置查询超时（30s）和行数限制（10万行）
3. 执行层
- 查询执行：在只读副本上执行 SQL，避免影响生产库。大查询走 OLAP 引擎（ClickHouse/Doris）
- 结果缓存：相同 SQL 的结果缓存 5 分钟，减少重复查询
- 增量查询：大数据集分页查询，避免 OOM
4. 洞察生成层
- 结果解读：LLM 将查询结果转为自然语言摘要。如"上月销售额 1200 万，环比增长 15%"
- 自动洞察：LLM 分析数据中的异常和趋势。如"电子产品品类增长 30%，但服装品类下降 10%，建议关注服装品类"
- 可视化建议：根据数据类型推荐图表（时间序列→折线图，占比→饼图，对比→柱状图）
- 下钻建议：建议用户进一步分析的方向。如"电子产品增长主要由手机品类驱动，是否查看手机品类的详细数据？"
架构图：
用户提问 → 意图识别 → Schema检索 → LLM生成SQL → SQL校验 → 执行查询 → 结果解读 → 洞察生成 → 可视化** ↑ ↓ ↓ 上下文管理 ← 多轮对话 ← 用户追问 ← 建议下钻 ← 自动洞察 ← 结果缓存 ← 查询超时保护
3️⃣ 答题模板（30 秒电梯版）
"四阶段完整流程。理解层：意图识别（明细/聚合/异常/预测）+RAG检索schema+上下文管理。生成层：Text-to-SQL（schema注入+few-shot+方言适配）+sqlglot语法校验+安全约束（只SELECT/超时30s/限10万行）。执行层：只读副本+OLAP引擎+结果缓存5分钟。洞察层：LLM解读结果+自动发现异常和趋势+可视化建议+下钻建议。核心：不是'LLM生成SQL'而是'理解→生成→执行→洞察'的完整流程，每层都有校验和兜底。"
4️⃣ 高频追问 & 应对
追问 1**：Text-to-SQL 的准确率怎么保证？LLM 生成的 SQL 经常出错怎么办？
三重保障：(1) Schema 增强——不只给 LLM 表结构，还给字段注释、外键关系、枚举值、示例数据。LLM 理解"gender 字段值 1=男 2=女"才能正确生成 WHERE 条件；(2) SQL 校验循环——生成后用 sqlglot 语法检查 + EXPLAIN 验证执行计划。如果语法错误或全表扫描，反馈错误给 LLM 重新生成（最多 3 轮）；(3) 执行结果校验——执行后检查结果是否合理（如销售额不应该为负数、行数不应该为 0）。异常结果触发重新生成。实测：三重保障下 SQL 准确率从 65% 提升到 88%（Spider benchmark）
追问 2：数据库有几百张表，schema 怎么检索？
RAG 方案：(1) 将每张表的 DDL + 注释 + 示例数据作为一个 chunk，用 BGE-M3 编码存入 FAISS；(2) 用户提问时用问题检索 Top-5 最相关的表；(3) 只注入相关表的 schema，而非全量 schema。对于 500 张表的数据库，schema 注入约 2000,\mathrm{tokens}（5\times400=2000）。实测：schema 检索准确率 >90%（Top-5 中包含正确表）。如果用户问题模糊（如"看一下数据"），Agent 追问"您想查看哪个业务领域的数据？销售/库存/用户？"
追问 3：多轮对话中如何理解"按品类拆分"这种省略上下文的请求？
上下文管理策略：(1) 查询历史——保留最近 5 轮的"问题+SQL+结果摘要"。用户说"按品类拆分"时，Agent 从历史中找到"上月销售额"的上下文，理解为"按品类拆分上月销售额"；(2) SQL 修改——不是从零生成新 SQL，而是在前一个 SQL 基础上修改。如前 SQL 是
SELECT SUM(amount) FROM sales WHERE month='2024-07'，修改为SELECT category, SUM(amount) FROM sales WHERE month='2024-07' GROUP BY category；(3) 确认机制——如果上下文不明确，Agent 追问"您是想按品类拆分上月销售额吗？"
5️⃣ 避坑 · 常见错误答法
- ❌ "直接把数据库 schema 全喂给 LLM 就行" → ✅ "几百张表的 schema 可能超过 10 万 tokens，远超上下文窗口。需要 RAG 检索相关表的 schema，只注入 Top-5 相关表。"
- ❌ "LLM 生成 SQL 后直接执行" → ✅ "LLM 可能生成语法错误或危险的 SQL（如全表扫描、笛卡尔积）。必须用 sqlglot 做语法检查 + EXPLAIN 验证执行计划 + 安全约束（只 SELECT/超时/行数限制）。"
- ❌ "返回数据表格就行" → ✅ "用户需要的是'洞察'而非'数据'。LLM 应该解读结果（'上月销售额1200万，环比增长15%'）+ 发现异常（'服装品类下降10%'）+ 建议下钻方向。"
6️⃣ 简历呼应
- 如果你有数据分析 Agent 项目：从"Text-to-SQL 准确率优化"切入，描述你实现的 schema 增强 + SQL 校验循环 + 结果校验方案，给出 Spider benchmark 分数
- 如果你只做过 BI/数据可视化：用"BI→Agent"迁移，说明 SQL/数据建模/可视化的经验直接适用，Agent 增强了自然语言交互和自动洞察能力
- 如果你是校招无项目：用 LangChain + SQLite + GPT-4 搭建一个 Text-to-SQL 原型，测试不同 schema 注入策略对准确率的影响
- "Spider: A Large-Scale Human-Labeled Text-to-SQL Dataset" (Yu et al., 2018)
- "DIN-SQL: Decomposed In-Context Learning for Text-to-SQL" (Pourreza et al., 2023)
- "Text-to-SQL with Large Language Models" (Tai et al., 2023)