解锁预测性洞察：Salesforce 数据工程师的 Einstein Discovery 指南

背景与应用场景

作为一名 Salesforce 数据工程师，我的日常工作核心是构建、维护和优化数据管道，确保业务团队能够从海量数据中获取清洁、可靠且可操作的信息。然而，传统的数据分析，如报表和仪表板，主要关注“发生了什么”，属于描述性分析。业务的真正价值增长点在于预测“将要发生什么”，并指导“如何促成最佳结果”，这正是预测性和指示性分析的范畴。这便是 Salesforce Einstein Discovery 的用武之地。

Einstein Discovery 是 Salesforce 平台内嵌的增强分析 (Augmented Analytics) 工具。它利用机器学习 (Machine Learning) 和人工智能 (AI) 自动分析数据，发现隐藏的模式和洞察，并构建预测模型。对于数据工程师而言，它不仅仅是一个黑盒工具，更是一个强大的引擎，可以将我们精心准备的数据转化为驱动业务决策的智能动力。

典型的应用场景包括：

最大化销售机会赢单率： 分析历史销售数据，预测哪些机会最有可能成交，并给出提升赢率的具体建议（例如，增加某个关键产品的折扣、引入技术专家等）。
降低客户流失率： 通过分析客户行为、服务案例和购买历史，预测哪些客户有流失风险，以便服务团队能提前介入，实施挽留措施。
优化市场营销活动效果： 预测哪些潜在客户最有可能响应某个营销活动，从而帮助市场团队更精准地分配预算，提升转化率。
供应链需求预测： 分析历史销售和库存数据，预测未来产品需求，优化库存管理，避免缺货或积压。

从数据工程的角度看，Einstein Discovery 将数据准备、模型训练、部署和集成的整个生命周期无缝地整合在 Salesforce 平台之上，极大地简化了将预测智能嵌入业务流程的复杂性。

原理说明

要充分利用 Einstein Discovery，我们需要理解其工作流程和核心概念。这个过程可以被看作一个从原始数据到可执行洞察的数据价值链。

1. 数据准备 (Data Preparation)

一切始于数据。Einstein Discovery 的“燃料”是 CRM Analytics（曾用名 Tableau CRM / Einstein Analytics）中的数据集 (Dataset)。作为数据工程师，这是我们的主战场。我们需要：

数据集成： 使用 CRM Analytics 的数据连接器，从 Salesforce 内部对象（如 Opportunity、Account）或外部系统（如 Snowflake、AWS S3、本地数据库）抽取数据。
数据转换： 通过 Data Prep Recipe（数据准备配方）对数据进行清洗、转换、聚合和特征工程。这包括处理缺失值、标准化字段、创建计算字段（例如，计算客户年龄、合同周期等），将多个数据源连接 (Join) 或联合 (Union) 成一个扁平化的分析数据集。
数据质量： 保证数据集的质量至关重要。“Garbage In, Garbage Out” 在机器学习中是铁律。我们需要确保数据没有偏差 (Bias)，并且能够真实反映业务过程。

2. 故事创建 (Story Creation)

当数据集准备就绪后，我们就可以创建一个“故事” (Story)。一个故事是 Einstein Discovery 执行自动化分析和模型构建过程的容器。在创建故事时，我们需要定义一个目标 (Goal)，例如，“最大化赢单率 (IsWon)”或“最小化客户流失 (Churn)”。

随后，Einstein Discovery 会：

自动化特征选择： 分析数据集中的所有字段，自动识别哪些字段与我们的目标关联性最强。
统计分析： 对数据进行深入的统计分析，生成三种类型的洞察 (Insights)：
- 描述性洞察 (Descriptive Insights)： 解释“发生了什么”。例如，“在所有成交的机会中，来自‘科技行业’的占比最高”。
- 诊断性洞察 (Diagnostic Insights)： 解释“为什么会发生”。它会通过比较和关联分析，找出关键驱动因素。例如，“当‘折扣率’超过 15% 且‘决策者已参与’时，赢单率显著提高”。
- 预测性洞察 (Predictive Insights)： 预测“将会发生什么”，并构建预测模型。

3. 模型评估与部署 (Model Evaluation & Deployment)

故事创建完成后，Einstein Discovery 会自动生成一个或多个机器学习模型（通常包括广义线性模型 GLM 和梯度提升机 XGBoost），并提供详细的模型评估指标，如准确率 (Accuracy)、AUC、R² 等。我们可以评估模型的质量，并选择最佳模型进行部署。

部署模型会创建一个 Prediction Definition（预测定义），它可以被 Salesforce 平台的其他部分调用。部署选项非常灵活：

Salesforce 字段预测： 将预测结果和改进建议直接写入 Salesforce 记录页面（例如，在 Opportunity 页面上显示预测的赢单率和推荐操作）。
Flow / Process Builder 调用： 在自动化流程中基于预测结果执行操作。例如，当一个高价值客户的流失风险预测超过 80% 时，自动创建一个任务分配给客户经理。
Apex 调用： 允许开发人员通过代码以编程方式获取预测结果，实现更复杂的自定义逻辑。

示例代码

作为数据工程师，我们常常需要支持开发团队将 AI 模型集成到复杂的业务逻辑中。使用 Apex 调用已部署的 Einstein Discovery 模型就是一个典型场景。例如，我们需要批量评估一组新导入的机会 (Opportunity) 的赢单概率。

以下代码示例展示了如何使用 ConnectApi 从 Apex 中调用一个已部署的预测模型。假设我们已经部署了一个用于预测机会赢单率的模型，并获得了它的 Prediction Definition ID。

// 假设这是一个用于批量处理机会的 Apex 类
public class OpportunityPredictionService {

    // 这是一个可调用的方法，例如可以从一个批处理 Apex 或 LWC 中调用
    @InvocableMethod(label='Get Opportunity Win Predictions' description='Gets win predictions for a list of Opportunities.')
    public static List<PredictionResultWrapper> getPredictions(List<Id> opportunityIds) {

        // 1. 定义要调用的预测模型 ID。这个 ID 可以从 Einstein Discovery 的模型管理器中获取。
        // 对于生产环境，建议使用自定义元数据或自定义设置来存储此 ID，而不是硬编码。
        String predictionDefinitionId = '1ORB00000008o1sOAA'; 

        // 2. 查询需要进行预测的记录，并选择模型训练时使用的字段。
        // 必须确保查询的字段与模型输入的字段一致。
        List<Opportunity> opportunities = [SELECT Id, Amount, LeadSource, (SELECT COUNT() FROM OpportunityContactRoles) 
                                            FROM Opportunity WHERE Id IN :opportunityIds];
        
        if (opportunities.isEmpty()) {
            return new List<PredictionResultWrapper>();
        }

        // 3. 构造 ConnectApi 的预测请求对象
        ConnectApi.EinsteinDiscovery.PredictionRequest predictionRequest = new ConnectApi.EinsteinDiscovery.PredictionRequest();
        predictionRequest.predictionDefinition = predictionDefinitionId;
        predictionRequest.records = opportunities; // 直接传入 SObject 列表
        predictionRequest.ask = null; // 'ask' 参数用于 what-if 分析，此处为简单预测，设为 null
        predictionRequest.settings = null; // 'settings' 参数用于控制返回的预测因子数量等，使用默认值

        // 4. 调用 Einstein Discovery 的预测 API
        // 这是一个同步调用，需要注意其对 Governor Limits 的消耗
        ConnectApi.EinsteinDiscovery.PredictionResult predictionResult = ConnectApi.EinsteinDiscovery.predict(predictionRequest);

        // 5. 解析返回结果并封装
        List<PredictionResultWrapper> results = new List<PredictionResultWrapper>();
        for (ConnectApi.EinsteinDiscovery.Prediction prediction : predictionResult.predictions) {
            PredictionResultWrapper wrapper = new PredictionResultWrapper();
            wrapper.opportunityId = prediction.record.Id;
            // 结果对象中的 'outcome' 字段包含了预测值
            wrapper.predictedOutcome = prediction.outcome.value; 
            // 'prescriptions' 包含了改进建议
            wrapper.topPrescription = !prediction.prescriptions.isEmpty() ? prediction.prescriptions[0].formattedValue : 'N/A';
            
            results.add(wrapper);
        }

        return results;
    }

    // 用于封装返回结果的内部包装类
    public class PredictionResultWrapper {
        @InvocableVariable(label='Opportunity ID')
        public Id opportunityId;

        @InvocableVariable(label='Predicted Outcome')
        public Double predictedOutcome;
        
        @InvocableVariable(label='Top Prescription')
        public String topPrescription;
    }
}

代码注释说明：

第 7 行： 这是核心，我们必须提供已部署模型的 ID。最佳实践是将其配置化管理。
第 11-12 行： 查询的 SObject 记录必须包含模型所依赖的所有输入字段。如果缺少字段，API 将返回错误。
第 19 行： `ConnectApi.EinsteinDiscovery.PredictionRequest` 是构建请求的主体。
第 21 行： 最方便的是直接将 SObject 列表传递给 `records` 属性。ConnectApi 会自动将其转换为模型所需的格式。
第 27 行： `ConnectApi.EinsteinDiscovery.predict()` 是执行预测的同步方法。对于大批量数据，应考虑在异步上下文（如 Queueable Apex）中调用，以避免超出 CPU 时间限制。
第 32-38 行： 遍历返回的 `PredictionResult` 列表。每个 `Prediction` 对象都与一个输入记录对应，并包含了预测结果 (`outcome`)、顶级预测因子 (`topPredictors`) 和改进建议 (`prescriptions`)。

注意事项

作为数据工程师，在实施 Einstein Discovery 项目时，我们需要关注以下关键点：

权限与许可

确保相关用户拥有正确的许可证和权限集。主要涉及：

CRM Analytics Plus License： 使用 Einstein Discovery 需要此许可证。
Einstein Discovery User Permission Set： 允许用户查看故事和与预测交互。
Einstein Discovery Manager Permission Set： 允许用户创建和管理故事及模型。
确保运行 Apex 代码的用户有权访问 `ConnectApi.EinsteinDiscovery` 类，并有权访问相关的预测定义。

数据与 API 限制

数据集限制： CRM Analytics 数据集有行数和列数的限制。在设计数据管道时必须考虑到这些限制。目前，每个数据集最多可以有 20 亿行和 5000 列。
API 调用限制： 通过 Apex 进行的 `predict` 调用会消耗 API 限制。虽然 `ConnectApi` 调用通常不计入每日 API 总调用限制，但它们受制于同步 Apex 的其他 Governor Limits，如 CPU 时间和堆大小。批量处理数据时务必进行优化。
模型限制： 每个 Salesforce 组织可以部署的预测模型数量是有限的。需要合理规划和管理模型生命周期。

模型质量与偏见

数据偏见 (Bias)： 模型的预测质量直接取决于训练数据的质量。如果训练数据中存在历史偏见（例如，对某个区域或人群的偏见），模型将会学习并放大这种偏见。我们需要在数据准备阶段就识别并缓解这些问题。
数据漂移 (Data Drift)： 业务环境是不断变化的，导致线上数据的分布会逐渐偏离训练数据，这称为数据漂移。这会导致模型性能下降。必须建立模型监控机制，定期使用新数据重新训练和部署模型。

错误处理

在 Apex 调用中，`ConnectApi.EinsteinDiscovery.predict()` 方法可能会抛出异常。例如，如果预测定义 ID 无效、输入数据缺少必要字段或数据格式不正确。必须在代码中使用 `try-catch` 块来妥善处理这些异常，避免对业务流程造成中断。

总结与最佳实践

对于 Salesforce 数据工程师来说，Einstein Discovery 不是一个可以替代我们工作的魔法棒，而是一个能极大放大我们工作价值的强大工具。它将复杂的机器学习流程自动化，让我们能更专注于数据本身——数据的质量、相关性和业务价值。

最佳实践总结：

从业务问题出发： 在启动项目前，与业务方清晰地定义一个具体、可衡量且有价值的业务问题（例如，将新客户的转化率从 15% 提升到 20%）。
投资于数据准备： 投入 80% 的精力在数据准备和特征工程上。高质量、精心设计的数据集是构建高质量模型的基石。
迭代与验证： 不要试图一次性构建一个完美的模型。采用敏捷方法，从一个最小可行性模型 (MVP) 开始，快速部署并收集业务反馈，然后不断迭代优化。
解释与信任： 利用 Einstein Discovery 提供的洞察和解释功能，向业务用户解释模型“为什么”会做出某个预测。建立用户对 AI 的信任是推动其在业务中落地的关键。
建立 MLOps 流程： 规划一个完整的模型生命周期管理 (MLOps) 流程，包括持续的性能监控、定期的数据刷新和模型再训练，以确保模型的长期有效性。

通过遵循这些实践，我们可以将 Einstein Discovery 从一个强大的分析工具转变为企业数据驱动决策文化的核心引擎，真正实现从数据到洞察，再到行动的闭环。

Salesforce中文网