与您所做决策紧密相关的模型
当更好的预测能改变一项决策时——该备什么货、审查哪些交易、哪些客户需要关注、推荐什么——机器学习就值得构建。我们使用 scikit-learn、PyTorch 或 TensorFlow 开发定制模型，从数据准备到生产环境，并将其与简单的基准进行对比测试，让您了解该模型带来了什么增益。您将获得一个在您系统内运行、能解释其预测，并随着您数据变化而受到监控的模型。
AI 辅助、专家主导的 ML 工程
AI 如何协助
- AI 协助数据剖析、起草清洗脚本并建议特征，由数据科学家进行验证。
- 编码代理起草训练管道、评估代码和服务 API，供工程师审查。
- AI 按细分汇总实验结果和错误模式，供工程师审查。
我们的专家负责什么
- 问题构建、成功指标，以及模型必须超越的基准
- 特征选择、泄漏检查和验证设计
- 公平性审查，以及哪些预测在采取行动前需要有人工审查
- 将每个模型版本提升至生产环境
模型从数据到生产的路径
预测模型的典型生命周期；关卡和阈值会按项目与你的团队商定。
数据审计
剖析模型将从中学习的记录：覆盖范围、标签质量，以及会泄漏结果的字段。
基线
设定需要超越的简单方法，例如上一周期的数据或你当前的规则。
训练
在较早的历史数据上训练候选模型，保留最近的一段时间用于测试它们。
离线评估
候选模型在留出数据上与基线进行评分，既看整体，也看每个重要细分群体。
检查点: 仅在超越基线时才继续推进
影子或有限度上线
模型在后台对实时案例进行评分，或先针对一小部分群体，同时当前的决策照常进行。
检查点: 你批准更大范围的使用
漂移监控
输入漂移和预测质量会对照商定的阈值进行跟踪，并在应考虑再训练时发出警报。
当出现故障时: 如果某个候选模型未能超越基线，或影子结果与离线测试不同，它就不会被提升上线，当前的方法继续运行。
谁会带着预测问题来找我们
规划和审查决策仍然依赖电子表格和固定规则，而本可以让这些决策更精准的销售、交易或传感器历史数据却闲置在你的数据库中。
- 根据过往销售预测需求的采购和规划团队
- 决定优先审查哪些交易或理赔的风险和欺诈分析师
- 拥有传感器数据、可借此提前标记故障设备的维护团队
您将获得什么
从原始数据到受监控的模型
预测和预报模型
销售预测、需求预测和风险评分，使用诸如梯度提升、Prophet 或 LSTM 网络等方法，根据在您数据上的结果进行选择。
分类和异常检测
客户细分、欺诈和垃圾信息检测，以及对交易、传感器数据或用户行为中的离群值检测，并为被标记的案例配备审查队列。
推荐引擎
针对产品和内容的协同、基于内容或混合式推荐，在发布前与简单的基准进行对比测试。
评估报告和模型卡
留出集和回测结果、按细分的错误、使用 SHAP 或特征重要性的解释，以及一张说明已知局限的模型卡。
生产 API 或批处理作业
模型以 REST API 或计划批处理作业的形式提供，与您的系统集成，并具备日志记录和版本化发布。
MLOps 和漂移监控
漂移和性能监控、重训练管道、模型版本管理和 A/B 测试，以便在您数据变化时跟踪质量。
模型工作不包括什么
- 文本、文档和图像由自然语言处理和计算机视觉处理；本服务对订单、交易和传感器读数等结构化记录进行建模。
- 生成式文本，例如从文档中得出的摘要或答案，属于 LLM Integration；此处的模型根据你的历史数据预测数字、分数或类别。
- 不包括全公司范围的数据仓库建设：我们准备模型所需的数据，而如果历史数据从未被记录，那么收集数据是第一步。
- 用于信贷、保险或健康决策的模型的监管批准仍由你的合规团队负责；我们提供模型卡和评估证据供他们审查。
典型的建模需求
我们所界定范围的典型场景，而非客户案例研究。
由电子表格设定的库存订单
采购人员根据去年的数据加上判断来设定订货量。我们会针对每个产品组，用一个预测模型与该方法进行对比测试，并在他们的规划工具中展示建议数量，由采购人员接受、调整或拒绝。
被标记的交易多于分析师能够核查的数量
固定的欺诈规则标记出的交易多于团队能够审查的数量。我们会基于过往审查决策训练一个评分模型，按风险对队列进行排序，并把每个案例的最终判断权留给分析师。
一个质量未知的继承而来的模型
一位前员工留下的流失预测模型仍在运行，但近来无人衡量它。我们会在近期数据上重建对它的评估，将其与一个简单基线进行比较，并加入漂移监控，以便你决定是重新训练它还是让它退役。
我们如何开发 ML 模型
- 01
问题定义
明确模型所支持的决策、成功衡量标准、需要超越的基线，以及机器学习是否根本就是合适的工具。
- 02
数据准备
审计、清洗和标注数据，构建特征，并检查数据泄漏和偏差。数据缺口会在训练开始前报告。
- 03
训练与验证
训练并比较候选模型，在留出数据上并按细分群体验证它们，并将结果和局限记录在模型卡中。
- 04
部署与监控
以 API 或批处理作业形式部署，将其与你的系统集成，并监控漂移和性能，按商定的计划进行再训练。
设计、QA 和运维如何支持您的模型
人们可以据以行动的预测
设计师塑造评分、置信度和原因在您工具中的呈现方式，以及员工如何覆盖某个预测，从而让模型支持决策而非隐藏决策。
整个管道的 QA
QA 检查数据验证、边缘情况、按细分的错误和公平性，并在重训练后的模型被提升之前运行回归测试。
按模型规模配置的基础设施
DevOps 负责运行服务、计划作业、监控和回滚。许多模型在标准基础设施上运行良好；只有在训练或推理需要时才会添加 GPU。
有监督的重训练
我们监控漂移，在新数据上重训练，并在每个新版本替换当前版本之前将二者进行对比，提升时须经您批准。
常见问题
常见问题解答
我们需要多少数据？
这取决于问题本身、你的数据有多嘈杂，以及你要预测多少种结果。我们会在问题定义阶段评估你的数据，并告诉你数据是否足够、增加标注是否有帮助，或者更简单的基于规则的方法是否更适合你。
你们如何检查模型的偏差和公平性？
我们审计训练数据，比较相关细分群体之间的错误率，并在模型卡中记录已知的局限。像 SHAP 这样的可解释性工具会展示哪些因素驱动了预测。在决策对人有重大影响的场景，我们会为人工审查而非自动执行进行设计。
当我们的数据发生变化时会怎样？
监控会跟踪输入漂移和预测质量。当性能低于你批准的阈值时，再训练流水线会产出一个新版本，在任何人将其提升上线之前，会将它与当前模型进行比较。
我们的训练数据可以留在我们自己的环境中吗？
可以。训练和服务可以在你的云账户中或在你所控制的基础设施上运行，因此数据可以留在其中。对于我们的开发工作，私有 / 本地 AI 工程 会在商定的边界内运行 AI 编码模型，而 Claude Code / OpenAI Codex 工程 则在商定的账户条款下使用商用编码代理。
