特征存储（feature store）
/ FEE-chur stor /
特征存储，是一个集中的去处，用来计算、储存并供给机器学习模型所「吃」的那些输入变量（也就是「特征」）。所谓特征，不过是关于某事物、一份预先备好的信息——一位客户过去 30 天的平均购买额、一件商品的品类、一个用户本周登录了多少次。特征存储，就是那间共享的食材间：这些食材在这里备好一次、码放整齐，再一致地分发给任何需要它们的人。
它解决的，是一个静悄悄却很折磨人的问题。同一个特征——比方说「客户 30 天的消费额」——会在两处用到：训练时（在历史数据上算）和线上服务时（在新鲜数据上算，还得快）。要是两个团队算得稍有出入，模型就在一种定义上训练、却在另一种定义上服务，准确度便莫名其妙地烂掉。这就是臭名昭著的「训练—服务偏差」。特征存储把每个特征只定义一次，保证同一个值同时流向训练和服务，同时还让各团队彼此复用对方的特征，而不必重造。
为什么这很重要：在成熟的机器学习组织里，把特征做对、做一致，其价值往往胜过一个更花哨的模型，而特征存储正是让这份纪律能规模化的基础设施。诚实的提醒是：它是一件相当重的基础设施，主要对那些有许多模型、许多团队共享数据的组织才划算。对一个单独的小项目而言，它可能是杀鸡用牛刀——一张表格、一段简单脚本就够了。它解决的是一个协同问题，要是你压根没那个问题，也就用不着这副药。
一个反欺诈模型需要「过去一小时内的交易笔数」。特征存储为两个世界用同一种方式算它：一个批处理任务为训练填好历史值，而一次快速查询，在刷卡的那一刻供给实时值——保证模型看到的是同一套一致的定义。
一个特征定义，两条供给路径——这正是治「训练—服务偏差」的药。
特征存储是为「协同问题」而设的基础设施，而不是建模上的升级。当许多团队和模型共享数据时，它才挣回自己的饭钱；对一个孤零零的项目，它通常是不必要的负担。别仅仅因为它听起来专业，就搬一个来用。