用户增长业务下的本体论数仓建设实践演讲介绍（讲师必填）当前用户增长业务存在多端数据割裂、指标口径混乱、用户ID不统一等问题，导致增长分析失真，精细化运营落地难，原有离线实时双栈架构维护成本高、数据延迟最高达2小时。本次摒弃传统分层数仓模式，采用用户本体论数仓架构，以用户OneID为核心重构数据体系，统一埋点与指标标准。落地中攻克了百亿级用户行为数据合并、多源数据冲突、实时增量更新三大痛点，通过本体建模、增量计算、口径归一化方案优化，实现指标偏差大幅减低，增长策略迭代效率大幅提升，精准赋能拉新、促活、留存全链路增长运营。

演讲提纲：

1. 业务背景与行业痛点

- 用户增长业务核心诉求：全链路用户行为追踪、精细化分层、增长效果归因、策略快速迭代

- 传统数仓核心问题：数据孤岛严重、指标口径不统一、实时离线架构割裂、海量数据查询低效

- 业务负面影响：增长分析失真、用户分层不准、运营策略滞后、资源投放浪费

2. 技术方案选型与核心思路

- 方案对比：传统分层数仓VS用户本体论数仓的适配差异

- 核心选型：以用户本体为核心、OneID全域关联、实时离线一体化架构

- 技术栈组合：Flink实时计算+Spark离线复盘+本体建模分层+自动化质量管控

- 核心设计：用户实体统一、行为事件归一、增长指标标准化体系搭建

3. 落地核心挑战与攻坚过程

- 数据层：多源异构数据冲突、百亿级用户行为数据合并与清洗难题

- 计算层：实时数据积压、增量更新成本高、查询响应慢问题

- 业务层：历史指标体系臃肿、业务侧口径认知不统一，落地适配难

4. 针对性解决思路与落地方案

- 数据治理：精简冗余埋点、统一事件标准、搭建OneID全域映射体系

- 架构优化：实时增量计算替代全量刷新，解决数据延迟与资源浪费问题

- 机制建设：建立指标归口管理、自动化数据校验、问题快速响应机制

5. 落地成效与数据复盘

- 技术成效：数据延迟、指标准确率、计算资源消耗优化数据

- 业务成效：用户分层精准度、增长策略迭代效率、投放ROI提升效果

6. 现存短板与未来迭代规划

- 当前方案未解决的痛点瓶颈

- 短期优化：智能化数据质检、标签体系轻量化迭代

- 长期规划：AI赋能用户增长预测、自动化策略归因、数仓成本精细化管控

听众收益：

1. 架构认知升级：打破传统分层数仓固化思维，掌握用户本体论数仓的核心设计理念，理解用户增长场景下“以实体为核心”相较于“以流程为核心”的架构优势，明确增长数仓专属的建模逻辑与适配场景。

2. 实战问题可复用经验：获取用户增长数仓落地的高频痛点解决方案，包括多源数据归一、指标口径统一、实时离线架构融合、海量行为数据高效处理等实战方法，可直接迁移至企业用户运营、精细化增长相关数仓建设场景。

3. 业务技术融合思维：学会从增长业务视角反向定义数仓建设标准，掌握“技术落地服务业务增长”的实操路径，规避数仓建设重技术、轻业务、沦为数据孤岛的常见问题，提升数据驱动增长的落地能力。

当 LLM 能力渗入数据平台，一个绕不开的问题是：数据能力该封装成 Skill 还是 Agent？全做成 Agent 会带来成本失控与能力重复；全做成 Tool 又撑不起归因、洞察、SQL 生成等多步决策场景。我们提出 Skill（原子能力层）/ Agent（场景编排层）/ 项目空间（治理层）的三层抽象，通过统一接口契约让 Skill 在多个 Agent 间复用，通过项目空间实现个人 → 空间 → 平台的三级贡献分发。目前已支撑探索分析、归因、洞察、SQL 生成等多个场景 Agent，底层 Skill 跨 Agent 复用率显著提升，个人贡献的能力也能沉淀为平台资产。本分享将正面回答"Skill 和 Agent 到底怎么分"这一高频争论，并复盘真实的设计取舍与踩坑。

演讲提纲：

一、业务背景与问题定义
1. 数据平台面对探索性、诊断性需求的响应困境
2. LLM 引入后的两种极端：全 Agent 化 vs 纯 Tool Use，各自失效的原因
3. 数据领域的独特张力：确定性 × 决策性并存

二、方案选型与核心架构
1. 三层抽象：Skill（能力层）/ Agent（编排层）/ 项目空间（治理层）
2. Skill 的接口契约：输入输出 / 副作用 / 权限 / 幂等
3. Agent 的编排模式：ReAct、Plan-Execute、人工介入
4. 项目空间的治理职责：发布订阅、权限穿透、生命周期

三、边界辨析：Skill 与 Agent 的五维判据
1. 是否用 LLM / 是否多步规划 / 是否有状态 / 面向谁 / 失败语义
2. 真实争论：SQL 生成到底是 Skill 还是 Agent？
3. 反模式：什么能力不该做成 Agent，什么能力不该做成 Skill

四、落地挑战与实证案例
1. 探索分析 / 归因 / 洞察 / SQL 生成：Agent 共用 Skill 的复用图谱
2. 踩坑：Skill 粒度失控、命名语义重叠、质量参差、贡献动力不足

五、贡献机制、未来规划与总结
1. 个人 → 空间 → 平台的三级分发机制
2. Skill 自动评测、Agent 能力图谱、跨空间能力流转
3. 开放问题：私有 Skill 体系与 MCP / A2A 开放协议如何共处

听众收益：

1. 一套可迁移的双层抽象方法论：掌握 Skill 与 Agent 的边界判据，能在自己的数据平台中落地分层能力架构，避免"每个需求都做一个 Agent"的失控。
2. 数据领域 Skill 设计经验：针对归因、洞察、SQL 生成等复杂场景，理解哪些原子能力值得沉淀为 Skill、哪些应当封装为 Agent，以及标签系统在其中的定位。
3. 能力贡献生态的工程取舍：理解个人 → 空间 → 平台的三级分发机制，在质量、权限、复用之间取得平衡，避免"人人可建"沦为"无人敢用"。

奇虎360做了一件挺有意思的事——在公司云数仓整体架构之上，搭了一个能"聊着天就把数据查了"的 AI 应用。一开始的想法很简单：让业务同学不用写 SQL，用自然语言就能取数。但做着做着发现，想让它从"会查数"变成"懂业务"，中间隔着一座大山——语义层。大模型写 SQL 这件事，学术数据集上能跑到 85%，一进真实数仓就现原形：几百张表、上万个字段、口径靠口口相传，准确率断崖式下跌，而且错了你都不知道它错在哪。更麻烦的是，业务不可能等你花半年把语义层建好再上线——大多数企业手里就只有散落的表文档和老员工的"这个字段是那个意思"。我们的做法是"半成品冷启动，边跑边长"：先用双路径混合路由让系统跑起来——语义完整的走确定性编译引擎，只有表和文档的走 RAG 降级，同时给每一条结果带上置信度分数，用户一看就知道"这条是系统算出来的，那条是系统猜的"；然后从薄 API 起步，查数、归因、决策逐层长成 Skill，高频使用的经验再反向沉淀为语义资产；配上三级评测加反馈飞轮，让质量可度量、可回溯。这套方案目前已支撑内部大数据集群运维、S3 、PoleFS 存储运维的指标分析与归因场景，同时、Ops机房运维、文库搜索、会员中台等跨部门业务也已接入使用。语义资产在真实使用中持续自生长——这条路我们已经在走了，来跟大家聊聊踩过的坑和拿到的一手经验。

演讲提纲：

一、范式转变：从"模型写 SQL"到"引擎写 SQL"
1. 学术基准的幻觉：Spider 85% → 真实数仓 50%，差距来自哪里？
2. 行业共识形成：不确定的归模型，确定的归引擎
3. 但新问题随之而来：语义层没建完的时候怎么办？

二、双路径混合路由：语义层不完善时的冷启动方案
1. AST 主路径：语义层完备时，LLM 仅做意图提取 → 确定性编译器生成 SQL，不走"猜"的路径
2. Fallback RAG 降级路径：只有表和文档时，混合检索（embedding + 关键词 + 外键图）定位相关表，LLM 兜底生成
3. 路由决策：PreMatch + 置信度度量 → 自动判定走哪条路径
4. 置信度的关键价值不止于"准不准"——它决定了哪些场景可以放心用。举个例子：产品运营同学要分析某个功能改版后的留存变化，一条错误的数据可能直接误导产品方向判断。但有了置信度兜底，0.95 以上自动入报表，0.65 以下系统主动提示"这条我不太确定，建议人工确认"——用户心里有数，敢用。反过来看，正是因为有了置信度，这类直接影响业务决策的高敏场景才敢投入生产使用，而不是永远停留在 demo 阶段。

三、Skill 体系：薄 API → 厚 Skill → 本体元数据
1. 行业参考：Snowflake Cortex Agent（语义查询 + 非结构化检索 + UDF + Agent Skills 编排）与我们的层面对齐
2. 渐进路径：暴露指标/维度/枚举查询接口（薄 API）→ 快速构建查数/归因/预测 Skill → 高频经验（归因因子、维度层次、业务阈值）沉淀为本体元数据
3. 最终形态：Skill 退化为纯编排器，知识全由本体层提供

四、量化评测：从学术基准到生产落地
1. 学术基准为什么不够：比 SQL 文本而非查询结果、不涉及业务口径/多轮对话/幻觉检测
2. 三级评测架构：L1 程序自动比对结果集 → L2 LLM Judge 语义判断 → L3 人工兜底
3. 数据飞轮：用户点赞经防污染过滤后自动采样为回归测试集，9 维指标持续追踪

听众收益：

1. 一套可迁移的渐进式语义层落地方法论：双路径路由让系统先跑起来，RAG + 置信度引导让语义资产在使用中自然生长。
2. 理解 NL2SQL 学术与生产的鸿沟：WikiSQL / Spider / BIRD 为什么不够用，以及如何搭建面向业务口径的生产级评测体系。
3. 掌握 Skill 到本体层的演进路径：薄 API → 厚 Skill → 本体元数据的设计取舍与落地经验。
4. 可复用的三级评测架构：L1 程序 → L2 LLM → L3 人工 + 反馈数据飞轮 + 回归测试。