标签：#quantitative

The last post was about making a number trustworthy. Leakage geometry, purge widths, de-overlap, a baseline that could not cheat. It ended with a minute-scale ceiling that held at 52% across seven configurations and a model family swap. This one is about what happens after you trust the number. Because a probability you are going to bet on is a different object from a probability you are going to report. The probabilities are not decorative The path-passage classifier is a three-class LightGBM. It returns p_up , p_down , p_none . Those go straight into the expected-value score that decides whether to take a trade and how big: long_score = p_up * ( B - C ) + p_down * ( - B - C ) + p_none * ( - C ) short_score = p_up * ( - B - C ) + p_down * ( B - C ) + p_none * ( - C ) B is the barrier, C the cost. Read the arithmetic. Every term is linear in a probability. Scale p_up by 1.2 and you scale the long score by very nearly 1.2. So miscalibration does not stay in the model. It becomes a bet-sizing error, in proportion, in the bins where the gate actually fires. A classifier that is right 70% of the time while claiming 90% is not 20 points wrong. It is sizing every position in that bin as though the edge were far larger than it is. Boosted trees are known for uncalibrated softmax output. I had been consuming it as if it were a probability. The audit Seven live assets. For each one, fit an Inductive Venn-Abers wrapper on the time-ordered older 80% of that model's training data, 6,988 rows, and evaluate against a 500-row uniform-random sample of the newer 20%, seed 42. The LightGBM models are reloaded from disk and left alone. Only the wrapper is fit. Measure Expected Calibration Error and log-loss, before and after. Asset ECE before → after ECE Δ Log-loss Δ BTC 0.1272 → 0.0621 -51.2% -5.5% ETH 0.1795 → 0.0298 -83.4% -11.5% SOL 0.1680 → 0.0386 -77.0% -10.6% XRP 0.2219 → 0.0645 -70.9% -17.7% ADA 0.1419 → 0.0369 -74.0% -8.0% LINK 0.1260 → 0.0737 -41.5% -1.2% LTC 0.1508 → 0.0603

A portfolio can look good on the usual scorecard and still answer the wrong question. One line says return was high. Another says risk-adjusted performance was acceptable. A third says drawdown stayed inside a tolerable range. Then the market turns, the benchmark starts recovering, and the thing I actually care about is different: how efficiently did the portfolio catch up? That is where a new metric can fool its own author. If I build a recovery measure and it moves almost exactly like an existing ratio, I have created a longer name for the same signal. The right acceptance test is geometric: a useful metric should cast a different shadow. This is the rule I used while validating Hyperlogarithmic Benchmark Catch-Up Ratio (HBCR): orthogonality to existing measures is a first-class test, not a chart for the appendix. 1. A new metric has to earn its axis HBCR was built to measure benchmark-relative recovery dynamics. The research page states the motivation plainly: traditional benchmark-relative metrics often fail to capture the true dynamics of investment performance, especially during market recoveries [ A New Metric for Private Equity Risk Adjusted Returns , Calibration of Risk and Correlation in Private Equity ]. That framing matters because the obvious validation path is tempting and weak. You compare the new number with familiar performance measures, find a comforting relationship, and declare victory. But a high correlation with a well-known score can be a warning. If HBCR strongly tracked Sharpe Ratio, it would probably be an expensive synonym for risk-adjusted return. The acceptance test I wanted was sharper. HBCR should have some relationship with performance, because recovery has economic content. It should also avoid collapsing into the same direction as Sharpe Ratio, Beta, Volatility, Alpha, Total Return, or Max Drawdown. Written as a predicate, the test has two sides. Let $\mathcal{T}$ be the set of metrics already on the scorecard, $\rho_{n,m}$ the corr

📈 多因子选股系统 — 项目功能介绍 观看地址: https://youtu.be/SpHsZdlyii8 面向 A 股市场的全链路量化分析平台 — 因子计算 · 机器学习 · 组合优化 · 回测验证 · 实时行情 指标 数据 Python 模块 108 业务代码 15,600+ 行 服务模块 30+ API 蓝图 14 内置因子 12 一、整体功能介绍 多因子选股系统是一个覆盖量化研究全流程的分析平台，从数据管理到策略回测一站式完成。系统采用 Flask + SQLAlchemy + SocketIO 技术栈，基于 Parquet + SQLite 双层存储架构，零外部数据库依赖，克隆即可运行。 核心能力总览 实时行情分析 ：通达信分钟数据接入，MACD、KDJ、RSI、布林带等技术指标实时计算 因子与选股 ：12 个内置因子 + 自定义因子表达式引擎，支持白名单安全校验 机器学习建模 ：XGBoost、LightGBM、RandomForest 三大算法的完整模型生命周期 组合优化 ：等权重、均值方差、风险平价、因子中性四种经典优化方法 回测验证 ：单策略与多策略回测，丰富的绩效指标（年化收益、夏普比率、最大回撤等） 风险管理 ：组合持仓管理、实时价格刷新、风险指标监控、预警管理、压力测试 请求流程 HTTP / WebSocket → Blueprint (app/api/*.py) → Service (app/services/*.py) → ParquetDataReader (行情数据) ↕ SQLAlchemy Models (SQLite 应用状态) 技术栈 类别 技术 后端框架 Python 3.8–3.11、Flask、Flask-SocketIO、Flask-SQLAlchemy、Celery 数据处理 Pandas、NumPy、PyArrow、SciPy、Scikit-learn 机器学习 XGBoost、LightGBM、RandomForest、CVXPY 前端 & 可视化 Bootstrap 5、ECharts、Plotly、Matplotlib / MPLFinance 数据源 通达信（实时行情）、Baostock（历史数据）、Tushare（可选）、Parquet 离线数据包 AI 能力 Ollama（本地 LLM）、OpenAI API（可选）、Text2SQL、Qwen2.5-Coder 二、各模块功能介绍 2.1 实时行情分析模块 API 蓝图前缀 ： /api/realtime-analysis/* 核心服务 ： RealtimeIndicatorEngine （ services/realtime_indicator_engine.py ）：实时技术指标计算 RealtimeTradingSignalEngine （ services/realtime_trading_signal_engine.py ）：多策略交易信号生成与融合 功能特性 ： 功能 说明 实时指标计算 支持 MACD、KDJ、RSI、布林带等经典技术指标的实时计算与展示 多策略信号生成 基于不同策略的交易信号生成，支持信号融合与综合研判 信号监控 交易信号的实时监控与历史回溯 策略回测 对生成的信号进行历史回测验证 板块分析 板块表现统计与异动检测 市场情绪 市场情绪指标的实时追踪 数据源 ：通达信分钟级行情数据，存储于 data/stock_minute/ （Parquet 格式）。 2.2 因子与选股模块 API 蓝图前缀 ： /api/ml-factor/* 、 /api 核心服务 ： FactorEngine （ services/factor_engine.py ）：内置因子计算与自定义因子管理 FactorExpressionEngine （ services/factor_expression_engine.py ）：白名单校验的自定义因子公式引擎 StockScoringEngine （ services/stock_scoring.py ）：因子评分与 ML 评分的综合选股引擎 内置因子（12 个） 维度 因子名 说明 动量 momentum_1d 1 日动量 动量 momentum_5d 5 日动量 动量 momentum_20d 20 日动量 波动率 volatility_20d 20 日波动率 技术指标 rsi_14 RSI 相对强弱 技术指标 turnover_rate 换手率 基本面 pe_ratio 市盈率 基本面 pb_ratio 市净率 基本面 roe 净资产收益率 基本面 debt_ratio 资产负债率 基本面 current_ratio 流动比率 基本面 gross_mar