1. FreeWheel ChatBI 项目背景与核心价值视频广告行业正面临数据分析效率的瓶颈。传统BI工具需要用户掌握复杂的SQL编写技能业务人员每次获取数据都需要经过提需求-等待开发-验证结果的长周期流程。在FreeWheel这样的全球广告技术平台每天要处理数亿级别的广告交易数据分析师需要快速响应各种业务问题为什么某个广告主的曝光量突然下降哪个地区的填充率出现异常不同销售渠道的收益对比如何ChatBI系统的出现彻底改变了这一局面。我们构建的Insights Chatbot实现了几个突破性价值自然语言交互业务人员可以直接用帮我看看最近一周北美地区视频广告的填充率趋势这样的日常用语获取数据智能分析自动化系统能自动检测数据异常并通过下钻分析定位到具体的问题维度如特定广告位、设备类型或地理位置知识沉淀复用将常见分析场景固化为可重复使用的工作流避免重复劳动这个项目的独特之处在于它不是简单的SQL翻译器而是深度融合了广告业务知识、大模型能力和专业分析算法的智能系统。举个例子当用户询问为什么XYZ广告主昨天的曝光量下降时系统会自动执行以下完整分析链路确认异常时间点是全天下降还是特定时段检查相关指标填充率、竞价成功率等按地理位置、设备类型等下钻分析定位到具体问题维度如iOS设备的填充率下降给出可能的原因和建议措施2. 系统架构设计解析2.1 整体技术栈布局系统的架构设计遵循三层能力融合原则[模型层] ├─ Azure OpenAI GPT-4 ├─ AWS Bedrock Claude └─ 自研时序预测模型(N-BEATS/Timer) [数据层] ├─ Presto分布式查询 ├─ 分层数据仓库 └─ 统一指标目录 [应用层] ├─ 智能选表引擎 ├─ Text2SQL转换器 ├─ 分析算法库 └─ 可视化渲染这种架构的关键优势在于模型层多路冗余当某个云服务出现延迟时可自动切换到备用模型数据层抽象统一通过Presto中间层屏蔽底层数据存储差异应用层模块解耦各组件通过标准化API通信便于独立升级2.2 核心创新点混合式分析引擎传统BI工具面临灵活度与准确性不可兼得的困境。我们独创的WorkflowAgent双模引擎完美解决了这个问题预定义工作流(Workflow)适用于高频分析场景如曝光量异常分析的标准路径异常检测 → 填充率检查 → 竞价分析 → 流量质量评估每个节点都经过业务专家精心调校准确率可达95%以上。动态智能体(Agent)处理长尾需求时系统会启动基于LangGraph的AgentPlanner生成分析计划Executor调用相应工具遇到异常时自动调整参数或发起追问例如处理为什么夏季周末的广告收益低于平时这类复杂问题时Agent会自主组合以下操作对比不同季节的周末/工作日数据分析各广告位的填充率差异检查竞争对手的竞价行为变化3. 关键技术实现细节3.1 让大模型理解广告业务广告行业有大量专业术语和业务逻辑我们通过知识注入三明治方案解决这个问题System Prompt基础知识约500字FreeWheel业务概览 - Supply Side: 流量提供方(如HBO、迪士尼) - Demand Side: 广告需求方(如宝洁、丰田) 核心指标 - 填充率 广告展示数/广告请求数 - eCPM 每千次展示收益 ...动态RAG检索基于Chroma向量库 当用户提到MKPL订单时系统会自动检索MKPL(Marketplace): 私有交易市场包含以下特性 - 保量交易(Guaranteed Deal) - 优先交易(Priority Deal) 相关数据表: mkpl_orders_fact业务规则校验层在SQL生成后会检查是否符合业务规则例如-- 会被系统拒绝的查询 SELECT * FROM inventory_fact WHERE cpm 0.1 -- 原因CPM低于0.1美元不符合业务常识3.2 智能选表引擎实现面对300多张表、上千个字段的复杂环境选表准确率直接决定查询效率。我们的解决方案包含四个关键步骤多路召回策略def recall_tables(query): # 向量检索(语义匹配) vector_results chroma.similarity_search(query) # 关键词检索(精确匹配) keyword_results bm25_search(query) # 图检索(关联扩展) graph_results graph_rag(query) return merge_results(vector_results, keyword_results, graph_results)业务规则过滤建立了一套包含87条规则的校验体系例如历史数据查询必须使用聚合表实时数据不能JOIN维度表某些指标只能按特定维度组合LLM智能决策设计特定的prompt结构## 任务 从候选表中选择最适合查询[用户问题]的表 ## 业务背景 [相关业务说明] ## 候选表 1. table_a: [描述][适用场景] 2. table_b: [描述][适用场景] ## 选择原则 - 时效性近期数据用_agg表 - 性能大表避免全表扫描 - 完整性需要包含[关键字段]闭环验证机制每个查询会记录候选表排序最终选择依据执行性能数据 这些数据用于持续优化选表模型3.3 Text2SQL的工业级实现不同于学术界的demo级实现我们的系统需要处理真实业务中的各种复杂情况字段歧义解决方案当用户查询收入时系统会区分gross_revenue(毛收入)net_revenue(净收入)recognized_revenue(确认收入)通过字段注释体系实现精准映射/* name: 收入 type: metric subtype: financial calculation: sum(amount) * exchange_rate available_dimensions: country, sales_channel */时区智能处理广告数据涉及全球时区系统会自动识别用户所在时区(通过账号配置)将查询时间转换为UTC结果展示时转回本地时间-- 生成的SQL会包含时区转换 WHERE event_time BETWEEN CONVERT_TZ(2024-01-01 00:00:00,America/New_York,UTC) AND CONVERT_TZ(2024-01-02 23:59:59,America/New_York,UTC)SQL优化策略分区裁剪自动添加日期分区条件谓词下推将过滤条件尽可能下推到子查询采样查询对探索性查询使用TABLESAMPLE4. 智能数据分析实战4.1 异常检测系统我们构建了多层次的异常检测体系统计基线法def detect_anomaly(series): # 基于历史数据的3sigma原则 mean series.rolling(28d).mean() std series.rolling(28d).std() return (series mean 3*std) | (series mean - 3*std)深度学习模型使用N-BEATS模型预测预期范围model NBEATS( input_chunk_length24, output_chunk_length12, generic_architectureTrue ) model.fit(train_series) pred model.predict(n12)业务规则引擎例如节假日流量波动不算异常新上线的广告位前3天不报警小流量活动(1000次展示)忽略4.2 根因分析工作流典型的曝光量下降分析路径时间定位确认是全天下降还是时段性对比同期历史数据维度下钻def drill_down(df, metric, dimensions): for dim in dimensions: grouped df.groupby(dim)[metric].sum() anomaly_scores compute_anomaly(grouped) if anomaly_scores.max() threshold: return dim, grouped.idxmax() return None关联指标检查填充率异常 → 检查广告库存竞价成功率低 → 分析竞争对手渲染错误率高 → 排查创意素材输出可视化报告自动生成包含以下要素的Markdown报告异常时间点截图关键维度下钻结果关联指标变化趋势可能原因列表5. 生产环境最佳实践5.1 性能优化方案查询加速策略预计算常用维度组合建立结果缓存层(TTL15分钟)异步执行长耗时查询资源隔离方案# Kubernetes资源配额 resources: queries: limits: cpu: 2 memory: 4Gi requests: cpu: 0.5 memory: 1Gi5.2 安全合规设计数据脱敏流程本地模型识别敏感字段def detect_pii(text): return re.findall(r\b\d{3}-\d{2}-\d{4}\b, text) # SSN模式替换为占位符-- 原始查询 SELECT * FROM users WHERE ssn 123-45-6789 -- 发送给LLM的查询 SELECT * FROM users WHERE ssn [SSN_1]结果回填权限控制矩阵角色数据访问范围操作权限分析师全部聚合数据查询/导出运营所属区域数据仅查询广告主自有活动数据受限查询5.3 持续改进机制反馈学习闭环用户点赞/点踩LLM自动分析差异人工复核关键案例更新训练数据集A/B测试框架class ABTest: def __init__(self): self.variants { text2sql_v1: Text2SQLV1(), text2sql_v2: Text2SQLV2() } def evaluate(self, query): # 随机分配实验组 variant random.choice(list(self.variants.values())) result variant.execute(query) log_metrics(result) return result6. 项目演进与行业启示FreeWheel ChatBI系统上线后产生了显著的业务影响数据分析需求响应时间从平均4小时缩短到3分钟业务人员自主分析比例提升至65%异常检测准确率达到92%误报率低于5%这个项目的成功实践为行业提供了几个重要启示领域知识工程仍然关键大模型需要与行业知识深度结合我们构建的广告业务知识图谱包含1,200业务概念500指标定义300分析场景模板混合智能架构是现实选择完全依赖LLM或传统规则都会遇到瓶颈我们的经验表明高频场景用预定义工作流(准确率高)长尾需求用动态Agent(覆盖度广)关键环节保留人工复核(风险可控)可解释性决定产品接受度我们通过以下设计建立用户信任展示SQL生成过程可视化分析路径标注数据置信度提供人工复核通道未来演进方向包括引入多模态分析(结合广告创意内容)开发预测性分析(而不仅是事后诊断)构建跨客户基准对比能力这个项目的核心经验在于真正的智能数据分析系统不是要取代人类专家而是通过人机协同放大人类的判断力和创造力。当一位广告运营人员能快速验证自己的业务假设当数据分析师能从重复劳动中解放出来专注深度洞察这才是技术创造的真实价值。
1. FreeWheel ChatBI 项目背景与核心价值视频广告行业正面临数据分析效率的瓶颈。传统BI工具需要用户掌握复杂的SQL编写技能业务人员每次获取数据都需要经过提需求-等待开发-验证结果的长周期流程。在FreeWheel这样的全球广告技术平台每天要处理数亿级别的广告交易数据分析师需要快速响应各种业务问题为什么某个广告主的曝光量突然下降哪个地区的填充率出现异常不同销售渠道的收益对比如何ChatBI系统的出现彻底改变了这一局面。我们构建的Insights Chatbot实现了几个突破性价值自然语言交互业务人员可以直接用帮我看看最近一周北美地区视频广告的填充率趋势这样的日常用语获取数据智能分析自动化系统能自动检测数据异常并通过下钻分析定位到具体的问题维度如特定广告位、设备类型或地理位置知识沉淀复用将常见分析场景固化为可重复使用的工作流避免重复劳动这个项目的独特之处在于它不是简单的SQL翻译器而是深度融合了广告业务知识、大模型能力和专业分析算法的智能系统。举个例子当用户询问为什么XYZ广告主昨天的曝光量下降时系统会自动执行以下完整分析链路确认异常时间点是全天下降还是特定时段检查相关指标填充率、竞价成功率等按地理位置、设备类型等下钻分析定位到具体问题维度如iOS设备的填充率下降给出可能的原因和建议措施2. 系统架构设计解析2.1 整体技术栈布局系统的架构设计遵循三层能力融合原则[模型层] ├─ Azure OpenAI GPT-4 ├─ AWS Bedrock Claude └─ 自研时序预测模型(N-BEATS/Timer) [数据层] ├─ Presto分布式查询 ├─ 分层数据仓库 └─ 统一指标目录 [应用层] ├─ 智能选表引擎 ├─ Text2SQL转换器 ├─ 分析算法库 └─ 可视化渲染这种架构的关键优势在于模型层多路冗余当某个云服务出现延迟时可自动切换到备用模型数据层抽象统一通过Presto中间层屏蔽底层数据存储差异应用层模块解耦各组件通过标准化API通信便于独立升级2.2 核心创新点混合式分析引擎传统BI工具面临灵活度与准确性不可兼得的困境。我们独创的WorkflowAgent双模引擎完美解决了这个问题预定义工作流(Workflow)适用于高频分析场景如曝光量异常分析的标准路径异常检测 → 填充率检查 → 竞价分析 → 流量质量评估每个节点都经过业务专家精心调校准确率可达95%以上。动态智能体(Agent)处理长尾需求时系统会启动基于LangGraph的AgentPlanner生成分析计划Executor调用相应工具遇到异常时自动调整参数或发起追问例如处理为什么夏季周末的广告收益低于平时这类复杂问题时Agent会自主组合以下操作对比不同季节的周末/工作日数据分析各广告位的填充率差异检查竞争对手的竞价行为变化3. 关键技术实现细节3.1 让大模型理解广告业务广告行业有大量专业术语和业务逻辑我们通过知识注入三明治方案解决这个问题System Prompt基础知识约500字FreeWheel业务概览 - Supply Side: 流量提供方(如HBO、迪士尼) - Demand Side: 广告需求方(如宝洁、丰田) 核心指标 - 填充率 广告展示数/广告请求数 - eCPM 每千次展示收益 ...动态RAG检索基于Chroma向量库 当用户提到MKPL订单时系统会自动检索MKPL(Marketplace): 私有交易市场包含以下特性 - 保量交易(Guaranteed Deal) - 优先交易(Priority Deal) 相关数据表: mkpl_orders_fact业务规则校验层在SQL生成后会检查是否符合业务规则例如-- 会被系统拒绝的查询 SELECT * FROM inventory_fact WHERE cpm 0.1 -- 原因CPM低于0.1美元不符合业务常识3.2 智能选表引擎实现面对300多张表、上千个字段的复杂环境选表准确率直接决定查询效率。我们的解决方案包含四个关键步骤多路召回策略def recall_tables(query): # 向量检索(语义匹配) vector_results chroma.similarity_search(query) # 关键词检索(精确匹配) keyword_results bm25_search(query) # 图检索(关联扩展) graph_results graph_rag(query) return merge_results(vector_results, keyword_results, graph_results)业务规则过滤建立了一套包含87条规则的校验体系例如历史数据查询必须使用聚合表实时数据不能JOIN维度表某些指标只能按特定维度组合LLM智能决策设计特定的prompt结构## 任务 从候选表中选择最适合查询[用户问题]的表 ## 业务背景 [相关业务说明] ## 候选表 1. table_a: [描述][适用场景] 2. table_b: [描述][适用场景] ## 选择原则 - 时效性近期数据用_agg表 - 性能大表避免全表扫描 - 完整性需要包含[关键字段]闭环验证机制每个查询会记录候选表排序最终选择依据执行性能数据 这些数据用于持续优化选表模型3.3 Text2SQL的工业级实现不同于学术界的demo级实现我们的系统需要处理真实业务中的各种复杂情况字段歧义解决方案当用户查询收入时系统会区分gross_revenue(毛收入)net_revenue(净收入)recognized_revenue(确认收入)通过字段注释体系实现精准映射/* name: 收入 type: metric subtype: financial calculation: sum(amount) * exchange_rate available_dimensions: country, sales_channel */时区智能处理广告数据涉及全球时区系统会自动识别用户所在时区(通过账号配置)将查询时间转换为UTC结果展示时转回本地时间-- 生成的SQL会包含时区转换 WHERE event_time BETWEEN CONVERT_TZ(2024-01-01 00:00:00,America/New_York,UTC) AND CONVERT_TZ(2024-01-02 23:59:59,America/New_York,UTC)SQL优化策略分区裁剪自动添加日期分区条件谓词下推将过滤条件尽可能下推到子查询采样查询对探索性查询使用TABLESAMPLE4. 智能数据分析实战4.1 异常检测系统我们构建了多层次的异常检测体系统计基线法def detect_anomaly(series): # 基于历史数据的3sigma原则 mean series.rolling(28d).mean() std series.rolling(28d).std() return (series mean 3*std) | (series mean - 3*std)深度学习模型使用N-BEATS模型预测预期范围model NBEATS( input_chunk_length24, output_chunk_length12, generic_architectureTrue ) model.fit(train_series) pred model.predict(n12)业务规则引擎例如节假日流量波动不算异常新上线的广告位前3天不报警小流量活动(1000次展示)忽略4.2 根因分析工作流典型的曝光量下降分析路径时间定位确认是全天下降还是时段性对比同期历史数据维度下钻def drill_down(df, metric, dimensions): for dim in dimensions: grouped df.groupby(dim)[metric].sum() anomaly_scores compute_anomaly(grouped) if anomaly_scores.max() threshold: return dim, grouped.idxmax() return None关联指标检查填充率异常 → 检查广告库存竞价成功率低 → 分析竞争对手渲染错误率高 → 排查创意素材输出可视化报告自动生成包含以下要素的Markdown报告异常时间点截图关键维度下钻结果关联指标变化趋势可能原因列表5. 生产环境最佳实践5.1 性能优化方案查询加速策略预计算常用维度组合建立结果缓存层(TTL15分钟)异步执行长耗时查询资源隔离方案# Kubernetes资源配额 resources: queries: limits: cpu: 2 memory: 4Gi requests: cpu: 0.5 memory: 1Gi5.2 安全合规设计数据脱敏流程本地模型识别敏感字段def detect_pii(text): return re.findall(r\b\d{3}-\d{2}-\d{4}\b, text) # SSN模式替换为占位符-- 原始查询 SELECT * FROM users WHERE ssn 123-45-6789 -- 发送给LLM的查询 SELECT * FROM users WHERE ssn [SSN_1]结果回填权限控制矩阵角色数据访问范围操作权限分析师全部聚合数据查询/导出运营所属区域数据仅查询广告主自有活动数据受限查询5.3 持续改进机制反馈学习闭环用户点赞/点踩LLM自动分析差异人工复核关键案例更新训练数据集A/B测试框架class ABTest: def __init__(self): self.variants { text2sql_v1: Text2SQLV1(), text2sql_v2: Text2SQLV2() } def evaluate(self, query): # 随机分配实验组 variant random.choice(list(self.variants.values())) result variant.execute(query) log_metrics(result) return result6. 项目演进与行业启示FreeWheel ChatBI系统上线后产生了显著的业务影响数据分析需求响应时间从平均4小时缩短到3分钟业务人员自主分析比例提升至65%异常检测准确率达到92%误报率低于5%这个项目的成功实践为行业提供了几个重要启示领域知识工程仍然关键大模型需要与行业知识深度结合我们构建的广告业务知识图谱包含1,200业务概念500指标定义300分析场景模板混合智能架构是现实选择完全依赖LLM或传统规则都会遇到瓶颈我们的经验表明高频场景用预定义工作流(准确率高)长尾需求用动态Agent(覆盖度广)关键环节保留人工复核(风险可控)可解释性决定产品接受度我们通过以下设计建立用户信任展示SQL生成过程可视化分析路径标注数据置信度提供人工复核通道未来演进方向包括引入多模态分析(结合广告创意内容)开发预测性分析(而不仅是事后诊断)构建跨客户基准对比能力这个项目的核心经验在于真正的智能数据分析系统不是要取代人类专家而是通过人机协同放大人类的判断力和创造力。当一位广告运营人员能快速验证自己的业务假设当数据分析师能从重复劳动中解放出来专注深度洞察这才是技术创造的真实价值。
