AI Data Pipelines — ETL/ELT עם שכבת Intelligence

מאת צוות מדיה דיל · 09.08.2026 · Technology · 8 דק׳

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

מהנדס דאטה שמסתכל על pipeline קלאסי של ETL רואה שרשרת ברורה: חילוץ מהמקור, טרנספורמציה לפי חוקים קבועים, וטעינה ליעד. זה עבד מצוין כשכל הנתונים היו טבלאות מובנות עם סכימה ידועה מראש. אבל ברגע שהארגון רוצה להזין למחסן הנתונים גם תמלולי שיחות תמיכה, גם תוכן פניות פתוחות בטקסט חופשי, וגם תוצרים ממודלי AI עצמם - החוקים הקבועים כבר לא מספיקים. AI Data Pipelines הוא הדור הבא של ETL/ELT: לא רק העברת נתונים ממקום למקום, אלא שכבת אינטליגנציה שמסווגת, מעשירה, מנקה ומבנה נתונים תוך כדי התהליך, לא רק אחריו.

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

למה ETL קלאסי לא מספיק לנתוני AI

ETL מסורתי מניח שכל שלב טרנספורמציה הוא דטרמיניסטי - אותו קלט תמיד מייצר אותו פלט, וזה מה שמאפשר שחזור, בדיקות ו-idempotency. ברגע שמכניסים שלב שקורא ל-LLM (למשל, סיווג רגש בפנייה, חילוץ ישויות מטקסט חופשי), הדטרמיניזם הזה נשבר - אותו קלט יכול להניב תוצאה מעט שונה בין הרצה להרצה, והשלב עצמו יכול להיכשל בדרכים שלא קיימות בטרנספורמציית SQL רגילה.

המשמעות המעשית היא שצריך לעצב את הצנרת מחדש סביב ההנחה שהשלבים ה"חכמים" הם לא-דטרמיניסטיים ופגיעים יותר: עם retry logic ייעודי, עם validation שבודק שהפלט של המודל תקין ולא רק שהקריאה הצליחה טכנית, ועם מנגנון fallback למקרה שהמודל נכשל שוב ושוב על רשומה מסוימת - כדי שרשומה בעייתית אחת לא תעצור את כל הצנרת.

ארכיטקטורת Pipeline עם שכבת AI

המבנה הטיפוסי כולל שלבים קלאסיים (extract, load) לצד שלבי AI ממוקדים: סיווג (classification) שממיין רשומות לקטגוריות, חילוץ (extraction) שמוציא שדות מובנים מטקסט חופשי, העשרה (enrichment) שמוסיפה מטא-דאטה כמו embeddings או תגיות, ו-ולידציה שבודקת את איכות התוצר. חשוב לתכנן כל שלב AI כיחידה עצמאית עם ממשק קלט-פלט ברור, כדי שאפשר יהיה להחליף מודל או להוסיף בדיקת איכות בלי לשבור את שאר הצנרת.

Orchestration ותזמון

שכבת ה-orchestration (למשל Airflow או כלי דומה) צריכה להכיר בכך ששלבי AI לוקחים זמן משתנה ועלולים להיכשל בשיעור גבוה יותר משלבי SQL קלאסיים. תכנון תורים נפרדים לשלבי AI, עם concurrency מוגבל (כדי לא לחרוג ממכסות ה-API של ספק המודל) ועם timeout ריאלי לכל קריאה, הוא ההבדל בין צנרת שרצה יציב לבין אחת שנתקעת כל כמה ימים בגלל rate limit לא צפוי.

Batch מול Streaming בהקשר AI

לא כל שלב AI צריך לרוץ בזמן אמת. הרבה מהעשרות (כמו סיווג נושא של פנייה, או חילוץ ישויות ממסמך) יכולות לרוץ ב-batch לילי בעלות נמוכה משמעותית מריצה מיידית על כל רשומה. השאלה הנכונה היא לא "האם streaming טוב יותר" אלא "אילו צרכנים בפועל צריכים את הנתון המועשר תוך שניות, ואילו יכולים לחכות עד המחזור הבא". הרחבה מלאה על ההבדל בין הגישות במדריך Real-Time AI Analytics.

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

ניהול עלויות בצנרת עם שלבי AI

קריאה למודל AI על כל רשומה בצנרת שמעבדת מיליוני שורות ביום יכולה להצטבר לעלות משמעותית מהר מאוד. תכנון עלויות נכון כולל שימוש במודלים קטנים וזולים לשלבי סיווג פשוטים, שמירה על caching לתוצאות שכבר חושבו (למשל, לא לחשב מחדש embedding לתוכן שלא השתנה), וניתוב דינמי בין מודלים לפי מורכבות המשימה - עקרונות שמפורטים במדריך AI Cost Engineering ובIntelligent Model Routing.

כדאי גם לבדוק באופן שוטף האם ניתן להחליף שלבים שרצים כרגע על מודל יקר במודל קטן ומאומן ייעודית (fine-tuned) למשימה הספציפית, שיכול להגיע לאיכות דומה בעלות נמוכה משמעותית עבור משימות סיווג צרות וחוזרות. שיקול נוסף שקל לפספס הוא עלות הכישלונות עצמם - אם שלב AI נכשל ומנגנון ה-retry מנסה שוב ושוב בלי backoff חכם, העלות המצטברת מהניסיונות הכושלים יכולה לחרוג משמעותית מהעלות של הריצה המוצלחת. backoff אקספוננציאלי עם מספר ניסיונות מוגבל, כפי שמתואר במדריך Agent Retry Architecture, מונע את התרחיש הזה.

איכות נתונים ו-Validation לשלבי AI

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

בניית ערכת evals קבועה לצנרת עצמה, לא רק למודל בבידוד, חשובה לא פחות - צריך למדוד לאורך זמן את שיעור הרשומות שעוברות ולידציה בהצלחה, לא רק את איכות המודל בבדיקה חד-פעמית. שינוי בהתפלגות הנתונים הנכנסים (data drift) יכול לפגוע באיכות התוצר גם בלי שהמודל עצמו השתנה. הרחבה במדריך LLM Evals.

Observability לצנרת AI

צנרת נתונים קלאסית נמדדת לפי זמן ריצה ושיעור הצלחה טכני. צנרת עם שלבי AI צריכה שכבת ניטור עשירה יותר: לא רק "האם השלב רץ בהצלחה" אלא "האם התוצר שלו סביר". זה כולל מעקב אחרי התפלגות רמות הביטחון שהמודל מחזיר לאורך זמן (ירידה פתאומית בביטחון הממוצע יכולה להעיד על data drift), מעקב אחרי שיעור הרשומות שנופלות לתור הבדיקה הידנית, ומעקב אחרי עלות מצטברת לכל ריצת צנרת ביחס לתקציב שהוקצה. הרחבה מלאה על עקרונות אלה במדריך LLM Observability.

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

שילוב עם נתונים לא מובנים

חלק גדול מהערך של AI Data Pipelines מגיע דווקא מהיכולת לעבד מקורות שלא היו נגישים לצנרת קלאסית - מסמכים, מיילים, תמלולים. שילוב מקורות כאלה דורש שלב קדם-עיבוד ייעודי שהופך אותם לטקסט מובנה לפני שהם נכנסים לשלבי הסיווג וההעשרה - עקרונות שמפורטים בהרחבה במדריך Unstructured Data Engineering ובDocument Intelligence Architecture. חשוב לתכנן את הצנרת כך ששלבי הקדם-עיבוד האלה מופרדים משלבי ההעשרה הסמנטית, כדי שאפשר יהיה לשפר כל אחד בנפרד. הפרדה כזו מאפשרת גם למדוד את שיעור ההצלחה של כל שלב בנפרד - למשל, כמה אחוז מהמסמכים עברו חילוץ טקסט תקין לעומת כמה אחוז מהטקסט שחולץ עבר סיווג נכון - במקום מדד מצטבר אחד שמסתיר איפה בדיוק הבעיה.

טעויות נפוצות

• הנחת דטרמיניזם בשלבי AI - טיפול בקריאת LLM כאילו היא טרנספורמציית SQL רגילה, בלי retry logic ו-validation ייעודיים.
• ריצת AI על כל רשומה בזמן אמת שלא לצורך - עלות מיותרת כשרוב הצרכנים יכולים לחכות למחזור batch.
• העדר תור בדיקה לרשומות שנכשלות - זריקת רשומות בעייתיות בשקט במקום להעביר אותן לבדיקה ולתקן את הסיבה השורשית.
• retry בלי backoff - ניסיונות חוזרים מיידיים שמצטברים לעלות גבוהה בלי לשפר את סיכויי ההצלחה.
• אין ניטור ל-data drift - הנחה שאיכות התוצר קבועה לאורך זמן בלי לבדוק שינויים בהתפלגות הנתונים הנכנסים.
• שכבת AI ושכבת קדם-עיבוד מעורבבות - קוד שממזג ניקוי טקסט בסיסי עם קריאות למודל באותו שלב, מה שמקשה על בדיקה, דיבוג והחלפת רכיבים בנפרד.
• העדר תיעוד גרסת מודל לכל רשומה - כשמתגלה בעיה בדיעבד, אין דרך לדעת אילו רשומות הושפעו מאיזו גרסת מודל או פרומפט.

דוגמה מהשטח

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

שאלות נפוצות

מה ההבדל בין AI Data Pipeline ל-ETL רגיל?

ETL רגיל מבצע טרנספורמציות דטרמיניסטיות מוגדרות מראש; AI Data Pipeline משלב שלבי סיווג, חילוץ והעשרה שמופעלים על ידי מודלים, עם כל האתגרים הנלווים של אמינות ועלות.

האם כדאי להריץ כל שלב AI בזמן אמת?

רק אם יש צורך עסקי מוכח בתגובה מיידית - רוב שלבי ההעשרה יכולים לרוץ ב-batch בעלות נמוכה משמעותית.

איך מתמודדים עם קריאות AI שנכשלות בצנרת?

עם retry עם backoff מוגבל, ותור בדיקה נפרד לרשומות שממשיכות להיכשל, כדי לא לעצור את כל הצנרת בגלל רשומה בעייתית בודדת.

איך מודדים איכות תוצר של שלב AI בצנרת?

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

מה קורה כשמודל חדש יוצא וצריך להחליף מודל בצנרת קיימת?

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

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

באמצעות ניתוב דינמי בין מודלים לפי מורכבות המשימה, caching לתוצאות שלא השתנו, ומעבר ל-batch עבור כל שלב שלא דורש תגובה מיידית.

איך מטפלים בנתונים לא מובנים בתוך אותה צנרת?

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

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

תגיות: AI data pipelines · ETL AI · ELT · data engineering · AI cost engineering · data validation

← חזרה לבלוג · צור קשר