从SelectDB离职，我去了这里开始AI创业

引言

之前有很多关心我个人情况的朋友也比较关注我下一步去哪里就业或者创业的动向，时至今日已差不多算尘埃落定了，跟各位关心的小伙伴汇报一下以后的决定和选择，以及我对整个数据行业的思考和判断。

今年伊始，有两个问题一直在困扰我，同时也是花了大半年的时间思索和实践看有无解题方案：

1. 1. 数据仓库无论是离线数仓，还是实时数仓还是离线数仓，其实都难逃模式建模的动作，而且绝大部分的数据开发人力投入，都是在做维护临时的指标加工看数和历史常规性指标的更新动作，前者没有太大的可复用价值，往往就是一个活动、一个Ide或其他带来的诉求，后者若指标口径不变的情况下，要从上游数据变化的 ODS 开始做变更，一直更新至 ADS 层。这两者的全流程（对口径、取数开发、维护、抽象复用等）几乎消耗了绝大部分数据开发的人力，但从结果来看，业务方似乎也不太想买账，常常以口径不对、时效性差、指标价值不大等等说辞来拒绝承担数据开发成本，导致最后大家活也干了，价值感也没找到，最后每年末都忙于如何“自证价值”，苦不堪言。
2. 2. 大模型的持续火热下，大家对大模型已经有了很多超过其本身能做到的期望，比如希望可以直接解决NL2SQL的问题，或者希望可以通过超大模型，来理解整个公司业务，构建具备深刻的数据价值的内容，同时市面上也流传很多技术流派来进一步的解决模型阶段“幻觉”和“重复输出不稳定”的问题，比如使用 RAG、小模型、大模型交叉审核 等等，那这些流派真的有某一个是彻底解决了这些问题么？又或者某一种方案能做到真正数据仓库有什么指标，只要数据仓库加工出的指标，就能保证100%获取稳定和准确无幻觉么？

基于上面两个问题，我们一起来思考思考，是否有破局之法。

判断一：数据仓库应该迎来新的进化

大数据技术演进与架构范式变迁

自谷歌“三驾马车”（GFS, MapReduce, BigTable）奠定基石以来，大数据领域经历了数次深刻的技术变革与架构迭代：

• • 离线数仓时代：确立了基于 Hive/Spark 的大规模批处理方案，并衍生出经典的 Lambda 架构。
• • 实时数仓探索：引入 Flink + Kafka 组合，推动流计算普及，催生了流批一体的 Kappa 架构。
• • 数据治理标准化：以阿里 OneData 为代表的分层建模方法论（ODS/DWD/DWS/ADS）成为行业事实标准。
• • 数据湖技术兴起：Iceberg、Hudi、Paimon 等 Table Format 的出现，解决了数据湖的 ACID 事务与更新痛点。
• • 湖仓一体化：通过 OLAP（如 Trino）+ 数据湖底座，实现了计算存储分离的 Lakehouse 架构。
• • 极致统一架构：迈向 All in OLAP，利用高性能引擎（如 Doris/ClickHouse）实现离在线一体化的极简数仓建设。

当下，随着 AI 在 Text-to-SQL 及各类数据加工过程中的深入应用，乃至 Flink 对 AI Native 引擎的探索，数据领域无疑迎来了一波新的技术浪潮。然而，审视这波浪潮，绝大部分实践仍局限于“工具赋能”层面——即优化 SQL 编写、加速 Job 构建或辅助 BI 结果展示。从整个数据仓库的宏观架构视角来看，尚未出现根本性的“深度重构”与“范式转移”。

基于此，我所构想的下一代原生智能数仓平台 (AI-Native Data Platform)，应当具备以下核心特征：

下一代 Data Agent 平台能力演进

1. 1. 极简架构：计算换取空间 实现数仓层次的极致扁平化。数据仅需完成 ODS 接入与 DWD 标准化清洗，后续的 DWS 汇总层与 ADS 应用层不再预先物理加工，而是依赖高性能引擎进行即时计算 (On-the-fly)。
2. 2. 统一治理与即席查询 具备全局统一的元数据与指标管理能力，屏蔽底层复杂性，提供强大的、面向不确定业务场景的随机复杂查询能力 (Ad-hoc Querying)。
3. 3. 智能物化与自动加速 平台能基于历史 SQL 执行日志和用户行为模式，利用 AI 自动推荐并构建最优物化视图 (Auto-MV)，实现透明加速。
4. 4. 从 ETL 作业到 Data Agent 池 数据建设模式由传统的静态 ETL 开发转变为动态的 Data Agent 构建。集中建设具备自主能力的 Data Agent 池，大幅提升指标与逻辑的复用性及主动响应能力。
5. 5. 大模型驱动的数字员工工厂 构建以大模型为核心的工作流编排平台。它既是业务自助加工的入口，也是数据部门预加工的“数字员工工厂”。无论是报表、看板需求，还是自然语言问答，都能智能路由至专属的 Data Agent 定向处理。
6. 6. 可信内核：精准无幻觉 将确定性的数据计算引擎与生成式的 AI 能力解耦。确保内核稳定可靠，查询结果精准，彻底杜绝 AI 幻觉与语义歧义，保障企业级数据安全。
7. 7. 分级运行模式：成本与安全并重 建立务实的混合运行机制。在常规非探索分析场景下，不依赖昂贵的“满血”大模型资源，基于 CPU 或轻量级小模型即可高效运转。这不仅显著降低了平台 TCO（总拥有成本），也有效防止了无自建算力池场景下的数据外泄风险。

满足以上条件的平台，将给企业和从业者带来如下收益：

1. 1. 省去了最繁琐的 DWS 和 ADS 构建过程，释放大量人力构建贴合业务知识的 Data Agent
2. 2. 业务方数据利用效率急剧提升，无需等待漫长的加工过程，且随机性和灵活性有非常大的改善，一切以业务增长为导向
3. 3. 不再充当 SQL Boy，从 SQL ETL 任务开发进阶为 Data Agent 数字员工开发，为职业拓宽道路

所以我断定，OLAP 将会迎来新的一波机会和市场，因为一切都要基于“快“和”准”，同时我现在加入的新公司，正是在研发如上所述的 Data Agent 平台，效果令人兴奋，后续篇章逐步给大家拆分探究这些功能在产品设计上是如何思考的。

判断二：准确的基础不该建立在概率之上

大模型的本质是概率，但是概率这件事，对数据行业而言，是很难容忍的。

在过往一次线下演讲时，我提到了一个基金行业高管跟我分享的观点：人工取数都无法做到100%准确，为什么要求NL2SQL要做到100%准确？

这里我个人觉得在“限定”条件下，这句话是成立的：所谓的不准确仅仅是数值上有质量问题的不准确，并非问指标 A 回答的却是完全无相关的指标 C 这种情况。但是大模型恰恰在这方面真的是超“擅长”，问题上下文理解在大量的Schema加入以后，有可能迎来根据一些略有相关的基础指标就加工出派生指标的情况，同时也可能迎来“挤爆”上下文等等一系列的问题。

所以无论是用 RAG、大模型交叉审计，还是使用其他一些依靠“魔法”打败“魔法”的事情，最终都无法呈现数据或者指标 100% 稳定、准确、同逻辑的查询能力。

所以微调专有小模型、自研其他技术路径的内核等，逐步成为了这个问题的核心技术价值点所在，**这一块是我们当下产品的最核心的技术力，能保证100%的准确、稳定和同逻辑查询能力。**这一块由于一些原因，不方便给大家透漏更多我们当前在做的技术路径的信息，后续时机成熟会和大家展开分享。

新的征程：易问数据

以上的问题和思考，促进了我对新工作和产品设计上的探索，这里很感谢鲁大推荐的腾讯、刘哥推荐的米哈游、杰哥推荐的天翼云、宇哥邀请的AI公司等等很多特别好的机会，但我思来想去，还是希望做一个当下自由度比较高一些，对自己产品有很强设计参与和落地参与的工作。

所以在数轮深度协商沟通以后，决定以联合创始人的身份加入易问数据，深度参与到下一代AI Data Agent 平台的设计开发和市场推广中来。

这群小伙伴非常非常 Nice，在过往的阶段也给很多很多头部如麦当劳、蜜雪冰城、康师傅、爱玛集团等等上百家用户提供了可靠、100%好评的 ChatBI 产品，但我觉得 ChatBI 仅是整个智能数据平台的第一步落地探索，一定会向更具备业务价值、平台价值、人效价值的方面演进，而后面的路途真是路漫漫其修远兮，吾将上下而求索。

后续我将从技术和产品角度，更多的来分享我们在产品设计和开发的经验，后续我们也将推出社区版本，让大家体验我们的产品能力。

最后感谢这段时间帮我的每一个朋友，希望我们能在未来的合作中更加戮力同心。

下一篇我们来讲讲在整个 NL2SQL 的场景中，我们提出和实践的 NL2LF2SQL 解决方案与其他 NL2DSL2SQL 和 NL2MQL2SQL 的对比。

来个点赞、在看、转发吧，这是最大动力了。