Lời khuyên phổ biến là: muốn backtest trung thực thì hãy lấy dữ liệu tick. Tôi cho rằng lời khuyên đó không đúng với phần lớn chiến lược, và làm theo thường khiến backtest tệ hơn chứ không tốt hơn. Không phải vì dữ liệu tick thiếu chính xác — đây là loại dữ liệu chính xác nhất bạn có thể lấy — mà vì cách phần lớn mọi người sử dụng nó đánh đồng độ phân giải với sự chặt chẽ, trong khi hai điều đó không giống nhau.
Đây là tình huống thường gặp. Một nhà nghiên cứu xây dựng chiến lược trên các nến 1 phút, đạt Sharpe mà họ hài lòng, rồi có người — người cố vấn, bài đăng trên diễn đàn, hay chính nỗi băn khoăn dai dẳng của họ — bảo rằng backtest không trung thực vì dựa trên nến. Thế là họ xây dựng lại toàn bộ quy trình bằng dữ liệu tick: từng giao dịch, từng lần cập nhật báo giá, đóng dấu thời gian đến micro giây. Backtest chạy chậm hơn, mã phức tạp gấp 3 lần, còn Sharpe... gần như không đổi, hoặc thay đổi theo hướng chẳng ai giải thích được. Dù vậy, họ vẫn triển khai vì dữ liệu tick tạo cảm giác chặt chẽ hơn, mà cảm giác chặt chẽ không đồng nghĩa với sự chặt chẽ thực sự.
Độ phân giải tick thực sự mang lại điều gì
Dữ liệu tick cho bạn biết trình tự và mức giá của mọi giao dịch, và (nếu trả phí) mọi lần cập nhật sổ lệnh. Đó là thông tin có giá trị. Nhờ nó, bạn có thể tái dựng vị trí trong hàng đợi, ước tính xác suất khớp ở một mức giá nhất định và nhận diện lựa chọn bất lợi — liệu thị trường có đi ngược hướng ngay sau khi lệnh giả định của bạn được khớp hay không. Tất cả những điều này cực kỳ quan trọng nếu thời gian nắm giữ của bạn tính bằng giây và lợi thế chỉ bằng một phần của tick.
Nhưng phần lớn chiến lược chúng tôi thấy tại Stratmill — cũng như phần lớn chiến lược mà các nhà nghiên cứu cá nhân và bán chuyên thực sự triển khai — giữ vị thế từ vài phút đến vài ngày. Với khung thời gian đó, điều quyết định backtest có trung thực hay không không phải là bạn có mô hình hóa giao dịch thứ 40 trong một phút cụ thể hay không. Mà là bạn có mô hình hóa chênh lệch giá mua bán, tỷ lệ funding, đường cong trượt giá, và thực tế rằng lệnh giới hạn của bạn phải xếp sau lệnh của người khác hay không. Bạn có thể mô hình hóa sai cả 4 yếu tố này bằng dữ liệu tick, nhưng lại mô hình hóa đúng cả 4 với nến 1 phút. Độ phân giải và tính trung thực là hai khía cạnh độc lập.
Đây là con số cuối cùng mà mọi người thường đánh giá thấp. Backtest cấp tick không đơn giản là "cùng một backtest nhưng có nhiều dòng dữ liệu hơn". Giao dịch trên hầu hết sàn thường đến không đúng thứ tự so với thời điểm hệ thống của bạn ghi nhận, được đính chính hồi tố, bị phân tán qua nhiều phân vùng của bộ khớp lệnh — và tại một số sàn chúng tôi đã lấy dữ liệu, đôi khi còn bị trùng lặp hoặc mất hẳn khi kết nối lại. Xây dựng một quy trình tick thực sự chính xác hơn quy trình nến được làm tốt, chứ không chỉ chi tiết hơn, là một dự án hệ thống thực thụ. Hầu hết các nhóm không thực hiện dự án đó. Họ đưa tệp tick của nhà cung cấp vào bộ backtest rồi coi như xong; như vậy, họ đã đổi một tập hợp các phép gần đúng đã biết và được ghi chép rõ ràng (OHLCV) lấy một tập hợp chưa biết và không được ghi chép (bất cứ logic đối soát tick nào mà nhà cung cấp sử dụng vào ngày có sự cố).
Thứ nhiễu mà bạn phải trả giá để có
Còn một chi phí thứ hai, ít liên quan đến kỹ thuật hơn mà liên quan nhiều hơn đến thống kê. Các giao dịch riêng lẻ dao động qua lại giữa giá mua và giá bán — đó là hiện tượng nảy giá mua bán, một sai lệch đã được biết đến trong tài liệu về vi cấu trúc thị trường từ những năm 1980. Nếu tín hiệu của bạn hoạt động nhanh hơn vài giây, backtest cấp tick có thể khiến bạn nhìn thấy cấu trúc trong thứ thực chất chỉ là hiện tượng nảy giá. Tôi từng thấy một nhà nghiên cứu phát hiện mẫu hồi quy về trung bình tuyệt đẹp trên dữ liệu từng giao dịch, nhưng mẫu đó biến mất ngay khi họ gộp dữ liệu thành nến thậm chí chỉ 5 giây, vì thứ họ thấy chỉ là hiện tượng nảy giá.
Một nhà giao dịch định lượng tôi quen — từng làm tạo lập thị trường, giờ vận hành một danh mục tiền mã hóa nhỏ — nói với tôi thế này: "Dữ liệu tick là kính lúp. Chĩa nó vào lợi thế của bạn thì tốt. Chĩa vào nhiễu của bạn, bạn sẽ mất 6 tháng để mô hình hóa nhiễu thật đẹp." Giờ đây, anh ấy backtest gần như mọi thứ bằng nến 1 giây hoặc 1 phút, và chỉ dùng dữ liệu tick cho câu hỏi cụ thể "lệnh giới hạn này có thực sự được khớp không", vốn là câu hỏi về xác suất khớp lệnh chứ không phải câu hỏi về tín hiệu.
Đó là cách phân chia hợp lý, và cũng là điều mà phần lớn người ủng hộ dữ liệu tick bỏ qua. Cách dùng dữ liệu tick trung thực không phải là chạy toàn bộ chiến lược bằng nó — mà là sử dụng có chọn lọc, để trả lời 1 hoặc 2 câu hỏi mà dữ liệu nến thực sự không thể giải đáp.
Khi những người phản đối nói đúng
Dù vậy, có những chiến lược bắt buộc phải dùng dữ liệu tick, và giả vờ như không phải vậy sẽ là nói quá. Nếu bạn đang làm một việc giống tạo lập thị trường — đặt báo giá ở cả 2 phía, quản lý tồn kho theo từng tick, quan tâm đến vị trí trong hàng đợi ở một mức giá cụ thể — dữ liệu nến hoàn toàn không thể mô tả vấn đề của bạn. Toàn bộ bài toán kinh tế của chiến lược đó nằm bên trong từng phút, chứ không phải giữa các phút. Điều tương tự cũng đúng với chênh lệch giá thống kê nhạy với độ trễ giữa các sàn, nơi câu hỏi thực sự là "giao dịch nào xảy ra trước", và với hoạt động tạo lập thị trường quyền chọn ở quy mô lớn, nơi vài trăm mili giây lựa chọn bất lợi sau một giao dịch chính là toàn bộ cuộc chơi. Trong những trường hợp đó, backtest bằng nến không phải là đơn giản hóa mà là sai ngay từ loại bài toán — bạn không kiểm tra một phiên bản có độ phân giải thấp hơn của chiến lược mình, mà đang kiểm tra một chiến lược khác chỉ tình cờ có cùng tên với chiến lược thật.
| Khung thời gian chiến lược | Dữ liệu nến bỏ sót điều gì | Có cần dữ liệu tick? |
|---|---|---|
| Tạo lập thị trường / dựa trên hàng đợi | Xác suất khớp lệnh, lựa chọn bất lợi, vị trí trong hàng đợi | Có — bắt buộc |
| Độ trễ / kinh doanh chênh lệch giá giữa các sàn | Trình tự giao dịch, sàn nào biến động trước | Có |
| Động lượng trong ngày, hồi quy về trung bình (phút–giờ) | Thời điểm khớp lệnh trong nến, chi phí chênh lệch giá mua bán | Chỉ để trả lời câu hỏi về xác suất khớp lệnh, không phải về tín hiệu |
| Giao dịch theo xu hướng / nhiều ngày, quyền chọn theo hướng giá | Hầu như không có gì đáng kể | Không — dữ liệu nến là đủ và thường còn rõ ràng hơn |
Vì vậy, điều tôi muốn nói không phải là "dữ liệu tick có hại". Mà là việc tìm đến nó thường giúp né tránh một câu hỏi khó hơn và kém hào nhoáng hơn: mô hình chi phí của tôi có đúng không? Giả định về khớp lệnh của tôi có đúng không? Lệnh này có thực sự được khớp không, hay tôi đang giả định rằng lệnh khớp ở mức giá mà sổ lệnh chưa bao giờ thực sự đưa ra? Nếu trung thực về vị trí trong hàng đợi và chênh lệch giá mua bán, bạn có thể trả lời những câu hỏi đó bằng nến 1 phút, thậm chí 1 giây. Dữ liệu tick giúp trả lời chính xác hơn, với chi phí kỹ thuật cao gấp vài lần, trong những chiến lược mà mức chính xác tăng thêm chẳng làm thay đổi kết luận. Hãy dành công sức đó cho những khung thời gian thực sự đòi hỏi nó và bỏ qua ở mọi trường hợp khác — như vậy nhóm nghiên cứu sẽ sử dụng thời gian hiệu quả hơn là mặc định chọn dữ liệu chi tiết nhất hiện có chỉ vì độ chi tiết cao tạo cảm giác chặt chẽ hơn.
← Tất cả bài viết


