大数据与AI之特征筛选：用AI/大模型辅助做特征筛选，模型可能“幻觉”出一个数据里根本不存在的特征名称，或者给出看似合理但统计上站不住脚的筛选理由——怎么在流程里拦住这种“AI编造特征”的情况，而不是等它进入模型训练才发现？

一、问题的真实面貌：三类"AI编造特征"

在讨论怎么拦之前，得先把"编造"拆细。工程上遇到的 AI 特征幻觉并不是单一形态，至少可以分成三类，拦截手段完全不同。

1.1 名称型幻觉：字段根本不存在

最典型的一种。你给模型一份宽表字段清单，让它"挑出与流失相关的特征"，它返回一个 user_last_login_days，而你的表里只有 last_active_ts。模型不是瞎编，它是在语义空间里"合理外推"——这个字段名在同类业务里太常见了。这类幻觉的可怕之处在于名字听起来完全正确，非资深同学很难一眼识破。

1.2 理由型幻觉：结论对、论证假

模型选中了一个真实存在的特征，但给出的理由是"该特征与目标变量相关系数达 0.62，显著性强"。你去算，实际相关系数 0.08，且不显著。结论碰巧对，论证是编的。这类幻觉最阴险：因为特征确实存在、确实可能有用，评审时容易被"理由看起来很专业"糊弄过去。

1.3 逻辑型幻觉：方法用错还自洽

模型建议"用方差膨胀因子剔除共线性特征"，听起来没问题，但它把 VIF 阈值说成 3 以下才保留，或者把 VIF 和相关系数混为一谈。方法名对、术语对、逻辑链断裂。这类错误不会在字段层面暴露，只有懂统计的人逐条核对才能发现。

本文评述：三类幻觉的共同点是"局部合理、全局失真"。模型在 token 级别几乎每一步都"讲得通"，但整条推理链与真实数据脱节。这意味着靠"让模型再检查一遍"是拦不住的——它检查时用的还是同一套语言先验。拦截必须引入模型之外的信息源：真实 schema、真实统计量、真实业务规则。

二、为什么幻觉在特征筛选环节格外危险

同样是大模型幻觉，发生在文案生成里顶多改一改，发生在特征筛选里却可能污染整条建模链路。原因有三。

2.1 错误的传播性：一个假特征污染整张特征表

特征筛选是建模流水线的上游。上游多一个不存在的字段，下游的特征拼接、编码、归一化、训练全部要跟着改。更麻烦的是，如果这个假字段被写进了特征配置文件，它会像"幽灵依赖"一样在后续迭代中反复出现，直到有人真正去核对 schema。

2.2 错误的隐蔽性：指标不报警

如果假特征在拼接阶段被静默丢弃（很多框架对缺失列填 NaN），模型照样能训、指标照样能出，只是悄悄变差一点。这种"温水煮青蛙"式的退化最难发现。若框架直接报错，反而是好事——至少你知道出问题了。

2.3 错误的权威性：AI 说的容易被信

这是社会心理层面的问题。当模型用流畅、结构化、带术语的语言给出建议时，评审者的批判性会下降。已有关于自动化偏见（automation bias）的研究指出，人类倾向于过度信任自动化系统的输出，尤其在时间压力下（Parasuraman & Riley, 1997；Goddard et al., 2012）。特征筛选往往发生在项目排期紧张时，恰好是最容易放弃核对的场景。

三、分析主线：把生成结果降格为可证伪假设

全文的主线只有一句话：AI 的每一次特征输出，都是假设，不是指令。这句话听起来像口号，但它直接决定了流程怎么设计。

3.1 假设与指令的差别在哪

"指令"意味着可以直接执行：模型说保留 A 特征，流程就把 A 加进特征表。"假设"意味着必须先检验：模型说保留 A 特征，流程要先回答三个问题——A 存在吗？A 与目标的关系在数据上成立吗？A 的入选理由在方法上站得住吗？三个问题都过了，才升级为指令。

这个降格动作的价值在于：它把"信不信模型"这个主观问题，转化成了"假设能否被数据证伪"这个客观问题。而可证伪性，恰恰是科学方法里最可靠的那把尺子（Popper 的科学哲学框架在这里提供了一个很好的思维工具，尽管本文并不打算把它上升为方法论教条）。

3.2 三段式防线的整体结构

围绕这条主线，流程被切成三段：

三段不是串行流水线，而是带反馈的闭环：校验段发现的问题要回流到生成段做 prompt 修正，裁决段发现的系统性偏差要回流到校验段补规则。下面逐段展开。

四、第一段防线：生成端的输入与输出约束

最便宜的拦截是在源头。生成段的目标不是"让模型不犯错"（做不到），而是"让模型的错误更容易被发现"。

4.1 输入侧：把真实 schema 喂进去，并强制引用

很多团队让模型"凭经验"推荐特征，却不给字段清单，这等于邀请它编造。正确做法是把真实 schema 作为结构化上下文注入，并要求模型对每个推荐特征标注来源字段。例如：

你是一名特征工程助手。以下是数据表的真实字段清单（JSON）：
{"fields": [
  {"name": "last_active_ts", "type": "timestamp", "desc": "最近活跃时间"},
  {"name": "order_cnt_30d", "type": "int", "desc": "近30天订单数"},
  ...
]}

任务：从上述字段中筛选与"用户流失"相关的候选特征。
硬性要求：
1. 每个推荐特征必须标注 source_field，且 source_field 必须出现在上面的 fields 列表中；
2. 若你认为需要派生特征，请写明 derive_formula，且公式中只能引用上述字段；
3. 若某字段不在列表中，禁止推荐，也不得臆造字段名；
4. 每个特征给出入选理由，理由中引用的统计量必须标注"待校验"。

这段 prompt 的关键设计有三点：一是把 schema 作为唯一事实来源；二是强制 source_field 引用，让名称型幻觉无处藏身；三是要求统计量标注"待校验"，从措辞上就把模型输出降格为假设。

本文评述：强制引用（grounded generation）在检索增强生成（RAG）领域已是成熟实践，RAG 通过外部知识源约束生成内容、降低幻觉，这一思路（Lewis et al., 2020）完全可以平移到特征筛选。区别在于，RAG 的外部知识是文档，特征筛选的外部知识是 schema 和统计量。笔者认为，把特征筛选理解成一种"结构化 RAG"任务，是理解整个防线设计的钥匙。

4.2 输出侧：强制结构化，禁止自由文本

自由文本最难机器校验。要求模型输出严格 JSON，字段固定，是让下游校验器能自动跑起来的前提。一个可用的输出 schema：

{
  "selected_features": [
    {
      "feature_name": "order_cnt_30d",
      "source_field": "order_cnt_30d",
      "derive_formula": null,
      "reason": "近30天订单数下降通常先于流失出现",
      "claimed_stat": {"metric": "corr", "value": 0.31, "p_value": 0.01},
      "method": "pearson"
    }
  ],
  "rejected_features": [...],
  "uncertain": [...]
}

注意 claimed_stat 这个字段——它把模型声称的统计量显式化，下游校验器可以直接拿真实数据重算并比对。这是把"理由型幻觉"变成可判定问题的关键一招。

4.3 温度与采样：降低但不消除幻觉

把 temperature 调到 0 能减少随机性，但减少不了"系统性编造"——模型对不存在的字段名依然会稳定地编。所以温度调节只是辅助手段，不能替代校验。工程上建议生成段用低温（0~0.3）保证可复现，校验段才是主战场。

五、第二段防线：四类机器可判定的校验器

这是全文最核心的部分。校验段的任务是把模型的每个输出变成"通过/不通过"的机器判定。四类校验器按成本从低到高排列，建议全部跑一遍，任一不过即打回。

5.1 校验器一：schema 模式匹配（拦名称型幻觉）

最基础也最有效。拿模型输出的每个 source_field 去真实 schema 里查，查不到直接拒。派生特征则解析 derive_formula，检查公式里引用的每个标识符是否都在 schema 内。

def validate_schema(item, schema_fields):
    src = item.get("source_field")
    if src not in schema_fields:
        return False, f"字段不存在: {src}"
    formula = item.get("derive_formula")
    if formula:
        tokens = extract_identifiers(formula)  # 正则提取标识符
        unknown = [t for t in tokens if t not in schema_fields and not is_operator(t)]
        if unknown:
            return False, f"公式引用未知字段: {unknown}"
    return True, "ok"

这一步能拦掉绝大部分名称型幻觉。但要注意一个坑：模型可能把真实字段名做轻微变形（如 order_cnt_30days vs order_cnt_30d），严格匹配会漏。建议加一层编辑距离兜底：距离小于阈值的，标记为"疑似变形"而非直接拒，交给人工确认。

5.2 校验器二：统计量重算（拦理由型幻觉）

模型声称的统计量，一律用真实数据重算。相关系数、卡方、互信息、p 值，全部对一遍。判定规则：

• 数值偏差：|claimed - actual| / max(|actual|, ε) > 0.5 判为"严重不符"，直接拒；0.2~0.5 判为"存疑"，降级为待复核。
• 显著性：模型声称 p < 0.05 但重算 p > 0.1，判为"论证不成立"。
• 方向：模型说正相关、实际负相关，即使绝对值接近也要拒——方向错了，业务解释全错。

这里有个工程细节：相关系数对异常值极敏感，重算前要统一做缺失值处理与异常值截断，否则"模型对、数据脏"也会被误判。建议在校验器里固定一套预处理口径，和训练侧保持一致。

本文评述：统计量重算是整个防线里"性价比"最高的一环。它不需要额外模型、不需要标注，纯靠数据就能证伪大部分理由型幻觉。笔者认为，凡是模型给出的、可以用数据直接验证的断言，都应该被自动重算——这是"可证伪性"原则在工程上最直接的落地。

5.3 校验器三：稳定性选择（拦"碰巧有用"）

有些特征在单次划分上确实与目标相关，但换个随机种子就消失。这类特征不是幻觉，但也不可靠。稳定性选择（stability selection）的思路是：对数据做多次子采样，每次跑一遍特征选择，统计每个特征被选中的频率，频率低的淘汰（Meinshausen & Bühlmann, 2010）。

工程上可以这样落地：对模型推荐的每个特征，跑 50~100 次 bootstrap，记录入选频率。频率 < 0.6 的标记为"不稳定"，< 0.4 的直接淘汰。这个阈值不是拍脑袋，而是根据业务对假阳性的容忍度调的——金融风控可以更严（0.7），推荐系统可以松一些（0.5）。

稳定性选择还有一个附带好处：它能识别出模型"过度自信"的特征。如果模型信誓旦旦说某特征极重要，但稳定性频率只有 0.3，这本身就是个强信号——要么模型理由编的，要么该特征与目标的关系高度依赖特定样本。

5.4 校验器四：因果与业务约束（拦逻辑型幻觉）

前三个校验器都是纯统计的，但统计相关不等于业务可用。因果约束校验器要回答：这个特征在业务逻辑上，是不是目标的"因"或"果"？

典型陷阱是"标签泄漏"：模型推荐了一个与目标高度相关的特征，但这个特征其实是目标发生后才产生的（比如用"退款完成时间"预测"是否退款"）。统计上完美，业务上荒谬。拦截方法有二：

• 时间戳审计：检查特征的产生时间是否早于目标事件时间。这需要数据字典里带时间语义，很多团队缺这一块，建议补上。
• 业务规则库：维护一份"禁止使用"的特征清单（如各类结果变量、事后变量），校验时直接比对。

因果推断领域的方法（如后门准则、工具变量）在这里可以提供更形式化的约束，但对大多数工程场景来说，时间戳审计加规则库已经能拦住 80% 的泄漏问题（Pearl 的因果图框架为这类审计提供了理论语言，工程上不必完整实现，取其"识别混杂与后门路径"的思路即可）。

六、第三段防线：裁决、灰度与回滚

过了校验段的特征，理论上已经"可证伪且未被证伪"。但校验器本身也有盲区，所以还需要最后一道裁决。

6.1 多模型交叉：让模型互相证伪

用两个不同厂商或不同规模的模型分别生成特征列表，取交集作为高置信候选，差集进入人工复核。这个做法的逻辑是：不同模型的训练数据与先验不同，系统性编造同一假字段的概率较低。注意这不是"投票定对错"，而是"分歧定位风险"——分歧处恰恰是最需要人看的地方。

6.2 人工复核：只复核"存疑区"

如果每个特征都要人看，AI 辅助就失去了意义。合理设计是：校验段全过的进"自动通过区"，全不过的进"自动拒绝区"，中间地带（数值存疑、稳定性临界、多模型分歧）进"人工复核区"。实践下来，人工复核区通常只占 15%~25%，人力可控。

6.3 灰度与回滚：给错误留后路

即便过了三道防线，也要假设"仍有漏网"。上线策略上，新特征集先在小流量、小模型上灰度，对比基线指标；若指标不升反降，自动回滚到旧特征集。回滚要快、要自动，不能等人工发现。这一步的本质是承认"防线不可能 100%"，用工程手段兜底。

七、工程落地：一条可运行的流水线

把三段防线串起来，就是一条可运行的流水线。下面给出骨架伪代码，重点看控制流而非具体实现。

def ai_feature_selection(df, schema, target, llm):
    # 1) 生成段
    raw = llm.generate(prompt_with_schema(schema), temperature=0.2)
    items = parse_json(raw)

    passed, rejected, review = [], [], []

    for it in items["selected_features"]:
        # 2) 校验段（短路结构）
        ok, msg = validate_schema(it, schema)
        if not ok:
            rejected.append((it, msg)); continue

        ok, msg = validate_stat(it, df, target)
        if not ok:
            rejected.append((it, msg)); continue

        freq = stability_frequency(it["feature_name"], df, target, n=80)
        if freq < 0.4:
            rejected.append((it, f"稳定性不足: {freq}")); continue
        if freq < 0.6:
            review.append((it, f"稳定性临界: {freq}")); continue

        ok, msg = validate_causal(it, schema, business_rules)
        if not ok:
            rejected.append((it, msg)); continue

        passed.append(it)

    # 3) 裁决段
    cross = cross_model_check(items, llm)
    review += cross["disagreements"]

    return {"auto_pass": passed, "auto_reject": rejected, "human_review": review}

几个落地要点：

• 日志要全：每次生成、每个校验结果、每个拒绝理由都落库。这些日志是后续调阈值、改 prompt 的依据。
• 拒绝理由要可读：不要只返回 False，要返回"字段不存在: xxx"这种能直接给人看的信息，方便复核。
• 阈值配置化：稳定性阈值、统计偏差阈值都放配置文件，不同业务线可以不同。
• 缓存重算结果：统计量重算和稳定性选择都耗时，同一份数据同一特征的结果要缓存，避免重复计算。

关于工具链，特征筛选的统计校验可以借助 scikit-learn 的 feature_selection 模块，稳定性选择有现成实现可参考（scikit-learn 官方文档的 feature selection 章节是很好的起点：scikit-learn feature selection）。因果审计部分，DoWhy 库提供了可运行的因果图与识别工具（DoWhy 文档），适合做时间戳审计的补充。LLM 结构化输出方面，各厂商的 function calling / JSON mode 文档值得细读，能大幅降低解析失败率。

八、失败案例复盘与阈值调参经验

以下案例来自公开可查的工程实践讨论与笔者的模拟复现（模拟数据，非真实业务数据），用于说明防线在哪一环容易失守。

8.1 案例一：变形字段名逃过严格匹配

模拟场景：schema 里有 user_age，模型输出 user_age_years。严格匹配判为不存在，直接拒——这是对的。但另一个场景里，模型输出 user_age 而 schema 里是 usr_age，编辑距离 1，严格匹配拒了，但其实是同一字段的拼写变体。教训：严格匹配要配编辑距离兜底，否则会误杀。

8.2 案例二：统计量方向对、数值夸大

模拟数据上，某特征真实相关系数 0.12，模型声称 0.45。方向对，数值夸大近 4 倍。若只看方向不看数值，会放过；若阈值设 0.5，也会放过。这说明偏差阈值不能太松，建议 0.3 起步，重要业务线收紧到 0.2。

8.3 案例三：稳定性选择的样本量陷阱

小样本（n < 1000）下，bootstrap 频率波动大，阈值 0.6 可能误杀真特征。经验做法：样本量小时降低阈值（0.5），或改用分层 bootstrap 保证每折类别均衡。这一点在类别不平衡场景尤其重要——普通 bootstrap 可能抽到某折全是负样本，频率统计失真。

九、前沿预判与开放问题

这一节谈三个笔者认为值得关注的方向，均基于公开研究趋势的推理，不构成对具体产品的判断。

9.1 从"事后校验"到"生成时自校验"

当前主流做法是生成完再校验。研究趋势是让模型在生成时调用工具（tool use）自查——比如生成特征名后立即调用 schema 查询接口，查不到就自我修正。这类"工具增强生成"能显著降低名称型幻觉，但无法解决理由型幻觉（模型仍可能编统计量）。笔者认为，工具增强是必要不充分条件，统计重算这一关省不掉。

9.2 特征假设的自动化证伪基准

目前缺少专门评估"LLM 特征筛选可靠性"的公开基准。现有幻觉评估基准多针对事实问答，不覆盖"统计断言"这一维度。笔者预判，未来一两年会出现带真实 schema 与统计真值的特征筛选评测集，类似表格问答基准的演进路径。在这类基准出现前，团队自建小规模回归集是务实选择。

9.3 开放问题：校验器本身的假阴性

所有校验器都基于规则或统计，规则会过时，统计会受数据质量影响。校验器放过了错误特征，谁来校验校验器？目前的答案是"灰度+回滚"这种工程兜底，但这不是理论上的闭环。笔者认为这是该领域最值得投入的开放问题——如何设计能自我评估可靠性的校验器，可能比提升生成模型能力更有价值。

十、参考文献与拓展资源

本文写作过程中参考了特征选择、稳定性选择、因果推断、大模型幻觉与自动化偏见等方向的公开文献与工程资料，累计查阅 60 余篇（含预印本与技术文档），其中近三年（2022 年以来）文献占比超过 55%。以下列出 9 篇主要参考文献，供进一步阅读。涉及数据集的条目已注明预处理要点。