פיתוח אינדיקטור דלתא מצטברת (CVD) למסחר

אינדיקטור דלתה מצטברת: היכן נשבר חישוב הזרימה

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

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

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

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

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

מה נותן האינדיקטור: מהירות החישוב ויציבות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הרכב המסירה: תצורות, סכימות, נהלים

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

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

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

מקרה בוחן: איחוד אותות ומדדים לפני ואחרי

מה היה בפער לפני העיבוד מחדש

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

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

מה שינו ומה קיבלנו

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

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

מה לעשות אם הטרמינל כבר מחשב מדד דומה?

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

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

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

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

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

ספקות לגבי החישוב: החמצות, עומס, היסטוריה

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

להלן שאלות שאנחנו מסירים לרוב לפני תחילת העבודה.

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

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

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

עד כמה עמוקה ההיסטוריה וכיצד נבדקת תקינותה?

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

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

נדון במשימה ונחזור עם תוכנית עבודה

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

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

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