מדוע שינוי התפלגות הוא האויב העיקרי של ML בייצור
לקוח מגיע עם מערך נתונים של 200 אלף שורות ושואל: "מדוע מודל הבסיס נותן דיוק של 87%, אבל בייצור הוא יורד ל-71%?" התשובה היא כמעט תמיד אותה תשובה — שינוי התפלגות בין נתוני אימון לנתוני הסקה שאיש לא מדד. כאן מתחיל פיתוח פתרונות AI אמיתי: לא עם בחירת ארכיטקטורה, אלא עם הבנת הנתונים.
אנחנו צוות עם ניסיון של 7 שנים ב-ML בייצור ויותר מ-50 פרויקטים שהושלמו. אנו בונים מערכות שעובדות תחת עומס: צינורות ניתנים לשחזור, גרסאות מודלים, ניטור סטיית נתונים ו-SLA להסקה מובטחים ב-P99. אין מחברות עם "תוצאות מבטיחות".
מה כוללים פתרונות פיתוח AI
ב-AI/ML אנו מתכוונים למחזור המלא: איסוף ותיוג נתונים, אימון, walidacja, פריסה, ניטור ואימון מחדש. כל שלב יכול להיות משימה עצמאית או חלק מפרויקט מקצה לקצה.
כיוונים שאנו עובדים איתם:
- LLM ו-Generative AI — כוונון עדין, צינורות RAG, מערכות מרובות סוכנים, פריסה באמצעות vLLM עם PagedAttention
- ראייה ממוחשבת — זיהוי אובייקטים, פילוח, OCR, זיהוי פנים, אנליטיקת וידאו
- NLP — NER, סיווג טקסט, ניתוח סנטימנט, חילוץ מידע, embeddings
- MLOps — תשתית אימון ופריסה, רישום מודלים, CI/CD למודלים, ניטור
- מערכות המלצה — סינון שיתופי, מבוסס תוכן, גישות היברידיות, שירות בזמן אמת
- הנדסת נתונים ל-ML — feature store, צינורות ETL, תיוג, איכות נתונים
- דיבור — ASR (זיהוי דיבור), TTS, הפרדת דוברים
איזה מחסן טכנולוגי אנו משתמשים ומדוע
בחירת הכלים תלויה במשימה, לא בהרגל.
אימון מודלים. PyTorch הוא המסגרת העיקרית. אנו שומרים על TensorFlow לפרויקטים legacy ו-TensorFlow Serving. אנו משתמשים ב-JAX כאשר יש צורך בביצועים גבוהים על TPU או גרדיאנטים מותאמים אישית. Hugging Face Transformers + PEFT + trl הוא הסטנדרט לעבודה עם מודלי שפה: LoRA, QLoRA, DPO, RLHF. DeepSpeed ו-FSDP לאימון מבוזר על מספר GPUs.
הסקה. vLLM עם PagedAttention עבור LLMs — מטפל ביותר מ-200 בקשות/שנייה עם זמן השהיה P99 < 800ms על A100, ומספק זמן השהיה נמוך פי 4 מפריסה נאיבית ללא continuous batching. ONNX Runtime + TensorRT עבור מודלי CV — מספק האצה פי 3-8 על פני הסקת PyTorch מקורית. bitsandbytes עבור קוונטיזציה INT4/INT8 ללא אובדן איכות משמעותי.
מאגרי וקטורים. pgvector לפרויקטים על PostgreSQL (אפס תלות בתשתית). Qdrant ו-Weaviate כאשר יש צורך בחיפוש וקטורי ברמת ייצור עם סינון וסקייל. FAISS עבור אינדקסים אופליין וניסויים. ChromaDB לפיתוח ואב-טיפוס.
תזמור LLM. LangChain עבור צינורות סוכנים מורכבים. LlamaIndex כאשר המשימה היא RAG על מסמכים. קריאות ישירות ל-OpenAI API, Claude API, Mistral API כאשר תזמור הוא מיותר.
MLOps. MLflow למעקב אחר ניסויים ורישום מודלים. Weights & Biases לפרויקטים עם ניסויים אינטנסיביים הדורשים ויזואליזציה ושיתוף פעולה. Kubeflow לצינורות ML על Kubernetes. DVC לגרסאות נתונים ומודלים.
מדוע GPU OOM הורג לוחות זמנים יותר מארכיטקטורה גרועה
זו אחת העצירות הנפוצות ביותר בפרויקטים אמיתיים. צוות בילה שבוע בבחירת ארכיטקטורה, השיק אימון של מודל 7B על A100 40GB — ו-10 דקות לאחר מכן OOM. הסיבות אופייניות.
ראשית: gradient_accumulation_steps לא מוגדר. עם batch_size=32 ואורך רצף של 2048 טוקנים, activations תופסים כ-18GB רק עבור מעבר קדימה. פתרון: הקטן batch ל-4 והגדר gradient_accumulation_steps=8, ה-batch האפקטיבי זהה, טביעת הזיכרון קטנה בהרבה.
שנית: אימון ב-fp32 במקום bf16. מעבר ל-torch_dtype=torch.bfloat16 ב-Hugging Face Trainer מחצית את צריכת הזיכרון. בארכיטקטורת Ampere (A100, A6000), bf16 עובד מהר יותר מ-fp16 וללא loss scaling.
שלישית: gradient checkpointing לא בשימוש. model.gradient_checkpointing_enable() מקריב 20-30% ממהירות האימון אבל מקצץ את זיכרון ה-activation פי 5-8. ברצפים ארוכים זה קריטי.
עם QLoRA המצב אפילו טוב יותר: קוונטיזציה של 4 ביט של המודל הבסיסי באמצעות bitsandbytes + מתאמי LoRA מאפשרת כוונון עדין של Llama-3 70B על שני A100 40GB. פרמטרים הניתנים לאימון הם כ-0.5% מהסך הכולל, אך תוצאת הכוונון העדין דומה לאימון מלא במשימות צרות. גישה זו מפחיתה את טביעת הזיכרון פי 4 בהשוואה לכוונון עדין מלא.
התפלגות לפי משימות אופייניות
הבנה איזה חלק של פרויקט לוקח הכי הרבה זמן עוזרת בתכנון נכון.
| משימה | נתונים | מודל | MLOps | סה"כ |
|---|---|---|---|---|
| כוונון עדין של LLM על נתונים ארגוניים | 30% | 40% | 30% | 100% |
| זיהוי CV בייצור | 40% | 35% | 25% | 100% |
| RAG על מסמכים | 25% | 30% | 45% | 100% |
| מערכת המלצות | 50% | 25% | 25% | 100% |
| NER על אוצר מילים מתמחה | 45% | 35% | 20% | 100% |
נתונים הם תמיד יקרים יותר ממה שזה נראה. זו לא פסימיות — זה ניסיון מעשרות פרויקטים.
כיצד לאמת את המערכת, לא רק את המודל
מודל עם F1 0.91 על קבוצת holdout אינו ערובה ל-F1 0.91 בייצור. הפער בין מדדים אופליין לאונליין מתרחש מכמה סיבות.
דליפה זמנית. Train מכיל נתונים עתידיים יחסית ל-validation. עם חלוקה אקראית על נתונים זמניים, זה קורה אוטומטית. הגישה הנכונה היא חלוקה זמנית עם פער בין train ל-val כדי לחסל דליפת תכונות.
סטיית תכונות. התפלגות נתוני הקלט משתנה עם הזמן. המודל מאומן על נתונים מתקופות קודמות, אבל היום התנהגות המשתמשים השתנתה. ניטור שינוי התפלגות באמצעות PSI (Population Stability Index) או KL-divergence הוא חובה עבור מערכות ML בייצור.
שינוי תוויות. יחס הכיתות בייצור שונה מהאימון. זה קריטי במיוחד בזיהוי הונאות ואבחון רפואי, שם חוסר איזון יכול להגיע ל-1:5000.
כדי לנטרל השפעות אלה, אנו משתמשים ב: stratified k-fold עם מודעות זמנית, כיול באמצעות Platt scaling או רגרסיה איזוטונית, כוונון סף למדדים עסקיים אמיתיים (לא דיוק, אלא precision@recall).
Generative AI בייצור: מגבלות אמיתיות
לפרויקטי LLM יש מאפיינים שלא מתוארים במדריכים. שלוש הבעיות הנפוצות ביותר.
הזיות ב-RAG. המודל עונה בביטחון על שאלה שאינה בהקשר. הסיבה היא לעתים קרובות לא המודל אלא שליפה גרועה: chunk_size=512 ללא חפיפה מוביל לכך שהתשובה הרלוונטית מחולקת בין שני chunks. פתרון: חפיפה של 20-30%, חיפוש היברידי (dense + sparse BM25), דירוג מחדש באמצעות cross-encoder (למשל, ms-marco-MiniLM-L-6-v2 מ-sentence-transformers).
זמן השהיה. פריסה נאיבית של מודל 13B על A10G בודד נותנת זמן השהיה P50 של כ-4 שניות — בלתי מקובל עבור יישומים אינטראקטיביים. vLLM עם PagedAttention ו-continuous batching מפחית זאת ל-600-900ms P50 תחת אותו עומס. לאופטימיזציה אגרסיבית עוד יותר: קוונטיזציה AWQ ל-4 ביט עם פגיעה מינימלית באיכות.
ניהול הקשר. עם חלון הקשר של 128k טוקנים, מודלים מתדרדרים באמצע ההקשר (lost in the middle). עבור מסמכים ארוכים, RAG היררכי עובד טוב יותר: תחילה שליפה גסה באמצעות embeddings של סיכום, ולאחר מכן שליפה עדינה באמצעות chunks מקוריים.
טכנולוגיות דיבור
משימות ASR מגיעות לעתים קרובות עם דרישה "לזהות אוצר מילים ספציפי לתחום" — מונחים רפואיים, מבנים משפטיים, שמות מוצרים. OpenAI Whisper large-v3 נותן WER בסיסי טוב, אבל על אוצר מילים מתמחה השגיאות גדלות בחדות.
כוונון עדין של Whisper באמצעות LoRA על קורפוס של 50-200 שעות של דיבור מתויג מפחית WER על אוצר מילים מתמחה פי 2-3. יתר על כן, מתאמים שוקלים 30-50MB — בניגוד למודל המלא (3GB עבור large-v3), קל לגרסא ולפרוס אותם.
להפרדת דוברים אנו משתמשים ב-pyannote.audio 3.x עם צינורות מאומנים מראש והתאמה אישית לתחום האקוסטי הספציפי.
שלבי פרויקט ותקציב משוער
ביקורת נתונים והגדרת בעיה. אנו בוחנים התפלגות כיתות, איכות תיוג, נפח ונוכחות דפוסים זמניים. לעתים קרובות המשימה מנוסחת מחדש: מ"לחזות נטישה" ל"דירוג לקוחות לפי הסתברות לנטישה ב-30 הימים הקרובים." זה משנה מדדים וארכיטקטורה.
בסיס תוך 1-2 שבועות. מודל פשוט עם צינור ניתן לשחזור. המטרה היא לנעול מדדים, להבטיח התאמת נתונים ולקבל נקודת ייחוס. XGBoost או רגרסיה לוגיסטית כבסיס עדיפים על רשת נוירונים ללא הבנת הבעיה.
שיפור איטרטיבי. הנדסת תכונות, בחירת ארכיטקטורה, כוונון היפרפרמטרים באמצעות Optuna או Ray Tune. כל ניסוי מתועד ב-MLflow או W&B — אחרת אי אפשר להבין מה באמת עזר.
אימות ובדיקות עומס. בדיקה על מקרי קצה, קלט עוין, בדיקות עומס. עבור LLMs: red teaming והערכת הזיות.
פריסה וניטור. שחרור Canary, בדיקות A/B, הגדרת התראות על מדדי איכות וסטיית נתונים. מודל ללא ניטור מתדרדר מבלי לשים לב.
לוחות זמנים ועלות משוערים
| סוג פרויקט | ציר זמן | עלות משוערת |
|---|---|---|
| אב-טיפוס על נתונים קיימים | 2-4 שבועות | צור קשר למחיר |
| מערכת ברמת ייצור עם MLOps | 3-6 חודשים | צור קשר למחיר |
| שילוב מודל מוכן | 1-3 שבועות | צור קשר למחיר |
העלות תלויה בנפח הנתונים, בדרישות החישוב ובמורכבות התשתית — מוערכת באופן אישי לאחר ביקורת המשימה. חיסכון בהסקה באמצעות אופטימיזציה (vLLM, קוונטיזציה) יכול להגיע ל-40% מהעלויות התפעוליות.
אילו תוצרים אתה מקבל לאחר פרויקט AI
כל התקשרות כוללת סט תקני של נכסים כדי להבטיח שחזור והעברה:
- דוח ביקורת נתונים (התפלגות, איכות, דפוסים זמניים, שגיאות תיוג)
- כרטיס מודל עם תצורת אימון, היפרפרמטרים ומדדים סופיים
- צינור ניתן לשחזור: DVC לנתונים, MLflow לניסויים, Docker לסביבות
- נקודת קצה פרוסה עם לוח מחוונים לניטור (השהיה P50/P95/P99, התראות סטייה)
- מפגש העברת ידע (שעתיים) ותיעוד מלא
- תמיכה של שבועיים לאחר ההשקה עם תגובה לתיקון חם תוך 4 שעות
באופציה, אנו מספקים לוחות מחוונים מותאמים אישית לבעלי עניין עסקיים ואינטגרציה עם ה-CI/CD הקיים שלך.
מדוע ניטור סטיית נתונים הוא דרישה בלתי ניתנת למשא ומתן
על פי תיעוד MLflow, מערכות ללא ניטור מתדרדרות בממוצע תוך חודשיים. זו לא תיאוריה — ראינו פרויקטים שבהם הדיוק ירד מ-91% ל-73% תוך שישה שבועות מכיוון שהתנהגות המשתמשים השתנתה עונתית. ניטור סטיית נתונים עם PSI והתראות ביצועים הוא הדרך היחידה לתפוס הידרדרות לפני שהיא משפיעה על מדדים עסקיים. אנו מבטיחים שהמודל שלך נכנס לייצור עם לפחות שלושה מדדי סטייה וטריגרים אוטומטיים לאימון מחדש.
טעויות נפוצות בתחילת פרויקט AI
- חוסר במדדי סטיית נתונים לפני פריסה
- שימוש רק בדיוק עבור כיתות לא מאוזנות
- חוסר ניטור זמן השהיה P99
- כוונון עדין של המודל כולו כאשר LoRA מספיק
- התעלמות מחלוקה זמנית במהלך אימות
- דילוג על הערכת עלות להסקה בקנה מידה
כיצד להתחיל את פרויקט ה-AI הראשון שלך מבלי לבזבז שישה חודשים
בדוק עד כמה המשימה שלך מוכנה לפתרון ML. קבל ייעוץ על הפרויקט שלך — הזמן ביקורת מקדימה של נתונים ודרישות. צור קשר כדי להעריך את המשימה שלך ולקבל מפת דרכים מפורטת עם הערכות זמן ועלות. אנו עובדים עם תשתית AWS/GCP מוסמכת ומבטיחים פרטיות נתונים.