执行算法中的常见错误
执行算法是什么——以及不是什么
执行算法是将订单拆分为更小操作并安排何时、如何向交易场所发送这些操作的自动化方法。其重点通常是执行质量：实际成交价/量与预期的接近程度、订单的成交速度，以及成本（如手续费和点差）对结果的影响。
一个常见的误解是认为执行算法可以在不依赖市场条件的情况下可靠地“改善”结果。执行逻辑无法控制流动性、价格的突然变化或市场的微观结构。它也无法消除来自成本、时间及操作限制的不确定性。
误解如何导致本可避免的问题
- 混淆机制与结果
一种典型错误是假设由于某个算法“设计”为实现某种成交方式，就一定能带来可预测的结果。实际上，执行结果会随波动性、可用流动性和订单簿形态而变化。
中性检查：将你能精确描述的内容（算法的规则）与你无法控制的内容（未来的成交、未来的点差、未来的延迟）区分开来。
- 使用错误输入且未声明假设
执行表现依赖于紧迫性、订单规模、时间粒度以及系统衡量进展的方式（例如已成交与剩余数量）。如果示例中混合了变量——比如在讨论变化成本的同时假设点差固定——计算就会变得脆弱。
中性检查：对于任何数值示例，明确说明假设（例如，固定成本 vs. 可变成本，固定延迟 vs. 可变延迟），并在假设变化时调整结论。
- 将历史关系视为保证
另一个错误是相信观察到的过去滑点或成交率会持续下去。即使某种方法在某一时期表现良好，未来条件也可能不同。历史关系可能是偶然的或特定于某一市场状态。
中性检查：避免将历史回测结果当作稳定事实进行预测。相反，应思考在什么情况下相同逻辑会产生不同行为。
证据或示例：常被忽视的失败模式
考虑一个简化场景：用户打算使用一种随时间提交较小子订单的算法来买入特定数量。一个现实的失败模式是部分成交与剩余漂移：如果早期子订单迅速成交，后期部分可能与不同的订单簿交互，导致更差的有效价格。
其他常见的执行算法失败模式包括：
- 延迟敏感性：决策与提交之间的延迟可能导致下一个子订单错过预期的时间窗口。
- 价格影响错配：如果算法假设影响较小，但订单规模消耗了可见流动性，滑点可能增加。
- 操作限制：速率限制、连接问题或订单被拒可能改变执行路径。
中性检查：思考当假设被打破时会发生什么——当流动性消失、点差扩大、订单部分被拒或出现时间抖动时。
局限性、风险及可独立验证的内容
执行算法不提供确定性。相同的策略逻辑在不同市场状态下可能产生不同结果，因为流动性和成本会变化。结果还取决于执行场所的规则和系统的操作行为。
要在不依赖承诺的情况下验证理解：
- 定义算法的控制变量（如何拆分、调度以及响应成交）。
- 识别哪些变量是外部且可变的（市场流动性、点差、波动性、时间抖动）。
- 检查示例和计算是否清晰说明了假设，并在假设变化时仍保持有效。
一个“完整”的解释应至少包含一个实质性的局限或失败模式——例如部分成交、延迟效应或成本可变性——因为这正是误解通常转化为实际执行风险的地方。
验证或下一个问题
如果你在比较两种关于执行算法的解释，请寻找算法规则与可变条件之间的清晰区分。然后确认每种解释是否明确说明了其假设并提到了失败模式。如果没有，则应将结论视为不完整而非正确。