如何衡量执行算法？

执行算法：你测量的是什么

执行算法是决定如何将订单拆分为更小操作、以及这些操作如何定时和路由的方法。为了以可验证的方式衡量它们，应重点关注可测量的执行字段（发生了什么）和可测量的时间字段（何时发生）。然后仅在明确陈述的假设下比较结果，因为市场状况和执行成本可能主导最终结果。

机制与可测量字段

定义衡量方法的一种实用方式是从一个“订单事件日志”开始，针对单个母订单进行分析。

1) 时间字段

• 请求时间：母订单提交的时间。
• 执行开始时间：首次子订单执行尝试的时间。
• 完成时间：母订单完全成交或终止的时间。
• 队列/延迟窗口：发送子订单到收到确认或成交之间经过的时间（如果数据可记录）。

2) 成交质量字段

• 成交率：已成交数量除以预期数量。
• 剩余数量：完成时未成交的部分。
• 成交分布：每个时间段内成交的数量。

3) 成本与价格影响字段 为避免歧义，使用选定的参考价格和明确定义的公式来计算成本。 常见的参考价格选择包括：

• 开始时的中间价（如果你能观察到，即最佳买价和卖价之间的中点）
• 决策价格：算法开始时的价格
• 到达价格：第一个可执行时刻的价格

然后测量：

• 滑点（Slippage）：平均执行价格与参考价格之间的差值（有方向性）。
• 执行缺口（Implementation shortfall，概念上）：相对于参考价格的成本，包含价格变动和执行不完全两方面。

4) 约束与控制字段 如果算法有参数（例如参与目标或时间限制），应将其视为可测量输入，并验证在每种场景下算法满足这些约束的频率。

证据与示例计算（含明确假设）

假设你有一个100单位的母订单：

• 母订单在10:00:00提交。
• 首次子订单执行尝试在10:00:05。
• 完全完成于10:00:35。
• 所有成交的平均执行价格为1.2000。
• 你的参考价格（执行开始时的中间价）为1.1980。

一个简单且可验证的滑点计算为：

• 滑点 = 平均执行价格 − 参考价格
• = 1.2000 − 1.1980 = 0.0020（每单位，以价格表示）

为使此计算独立且可复现，你还应说明：

• 参考价格定义（10:00:05的中间价）
• 数据粒度（成交价格和时间戳）
• 是否使用了加权平均

如果你还观察到100单位中仅有90单位成交，则报告成交率 = 0.90，并将不完全成交视为一个独立的重要组成部分，而非仅归入价格因素。

局限性与失效模式（什么会破坏比较）

即使有严谨的指标，若忽略可变性，比较仍可能产生误导。

重要局限性

• 市场条件主导：流动性、点差宽度和波动性可能在执行过程中变化并影响成本。
• 不同场景下的成本差异：费用、佣金及任何与执行相关的收费都可能改变成本指标。
• 基准依赖性：参考价格定义改变时，滑点数值也会变化。
• 历史关系不能确立未来结果：一种市场机制下的过往表现可能不适用于另一种机制。

需测量或注意的失效模式

• 部分成交：算法完成时仍有未成交数量。
• 队列延迟与延迟敏感性：在拥堵加剧期间，执行时序可能恶化。
• 相对于预期节奏的过度交易或交易不足：实际子订单频率可能偏离目标。
• 停止/终止行为：频繁取消或提前退出可能使成本和完成时间比较产生偏差。

验证与下一个问题

要验证关于执行算法的声明，你需要三个可独立检查的内容：(1) 测量字段和公式，(2) 使用的时间戳和时间窗口，(3) 关于参考价格和数据可用性的假设。如果两方计算“相同”的指标，但选择了不同的参考价格或采样窗口，其结果可能合法地不一致。

一个有用的问题是：你实际拥有关于参考价格（中间价、到达价或其他代理）以及延迟/确认的数据吗？回答这个问题后，你可以在比较算法或提供商之前统一衡量定义。