Chiến lược theo xu hướng chỉ mua BTCUSDT.BINANCE Perp 4H với mất cân bằng dòng mua/bán taker (3 tham số, đồng thuận dòng lệnh + xu hướng, tín hiệu tổng hợp thuần từ tick)

Chiến lược theo xu hướng chỉ mua một tài sản trên perp BTCUSDT.BINANCE sử dụng bar 4H, với tín hiệu định hướng được dẫn dắt bởi AGGREGATED TAKER ORDER FLOW (từ dữ liệu bổ sung trade_ticks) thay vì bởi các chỉ báo suy ra từ giá (đã được kiểm tra kỹ lưỡng và phần lớn thất bại về mặt thực nghiệm theo nhật ký bỏ qua của phiên này). Đây là lớp cơ chế thực sự NEW cho danh mục factory — mọi chiến lược trước đây tôi đã xem xét đều sử dụng tín hiệu suy ra từ OHLCV (mức giá, đường trung bình động, lợi nhuận, vol, tỷ lệ). Mất cân đối taker mua/taker bán là INFORMATIONALLY DISTINCT từ giá: nó đo lường WHO đang lấy thanh khoản (người mua chủ động so với người bán chủ động), mà tài liệu vi cấu trúc học thuật (Easley-Kiefer-O'Hara PIN 1996, Easley-Lopez-de Prado-O'Hara VPIN 2012) đã thiết lập là có tính dự báo nơi chỉ riêng giá thì không. Cơ chế: tại mỗi lần đóng bar 4H, tổng hợp các trade tick của bar thành taker_buy_volume so với taker_sell_volume, tính mất cân đối = (mua - bán) / (mua + bán). LONG khi mất cân đối 4H > +0.05 (taker mua liên tục) AND giá > 100-bar SMA (hội tụ xu hướng — dòng tiền phải đồng thuận với xu hướng). Thoát khi mất cân đối đảo chiều âm OR giá giảm xuống dưới SMA. Tín hiệu order-flow có hồ sơ thống kê cơ bản khác so với các tín hiệu momentum giá đã thất bại: chúng trực tiếp quan sát AGENT BEHAVIOR (bên nào sẵn sàng trả spread) thay vì hành vi tác nhân INFERRING từ giá (là hệ quả trễ của hành vi). Chỉ 3 tham số (thấp hơn nhiều so với trần 5 tham số). Tần suất giao dịch: ~40-80 giao dịch/năm qua 6+ năm dữ liệu trade tick Binance → tổng 240-480 giao dịch → 16-32 OOS giao dịch mỗi cửa sổ walk-forward, thoải mái trên ngưỡng 5 giao dịch. Đây cũng là INFRASTRUCTURE TEST quan trọng: nếu dữ liệu trade_ticks tải đúng vào pipeline factory (file data_specification.md liệt kê nó dưới catalog_data_types và cờ subscribe_trade_ticks tồn tại), điều này mở ra cả một lớp cơ chế mới cho nghiên cứu tương lai. Nếu nó không tải được (tương tự khoảng trống funding rate HL đã chặn các chiến lược 9), bản thân sự thất bại là có tính thông tin và làm nổi bật một ticket hạ tầng đáng ghi nhận.

Phản hồi yêu cầu một DIAGNOSTIC, chứ không phải đoán thêm một lược đồ. Tôi đã truy vấn trực tiếp data/supplementary/metrics/BTCUSDT/*.parquet: 334,643 dòng, cột taker_long_short_vol_ratio, dấu thời gian tính bằng ms; số dòng mỗi năm 2023=12,096 / 2024=16,990 / 2025=14,688, và tháng EVERY từ 2023-01 đến 2025-12 có >=288 dòng (liên tục, chỉ thưa so với dữ liệu 2020-2022 dày đặc mỗi 5 phút). Vì vậy điều kiện (3) 'không có dòng -> tạo phiếu yêu cầu' là sai, và tiền đề của điều kiện (2) về trình nạp không khớp lược đồ cũng sai (trình nạp của tôi đã đọc chính xác cột + khóa dấu thời gian này). Nguyên nhân gốc thực sự nằm ở đoạn mã phía sau của chính tôi: giới hạn độ cũ của _taker_imbalance là 24h. Tôi đã xác thực ngoại tuyến với kho parquet thực bằng cách quét các nến 4H tổng hợp trong 2023-2025: giới hạn 24h chỉ gắn tín hiệu taker cho 24.9% số nến (sau các điều kiện imbalance>0.05 và price>SMA, mức này giảm còn khoảng 2.79% mức phơi nhiễm như quan sát được), trong khi giới hạn 14 ngày gắn tín hiệu cho 95.3% — do đó mọi cửa sổ kiểm định cuốn chiếu 3 sẽ có giao dịch. Hàm _taker_imbalance vốn đã giữ lại tỷ lệ gần nhất tại hoặc trước đó khi cửa sổ 4h gần nhất trống; chỉ có giới hạn chặn nó, vì vậy cách sửa là một tham số duy nhất (max_lag_hours=336), với thay đổi ZERO đối với tín hiệu, logic vào/thoát lệnh hoặc định cỡ vị thế và NO cơ chế dự phòng bằng đại diện giá. Cách này giữ nguyên cơ chế dòng lệnh và cuối cùng giúp kiểm định được trên toàn bộ giai đoạn kiểm định ngược. Lưu ý cho chuyên viên phân tích: độ bao phủ taker 2023-2025 thực sự thưa hơn 2020-2022 (~12% mật độ mỗi 5 phút), do đó tín hiệu được giữ lại thô hơn trong những năm đó; việc bổ sung dữ liệu ngược metrics dày đặc mỗi 5 phút cho 2023-2025 sẽ cải thiện độ trung thực, nhưng chuỗi đủ liên tục từ tháng này sang tháng khác để kiểm định cuốn chiếu ngay bây giờ.

Sharpe giảm phồng (deflated Sharpe) thất bại với xác suất overfitting cực đoan ở lần thử 1. DSR=0.3175 (so với ngưỡng 0.95), is_significant=FALSE, với Sharpe tối ưu 1.9615 BELOW ngưỡng vận may kỳ vọng cực đại 225 lần thử là 2.3078, và — mang tính quyết định — PBO=0.8664 (xác suất 87% rằng việc chọn tham số bị overfit). Theo khung này, một DSR thấp kết hợp với PBO rất cao là tín hiệu từ bỏ mang tính quyết định. Walk-forward xác nhận điều đó: is_overfitted=TRUE với trung bình IS 3.91 sụp đổ xuống trung bình OOS 0.962 và các cửa sổ OOS [2.76, 1.32, -1.19] (một cửa sổ âm). Giá trị probabilistic_sharpe cao (0.9964) là cái bẫy cổ điển PSR-vs-DSR — nó bỏ qua việc chọn lọc 225 lần thử mà PBO/DSR trừng phạt. Các điểm tích cực thực sự (0 vách độ nhạy, sharpe_ci_low +0.4252 dương, tỷ lệ holdout hợp lệ đạt 1.213) đo lường sự ổn định cục bộ và một cửa sổ forward thuận lợi, không phải ý nghĩa thống kê, và không thể vượt qua một 87% PBO với Sharpe được chọn dưới ngưỡng vận may. Không lặp lại (lần thử 1 trên 2, đã là vòng lặp 3): độ nhạy đã sạch với 0 vách độ, nên quét đã khám phá hoàn toàn vùng ổn định nhưng OOS vẫn sụp đổ và PBO là 0.87 — overfitting nằm ở SELECTION walk-forward trên 225 lần thử, không phải ở một vách độ có thể sửa, và chỉ với 3 tham số cốt lõi, một quét best-of-225 lần thứ hai sẽ tìm lại các cấu hình overfit tương tự. Không revise_hypothesis: mất cân bằng dòng taker là một cơ chế thử nghiệm đầu tiên không có sibling được thăng cấp nào mắc kẹt trên một target đã chết, nên không có gì được chứng minh để chỉ lại vào một công cụ mới. Cảnh báo bổ sung (không phải nguyên nhân gốc được xác nhận): tín hiệu 'order flow' được suy ra từ chuỗi metrics thưa thớt taker_long_short_vol_ratio với carry-forward staleness 14 ngày thay vì trade ticks thô, nên trong các giai đoạn thưa thớt 2023-2025 nó có thể là một snapshot đơn lẻ được giữ về phía trước đến hai tuần — suy giảm thành một proxy cũ, thông tin thấp và làm suy yếu tiền đề 'khác biệt về mặt thông tin so với giá'; kết hợp với xu hướng BTC chỉ long trong một mẫu 6 năm thiên về bull (alpha cơ sở 0.02, benchmark_correlation 0.30), phần lớn lợi nhuận có thể là beta. FAILURE PATTERN: một cơ chế order-flow thực sự mới lạ với một profile bất thường sạch (0 vách độ nhạy, CI-low dương, một holdout đạt) vẫn có thể là một overfit best-of-225 — ở đây PBO 0.8664 với DSR 0.32 và một Sharpe tối ưu (1.96) dưới ngưỡng vận may 2.31, cộng với một walk-forward is_overfitted với cửa sổ âm OOS, là mang tính quyết định. Một lưới nhạy sạch và một cửa sổ holdout thuận lợi duy nhất NOT cứu một tối ưu hóa có lựa chọn 87% có khả năng bị overfit; tính mới lạ và ổn định cục bộ không phải là ý nghĩa thống kê.

Đừng NOT tối ưu hóa — tín hiệu dòng lệnh chủ động có một khoảng trống dữ liệu mang tính cấu trúc 2023-2025 (chỉ có giao dịch trong 2020-2022 và 2026; annual_returns bỏ qua 2023/2024/2025; exposure_pct 2.79%), nên quy trình walk-forward với cửa sổ 3 sẽ chạy suốt một cửa sổ trên dữ liệu bằng không và không thể xác thực lợi thế từ dòng lệnh. Thay đổi của bộ nạp chịu được sai khác lược đồ ở vòng lặp 2 đã không NOT khắc phục khoảng trống, vì vậy bước tiếp theo là chẩn đoán, không phải đoán thêm về lược đồ: (1) Truy vấn trực tiếp danh mục/cửa hàng dữ liệu bổ sung và xác nhận liệu các hàng khối lượng mua/bán chủ động của `metrics` (hoặc taker_long_short_vol_ratio) PHYSICALLY EXIST cho BTCUSDT 2023-01 đến 2025-12 hay không. In số lượng hàng và tên cột/khóa dấu thời gian thực tế cho một mẫu 2024. (2) Nếu các hàng tồn tại dưới một lược đồ khác nữa (tên cột hoặc khóa dấu thời gian mà bộ nạp của bạn vẫn chưa khớp), hãy mở rộng `_row_ratio`/`_row_ts`/`_load_taker_flow` để đọc chúng rồi chạy lại; xác nhận exposure_pct tăng và giao dịch được điền vào 2023-2025. (3) Nếu các hàng không NOT tồn tại (chuỗi chỉ số chủ động chưa từng được thu thập/bổ sung dữ liệu cho những năm đó), thì đây chính xác là vấn đề hạ tầng/thu thập dữ liệu như giả thuyết đã dự đoán — mã chiến lược không thể khắc phục, vì vậy hãy tạo phiếu yêu cầu thu thập dữ liệu cho các chỉ số dòng lệnh chủ động nhiều năm và DO NOT gửi lại chiến lược này để tối ưu hóa cho đến khi dữ liệu bao phủ toàn bộ giai đoạn kiểm thử ngược. Chỉ khi chuỗi dòng lệnh chủ động bao phủ liên tục 2020-2026 thì việc tối ưu hóa mới đáng thực hiện; cơ chế này có triển vọng nhưng hiện chưa thể kiểm thử.