OptiNod Academy
Backtest và giao dịch thực tế — Tìm nguyên nhân từ giao dịch lệch đầu tiên
Cố định cùng mã nguồn, dữ liệu và thiết lập, rồi đối chiếu từng giao dịch để tìm chênh lệch ở tín hiệu, khớp lệnh hay chi phí.
Trước khi so hai đường vốn, hãy bảo đảm bạn đang so cùng chiến lược, thị trường và giai đoạn. Điểm bắt đầu hữu ích nhất là giao dịch lệch đầu tiên.
Hai bản mang cùng tên chiến lược vẫn có thể dùng mã nguồn, tham số, sàn hoặc loại hợp đồng khác nhau. Không thể giải thích mọi chênh lệch bằng trượt giá. Trước hết, lưu đúng phiên bản mã và toàn bộ đầu vào; thống nhất mã giao dịch đầy đủ, sàn, giao ngay hay hợp đồng vĩnh cửu, nến thông thường, khung thời gian, phiên, lịch sử đã nạp và thời điểm bắt đầu–kết thúc kiểm chứng.
Tiếp theo, ghi vốn ban đầu, tiền tệ tài khoản, đơn vị khối lượng, cách tái đầu tư hay dùng khối lượng cố định, số lần vào thêm vị thế, phí, trượt giá và tùy chọn tính toán–xử lý lệnh. Cùng khoảng ngày nhưng khác dữ liệu khởi tạo chỉ báo trước ngày bắt đầu cũng có thể làm tín hiệu đầu tiên khác nhau. Giờ hiển thị trên biểu đồ và giờ phiên của sàn cũng cần được phân biệt.
Backtest mô phỏng giao dịch theo những điều kiện đó. Giao dịch thực tế còn có quá trình truyền tín hiệu, gửi lệnh và khớp lệnh. Khi kết quả lệch, hãy đi lần lượt từ tín hiệu đến lệnh, giá khớp và chi phí. Chênh lệch có thể theo cả hai hướng; điều cần tìm là bằng chứng giải thích được từng giao dịch.
Một hồ sơ so sánh cần có bản mã nguồn đã lưu và mọi tham số, nhà cung cấp dữ liệu, mã giao dịch đầy đủ kèm sàn và hợp đồng, loại nến, khung thời gian, phiên, phạm vi lịch sử và thời gian kiểm chứng. Với hợp đồng phái sinh, cần cả hệ số hợp đồng và đơn vị khối lượng. Hai sản phẩm có tên gần giống nhau không nhất thiết có cùng chuỗi giá.
Điều kiện vốn cũng phải thống nhất. Lệnh tính theo phần trăm vốn, khối lượng tài sản hay giá trị danh nghĩa cố định sẽ tạo ra mức rủi ro và chi phí khác nhau. Khi đối chiếu, ghép các lần khớp một phần, đóng một phần và đảo vị thế vào đúng giao dịch thay vì chỉ so tổng số dòng của hai tệp.
TradingView cho phép thiết lập riêng khối lượng lệnh, phí, trượt giá và cách tính lại. Dùng nến thông thường làm mốc so sánh; giá tổng hợp của Heikin Ashi hoặc Renko không tự động là mức giá có thể giao dịch thật. Xem các thuộc tính chiến lược và dữ liệu biểu đồ không tiêu chuẩn để kiểm tra các giả định.
Điều kiện bắt đầu kiểm chứng: Xuất danh sách giao dịch từ cùng bản mã, tham số, mã thị trường và khoảng thời gian, rồi chọn giao dịch lệch đầu tiên. Ghép các lần khớp bằng mã lệnh và khối lượng. Nếu phát hiện điều kiện gốc khác nhau, dừng kết luận nguyên nhân lợi nhuận và chạy lại sau khi đã đồng nhất.
Tách thời điểm tính tín hiệu khỏi thời điểm khớp lệnh
Theo thiết lập mặc định, chiến lược TradingView tính khi nến đóng. Lệnh thị trường được tạo lúc đó có thể khớp mô phỏng sớm nhất ở tick tiếp theo; trong dữ liệu lịch sử, thời điểm này thường là giá mở cửa nến sau. Mặc định không phải khớp tại giá đóng cửa nến tín hiệu. “Nến sau” cũng không có nghĩa là chờ hết thêm một nến mới gửi lệnh. Cơ chế tạo và thực hiện lệnh của TradingView
process_orders_on_close là tùy chọn cho phép xử lý lệnh tại lúc nến đóng trong mô phỏng. Chỉ việc bật tùy chọn này chưa đủ để kết luận có look-ahead bias. Tuy nhiên, một cảnh báo được gửi sau khi nến đóng có khớp được đúng mức giá ấy ngoài thị trường hay không lại cần kiểm tra riêng. Phiên đóng cửa, độ trễ truyền tin và thời điểm sàn nhận lệnh đều có ảnh hưởng. Giải thích tùy chọn xử lý lệnh
Khi đối chiếu, lưu riêng thời điểm điều kiện trở thành đúng, cảnh báo được gửi, sàn nhận lệnh và từng lần khớp. Lệnh giới hạn hoặc lệnh dừng có thể được kích hoạt giữa nến, nên không cần ép mọi loại lệnh về giá mở cửa nến tiếp theo. Hãy kiểm tra đúng loại lệnh và thời điểm nó bắt đầu có hiệu lực.
Thiết lập so sánh — Dùng nến 15 phút thông thường, chỉ so tín hiệu đã xác nhận lúc đóng nến và ghi lệnh thị trường theo bộ mô phỏng mặc định. Điểm vào là lần khớp khả dụng đầu tiên sau tín hiệu; dừng lỗ cố định dưới đáy nến tín hiệu tại mức đã định trước. Đây không phải khuyến nghị giao dịch. Loại khỏi so sánh chất lượng khớp các giao dịch khác thời điểm tín hiệu, khối lượng hoặc quy tắc dừng lỗ.
Đo trượt giá bằng cùng giá tham chiếu và cùng điều kiện lệnh
Muốn đo trượt giá, trước hết cần chỉ rõ giá tham chiếu. Giá đóng cửa lúc có tín hiệu, giá chào lúc gửi lệnh và giá chào lúc sàn nhận lệnh bao gồm những khoảng trễ khác nhau. So giá khớp bình quân với mốc đã chọn, rồi quy ước cùng chiều bất lợi cho lệnh mua và bán. Cũng có trường hợp giá khớp tốt hơn mốc tham chiếu.
Cùng giá trị lệnh nhưng độ sâu sổ lệnh, chênh lệch mua–bán, loại lệnh và thời điểm giao dịch có thể làm kết quả khác nhau. Nếu bỏ các lệnh giới hạn không khớp khỏi mẫu, bạn chỉ còn quan sát những lệnh đã thực hiện được. Vì vậy, lưu cả khối lượng yêu cầu, khối lượng khớp, phần chưa khớp và việc hủy lệnh.
Không có một mức bp tối thiểu phù hợp cho mọi thị trường. Dùng quan sát từ đúng sản phẩm, quy mô và loại lệnh để xây dựng kịch bản thông thường và bất lợi, rồi tính lại kết quả theo các mức chi phí đó. Thiết lập trượt giá cố định của TradingView dùng đơn vị tick và không mô phỏng vị trí xếp hàng trong sổ lệnh. Trượt giá và lệnh giới hạn chưa khớp
Phí giao dịch theo giá trị mua bán, funding theo vị thế tại kỳ thanh toán
Phí phải dựa trên biểu phí thực tế, phân loại maker–taker, giảm phí, hoàn phí và đặc tả hợp đồng. “Phí khứ hồi 0,1%” không có nghĩa là “mất 0,1% vốn tài khoản”. Không thể chỉ lấy số giao dịch nhân với một tỷ lệ rồi coi đó là phần trăm vốn bị mất.
Ví dụ giả định để giải thích: giá trị mở và đóng vị thế đều là 1.000 USD, phí mỗi lần khớp là 0,05%, nên phí khứ hồi là 1 USD. Lặp lại cùng giao dịch 100 lần thì phí là 100 USD. Tỷ lệ so với vốn phụ thuộc vốn và khối lượng. Không lấy số giao dịch nhân tỷ lệ phí khứ hồi rồi trừ thẳng khỏi lợi suất tài khoản.
Funding của hợp đồng vĩnh cửu phụ thuộc giá trị vị thế tại thời điểm thanh toán, dấu của tỷ lệ và chiều long–short. Nó có thể là khoản trả hoặc nhận, không tỷ lệ trực tiếp với số lần giao dịch. Khoảng cách giữa các kỳ cũng khác theo sản phẩm và có thể thay đổi; không mặc định luôn là tám giờ. Dùng lịch sử tỷ lệ và quy tắc của đúng hợp đồng. Kiểm tra chi phí giao dịch
Ghép phép tính với sao kê phí và funding của tài khoản. Đồng thời kiểm tra xem có trừ hai lần một chênh lệch vốn đã nằm trong giá khớp hay không. Sau khi cập nhật chi phí, cần đánh giá lại kết quả trên dữ liệu; việc mô hình hóa chi phí không tự bảo đảm chiến lược còn có lợi nhuận.
Nến chạm cả chốt lời và dừng lỗ cần được kiểm tra đường đi bên trong
OHLC cho biết giá mở, cao, thấp và đóng, nhưng không chứa thứ tự của mọi tick. Nếu cả lệnh chốt lời lẫn dừng lỗ đã có hiệu lực và cùng một nến chạm cả hai, kết quả phụ thuộc điều kiện nào có thể thực hiện trước. Giá từng chạm một mức trước lúc lệnh tồn tại không chứng minh rằng lệnh đó đã khớp.
Ví dụ giả định: vị thế long vào tại 100, dừng lỗ 98 và chốt lời 103. Chỉ biết nến có đỉnh 104 và đáy 97 chưa cho biết lệnh thoát nào xảy ra trước.
Bộ mô phỏng của TradingView mặc định suy ra đường đi bên trong nến từ vị trí giá mở cửa so với giá cao và thấp. Nó không áp dụng quy tắc “luôn xử lý dừng lỗ trước”. Bar Magnifier dùng dữ liệu khung thấp hơn nếu có để cải thiện ước tính, nhưng không khôi phục toàn bộ tick, hàng đợi, độ sâu sổ lệnh hay độ trễ thực tế. Bộ mô phỏng môi giới của TradingView
Lọc riêng các giao dịch chạm cả hai mức, kiểm tra thời điểm lệnh có hiệu lực, rồi so kết quả với dữ liệu khung thấp trong phần lịch sử có đủ dữ liệu. Nếu kết quả đổi nhiều, chiến lược nhạy với giả định đường đi trong nến. Với khoảng thiếu dữ liệu, giữ rõ giới hạn ấy thay vì gọi một trong hai kết quả mô phỏng là khớp lệnh thực tế.
Dữ liệu quá khứ cũng có ranh giới thông tin tại từng thời điểm
Nếu đánh giá việc chọn tài sản trong quá khứ bằng danh sách hiện còn giao dịch, các tài sản đã hủy niêm yết có thể bị bỏ qua và tạo thiên lệch sống sót. Với chiến lược chọn trong một tập tài sản, cần phục dựng tiêu chí lựa chọn và tình trạng niêm yết tại thời điểm đó. Dữ liệu bị thiếu cũng không nên tự động được hiểu là giai đoạn lợi nhuận bằng không.
Look-ahead bias xuất hiện khi quyết định quá khứ dùng thông tin chưa có tại lúc quyết định. Hãy kiểm tra xem giá trị cuối cùng của nến khung lớn có bị đưa về trước thời điểm xác nhận, hoặc thống kê từ toàn bộ giai đoạn kiểm chứng có bị dùng để ra quyết định ở đầu giai đoạn hay không. Giá hiện tại của nến đang chạy thay đổi không tự nó là nhìn trước tương lai. Nếu chiến lược chỉ dùng dữ liệu xác nhận, phải thiết kế đúng thời điểm từng đầu vào trở thành xác nhận. Các dạng repainting
Nhà cung cấp sửa giá hoặc bổ sung lịch sử cũng có thể thay đổi kết quả tính lại. Lưu thời điểm lấy dữ liệu và thời điểm so sánh giúp phân biệt thay đổi dữ liệu, phiên bản mã và điều kiện tính toán.
Dùng triệu chứng để chọn bằng chứng cần đối chiếu
| Triệu chứng | Nguyên nhân có thể | Phép kiểm tra hoặc bằng chứng | Giới hạn kết luận |
|---|---|---|---|
| Nến phát tín hiệu đã khác | Khác mã, tham số, thị trường, lịch sử hoặc xác nhận HTF | Bản điều kiện đã lưu cùng đầu vào và tín hiệu ở một thời điểm | CSV giao dịch không chứng minh tín hiệu tồn tại realtime lúc nào |
| Tín hiệu giống nhưng giá khớp khác | Thời điểm lệnh, độ trễ, spread, trượt giá | Thời điểm gửi–nhận, giá chào, mã lệnh và giá khớp bình quân | Không có sổ lệnh lúc đó thì khó tách hết từng ảnh hưởng |
| Kết quả chốt lời và dừng lỗ đảo ngược | Đường đi trong nến, hiệu lực lệnh, lệnh giới hạn chưa khớp | Khung thấp, lịch sử lệnh và so sánh Bar Magnifier | Khung thấp không khôi phục sổ lệnh hay hàng đợi |
| Giao dịch khớp nhau nhưng lãi ròng khác | Khối lượng, hệ số hợp đồng, phí, funding, quy đổi | Tính lại từng giá trị khớp và dòng phí | Còn phải kiểm tra làm tròn và tiền tệ thanh toán |
| Chỉ giao dịch thực tế bị thiếu lệnh | Mất cảnh báo, lệnh bị từ chối, khối lượng tối thiểu, chưa khớp, giới hạn vị thế | ID cảnh báo và lệnh, lý do từ chối, khối lượng yêu cầu–đã khớp–còn lại và số dư khả dụng | Cảnh báo gửi thành công hoặc API tiếp nhận lệnh chưa chứng minh lệnh đã khớp |
| Tín hiệu đổi sau khi tải lại | HTF chưa đóng, tính giữa nến, vẽ lùi, dữ liệu sửa | Bản ghi quan sát trước đó so với cùng đoạn sau tải lại | Chỉ thấy khác chưa đủ kết luận rò rỉ tương lai |
| Chỉ giai đoạn tối ưu hóa có kết quả tốt | Chọn lặp lại, điều kiện riêng của giai đoạn, rò rỉ dữ liệu | Lưu các cấu hình đã thử và tiêu chí chọn; đánh giá cùng quy trình trên giai đoạn riêng | Kết quả giảm chưa đủ kết luận quá khớp hoặc repainting |
Chọn một nguyên nhân rồi thay một điều kiện, giữ các điều kiện còn lại để quan sát chính giao dịch ấy thay đổi ra sao. Nếu sửa phí mà vị trí tín hiệu cũng đổi, kiểm tra các quan hệ ngược như quy mô lệnh phụ thuộc vốn tài khoản. Sửa mọi thứ cùng lúc sẽ làm mất dấu nguyên nhân.
Chỉ đổi điều kiện đã chọn rồi so lại cùng giao dịch lệch đầu tiên. Khi thiếu bằng chứng, để nguyên nhân chưa rõ và thu thập bản ghi cần thiết ở lần quan sát tiếp theo. Phân tích walk-forward giải thích cách kiểm chứng lựa chọn lặp lại. Kết quả kém hơn ở giai đoạn sau chưa xác định được nguyên nhân.
Thêm bản ghi realtime vào việc so danh sách giao dịch
Khi so TradingView với một bộ máy khác, xuất danh sách cùng điều kiện rồi ghép theo thời điểm vào–thoát, chiều, khối lượng và giá. Xác định giao dịch bắt đầu lệch hữu ích hơn việc chỉ thấy tổng lợi nhuận giống nhau. Hai danh sách trùng nhau cũng vẫn có thể đang dùng chung một giả định sai.
CSV và Bar Replay giúp kiểm tra tính toán lịch sử, nhưng không tự chứng minh một tín hiệu đã tồn tại trong realtime. Lưu trước phiên bản mã, tham số, cấu hình cảnh báo, ảnh hoặc giá trị có thời gian, cùng nhật ký gửi lệnh và khớp lệnh. Sau giai đoạn quan sát, tải lại cùng đoạn với cùng điều kiện và đối chiếu. Phần thiếu trong bản ghi cũ cần được bổ sung bằng lần quan sát tiếp theo.
Khi chưa giải thích được chênh lệch, tiếp tục chỉnh tham số cho đường vốn đẹp có thể che mất vấn đề. Quay lại giao dịch lệch đầu tiên, xác định thông tin và lệnh nào thực sự tồn tại vào lúc đó. Từ bằng chứng ấy, bạn mới biết phần nào của kết quả quá khứ đã được kiểm chứng và phần nào vẫn chưa rõ.
Để thêm chiến lược và khớp chi phí, thời gian, hãy làm theo ví dụ đã chạy trong hướng dẫn backtest TradingView.