从对 LLM（Large Language Model）的需求来看企业对于 AI 建设的需求大致分为三类

1. 需要自建 LLM 来提升产品与业务效率的
2. 需要使用 LLM 的能力但是综合成本和效用考虑不会自建的
3. AI 在主营业务上并没有太多的应用场景，更多使用集成了 AI 能力的产品

第一类——自建 LLM

这类的企业基本以现有的巨头为主，需要使用 LLM 构造产品，并有着海量客户。

例如，微软需要 LLM 生产更好用的桌面操作系统和桌面软件，苹果需要 AI 生产更好用的移动设备。和之前的 AI 相比，在中长周期内，已经很难会对模型的结构有新的迭代，更多的都是喂更多的数据。

第二类——使用接口

以中小型企业为主，使用接口，结合 RAG、Agent 等开发 AIGC 应用，可能供内部使用，也可能封装为产品对外服务，调用量可能很高，但一般少于第一类。

第三类——使用现成的产品

以传统企业为主，可能涉及将相关的信息、资料、数据托管在企业服务软件平台上。

现在数据对于 AI 在企业中的应用可以分为两类：Data For AI 与 AI For Data。

其中 Data For AI 指的是，大量的用户数据和企业数据将用于模型的训练流程。

AI For Data 指的是，用 AI 能力把企业现有的数据资产以更加高效和充分的方式利用起来，一般场景以推理为主。

对于第一类企业而言，需要模型训练和模型推理两种场景，对应的数据应用方式两类都有涉及。而后两类以 AI For Data 为主。

Data For AI

以 MOSS 大模型的数据集为例，一个基本的数据文件的形式为：

很显然，这是一个非常标准的 JSON 格式文件，在大模型的训练过程中，这样的文件可能存在上亿个。对于企业而言，无论是 Fine-Tune 还是 Train from Scratch 都需要海量的类似的 JSON 文件。

挑战一，如何准备训练 LLM 所需的数据集。

训练的原始数据可能有多种来源：

公开数据集和公网上可被轻易下载和触达的开源的预训练数据
数据科学团队根据模型训练的需要在特定来源使用爬虫技术获取
企业自有数据，可能存在于各个部门不同的基础设施里，比如结构化数据库里存的客户对于商品的评价；半结构化数据库里存的客服与客户的对话；交易相关的以非结构化文本方式保存的日志；商品图、模特图等等非结构化的图片等等

那么对于一个自有的多模态大模型而言，对应这第一个挑战，相关工作可能有：

企业需要把以前的知识整理成类似的格式，构造海量的 Instruction-output 对
企业需要从外界爬取需要的数据，并整理成类似的格式
涉及到多模态的训练需要额外的图片的访问做 Instruction-output 匹配

挑战二，如何成体系地更新并管理 LLM 训练或 Fine-Tune 需要的数据以保证模型的迭代同时满足合规要求

和之前的 AI 相比，在中长周期内，已经很难会对模型的结构有新的迭代，更多的都是喂更多的数据，或者让模型能够更多地使用企业知识。因此，在现在模型训练的大量挑战会变成面向数据管理和使用的挑战。

如图中的语料数据，在这个问答对中，是一个显著的数学题问答。这样的回答有可能出现在教辅材料上，也有可能发生在老师学生的对话中，对话里面还包含了 Latex 公式。那么假如我们对语料文件使用文件夹分类的时候，到底把它归到哪一类呢？显然单纯的文件夹的管理并不能直接满足要求，因为非结构化数据本身的特性和标签足够复杂。对于数据的索引依赖一套有效的元数据管理体系，要求有分类、有来源、有权限等等。

显然这个问题一直是围绕 AI 持续存在的痛点，目前也并没有很好的解决方案。因此在 Lakehouse 的架构之间存在 Catalog 类的产品，随着 Snowflake 宣布开源 Polaris 和 DataBricks 开源了 Unity 这类 Catalog 的产品，也能说明，从需求侧来说，企业有越来越多的多源数据接入、管理、分析的需求。

挑战三，如何更加经济、成本可控地存储各种数据

随着企业数字化业务的增多，对应的数据信息也呈爆炸增长。数据文件体积和过去相比大了很多倍，过去的数据一般存放在专用的 NAS 服务器的文件存储中，或由专门的集群所搭建的 HDFS 存储中。在上一代数据湖中 HDFS 应用得尤其广泛。现代数据湖更多地会直接采用云服务商所提供的对象存储作为存储底座，因为它面向文件、海量、统一访问、安全、并且便宜，是最适合数据湖需求的存储类型。在对象存储基础上，有数据湖相应的软件，Hudi/Delta Lake/IceBerg 也都支持对象存储。

挑战四，如何运维复杂的数据流转的管道

在个人电脑上操作数据的时候相信都经历过类似的场景，把手机里的照片拷贝到电脑上进行处理。每次拷贝四五百张尚可，但是每次复制粘贴的操作面向四五千张照片的时候，大概率会卡死，然后你想挑出重点照片再拷贝，发现读取照片、预览照片都很慢几乎也不可操作。

于是你为了避免下次再碰见这个问题有了几个方案：

以后养成习惯，每多 100 张照片的时候就往电脑上同步一份
以后建立了一组文件夹/相册，把照片分门别类放起来，让每次的处理和使用范围能够快速有效地缩小
在手机上购买了一个很好用的照片处理软件，避免使用电脑处理照片

在数据基础设施的处理上，方案其实是类似的：

在传统数据分析中，数据仓库来承载经过 ETL 计算之后的结果，成为新的存储，在这个过程中，也少不了 Kafka、Flink 的参与，数据技术设施需要维护多套，并且存储成倍提升。传统数据分析使用的是方案 1，分批、按次、或实时完成数据的清洗和搬运，把大计算拆成小计算，大搬运拆成小搬运，利用业务闲时完成；
在传统机器学习过程中，有 Feature Store 来解决这个问题，将训练使用的字段经过合成、计算、聚合成为新的特征，占用部分存储，管理训练数据。Feature Store 的方案更像是混合了方案 1 和方案 2。
生成式 AI 产生的数据量太大，成本冲击也比较大，于是 DataBricks 提出了类似方案 3 的概念。手机就好比是数据湖，建一个能直接处理湖中数据的计算引擎。在数据量指数级增长的今天，数据基础设施的演进也基本向避免数据的搬运，减少二次加工进行。因此，这个计算引擎的价值在今天也随着数据量的增多而加大。

挑战五，如何在用基础设施越来越复杂的时候仍然保证用户的易用性

从数据的流向来看，对于用户使用的场景可以分为两类，一类是数据的流入，一类是数据的流出。企业为了应对更多的数据使用挑战，不仅要用更大量的数据，也要使用更多类型、格式的数据，因此都会选择数据湖作为数据存储的基础设施，而在数据湖的存储选型上，一般都会选择对象存储，也就是 MinIO 或 AWS S3 等作为数据湖的存储底座。然而在数据入湖的过程中并不是通过对象存储的通用接口上传就完成了，数据工程师仍然要额外考虑很多：

旧的已经在对象存储的数据如何管理？
跨云的数据如何管理？跨数据中心的数据如何管理？
对象存储的数据只能增删，无法修改，当数据流入很大的时候，如何做增量更新？
数据的目录、血缘信息如何存？用什么存？

当数据被提取/计算的时候，数据分析师和数据科学家仍然面临许多问题：

数据科学家无法使用对象存储的借口，如何能让他们用 SQL、一两行之内的 Python 就能便捷使用？
数据使用需要鉴权，如何能无感地使用数据并且合理鉴权
部分数据需要加密、脱敏，如何使用 SQL、Python 方便地配置加密、脱敏并按照权限让用户便捷使用

AI For Data

在数据驱动决策的流程上，虽然目前没有最佳实践，但是目前业界普遍在进行很多的研究和尝试。目前在这个环节中，仍然有很多需要人工参与的流程：

业务人员根据经营状况和企业的战略决定目前最需要关心的经营数据指标
数据开发把这些数据指标翻译成 SQL
SQL 执行之后都是一些原始的表格，有的表格被可视化为图形
一些决策者通过可视化图表产生业务指导和决策
一些决策者需要通过二次整理的经营报告来产生业务指导和决策

在上述的业务闭环中，如果让 AI 来参与，最理想的情况是通过 AI 让业务流程自发运转，人只需要在关键点进行观测，来保证系统运行不出故障。然而因为当前 AI 能力的限制，目前还无法用一套基础设施来完成这个流程。

AI 尚无法替代的环节

指标 SQL 化

对于结构化数据这种强逻辑和要求较为精准的计算场景，基于概率学的 AI 很难能够生成需要的复杂 SQL。目前市面上完全基于 LLM 进行 SQL 转义的产品基本没有能够满足客户要求的，反而是融合了一定业务知识和业务对应 SQL 的先验知识的产品目前都能取得较为靠谱的结果，但是离大规模的生产应用仍然有距离。

数据库查询 AI 化

分析型数据库和查询引擎是通过数据的相互关系执行的正向计算，保证白盒的同时能人为地评估、改进计算效率。对比 AI 的黑盒，用结果倒推规律再套用到其他结果的逆向计算来说，计算代价和效率具有天然的优势。随着业务场景的丰富，计算需要越来越快，占用的资源越来越少，因此计算速度和代价的要求越来越苛刻，因此 AI 难以胜任此类任务。

数据驱动决策的根本价值

其实根本价值在于两条：

适应企业所有的变化
产生有意义的经营决策

企业的策略随着每天的经营情况或在微观，或者宏观基本都需要调整，而通过数据形成知识，通过知识再变成决策的流程离开数字化将变得非常长，在过去常以月、季度为单位进行决策调整。企业经营者都希望进行更加细颗粒的决策支持以保证企业始终在正确的发展道路上。

因此 AI 的价值可以协助缩短生产正确决策的过程，企业可以更加敏捷地进行策略调整来改善经营，攫取更多利润。

从这个角度来说，真正的价值来源于加速决策到数据，数据再反哺决策的流程，因此使用 AI 优化任意一个单点，价值只有省去人力成本，但是不一定能够达到“增效”的程度。

当前的 AI For Data 进行了初步的探索

RAG 的诞生使得数据可以进入大模型的分析流程

RAG 的原理很简单，把用户的输入向量化之后和数据库中的信息做匹配和查询，查询所得的信息通过大模型进行整合反馈给用户。当然在实践中，为了让查询和索引更高效，可能引入分层、分块等等复杂的策略。

在企业使用 LLM 的时候 RAG 的好处有两个：

避免大模型的幻觉，所有需要的信息都有精准的对应
能够利用企业现有的知识（无法进行数值计算）

RAG 目前能做什么事情

目前来看，通过观察可视化结果来生成经营报告，以及初步的通过业务进展来决定跟踪哪些指标，通过大模型结合企业现有的知识是能够负担一些的。

AIGC 时代湖仓生态下的Data and AI

Data For AI 中长期来看，湖仓架构是未来

上述的五个挑战，归纳来看可以总结为三个点：

数据的管理与使用
计算的效率
对应的成本

在湖仓中，数据湖通过一套通用存储基础设施，作为企业的 Single Source of Truth 最大程度避免存储的重复建设从而降低成本。通过 Catalog、表格式、结构化索引、标签、框架等等手段解决数据的管理与使用问题，通过 LakeHouse 基础设施拔升计算效率。

举一个通俗的例子，数据的管理与使用好比用料清单和菜谱，对象存储和数据就是冰箱，而 LakeHouse 引擎是厨师，AI 是食客。食客的胃口随着 AI 技术的演进会越来越大，Lakehouse 就需要足够强大来满足食客的胃口。食客胃口膨胀，市场空间从千亿增长到万亿美金，对应的 Lakehouse 空间也会从几十亿增长到几百亿。

AI For Data 短期尚无最佳实践

目前 DataBricks 在其宣传材料中给了一套解决方案

通过在数据湖中存储向量，并且使用查询引擎去做匹配。但是目前尚不是业界共识，也没有进行大规模的生产级应用。生产级应用的向量匹配依然依赖类似于 ETL 的流程，从湖中抽取数据进入向量数据库完成匹配，并且仍然面临扩容、管道维护等等问题。

中长期来看湖仓一体价值不可替代

中长期来看 AI For Data 会更加聚焦，而非使用 RAG 解决某个单点问题。在数据驱动决策的闭环流程中，显著可以分为“查询前”和“查询后”，随着 AI 发展，可能使用一套智能系统整合了全部的数据驱动决策流程，也可能分为中间的某些系统模块，成为一个带有 AI 能力的系统工程。

但是无论其能力如何整合演变，查询和数值计算本身是无法被替代的。可能在未来的某一时刻，我们扩展了计算的定义，使用结构化查询语言或者其他的 DSL 能够做更多的事情，甚至操纵一个带有智能的分析引擎对数据进行深度挖掘，但是 Lakehouse 本身的生态位置和数值计算能力是难以被替代的。