FeatureStore Summit 2023 笔记

Hopsworks – From building to using feature stores for ML systems – FS Summit 2023

观点1：deploying models to production is a data challenge

• 多种数据来源（streaming无界数据、数仓、数据库、文件、现有的表格系统、图数据库）
• need for a variety of frameworks（spark、airflow、hive、polars、arrow、duckDB、多语言, etc）
• 实验、训练、生产之间的gap
• custom one-off pipelines to make data available in real time（训练是一个通路机制、预估是另外一个通路机制）

hopsworks的方法：FTI PIPELINES

Data -> [FeaturePipeline] -> [Training Pipeline] -> [Inference Pipeline] -> Predictions

• FeaturePipeline: Transform data into features/labels
• TrainingPipeline: Train models with features/labels
• InferencePipeline: Make predictions with models & new features

hopsworks 提供了 API 来支持上述3个pipeline上要实现的工作。

要点1：不同框架的适用场景（FeaturePipeline）

• bigger data & Real-time: spark, flink
• bigger data & batch: spark, google big query, dbt
• small data & Real-time: bytewax
• small data & batch: pandas, polars

hopsworks 提供统一的应用接口，底层可以选择不同的 data frameworks

要点2：训练与推理阶段，提供Laptop的体验，读写速度优化

底层训练框架使用 pytorch 或者 tensorflow，读取 FeatureStore（spark、DuckDB）时，提供 dataset 接口。dataset 接口屏蔽底层数据库实现，使得可以切换升级。并提供读写速度优化。

要点3：预估阶段使用跟训练时相同的UDF，来保证训练与推理的一致性

Request data -> On-demand transformations(Pandas UDF) + FeatureStore features -> Model -> Predictions

hopsworks提供接口从FeatureStore中读取数据，www.featurestore.org/benchmarks 有对比评测。

最后视频宣传了 hopsworks 提供的 serverless 的服务。

wechat – wechat’s feature platform for real-time recommender systems – FS Summit 23

摘要

分享了微信推荐在线场景获取特征方面的并行优化技术，数据格式采用Arrow。online阶段获取feature，有些操作因为成本规模的因素，必须online实时操作：过滤、拼接（user with item）、排序与聚合、数值转换（不同模型方法不同）。微信的请求模式：每个请求包含一个 user ID 和多个 items（理解为对 items 进行排序，使得更适合该 user）。这个场景适合做向量计算与编译优化。

理解向量计算：

首先理解传统的矩阵运算，举个例子，假如每个 item 都有一个 float 类型的特征，那么可以把所有 items 的该特征当成一个vector（列向量），然后跟 user 的一个 float 类型的特征（标量）做点积，得到一个新的向量，新的向量每个元素的值就是 items 相对这个 user 的得分（可按照得分进行排序，展现给用户）。扩展到 item 有很多列，此时 N 个 item 的 M 个特征构成一个 N*M 的矩阵，user 有 M 个特征构成一个 M*1 的矩阵。两个矩阵相乘得到一个 N*1 的矩阵（一个向量），最终就是 item 相对 user 的分数。这是一个典型的 GPU 矩阵计算。

视频中的向量计算，意思是对所有 item 的相同特征的过程是完全一致的，可以理解为 input 不同，计算逻辑相同。可以采用并行计算的一些思路，做并行化。例如使用 CPU simd 指令集。

编译：离线训练时可能采用 python 或者 c++，因为这些代码在在线训练场景会被反复调用，所以可以优化成性能更高的代码。把这个优化过程成为编译。

知识点1

Apache Arrow

什么是 primitive array ？

知识点2

LLVM JIT & Gandiva

知识点3

GCC -ftree-vectorize

知识点4

Operator Fusion，目的是减少每次 operator 调用的开销（virtual dispatch、input validation and copy、output memory allocation）

Wayfair – Wayfair’s Mercury Feature Platform – FS Summit 23

KeyIdea

• Prioritize maintainability and efficiency over flexibility in defining new feature
• improve model performance by increasing access to signals
• define, build, consume, and maintain features as a group, rather than individually

观点1

ALL ML systems make tradeoffs, between:

• predictive performance(AUC, RMSE, etc)
• Resource Efficiency(Latency, CPUs, etc)
• Maintainability(Staffing, Velocity, etc)

这点比较有感触，很多大厂定制系统，都在1、2上发力，维护成本高昂，新部署一套或者应用到其他业务的成本巨大，维护人力不会有成就感。反之，相对易维护的系统，在效果和效能上需要做一些放弃。这个不一定是公理（类似分布式CAP理论），但是是一个普遍的现象和规律。

The more predictive model is not always better. Success comes from managing tradeoffs.

做法1

分层次对 feature 分组。从上至下以此是：entity、feature family、feature groups、编码生成的特征。

从特征使用、版本管理出发，将共享实体分析（Geo、Channel）的特征划为一组；从性能表现出发，将共享共享actions（atc, clicks, etc）的特征组合到一起。

把 feature group 理解成一个标准套餐，一个套餐包含6~1000个不同维度的feature。每个feature在底层实现层，可能是不同单位/口径的，但是他们能够归一化为一个特征。不同的feature family 可以共享相同的 feature group，例如北京地域的用户特征是一个 feature family，上海地域的用户特征是一个 feature family，这2个 feature family 的下一层特征类型与组合是一致的，值不同而已。feature family的上层是实体类型，即北京用户、上海用户的实体都对应『用户』。

TODO：后面的例子基本没看懂。

观点2

用神经网络做对比，神经网络可以理解为：从原始输入到学习到的中间层表示，再到预估结果。对于企业数据来讲，source的内容经过feature engineering得到representation，然后供给模型做预估。

引用『Weighted Sums of Random Kitchen Sinks: Replacing minimaztion with randomization in Learning』这个文章的观点，”Random Kitchen Sinks” provide intuition for the effectiveness of programmatic feature definitions.

Programmatic feature definitions can be thought of as a deterministic analog of the random kitchen sink in the context of an enterprise data warehouse.

简单来说：‌ Wayfair 是说，我们像设计神经网络中间层一样精心设计特征工程。RKS 那篇文章告诉我们，哪怕特征映射是随机的（厨房水槽），只要数量多种类丰富，效果就很好。这反过来证明了我们分析师在企业数据仓库里用SQL精心编写的大量确定性特征规则（程序化特征定义），虽然不随机，但同样是通过构建强大的特征映射空间来提升模型效果的绝佳方式，是RKS思想在企业确定性环境下的实践。特征存储就是为了更好地管理和使用这些“确定性RKS”而建的。

Arize – Stop Blaming the Algorith: It’s Your Feature Store! – FS Summit 23

Arize AI 公司出品，下面是 DeepSeek 给出的这家公司的总结：

Arize（全称 ‌Arize AI‌）是一家专注于 ‌机器学习可观测性（ML Observability）‌ 领域的领先科技公司。

简单来说，它的核心业务是帮助企业监控、理解和改进其生产环境中部署的机器学习模型。‌

以下是关于 Arize 的关键信息：

核心产品：‌ ML Observability 平台。
解决的问题：‌
模型性能下降：‌ 检测模型在生产中出现准确率下降、预测错误等问题。
概念漂移：‌ 这正是你之前询问的“sudden drift”和“gradual drift”发生的场景！Arize 的平台能自动检测数据分布（特征漂移）和模型预测关系（概念漂移）随时间的变化。
数据质量问题：‌ 监控输入模型的数据是否存在异常、缺失值激增、分布偏移等。
模型偏差：‌ 识别模型在不同子群体（如地域、性别、年龄段）上的表现差异和公平性问题。
根因分析：‌ 当模型表现不佳时，帮助数据科学家快速定位问题是出在数据、模型本身还是代码逻辑上（例如特征处理错误）。
主要功能：‌
模型性能监控：‌ 实时跟踪准确率、召回率、AUC 等关键指标。
漂移检测：‌ 自动检测特征漂移（输入数据分布变化）和预测漂移（模型输出/概念变化），并区分“sudden drift”和“gradual drift”。
数据质量监控：‌ 跟踪输入特征的统计特性、缺失值、数据类型异常等。
模型可解释性：‌ 提供特征重要性分析、错误分析等工具，帮助理解模型行为。
根因分析工具：‌ 关联性能下降、漂移、数据问题，加速问题诊断。
模型比较与版本控制：‌ 比较不同模型版本或生产与训练环境的表现差异。
警报与协作：‌ 设置警报规则，并通过集成通知团队成员。
目标客户：‌ 任何在生产环境中大规模部署机器学习模型的行业和企业，特别是：
金融服务（欺诈检测、风险评估）
电子商务（推荐系统）
广告科技（点击率预测）
软件即服务（智能化功能）
医疗保健（预测分析）
物流运输（需求预测）
公司地位：‌ Arize 是 ML Observability 这个新兴领域的先驱和领导者之一，经常被分析师报告（如 Gartner， Forrester）提及，并与 Tecton, Fiddler, WhyLabs 等公司竞争。
成立时间：‌ 2019年。
总部：‌ 美国加利福尼亚州伯克利。
创始团队：‌ 团队成员拥有 Google, Uber, Apple, Facebook 等科技公司在机器学习基础设施和模型部署方面的深厚经验。
开源项目：‌ 开发并维护了知名的开源机器学习可观测性库 ‌Phoenix‌，允许用户免费在本地环境进行模型分析和探索。

总结：‌

Arize AI 是一家提供 ‌机器学习可观测性平台‌ 的科技公司。它帮助数据科学家和机器学习工程师 ‌监控‌ 生产环境中的模型性能，‌检测‌ 数据漂移、概念漂移（包括你问到的 sudden drift 和 gradual drift）以及数据质量问题，‌诊断‌ 模型失败的根本原因，从而确保部署的机器学习模型持续可靠、公平且高效地运行，最终提升业务价值。

如果你在构建或部署机器学习模型，尤其是在乎模型在生产环境中的表现和健康状况，Arize 提供的正是这类解决方案。你可以访问他们的官方网站（arize.com）获取更详细信息。

观点：What does Feature Failure Look Like?

• vendor data shifting
• statistical drift
• online/offline skew

方法，监控全流程

全流程监控：针对数据源头，监控raw data的变化；在数据 ETL 阶段，监控数据质量与feature engineering代码的错误；在FeatureStore存储阶段，监控 feature 质量；在训练和预估阶段，监控model输出与输入的feature。总结为三个大阶段：

• Data quality monitors，确保高质量的上游数据: 空值率、质量、sum、count、average，等。
• tabular drift monitors, 检测统计分布，特征在生命周期内的变化：PSI, KL Divergence，JS Distance, KS Statistic。可以检测sudden drift、gradual drift。
• Embeddings Drift monitors, 检测非结构化特征（NLP,CV）的数据分布变化，这些feature一般都是embedding：欧式举例、cosine相似度。可以使用 PCA 等方法降维到3维，观察分布变化。

Bytewax – Bringing ML Online: Defining ML Features in Real-Time – FS Summit 23

Bytewax‌ 是一家专注于 ‌实时数据流处理‌（Real-time Data Streaming）的开源技术公司，提供高性能的分布式流处理框架。其核心产品是开源库 ‌Bytewax‌，旨在简化大规模实时数据处理和机器学习管道的开发。

提供了基于 python 的流式计算框架。分享主要是介绍如何使用。

Fennel – Architecture of Fennel’s realtime feature platform – FS Summit 23

DeepSeek对fennel的总结

Fennel 并非传统意义上的软件公司，而是一个以开源技术为核心的实时机器学习（ML）基础设施平台‌，其商业实体为 ‌Fennel AI, Inc.‌。

首创 ‌「特征即服务」（Feature-as-Code）‌ 范式，将特征计算引擎直接嵌入数据库（如 Snowflake/BigQuery），实现 ‌“零ETL”实时特征管道‌。
👉 解决行业痛点：传统特征平台需将数据迁移到外部计算引擎（Spark/Flink），导致高延迟与冗余成本。

关键技术突破‌：
✅ ‌In-DB Compute‌：在Snowflake等数仓内执行流式窗口聚合（如1分钟滚动统计）
✅ ‌统一批流‌：用同一套Python代码定义批处理特征与实时特征
✅ ‌Automatic Backfilling‌：自动修复历史数据，无需人工回填脚本

📌 终极评价

‌Fennel 是特征工程领域的“颠覆者”‌，通过‌将计算推向数据层‌，从根本上重构实时ML基础设施。短期聚焦云数仓用户痛点，长期可能推动行业放弃重型计算引擎。其技术上限极高，但商业落地仍处早期（2024年公布首批企业客户）。‌值得关注的信号‌：是否被Snowflake/Databricks收购整合。

观点

关于Fennel的独特的架构选择：

• 简化创作（使用）。使用 Pure Python，no DSLs or PySpark。可以更多满足用户的使用场景，用户可以继续使用Python的生态，另外底层基于Rust构建，弥补性能。
• 只提供一种计算接口，同一个代码内部可能运行在 batch & streaming。有个缺点，batch场景有很多操作需要做性能、内存优化，如果计算代码一致，就丧失了优化机会。
• 读/写分离，features as functions，not data。简单理解就是 source data 进入系统后，存储到不同的介质上作为 DataSet，这是写阶段；定义一个DAG，DAG中每个节点是feature，feature是以functions的形式来定义，也可以理解成feature就是一段计算逻辑，这是读阶段。这种方式的确很独特，对于一些轻量的计算来讲比较合适，对于重量计算，如果特征被多租户频繁读取，都依赖重新计算一遍，成本就比较高，还是需要把 feature 当成 data 存储起来。
• 深入垂直集成，Anti-Virtual。Fennel 自带并管理所有它需要的模块，零依赖安装。使用时不需要考虑跟 K/V store 集成，以及流式计算引擎 or metadata store。其他创业公司的 feature store 产品，都会跟 AWS 的服务做无缝集成，但是需要用户去维护 AWS 上的服务，例如水平伸缩。开箱即用，适合一些小体量业务的调研，其缺点是可能需要付出更多的成本，性能受约束，灵活扩展性差。

Streaming Engine

Fennel的离线流式引擎跟我做过的Imazon（https://xie.infoq.cn/article/4fe9a795b6caf73c68206e29a）非常类似，算子在一个node内部署，如果跨node则通过消息队列来通信，所有的算子都是以异步的方式工作的。好处是 back pressure、backfilling 非常容易。部署node宕机后，不影响整个流，稳定性、水平扩展性很好。

Fennel提出他们的实现可以避免 OOMs。Spark 与 Flink 在做一些特征计算任务时会用光内存。在Fennel的 stream engine中，没有 in-memory state of jobs。所有的状态都存储在 disks 上，通过 block/page cache 来降低读写开销。All shuffle is mediated via Kafka。No GC。

Streaming Engine Is Time Aware，下面是 DeepSeek的相关介绍：

好的，这是一份关于‌时间感知流处理引擎 (Time-Aware Streaming Engine)‌ 的详细中文解释：

时间感知流处理引擎是什么？‌

它是一种专门设计用于处理‌无限、持续到达数据流（流数据）‌ 的系统，其核心在于‌内置对时间概念的深刻理解和原生支持‌。它不仅仅处理数据本身，更理解每个数据点所关联的‌时间上下文‌（何时发生），并据此进行精确的计算和处理。

核心特征与能力详解：‌

事件时间 vs. 处理时间：‌

事件时间 (Event Time)：‌ 这是数据‌实际发生‌的时间戳（例如，传感器读数的时间、用户点击的时间、交易发生的时间）。这是业务逻辑中最关心的“真实”时间。
处理时间 (Processing Time)：‌ 这是数据‌被流处理引擎接收或处理‌的时间戳。
时间感知的意义：‌ 引擎能明确区分并正确处理这两种时间。特别是能够基于‌事件时间‌进行计算，即使数据因网络延迟等原因‌乱序‌到达（事件时间早的数据可能晚到），也能保证计算结果的‌时间准确性‌和‌可重现性‌。这对于依赖事件顺序的分析（如会话分析、基于时间的聚合）至关重要。

窗口化计算 (Windowing)：‌

流处理的核心操作之一是将无限流划分为有限的“窗口”进行计算（如计数、求和、平均值、最大值等）。
时间感知的窗口：‌ 引擎支持基于‌事件时间‌定义窗口边界。常见窗口类型：
滚动窗口 (Tumbling Windows)：‌ 固定大小、不重叠的窗口（如：每分钟、每5分钟）。
滑动窗口 (Sliding Windows)：‌ 固定大小、按固定间隔滑动的窗口（如：每1分钟计算过去5分钟的数据，窗口有重叠）。
会话窗口 (Session Windows)：‌ 根据用户活动的不活跃间隙动态划分的窗口（常用于用户行为分析）。
时间感知的关键：‌ 窗口的划分和触发是基于‌事件时间‌而非处理时间，确保窗口包含的是在特定事件时间段内真正发生的事件。

水位线 (Watermarks)：‌

解决乱序问题的核心机制：‌ 水位线是一种系统生成的、与事件时间相关的特殊标记。它表示一个时间点 T，并暗示引擎：“‌在这个时间点 T 之前的事件数据，预计已经全部到达‌（或绝大部分已到达，迟到数据非常少）”。
作用：‌
触发窗口计算结果：‌ 当水位线超过窗口的结束时间时，引擎可以安全地触发该窗口的最终计算结果（因为在此之前的事件已基本到齐）。
处理迟到的边界：‌ 水位线定义了“准时”和“迟到”数据的界限。引擎通常会设置一个“允许迟到”的时间阈值（Allowed Lateness）。
平衡延迟和完整性：‌ 水位线策略（如：观察最大事件时间减去固定延迟）允许开发者权衡结果输出的‌延迟‌（更快看到结果）和‌完整性‌（等待更多可能延迟的数据）。

处理迟到数据 (Late Data Handling)：‌

即使使用了水位线，理论上仍可能有事件时间小于当前水位线的事件数据迟到到达（例如，在网络中卡了很久）。
时间感知引擎的策略：‌
允许迟到 (Allowed Lateness)：‌ 为窗口设置一个容忍期。迟到但仍在容忍期内到达的数据，会被重新触发计算（更新之前的结果或输出修正结果）。
侧输出 (Side Outputs)：‌ 将超过容忍期的极端迟到数据输出到专门的流中，供其他用途（如异常监控、特殊处理），避免污染主结果流。
丢弃：‌ 超过容忍期且无特殊处理的数据通常被丢弃。

状态管理与时间：‌

流处理常需要维护状态（如累加器、窗口内容、用户会话状态）。
时间感知的状态 (Time-Versioned State)：‌
状态可以与时间关联（如基于事件时间键控）。
引擎支持高效的‌状态过期 (State TTL – Time to Live)：‌ 可以根据事件时间自动清理过期的状态（例如，会话窗口结束很久后清理其状态）。
支持‌按时间点查询状态 (Temporal Queries / Point-in-Time Queries)：‌ 查询过去某个事件时间点的状态值（例如，用户当时的状态）。

时间特征 (Time Characteristic)配置：‌

引擎允许开发者显式设置作业使用的‌时间语义‌：EventTime（事件时间，最常用）、ProcessingTime（处理时间，简单但结果不可重现易受延迟影响）、IngestionTime（摄入时间，介于两者之间，记录进入引擎的时间）。

为什么需要时间感知？‌

保证结果准确性：‌ 基于事件时间的计算才能反映真实世界事件发生的顺序和时刻，避免因处理延迟或网络延迟导致结果偏差（如处理时间计算的窗口在高峰期延迟时，会包含不属于该时间段的数据）。
结果可重现性：‌ 相同的数据流重新处理，只要事件时间戳不变，基于事件时间计算的窗口结果就是一致的。基于处理时间的结果则每次都可能不同。
复杂事件处理：‌ 识别跨时间段的模式（如“用户5分钟内连续3次失败登录”）必须依赖事件时间。
精确的时序分析：‌ 金融交易分析、IoT传感器监控、用户行为路径分析等场景都要求精确的时间对齐。

典型应用场景：‌

金融交易监控：‌ 检测特定时间窗口内的欺诈模式（如1分钟内同一账户多次异地交易）。
实时仪表盘：‌ 生成基于事件时间的准确每分钟/小时PV、UV、销售额。
物联网 (IoT)：‌ 计算设备在过去5分钟内的平均温度/压力/振动值，用于预测性维护。
用户行为分析：‌ 定义用户会话（基于连续活动的间隔），计算跳出率、转化路径时长。
网络监控：‌ 统计特定事件时间窗口内的错误率、延迟分布。
广告计费：‌ 基于广告实际展示或点击的事件时间进行准确计费。

代表性的时间感知流处理引擎：‌

Apache Flink：‌ ‌公认在事件时间处理和水位线机制方面做得最成熟和最完善的引擎之一‌。API设计原生围绕事件时间。
Apache Kafka Streams：‌ 基于Kafka的消息时间戳和内置状态存储提供了良好的事件时间支持。
Apache Spark Structured Streaming：‌ 在较新版本（2.1+）中逐步增强了事件时间处理和水位线功能。
Google Cloud Dataflow：‌ Google托管的流批统一数据处理服务，其Runner（如Flink Runner）支持完善的时间感知处理。
阿里云实时计算Flink版 / Ververica Platform：‌ 基于Apache Flink的商业化产品。

总结：‌

时间感知流处理引擎是现代大数据处理的关键基础设施。它通过‌事件时间语义、水位线机制、对迟到数据的处理策略以及时间感知的状态管理‌，解决了在持续、无序、延迟的数据流中，如何‌准确、一致、高效地‌进行基于时间的计算（如窗口聚合、会话分析、复杂事件检测）这一核心挑战。这使得开发者能够构建出真正反映业务现实、结果可靠且可重现的实时数据处理应用。

No Central Scheduler，水平可扩展。每个 worker node 有自己的 supervisor，负责一定分片的处理任务；可以水平对 worker node 进行扩容或缩容。

Uber – Uber’s Risk Knowledge Platform – FS Summit 23

Motivation

可扩展 & self-service的特征工程平台（定义、计算、监控特征），支持预测性决策。在uber中的应用领域：支付欺诈、促销滥用、窃取账户、不当行为检测，等。

端到端的特征工程流程

explore&analyze data -> feature engineering -> [ ML Models | Rules ] -> Actioning: Ban, Warn, Error

后2个阶段是 decisioning 过程。根据决策效果，也会反过来影响 feature engineering，这是 feature iteration。

uber的Risk Knowledged Platform主要由3个部分构成：uflow 负责计算和存储特征，ugraph负责存储图关系以及ML需要的use case，decisioning service接受用户行为触发然后查询ugraph、uflow的特征并请求michelangelo中的各类模型（如payment fraud model, account takeover model）来判别预估当前的用户行为是否涉及风险。

uflow feature store

uflow 负责的计算有3种，划分如下: Batch(Hive, spark), Near Real Time(Kafka, Flink), Realtime(RPCS, @prediction time)。feature 都存储在 FeatureStore(cassandra)中。

uflow 管理 feature 的以下几方面内容：

• feature catalog：定义、元数据
• feature quality: 正确性、分布、完整性、时鲜性、异常检测
• feature lineage（数据血缘): trace up & down stream, feature 关联关系
• feature lifecycle: 新建特征、特征评估、deprecation(废弃特征，下线特征)

ugraph

有3种规格的图：

• intermediate graph: 支持从一个不同的历史时间，重新生成特征，或生成一个 reconciled graph
• reconciled graph: 给出当前时刻的完整的entities的视图
• feature graph: 只存储 ML 用例关心的 entities，是一个更小的图，一般存储过去的状态。

数据流是：hive tables -> spec based ingestion -> intermediate -> [reconciled graph | Feature graph]

查询时同时查询 reconciled graph 和 feature graph。

ML for 风险评估

偏算法。

batch feature backfilling，基于单条数据（basic table）做实体扩展（利用ugraph），从一个record变成e个entity，然后每个实体查询不同 time windows 下的 metrics（即特征），最终训练集合规模从1扩展成e*m*n，这样子训练的模型效果更好，避免了过拟合等缺点。

near real time feature backfill，提到一些temporal join等概念，这里不太懂，先跳过。

Feature Byte – Accelerating Data Science through Feature Platforms and Generative AI – FS Summit 23

这个视频主要分享了一些观点，由其是探讨了LLM对 feature platform的影响与替代关系。

feature platform 让特征工程更容易

• 减少延迟（提前计算并存储起来）
• 避免训练和生产环境的不一致
• 简化复杂特征的生产过程（通过描述式框架，一般都用python实现）
• 加速使用新特征的实验（通过自动回填，automated backfilling）
• 更容易找到和复用已存的特征
• 提供一个统一的解决方案，从实验到部署

LLM在改变 data science

• data scientist：根本性简化了复杂任务（NLP），很多场景下不需要训练
• risk manager：难以解释，随机
• MLops engineer：another transformation to operationalize

如果有了 LLM，是否还需要 Feature Platforms

相互补充，Feature Platforms可以改善 LLM 的操作/实现：

• point-in-time correctness
• 低延迟
• caching（减少昂贵的LLM calls）
• transformer library

LLM会替代传统的特征工程么？

未来也许，现在还差点。以下是2023年观点：

• deep learning 表格数据领域还没有兑现其强大能力，除了：regular time series 和 sequences of events（推荐系统）
• 突发内容，无法被预训练
• 不能提供模型验证过程，可解释性差，数据集不够大时效果可能不够健壮

LLM 如何帮助 feature engineering

LLM 可以借助 data 的良好的 spec 描述，提供深度领域知识，为特征工程提供决策信息，评估一个feature对于应用场景是否有相关性。

FeatureByte目前利用 GenAI（LLM）做了上述的工作，主要如下应用：

• 输入 data 描述（tables、columns、entities），LLM提供数据语义与领域洞察（分析）
• 输入Use Case描述（domain，content，target）+ data 描述 + FeatureCode&描述，GenAI生成相关分数和解释，最终生成 Context-aware 的 特征建议。
• 强调了：过程的可解释性和相关性，并且可以编辑调整。

H2O.ai / AT&T – Operationalizing AI at Scale with H2O Feature Store – FS Summit 23

给出一个数据，data scientists 花了 80% 时间在数据准备上，具体包含：构建训练集合(3%)、清理和组织数据(60%), 选择数据集合（19%），挖掘数据（9%），改进算法（4%），其他（5%）

把 AI Clouds 总结为 4 阶段：

• Raw Data，Real-time & Batch
• Feature Engineering
• Feature Store，Online / Offline / metadata registry
• Feature Consumption, Real-time Prediction / Batch Predictions / Model Traning

H2O 管理4w特征，200模型，250+ 专业 data scientists 和 200+ 民间 data scientists。

使用H2O的feature store，用2个小时增加了一个account activity特征，将模型效果从66%提升到77%。

最后给了一个 Feature Store 配合 GenAI 的 demo：把feature store中的数据提供给 GenAI 作为 promotion。

TODO：

• apache airflow
• dbt
• great expectations
• backfilling