Manifold模型洞察：生产级可解释性与交互式可视化分析

1. 项目概述：Manifold 不是“调试器”，而是一套面向真实生产环境的模型洞察工作流

你有没有遇到过这样的场景：模型在离线评估时 AUC 0.92，上线后第二天监控告警说线上准确率掉到 0.73；或者业务方指着一张报表问：“为什么这个年龄段用户的拒贷率突然翻倍？模型是不是歧视了？”——而你翻遍特征重要性、SHAP 值、混淆矩阵，却找不到一个能直接指向“问题发生在哪里、为什么发生、谁该去改”的证据。这不是模型没训好，而是 缺乏一套把抽象指标翻译成具体业务语义的桥梁 。Uber 的 Manifold 就是为解决这个断层而生的。它不是传统意义的“debugger”（调试器），不抓 Python 异常或梯度爆炸；它是一套 以人为核心、以可视化为语言、以对比分析为方法论的模型洞察栈（Model Insight Stack） 。核心关键词是 Manifold、模型洞察、交互式可视化、模型对比、特征归因、生产级可解释性 。它专为数据科学家、ML 工程师和业务分析师设计，目标很实在：让一个没写过一行 PyTorch 的风控经理，也能在 5 分钟内拖拽出“近 7 天新客 vs 老客的模型预测分布差异”，并点击某个异常区间，立刻看到背后驱动该差异的 Top 3 特征及其原始取值范围。我第一次在内部 demo 上看到它时，第一反应不是“技术多炫”，而是“这下终于不用再花半天写 SQL + Pandas + Matplotlib 拼凑一份临时分析报告了”。它解决的不是“模型能不能跑”，而是“模型到底在怎么想、想得对不对、哪里想歪了”。如果你正被模型上线后的黑盒焦虑、跨团队沟通成本高、复现问题耗时长等问题困扰，Manifold 提供的不是理论框架，而是一套已经过 Uber 数百个核心推荐、定价、风控模型验证的实操路径。

2. 整体架构与设计哲学：为什么是“Manifold”而不是“Debugger”

2.1 名字背后的隐喻：流形（Manifold）即“高维现实的低维可理解切片”

Manifold 这个名字绝非随意选取。在数学中，流形（Manifold）指的是一种局部看起来像欧几里得空间（如平面、直线）的拓扑空间，比如地球表面是二维流形，虽然整体是球面，但站在北京天安门广场上，你感觉脚下就是一片平坦的二维平面。Uber 团队用这个词命名，其深意在于： 机器学习模型的决策空间是极高维、非线性的（比如一个含 1000 个稀疏特征的深度推荐模型，其输入空间维度可能高达百万级），人类根本无法直接理解。Manifold 的使命，就是在这个不可见的高维“流形”上，为你切出一个个可理解、可交互、可操作的二维或三维“切片”（Slice） 。这些切片不是随机的，而是围绕三个核心锚点构建的： 数据切片（Data Slice）、模型切片（Model Slice）、特征切片（Feature Slice） 。例如，当你选择“所有用户中收入 > 50k 且最近 30 天有 2 次以上 App 打开行为”的数据切片时，Manifold 并非简单地过滤出这部分样本，而是立即计算并渲染出：① 该切片上的模型预测分布直方图（vs 全量分布）；② 该切片上各特征对预测结果的 SHAP 归因强度排序；③ 该切片上模型置信度（如 softmax 输出的最大概率）的分布。这三个视图共同构成了一个关于“高收入活跃用户”这个业务概念的完整、低维、可理解的“切片”。这比单纯看全局 SHAP 值或单个样本的 LIME 解释，信息密度高出一个数量级。我后来在复现类似思路时深刻体会到，很多所谓“可解释性工具”失败，正是因为它们只提供“点”（单样本解释）或“面”（全局统计），而 Manifold 提供的是“体”（带上下文的动态切片）。

2.2 架构分层：从数据源到交互前端的四层解耦

Manifold 的开源实现（GitHub: uber/manifold）虽已停止维护，但其架构思想至今仍是行业标杆。它采用清晰的四层解耦设计，每一层都可独立替换或扩展，这正是它能支撑 Uber 内部异构技术栈的关键：

• 数据接入层（Data Ingestion Layer） ：这是最灵活的一层。它不强制要求数据必须来自特定数据库。官方示例支持 CSV、Pandas DataFrame、Spark DataFrame 三种输入。但实际在 Uber 生产环境中，它通过一个轻量级适配器（Adapter）对接内部的实时特征仓库（Feature Store）和离线数仓（Hive/Trino）。关键设计是： 它只读取“预测结果”和“原始特征值”，不触碰模型训练代码本身 。这意味着，无论你的模型是用 TensorFlow 训练的、XGBoost 训练的，还是用自研的 C++ 推理引擎加载的，只要能输出 prediction 和 feature_dict ，Manifold 就能工作。我见过最极端的案例是，一个团队用 Manifold 分析一个部署在 FPGA 上的超低延迟风控模型，他们只需在模型服务的 gRPC 响应中额外注入一个 debug_info 字段，包含预测值和关键特征快照，Manifold 就能无缝接入。这种“模型无关性”（Model-Agnostic）是它区别于大多数“集成式调试工具”的根本。

• 计算引擎层（Computation Engine） ：这一层负责所有重计算。核心是两个模块：① Slice Engine ：接收用户定义的切片规则（如 age > 30 AND city IN ['Beijing', 'Shanghai'] ），生成对应的布尔索引，并高效地在百万级样本上执行向量化过滤。它利用 NumPy/Pandas 的底层优化，避免 Python 循环。② Insight Engine ：这是真正的“大脑”。它预置了多种洞察算法：基于 KS 检验的分布漂移检测、基于决策树的切片内特征重要性重排序、基于聚类的预测结果分组分析。所有算法都设计为“懒计算”（Lazy Evaluation）：只有当用户在 UI 上点击某个切片、展开某个图表时，才触发对应计算，极大降低前端压力。我曾对比过，一个含 100 万样本、50 个特征的数据集，在 Manifold 中加载后初始内存占用仅 120MB，而同等数据在 Jupyter 中加载一个 Pandas DataFrame 就要 800MB+。这种资源效率，是它能在工程师笔记本上流畅运行的基础。

• 可视化服务层（Visualization Service） ：这是 Manifold 最惊艳的部分。它没有使用 D3.js 或 Plotly 这类通用库，而是基于一个高度定制化的 WebGL 渲染引擎（内部代号 “Vega-Lite for ML”）。其核心创新在于 “联动渲染”（Linked Rendering） ：当你在左侧的“特征分布图”中用鼠标框选一个年龄区间（如 25-35 岁），右侧的“预测分布图”和下方的“特征归因图”会 毫秒级同步高亮显示该区间内样本的对应数据点 。这种联动不是简单的事件监听，而是底层共享同一个 WebGL 缓冲区（Buffer），所有图表共用同一份顶点数据。这使得即使在 10 万点的散点图上做复杂筛选，帧率也能稳定在 60FPS。我试过在一台 2018 款 MacBook Pro 上，同时拖拽 5 个不同特征的滑块进行多维切片，UI 依然丝滑。这种性能，是它能承载“探索式分析”（Exploratory Analysis）体验的物理基础。

• 交互前端层（Interactive Frontend） ：这是一个纯静态的 React 应用，通过 REST API 与后端通信。它的 UI 设计遵循“零配置启动”原则：用户上传一个 CSV 文件（含 id , label , prediction , feature_1 , feature_2 , ...），点击“Launch”，页面就自动渲染出默认的全量数据洞察视图。所有高级功能（如自定义切片、模型对比）都通过右侧面板的“Add Slice”、“Compare Models”等按钮渐进式展开，新手不会被吓退，专家又能快速调用深度功能。这种“由浅入深”的交互逻辑，是我见过的最符合数据科学家工作流的设计。

2.3 与传统 ML Debugging 工具的本质区别

很多人初看 Manifold，会把它和 TensorBoard、Weights & Biases (W&B) 或 Captum 混淆。但它们解决的是完全不同的问题域：

这个表格揭示了一个残酷现实： 90% 的线上模型问题，既不是训练没训好（W&B 管），也不是单个样本解释不清（Captum 管），而是模型在某个未被充分测试的业务场景下，系统性地表现失常 。Manifold 填补的，正是这个巨大的、被长期忽视的“中间地带”。我曾帮一个电商客户排查“大促期间首页推荐转化率暴跌”问题。W&B 显示训练指标一切正常，Captum 解释单个商品没问题。最后用 Manifold 加载大促期间的线上日志，创建 is_promotion_day=True AND user_segment='new' 切片，瞬间发现：该切片下，模型对“价格敏感度”特征的归因权重暴涨 300%，而线上实际数据显示，新客对促销价格并不敏感，反而是“社交裂变系数”这个特征被严重低估。问题根源很快定位到：训练数据中“新客”样本极少，且几乎都来自非大促期，模型从未学过如何为大促新客打分。这个洞见，是任何训练监控或单样本解释工具都无法提供的。

3. 核心功能解析与实操要点：从零开始构建一次有效洞察

3.1 数据准备：不是“格式正确”，而是“语义完备”

Manifold 对数据格式的要求看似简单：一个 CSV 文件，列名包含 label （真实标签）、 prediction （模型预测值）、以及所有你想分析的原始特征（如 age , income , last_login_days_ago ）。但 真正决定分析成败的，是数据的“语义完备性” 。我见过太多团队栽在这个环节：

• 陷阱一：特征“脱敏”过度 。为了“安全”，把 city 特征编码成 city_id=12345 。Manifold 能画出 city_id 的分布，但你能看出 12345 对应的是北京还是拉萨吗？业务方看到这个数字，只会一脸茫然。 正确做法 ：保留原始可读值（ city='Beijing' ），或至少提供一个映射字典（ city_map.json ），并在 Manifold 启动时通过 --feature-map 参数加载。

• 陷阱二：忽略“时间戳”和“版本标识” 。Manifold 的强大之处在于对比分析，但对比需要基准。如果你的数据只有一张表，那只能做静态分析。 最佳实践 ：在 CSV 中加入 timestamp （ISO8601 格式）和 model_version （如 v2.1.0 ）两列。这样，你就能在 UI 中轻松创建切片 model_version='v2.0.0' AND timestamp > '2023-10-01' ，与 model_version='v2.1.0' AND timestamp > '2023-10-01' 进行对比，直接定位模型升级带来的影响。

• 陷阱三：预测值类型错配 。Manifold 默认将 prediction 列视为连续值（回归任务）或概率（二分类任务）。如果你的模型输出的是类别 ID（如 prediction=1 表示“正类”），Manifold 会错误地将其当作数值处理，导致分布图毫无意义。 解决方案 ：对于多分类，确保 prediction 列是概率向量（如 [0.1, 0.7, 0.2] ），或使用 --task-type classification 参数并指定 --positive-class 1 。

提示：Manifold 官方提供了一个 manifold-data-validator 脚本。运行 python -m manifold.validator --input data.csv ，它会自动检查：① 是否存在必需列；② label 和 prediction 的数据类型是否匹配（如都是 float）；③ 特征列是否有大量缺失值（>30% 会警告）；④ 时间戳格式是否合法。这个脚本应该成为你数据准备流程的强制关卡。

3.2 创建第一个“救命切片”：以“地域性能衰减”为例

假设你刚收到一条告警：“华东地区用户订单取消率在过去 24 小时内上升了 40%”。以下是我在 Uber 实战中总结的、用 Manifold 快速定位问题的标准化五步法：

1. 加载数据 ：启动 Manifold 服务（ manifold launch --data ./data/cancel_logs_24h.csv ），等待 Web UI 在 http://localhost:8080 启动。

2. 定义核心切片（The Anchor Slice） ：在左侧面板点击 + Add Slice 。在弹出的对话框中，输入切片名称 High_Cancel_Rate_Area ，然后在规则编辑器中输入：

   region == 'East_China' AND 
   prediction_cancel_prob > 0.5
   

   这里 region 是你的地域特征， prediction_cancel_prob 是模型输出的取消概率。点击 Create 。Manifold 会立即在主视图中高亮显示这个切片，并在右侧显示其统计摘要：样本数、平均取消概率、KS 检验 p-value（与全量分布对比）。

3. 执行“分布对比”（Distribution Comparison） ：这是 Manifold 的王牌功能。在切片列表中，找到刚创建的 High_Cancel_Rate_Area ，点击其右侧的 Compare 按钮。在弹出的窗口中，选择对比基准为 All Data 。Manifold 会并排渲染两张图：左边是全量数据的 prediction_cancel_prob 分布直方图，右边是华东高危切片的分布。 关键观察点 ：如果高危切片的分布整体右偏（集中在 0.6-0.9 区间），而全量分布峰值在 0.1-0.3，这说明模型在华东地区“系统性地”给出了过高的取消概率，问题很可能出在模型本身或华东特有特征上。

4. 深挖“特征归因”（Feature Attribution） ：在对比视图下方，切换到 Feature Attribution 标签页。这里会显示：对于 High_Cancel_Rate_Area 这个切片内的所有样本，各个特征对 prediction_cancel_prob 的平均 SHAP 值（绝对值）排序。 重点关注 ：排在前三位的特征。在我的一个真实案例中，第一位是 user_app_version （用户 App 版本），第二位是 last_order_time_hours_ago （上次下单距今小时数）。这立刻将怀疑焦点从“模型逻辑”转向了“数据管道”——我们发现，一个新上线的 App v5.0 版本，其埋点逻辑变更，导致 last_order_time_hours_ago 这个特征在华东地区被错误地填充为一个极大值（如 999999），而模型恰好把这个异常值解读为“极度不活跃用户”，从而给出高取消概率。

5. 导出“证据包”（Evidence Package） ：定位到根因后，点击右上角的 Export 按钮。Manifold 会生成一个 ZIP 包，内含：① 当前切片的详细统计 PDF 报告；② 关键图表的 PNG 高清截图；③ 一个 slice_samples.csv 文件，包含该切片内所有样本的 id , label , prediction , 以及 top3 归因特征的原始值。这个 ZIP 包就是你向工程团队提 Bug 的“铁证”，无需任何额外解释，对方打开 slice_samples.csv ，一眼就能看到 user_app_version=5.0 和 last_order_time_hours_ago=999999 的强关联。

注意：Manifold 的切片规则支持完整的 Python 表达式语法，包括 in , not in , str.contains() , pd.isna() 等。但 强烈建议避免使用过于复杂的嵌套逻辑 。一个切片规则最好只包含 2-3 个条件。过于复杂的规则（如 ((age > 25 and income < 50000) or (city in ['Shenzhen', 'Hangzhou'])) and app_version.startswith('4.') ）会让分析变得难以复现和解释。记住，Manifold 的哲学是“小切片，深洞察”，而不是“大切片，粗覆盖”。

3.3 模型对比：不是“A/B Test”，而是“决策逻辑审计”

Manifold 的 Compare Models 功能，常被误解为简单的 A/B 测试看板。实际上，它是一个强大的“模型决策逻辑审计工具”。假设你有两个模型版本： v1.0 （旧版，基于历史订单统计）和 v2.0 （新版，加入了实时用户行为图神经网络）。你想知道，新版模型的“智能”究竟体现在哪里？

标准操作流程如下：

1. 准备双模型数据 ：确保你的 CSV 文件中，有 model_v1_prediction 和 model_v2_prediction 两列，以及一个 model_version 列（值为 'v1.0' 或 'v2.0' ）。

2. 创建“决策分歧切片”（Decision Disagreement Slice） ：这是最关键的一步。在 + Add Slice 中，创建一个规则：

   model_version == 'v1.0' AND 
   abs(model_v1_prediction - model_v2_prediction) > 0.3
   

   这个切片捕获了所有“两个模型意见严重不合”的样本。Manifold 会立即告诉你，这类样本占全量的 8.2%。

3. 分析分歧样本的“共性画像” ：在 High_Disagreement 切片下，切换到 Feature Attribution 视图。你会看到，对于这些分歧样本， model_v1 最看重的特征可能是 avg_order_value_30d （30天平均订单额），而 model_v2 最看重的却是 graph_centrality_score （图中心性分数）。这直接揭示了两个模型的决策范式差异：老模型依赖历史消费金额，新模型则更关注用户在社交关系网中的位置。

4. 执行“一致性审计”（Consistency Audit） ：在 Compare Models 视图中，选择 Consistency 选项卡。Manifold 会计算一个“一致性分数”：对于每个特征，它衡量 v1.0 和 v2.0 在该特征上的归因方向（正向/负向）和强度是否一致。结果显示， graph_centrality_score 的一致性分数仅为 0.12（满分 1.0），而 avg_order_value_30d 的一致性分数高达 0.95。这说明，新模型引入的图特征，是导致决策分歧的绝对主力。业务方据此可以判断：如果 graph_centrality_score 的数据质量不稳定（如新用户图谱稀疏），那么在该特征上赋予过高权重，反而会损害模型鲁棒性。

这个分析过程，远超出了传统 A/B Test 只看“最终指标提升多少”的层面，它深入到了模型“思考方式”的对比，这才是技术负责人真正需要的决策依据。

4. 实操过程与核心环节实现：手把手搭建本地分析环境

4.1 环境搭建：避开 Python 版本与依赖地狱

Manifold 的官方 GitHub 仓库（uber/manifold）最后一次更新是 2021 年，这意味着它默认依赖的 tensorflow==1.15.0 和 pandas==0.24.2 在现代 Python 环境中极易冲突。我经过数十次尝试，总结出最稳妥的本地部署方案：

1. 创建纯净虚拟环境 ：

   # 强烈推荐使用 conda，比 venv 更擅长处理科学计算依赖
   conda create -n manifold-env python=3.7
   conda activate manifold-env
   

2. 安装核心依赖（按此精确顺序） ：

   # 先装最底层、最易冲突的
   pip install numpy==1.16.6
   pip install pandas==0.24.2
   # 再装 Manifold 的核心计算引擎
   pip install scikit-learn==0.20.3
   # 最后装 Manifold 本身（注意：必须从源码安装，PyPI 上的 wheel 已过期）
   git clone https://github.com/uber/manifold.git
   cd manifold
   pip install -e .
   # 安装前端依赖（需要 Node.js >= 12）
   cd manifold/frontend
   npm install
   npm run build
   cd ../..
   

3. 验证安装 ：

   # 运行内置的示例数据
   manifold launch --data manifold/examples/data/iris.csv --port 8080
   

   如果浏览器成功打开 http://localhost:8080 并显示鸢尾花数据的交互式分析界面，说明环境搭建成功。

注意：如果你的机器没有 GPU，或者不想安装 TensorFlow，Manifold 提供了 --no-tf 参数。它会自动回退到纯 NumPy 实现的 SHAP 计算（速度稍慢，但足够分析百万级样本）。命令变为： manifold launch --data data.csv --no-tf 。

4.2 从 CSV 到洞察：一个完整实操案例

让我们用一个真实的风控场景来走一遍全流程。假设你有一份 credit_risk_data.csv ，包含以下列：

• user_id : 用户唯一 ID
• label : 1=逾期，0=正常
• prediction : 模型预测的逾期概率（0.0-1.0）
• age : 年龄
• income : 年收入（万元）
• debt_ratio : 负债收入比（小数）
• credit_history_months : 信用历史月数
• is_new_user : 是否为新用户（True/False）

步骤一：快速诊断“新用户逾期率异常”

1. 启动 Manifold： manifold launch --data credit_risk_data.csv --port 8080
2. 创建切片： + Add Slice → 名称 New_User_High_Risk → 规则 is_new_user == True AND prediction > 0.4
3. 查看统计：Manifold 显示该切片有 12,450 个样本，平均预测概率为 0.62，KS p-value = 1.2e-15（极显著差异）。
4. 分布对比：与 All Data 对比，发现 New_User_High_Risk 切片的预测分布峰值在 0.55-0.75，而全量分布峰值在 0.15-0.25。模型确实在“高估”新用户风险。
5. 特征归因：在 New_User_High_Risk 切片下， Feature Attribution 显示 Top3 特征为：① credit_history_months （归因值 -0.41）；② income （归因值 -0.28）；③ age （归因值 -0.19）。负号表示：这些特征值越小，预测逾期概率越高。这符合常识：新用户信用历史短、收入低、年龄小，风险高。

步骤二：深挖“信用历史短”的归因逻辑

仅仅知道 credit_history_months 重要还不够。我们需要知道，模型是如何“解读”这个特征的。在 New_User_High_Risk 切片的 Feature Attribution 视图中，点击 credit_history_months 这一行右侧的 View Detail 按钮。Manifold 会弹出一个新窗口，展示：

• 该切片内 credit_history_months 的分布直方图（X轴：月数，Y轴：样本数）。
• 一条红色曲线： credit_history_months 与 prediction 的平滑拟合关系（Loess 曲线）。
• 一条蓝色虚线：全量数据中 credit_history_months 与 prediction 的关系。

关键发现 ：红色曲线显示，在 credit_history_months < 6 的区间， prediction 随着月数减少而急剧上升（从 0.3 升到 0.8）；而蓝色虚线在该区间则平缓得多（从 0.25 升到 0.35）。这说明， 模型对新用户的“信用历史短”这一信号，赋予了远超平均水平的惩罚权重 。业务方据此可以判断：当前模型可能过度保守，对有潜力的新用户（如高学历、高收入的年轻白领）造成了误杀。后续优化方向就很清晰了：在训练数据中，为高质量新用户增加样本权重，或在特征工程中，为 credit_history_months 添加一个“新用户质量分”交叉特征。

步骤三：生成可交付报告

点击 Export → Generate Report 。Manifold 会生成一个 report_20231015.zip 。解压后：

• summary.pdf ：一页纸的 executive summary，包含切片定义、关键统计、Top3 归因特征及业务解读。
• charts/ 目录：所有图表的高清 PNG。
• samples/ 目录： new_user_high_risk_samples.csv ，包含 1000 个随机抽样的高风险新用户 ID 和他们的特征快照。

这份报告，可以直接发给风控策略团队，作为模型迭代需求的正式输入。整个过程，从启动到生成报告，耗时不到 8 分钟。

5. 常见问题与排查技巧实录：那些官方文档不会写的坑

5.1 性能瓶颈：当百万级数据“卡住”了 UI

现象 ：加载一个含 200 万样本、80 个特征的 CSV 后，UI 响应极其缓慢，拖拽滑块时图表刷新延迟超过 2 秒。

根因分析与解决 ：

• 根因一：前端渲染压力过大 。Manifold 的 WebGL 渲染器在绘制 200 万点时，显存和 CPU 都会吃紧。
  • 解决 ：启用前端采样（Frontend Sampling）。在启动命令中添加 --max-points 50000 。Manifold 会在前端自动对数据进行均匀采样，只渲染最多 5 万个点。对于探索性分析，5 万个点的分布形态与 200 万点几乎一致，但性能提升 5 倍以上。 manifold launch --data big_data.csv --max-points 50000
• 根因二：后端计算阻塞 。当用户快速连续创建多个复杂切片时， Insight Engine 的计算队列会堆积。
  • 解决 ：调整计算并发数。Manifold 默认使用单线程计算。在 manifold/config.py 中，将 MAX_WORKERS = 4 （根据你的 CPU 核心数调整）。重启服务即可。

实测心得：在一台 16GB 内存、4 核 CPU 的笔记本上，通过 --max-points 50000 和 MAX_WORKERS=4 的组合，Manifold 可以流畅分析 500 万样本的数据集。关键在于， 不要试图让 Manifold 做“全量精确计算”，而要接受“亚秒级、高保真探索” 。这正是它设计的初衷。

5.2 特征归因“失真”：为什么 SHAP 值看起来不合理？

现象 ：在一个切片中， Feature Attribution 显示 age 的归因值为 +0.5（正向），但业务常识是“年龄越大，信用风险越低”，应该是负向。

排查与解决 ：

1. 检查特征缩放（Scaling） ：Manifold 默认会对所有数值特征进行 Z-score 标准化（均值为 0，标准差为 1）后再计算 SHAP。如果 age 的原始分布是 [18, 80]，标准化后，一个 80 岁的用户 age_zscore ≈ +2.5 ，而一个 18 岁的用户 age_zscore ≈ -2.5 。如果模型逻辑是“ age_zscore 越大，风险越低”，那么 SHAP 值就会是负的。但 Manifold 的归因图显示的是 age_zscore 的贡献，而非原始 age 。 解决 ：在 Feature Attribution 视图中，点击 age 行的 View Detail ，查看 age_zscore 与 prediction 的关系曲线。如果曲线是下降的，说明归因逻辑正确，只是你忘了看的是标准化后的特征。
2. 检查切片偏差（Slice Bias） ： age 的归因值是该切片内所有样本的平均 SHAP。如果切片中恰好包含了大量高龄但高风险的特殊人群（如退休人员无稳定收入），那么平均归因就可能为正。 解决 ：在 View Detail 中，查看 age 的分布直方图，确认是否存在极端值或长尾。如果有，尝试创建一个更精细的切片，如 age > 65 AND income < 10 ，再看归因。

5.3 模型对比失效：两个模型的预测值“对不上”

现象 ：在 Compare Models 视图中， v1.0 和 v2.0 的预测分布图看起来完全不同，但你知道它们在相同数据上跑出来的结果应该很接近。

根因与修复 ：

• 根因：预测值的标度（Scale）不一致 。 v1.0 输出的是原始 logits（如 [-5.2, 3.8]），而 v2.0 输出的是经过 sigmoid 转换的概率（如 [0.005, 0.978]）。Manifold 默认将所有 prediction 列都当作概率处理，导致 v1.0 的 logits 被错误地解释。
  • 修复 ：在启动时，使用 --prediction-cols 参数明确指定每列的含义：

    manifold launch \
      --data dual_model_data.csv \
      --prediction-cols "v1_logits:v1.0_prediction,sigmoid" \
      --prediction-cols "v2_prob:v2.0_prediction,identity"
    

    这告诉 Manifold：对 v1.0_prediction 列，先应用 sigmoid 函数（ sigmoid ），再进行分析；对 v2.0_prediction 列，直接使用原始值（ identity ）。

5.4 常见问题速查表

最后分享一个小技巧：Manifold 的 UI 支持键盘快捷键。在任意图表上按 C 键，可以快速复制当前图表的 PNG 到剪贴板；按 S 键，