Trả lời ngắn: Adaptive Position Sizing trong EA là quy trình điều chỉnh khối lượng ứng viên theo một bộ đầu vào và giới hạn đã khai báo trước. Nó tính sức chịu lỗ, chuẩn hóa theo quy tắc symbol, áp trần phơi nhiễm rồi kiểm tra tài khoản; không tự tăng lot vì vừa thua hoặc vì tín hiệu có vẻ “chắc”.

Đọc xong, bạn sẽ hiểu: cách đi từ equity đến một candidate size; vì sao phải làm tròn xuống; Money Management, Risk và Execution chia việc ra sao; và lúc nào EA phải ALLOW, REDUCE, BLOCK hoặc RECHECK.

Lưu ý giáo dục: toàn bộ số liệu A18 dùng đơn vị giả U. Đây là bài học kiến trúc, không phải mức rủi ro, khối lượng hay thiết lập giao dịch được khuyến nghị.

1. Adaptive sizing là điều chỉnh có giới hạn, không tăng lot sau lỗ

a. Thứ được điều chỉnh chỉ là ứng viên

Khối lượng ứng viên (candidate size) là con số được đề xuất để các cổng phía sau kiểm tra. Nó chưa phải lệnh, chưa được phép gửi và chắc chắn chưa phải bằng chứng đã khớp.

Chữ “adaptive” không có nghĩa là tăng khối lượng khi cơ hội có vẻ đẹp. EA dùng ảnh chụp đầu vào đã đóng băng, tính theo quy tắc có trước, rồi giữ nguyên hoặc giảm khi biến động, thanh khoản hay phơi nhiễm xấu đi.

Hãy hình dung một xe tải chuẩn bị qua cầu. Kho hàng đề xuất chở hai tấn, nhưng cầu chỉ cho phép 1,5 tấn. Con số hai tấn không có quyền vượt biển giới hạn; hàng phải giảm trước khi xe đi. Khối lượng ứng viên cũng vậy.

b. Ba owner, ba quyền khác nhau

Money Management tính ứng viên từ ngân sách rủi ro và mức lỗ tiền tệ trên một đơn vị khối lượng. Risk Engine xem tổng phơi nhiễm, giới hạn tài khoản và điều kiện cấm. Execution Engine chuẩn hóa volume, kiểm tra tính hợp lệ, gửi request và theo dõi bằng chứng giao dịch.

Quyền phải đi một chiều:

  • Money Management được đề xuất.
  • Risk Engine được giảm hoặc chặn, không được âm thầm tăng.
  • Execution được chuẩn hóa và kiểm tra, không được biến 0.20 thành 0.30 vì tiện làm tròn.

Chuỗi thua, khoản lỗ “cần gỡ” hay điểm tự tin không được dùng để tăng risk. Đó là đổi chính sách phơi nhiễm, không phải adaptive sizing.

2. Pipeline A18: từ ngân sách 30 U đến ứng viên 0.20 lot

a. Đóng băng đầu vào trước khi tính

Pipeline của A18 là:

EQUITY SNAPSHOT → BASE RISK BUDGET → ADAPTIVE FACTORS → LOSS/UNIT → RAW SIZE → FLOOR TO STEP → PORTFOLIO/LIQUIDITY CAPS → ORDERCHECK → CANDIDATE

Snapshot là bộ đầu vào tại cùng thời điểm logic; version là danh tính của nó. A18 dùng A18:SNAPSHOT:V1. Dữ liệu quan trọng đổi thì tạo V2, không sửa V1 khi request cũ còn xử lý.

Hình 1 — Khối lượng chỉ là ứng viên sau chuỗi tính toán và vẫn chưa phải bằng chứng thực thi.

b. Từng phép tính của A18

Equity giả là 10,000 U. Chính sách demo đặt tỷ lệ cơ sở 0.50%, nên:

10,000 × 0.005 = 50 U

50 U là ngân sách rủi ro cơ sở trong kịch bản tính, không bảo đảm lỗ thực tế dừng đúng số này. Hệ số biến động bằng 0.60:

50 × 0.60 = 30 U

Bước tiếp theo cần mức lỗ tiền tệ trên một đơn vị. Với hướng, giá mở giả và giá dừng giả của A18, OrderCalcProfit() ước tính một lot sẽ lỗ 120 U. Hàm này trả ước tính bằng tiền tệ tài khoản trong môi trường giao dịch hiện tại. MQL5 OrderCalcProfit

Ứng viên thô:

30 ÷ 120 = 0.25 lot

Symbol demo có minimum 0.10, maximum 2.00, step 0.10; terminal cũng cung cấp SYMBOL_VOLUME_LIMIT. MQL5 Symbol properties

0.25 không nằm trên lưới step 0.10. EA phải floor, tức làm tròn xuống, thành 0.20 lot. Làm tròn lên 0.30 sẽ làm mức lỗ dự kiến vượt ngân sách 30 U.

Hình 2 — A18 làm tròn xuống theo bước khối lượng thay vì làm tròn lên.

c. 0.20 vẫn chưa phải ALLOW

Trần phơi nhiễm/thanh khoản của A18 là 0.20 lot, nên ứng viên sau cap vẫn là 0.20. Nhưng snapshot không có bằng chứng margin đáng tin cậy. Kết quả cuối phải là RECHECK, số request mới bằng 0.

Phép tính đúng không bù được dữ liệu thiếu. OrderCheck() kiểm tra tham số và ước tính trạng thái margin sau giao dịch, nhưng thành công vẫn không bảo đảm request được thực thi. MQL5 OrderCheck

3. Năm lớp bằng chứng và bốn trạng thái quyết định

a. Năm lớp phải cùng hợp lệ

Lớp 1 — độ mới. Equity, giá, spread, thanh khoản và vị thế phải có timestamp phù hợp. AccountInfoDouble() đọc equity và các số liệu margin; contract vẫn phải định nghĩa “quá cũ”. MQL5 AccountInfoDouble

Lớp 2 — mức lỗ trên một đơn vị. Khoảng cách points chưa đủ; giá trị tiền còn phụ thuộc symbol, contract, hướng và tiền tệ tài khoản. A18 dùng kịch bản open-to-stop để lấy 120 U/lot.

Lớp 3 — quy tắc symbol. Minimum, maximum, step và tổng volume theo hướng đều phải được kiểm tra. Nếu ứng viên sau floor thấp hơn minimum, câu trả lời là BLOCK, không ép lên minimum.

Lớp 4 — phơi nhiễm tổng. Risk Engine phải tính vị thế, lệnh chờ và cap basket/tài khoản; nhiều candidate nhỏ vẫn có thể tạo tổng quá lớn.

Lớp 5 — preflight tài khoản. Volume hợp lệ về hình thức vẫn có thể thiếu margin hoặc vi phạm tham số. Preflight phải dùng dữ liệu mới và lưu lý do quyết định.

b. Bốn trạng thái không nhập nhằng

  • ALLOW: ứng viên không đổi và mọi gate đều đủ bằng chứng.
  • REDUCE: một cap hợp lệ hạ ứng viên xuống mức vẫn được phép.
  • BLOCK: hard rule thất bại; không chờ dữ liệu mới để chữa lỗi logic.
  • RECHECK: bằng chứng cần thiết thiếu, cũ hoặc mơ hồ; chụp snapshot mới rồi tính lại.

Cap 0.10 có thể biến 0.20 thành REDUCE → 0.10. Cap 0.05 thấp hơn minimum 0.10 phải thành BLOCK. A18 thiếu bằng chứng margin nên vẫn RECHECK.

Hình 3 — Thiếu bằng chứng margin biến ứng viên hợp lệ về hình thức thành trạng thái RECHECK.

4. Mười lỗi biến sizing thành bộ khuếch đại rủi ro

  1. Điểm tin cậy tăng thẳng risk. Model hoặc signal score thường không được hiệu chỉnh thành xác suất; dùng nó làm số nhân volume có thể khuếch đại sai số.
  2. Thua thì tăng size. Đây là loss chasing/Martingale, không phải thích nghi có giới hạn.
  3. Chia cho khoảng cách points. Thiếu quy đổi tiền tệ khiến các symbol không còn so sánh được.
  4. Làm tròn lên. 0.25 → 0.30 vượt ngân sách; quy tắc an toàn là floor.
  5. Bỏ min/max/step/limit. Request có thể không hợp lệ hoặc vượt tổng volume theo hướng.
  6. Dùng snapshot cũ. Equity, spread, volatility hoặc exposure đã đổi làm phép tính mất nghĩa.
  7. Nhân hệ số hai lần. Chẳng hạn volatility đã giảm risk budget rồi lại giảm denominator; kết quả bị bóp méo ngoài chủ ý.
  8. Chỉ nhìn từng lệnh. Nhiều candidate nhỏ có thể tạo một basket quá lớn hoặc quá tương quan.
  9. OrderCheck=true nghĩa là đã khớp. Sai: đó là preflight. OrderSend=true cũng chưa chứng minh giao dịch đã thực thi; phải đọc result và theo dõi transaction. MQL5 OrderSend
  10. Tính lại khi request cũ còn bay. V2 có thể tạo request thứ hai trước khi V1 có kết luận, dẫn tới duplicate exposure.

Pipeline đúng vẫn không khóa lỗ thực tế tại đúng ngân sách vì gap, trượt giá, phí và thanh khoản. Sự kiện giao dịch có nhiều giai đoạn, thứ tự transaction tới terminal không được bảo đảm. MQL5 OnTradeTransaction

5. Position Sizing Contract trước khi viết code

Một Position Sizing Contract tối thiểu nên trả lời:

  1. Module nào sở hữu phép tính? 2. Version snapshot là gì? 3. Symbol/hướng nào?
  2. Equity lấy ở đâu, lúc nào? 5. Tỷ lệ cơ sở nào? 6. Hệ số nào được phép?
  3. Mỗi hệ số có khoảng giới hạn gì? 8. Stop lấy từ đâu? 9. Loss/lot tính bằng cách nào?
  4. Min/max/step/limit hiện tại? 11. Exposure đang có? 12. Trần danh mục?
  5. Trần thanh khoản? 14. Quy tắc làm tròn? 15. Preflight margin nào?
  6. Bao lâu thì dữ liệu stale? 17. Decision/reason nào? 18. Request identity nào?

Các hard rule nên được viết thẳng:

  • Hệ số chỉ trung tính hoặc giảm trong phạm vi bài này.
  • Luôn floor về step, không ceil.
  • Dưới minimum thì BLOCK, không ép lên.
  • Denominator bằng zero, stop không hợp lệ hoặc loss/lot thiếu thì BLOCK.
  • Bằng chứng thiếu/cũ thì RECHECK.
  • Risk/account gate chỉ giảm hoặc chặn.
  • Execution không được tự nâng candidate.

Log lưu cả giá trị thô và cuối, state, reason và snapshot version. Xử lý lại A18:SNAPSHOT:V1 không được tạo thêm request; input mới cần version mới và request trước không còn mơ hồ.

6. Worksheet A18 trong 15 phút

a. Cách làm

Dùng giấy hoặc Google Sheets; chưa mở MT5, chưa kết nối tài khoản và chưa dùng tiền thật. Chép bảng, tính từng hàng rồi ghi state.

b. Mẫu đối chiếu

Stage Input Calculation Output/state
Base budget equity 10,000 U, risk 0.50% 10,000 × 0.005 50 U
Adaptive budget factor 0.60 50 × 0.60 30 U
Raw size loss/lot 120 U 30 ÷ 120 0.25 lot
Broker step step 0.10 floor 0.25 0.20 lot
Exposure cap max 0.20 lot min(candidate, cap) 0.20 lot
Account check margin evidence missing no assumption RECHECK, request 0

Thử thêm hai biến thể:

  • Nếu cap là 0.10, mọi bằng chứng khác đều mới và preflight qua, kết quả là REDUCE → 0.10.
  • Nếu cap là 0.05 trong khi minimum là 0.10, kết quả là BLOCK, không nâng lên minimum.

Ghi ALLOW 0.20 thì xem lại hàng cuối; làm tròn lên 0.30 thì xem lại ngân sách 30 U.

7. Tổng kết: candidate có giới hạn, bằng chứng mới có quyền quyết định

a. Năm ý chính

  • Adaptive sizing tạo khối lượng ứng viên, không tạo quyền thực thi.
  • Money Management đề xuất; Risk giảm/chặn; Execution chuẩn hóa và preflight.
  • Mức lỗ tiền tệ trên một lot quan trọng hơn khoảng cách points đứng riêng.
  • Floor, symbol rules và aggregate exposure đều là hard gate.
  • Thiếu bằng chứng dẫn tới RECHECK/BLOCK, không được suy đoán thành ALLOW.

Bài trước là Recovery System trong EA. Bài tiếp theo là Tick Data Quality trong Backtest EA #19.

b. Câu hỏi tự kiểm tra

  • Vì sao 0.25 lot phải về 0.20, không lên 0.30?
  • Cap 0.05 thấp hơn minimum 0.10 phải trả trạng thái nào?
  • Vì sao A18 vẫn RECHECK dù candidate sau cap là 0.20?
  • OrderCheck thành công có chứng minh lệnh đã khớp không?

c. Gợi ý đáp án

Xem gợi ý câu 1

Làm tròn lên sẽ vượt ngân sách; phải floor theo step. → xem mục 2.

Xem gợi ý câu 2

BLOCK; ép lên minimum sẽ vượt cap. → xem mục 3.

Xem gợi ý câu 3

Snapshot thiếu bằng chứng margin, nên chưa đủ điều kiện ALLOW. → xem mục 2 và 3.

Xem gợi ý câu 4

Không; đó là preflight, còn thực thi cần result và transaction evidence. → xem mục 3 và 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Khối lượng ứng viên Volume đề xuất, chưa có quyền gửi.
Ngân sách rủi ro Mức lỗ dự kiến tối đa trong kịch bản tính.
Hệ số thích nghi Số nhân có giới hạn để giữ hoặc giảm ngân sách.
Loss per unit Mức lỗ tiền tệ ước tính cho một lot.
Volume step Bước khối lượng symbol chấp nhận.
Floor Làm tròn xuống về bước hợp lệ.
Exposure cap Trần phơi nhiễm tổng được phép.
Preflight Kiểm tra trước gửi, không phải xác nhận khớp.
Snapshot version Danh tính bộ đầu vào đã đóng băng.
RECHECK Chờ dữ liệu đủ/mới rồi tính lại.

e. Nguồn tham khảo

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Tính khối lượng không thể loại bỏ rủi ro mất vốn, trượt giá, phí, khoảng trống giá hoặc lỗi thực thi.