FeatureStore Summit 2024 笔记

Kickoff

Feature Stroe State of the Union in 2024

• 2017，Michelangelo from Uber
• 2019, First Open-Source Feature Store
• 2021, First Cloud Vendors Feature Stores
• 2022, Feature Stores go Real-Time
• 2023, Feature Stores go Serverless
• 2024, Offline Store is the Lakehouse。”Cloud-based object storage using (Lakehouse) formats will be the OLAP DBMS archetype for the next ten years.” —— Pavlo and Stonebraker, SIGMOD RECORD 2024

hopsworks 在SIGMOD 2024发表了一篇涉及该领域benchmark的文章: The Hopsworks Feature Store for Machine Learning, 提到了3个方面的benchmark：Feature Freshness, Online Stroe Throughput/Latency, Offline Store Throughput

Jim Dowling 提到一本自己的书：https://www.hopsworks.ai/lp/oreilly-book-building-machine-learning-systems-with-a-feature-store

Hopsworks – From Feature Store to AI Lakehouse

给出了 Lakehouse 的原始概念图：

• 应用层: Data Integration(Fivetran, Airbyte, etc); BI Tools(Tableau, Looker, etc); Event Bus(Kafka, Kinesis, Red panda, etc)
• 引擎层 + Catalog：SQL/Batch Query Engine(Spark, DuckDB, BigQuery, StarRocks, Trino, Snowflake, Polars, Dremio, etc), Streaming Engine(Flink, Spark Streaming, Feldera, etc), Catalog(Hive, Unity Catalog, Polaris, Iceberg REST API)
• 存储层：Table Format(Delta, Iceberg, Hudi), Storage(S3, ADLS, etc)

提出 Online Store 和 Vector Index 将 lakehouse 扩展为 AI Lakehouse。不太理解，vector index仅仅是一种向量查询方法，为什么要硬生生跟 AI 挂钩？额外看了下这个视频（https://www.youtube.com/watch?v=dRcjTe5qgwM）最终解释了hopsworks的整体架构——ML Pipelines and AI-enabled Applications:

• Unified API For AI:
  • Feature API(Batch, Streaming, On-Demand)
  • Training API(Training, Fine-Tuning)
  • Inference API(Batch, Online)
• Unified ML Platform For AI:
  • Feature Store (Feature Group, Feature Query Engines)
  • Model Platform(Model Registry for KServe, KServe Deployments)
• Unified Data Layer For AI:
  • Offline Store(Hopsfs)
  • Online Store(RonDB)
  • Vector Index(OpenSearch)
  • Prompt Store(RonDB)

视频中提到 TikTok 的文章：Exabytes of data in ByteDance Iceberg-powered Lakehouse，用TikTok解释 Real-Time AI Systems 需要优化 Feature Freshness（AI Lakehouse 需要接受 Streaming Feature Pipieline 的写作为输入，并支持 Inference Pipeline 从 AI Lakehouse 中读取数据，写入的数据到能够读出来，需要在 ms 或者 s 之间）。

hopsworks 介绍了一篇自己的博客：https://www.hopsworks.ai/post/the-ai-lakehouse，里面介绍了 AI Lakehouse 的基本架构。

最终介绍了 hopsworks 使用 LLM 来增强 lakehouse 的例子：对 Real-Time History&Context 构建 Vector Index，做 RAG，然后通过Function call 来查询 Lakehouse 的 Tables， Lakehouse Tables 的查询结果再次作为 prompt 输入给 LLM。这个视频详细介绍了 Function Calling for LLMs 的用法：https://www.youtube.com/watch?v=dRcjTe5qgwM。

Function Calling Steps when query Feature Groups：

• 输入：必要的 ID 和 用户 query 信息
• 提前写好一些 functions（这些 functions 实现查询当前 FeatureStore 中的表格），把用户 query 信息 + ID 和可用的 functions 一起发送给 LLM，看 LLM 是否决定执行一些 functions
• LLM 返回要执行的 functions 以及 params
• 执行 functions，并收集结果
• 将 functions 的结果进行良好描述，带着原始 query，继续发送给 LLM 进行查询
• 拿到结果

Uber – Uber’s GenAI Oncall Co-Pilot Journey

线上问题多，信息分散，on call 需要等待。uber 构建 On Call Copilot（名为Genie的聊天机器人）遇到如下挑战：相应准确性、数据质量、数据安全、用户体验、bot credibility、human bias。

整体架构是：数据源（wiki、pdf）-> assistant platform(Data ETL, ChatBot, Eval评估数据, Cost成本跟踪) -> IDE/Chat App

关于 Data ETL，通过一个触发器定时运行，有三个阶段：

• DataPrep，负责从Wiki/文件系统中获取源数据，做数据预处理（切块等）。推荐只提供与回答问题相关的数据，提高模型生成的准确性。
• EmbeddingGeneration，可以调用开源的模型或者michelangelo内部托管的模型，对切块的数据做embedding提取
• pusher，将切块数据存储到offline storage中便于debug、trace、retry；另外将embedding推送到VectorDB中支持在线的ann检索。

用户查询问题时，首先使用相同的模型对query进行embedding提取，然后查询VectorDB检索到相关内容，加上用户自定义的prompts，传送给LLM，LLM负责生成答案（包含切块对应原始文件的引用）。过程中，会利用用户ID做串联，将成本计费到ID头上。

效果评估：将 LLM 的输出 + 用户反馈 + 其他元信息 做预处理，然后送给评估模块（LLM as a judge + 经典ML Metrics），然后由Aggregator计算一些可描述的统计指标（平均数、中位数），如果是LLM作为judge则用另一个LLM来总结文本输出。

LLM作为judge的时候，可以询问LLM覆盖率（这个问题是否足以在文档中覆盖它，如果不是，有什么更好的建议）。Demo中基本使用覆盖率这个指标，也会给出未覆盖的片段。

作者提到 genie 节省了13000 engineering hours，16%问题解决率、32.0%有帮助、43.2%无帮助、7.9%不相关。将一个 bot 产品化使用还是很难的。Partner Engagement对bot的准确率很关键。platformization led to self service RAG capabilities。

https://tinyurl.com/uber-genie 阅读更多。

Airbnb – Chronon, Airbnb’s Open Source Feature Engineering Framework

Chronon是一个开源平台，支持ML参与者高效开发、部署、管理并监控ML的 data pipeline。作者提到构建chronon为了解决一下问题：

• 多处定义特征
• 离线、在线的不一致
• 回填慢(backfill)，并导致迭代速度慢
• 构建pipeline时重复的胶水代码
• 多个组织要相互copy工作

从源数据视角，作者对 ML 应用做了2个类别的分类：

• 非结构化数据：图片分类、物体检测、NLP问题、Chat app
• 结构化数据：信用分数、欺诈检测、广告推荐、个性化搜索，Customer LTV

从预估视角，作者也提到2个类型（分别对应非结构化数据与结构化数据，不过这个不一定准确）：

• 所有的数据是一次性可以拿到的，例如从一个图片中直接提取特征，从一个文本中抽取word。
• 随着用户在平台上的交互，data逐步到达，特征需要从很多事件流（登录、点击、页面浏览）中抽取出来。需要交互式的手工定制特征工程（feature engineering）。

看起来，第二种 feature engineering 就是Chronon 的工作场景。常需要使用时序数据库，或者表格类数据库做某个时间窗口内的数据的聚合，由其是点展日志类处理。我以前做过的Imazon更倾向于单个图片的处理，也需要利用一个table拼接等待一个网页的所有的图片都爬取完了，再处理网页的特征，这也可以看做一个聚合操作。比较期待 chronon 的用户接口是怎么设计的。

作者解释了特征值与时间的关系。给定多个特征，以及他们在一个时间窗口内的序列值，对应一个label。随着时间变化，特征会有新的值，label也会变化。这个比较容易理解。

作者提到 offline 采用 SQL 来处理训练样本（或者说 feature engineering），online 时一般根据service语言选择来编码（java、c++、python），这里存在重复工作，且可能导致不一致。chronon提供的python接口的 api，来作为中间层语言。在 Feature Management System 中，用户通过 chronon 提供的 feature definition 与 aggregation library 来做特征定义以及聚合操作实现，在离线的训练pipeline以及在线serving pipeline中都使用相同的 feature definition 与 aggregation library，实现了离在线统一。另外，作者提供模型训练可以使用training pipeline实现快速的backfills，在线预估阶段可以实现低延迟预估，可能跟底层基于scala engine实现有关。

阅读更多: https://github.com/airbnb/chronon, https://chronon.ai/

TODO:

iceberg, delta lake, hudi, parquet, chronon

https://www.hopsworks.ai/post/the-ai-lakehouse