פיתוח מודל ML לחיזוי נזילות שוק הקריפטו

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1376
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1350
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    798
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1094
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1035
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1132

מדוע תחזית נזילות שוק הקריפטו נשברת בפועל

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

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

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

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

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

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

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

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

  • דיוק התחזית באופק העסקה. המודל מבוסס PyTorch נשען על עומק ספר ההזמנות, זרימת העסקאות והטיה בין הצדדים; שיעור האותות הנכונים באופק הנדרש עולה מרמת ניחוש אקראי לכ-60–70% במדגם המוחזק בצד.
  • הפחתת ההחלקה ועלות הביצוע. נפח ההזמנה מחושב מתוך התחזית של הנזילות הזמינה, ולכן הכניסה «אוכלת» את ספר ההזמנות לעתים רחוקות יותר: הסטייה של מחיר הביצוע מהמחיר המחושב יורדת פי כמה, והעמלות והפסדים על הספרד מפסיקים להיות העלות העיקרית של האסטרטגיה.
  • צמצום זמן ההשבתה בעבודה עם הזמנות. שירות התחזית שומר על זמן תגובה בתקציב שהוגדר, תור ההזמנות לא מצטבר, ובמקרה של ירידה בביצועים גרסת הגיבוי משתלטת — קו המסחר לא נעצר בזמן האימון מחדש.
  • עמידות בתקופות שוק. בתנועות חדות המטריקה יורדת באופן מבוקר: בקרת הדריפט מעבירה את המודל למצב זהיר עם גודל פוזיציה מוקטן במקום גידול מפולת של שגיאות.

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

תחזית נזילות: גישות והמגבלות שלהן

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

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

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

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

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

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

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

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

נתונים, תכונות ותקנות תפעול המודל

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

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

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

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

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

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

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

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

  • שיעור העסקאות במחיר הגרוע ביותר בעומק הזמין: 18% → 6%;
  • שיעור ההזמנות שנכשלו בשעות שוק: 12% → 3%;
  • ההחלקה ביחס לאמצע הספרד הצטמצמה בחצי.

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

מה עושים אם הנתונים ההיסטוריים מועטים או חלקיים?

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

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

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

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

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

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

ספקות לגבי נתונים, אופק ועמידות המודל

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

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

עד כמה התחזית עמידה בשוק לא יציב?

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

באיזו תדירות מאמנים מחדש ומה עם הגנת הנתונים?

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

כיצד התחזית משתלבת במערכת המסחר?

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

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

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

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

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