匹配与置信度

价格是跨平台数据中比较容易的那一部分。难的部分是判断两个上架标的其实是同一场比赛：各平台使用不同的代码、球队标识和市场结构，一次错误的配对会产生一个看起来真实、但结算方式却是错的机会。dino 把匹配当作一套独立于定价的系统来处理。本页说明它的运作方式。

匹配是离线的，定价是实时的

匹配运行在一个缓慢、可复核的循环中，与热路径上的实时定价相互独立。匹配引擎会扫描两个平台的目录——对今天和明天的比赛至少每 15 分钟扫描一次，在每场比赛开赛前一小时内缩短至每 3 分钟一次——对发现的内容进行规范化处理，并把已确认的配对写入配对表。定价循环只会为这张表里的配对定价。

一个尚未被配对的市场，只会单纯地不生效。失败模式永远是错过一个机会，而不是出现一个虚假的机会。

配对如何评分

球队和赛事名称会依据按联赛划分的名称库进行规范化处理，该名称库由各平台自身已结算的市场作为种子数据构建。命中名称库精确匹配会保留完整置信度。模糊名称匹配也允许形成一个配对，但在被独立确认之前，其置信度会被限制在 0.95 以下。

每个配对都携带两个独立的分数：

• entity_confidence —— 我们有多确定两个上架标的是同一支球队、同一场比赛。
• resolution_confidence —— 我们有多确定两个平台会以相同的方式结算该结果。

作为代表值的 confidence 始终取两者中较低的一个，因此结算方式的不一致永远无法隐藏在完美的名称匹配背后。扣减因素是明确列出的：一次模糊名称命中、一次仅凭开赛时间接近而非精确日期成立的匹配，或是一条从联赛默认规则推断、而非直接从该市场自身条款中读取的结算规则。

生效门槛

这些分数决定了什么可以作为套利提供。一个配对只有在两个分数都达到或超过 0.95、且该市场的每个结果都在两个平台上被覆盖时，才会进入实时数据流；一个未确认的配对会停留在待审核区，永远不会生效。在 v2 API 上，提供给外部的 signal 需要在每次请求时通过四项检查才能确立：该配对处于活跃状态且至少有两次独立确认、跨平台结算一致性已确认、该配对完整的风险集合中不存在 high 或 critical 严重程度的风险，并且每个结果都已在两个平台上定价。达不到这些条件的一律以 spread 提供。市场对象页面对该字段有详细说明。

覆盖不完整是一项硬性阻断，而不是扣分项。一个三向的足球市场如果只匹配了两条腿，无论名称匹配的置信度有多高，它永远不会具备生效条件——如果按双向定价，就会无声地忽略"平局"这一结果。

Candidates：待审核区，实时推送

Pro 套餐可以订阅 candidates:{sport}：即匹配引擎已经形成、但尚未确认的配对——可能是一次仍低于上限的模糊名称匹配，也可能是一个尚未在两个平台上都被覆盖的结果。一个新上架的标的通常会在该平台公开后的几分钟内出现在这里。确认需要独立佐证，因此在这些检查完成之前，candidates 会领先于已确认数据流一步。

candidates 是关于配对本身的事实，而不是机会。它们永远不会生效，它们会附带两个置信度分数一同到达，基于某个候选项计算出的任何价差都不应被当作可执行的价格。candidates 提供给你的，是匹配引擎当前视野中最早的一层可见性——那些仍在被核查的配对。

确认闭合循环

一个模糊配对只有在独立检查一致通过时才会被晋级——也就是说，该配对已经对照两个平台各自的上架信息、元数据和市场行为得到了佐证——只要检查不一致，它就永远不会生效。已晋级的配对之后仍会对照已结算市场的真实结果进行复审，一旦发现结算错误就会被降级。这套系统的设计目标是修复一次错误的晋级，而不是永久信任它。