למה בוט מסחר מותאם אישית נשבר בשוק החי
שגיאות כמעט אף פעם לא נמצאות באסטרטגיה עצמה. כשלים מתרכזים בשכבה שבין האות לעסקה המאושרת: לפי ניתוחי תקלות במסחר אלגוריתמי, עיקר עצירות החשבון נובע מביצוע וקישוריות, ולא מהיגיון הכניסה (דו"ח על כשלים תפעוליים במסחר אלגוריתמי).
בוט מסחר מותאם אישית שנכתב עצמאית נופל לרוב דווקא כאן — במקום שבו נגמרת המתמטיקה ומתחיל ספר הפקודות האמיתי.
החלקה של מחיר — המקור הראשון לפער. ההיגיון מחשב כניסה לפי מחיר העסקה האחרונה, בעוד שהביצוע בפועל מתבצע לפי רמות ספר הפקודות: בתנועה חדה, הפער בין המחיר המחושב למחיר בפועל אוכל את התוחלת החיובית של האסטרטגיה כולה.
הלאה — ביצוע חלקי של הזמנות. ההזמנה אוספת חלק מהנפח, היתרה תלויה בספר הפקודות, והבוט כבר מחשיב את הפוזיציה כאסופה ושולח הזמנה נוספת. אותו תרחיש יוצר שכפול הזמנות: תגובת הבורסה לא הגיעה, המודול חזר על השליחה מבלי להתאים את מצב החשבון.
סוג נפרד — ניתוק החיבור לבורסה. ערוץ נתוני השוק נופל, אך ההזמנות והפוזיציה בבורסה ממשיכות להתקיים. ללא התאמה בעת ההתחברות מחדש, הבוט או פותח פוזיציה שנייה, או נשאר ללא פקודות הגנה מסוג סטופ, והסיכון גדל ללא כל אות.
אף אחד מהכשלים האלה לא נרפא על ידי כיוונון פרמטרים של האסטרטגיה. יש צורך בשכבת ביצוע נפרדת: שליחת הזמנות אידמפוטנטית, יומן מצב מקומי, התאמה תקופתית עם הבורסה, מגבלות על נפח ומספר החזרות. אנו מפרטים כיצד זה נסגר.
מה נותנת לוגיקת ביצוע הזמנות משלנו
את לוגיקת ביצוע ההזמנות אנו מוציאים לשכבה נפרדת בין האסטרטגיה לממשק המסחר של הפלטפורמה. האסטרטגיה מעבירה רק כוונה — כיוון, נפח, סטייה מותרת במחיר — והשכבה עצמה מחליטה כיצד ליישם אותה: לפצל לחלקים, להציב הזמנת לימיט או לבטל אותה עם יציאת השוק.
הפער בין "החלטה לשליחה" מייצר השפעות שנראות ביומן הביצוע, ולא בדו"ח "נהיה נוח יותר".
מהירות תגובה לאירוע שוק
מטפל האירועים מחזיק חיבור קבוע לפלטפורמה ומגיב לשינוי בספר הפקודות ללא מעורבות אדם. תור המשימות ומפתחות אידמפוטנטיים של הזמנות מונעים שליחת כפילות בעת מסירה חוזרת של הודעה.
הנתיב מהאות להזמנה מתקצר למעבר אחד במטפל, ושיעור ההזמנות שלא בוצעו יורד — בדרך כלל מעשרות אחוזים לאחוזים בודדים. יומן ההזמנות והפוזיציות נכתב ל-PostgreSQL, לכן אי-התאמה בין המצב הפנימי לתגובת הפלטפורמה מנותחת לפי עובדות.
ניהול סיכונים ופוזיציות
מגבלה על פוזיציה, ירידה מקסימלית להפסד במהלך סשן, איסור הזמנות מנוגדות ועצירה אוטומטית בעת חוסר סנכרון — אלו בדיקות בתוך שכבת הביצוע, ולא הוראה לתורן. סוג הכשלים "חריגה מהמגבלה כי לא הספקתי לחשב" נעלם: החריגה נחסמת לפני השליחה.
עמידות בתקלות נשענת על התחברות מחדש עם שחזור מצב מהיומן ועל צמצום הפוזיציה בעת אובדן קשר — פעולות ידניות נשארות במידה הנדרשת על פי תקנון הפלטפורמה.
מצבי עבודה: מאותת ועד אוטונומי לחלוטין
מצב עבודה אינו עוסק במידת האמון בבוט, אלא במקום של האדם במחזור המסחר: יצירת אות, בדיקת סיכון, הצבת הזמנה, ליווי פוזיציה. מכך באיזה שלב עומד האישור, תלויים גם השהיית התגובה וגם הדרישות למעגל הביצוע.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| אות | אסטרטגיה חדשה, בודקים השערה בשוק החי | מהירות התגובה מוגבלת על ידי אדם: בזמן שאתה מאשר, המחיר בורח |
| חצי-אוטומטי | חלק מההחלטות מפורמלות, חלק נשאר אצל הסוחר | נדרשים כללים ברורים להעברת שליטה, אחרת מצב הפוזיציה לא תואם |
| אוטונומי במעגל נפרד | האסטרטגיה מגובשת, מגבלות הסיכון מוגדרות היטב | נתקל בנזילות הכלי ובמגבלות הפלטפורמה, נדרש בקרת סיכון חיצונית |
| צל | לפני מעבר לאוטונומי — להשוות החלטות הרובוט עם הנוכחיות | עסקאות לא מבוצעות, רק נרשמות אי-התאמות |
מצבי אות וחצי-אוטומטי
במצב אות, הרובוט מוסר חישוב מוכן: כלי, כיוון, מחיר כניסה, נפח, רמת סטופ. האדם מאשר או דוחה — וכל דחייה נרשמת ביומן עם סיבה, אחרת לא ניתן להבין היכן בדיוק האסטרטגיה מאבדת תוצאה.
במצב חצי-אוטומטי הגבול עובר עמוק יותר: את הכניסה מאשר האדם, בעוד שנפח הפוזיציה, העברת הסטופ וסגירות חלקיות הרובוט מנהל בעצמו.
הערך המעשי של חיבור כזה הוא הפוך: הוא אוסף סטטיסטיקה על החלטות ידניות ומראה אילו מהן כדאי להעביר לרובוט.
מצב אוטונומי ומגבלותיו
המעגל האוטונומי נפרס בנפרד: מפתחות גישה משלו, מגבלות משלו בצד הפלטפורמה, בידוד משאר התשתית. בעת כשל של צומת, הפוזיציות הפתוחות נשארות תחת שליטה, ולא תלויות ללא ליווי. מגבלות האוטומציה לא נעלמות לשום מקום: החלקה בספר פקודות דק, ביצועים חלקיים, ניתוק קשר ברגעי תנודתיות.
לכן המצב האוטונומי תמיד מגיע עם מנגנוני הגנה — גודל פוזיציה מקסימלי, סטופ יומי, השהיה בתנועה חריגה — ולפני ההפעלה בדרך כלל מריצים מצב צל, שבו הרובוט מחשב אך לא שולח הזמנות.
כיצד מתבצעת הטמעה: מניתוח האסטרטגיה ועד מסירת הקוד
הטמעת בוט מסחר מתחילה לא בקוד, אלא בפורמליזציה של כללים: כל עוד האסטרטגיה קיימת כ"רואים בעין את הכניסה", לא ניתן לבדוק אותה על היסטוריה ולא להעביר לצוות שלך. אנו מפרקים את הלוגיקה לתנאים חד-משמעיים — מה נחשב לאות, כיצד מחושב נפח הפוזיציה, מתי הפוזיציה נסגרת בכפייה.
ניתוח האסטרטגיה והגבלות הפלטפורמה
- ניתוח האסטרטגיה: כללי כניסה ויציאה, עבודה עם נפחים חלקיים, התנהגות הבוט כאשר אין אות.
- מגבלות הפלטפורמה: מגבלות על קצב בקשות, סוגי הזמנות מותרים, צעד מחיר ונפח, עמלות, מצבי סשנים מסחריים.
- תרשים אינטראקציה עם חשבון המסחר: מפתחות גישה למסחר בלבד, הפרדה בין מעגל ייצור למעגל בדיקה, אחסון סודות מחוץ לקוד.
- הרכבת הלוגיקה וההגנות: חישוב נפח, מגבלת סיכון לעסקה וליום, מגביל מספר הזמנות, טיפול נכון בניתוקי קשר.
בדיקה לפני חשבון אמיתי
- בדיקה על נתונים היסטוריים: הרצה על מחירים לתקופה ארוכה תוך התחשבות בעמלות והחלקה, השוואת מספר העסקאות לציפיות.
- עבודה בחשבון בדיקה: אותם כללים בזמן אמת, תיקונים עקב כשלי פלטפורמה ועיכובי ביצוע.
- העברה מבוקרת לחשבון אמיתי: נפח קטן, התאמה יומית של דוחות הבוט עם היסטוריית החשבון, הרחבת נפחים לאחר אישור.
מסירת הקוד — שלב נפרד: מאגר עם היסטוריית שינויים, הוראות הפעלה ועצירה, ניתוח עם המהנדסים שלך. הקוד נשאר אצלך, אתה בונה תמיכה בעצמך או ממשיך איתנו.
מה מקבלים לידיים: קוד, תרשימים, תקנונים
מסירת הבוט אינה ארכיון עם קוד, אלא סט חפצי אומנות שלפיהם מקימים את המערכת מאפס ללא המחבר. אנו מוסרים לפי רשימה: אם לא ניתן לבדוק סעיף על מתקן נפרד, הוא אינו נחשב כמאושר.
קוד ותצורות
- קוד המקור של הבוט ומודולי האסטרטגיה עם היסטוריית שינויים — הבנייה משוחזרת בסביבה נקייה.
- תצורות למעגל בדיקה ולמעגל עבודה: זוגות מסחר, מגבלות נפח, פסקי זמן, ספי הפעלה.
- תרשים אינטראקציה בין רכיבים: מסלול האות מנתוני שוק ועד הצבת הזמנה וצווארי בקבוק.
- מדיניות גישה ואחסון מפתחות: תפקידים, היכן מאוחסנים מפתחות הגישה לבורסה, סדר רוטציה, הרכב היומן.
תיעוד ותקנונים
- תיעוד האסטרטגיה: תנאי כניסה ויציאה, חישוב אינדיקטורים, סימני סטייה ותנאי עצירת הבוט.
- תקנוני תפעול: סדר הפעלה, בדיקות לפני סשן מסחר, פעולות התורן בעת הפעלת מגבלות.
- הוראות שחזור לאחר תקלה: כיצד להתאים את מצב הפוזיציות ליומן העסקאות ולחזור לעבודה.
- סדר שיפורים: כיצד להוסיף אסטרטגיה או פרמטר ואילו בדיקות עובר השינוי לפני פריסה.
מקרה בוחן: מעבר מפתרון מוכן לבוט משלנו
הלקוח הגיע עם בוט מוכן: האסטרטגיה עבדה, אך חיה בתוך לוגיקה זרה. לא ניתן היה לשנות תנאי כניסה או להבין מדוע חלק מההזמנות עוברות לאישור ידני. האסטרטגיה הועברה לבוט משלנו, תוך שמירה על ההתנהגות בנתונים היסטוריים.
מה היה לפני
הפתרון המוכן ביצע אוטומטית כשלושה רבעים מההזמנות, והשאר חיכו לאישור מפעיל — הוא ישב מול המסך בשעות הפעילות של השוק. הפוזיציה בפועל לא תאמה את המחושבת מספר פעמים בשבוע: חלק מהעסקאות אבדו בעת ניתוק הערוץ, והדבר התגלה רק בבדיקה ידנית. זמן ההשבתה בעת אובדן קשר הגיע עד 40 דקות, ובכל אותו זמן הפוזיציות הפתוחות נותרו ללא ניהול.
מה קרה אחרי
שיעור ההזמנות שבוצעו אוטומטית עלה ל-98%, פעולות ידניות נותרו פחות משני אחוזים — משיכת כספים והחלפת פרופיל סיכון. השחזור לאחר ניתוק קשר אורך עד 30 שניות: הבוט מתחבר מחדש, משווה את המצב בפועל למחושב, ורק אחר כך מסיר את ההשהיה.
סוג הכשלים "חוסר סנכרון פוזיציה" נסגר: כל הזמנה נושאת מפתח חזרה, וההתאמה מופעלת בכל התחברות מחדש.
מטריקות אנו אוספים דרך Grafana — הפאנל מציג את שיעור ההזמנות שבוצעו, זמן השחזור ומספר ההתערבויות הידניות לפי ימים. פרוטוקול המדידות לפני ואחרי מצורף לדו"ח הקבלה: לפיו ניכר שהעניין בלוגיקת הביצוע, ולא בשינוי עומס השוק.
מה לעשות אם פתרון מוכן כבר סוחר בבורסה
אין צורך לכבות פתרון עובד כדי להתחיל בהעברה. בוטים מוכנים מוגבלים לאו דווקא בלוגיקת האסטרטגיה, אלא בשלד שלה: כללי כניסה ויציאה קבועים, ניהול סיכונים משתנה רק בגבולות השדות המוגדרים, ומצב הבדיקה מחשב לפי היסטוריה ללא תור הזמנות אמיתי. מגבלות אלו הן הגורם למעבר.
העברת האסטרטגיה מתחילה בפורמליזציה: כניסה, יציאה, הוספות וסטופים מתוארים כמפרט בלתי תלוי בפלטפורמה הקודמת. לאחר מכן היא מורצת על אותה היסטוריה ועל הקלטת זרימת ההזמנות, והעסקאות מותאמות ליומן הבוט הנוכחי — פער במחיר ובזמן ההפעלה מראה היכן אנו קוראים את השוק אחרת.
| אפשרות הגירה | מתי מתאים | מגבלות |
|---|---|---|
| הרצה במקביל | עסקאות תכופות, מחיר טעות גבוה | המגבלות מתחלקות בין שני המעגלים |
| העברה בחלקים | מספר כלים או אסטרטגיות | קופה ובקרת סיכון מופרדים זמנית |
| החלפה מלאה לאחר בדיקה | אסטרטגיה אחת, עסקאות נדירות, יש חלון זמן השבתה | דורש התאמת יומנים לפני מיתוג |
התאימות למעגל הנוכחי נבדקת לפני המיתוג: הבוט החדש מתחבר לחשבון עם הרשאות מוגבלות — עסקאות מותרות, משיכת כספים חסומה — וממשיך את הליווי של עסקאות שכבר פתוחות לפי אותם סטופים. לאחר מכן הכלים מועברים בקבוצות, המערכת הישנה נשארת כגיבוי חם, והמסחר אינו נעצר אף לרגע.
ספקות טכניים: עיכובים, כשלים, שיפורים
לפני הפעלת אסטרטגיה בחשבון אמיתי, הלקוח בודק כיצד המערכת מתנהגת במצבי חירום: מה קורה בעת ניתוק קשר עם הפלטפורמה, היכן מאוחסנים המפתחות, כיצד הלוגיקה נבדקת לפני העסקאות הראשונות. להלן שאלות טכניות שעולות לרוב בעת הקבלה.
מה יקרה אם החיבור לפלטפורמה ינותק?
הבוט מנהל יומן מצב מקומי: בעת אובדן הערוץ לא מוצבות הזמנות חדשות, הפוזיציות הפתוחות נשארות במעקב. לאחר שחזור הקשר, המודול משווה את הפוזיציות והמאזן בפועל עם היומן, ורק אז מחדש את העבודה. אי-התאמה מעלה התראה, ולא "מטופלת" על ידי אלגוריתם.
כיצד מצטמצמת השהיית הביצוע?
האות מחושב באותו תהליך של שליחת ההזמנה, החיבור לזרם נתוני השוק קבוע. אנו רושמים את ההשהיה מהאות ועד להזמנה — צוואר הבקבוק נראה במטריקות, ולא מתגלה דרך ירידה בהפסד.
היכן מאוחסנים מפתחות הגישה לחשבון?
מפתחות עם הרשאת מסחר מאוחסנים מוצפנים בצד הלקוח ואינם נכנסים לקוד או ליומנים. הרשאה למשיכת כספים אינה ניתנת להם בפלטפורמה, הפענוח — באמצעות סוד נפרד.
כיצד נבדקת האסטרטגיה לפני חשבון אמיתי?
תחילה הרצה על נתונים היסטוריים, לאחר מכן מעגל בדיקה של הפלטפורמה עם זרימת הזמנות אמיתית, ואז חשבון עם נפח מינימלי. קריטריון המעבר — ההתנהגות תואמת את החישוב, והפער בביצוע ובהחלקה נכנס לסטייה שהוגדרה.
מי אחראי על שיפורים ותמיכה לאחר המסירה?
שינוי כללי הפלטפורמה — שיפור מתוכנן: מתקנים את המתאם והתצורה, האסטרטגיה עצמה אינה נכתבת מחדש. לאחר המסירה אנו נשארים בתמיכה: עוקבים אחר שינויים, מעדכנים תלויות, מנתחים תקלות לפי יומנים.
נדון באסטרטגיה שלך ונחזור עם תוכנית
כדי שהערכת לוחות הזמנים תתבסס על עובדות ולא על הנחות, יש צורך במעגל קלט: ככל שתתאר בצורה מדויקת יותר את הכללים והמגבלות, כך נניח פחות הנחות בתוכנית. שלח את מה שיש — אפילו טיוטה בטבלה תתאים.
- כללי האסטרטגיה: אותות כניסה ויציאה, חישוב נפח, התנהגות בתנועה חדה ובספר פקודות דק.
- פלטפורמות וכלים: היכן סוחרים, שוק ספוט או חוזים, אילו סוגי הזמנות ומגבלות בצד הפלטפורמה.
- מעגל נוכחי: מה כבר עובד — עסקאות ידניות, טבלאות, סקריפטים, חבילות מוכנות. בנפרד נציין מה מעבירים ומה כותבים מחדש.
- מגבלות סיכון: ירידה מקסימלית מותרת, מגבלה לעסקה וליום, מה הבוט עושה בעת ניתוק קשר וחוסר סנכרון מצב.
- דיווח: אילו מטריקות נדרשות, באיזה פורמט ולאן לייצא, האם נדרש יומן עסקאות עם אפשרות לנתח ביצועים שנויים במחלוקת.
- נתונים להתאמה: היסטוריית עסקאות או תקופת בדיקה — לפיה נריץ את הלוגיקה לפני העברה לחשבון אמיתי.
- מעגל גישה: היכן ממוקמים, למי שייכים המפתחות, בשלב ראשון די בהרשאות קריאה בלבד.
לאחר מכן הסדר הוא כזה: נשאל שאלות הבהרה בנקודות שנויות במחלוקת, נציג תרשים אינטראקציה בין המודולים, ניתן הערכת לוחות זמנים והרכב העבודות לפי שלבים — מניתוח האסטרטגיה והשוואה על היסטוריה ועד הפעלה ותמיכה. תאר את המשימה — נחזור עם תוכנית עבודה שבה לכל שלב יש תוצאה ניתנת לבדיקה.