CVTE 数据分析师面经（含 AI 取数助手设计）

《面试题目》

1. 简单做一下自我介绍。
2. 你对未来 3 到 5 年的职业发展有规划吗？
3. 你理想的工作模式是什么？
4. 在实习中，你有没有主动发现问题、并用数据分析能力推动解决的案例？
5. 指标口径不统一是数据分析和运营的常见问题。假设两个部门对同一指标存在争议、互不认可，你作为参与指标体系建设的数据分析师，会如何处理？
6. 假设需要建设经营分析驾驶舱，供业务负责人每日查看，作为数据分析师，接到这个需求你会如何设计？
7. 假设你搭建完成的看板上线后，业务反馈页面加载需要 20 秒，速度很慢。你如何定位和优化？
8. 数分岗位对 AI 能力要求较高，业务有大量提数需求。假设公司有 1000 名销售，希望查询昨日业绩，团队准备开发自然语言取数助手，销售一句话即可查询昨日业绩，支持下钻分析、自动输出数据报告。你会如何设计，以及如何验收这个能力？
9. 完善知识库之后，模型依然存在幻觉，还有哪些手段提升数据查询准确率？
10. 你提到多 Agent 协作。如果上游 Agent 输出错误，如何校验、建立纠错机制？
11. AI 时代数分也需要写 SQL。你认为 AI 辅助写 SQL 有哪些注意事项，如何保证 AI 生成的 SQL 可以直接使用？
12. 这套多 Agent 智能取数助手，业务推广时，业务人员习惯使用 Excel 表格、对 AI 工具存在不信任、担心数据不准确。你会如何推广这个工具，推动业务使用？
13. 三段实习中，有没有遇到很难处理的问题？可以举案例，数开或数据质量运营相关都可以。
14. 在你理解中，当前 AI 工作模式还有哪些优化方向？
15. 你们实习生内部 AI 使用政策如何？是否所有模型都可以随意调用，还是公司有自研大模型平台、可以调用 API、存在额度限制？
16. 反问：数分两个培养方向最终如何确定？是公司分配还是候选人自主选择？
17. 反问：数据同学是统一在大部门，还是分配到业务团队？例如销售团队配置专属数分，还是统一在数据部门接收需求？

《参考解析》

指标口径冲突怎么处理：这类问题的关键是先承认「口径没有绝对对错，只有服务于什么决策」。落地做法分四步：① 把争议拆成具体差异项——时间口径（自然日/滚动 24 小时/财务月）、主体口径（下单用户/支付用户/去重维度）、状态口径（下单/支付/发货/退款是否剔除）、数据源（埋点/业务库/财务系统），通常一列就发现两边说的不是同一个东西；② 拉上双方业务方 + 数据负责人开一次口径对齐会，形成书面定义，写进指标字典（口径、SQL、责任人、变更记录）；③ 在指标平台上做「一个指标一个定义、一个出口」，看板和取数都从同一张 DWS/ADS 表出，禁止各团队自己写 SQL 复算；④ 后续变更走审批与公告，历史数据是否回溯重算要明确说明。补充一句很有加分：指标治理的收益要用「避免一次误决策的成本」来汇报，否则业务方没有动力配合。

经营分析驾驶舱的设计：先问清「谁看、看什么决策、多久看一次」，驾驶舱不是把指标堆上去。① 指标体系：北极星指标（营收/毛利）→ 一级拆解（收入 = 客户数 × 客单价，或按产品线/区域/渠道拆）→ 二级过程指标，遵循 MECE；每个指标都标口径、更新频率、责任部门。② 分层：顶部核心 KPI 卡（带目标值与同比环比、达成率），中间趋势与结构（趋势线、瀑布图、占比），底部明细与下钻入口。③ 数据链路：ODS → DWD → DWS/ADS 预聚合，按「天/周/月」粒度预计算好，看板只查聚合结果；重点指标做 T+1 甚至准实时（小时级）批量刷新，并加上数据更新时间与数据质量校验结果，让业务知道数据是不是可信。④ 性能与权限：结果集控制、缓存、按角色做行级权限（区域/事业部）。⑤ 交互原则：一屏内看到「好不好、差在哪、下一步查什么」，异常用阈值/环比预警标红，不要超过 3 层下钻。

看板加载 20 秒怎么定位：先分层定位，不要上来就说加索引。① 前端/网络层：浏览器 Network 面板看是哪个请求慢——是首屏 JS 体积大、还是某个接口 20 秒；同时看是不是并发请求太多、被浏览器同域并发限制排队。② 接口/查询层：看慢 SQL 日志或 APM 链路，按「扫描行数、是否走分区/索引、是否大表 join、是否有 select *、是否有全表 count(distinct)」逐项排查；常见病根是看板直连明细表、每次实时算同比环比。③ 存储层：确认是否命中了预聚合表、分区裁剪是否生效。优化手段按性价比排序：把计算前置到 ETL/物化视图做预聚合 → 给过滤字段和分区键建索引、调整分区粒度 → 减少列和宽表 join、把多指标合并成一次查询 → 结果缓存（分钟级 TTL，业务能接受延迟的话）→ 前端分页/懒加载 + 骨架屏 + 明确 loading 态。最后一定要加数据更新时间和看板加载埋点，否则优化完没有度量。

自然语言取数助手怎么设计与验收：设计上建议拆成四个模块。① 语义层：把「昨日业绩」「销售额」这类业务词映射到指标字典（指标 + 维度 + 时间口径 + 权限过滤），这是准确率的根基——不要让模型直接对库表裸奔，模型只允许生成基于语义层/宽表的受限 SQL。② 查询生成：Text-to-SQL 用带表结构 DDL、字段注释、少量同义句示例（few-shot）和枚举值字典做提示，输出后做语法校验 + 白名单校验（只读、只允许访问已授权的表/字段、强制带上行级权限条件、强制 LIMIT 和超时）。③ 执行与容错：超时/空结果时给出可执行的下一步建议；结果一律回带口径说明（指标定义、时间范围、数据更新时间）。④ 呈现：一句话得到结果 + 一句话结论 + 图表，支持下钻到明细，自动生成日报/周报。验收要分两层：一层是能力指标——准备 200~500 条真实问法（含口语、错别字、多指标、多轮追问）做测试集，看执行准确率（SQL 语义是否正确）和忠实度（结论是否与 SQL 结果一致），而不是只看「SQL 能不能跑通」；另一层是权限与安全验收（越权取数、注入、跨部门数据）；再加上业务侧指标：采用率、问法覆盖率、人工干预率、单次取数耗时对比（原来找数分提需求要多久）。上线用灰度 + 双跑比对（AI 结果与人工口径一致才算通过）。

怎么压幻觉、怎么纠错：幻觉在取数场景里的表现是「编字段、编表、编数值、编口径」。手段：① 收窄自由度——模型只能从语义层选指标和维度，不允许自由生成表名字段名；② 检索增强——用业务知识库（指标定义、同义词、历史问法）做召回再拼提示，而不是只靠模型记忆；③ 输出结构化+校验——让模型输出结构化查询计划（指标、维度、过滤、时间），再由确定性代码翻译成 SQL，这样能被程序校验；④ 结果自检——执行前后做一致性校验：SQL 是否只读、行数是否异常、与上一周期偏离是否超过阈值（偏离就提示确认而不是直接给结论）、关键数字是否与底层明细抽样对齐；⑤ 低置信度就拒答或转人工，并记录 badcase 回流。多 Agent 纠错则是：上游 Agent 的输出必须带结构化中间产物，下游用规则校验 + 第二次独立生成做交叉验证（两个方案不一致就升级人工），再加一个专门的 critic Agent 按固定清单审查，所有决策留痕可回放；重试要有次数上限，避免错误被放大。

AI 辅助写 SQL 的注意事项：① 安全边界——只给只读账号，强制表/字段白名单与行级权限，禁止 DDL/DML，强制 LIMIT 与超时；② 正确性——务必人工核对口径（时间范围、是否去重、是否剔除退款/测试单），join 条件最容易错（一对多导致指标翻倍），建议先在样本分区上跑一遍再全量；③ 可读与可维护——要求统一格式化、加注释、把魔法值换成参数，指标计算尽量复用语义层而不是复制粘贴；④ 性能——检查是否命中分区与索引、避免 select *、避免在大表上用函数包住过滤字段、注意 count(distinct) 的开销；⑤ 流程——AI 生成的 SQL 进生产前过一遍代码评审或至少双人抽查，产出物入库到指标字典，形成可复用的资产。一句可以直接说的结论：AI 提效在于「初稿」，责任仍然在人，验收标准是结果与人工口径一致。

面试复盘：这场面试基本没有考数分传统八股（概率统计、A/B 实验），而是围绕 AI 落地 + 指标体系设计展开，属于典型的「数分岗位 AI 化」问法。反问环节面试官补充了岗位信息：数分分经营分析（关注营收、成本、预算、费用、整体绩效等结果指标）和业务数据分析（偏过程指标）两个方向；团队有两种模式，业务端渗透模式是小团队对接特定业务板块，平台端按领域（供应链、质量、营销、研发、财务）覆盖集团。回答这类设计题时，建议固定用「需求澄清 → 指标/口径 → 数据链路 → 交互与权限 → 度量与验收」的框架，比零散输出更容易被认可。