回测收益别被交易成本吃掉:gs-quant市场冲击与流动性实操指南【免费下载链接】gs-quantPython toolkit for quantitative finance项目地址: https://gitcode.com/GitHub_Trending/gs/gs-quant如果你在 gs-quant(一套面向量化金融的 Python 工具包)上跑过回测,大概率注意到过同一个问题:回测曲线好看,策略一到实盘收益就缩水。元凶通常是被忽略的交易成本模型——当单笔订单量达到日均成交量的百分之几时,成交价其实已经被推到了不利的一侧。本文从 gs-quant 的回测引擎切入,讲清订单拆分、冲击系数校准、长周期分批回测这三件事怎么做。为什么回测的成交价太好了回测默认假设你能按历史收盘价买到任意数量,这等价于假设市场有无限流动性。现实里,大单的成本大致取决于两个变量:下单量:量越大,价格被推得越远日均成交量:流动性越低,同样的量需要更长时间才能完成完成时间:拖得越久,期间价格漂移的不确定性越大gs-quant 的回测入口是 Backtest 类,负责管理回测生命周期并通过get_results()拉取结果。但成本模型藏在执行层,这才是回测结果能否复现实盘的关键。拆解执行链路:订单如何变成成交执行逻辑在 gs_quant/backtests/execution_engine.py 的SimulatedExecutionEngine里,工作方式很简单:submit_order把订单放进队列,按完成时间排序ping随时间推进被调用,到点的订单生成成交fill FillEvent( orderorder, filled_priceorder.execution_price(self.data_handler), filled_unitsorder.execution_quantity(), )成交价由订单自身的execution_price决定——要建模市场冲击,只需要换掉订单的取价方式,引擎层不用动。gs_quant/backtests/order.py 里自带的订单类型:订单类型取价逻辑适用场景OrderAtMarket指定时刻的即时市场价小单、立即成交OrderTWAP时间窗口内价格均值大单拆分、摊薄冲击OrderMarketOnClose指定日收盘价调仓类交易OrderCost价格为 0,直接记金额佣金、固定费用三层的调用关系: 订单怎么拆分才能压低冲击OrderTWAP的默认假设是窗口内均匀拆单、按均价成交,本质是线性近似冲击成本:拆得越慢,付得越少。把它和冲击公式对照着看:成交价 ≈ 中间价 × (1 冲击系数 × 订单量 ÷ 日均成交量)实操上常用一条规则:单次成交量不超过日均量的 5%。例如要买入 50 万股、日均量 100 万股,按 5% 参与率一天最多买 5 万股,OrderTWAP的TimeWindow就要拉到至少 10 个交易日。冲击系数怎么校准下图是项目自带的流动性预测思路:同一个流动性预测输出,同时驱动市场冲击估计、参与率约束和成交可行性判断。校准步骤:拉出标的池近 3–6 个月的日均成交量与波动率把历史大单按量级分桶,统计实际均价与理论中间价的差分桶拟合冲击系数,验证它与参与率大致呈线性或平方根关系把拟合结果替换进订单的execution_price,做前后对照回测回测批次设为多少合适长周期回测不能一次全跑。gs_quant/markets/portfolio_manager.py 的PortfolioManager.schedule_reports(months_per_batch6)支持把历史区间按月切成滑动窗口分批提交,参数 ≤0 会抛MqValueError。超过一年的区间建议每批 6 个月,既避免超时,也让大单的冲击分析更稳定。关键参数推荐值:参数作用推荐值months_per_batch每批历史回测的月数3–6 个月冲击系数(impact_factor)每 1% 量参与的价格不利偏移幅度0.01–0.05,按资产分桶校准参与率上限单笔订单量 ÷ 日均量≤5%TWAP 窗口长度订单拆分完成的总天数由参与率反推,通常 ≥2 天如何扩展自定义成本模型线性 TWAP 不够用时,子类化SimulatedExecutionEngine,把流动性模型注入进来:class LiquidityAwareEngine(SimulatedExecutionEngine): def __init__(self, data_handler, liquidity_model): super().__init__(data_handler) self.liquidity_model liquidity_model关键是保持submit_order/ping接口不变,这样上游的 gs_quant/backtests/generic_engine.py 完全不用改,构造时传入新类即可。落地建议马上可以做的两件事:先跑成本敏感性对照:给现有回测分别加 10bp / 50bp 的冲击,观察夏普比率和收益排序变化。如果前几名资产换位,说明原回测不可信。从 5% 参与率规则入手:先统计回测里大单超过日均量 5% 的比例,把超标的订单换成更长窗口的OrderTWAP,这一步比完整校准冲击模型更便宜、见效更快。延伸阅读回测教程与示例:gs_quant/documentation/04_backtesting/官方文档入口:docs/index.rst风险模型(配合做绩效归因):gs_quant/models/risk_model.py回测示例合集:gs_quant/content/Contents.ipynb【免费下载链接】gs-quantPython toolkit for quantitative finance项目地址: https://gitcode.com/GitHub_Trending/gs/gs-quant创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 回测收益别被交易成本吃掉:gs-quant市场冲击与流动性实操指南
回测收益别被交易成本吃掉:gs-quant市场冲击与流动性实操指南【免费下载链接】gs-quantPython toolkit for quantitative finance项目地址: https://gitcode.com/GitHub_Trending/gs/gs-quant如果你在 gs-quant(一套面向量化金融的 Python 工具包)上跑过回测,大概率注意到过同一个问题:回测曲线好看,策略一到实盘收益就缩水。元凶通常是被忽略的交易成本模型——当单笔订单量达到日均成交量的百分之几时,成交价其实已经被推到了不利的一侧。本文从 gs-quant 的回测引擎切入,讲清订单拆分、冲击系数校准、长周期分批回测这三件事怎么做。为什么回测的成交价太好了回测默认假设你能按历史收盘价买到任意数量,这等价于假设市场有无限流动性。现实里,大单的成本大致取决于两个变量:下单量:量越大,价格被推得越远日均成交量:流动性越低,同样的量需要更长时间才能完成完成时间:拖得越久,期间价格漂移的不确定性越大gs-quant 的回测入口是 Backtest 类,负责管理回测生命周期并通过get_results()拉取结果。但成本模型藏在执行层,这才是回测结果能否复现实盘的关键。拆解执行链路:订单如何变成成交执行逻辑在 gs_quant/backtests/execution_engine.py 的SimulatedExecutionEngine里,工作方式很简单:submit_order把订单放进队列,按完成时间排序ping随时间推进被调用,到点的订单生成成交fill FillEvent( orderorder, filled_priceorder.execution_price(self.data_handler), filled_unitsorder.execution_quantity(), )成交价由订单自身的execution_price决定——要建模市场冲击,只需要换掉订单的取价方式,引擎层不用动。gs_quant/backtests/order.py 里自带的订单类型:订单类型取价逻辑适用场景OrderAtMarket指定时刻的即时市场价小单、立即成交OrderTWAP时间窗口内价格均值大单拆分、摊薄冲击OrderMarketOnClose指定日收盘价调仓类交易OrderCost价格为 0,直接记金额佣金、固定费用三层的调用关系: 订单怎么拆分才能压低冲击OrderTWAP的默认假设是窗口内均匀拆单、按均价成交,本质是线性近似冲击成本:拆得越慢,付得越少。把它和冲击公式对照着看:成交价 ≈ 中间价 × (1 冲击系数 × 订单量 ÷ 日均成交量)实操上常用一条规则:单次成交量不超过日均量的 5%。例如要买入 50 万股、日均量 100 万股,按 5% 参与率一天最多买 5 万股,OrderTWAP的TimeWindow就要拉到至少 10 个交易日。冲击系数怎么校准下图是项目自带的流动性预测思路:同一个流动性预测输出,同时驱动市场冲击估计、参与率约束和成交可行性判断。校准步骤:拉出标的池近 3–6 个月的日均成交量与波动率把历史大单按量级分桶,统计实际均价与理论中间价的差分桶拟合冲击系数,验证它与参与率大致呈线性或平方根关系把拟合结果替换进订单的execution_price,做前后对照回测回测批次设为多少合适长周期回测不能一次全跑。gs_quant/markets/portfolio_manager.py 的PortfolioManager.schedule_reports(months_per_batch6)支持把历史区间按月切成滑动窗口分批提交,参数 ≤0 会抛MqValueError。超过一年的区间建议每批 6 个月,既避免超时,也让大单的冲击分析更稳定。关键参数推荐值:参数作用推荐值months_per_batch每批历史回测的月数3–6 个月冲击系数(impact_factor)每 1% 量参与的价格不利偏移幅度0.01–0.05,按资产分桶校准参与率上限单笔订单量 ÷ 日均量≤5%TWAP 窗口长度订单拆分完成的总天数由参与率反推,通常 ≥2 天如何扩展自定义成本模型线性 TWAP 不够用时,子类化SimulatedExecutionEngine,把流动性模型注入进来:class LiquidityAwareEngine(SimulatedExecutionEngine): def __init__(self, data_handler, liquidity_model): super().__init__(data_handler) self.liquidity_model liquidity_model关键是保持submit_order/ping接口不变,这样上游的 gs_quant/backtests/generic_engine.py 完全不用改,构造时传入新类即可。落地建议马上可以做的两件事:先跑成本敏感性对照:给现有回测分别加 10bp / 50bp 的冲击,观察夏普比率和收益排序变化。如果前几名资产换位,说明原回测不可信。从 5% 参与率规则入手:先统计回测里大单超过日均量 5% 的比例,把超标的订单换成更长窗口的OrderTWAP,这一步比完整校准冲击模型更便宜、见效更快。延伸阅读回测教程与示例:gs_quant/documentation/04_backtesting/官方文档入口:docs/index.rst风险模型(配合做绩效归因):gs_quant/models/risk_model.py回测示例合集:gs_quant/content/Contents.ipynb【免费下载链接】gs-quantPython toolkit for quantitative finance项目地址: https://gitcode.com/GitHub_Trending/gs/gs-quant创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考