אינטגרציה של בוט מסחר AI עם QUIK QLUA

בוט מסחר AI: היכן נשבר ביצוע העסקאות

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

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

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

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

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

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

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

מה נותנת אוטומציה של מסחר: האפקט במטריקות

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

בוט ב-QUIK עובר את אותו מסלול בשברירי שנייה ואינו מוסח: מהירות התגובה לאירוע מפסיקה להיות תלויה במספר הפוזיציות שמלוות בו-זמנית.

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

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

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

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

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

דרכי חיבור של לוגיקת מסחר: השוואת אפשרויות

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

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

סדר היישום: מביקורת אסטרטגיה ועד למסירה

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

1. ביקורת אסטרטגיה וגבולות סיכון. מנתחים על איזה נתונים נבנה האות, היכן הלוגיקה מאבדת יציבות ואילו מגבלות על פוזיציה, דרודאון ותדירות עסקאות אנו מחשיבים כקבילות.
2. מפת זרימות ונקודות כשל. מקבעים מהיכן מגיעים הציטוטים, היכן מחושבת ההחלטה וכיצד ההוראה מגיעה לטרמינל המסחר QUIK דרך QLUA — כולל התנהגות המערכת בעת ניתוק הקשר.
3. הרכבת מעגל בדיקות. עותק מבודד של סביבת העבודה: אותו ניתוב הוראות ואותן מגבלות, אבל בלי חשבון אמיתי — טעויות כאן לא עולות דבר.
4. בדיקה על נתוני היסטוריה. הרצה בכמה מצבי שוק — מגמה, תנועה צדית, מהלכים חדים; בודקים דרודאון, שיעור ההוראות שנדחו ופער מול המודל המחושב.
5. מגבלות והגנות. עצירת חירום לפי הפסד יומי, מגבלה על מספר העסקאות, חסימה בעת אי-סנכרון נתונים, יומן לכל החלטה של הבוט.
6. מסירה לתפעול. נהלי הפעלה ועצירה, ניטור והתראות, הפרדת הרשאות, הוראות למהנדס תורן.
7. ליווי. התאמות לאחר שינוי בתנודתיות, ניתוח תקלות, בחינה מחדש של הבדיקות לפני כל הרחבת מגבלות.

מה נשאר אצל המזמין: קונפיגורציות, סכמות, נהלים

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

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

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

בפועל: כיצד הסרנו הפסדים בביצוע הוראות

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

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

מה שינינו

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

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

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

ספקות טכניים לפני ההתחלה: בקצרה ולעניין

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

מה קורה בעת ניתוק הקשר עם הטרמינל?

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

כיצד בודקים את הלוגיקה לפני חשבון אמיתי ומי מרחיב אותה?

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

נדון במשימה: מה לשלוח להערכה מדויקת

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

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

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

מה לעשות אם בוט המסחר כבר פרוס?

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

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

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

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

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

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