【XGBoost 系列 第2讲】输入特征设计：截面因子、时序特征与标签定义

一、目标与场景

XGBoost 第二讲讨论输入特征设计。很多团队在做量化建模时，会很快跳到树深、学习率、正则化、早停轮数这些参数上，仿佛调参才是模型成败的核心。但在真实项目里，模型表现的上限往往不是由调参决定的，而是由输入决定的。输入特征如果没有边界，标签如果没有口径，样本如果存在泄漏，调参越细，越可能把错误放大。

XGBoost 适合处理结构化表格数据，也能容纳非线性关系和特征交互，但这不代表它可以替团队处理所有研究口径问题。模型不知道某个字段是否在交易时点可见，不知道某个标签是否和执行周期一致，也不知道某批样本是否被错误混入训练集。它只会根据输入学习规律。因此，输入设计不是模型前的杂务，而是建模本身的一部分。

这一讲把输入拆成三个核心对象：截面因子、时序特征和标签定义。截面因子负责同一时点上的横向比较，时序特征负责同一资产随时间变化的描述，标签定义负责告诉模型到底要学习什么。三者要放在同一套流程里设计，而不是由不同脚本临时拼接。只有输入体系稳定，后续参数调优、特征解释、分层组合和线上部署才有基础。

本文聚焦 XGBoost 输入表的专业设计方法，不讨论收益承诺，也不把某一种特征写成通用答案。这里重点讲方法：如何定义研究问题，如何组织截面和时序信息，如何防止泄漏，如何建立特征字典和复盘机制。目标是让 XGBoost 输入表从“能训练”变成“可信、可复现、可解释”。

在这个目标下，输入表不应该只是一个临时拼出来的 DataFrame，而应该是一份带有契约的研究资产。每一列为什么存在，每一行代表什么，每一次过滤基于什么规则，都应该能说明白。否则模型训练虽然可以执行，但研究结论无法稳定传递给下一轮实验，也无法传递给工程和风控环节。

二、输入规范

在设计特征之前，先定义研究问题。一个可执行的问题至少要包含四个边界：目标资产范围、决策频率、持有周期和评价口径。目标资产范围决定截面比较的对象；决策频率决定特征更新速度；持有周期决定标签窗口；评价口径决定模型输出最终如何被使用。如果这些边界没有写清楚，特征工程就会不断膨胀，最后变成无法解释的输入集合。

输入表的每一行，也要有清晰含义。比如一行代表某资产在某交易日的一个观察样本，那么这行里的所有特征都必须在该交易日的决策时点可见，标签必须发生在决策之后。这个原则看起来简单，但很多错误都出在这里。只要有一个字段提前看到了未来，验证结果就会被污染。

字段命名也要规范。建议命名能反映来源、窗口和变换方式，例如是否是截面标准化、是否是滚动窗口、是否做了分位处理。命名不是形式，命名清楚之后，后续做重要性分析、SHAP 解释、异常排查和版本迁移都会轻很多。反过来，如果大量字段只叫 feature_1、feature_2，模型训练也许能跑，但团队很难维护。

输入规范还要说明缺失值处理方式。缺失不是单一问题，停牌、上市时间不足、字段不适用、接口异常都会造成缺失。对 XGBoost 来说，缺失值本身可以被模型处理，但团队仍然需要知道缺失来自哪里。比较稳的做法，是在必要时保留缺失标记，让模型和复盘都能看到缺失结构，而不是盲目填成一个数。

输入规范还应包含样本池版本。量化任务里的截面比较依赖样本池，如果今天使用全市场，明天使用某个指数成分，后天又排除流动性不足样本，那么同一个因子值的含义都会改变。样本池不是筛选小动作，而是研究设定的一部分。每次样本池变化，都应该记录生效时间、纳入规则、剔除规则和责任人。

另外，输入表要尽量避免混合不同更新频率而不加说明。日频行情、财务数据、公告事件、行业分类、风险暴露，它们的更新时间和可见时间不同。如果只是按日期简单合并，很容易把尚不可见的信息提前放入样本。正确做法是先定义每类数据的可见性，再做对齐，而不是先合并再补解释。

从实操角度看，一张合格的 XGBoost 训练表至少应包含几类基础列：trade_date 表示样本日期，instrument 表示资产代码，universe_flag 表示是否属于本轮样本池，is_tradable 表示当期是否可交易，label 表示监督学习目标，后面再接入截面因子、时序特征和必要的状态标记。训练时可以只把特征列送入模型，但这些基础列不能丢，因为它们决定样本能否被审计、能否回放、能否和预测输出重新对齐。

一个常见的输入表 schema 可以按以下方式理解：标识列负责定位样本，过滤列负责说明样本是否可用，标签列负责说明学习目标，特征列负责提供模型输入，辅助列负责复盘。辅助列不一定进入模型，但在排查时非常关键，例如行业、样本池版本、数据版本、缺失标记、极端样本标记等。专业项目里，训练矩阵可以很干净，但训练矩阵背后的宽表必须保留足够上下文。

三、截面因子设计

截面因子回答的是“同一时点谁更强、谁更弱”。在选股、排序、分层组合等任务中，截面信息非常重要。常见的截面处理包括排名、分位数、行业内标准化、去极值、横截面 z-score 等。它们的目的不是让数值变得更漂亮，而是让不同资产之间可以比较。

设计截面因子时，第一原则是可比性。不同资产的价格、成交额、波动和财务规模本来就不在同一尺度上，如果直接把原始数值输入模型，模型可能学到的是规模差异，而不是可交易信号。第二原则是稳定性。一个因子如果只在某一小段样本里有效，需要标注为阶段性特征，而不是直接进入稳定特征层。第三原则是可追踪性。因子从哪些字段计算而来、如何标准化、是否做行业中性处理，都要能回放。

截面因子还要避免同质堆叠。很多团队会把多个高度相关的指标同时放进去，表面上特征数量增加了，实际上信息增量很小。XGBoost 虽然能处理一定冗余，但冗余过多会让重要性解释变得混乱，也可能让模型在不同训练窗口里选择不同的替代特征，表现出不稳定。

另一个需要注意的问题，是截面池的口径。全市场、指数成分、行业内样本、可交易样本，不同样本池生成的截面排名不一样。一个因子在全市场的分位值，和在某个行业内部的分位值，表达的不是同一件事。因此，截面因子必须绑定样本池口径，不能脱离上下文使用。

截面因子最好分层管理。基础层可以放长期稳定、含义清楚、覆盖较好的特征；增强层可以放经过验证但仍需观察的特征；实验层可以放本轮试验新增的特征；退役层记录已经不用但需要追溯的特征。这样做的好处是，团队不会把所有特征混成一锅，也不会因为一次实验表现不错，就把阶段性特征直接推到稳定流程里。

四、时序特征设计

时序特征回答的是“同一资产在时间上发生了什么变化”。动量、反转、波动、量价关系、成交活跃度、均线偏离、状态切换，都可以属于时序特征。时序特征最重要的是窗口设计和可见性控制。窗口太短，噪声会很多；窗口太长，反应会变慢。窗口没有绝对标准，必须和交易频率、持有周期、调仓节奏联系起来。

设计时序特征时，建议先写业务假设，再写计算方式。比如一个短窗口动量特征，是为了捕捉近期强弱延续；一个长窗口波动特征，是为了描述风险状态；一个成交量变化特征，是为了观察参与度是否变化。假设写清楚后，后续评估特征时才知道应该看什么，而不是只看模型分数是否上升。

时序特征还要特别防止未来函数。滚动均值、滚动波动、分位数、标准化参数，都必须只用当前时点之前的数据计算。如果在整个样本上统一标准化，再切训练和验证，就可能把未来分布信息带入训练。比较稳的方式，是把所有随时间变化的统计量都放进滚动或训练窗口内部计算，并记录窗口边界。

对于多窗口特征，也要控制重复表达。不同窗口可以提供不同时间尺度的信息，但如果每个指标都随手展开许多窗口，输入表会迅速膨胀。更稳的做法，是先设定少量有明确含义的窗口，再观察它们在不同阶段的贡献和稳定性。特征越多，越需要版本和退役机制。

时序特征还要和调仓频率匹配。一个低频调仓策略，不一定需要非常细的短窗口扰动特征；一个高频或短周期策略，也不能只依赖反应迟缓的长窗口特征。特征窗口和决策频率不匹配，会让模型学到不稳定关系。输入设计时应先确认策略动作多久发生一次，再决定特征应该观察多长历史。

五、标签定义

标签是监督学习的目标，也是最容易导致结果失真的地方。标签定义要回答三个问题：预测对象是什么，预测窗口多长，模型输出如何进入交易动作。比如是预测未来收益、未来相对排名、上涨概率，还是某种风险调整后的方向信号，它们对应的训练目标和评估方式完全不同。

标签必须和执行逻辑一致。如果模型训练的是未来一段收益，但实际交易使用的是分层排序，那么标签和交易动作之间就要有明确映射。如果最终决策会扣除交易成本、限制换手、控制行业暴露，那么标签或评估阶段也要考虑这些约束。训练目标和执行目标脱节，是很多离线结果无法落地的重要原因。

标签还要有可审计性。任意一行样本都应该能追溯标签如何生成，使用了哪些价格，窗口从哪里开始到哪里结束，遇到停牌或无法交易时如何处理。如果标签计算散落在临时脚本里，后续很难复盘。标签脚本应该像特征脚本一样进入版本管理。

不要频繁变更标签口径。标签一变，整个任务都变了。若确实需要调整，应把它视为一次新实验，而不是小修小补。比较稳的做法，是保留旧标签版本，明确新旧差异，再在同一套特征和样本切分下做对照。这样才能知道表现变化来自标签，而不是其他因素。

标签还要处理不可交易场景。比如标签窗口内出现停牌、涨跌停、成交受限或样本退市时，是否保留、如何标记、是否进入训练，都要提前定义。否则模型可能学到一种实际无法执行的收益结构。标签设计不是只算未来涨跌，它还要服务最终的交易动作。

如果模型输出最终用于排序，标签也要考虑排序稳定性；如果输出用于分类，标签阈值要有业务解释；如果输出用于回归，评价指标要能和组合构建衔接。标签越贴近最终使用方式，训练结果越有实际意义。

标签构造可以先从最小口径写清楚。比如日频选股任务里，若样本日期为 t，特征只能使用 t 日决策时点前可见的信息，标签可以定义为 t+1 到 t+k 的未来收益、未来相对排名或分层结果。这里的关键不是具体选择哪个 k，而是把窗口起点、终点、价格口径、停牌处理、成本是否扣除和无法交易样本处理写入标签版本。只要这些条件没有固定，后续训练分数就缺少比较基础。

如果最终使用方式是横截面排序，标签最好同时保留原始收益和排序标签。原始收益便于复盘价格口径，排序标签便于对接模型训练和分层评估。若直接只保留一个处理后的标签，后续发现异常时很难判断问题来自价格、样本过滤还是排序规则。

六、常见误区与防泄漏排查

防泄漏是 XGBoost 量化建模的底线。泄漏通常不会报错，它只会让离线表现变得异常好。常见泄漏包括使用未来财务数据、用全样本统计量做标准化、随机切分时序样本、标签窗口和特征窗口重叠、在验证集调完规则后继续把验证结果当独立评估。每一种泄漏都会让模型看起来更聪明，但这种聪明无法上线。

样本组织建议按时间滚动、按资产对齐。训练集、验证集和测试集要按时间顺序隔离，不建议对时序样本随机打散。对于截面任务，可以在同一交易日内保留多个资产样本，但不同时间段之间仍要保持清晰边界。这样做可以让验证更接近真实研究流程。

样本权重也要谨慎。某些项目会给近期样本更高权重，或给特定状态样本更高权重，这本身不是问题，但必须解释清楚。权重改变了模型学习重点，也会影响特征重要性。如果没有记录，后续模型波动会很难归因。

防泄漏最好做成训练前门禁，而不是靠人工记忆。门禁可以检查特征时间戳、标签窗口、切分边界、标准化范围和样本重复情况。门禁不一定能捕捉全部问题，但能拦住很多低级错误。只要门禁持续运行，团队对结果的信任度会明显提高。

样本组织还需要关注重复样本和相邻样本依赖。如果同一资产在连续日期上生成高度相似的样本，训练和验证之间虽然时间上分开，但仍可能存在很强的状态延续。对此不一定要删除样本，但评估时要知道这种依赖存在。对真实交易来说，样本不是彼此独立的，评估方法也不能完全按独立样本来理解。

训练前检查清单建议固定为六项。第一，所有特征列的可见时间不得晚于样本决策时间。第二，标签窗口必须完全落在决策时间之后。第三，训练、验证、测试按时间隔离，不能随机混洗。第四，截面标准化只能在当期样本池内完成，不能跨未来样本。第五，缺失值、极端值和不可交易样本要有标记。第六，样本池版本和标签版本必须写入实验记录。只要这六项有一项说不清，模型训练就不应该进入结果比较阶段。

七、工具落地与工程化治理

工程上，建议把输入设计拆成几个固定模块：样本池生成、标签生成、截面特征生成、时序特征生成、特征合并、质量检查和训练输出。每个模块都有输入输出，不要把所有逻辑写进一个训练脚本。模块化之后，问题定位会容易很多。

特征字典是工程落地的核心资产。字典里至少记录特征名、含义、来源字段、窗口、变换方式、缺失处理、适用范围、版本状态和负责人。特征被废弃时，也不要直接删除记录，而是标注退役原因。这样后续遇到类似问题时，团队可以知道哪些路已经试过，为什么不继续用。

版本记录要覆盖特征、标签、样本和参数。只记录模型参数没有意义，因为模型参数无法解释输入变化。一次完整实验应能回答：用了哪个样本池，哪个标签版本，哪些特征，怎样切分，怎样训练，输出保存在什么位置。没有这些上下文，实验结果无法复用。

工程落地还要建立特征退役机制。特征库不能只进不出。随着市场结构、交易约束和样本覆盖变化，一些曾经有用的特征会失去稳定性，一些特征会与新增特征高度重复。退役不是删除历史，而是停止默认使用，同时保留原因和证据。这样后续复盘时，团队能理解为什么某个特征不再进入主模型。

如果后续要上线，输入表还要和预测服务、组合构建、监控系统共享同一套字段契约。研究阶段叫一个名字，服务阶段换一个名字，监控阶段再换一个名字，会制造大量隐性错误。字段契约贯穿研究到生产，才能真正减少交接成本。

八、复盘与结语

XGBoost 输入设计的复盘，不应该只看模型分数。更重要的是看哪些特征贡献稳定，哪些特征只在个别阶段有效，哪些特征和标签口径存在冲突，哪些缺失或异常样本影响较大。复盘输出最好固定成模板，包含本轮变更、结果变化、异常发现、保留特征、退役特征和下一步计划。

这一讲的核心结论很简单：XGBoost 的强项是学习结构化输入中的非线性关系，但它不会替你判断输入是否真实、标签是否合理、样本是否泄漏。截面因子、时序特征和标签定义必须共同设计，才能得到稳定输入。把输入体系做好，后面的参数调优才不是盲调，特征解释才不是事后解释，模型上线才有可追溯基础。

如果只记住一句话，那就是：先把输入做成体系，再谈模型能力。输入体系稳定，调参才有比较意义；输入体系混乱，调参只是把混乱包装得更复杂。XGBoost 能做很多事情，但它最需要的，是一张口径清楚、时间干净、标签可信、特征可追踪的训练表。

九、风险揭示与免责声明