我们系统的原理
当您听到诸如“自动”和“欺诈”之类的术语时，您可能会想到机器学习，Apache Spark，Hadoop，Python，Airflow和来自Apache Foundation生态系统和数据科学的其他技术。我认为通常不会提到使用这些工具的一个方面：在开始使用它们之前，它们需要企业系统中的某些先决条件。简而言之，您需要一个包含数据湖和存储的企业数据平台。但是，如果您没有这样的平台，仍然需要发展这种做法怎么办？我在下面讨论的以下原则帮助我们达到了可以集中精力改进思想而不是找到可行的思想的地步。但是，这不是项目的“高原”。从技术和产品的角度来看，计划中还有很多事情。
原则1：商业价值至上
我们将商业价值置于所有努力的中心。通常，任何自动分析系统都属于具有高度自动化和技术复杂性的复杂系统。如果从头开始创建一个完整的解决方案将花费很长时间。我们决定优先考虑业务价值和技术完整性。在现实生活中，这意味着我们不接受先进技术作为教条。我们选择目前最适合我们的技术。随着时间的流逝，似乎我们不得不重新实现一些模块。我们接受了这种妥协。
原则2：增强智能
我敢打赌，大多数不深入开发机器学习解决方案的人可能会认为替换人是目标。实际上，机器学习解决方案远非完美，只能在某些领域被替换。我们从一开始就放弃了这个想法，原因有几个：欺诈活动的数据不平衡，以及无法为机器学习模型提供详尽的功能列表。相反，我们选择了增强智能选项。它是人工智能的替代概念，其重点在于人工智能的支持作用，突出了认知技术旨在改善人类智能而不是替代人类智能这一事实。 [1]
考虑到这一点，从一开始就开发完整的机器学习解决方案将需要大量的工作，而这将延迟为我们的业务创造价值。我们决定在领域专家的指导下构建一个具有迭代式增长的机器学习功能的系统。开发这样一个系统的棘手部分是，它不仅要向我们的分析人员提供案例，而不仅仅是欺诈活动。通常，客户行为中的任何异常情况都是可疑的情况，专家需要以某种方式进行调查和做出响应。这些举报案件中只有一小部分确实可以归类为欺诈。
原则3：丰富的情报平台
我们系统最难的部分是系统工作流程的端到端检查。分析师和开发人员应该能够轻松检索具有用于分析的所有指标的历史数据集。此外，数据平台应提供一种简便的方法，用新的指标来补充现有的指标。我们创建的过程不仅是软件过程，还应使重新计算以前的期间，添加新指标和更改数据预测变得容易。我们可以通过累积生产系统生成的所有数据来实现这一目标。在这种情况下，数据将逐渐成为障碍。我们将需要存储和保护不断增长的不使用的数据。在这种情况下，随着时间的流逝，数据将变得越来越不相关，但仍需要我们努力进行管理。对于我们来说，数据ho积没有任何意义，因此我们决定采用其他方法。我们决定围绕我们要分类的目标实体组织实时数据存储，并且仅存储允许我们检查最近和当前期间的数据。这项工作面临的挑战是，我们的系统是异构的，具有多个数据存储和软件模块，这些数据存储和软件模块需要进行仔细的计划才能保持一致。通过它可以检查最近和当前期间。这项工作面临的挑战是，我们的系统是异构的，具有多个数据存储和软件模块，这些数据存储和软件模块需要进行仔细的计划才能一致地工作。通过它可以检查最近和当前期间。这项工作面临的挑战是，我们的系统是异构的，具有多个数据存储和软件模块，这些数据存储和软件模块需要进行仔细的计划才能保持一致。
我们系统的建设性概念
我们的系统中有四个主要组件：摄取系统，计算，BI分析和跟踪系统。它们用于特定的隔离目的，我们通过遵循特定的设计方法将它们隔离。
基于合同的设计
首先，我们同意组件应仅依赖于在它们之间传递的某些数据结构（合同）。这样可以很容易地在它们之间进行集成，而不必强加特定的组件组成（和顺序）。例如，在某些情况下，这使我们可以直接将接收系统与警报跟踪系统集成在一起。如果是这样，将按照约定的通知合同进行。这意味着将使用任何其他组件可以使用的合同来集成这两个组件。我们不会添加其他合同来从输入系统向跟踪系统添加警报。这种方法要求使用预定的最小数量的合同，并简化了系统和通信。事实上，我们使用一种称为“合同第一设计”的方法，并将其应用于流式合同。 [2]
维护和管理系统中的状态将不可避免地导致其实施复杂化。通常，状态可以从任何组件访问，它应该是一致的，并为所有组件提供最相关的值，并且使用正确的值应该是可靠的。此外，调用持久性存储以获取最后的状态将增加I / O的数量，并增加实时管道中使用的算法的复杂性。因此，我们决定尽可能从系统中完全删除状态存储。这种方法要求在传输的数据块（消息）中包含所有必要的数据。例如，如果我们需要计算某些观测值的总数（具有某些特征的操作或案例的数量），我们在内存中对其进行计算并生成此类值的流。相关模块将使用分区和批处理将流拆分为实体，并使用最新值进行操作。这种方法消除了永久存储此类数据的需求。我们的系统使用Kafka作为消息代理，并且可以将其用作KSQL的数据库。 [3]但是使用它会将我们的解决方案与Kafka紧密联系在一起，因此我们决定不使用它。我们采用的方法允许我们在不进行重大内部系统更改的情况下，用另一个消息代理替换Kafka。这种方法消除了对此类数据具有永久磁盘存储的需求。我们的系统使用Kafka作为消息代理，并且可以将其用作KSQL的数据库。 [3]但是使用它会将我们的解决方案与Kafka紧密联系在一起，因此我们决定不使用它。我们采用的方法允许我们在不进行重大内部系统更改的情况下，用另一个消息代理替换Kafka。这种方法消除了对此类数据具有永久磁盘存储的需求。我们的系统使用Kafka作为消息代理，并且可以将其用作KSQL的数据库。 [3]但是使用它会将我们的解决方案与Kafka紧密联系在一起，因此我们决定不使用它。我们采用的方法允许我们在不进行重大内部系统更改的情况下，用另一个消息代理替换Kafka。
这个概念并不意味着我们不使用磁盘存储和数据库。为了检查和分析系统性能，我们需要在磁盘上存储代表各种指标和状态的数据的重要部分。这里的重点是实时算法与此类数据无关。在大多数情况下，我们使用存储的数据对系统产生的特定情况和结果进行离线分析，调试和跟踪。
我们系统的问题
我们已经在一定程度上解决了某些问题，但是它们需要更周到的解决方案。现在，我只想在这里提及它们，因为每一点都值得单独写一篇文章。
- , , .
- . , .
- IF-ELSE ML. - : «ML — ». , ML, , . , , .
- .
- (true positive) . — , . , , — . , , .
- , .
- : , () .
- 最后但并非最不重要的。我们需要创建一个广泛的性能验证平台，在该平台上我们可以分析模型。[4]