ניהול סיכונים באלגו: איך מסחר אוטומטי דרך API לא יפיל אותך

הרבה אנשים חושבים שהסיכון באלגו בא מהשוק: טעית בכיוון — הפסדת. אבל מי שהריץ סקריפטים תקופה יגיד לך שמה שמאפס חשבון ברגע הוא בדרך כלל לא השוק, אלא הקוד שלך עצמך — כיוון הפוך, לולאה שלא נעצרת, הזמנה כפולה אחרי ניתוק רשת. במסחר ידני, לפני הלחיצה על אישור יש עוד מבט אחרון; לסקריפט אין את המבט הזה, הוא יבצע את הטעות בנאמנות וברציפות.

במאמר הזה אנחנו (צוות המערכת של MeowQuant) עוסקים במיוחד בניהול סיכונים באלגו, ומגיעים אליו מ"איך מגינים ברמת הקוד", לא בקריאות כלליות של "שלוט בפוזיציה". נפרק את כמה סוגי הסיכון הייחודיים למסחר API, ניתן קוד של סטופ-לוס, פיצול פוזיציות ו-retry שאפשר להעתיק, ואז נבהיר את הקו האדום של אבטחת החשבון ואת סדר העלייה לבמה של "התחלה קרה בסכום קטן". בסוף הקריאה אתה אמור להיות מסוגל להתקין לסקריפט שלך כמה בלמים, כך שגם אם הוא טועה הוא לא יגרור אותך לאיפוס.

הסיכונים הייחודיים של מסחר API

למסחר ידני ולמסחר אוטומטי דרך API יש סוגי סיכון שונים. האויב העיקרי של מסחר ידני הוא הרגש והשיפוט; במסחר API, מעל לזה, מתווספת קטגוריה שלמה של סיכונים "ייחודיים למכונה". מי שמזהה אותם יודע איפה צריך להתקין את הבלם.

תוכנה שמשתוללת

זה הטיפוסי ביותר. קטע לוגיקה נכתב שגוי — כיוון קנייה/מכירה הפוך, תנאי סטופ-לוס שנכתב הפוך, לולאה שחסר בה תנאי יציאה — והתוכנה לא נעצרת לחשוב "אולי משהו לא בסדר" כמו אדם, אלא מבצעת את ההוראות השגויות שוב ושוב. ידנית אולי היית מבחין כבר אחרי הזמנה שגויה אחת, אבל הסקריפט יכול להזין עשרות הזמנות שגויות בשניות. עוצמת ההרס של ההשתוללות נעוצה ב"נאמנות" שלה.

הזמנות כפולות

קורה הכי הרבה בקפיצות רשת או ב-timeout של בקשה. שלחת בקשת הזמנה, לא קיבלת תגובה, הסקריפט חשב שהיא נכשלה ושלח שוב — אבל בעצם ההזמנה הראשונה כבר התבצעה, וכך הזמנת פעמיים. בחוזים, זה אומר פוזיציה כפולה, סיכון כפול. הזמנה כפולה היא לרוב לא שגיאת לוגיקה, אלא חוסר טיפול ב"מצב הביניים הלא ודאי".

ניתוק רשת ונפילת חיבור

הסקריפט רץ על המחשב או השרת שלך, וברגע שהרשת מתנתקת הוא מאבד קשר עם הבורסה. המצב הגרוע: הפוזיציה שלך עדיין חשופה בשוק, ולוגיקת הסטופ-לוס שהייתה אמורה להגן עליה התנתקה יחד עם הסקריפט. עד שתתחבר מחדש, ייתכן שהכל כבר השתנה לבלי הכר. מהות סיכון הניתוק היא לא לשים את כל ההגנה על ההנחה ש"הסקריפט תמיד מקוון".

ניהול פוזיציות ופיצול

החומה הראשונה של ניהול סיכונים היא לא לתת לאף טעות בודדת לפגוע בכל ההון שלך. זה מושג דרך כללי פוזיציה, והכללים האלה צריכים להיות כתובים קשיח בקוד, לא להסתמך על איפוק שלך ברגע אמת.

כמה עקרונות שאנחנו בעצמנו תמיד מקפידים עליהם:

• הגדר תקרה לפוזיציה בודדת. אף הזמנה לא תעלה על אחוז קבוע מסך ההון (למשל 1%–2%). כך גם אם ההזמנה הזו טועה בכיוון לחלוטין, להפסד יש תקרה.
• הגדר תקרה לסך הפוזיציות. סך הפוזיציות הפתוחות לא יעלה על סכום כולל, ואל תיתן לתוכנה הזדמנות לזרוק את כל ההון בבת אחת.
• פצל פוזיציות, אל תיכנס הכל בבת אחת. חלק את ההון לכמה מנות שנכנסות בהדרגה, כדי להפחית את הזעזוע מטעות שיפוט בנקודת כניסה אחת.
• השאר מזומן לסקריפט. שמור תמיד בחשבון חלק מההון שלא משתתף במסחר, גם כחיץ וגם כמרחב לפעולה ידנית כשמשהו משתבש.

כתוב את אלה כאילוצים קשיחים בקוד, בדוק לפני הזמנה, ואם לא מתקיים — דחה את ההזמנה:

MAX_PER_ORDER_RATIO = 0.02   # פוזיציה בודדת לא תעלה על 2% מסך ההון
MAX_TOTAL_RATIO     = 0.30   # סך הפוזיציות לא יעלה על 30% מסך ההון

def check_position_limit(okx, symbol, order_value_usdt):
    bal = okx.fetch_balance()
    equity = bal['USDT']['total']          # סך ההון במונחי USDT

    # תקרת פוזיציה בודדת
    if order_value_usdt > equity * MAX_PER_ORDER_RATIO:
        raise ValueError('חורג מתקרת הפוזיציה הבודדת, ההזמנה נדחית')

    # כאן אפשר להוסיף בדיקה ש"סך הפוזיציות + ההזמנה הזו" לא יעלה על MAX_TOTAL_RATIO
    return True

הקטע הזה לא מסובך, אבל הערך שלו הוא בכך שהוא הופך את הרצון "אני צריך לשלוט בפוזיציה" לשער שהסקריפט חייב לעבור לפני כל הזמנה. הרצון מתנדנד, הקוד לא.

סטופ-לוס חייב להיות תכנותי (קוד)

אם תזכור רק משפט אחד מהמאמר הזה, תזכור את זה: סטופ-לוס חייב להיות תכנותי. הסקריפט רץ אוטומטית, ואי אפשר להשגיח על השוק 24 שעות; כשהשוק מתהפך מהר, עד שתראה ותסגור ידנית בדרך כלל כבר עברת כמה רמות מחיר.

לסטופ-לוס תכנותי יש שתי גישות, ומומלץ לשלב ביניהן:

גישה ראשונה: הזמנה מותנית / סטופ-לוס בצד הבורסה. במקביל להזמנת ההזמנה הראשית, תלה ב-OKX הזמנת סטופ-לוס, ותן לבורסה לסגור את הפוזיציה אוטומטית במחיר ההפעלה. היתרון הכי גדול שלה: גם אם הסקריפט שלך מתנתק, הסטופ-לוס הזה עדיין פעיל בצד הבורסה. זה הצעד האמין ביותר נגד "פוזיציה חשופה בעת ניתוק".

גישה שנייה: ניטור מקומי בסקריפט + סגירה בהפעלה. הסקריפט קורא בלולאה ברציפות את ההפסד הלא ממומש של הפוזיציה, וברגע שהוא חורג מהסף שהגדרת הוא שולח ביוזמתו הזמנת סגירה. היא גמישה יותר (מאפשרת trailing stop, סטופ לפי זמן ועוד), אבל בתנאי שהסקריפט מקוון.

להלן השלד המינימלי של סטופ-לוס בניטור מקומי, להדגמת הלוגיקה (לפני חשבון אמיתי חובה לאמת בדמו):

import ccxt, time

okx = ccxt.okx({
    'apiKey':   'ה_apiKey_שלך',
    'secret':   'ה_secret_שלך',
    'password': 'ה_Passphrase_שלך',
    'enableRateLimit': True,
})

symbol      = 'BTC/USDT'
entry_price = 60000      # מחיר הכניסה הממוצע שלך (דוגמה)
amount      = 0.001      # כמות הפוזיציה
stop_ratio  = 0.05       # סטופ-לוס בירידה של 5%

while True:
    ticker = okx.fetch_ticker(symbol)
    last = ticker['last']
    drawdown = (entry_price - last) / entry_price

    if drawdown >= stop_ratio:
        okx.create_order(symbol, 'market', 'sell', amount)
        print(f'הופעל סטופ-לוס, נסגרה פוזיציה ב-market @ {last}')
        break

    time.sleep(10)   # השאר מספיק מרווח, אל תפציץ את הממשק

שים לב לשני דברים: ראשית, חובה sleep בלולאה, אחרת תיתקל במגבלת קצב; שנית, סטופ-לוס מקומי הוא רק תוספת, וסטופ-לוס בצד הבורסה הוא קו ההגנה האחרון בעת ניתוק — עשה את שניהם וזה יציב.

מניעת הזמנות כפולות וניתוק רשת

שורש ההזמנה הכפולה הוא "אני לא בטוח אם ההזמנה הקודמת התבצעה או לא". הליבה של ההגנה: אל תשלח מחדש באופן עיוור, קודם וודא סטטוס.

שתי שיטות שעובדות יחד:

השתמש במזהה לקוח ייחודי (clientOrderId). בעת ההזמנה צרף ID ייחודי שאתה מייצר בעצמך, והבורסה תדחה ID חוזר — זו מניעת כפילות טבעית. גם אם שלחת מחדש בגלל timeout, הבורסה תכיר רק בהזמנה הראשונה.

import uuid

cid = 'meow-' + uuid.uuid4().hex[:16]   # מזהה הזמנה ייחודי שאתה מייצר בעצמך

order = okx.create_order(
    symbol, 'limit', 'buy', 0.001, 50000,
    params={'clientOrderId': cid},       # צרף אותו, גם שליחה מחדש תוכר רק פעם אחת
)

אחרי timeout / ניתוק — קודם בדוק, אז השלם. אם בקשת ההזמנה נכנסה ל-timeout, אל תשלח שוב ישירות; קודם השתמש בשאילתת הזמנות פתוחות או שאילתת פוזיציות כדי לוודא אם ההזמנה הקודמת נכנסה או לא, ורק אז החלט אם להשלים. אחרי חיבור מחדש אותו דבר — קודם fetch_open_orders ו-fetch_positions כדי לראות בבירור את המצב האמיתי הנוכחי, ורק אז תן לאסטרטגיה להמשיך. הפיכת "קודם לבדוק סטטוס, אז לפעול" לצעד הקבוע הראשון אחרי חיבור מחדש חוסמת את רוב הפעולות הכפולות שנגרמות מאובדן קשר.

מגבלת קצב, זמן קצוב ו-retry

ניהול סיכונים הוא לא רק מניעת הפסד כספי, אלא גם מניעה של הסקריפט "ממוטט את עצמו". טיפול גרוע במגבלת קצב ובזמן קצוב יגרום לאסטרטגיה שלך להיכשל ברגע הקריטי.

מגבלת קצב: הדלק באתחול 'enableRateLimit': True, ו-ccxt תשתול אוטומטית מרווחים בין הבקשות. בלולאות תדירות גבוהה הוסף נסיגה מעריכית (נתקלת פעם — חכה שנייה; שוב — 2 ואז 4 שניות). על החלק הזה הרחבנו במאמר על שגיאות API נפוצות, וכאן רק נדגיש: בכל לולאה שפוגעת בממשק, מגביל קצב הוא ציוד תקני.

זמן קצוב (timeout): הגדר לבקשה זמן קצוב ברור, אל תיתן לסקריפט להיתקע ולקפוא כולו בגלל בקשה אחת. ב-ccxt אפשר להגדיר 'timeout' (במילישניות):

okx = ccxt.okx({
    'apiKey':   'ה_apiKey_שלך',
    'secret':   'ה_secret_שלך',
    'password': 'ה_Passphrase_שלך',
    'enableRateLimit': True,
    'timeout': 10000,     # זמן קצוב של 10 שניות לבקשה בודדת, למניעת תקיעה
})

ל-retry יש תקרה. בקפיצת רשת אפשר לנסות שוב, אבל הגדר מספר ניסיונות מקסימלי, ואחרי שמיצית — התרע / עצור, ולא נסיונות אינסופיים. נסיונות אינסופיים הם בעצמם סוג של "תוכנה משתוללת" — הם יבזבזו בקשות ברציפות, ואף יבצעו פעולות כפולות, בלי שתשגיח.

הרשאות ורשימת IP: הקו האדום של האבטחה

השכבה התחתונה ביותר של ניהול הסיכונים היא אבטחת החשבון. הסקריפט כתוב יציב ככל שיהיה, אם האישורים דלפו הכל מתאפס. כאן יש שני קווים אדומים כמעט בלי יוצא מן הכלל:

סמן רק 'קריאה' ו'מסחר', לעולם אל תסמן 'משיכה'. הרצת אלגו בכלל לא משתמשת בפעולת המשיכה. כל עוד אין למפתח הרשאת משיכה, גם אם שלושת האישורים — apiKey, secret, Passphrase — ידלפו יום אחד, מי שישיג אותם יוכל לכל היותר להזין הזמנות פרועות בחשבון שלך (שזה כמובן רע, אבל אילוצי הפוזיציה והסטופ-לוס שלמעלה נותנים רשת ביטחון), ולא לסחוב את המטבעות. וברגע שתסמן משיכה, דליפה שווה למסירת המפתח של הכספת.

הגדר רשימת IP מורשים. אם הסקריפט שלך רץ על מכונה עם IP קבוע (שרת ענן, חיבור ביתי עם IP ציבורי קבוע), הוסף את ה-IP הזה לרשימה של המפתח, שתקבל בקשות רק ממנו, והאבטחה עולה עוד מדרגה. אם ה-IP שלך משתנה הרבה, רשימה מורשית תדחה אותך בטעות כל יום, ובמצב כזה אפשר לא להגדיר אותה כרגע — אבל חובה לשמור היטב על האישורים: אל תכתוב אותם קשיח בקוד שעולה לרשת, עבור למשתני סביבה או לקובץ תצורה שלא מסונכרן.

שני הקווים האלה, בתוספת הפוזיציה והסטופ-לוס מקודם, מרכיבים את ההגנה ש"גם אם יקרה המצב הגרוע ביותר, להפסד יש גבול". הצעדים המדויקים ליצירת מפתח נמצאים במבוא המעשי ל-API שלנו, ואפשר גם להשתמש ברשימת בדיקת הרשאות API כדי לעבור על הכל לפני פתיחת מפתח.

התחלה קרה בסכום קטן: רשימה לפני הכסף האמיתי

כל ניהול הסיכונים ברמת הקוד מותקן, ולפני עלייה לחשבון אמיתי נשאר צעד אחרון: אל תיכנס מיד בפוזיציה כבדה. אסטרטגיה חדשה שעולה לכסף אמיתי — אנחנו תמיד הולכים ב"התחלה קרה בסכום קטן", בסדר הזה:

• קודם הרצה רציפה בדמו. כיסוי כמה סבבי עליות וירידות, אישור שהזמנה, ביטול, סטופ-לוס ו-callbacks כולם כמצופה. הצעד הזה ללא עלות, ודילוג עליו שווה לשימוש בכסף אמיתי כסביבת בדיקה.
• אחר כך התחלה קרה עם מעט כסף אמיתי. סכום קטן עד שגם אם תפסיד הכל לא יכאב לך, התייחס אליו כשכר לימוד. ה-slippage והעומק שהדמו לא מסוגל לשחזר — רק עכשיו ייחשפו.
• עקוב אחריו בימים הראשונים. אל תרפה באמת, ודא שההתנהגות בחשבון האמיתי תואמת לדמו, שהסטופ-לוס באמת מופעל, שאין הזמנות כפולות, ורק אז הגדל בהדרגה.
• חוזים ומינוף בסוף. לפני שהספוט רץ יציב, אל תיגע במינוף. מינוף מגביר פי כמה כל אחת מקטגוריות הסיכון הנ"ל, ובשלב המתחיל אנחנו ממליצים בחום לעשות רק ספוט.

חבר את הרשימה הזו לאילוצי הקוד מקודם, ומה שאתה מתקין לסקריפט הוא לא בלם אחד אלא כמה: לפוזיציה יש תקרה, הסטופ-לוס מופעל אוטומטית, הזמנה כפולה נחסמת, גם אם האישורים דלפו אי אפשר לסחוב כסף, והעלייה לבמה היא קודם בכסף קטן. אף אחד מהם לבדו לא מספיק, ורק יחד הם משאירים בין "טעות" ל"איפוס" מספיק חיץ.

בדיקה: מהמורה שנתקלנו בה

שאלות נפוצות

ניהול סיכונים הוא לא דבר שנגמר ברגע שסיימת לכתוב קוד — הוא צריך לגדול יחד עם האסטרטגיה שלך. מומלץ לשמור את הרשימה מהמאמר הזה, ולעבור עליה בכל פעם שעולה אסטרטגיה חדשה. הלאה אפשר ללכת לשגיאות API נפוצות כדי להשלים את יציבות הסקריפט, וקוד חדש תמיד קודם לדמו לאימות. זכור את המשפט הישן: קודם לשרוד, אחר כך לדבר על רווחים.