想象你是一家连锁餐厅的老板。十几个分店的后厨各自买菜、各自切配、各自凭手感调味,同一个“鱼香肉丝”,有的店咸、有的店甜,顾客投诉不断。要改变乱象,你决定建一座中央厨房:统一采购生鲜、统一洗切分装,把食材变成贴着标签的半成品送进冷库,任何分店高峰期下单,几秒就能取出来,而且和主厨试菜时的味道一模一样。推荐系统的“特征平台”,就是算法世界里的这座中央厨房。 推荐模型不靠魔法预测喜好,它依赖海量“特征”:用户点过什么、停留多久、商品什么价格。没有平台时,各团队自己写脚本加工特征,口径不一、线上线下对不上味,模型一上线就翻车。特征平台把特征的加工、存储、服务、复用统一管起来,让团队像用中央厨房的半成品一样,高效、稳定、口味一致地“做菜”。

岗位关联

对 AI 从业者而言,特征平台是推荐系统从“作坊式实验”走向“工业化交付”的必经之路,掌握它能让你独立设计一套特征高效生产、稳定服务的工程体系,是从初级算法工程师走向系统型工程师的关键一跃。

目录
  1. 可视化演示
  2. 平台概述:从混乱后厨到中央厨房
  3. 核心架构:中央厨房的四间房
  4. 特征管理:菜谱手册的规矩
  5. 一致性保障:堂食与外卖必须同味
  6. 性能优化:高峰期也能秒出菜
  7. 实践案例:连锁餐厅的标准化手册
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

演示推荐系统特征平台的核心流程:原始特征抽取、统一存储、在线特征服务与监控反馈,并对比关键性能指标与优化策略,帮助理解特征工程在推荐实践中的落地。

本节配有交互动效(进入视口后自动加载,约 3KB)。

特征平台全流程 抽取:汇聚离散与连续原始特征 存储:统一特征库与元数据 服务:低延迟在线特征获取 反馈:监控质量与回流优化 特征统一 驱动模型效果

平台概述:从混乱后厨到中央厨房

假设你经营连锁餐厅,几个分店的后厨各买各的菜、各切各的葱姜蒜,厨师凭手感放盐,顾客今天说咸、明天说淡。要解决乱象,就得建一座中央厨房:统一采购、统一切配、统一分装,把食材变成贴好标签的半成品,再配送到各分店。特征平台在推荐系统里扮演的正是这个角色——把“怎么做特征”这件容易各搞各的事,变成一套标准化流水线。

推荐模型要预测用户会不会点一个商品,依赖大量“特征”:用户点过什么、浏览多久、商品多贵、当前什么时段。早期团队各自写脚本算特征,口径五花八门,同样叫“点击次数”,有人按 7 天统计、有人按 30 天统计,模型一上线就“翻车”。特征平台要解决的,就是统一特征的加工、存储、服务与治理,让所有人共用同一套标准。

一个特征可以被看作一种加工函数:给定用户、物品和时刻,输出一个数值。

有了平台,特征就像半成品食材一样标准化。工程师不需要关心特征怎么算出来的,只需从“菜谱”里查到定义、拿到结果直接用。整个推荐系统的迭代速度因此成倍提升,这就是平台最朴素的业务价值——把做饭的精力从“切菜”解放到“研发新菜”上。

f(u,i,t)=ψ(U(u,t), I(i), C(t))\displaystyle f(u, i, t) = \psi\bigl(U(u, t),\, I(i),\, C(t)\bigr)
这个公式概括了特征的本质:任意特征都是“用户历史 + 物品属性 + 上下文”三者经加工后的结果。
  1. 输入三元组特征由用户、物品、时刻三个要素共同决定,任一要素变化,特征值都可能改变。
    (u,i,t)(u, i, t)
  2. 用户信号提取该用户截至时刻 t 的行为历史,如点击次数、停留时长。
    U(u,t)U(u, t)
  3. 物品属性抽取物品自身的静态属性,如价格、类目、品牌。
    I(i)I(i)
  4. 上下文特征刻画推荐发生时的环境信息,如时间段、设备类型。
    C(t)C(t)
  5. 加工函数把三类输入变换为数值向量,即最终的特征计算结果。
    ψ(⋅)\psi(\cdot)

核心架构:中央厨房的四间房

一座中央厨房通常有四间房:备菜间负责大批量洗切,冷库负责保鲜存储,出菜口负责高峰期快速交付,墙上的菜谱手册记录每道菜的标准做法。特征平台的核心架构恰好与之对应,四类组件缺一不可。

第一是离线计算引擎:像备菜间一样,用 Spark、Hive 等框架按小时或按天批量处理海量历史日志,产出训练用的特征表。第二是特征存储组件:像冷库,离线结果落到宽表或文件,在线实时特征落到 Redis 这类 KV 存储。第三是在线特征服务:像出菜口,提供低延迟的 SDK,让线上推理请求在几毫秒内拿到特征。第四是元数据管理:像菜谱手册,登记每个特征的口径、负责人、版本,是平台治理的基石。

在线服务的延迟是架构设计的第一约束,缓存、KV 存储、网络每一环都在抢时间:

四间房各司其职:备菜间批量产出大部分特征,冷库把热数据放到最快的位置,出菜口用统一协议对外服务,菜谱手册保证所有人按同一标准做事。理解了这四块,你就理解了特征平台架构的主干。

Tbudget=Tcache+Tkv+Tnet≤50 ms\displaystyle T_{budget} = T_{cache} + T_{kv} + T_{net} \leq 50\ \mathrm{ms}
特征服务的端到端延迟由缓存、存储、网络三段组成,总和必须控制在 50 毫秒以内,这是在线架构设计的核心不等式。
  1. 总预算在线服务端到端延迟必须控制在 50 毫秒以内,否则推荐接口整体超时。
    Tbudget≤50 msT_{budget} \leq 50\ \mathrm{ms}
  2. 缓存耗时命中本地缓存时的读取时间,通常在微秒级。
    TcacheT_{cache}
  3. 存储耗时未命中缓存、需要访问 KV 存储时的耗时,毫秒级。
    TkvT_{kv}
  4. 网络耗时跨机房或跨进程通信带来的固定开销。
    TnetT_{net}
  5. 加和约束三段耗时相加不得超过总预算,是特征服务架构设计的核心约束。
    Tcache+Tkv+TnetT_{cache} + T_{kv} + T_{net}

特征管理:菜谱手册的规矩

中央厨房的菜谱手册会写清楚每道菜的用料、刀工、火候,谁改动了菜谱必须记录在案。特征平台的特征管理,同样围绕“菜谱”展开,核心是规范、注册、版本、复用四件事。

定义规范要求每个特征必须有明确的名字、类型、口径和负责人。注册与发布让开发者在平台上用 SDK 或界面登记特征,平台自动接好离线加工与在线服务链路。版本与口径是重中之重:口径就是“这个特征怎么算”,比如“近 7 天点击次数”,一旦修改必须升版本,否则线上线下的味道就对不上。特征复用让不同团队共享公共特征,避免重复建设。

特征版本的管理可以抽象成一个元组,每个特征版本由四要素唯一标识:

菜谱手册的规矩越清晰,后厨越不会乱。特征管理做得好,团队之间就能放心复用彼此的特征,像共享半成品食材一样,不用每次从剥蒜开始。这也是平台让协作效率发生质变的关键。

V(f)=(owner, caliber, commit_id, ts)\displaystyle V(f) = \bigl(\text{owner},\, \text{caliber},\, \text{commit\_id},\, ts\bigr)
一个特征版本由“负责人、口径、代码提交号、发布时间”四元组唯一确定,任何一项变化都意味着一个新版本。
  1. 版本标识用四元组唯一标识一个特征版本,版本是治理的最小单元。
    V(f)V(f)
  2. 负责人标注特征由哪个团队或个人维护,出问题时能快速找到责任方。
    owner\text{owner}
  3. 口径标识唯一标识特征的计算规则,如“近 7 天点击次数”。
    caliber\text{caliber}
  4. 提交号代码仓库中的提交编号,精确定位这次改动改了什么。
    commit_id\text{commit\_id}
  5. 发布时间记录版本发布的时间戳,支持回滚与审计。
    tsts

一致性保障:堂食与外卖必须同味

顾客最怕的一件事,是堂食的鱼香肉丝和外卖的鱼香肉丝味道不一样。推荐系统同样怕“味道不一致”:模型训练时看到的特征,和上线后线上喂给模型的特征,必须是一回事。这个问题有个专业名字叫“训练推演偏差”(train-serve skew)。

造成偏差的根源有三类:其一是加工逻辑分叉,离线脚本和在线代码各自维护,看似相同实则不同;其二是口径版本没同步,训练用了新口径、线上还在用旧口径;其三是时间穿越,训练样本不小心用到了“未来”的数据。要解决,平台会强制离线批处理和在线实时计算共用同一套加工代码,并配合特征的时间对齐与分布校验。

时间对齐是防止“未来信息”泄露的关键约束,任何特征在标签时刻必须是“可知”的:

只有保证堂食和外卖同味,顾客才会信任这家餐厅。一致性保障手段(同代码、时间对齐、分布校验)就是特征平台的质量检查线,一旦偏离能及时发现,避免模型在线上“悄悄变难吃”。

Xt=g({ds∣s<tlabel})\displaystyle X_t = g\bigl(\{d_s \mid s < t_{label}\}\bigr)
时刻 t 的特征只能由标签时刻之前的历史行为算出,绝不允许“偷看未来”,这是训练数据正确性的底线。
  1. 标签时刻训练样本中预测目标实际发生的时间点,比如用户“是否购买”发生的那一刻。
    tlabelt_{label}
  2. 历史数据集合只取标签时刻之前产生的全部行为数据。
    {ds∣s<tlabel}\{d_s \mid s < t_{label}\}
  3. 加工函数把历史数据聚合为特征,常见操作有求和、计数、均值。
    g(⋅)g(\cdot)
  4. 无泄漏特征生成的任意时刻特征在标签时刻都是可知的,训练与线上口径完全一致。
    XtX_t

性能优化:高峰期也能秒出菜

餐厅最怕中午高峰期后厨忙不过来。聪明的做法是:把最受欢迎的几道菜提前做熟放在出菜口保温柜里,顾客一点就端出来;同时把多个订单合并处理,减少来回跑动。特征平台的性能优化,思路完全一致。

缓存加速对应保温柜:把热门用户和物品的特征放进本地内存或分布式缓存,命中就直接返回,不用访问底层存储。批量拉取对应合并订单:一次 RPC 请求同时取几十个特征,而不是串行请求几十次。降级容错对应“菜没了换个做法”:服务超时或存储抖动时,返回默认特征值,保证推荐接口不挂。资源调度则给最热的特征分配最多的缓存资源。

缓存的收益可以用期望延迟来量化,命中率越高,平均延迟越低:

保温柜、合并订单、备用方案三管齐下,高峰期也能稳定出菜。性能优化没有一招制胜,围绕命中率、批量化和容错持续打磨,在线特征服务才能扛住亿级流量。

Teff=HR×Tcache+(1−HR)×Tkv\displaystyle T_{eff} = HR \times T_{cache} + (1 - HR) \times T_{kv}
实际响应时间等于命中率加权的缓存耗时与存储耗时之和,缓存命中率直接决定在线服务快不快。
  1. 命中率请求中命中缓存的比例,衡量缓存策略的有效性。
    HRHR
  2. 快路径耗时命中缓存时直接返回特征所需的时间。
    TcacheT_{cache}
  3. 慢路径耗时未命中缓存、回源访问 KV 存储所需的时间。
    TkvT_{kv}
  4. 期望延迟按命中率加权后的平均响应时间,数值越小越好。
    TeffT_{eff}
  5. 加权等式命中比例乘以快路径耗时,加上未命中比例乘以慢路径耗时。
    HR×Tcache+(1−HR)×TkvHR \times T_{cache} + (1 - HR) \times T_{kv}

实践案例:连锁餐厅的标准化手册

把中央厨房开成全国连锁,最后靠的是一本厚实的标准手册:什么食材进什么库、切多大尺寸、装多少克一盒、出菜时限多少秒。某电商平台的信息流推荐系统,也走过同样的路:从各自为战到统一特征平台,最终沉淀出一套完整的工程实践。

业务场景:App 首页信息流,每天承接数十亿次推荐请求,每请求需要数百个特征。改造前,特征散落在多个团队脚本里,口径对不上,新增特征从开发到上线要数周。架构设计:离线用 Spark 批量加工历史特征,实时用 Flink 计算行为序列,统一落到 Redis 特征库,在线通过特征服务 SDK 批量拉取,元数据中心登记全部特征的版本与血缘。收益评估:新特征开发周期从两周缩短到两天,训练与线上特征偏差率从 8% 降到 0.5%。

业务收益最终要看推荐效果,点击率相对提升是常用的衡量指标:

案例背后的踩坑经验同样宝贵:新特征必须历史回填、口径变更必须升版本、缓存必须监控命中率。这些经验被写进“标准手册”,成为团队持续复用的资产。特征平台的建设没有终点,它就是把每一次成功和失败的教训,沉淀成大家共同遵守的厨房规矩。

ΔCTR=CTRnew−CTRoldCTRold×100%\displaystyle \Delta CTR = \frac{CTR_{new} - CTR_{old}}{CTR_{old}} \times 100\%
新特征或新架构带来的点击率相对提升,是评估特征平台业务价值的直接量化指标。
  1. 新旧点击率分别表示新特征上线前后的推荐点击率。
    CTRnew, CTRoldCTR_{new},\ CTR_{old}
  2. 绝对差值衡量点击率的绝对提升幅度,越大说明效果越好。
    CTRnew−CTRoldCTR_{new} - CTR_{old}
  3. 相对提升率除以旧值得到相对提升比例,便于跨实验对比。
    CTRnew−CTRoldCTRold\frac{CTR_{new} - CTR_{old}}{CTR_{old}}
  4. 百分比口径乘以 100% 得到业务汇报中常用的百分比数值。
    ×100%\times 100\%

AI 应用场景

实时推荐特征服务

阶段:在线推理(特征服务阶段)

解决的问题:传统做法是算法工程师每次实验都自己写 Redis 读写脚本,特征散落在各团队代码里,口径不统一、延迟高。特征平台统一提供 SDK,一行代码拉取用户与物品的全量特征,缓存与批量拉取自动生效,像从冷库取标准半成品,不需要自己种菜。

具体案例:某电商 App 首页信息流每次请求需要 200 个特征。接入特征平台后,批量拉取把 200 次串行访问合并为 1 次 RPC,P99 延迟从 80ms 降到 35ms,模型在线 AUC 保持稳定。

新特征上线与历史回填

阶段:离线训练(特征工程阶段)

解决的问题:新特征只从“今天以后”开始计算,训练集和线上不一致,模型上线效果必然打折。特征平台在注册新特征时自动生成“历史回填任务”,按同一口径把过去 90 天的训练样本全部补齐,相当于新菜上线前先让总厨试吃 90 天。

具体案例:用户“近 7 天浏览某类目时长”特征上线,平台自动回填 90 天训练样本,A/B 实验 CTR 提升 3.2%,回填耗时 4 小时完成,全程无需人工干预。

特征质量监控与告警

阶段:模型运维(数据质量阶段)

解决的问题:特征漂移或上报异常时,模型质量会悄悄下降,人工难以察觉。特征平台对每个特征做分布监控,离线与在线分布偏差超阈值自动告警,类似中央厨房给冷库装温湿度传感器。

具体案例:某特征在凌晨出现大面积缺失,平台监测到在线取值分布与离线基线偏差超过 5 倍标准差,10 分钟内推送告警,值班工程师回滚特征版本,避免了大面积推荐质量劣化。

Python 演示

python127 行
# -*- coding: utf-8 -*-"""简化版特征平台:离线加工 + 在线服务 + 缓存加速"""import random  class FeatureDefinition:    """特征定义:描述特征名称、类型与负责人"""    def __init__(self, name, ftype, owner, description=""):        self.name = name        self.ftype = ftype        self.owner = owner        self.description = description  class FeatureRegistry:    """元数据中心:统一注册特征,支持查询与复用"""    def __init__(self):        self.features_map = {}     def register(self, feature):        if feature.name in self.features_map:            raise ValueError("feature %s already exists" % feature.name)        self.features_map[feature.name] = feature     def get(self, name):        return self.features_map.get(name)  class FeatureStore:    """特征存储:key=(user,item),value=特征向量"""    def __init__(self):        self.data_map = {}     def write(self, key, value):        self.data_map[key] = value     def read(self, key):        return self.data_map.get(key)  class OnlineServing:    """在线特征服务:带LRU缓存,自动统计命中率"""    def __init__(self, store, cache_size=128):        self.store = store        self.cache = {}        self.cache_order = []        self.cache_size = cache_size        self.hit_count = 0        self.request_count = 0     def get_features(self, user, item):        key = (user, item)        self.request_count += 1        if key in self.cache:            self.hit_count += 1            return self.cache[key]        value = self.store.read(key)        if value is not None:            self._put_cache(key, value)        return value     def _put_cache(self, key, value):        if key in self.cache:            self.cache_order.remove(key)        self.cache[key] = value        self.cache_order.append(key)        if len(self.cache_order) > self.cache_size:            old_key = self.cache_order.pop(0)            del self.cache[old_key]     def hit_rate(self):        if self.request_count == 0:            return 0.0        return self.hit_count / float(self.request_count)  def offline_compute(logs):    """离线批量计算:把原始行为日志加工成特征向量"""    store = FeatureStore()    for log in logs:        key = (log["user"], log["item"])        hist = store.read(key)        if hist is None:            hist = [0, 0, 0.0]        hist[0] += 1                                  # 点击次数累加        hist[1] += log.get("view_time", 0)             # 累计浏览时长        hist[2] = max(hist[2], log.get("price", 0.0))  # 历史最高价格        store.write(key, hist)    return store  def main():    random.seed(42)    registry = FeatureRegistry()    registry.register(FeatureDefinition("click_cnt", "int", "rec_team"))    registry.register(FeatureDefinition("max_price", "float", "rec_team"))     users = [1001, 1002, 1003]    items = [2001, 2002, 2003]    logs = []    for _ in range(3000):        logs.append({            "user": random.choice(users),            "item": random.choice(items),            "view_time": random.randint(1, 60),            "price": random.uniform(1.0, 10.0),        })     # 离线加工:所有日志变成特征向量    store = offline_compute(logs)     # 在线服务:带缓存的批量特征查询    serving = OnlineServing(store)    requests = [(random.choice(users), random.choice(items)) for _ in range(500)]     sample = serving.get_features(requests[0][0], requests[0][1])    print("sample feature:", sample)     for user, item in requests:        serving.get_features(user, item)     print("cache hit rate: %.2f" % serving.hit_rate())    print("registered features:", len(registry.features_map))  if __name__ == "__main__":    main()
目的:用 200 行不到的代码模拟一个微型特征平台,演示“特征注册 → 离线加工 → 在线服务 → 缓存加速”的完整闭环。
  1. class FeatureRegistry:模拟元数据中心,所有特征先注册再使用,就像菜谱先登记再开工。
  2. hist[0] += 1 # 点击次数累加离线加工的核心是把原始日志聚合成统计特征。
  3. if key in self.cache:命中缓存直接返回,避免每次请求都访问底层存储。
  4. old_key = self.cache_order.pop(0)缓存满了,淘汰最久未用的 Key,模拟 LRU 策略。
  5. def hit_rate(self):统计命中率,这是评估缓存效果、指导资源调度的关键指标。
  6. store.write(key, hist)加工结果写回特征存储,供训练和在线服务共用同一份数据。
  7. serving.get_features(user, item)在线拉取特征时走统一接口,训练与上线共用同一口径。

常见误区

误区“特征平台不就是把算好的特征存起来、线上能查到就行吗?跟 Redis 差不多,重点是数据塞进去。”

正解存储只是特征平台的一小块。它更像中央厨房:要管菜谱(口径定义)、管备菜(离线加工)、管冷库(存储)、管出菜(在线服务)、管质检(监控校验)。漏掉任何一环,平台就退化成“手动跑脚本 + 手动导数据”,一致性、复用、迭代速度全都回到作坊式水平。

为何常见:初学者最早接触特征平台时,往往在文档里先看到“特征存储”组件,误以为存储就是全部;没经历过“口径不一致导致模型翻车”的痛,自然低估了治理的价值。

误区“离线训练和上线时都用同一个函数算特征,那肯定就一致了,不用再做校验。”

正解代码一致只是必要条件,不是充分条件。即使代码相同,数据源、时间窗口、默认值、降级策略都可能不同:离线可以用全量日志,线上可能只见得到部分实时流;线上超时返回默认值,离线却按真实值计算。所以还需要持续做分布对比和信号校验,像餐厅每天抽查堂食与外卖的口味。

为何常见:人们容易把“逻辑相同”和“结果相同”混为一谈,忽略了数据到达早晚、缺失率、默认值这些现实差异。

误区“特征平台能力这么强,那就把所有能想到的统计量都做成特征,模型总能学到东西。”

正解特征不是越多越好。无区分度的特征带来存储和计算开销,高度相关的特征增加训练成本,还提高了口径管理与监控的复杂度。实际中平台会做特征有效性评估与下线机制,像中央厨房定期清理卖不动的库存,避免食材囤积过期。

为何常见:直觉上“信息越多越准”,忽视了特征工程的边际收益递减和运维成本,把模型能力错误归因于特征数量。

误区“新特征从今天开始算就行,反正以后训练数据都会带上它,不用浪费时间回填历史。”

正解如果不回填,训练集里新特征全是缺失或默认值,模型学不到新特征的贡献;而线上却是真实值,训练与推演直接不一致,上线效果会大打折扣。正确做法是注册特征时自动触发按同一口径的历史回填,保证训练样本“和线上一样有味道”。

为何常见:回填成本高、链路长,新人容易为了赶实验进度跳过这一步,直到模型上线效果负向才回头补课。

面试题

Q1. 特征平台最核心的定位是下列哪一项?

单选题 · easy

  • A.直接替换推荐算法的模型训练
  • B.统一特征的加工存储与服务链路← 正确答案
  • C.只负责用户行为日志的离线存储
  • D.替代运营人员完成推荐选品工作

答案:B。特征平台的核心是“统一管理特征从加工到服务的全链路”,相当于中央厨房统一备菜与供给;它不训练模型(A)、不只做存储(C)、也不自动选品(D)。

Q2. 训练时算的特征与上线时用的特征不一致,专业上通常称为?

单选题 · easy

  • A.模型训练中梯度消失难收敛问题
  • B.特征存储容量严重不足的问题
  • C.训练与推演特征偏差的问题← 正确答案
  • D.线上流量突增导致过载的问题

答案:C。train-serve skew(训练推演偏差)指训练与上线特征不一致,像堂食和外卖味道不同;其余选项分别是训练优化、存储容量、流量治理问题,与特征口径无关。

Q3. 在线特征服务中“缓存命中率”的正确计算公式是?

单选题 · mid

  • A.缓存内容占存储总量的百分比值
  • B.缓存容量除以请求并发数的值
  • C.命中缓存次数除以总请求次数← 正确答案
  • D.缓存写入次数乘以读取次数的积

答案:C。命中率 = 命中缓存次数 ÷ 总请求次数,衡量请求走“快路径”的比例;A 是存储占比,B 是容量与并发的关系,D 是读写次数乘积,都不能反映命中比例。

Q4. 为避免训练样本泄露“未来信息”,特征计算应当怎么做?

单选题 · mid

  • A.使用截至当前的全量历史数据
  • B.只使用样本当天的行为数据
  • C.混入模型下一轮的预测结果
  • D.只取标签时间之前的行为数据← 正确答案

答案:D。point-in-time 原则要求只用标签时刻之前的数据,像做菜只看已经进库的食材;A 可能混入未来数据,B 仍可能包含标签后数据,C 直接泄露未来,只有 D 正确。

Q5. 特征平台中元数据中心的主要职责是?

单选题 · hard

  • A.维护特征的规格口径与负责人← 正确答案
  • B.把加工后的特征直接返回用户
  • C.替代离线引擎做批量加工计算
  • D.为线上模型实时更新网络权重

答案:A。元数据中心像菜谱手册,登记“特征怎么算、谁负责、什么版本”;B 是特征服务,C 是计算引擎,D 是模型训练,都不是元数据中心的职责。

Q6. 某高频热点特征的缓存命中率偏低,最有效的优化方法是?

单选题 · hard

  • A.删除该特征预热的缓存记录
  • B.缩小缓存容量并降低其优先级
  • C.关闭该特征服务的降级兜底
  • D.热点扩容缓存并支持批量拉取← 正确答案

答案:D。热点特征应扩容缓存、增加副本,并把多个特征合并为一次批量拉取以降低回源压力;A 删除缓存、B 缩小容量、C 关闭兜底都会让情况更糟。

Q7. 特征平台中常见的性能优化手段包括哪些?

多选题 · mid

  • A.引入本地缓存与分布式缓存← 正确答案
  • B.单次请求批量拉取多个特征← 正确答案
  • C.超时降级并返回默认特征值← 正确答案
  • D.把所有特征都改成实时流式计算

答案:ABC。缓存(A)、批量拉取(B)、降级容错(C)是三大常用手段;全部实时化成本高且没必要,冷特征应离线加工、缓存加速,所以 D 不选。

Q8. 下列哪些情况会导致训练与推演特征不一致?

多选题 · hard

  • A.离线与在线加工逻辑代码分叉← 正确答案
  • B.特征口径版本更新后未同步← 正确答案
  • C.训练集计算时混入了未来信息← 正确答案
  • D.推荐页面 UI 模板重新改版上线

答案:ABC。代码分叉、版本不同步、时间穿越是造成 train-serve skew 的三大典型原因;UI 改版不影响特征计算口径,所以 D 不选。

Q9. 建设特征平台带来的主要业务价值有哪些?

多选题 · easy

  • A.新特征从立项到上线的周期缩短← 正确答案
  • B.特征可跨团队复用与共享← 正确答案
  • C.线上线下特征一致性有保障← 正确答案
  • D.完全替代算法工程师调参工作

答案:ABC。平台最直接的价值是加速特征迭代、促进复用共享、保障线上线下一致性;D 把模型调参这一算法工程师的核心职责也归给平台,显然是错误选项。

Q10. 特征描述中的“口径”具体指的是?

单选题 · mid

  • A.特征计算规则与统计窗口定义← 正确答案
  • B.特征在存储中占用的物理空间
  • C.线上特征服务进程的数量规模
  • D.模型推理所用机器型号与规格

答案:A。口径是“特征怎么算”,例如“近 7 天点击次数”中的统计窗口和聚合方式;其余选项分别对应存储容量、服务规模和硬件配置,都不是口径的含义。