项目背景与架构
业务常面临报表固定与看数门槛高的问题。当业务需要直接提问并获取带图表和归因的答案时，常规工具无法满足。核心难点在于多步查询与对比解释的归因逻辑，以及保证结论可信，避免模型凭空捏造归因结果。
架构分为四层。意图与计划层负责将问题分类为取数、对比、归因或预测，规划先看总量再做维度下钻的步骤，并将复杂问题拆解。执行层调用内部 SQL Agent 或指标服务，在多步查询中传递上下文，结构化保留每步的表、数值与时间范围。
归因与叙述层执行维度下钻对比，计算各维度变化对总量的贡献度。生成叙述时，数值全部来自查询结果，模型仅负责组织语言。异常检测采用同环比等统计规则，不依赖模型的主观感觉。交付层采用结论先行加图表的模式，根据问题类型选择趋势、构成或对比图表，确保每步查询带有可回溯的引用，实现数字与结论分离。
面试官会挖的难点
- 「归因怎么避免瞎编」 核心在于贡献度分解等确定性计算先行，让模型只解释数字。要求归因结论必须标注基于哪些维度的对比，避免单因子归因谬误，无法归因时直接回复不知道而不是让模型硬编。
- 「多步查询上下文丢失」 依赖对话历史让模型复述容易导致条件遗漏。解决思路是将中间查询结果结构化存储与传递，每一步的输出作为下一步的明确输入，不依赖模型记忆来维持查询状态。
- 「指标口径与业务对不上」 模型容易自创指标名称或计算逻辑。应对方法是在架构中引入指标语义层统一定义，Agent 必须调用定义好的实体。图表选型也需按问题类型严格映射，不让模型自由发挥。
指标怎么讲
评测集主要通过回放历史真实的分析需求来构建。端到端指标重点关注问题解决率，即业务确认回答有用的比例，以及多轮对话的完成率。
过程指标需拆解到具体链路，包括查询步骤的成功率、归因接受率，以及平均轮次与耗时。通过对比基线版本，证明引入结构化意图规划与贡献度计算后，问题解决率与归因接受率均呈现正向增长趋势。
简历怎么写
- 构建 ChatBI 数据分析 Agent，设计意图规划、多步取数与贡献度归因链路，实现结论先行的叙述生成，数值全部引用查询结果以保障可信度。
- 搭建指标语义层与图表选型规则，统一业务口径，并采用统计规则替代模型主观判断进行异常检测，优化图表渲染与分析的准确性。
- 基于历史真实分析需求回放构建评测集，迭代查询链路与归因逻辑，带动问题解决率与归因接受率持续提升。
常见 badcase 与治理
- 归因单一化：现象是模型在解释数据时只挑最显眼维度下结论。问题出在归因层缺乏多维约束。治理动作是强制执行多维度的贡献度对比，要求综合各维度数据后再生成结论。
- 数字幻觉：现象是模型在生成叙述时自行口算数值。问题出在归因与叙述层未限制模型生成边界。治理动作是切断模型心算权限，规定数值一律引用工具返回结果并进行模板填槽。
- 问题过宽：现象是用户输入模糊指令导致查询无从下手。问题出在意图与计划层缺乏多轮引导。治理动作是在意图层增加反问机制，引导业务收窄分析维度与时间范围。
面试讲法收束
一分钟内可以将项目结构化为四个层次。先讲业务看数门槛高的问题背景，接着阐述计划、执行、归因三层核心设计，强调数字与解释分离。然后说明通过贡献度分解与引用回溯建立的可信机制。最后客观指出在开放预测类问题上仍然表现较弱的边界。
怎么扩展
取数后端可以向下接入 Text2SQL Agent，处理更复杂的非标准化查询需求。交互模式上从被动问答向主动洞察延展，定时扫描数据异常并主动推送分析报告。预测类需求应接入专业的时序模型，而非依赖大语言模型硬猜。
—— 本场面试完 ——