注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
警报工作流
无论是检测欺诈还是发现收入机会，警报工作流会自动将问题呈现给终端用户进行审查，他们可以一键做出决策。这些工作流使团队能够将注意力集中在解决最紧迫的问题上，而不是花时间手动拼凑数据。
Foundry的数据连接和Ontology允许组织在几天内而不是几个月内实施这种模式，并继续安全高效地实施、定制和维护它。
解决方案
警报工作流旨在自动呈现警报（更新、问题、机会等）供用户审查并做出决策。通常，用户会看到优先级警报和与警报相关的相关数据，他们会审查这些数据以做出决策。他们的决策通过记录决策的按钮（数据输出）记录到Foundry数据中，有时如果合适，也会记录到生产系统中。
以欺诈检测为例，用户可能会收到从最有可能到最不可能的欺诈警报列表进行审查。点击警报会显示所有支持信息，用户可以根据这些信息使用一个简单的按钮来指示是否为欺诈。
警报框架是针对那些花费大量时间从各种数据源中筛选并手动拼凑数据点以识别问题的用户的绝佳解决方案，最终目标是对发现的问题做出决策。有时终端用户有基本的SQL查询可以呈现部分这些问题，或者用户根本不筛选数据，因为工作太复杂。
警报可以被用于从检测欺诈到发现收入机会的应用案例。警报可以通过数据管道、机器学习模型、Foundry规则或这些组合中的任何一个生成。
关键要素
用户界面
以下是与警报工作流相关的界面列表。
警报界面
警报界面是用户将使用的主要应用程序。从这个界面，终端用户可以看到所有的警报、与帮助他们对警报做出决策相关的数据，以及他们可以用来记录决策的按钮。
下面显示了一个示例界面，其中包含最常用的组件。这个界面通常在Workshop中构建。
例如在欺诈检测中，筛选可能是欺诈可能性评分、特定类型的欺诈等。警报本身是欺诈案例，相关数据可能包括历史支付和用户资料。按钮通常可能包括欺诈/非欺诈，并提示用户提供解释。
相关产品：
影响追踪器
影响追踪器显示与警报界面相关的生产和运营指标。管理者通常使用追踪器来审查指标，例如已解决的警报数量、在警报界面中常见的决策是什么、他们离达到目标关键绩效指标的距离等。
下面显示了一个示例追踪器，其中包含最常用的组件。这个界面可以在Quiver或Workshop中构建。
在欺诈检测中，这个影响追踪器可能显示已审查的欺诈/非欺诈案例的百分比、由用户填充的欺诈关键驱动因素和解释、通过早期检测欺诈节省的金额、决策时间等。
相关产品：
（非必填）Foundry规则
Foundry规则是一个Foundry应用程序，允许任何用户，无论其编码背景如何，使用用户友好的点击界面在数据上创建和维护规则，以定义任意数量的警报条件。每个定义的规则都会创建一种警报类型。Foundry规则的实施在下面的警报自动化部分中详细说明。
相关产品：
Ontology
以下是与警报工作流设置相关的Ontology相关概念的列表。
Object
警报工作流通常包括一个触发对象类型（如客户、金融交易、制造过程或服务类型）和一个特定的警报对象（如潜在的欺诈警报、与服务类型相关的收入机会或与制造过程相关的过程优化机会）。
相关产品：
操作
操作是这个工作流的核心，因为它们记录终端用户的决策。从用户的角度来看，这些是他们点击的按钮。在后端，这些按钮由Ontology操作支持，这些操作配置为记录用户做出的决策。典型的操作字段包括：
- 用户ID
- 决策时间戳
- 做出决策的警报对象
- 决策本身（True/False，接受/拒绝等）
- （可选）决策的解释（有助于在追踪器中审查）
在欺诈检测中，这些操作会记录案件是否被确定为欺诈、做出决策的用户、他们做出决策的时间、他们为什么做出那个决策（解释）以及审查的具体案例ID。
相关产品：
数据输出
数据输出是Foundry记录决策的术语。文档可以在数据输出页面找到。本质上，通过Ontology应用程序制作了警报对象烘焙数据集的副本。操作将在复制的（数据输出）数据集中记录在操作部分中定义的字段。在欺诈检测中，对特定案例采取的操作然后会更新Ontology和相关数据集，以说明所采取的决策（例如通过设置警报是否确定为欺诈及调查结果的解释）。
除了写回到Foundry外，也常常写回到生产系统，如SAP、Oracle等。这通常涉及设置具有读写权限的生产系统的直接连接，并通过连接传递数据输出数据集的结果。请与您的Palantir团队联系以获取更多详细信息。
相关产品：
警报自动化
以下是与自动化警报相关的Foundry主题。
Foundry规则
Foundry规则是一组组件，允许用户在数据上创建和维护规则，无论其编码背景或能力如何。Foundry规则可以被用于根据任何所需条件定义各种不同类型的警报。Foundry规则的输出然后可以转换为警报对象。
下面显示了一个Foundry规则界面的示例。
在欺诈检测中，一些客户选择使用Foundry规则定义一种欺诈活动类型，并呈现所有相关的适用案例。例如，一个规则可能是：每当客户的费用超过$10k，或者每当客户在同一天内在两个不同城市有两个连续费用。
相关产品：
数据管道
有时，创建警报的逻辑可能非常明确，并且涉及复杂的规则，最适合在数据管道中编码。
例如，保险公司必须根据与医疗服务提供者的合同费率支付索赔，这些合同费率在他们的系统中显示为一组代码。当合同重新谈判时，应该记录一组新的代码以适用于新的时间跨度。在这种情况下，最好编码所有确定哪些代码应该何时适用的逻辑，并在Foundry中创建一个提案对象，建议使用重新谈判合同中的新代码分割时间跨度。
相关产品：
要求
无论使用哪种模式，基础数据基础都是由管道和同步到外部源系统构建的。
数据集成管道
用包括SQL、Python和Java在内的多种语言编写的数据集成管道被用于将数据源集成到主题Ontology中。
数据连接器
Foundry可以从多种来源同步数据，包括FTP、JDBC、REST API和S3。从多种来源同步数据并编译尽可能完整的真实来源是实现最高价值决策的关键。
应用案例实现模式
- 有效地实时调整销售和营销管道
- 通过保修分析优化索赔并减少支出
- 通过警报和调查支持防止变压器故障
- 公共安全停电范围
- 通过警报和了解提供者性能减少健康网络提供者的成本
- 减少对医疗保健提供者的多付和少付
- 通过集成的警报和分类应用程序响应全局安全事件
想了解更多关于此应用案例模式的信息或希望实施类似的内容？开始使用Palantir ↗。