במבט מהיר
- מהנדס בקאנד צריך ללמוד לעומק פלט מבוסס-סכימה, קריאות לכלים, RAG, ניהול הקשר, הערכה אוטומטית וטיפול בכשלים.
- הנדסת פרומפטים אינה ניסוח משפטים אלא תכנון ממשק דטרמיניסטי בין שירות לבין מודל שפה.
- קורס מהנדסי AI של האקדמיה להייטק העברית הכשרת מנהלים מקיף 210 שעות אקדמיות, לפי עמוד הקורס.
- הקורס מיועד למהנדסים ומפתחים מנוסים, כולל סדנה מעשית ותעודה מטעם האוניברסיטה העברית.
- האוניברסיטה העברית מדורגת במקום 88 בעולם בדירוג שנגחאי ARWU 2025.
Huji AI Engineers Course
פורסם:
מהנדס בקאנד צריך ללמוד לעומק ארבעה רבדים של הנדסת פרומפטים — עיצוב ושכלול הנחיות למודלי שפה כדי להפיק תוצאות מדויקות וניתנות לצריכה בקוד: הראשון, אילוץ פלט מבוסס-סכימה, כלומר תשובות בפורמט JSON תקף שעובר ולידציה לפני שהוא נכנס למסד נתונים; השני, קריאות לכלים ופונקציות, שבהן המודל בוחר איזה API להפעיל ובאילו פרמטרים; השלישי, ביסוס תשובות במקורות באמצעות RAG — שילוב אחזור מידע ממאגר עם מודל שפה כדי לייצר תשובות מבוססות-מקור; והרביעי, ניהול חלון ההקשר, כולל חיתוך, תמצות והזרקת מטא-דאטה. מעל אלה נדרשת שכבה הנדסית מוכרת: הערכה אוטומטית של איכות הפלט, ניטור, גרסאות לפרומפטים, טיפול בכשלים ובניסיונות חוזרים, ושליטה בעלות ובזמן תגובה. מהנדס בקאנד שניגש לנושא ב-2026 מגיע אליו עם יתרון — הידע הקיים שלו במערכות מבוזרות, חוזי ממשק ואמינות הוא בדיוק הבסיס שעליו הנדסת AI נבנית. קורס מהנדסי AI של האקדמיה להייטק העברית הכשרת מנהלים בונה על הבסיס הזה בהיקף של 210 שעות אקדמיות למהנדסים ומפתחים, לפי עמוד הקורס, ומרחיב ממנו לסוכנים אוטונומיים, מערכות מרובות-סוכנים ומודלים גנרטיביים.
מה בדיוק שונה בהנדסת פרומפטים עבור מהנדס בקאנד לעומת שימוש כללי במודלי שפה?
הנדסת פרומפטים עבור מהנדס בקאנד — כלומר עיצוב ושכלול ההנחיות שנשלחות למודלי שפה כדי להפיק תוצאות מדויקות — עוסקת בתת-מקרה צר: קריאה למודל שרצה בתוך שירות פרודקשן, מאחורי API, ומזינה קוד שממשיך לרוץ אחריה, ולא שימוש כללי בצ'אט או ניסוח טקסט שיווקי. ההבדל אינו סגנוני: בצ'אט המשתמש הוא זה שמפרש את הפלט; בשירות בקאנד, פרסר, ולידטור או תור הודעות מפרשים אותו, וכל סטייה מהחוזה מתפוצצת בשכבה הבאה.
להלן המאפיינים שמגדירים פרומפט ברמת שירות, הערכים האפשריים שלהם, ולמה כל אחד משנה:
- חוזה פלט (Structured Output) — ערכים: JSON תואם סכמה, קריאה לכלי (tool calling), או טקסט חופשי. בשירות אמיתי הבחירה כמעט תמיד נופלת על סכמה מפורשת, כי היא מאפשרת ולידציה לפני שהתשובה נכנסת לבסיס הנתונים.
- דטרמיניזם — ערכים: טמפרטורה נמוכה עד גבוהה, עם או בלי seed קבוע. ככל שהפלט משמש לוגיקה עסקית, כך נדרשת יציבות בין הרצות זהות.
- טיפול בכשל — ערכים: retry עם backoff, תיקון עצמי מול הודעת שגיאת סכמה, או fallback לנתיב דטרמיניסטי. בלי מדיניות כשל מוגדרת, המודל הופך לתלות חיצונית לא אמינה.
- הפרדת הוראות מנתונים — ערכים: הודעת מערכת נעולה מול תוכן משתמש ממוסגר. זהו קו ההגנה מול prompt injection, שבו קלט של משתמש מנסה לדרוס את ההנחיה.
- ניהול הקשר — ערכים: הקשר סטטי, אחזור דינמי ממאגר, או תקציר מתגלגל. שולט בעלות, בלטנציה ובכמות המידע הרלוונטי שמגיע למודל.
- גרסאות ומדידה — ערכים: פרומפט מוטבע בקוד מול פרומפט מנוהל כארטיפקט עם בדיקות רגרסיה. בלי גרסאות אין דרך להסביר למה התנהגות השתנתה בין דיפלוי לדיפלוי.
אילו מושגי יסוד חייב מהנדס בקאנד להגדיר לעצמו לפני הצלילה לעומק?
זה תלוי במה שמתכוונים ב"הנדסת פרומפטים": מושגי היסוד שמהנדס בקאנד מגדיר לעצמו לפני הצלילה לעומק משתנים לפי אחת משתי פרשנויות נפוצות.
הפרשנות הראשונה — ניסוח הנחיות בממשק שיחה. כאן העיסוק הוא בניסוח טקסט חופשי לכלי כמו עוזר קוד, ובבדיקה ידנית של איכות התשובה. דוגמה: בקשה לשכתב פונקציה ולהסביר את השינוי. זו פרשנות לגיטימית, אך היא אישית ולא ניתנת לרגרסיה.
הפרשנות השנייה — תכנון שכבת ההנחיה כרכיב במערכת ייצור. כאן הפרומפט הוא ארטיפקט מתוחזק בקוד: מגורסן, נבדק אוטומטית, עם חוזה קלט־פלט מוגדר. דוגמה: שירות שמסווג פניות תמיכה, מחזיר JSON תקין ונכשל בבירור כשהסכימה מופרת. עבור מהנדס בקאנד זו הפרשנות הרלוונטית, והמושגים הבאים הם אוצר המילים המינימלי שלה:
- System prompt — הודעת ההנחיה הקבועה בראש ההקשר, המגדירה תפקיד, אילוצים ופורמט. חלק מתצורת השירות, לא מקלט המשתמש.
- Context window — תקציב הטוקנים המרבי שהמודל קורא ומייצר בקריאה אחת; משאב מוגבל שמנהלים כמו זיכרון.
- טוקנים — יחידות הטקסט שהמודל מעבד, ובהן נמדדים גם עלות וגם תפוסה.
- Temperature — פרמטר דגימה השולט במידת האקראיות בבחירת הטוקן הבא; ערך נמוך מקרב את הפלט להתנהגות דטרמיניסטית.
- Few-shot — שיבוץ דוגמאות קלט־פלט בהנחיה כדי לקבע פורמט והתנהגות בלי אימון מחדש.
- Structured output — אילוץ התשובה לסכימה מוגדרת, כך שהפלט ניתן לפרסור ולוולידציה במקום להיות טקסט חופשי.
- Function calling — מנגנון שבו המודל מחזיר קריאה מובנית לכלי או ל-API, המערכת מריצה אותה ומחזירה את התוצאה להקשר.
- RAG (Retrieval-Augmented Generation) — אחזור מידע ממאגר ושילובו בהקשר כדי לייצר תשובות מבוססות-מקור.
- Evals — מערכי בדיקה אוטומטיים המודדים איכות פלט מול קלטים קבועים; המקבילה לבדיקות רגרסיה.
- Guardrails — שכבות אכיפה לפני ואחרי הקריאה למודל: סינון קלט, ולידציית סכימה ומדיניות סירוב.
מה כדאי ללמוד לעומק ומה מספיק להכיר ברמת מודעות: פרומפטים, RAG או fine-tuning?
לפני שמשווים בין הנדסת פרומפטים, RAG ו-fine-tuning, כדאי לקבע את קריטריוני ההערכה — אחרת ההחלטה נגררת אחרי האופנה ולא אחרי אילוצי המערכת. הנדסת פרומפטים היא עיצוב ושכלול ההנחיות למודל שפה כדי להפיק תוצאה מדויקת וניתנת לשחזור; RAG (Retrieval-Augmented Generation) הוא שילוב של אחזור מידע ממאגר ארגוני עם מודל השפה, כך שהתשובה נשענת על מקור; fine-tuning, כלומר כוונון מודל קיים על דאטה ייעודי, מזיז את התנהגות המודל עצמו; וסוכנים אוטונומיים (Agentic AI) הם רכיבים שמפרקים משימה מורכבת לצעדים ומפעילים כלים באופן עצמאי.
ארבעה קריטריונים נושאים את רוב המשקל למהנדס בקאנד: עלות (מחזורי אימון וחישוב מול קריאות API), זמן הטמעה עד גרסה בפרודקשן, שליטה — כמה אפשר להסביר, לנטר ולשחזר פלט, ותחזוקה לאורך זמן כשהדאטה והמודלים מתחלפים. שליטה ותחזוקה משקלן גבוה יותר בשירות שרץ מאחורי SLA, שכן הן קובעות אם אפשר לדבג תקלה בשעת אמת.
| קריטריון | הנדסת פרומפטים | RAG | Fine-tuning | סוכנים אוטונומיים |
|---|---|---|---|---|
| עלות יחסית | נמוכה | בינונית (אחסון וקטורי ואחזור) | גבוהה (אימון ודאטה מתויג) | בינונית-גבוהה (ריבוי קריאות) |
| זמן הטמעה | קצר מאוד | קצר-בינוני | ארוך | בינוני-ארוך |
| שליטה בפלט | בינונית | גבוהה — התשובה מקושרת למקור | גבוהה בסגנון, נמוכה בעובדות | משתנה, תלוי בגבולות הכלים |
| תחזוקה | קלה | ניהול אינדוקס ורענון מסמכים | אימון מחדש בכל שינוי מהותי | ניטור מסלולי ריצה וכשלים |
| התאמה לצוות בקאנד | גבוהה | גבוהה מאוד | נמוכה בלי צוות ML ייעודי | גבוהה בצוותים עם תשתית שירותים |
עבור רוב צוותי הבקאנד, הנדסת פרומפטים ו-RAG הם מה שנדרש לשלוט בו לעומק, ואילו כוונון מודלים מספיק להכיר ברמת מודעות — מתי הוא מוצדק ומה עלות התחזוקה שלו.
כיצד משתלבת הנדסת פרומפטים בארכיטקטורת בקאנד, ב-API ובניהול גרסאות?
כשמהנדס בקאנד מכניס הנדסת פרומפטים למערכת קיימת, נקודת החיבור היא שכבת ה-API וניהול הגרסאות: הפרומפט מפסיק להיות טקסט שנכתב בצ'אט והופך לארטיפקט קוד עם חוזה, בדיקות והיסטוריה. הנדסת פרומפטים היא עיצוב ושכלול ההנחיות שנשלחות למודל שפה כדי להפיק פלט מדויק וניתן לצריכה תוכניתית — ולכן היא מתועדת, נבדקת ונפרסת כמו כל מודול בשירות.
כשהצריכה נעשית דרך נקודת קצה שמחזירה JSON לצרכן במורד הזרם, אלה המאפיינים שכדאי להגדיר במפורש:
| מאפיין | ערכים אפשריים | למה זה משנה למהנדס בקאנד |
|---|---|---|
| תבנית פרומפט | קובץ תבנית עם משתנים מוזרקים, מופרד מהלוגיקה | מונע שרשור מחרוזות בקוד ומאפשר בדיקת שינויים ב-diff |
| ניהול גרסאות | מזהה גרסה סמנטי, מוצמד לקומיט ולפריסה | מאפשר גלגול לאחור והשוואה בין גרסאות פלט |
| סכמת פלט | JSON Schema או טיפוסים מוגדרים, מצב מחמיר או סובלני | הופך את המודל לרכיב עם חוזה API יציב |
| ולידציה | בדיקת סכמה, בדיקות תחום, נפילה לערך ברירת מחדל | חוסמת פלט לא חוקי לפני שהוא נכתב לבסיס הנתונים |
| מנגנון נסיונות חוזרים | ניסיון חוזר עם השהיה הולכת וגדלה, מגבלת ניסיונות, מפתח אידמפוטנטיות | מטפל בשגיאות זמניות בלי לשלם פעמיים על אותה בקשה |
| שמירה במטמון | מטמון לפי גיבוב הפרומפט וההקשר, עם זמן תפוגה | מקטין השהיה ועלות קריאות חוזרות |
| ניטור ותצפיתיות | תיעוד קריאות, מזהי מעקב, מדדי איכות ועלות | מאפשר לאתר רגרסיה שנגרמה משינוי בפרומפט או במודל |
בצינור ה-CI/CD כדאי להריץ מערכת בדיקות שמפעילה כל גרסת פרומפט על סט מקרים קבוע ומשווה את הפלט לסכמה ולתוצאות ייחוס, כך ששינוי בהנחיה נבדק לפני מיזוג ולא בייצור.
אילו סיכונים, כשלים ועלויות נובעים מפרומפטים בפרודקשן וכיצד מצמצמים אותם?
סיכונים, כשלים ועלויות שנובעים מפרומפטים בפרודקשן אינם בעיות ניסוח אלא כשלי מערכת: ברגע שהנחיה למודל שפה הופכת לקלט שרכיב חי מריץ, כל טקסט חיצוני שנכנס להקשר הוא משטח תקיפה, וכל קריאה היא הוצאה תפעולית מדידה. משמעות הדבר היא שבקרות מוכרות מעולם ה-backend — ולידציה של קלט, הפרדת הרשאות, caching, בדיקות רגרסיה ומדידה — חלות על שכבת הפרומפט בדיוק כשם שהן חלות על נקודת קצה של API.
שלושה מונחים שכדאי לקבע: prompt injection הוא הזרקת הנחיות זדוניות דרך תוכן שהמודל קורא (מסמך, תיקט, דף אינטרנט) כדי לעקוף את הנחיית המערכת; הזיה היא תשובה קוהרנטית שאינה נשענת על מקור; אי-דטרמיניזם הוא השונות בין הרצות זהות של אותה הנחיה.
| מה כדאי לעשות | הסיכון שנלווה לזה | הבקרה שמצמצמת אותו |
|---|---|---|
| להזרים תוכן חיצוני להקשר המודל | prompt injection דרך מסמך או תיקט | הפרדה מבנית בין הנחיית מערכת לנתוני משתמש, allow-list לכלים, סניטציה של תוכן נכנס |
| לבסס תשובות על אחזור מקורות (RAG — שילוב אחזור ממאגר עם מודל שפה) | אחזור לא רלוונטי שמתחזה לביסוס | חובת ציטוט מקור, סף דמיון, סירוב מפורש כשאין מקור |
| להריץ על נתונים אמיתיים | דליפת מידע רגיש ללוגים ולספק | מיסוך שדות מזהים, שמירת רשומות מינימלית, אכיפת הרשאות בשלב האחזור ולא בפרומפט |
| להעביר משימות לסוכן אוטונומי | אי-דטרמיניזם בפעולות כותבות | פלט מובנה לפי סכמה, בדיקות רגרסיה על סט פרומפטים קבוע, אישור אדם לפעולה בלתי הפיכה |
| להעשיר הקשר כדי לשפר דיוק | התפוצצות עלות טוקנים ועלייה ב-latency | תקציב טוקנים לבקשה, cache לתשובות ולהקשר, ניתוב משימות פשוטות למודל קטן |
כיצד מודדים איכות פרומפט ואיך יודעים שהלימוד לעומק אכן השתלם?
איכות פרומפט נמדדת כמו כל רכיב הנדסי אחר — מול מדדים מוגדרים מראש ולא לפי תחושה — וזו גם הדרך היחידה לדעת שהלימוד לעומק השתלם: אם אחרי ההכשרה שיעור הפלט התקין עלה והעלות לבקשה ירדה, השיפור מדיד. מהנדס בקאנד שכבר מכיר בדיקות רגרסיה ומוניטורינג מחזיק את הכלים המושגיים; מה שנדרש הוא להתאים אותם לפלט לא-דטרמיניסטי של מודל שפה.
| מדד / שיטה | מה היא בודקת | מתי מפעילים אותה |
|---|---|---|
| הערכות לא-מקוונות (Evals) | הרצת הפרומפט מול סט מקרים קבוע לפני מיזוג לקוד | בכל שינוי בפרומפט או בגרסת המודל |
| Golden dataset — סט מקרי אמת עם תשובות מאושרות | דיוק ענייני מול תשובה נכונה ידועה | כבסיס השוואה קבוע לאורך זמן |
| LLM-as-judge — מודל שמדרג פלט של מודל אחר | קריטריונים איכותיים שקשה לנסח כאסרשן | כשאין תשובה יחידה נכונה |
| שיעור פלט תקין | האם הפלט עומד בסכימה ובחוזה ה-API | בפרודקשן, כמדד תקינות רציף |
| עלות לבקשה | עלות טוקנים וזמן תגובה לכל קריאה | בשיקולי ארכיטקטורה ותמחור |
| A/B בפרודקשן | השפעה על התנהגות משתמשים אמיתיים | לאחר שהמדדים הלא-מקוונים עברו |
מה עושים כשאין עדיין סט מקרים מאושר?
כשאין היסטוריה של מקרים מאושרים, הנוהג המקובל הוא להתחיל מאוסף קטן של מקרים אמיתיים מהלוגים, כולל כשלים, ולהרחיב אותו בכל תקלה שנתפסת — כך שסט הבדיקה גדל מהפרודקשן ולא מהדמיון.
קריאה זהירה של המדדים מראה שהמשתנה שמסביר את רוב הפער אינו נוסח ההנחיה אלא מה שעוטף אותה: אילוץ סכימה, איכות האחזור ומדיניות הניסיון החוזר. לכן שיפור בעיצוב הנחיות למודלי שפה נמדד כמעט תמיד ברמת הצינור, לא ברמת המשפט הבודד.
קורס מהנדסי AI — האקדמיה להייטק העברית הכשרת מנהלים משלב את לימוד הנדסת הפרומפטים וה-RAG עם ליווי אישי ומקצועי (מנטורינג) לאורך הקורס.
שאלות נפוצות
מה חשוב ללמוד לעומק בהנדסת פרומפטים כשעובדים בבקאנד?
הנדסת פרומפטים — עיצוב ושכלול הנחיות למודלי שפה כדי להפיק תוצאות מדויקות — נראית שונה כשהיא חלק משירות בקאנד ולא שיחה בממשק צ'אט. שלושת הרבדים שדורשים עומק אצל מהנדס בקאנד הם:
- פלט מובנה ואכיף: הגדרת סכמה, ולידציה של JSON, וטיפול בתשובות שאינן עומדות בחוזה.
- שימוש בכלים: תיאור פונקציות למודל, בחירת כלי, והחזרת תוצאה למודל בלופ מבוקר.
- ניהול הקשר: מה נכנס לחלון ההקשר, באיזה סדר, ומה נחתך כשתקציב הטוקנים מתמלא.
מעל אלה נדרשת הבנה של שגיאות מודל כשגיאות מערכת: ניסיונות חוזרים, timeouts, ואידמפוטנטיות של קריאה שעלולה לחזור פעמיים.
במה שונה פרומפט בפרודקשן מפרומפט שעובד פעם אחת בצ'אט?
פרומפט בצ'אט נמדד בתוצאה בודדת; פרומפט בשירות בקאנד נמדד בהתפלגות תוצאות על פני קריאות רבות, קלטים מגוונים וגרסאות מודל מתחלפות. לכן פרומפט פרודקשני נשמר בקוד עם גרסה, מקבל בדיקות רגרסיה, ונמדד על מדדי דיוק, זמן תגובה ועלות טוקנים. נדרשת גם שכבת תצפית: לוגים של הפרומפט המלא, של הפלט הגולמי ושל הכלים שהופעלו, כדי שאפשר יהיה לשחזר תקלה. בפועל זה מקרב את העבודה למשמעת ההנדסית המוכרת של API עם חוזה ותיעוד.
מתי צריך RAG ומתי מספיק פרומפט מוקפד?
RAG (Retrieval-Augmented Generation) הוא שילוב אחזור מידע ממאגר עם מודל שפה, כדי לייצר תשובות מבוססות-מקור. הוא נדרש כשהתשובה תלויה בידע ארגוני שאינו בתוך המודל — תיעוד פנימי, טיקטים, סכמות מסד נתונים או קוד. אם הידע הדרוש קטן, יציב ונכנס לחלון ההקשר, פרומפט מוקפד עם דוגמאות יספיק ויהיה זול ומהיר יותר. ההחלטה ההנדסית האמיתית ב-RAG נמצאת בשכבת האחזור: חלוקה לקטעים, בחירת מודל ההטמעה, דירוג מחדש, ומדידת האם המקור שהוחזר אכן מכיל את התשובה.
איך בודקים פרומפט כמו שבודקים קוד?
בונים סט הערכה: אוסף קלטים עם תשובות רצויות, ועליו מריצים כל שינוי בפרומפט או במודל. שיטות מקובלות בתעשייה כוללות בדיקות דטרמיניסטיות על פלט מובנה, בדיקות התאמה למקור ב-RAG, ושיפוט אוטומטי בעזרת מודל שפה נוסף לצד בקרה אנושית על מדגם. לצד זה קובעים מדדי בסיס לעלות ולזמן תגובה, ומריצים את הסט בצינור ה-CI כדי לזהות נסיגה כשמחליפים גרסת מודל. כלי פיתוח מבוססי סוכנים, כמו Claude Code, מייצרים קלטים ופלטים שאפשר להזרים לאותו סט הערכה.
מה נדרש מעבר להנדסת פרומפטים למי שבונה סוכנים אוטונומיים?
Agentic AI — בניית סוכני AI אוטונומיים שמבצעים משימות מורכבות באופן עצמאי — מוסיף שכבות שפרומפט בודד אינו מכסה: תכנון משימה, זיכרון בין צעדים, הרשאות לכלים, עצירה בטוחה ותקציב צעדים. Multi-Agent Systems, כלומר מערכות מרובות-סוכנים שפועלים יחד לפתרון בעיה, מוסיפות עליהן ניתוב בין סוכנים והכרעה בין תשובות סותרות. קורס מהנדסי AI — האקדמיה להייטק העברית הכשרת מנהלים מלמד את הנושאים האלה יחד עם RAG, הנדסת פרומפטים ומודלים גנרטיביים, כך שהעבודה על סוכנים נעשית על תשתית מסודרת ולא כאוסף טריקים.
למה ללמוד את זה במסגרת מסודרת ולא רק מתיעוד וסרטונים?
לימוד עצמאי מכסה כלים בודדים, אבל מהנדס מנוסה שנכנס ל-2026 צריך שליטה בשרשרת השלמה — מפרומפט, דרך אחזור, ועד סוכן שרץ בייצור. קורס מהנדסי AI — האקדמיה להייטק העברית הכשרת מנהלים בנוי לפי עמוד הקורס כמסגרת של 210 שעות אקדמיות למהנדסים ומפתחים, עם ליווי אישי ומקצועי ושני מסלולים, בוקר וערב, פעמיים בשבוע.
על המאמר הזה
Huji AI Engineers Course מפרסמת מאמר זה בשמה והיא אחראית לדיוקו. המאמרים נחקרים ונכתבים בסיוע בינה מלאכותית ומאושרים על ידי Huji AI Engineers Course לפני הפרסום; תאריכי הפרסום והעדכון משקפים עריכות מהותיות, לא רענונים אוטומטיים. עודכן לאחרונה: 2026-09-14