在过去大约六个月中，我一直在创建一个系统来打击欺诈（欺诈活动、欺诈等），而没有任何初始基础设施。 今天我们在系统中发现并实施的想法可以帮助我们检测和分析许多欺诈活动。 在这篇文章中，我想谈谈我们遵循的原则以及我们为实现系统当前状态所做的工作，但不涉及技术部分。
我们系统的原则
当您听到“自动”和“欺诈”等术语时，您很可能会开始考虑机器学习、Apache Spark、Hadoop、Python、Airflow 以及 Apache 基金会生态系统和数据科学领域的其他技术。 我认为使用这些工具的一个方面通常不会被提及：在开始使用它们之前，您的企业系统需要满足某些先决条件。 简而言之，您需要一个包含数据湖和仓库的企业数据平台。 但如果你没有这样的平台，仍然需要发展这种做法怎么办？ 我在下面分享的以下原则帮助我们达到了这样一个目标：我们可以专注于改进我们的想法，而不是寻找可行的想法。 然而，这并不是一个项目停滞期。 从技术和产品的角度来看，计划中还有很多东西。
原则一：商业价值第一
我们将“商业价值”置于我们所有努力的首位。 一般来说，任何自动分析系统都属于自动化水平较高、技术复杂性较高的复杂系统。 如果从头开始创建完整的解决方案将花费大量时间。 我们决定将商业价值放在第一位，将技术完整性放在第二位。 在现实生活中，这意味着我们不接受先进技术作为教条。 我们选择目前最适合我们的技术。 随着时间的推移，我们似乎必须重新实现一些模块。 这是我们接受的妥协方案。
原则 2：增强智能
我敢打赌，大多数没有深入参与开发机器学习解决方案的人可能会认为取代人类是目标。 事实上，机器学习解决方案远非完美，只有在某些领域才有可能替代。 我们从一开始就拒绝了这个想法，原因有几个：欺诈活动的数据不平衡以及无法为机器学习模型提供全面的功能列表。 相比之下，我们选择了增强智能选项。 这是人工智能的另类概念，侧重于人工智能的支撑作用，强调认知技术旨在增强人类智能，而不是取代人类智能。 [1]
鉴于此，从一开始就开发完整的机器学习解决方案需要付出巨大的努力，这将延迟为我们的业务创造价值。 我们决定在领域专家的指导下构建一个具有迭代增长的机器学习方面的系统。 开发这样一个系统的挑战性部分在于，它必须为我们的分析师提供案例，而不仅仅是关于是否是欺诈活动。 一般来说，客户行为的任何异常都是可疑的，专家需要进行调查并以某种方式做出回应。 这些报告的案例中只有一小部分可以真正归类为欺诈。
原则 3：丰富的分析平台
我们系统中最具挑战性的部分是系统工作流程的端到端验证。 分析师和开发人员应该轻松获取历史数据集以及用于分析的所有指标。 此外，数据平台应该提供一种简单的方法来用新的指标来补充现有的指标集。 我们创建的流程（不仅仅是软件流程）应该使我们能够轻松地重新计算以前的时期、添加新指标并更改数据预测。 我们可以通过积累生产系统生成的所有数据来实现这一目标。 在这种情况下，数据就会逐渐成为麻烦。 我们需要存储越来越多我们不使用的数据并对其进行保护。 在这样的场景下，随着时间的推移，数据会变得越来越无关紧要，但仍然需要我们努力管理它。 对我们来说，数据囤积没有意义，因此我们决定采取不同的方法。 我们决定围绕我们想要分类的目标实体组织实时数据存储，并仅存储允许我们检查最近和相关时期的数据。 这项工作面临的挑战是我们的系统是异构的，具有多个数据存储和软件模块，需要仔细规划才能以一致的方式运行。
我们系统的设计理念
我们的系统有四个主要组成部分：摄取系统、计算系统、BI 分析和跟踪系统。 它们服务于特定的、孤立的目的，我们通过遵循特定的设计方法来保持它们的隔离。
基于合同的设计
首先，我们同意组件应该只依赖它们之间传递的某些数据结构（契约）。 这使得它们之间的集成变得很容易，并且不会强加特定的组件组成（和顺序）。 例如，在某些情况下，这允许我们直接将进气系统与警报跟踪系统集成。 在这种情况下，这将根据商定的警报合同来完成。 这意味着这两个组件将使用任何其他组件都可以使用的合同进行集成。 我们不会添加额外的合同来从输入系统向跟踪系统添加警报。 这种方法需要使用预定的最小数量的合约，并简化了系统和通信。 本质上，我们采用一种称为“合约优先设计”的方法并将其应用于流合约。 [2]
随处流媒体
在系统中保存和管理状态将不可避免地导致其实现的复杂性。 一般来说，状态应该可以从任何组件访问，它应该是一致的，并提供所有组件的最新值，并且它应该是可靠的，具有正确的值。 此外，调用持久存储来检索最新状态将增加 I/O 操作的数量以及实时管道中使用的算法的复杂性。 因此，我们决定如果可能的话，从我们的系统中完全删除状态存储。 这种方法要求所有必要的数据都包含在传输的数据块（消息）中。 例如，如果我们需要计算某些观察的总数（具有某些特征的操作或案例的数量），我们会在内存中计算它并生成此类值的流。 相关模块将使用分区和批处理将流拆分为实体并根据最新值进行操作。 这种方法消除了对此类数据进行持久磁盘存储的需要。 我们的系统使用Kafka作为消息代理，它可以与KSQL一起用作数据库。 [3] 但使用它会将我们的解决方案与 Kafka 紧密联系在一起，因此我们决定不使用它。 我们选择的方法允许我们用另一个消息代理替换 Kafka，而无需对系统进行重大内部更改。
这个概念并不意味着我们不使用磁盘存储和数据库。 为了测试和分析系统性能，我们需要在磁盘上存储大量代表各种指标和状态的数据。 这里重要的一点是实时算法不依赖于此类数据。 在大多数情况下，我们使用存储的数据对系统产生的特定案例和结果进行离线分析、调试和跟踪。
我们系统的问题
有些问题我们已经解决到一定程度了，但还需要更周到的解决方案。 现在我只想在这里提及它们，因为每一点都值得单独写一篇文章。
- 我们仍然需要定义流程和策略，支持为我们的自动化数据分析、发现和探索积累有意义的相关数据。
- 将人工分析结果纳入自动设置系统的过程中，以使用最新数据更新系统。 这不仅更新了我们的模型，还更新了我们的流程并提高了我们对数据的理解。
- 在 IF-ELSE 的确定性方法和 ML 之间找到平衡。 有人说，“机器学习是绝望者的工具。” 这意味着当您不再了解如何优化和改进算法时，您将需要使用机器学习。 另一方面，确定性方法不允许检测未预期的异常。
- 我们需要一种简单的方法来测试我们的假设或数据中指标之间的相关性。
- 该系统必须具有多个级别的真阳性结果。 欺诈案件仅占所有可被视为对系统有利的案件的一小部分。 例如，分析人员希望收到所有可疑案例进行验证，而其中只有一小部分是欺诈。 系统必须有效地将所有案例呈现给分析师，无论是实际的欺诈还是只是可疑的行为。
- 数据平台应该能够检索历史数据集，并实时生成和计算结果。
- 在至少三种不同的环境中轻松自动地部署任何系统组件：生产环境、实验环境（测试版）和开发人员环境。
- 最后但并非最不重要。 我们需要建立一个丰富的性能测试平台来分析我们的模型。 [4]
引用
来源： habr.com