הנדסת נתונים ובניית צינורות ML

הנדסת נתונים ל-ML: צינורות נתונים, תיוג ואיכות נתונים

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

הנדסת נתונים ל-ML היא לא רק ETL. זה בניית תשתית נתונים ניתנת לשחזור שהופכת אימון מודלים לאמין ואימון מחדש לצפוי. מניסיון הצוות שלנו (8 שנים בהנדסת נתונים, מעל 30 פרויקטי ML), כל בעיה שנייה בפרודקשן קשורה לא לארכיטקטורת המודל אלא לשלמות מערך הנתונים.

במה שונים צינורות ETL ל-ML מ-BI?

ETL לאנליטיקה ו-ETL ל-ML הם משימות שונות. אנליטיקה צריכה אגרגציה, ML צריך רשומות בודדות עם היסטוריה. אנליטיקה לא דורשת חלוקת train/val/test, ML כן. הטיה באנליטיקה מפריעה לפרשנות, ב-ML היא משפיעה ישירות על איכות המודל.

כלים. Apache Spark לנפחים גדולים (10GB+): PySpark עם DataFrames, אופטימיזציות באמצעות partitioning ו-caching. dbt לטרנספורמציות על גבי DWH (Snowflake, BigQuery, Redshift) — דקלרטיבי, מנוהל גרסאות, נבדק. Pandas + Polars לנפחים עד כמה GB — Polars מהיר פי 5‑10 מ-Pandas בטרנספורמציות טיפוסיות.

חלוקות זמניות. ל-ML חשוב שהחלוקה תהיה לפי זמן, לא אקראית. אם הנתונים זמניים (טרנזקציות, אירועי משתמש), חלוקה אקראית גורמת לדליפת נתונים: המודל רואה נתונים עתידיים במהלך האימון. כלל: אימון על תקופה T1‑T2, walidation על T2‑T3 (עם פער למניעת דליפה), test על T3‑T4. חלוקה שגויה יכולה לעלות 10–15% מאיכות המודל ב-validation.

צינורות מצטברים. המודל מאומן מחדש מדי שבוע על נתונים חדשים. יש צורך בצינור שמוסיף בהדרגה רשומות חדשות למערך האימון מבלי לטעון הכל מחדש. Delta Lake או Apache Iceberg — פורמטים עם טרנזקציות ACID, Change Data Capture, time travel.

מה גורם ל-Training‑Serving Skew ואיך להימנע ממנו?

Feature Store פותר את בעיית חוסר הסנכרון בין אימון ל-inference. השגיאה הערמומית ביותר בתשתית ML היא training‑serving skew: תכונה מחושבת אחרת באימון ובפרודקשן. המודל לומד על נתונים נכונים, אבל ה-inference מקבל ערכים שונים.

Feast (קוד פתוח) — חנות offline על Parquet/Delta ב-S3 לאימון, חנות online על Redis ל-inference עם זמן השהיה נמוך (<10ms). הגדרות תכונות כקוד Python:

from feast import FeatureView, Field from feast.types import Float32, Int64 user_features = FeatureView( name="user_features", entities=["user_id"], schema=[ Field(name="purchase_count_7d", dtype=Int64), Field(name="avg_session_duration", dtype=Float32), ], ttl=timedelta(days=7), source=user_features_source, ) 

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

תכונות סטרימינג. כאשר צריך לעדכן תכונה בזמן אמת (מספר טרנזקציות ב-10 הדקות האחרונות), נדרש עיבוד סטרימינג. Apache Kafka + Apache Flink או Kafka Streams לחישוב תכונות בזמן אמת → כתיבה לחנות online. יותר מורכב, יותר יקר, נדרש רק כשהתיישנות התכונה קריטית לאיכות. לדוגמה, צינור זיהוי הונאות דרש p99 latency מתחת ל-200ms לעדכוני תכונות.

תיוג נתונים: איך לא לבזבז תקציב

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

Label Studio — קוד פתוח, תומך בתיוג תמונות (bounding box, polygon, segmentation), טקסט (NER, classification), אודיו, וידאו. נפרס תוך 10 דקות באמצעות Docker. לצוותים קטנים — הבחירה הראשונה.

הערכת איכות תיוג. Inter‑annotator agreement — מידת ההסכמה בין המתייגים. Cohen’s Kappa > 0.8 — טוב, 0.6‑0.8 — סביר, < 0.6 — המשימה מעורפלת או ההנחיות גרועות. חפיפת תיוגים (10‑20% מהדוגמאות מתויגות על ידי שני מתייגים עצמאיים) היא פרקטיקה חובה.

למידה אקטיבית מונעת בזבוז תקציב. אל תתייגו דוגמאות אקראיות; בחרו את אלה שבהן המודל הכי פחות בטוח (ביטחון נמוך, אי-ודאות גבוהה). מאפשרת להשיג את אותה איכות עם 50‑70% מנפח התיוג. Modals, Prodigy, Label Studio תומכים בזרימות למידה אקטיבית. בפרויקט NLP אחד, צמצמנו את תקציב התיוג פי 2.5 באמצעות למידה אקטיבית — חיסכון של כ-$18,000 לאורך חיי הפרויקט.

נתונים סינתטיים. כאשר נתונים אמיתיים נדירים או יקרים להשגה. ל-CV: רינדור ב-Blender/Unity עם טקסטורות ריאליסטיות (domain randomization). ל-NLP: פרפרזה באמצעות LLM, backtranslation. סיכון: המודל לומד את ההתפלגות של נתונים סינתטיים, לא נתונים אמיתיים — נדרשת זהירות ו-validation על holdout אמיתי.

איכות נתונים: ולידציה וניטור

Great Expectations — דה פקטו סטנדרט לולידציית נתונים בצינורות ML. Expectations הן הצהרות דקלרטיביות על נתונים: "עמודה from feast import FeatureView, Field from feast.types import Float32, Int64 user_features = FeatureView( name="user_features", entities=["user_id"], schema=[ Field(name="purchase_count_7d", dtype=Int64), Field(name="avg_session_duration", dtype=Float32), ], ttl=timedelta(days=7), source=user_features_source, ) מכילה ערכים מ-0 עד 120", "לעמודה age אין nulls", "ההתפלגות של user_id לא חורגת ביותר מ-20% מקו הבסיס". רץ בצינור, ובכישלון חוסם את ההמשך. כפי שנכתב בתיעוד הרשמי, Great Expectations מבטיח חוזי נתונים בין צוותים.

Pandera — אלטרנטיבה פייתונית ל-pandas/polars DataFrames. ולידציה מבוססת סכמה עם type hints:

import pandera as pa schema = pa.DataFrameSchema({ "user_id": pa.Column(int, nullable=False), "score": pa.Column(float, pa.Check.between(0, 1)), "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])), }) 

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

הסרת כפילויות. כפילויות במערך האימון מנפחות מדדים (אותן דוגמאות ב-train וב-val) ומעוותות משקלי מודל. MinHash LSH להסרת כפילויות משוערת של מערכי נתונים גדולים. לדיוק — hash לפי תוכן מנורמל.

השוואת כלי ולידציה

מה כולל פרויקט הנדסת נתונים ל-ML?

אנחנו מספקים את המחזור המלא:

• ביקורת נתונים וצינורות קיימים (שבוע).
• עיצוב ארכיטקטורה: בחירת כלים, פורמטים, שיטות תיוג.
• יישום צינור ETL/ELT עם ולידציה וניטור.
• תיעוד קוד ותהליכים (model card, data card).
• הכשרת הצוות שלך לתפעול הצינור.
• תמיכה לאחר פריסה למשך 3 חודשים.
• גישה למאגר הקוד ולכל הגדרות הצינור.

איך אנחנו בונים צינור: שלב אחר שלב

1. ביקורת נתונים קיימים. פרופיילינג: ydata‑profiling (לשעבר pandas‑profiling) מייצר דוח HTML עם סטטיסטיקות, התפלגויות, קורלציות, ערכים חסרים תוך דקות. אנחנו גם מבצעים בדיקת שלמות נתונים – בעיות טיפוסיות כוללות 30‑50% חותמות זמן חסרות או סחיפת סכמה.
2. עיצוב צינור. הגדרת מקורות נתונים, תדירות עדכון, דרישות זמן השהיה לתכונות, נפחים. דוגמה: צינור בזמן אמת למנוע המלצות דורש זמן השהיה מתחת ל-5 שניות ומעבד 1TB/יום.
3. יישום ובדיקות. בדיקות יחידה על טרנספורמציות, בדיקות אינטגרציה על הצינור, ולידציית נתונים באמצעות Great Expectations. אנחנו שואפים ל-95% כיסוי בדיקות ללוגיקת הטרנספורמציה.
4. פריסה וניטור. התראות על טריות, בדיקות איכות, חריגות בנפחי נתונים. סף התראה טיפוסי: אין נתונים חדשים במשך שעתיים.

אחסון ופורמטים

לרוב פרויקטי ה-ML בהתחלה: Parquet ב-S3 + DVC לניהול גרסאות. Delta Lake או Iceberg כאשר נדרשים עדכונים מצטברים או time travel.

למה לסמוך עלינו

אנחנו עובדים בהנדסת נתונים ו-ML למעלה מ-8 שנים. בתקופה זו השלמנו יותר מ-40 פרויקטים — מבניית צינורות למודלי NLP ועד תיוג מערכי נתונים לראייה ממוחשבת. אנחנו מבטיחים שחזוריות צינור ושקיפות תהליך מלאה. בכל פרויקט אנחנו משתמשים בכלי קוד פתוח כך שלא תהיו קשורים לספק.

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