פיתוח מערכת אוטומטית לקווי מגמה

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

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

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

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

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

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

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

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

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

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

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

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

מצבי חישוב של קווי מגמה: השוואת גישות

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

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

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

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

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

קונפיגורציות, סכמות ונוהלים: מה מוסרים לידיים

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

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

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

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

איך זה היה

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

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

מה שינו

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

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

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

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

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

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

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

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

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

ספקות טכניים: מגבלות ותאימות

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

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

איך המערכת משתלבת במעגל שכבר עובד?

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

מה עם תמיכה אחרי ההרצה?

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

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

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

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

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