ההחלטה — Prompt מול RAG מול Fine-Tune (ונוף 2026)

למה ההחלטה חשובה יותר מהאימון

Fine-tuning נשמע כמו הדבר הרציני. הוא מרגיש כמו שלב מתקדם: יש dataset, יש GPU, יש גרפים, יש מילים כמו LoRA ו-epochs. אבל בפועל, רוב הפרויקטים הקטנים נופלים הרבה לפני שהמודל רואה דוגמה אחת. הם נופלים כי בחרו טיפול לפני שאבחנו את הבעיה. זה כמו לקחת אנטיביוטיקה כי כואב הראש. אולי יש זיהום, אבל אולי לא שתיתם מים. בפרויקטי LLM, אותו בלבול עולה כסף, זמן, נתונים, ולפעמים גם אמון של לקוח.

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

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

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

אם הבעיה היא התנהגות עמידה, אז fine-tuning מתחיל להיות מועמד אמיתי. למשל, מודל שצריך לכתוב תמיד בקול מותג עברי-אנגלי מסוים, להחזיר JSON תקין גם אחרי אלפי בקשות, או לבצע reasoning בתחום צר בצורה שה-prompt לא מצליח לאכוף. כאן אנחנו לא מבקשים מהמודל לדעת עובדה חדשה. אנחנו מבקשים ממנו להפוך הרגל תגובה מסוים לברירת מחדל.

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

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

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

שלוש דרכים לתקן מודל: prompt, RAG, fine-tune

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

Prompt engineering הוא השכבה הראשונה. זה כולל system prompt, דוגמאות few-shot, פורמט פלט, רשימת איסורים, טון, תפקיד, וכל הוראה שאפשר להכניס ל-context. היתרון שלו ברור: הוא מהיר, זול, הפיך, וקל לבדיקה. החיסרון הוא שהוא לא תמיד יציב. אם ההוראה ארוכה מדי, אם המשתמש שולח קלט קשה, או אם יש הרבה מטרות סותרות, המודל יכול להתחיל להחליק.

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

Fine-tuning הוא שינוי הרגל. אתם נותנים למודל דוגמאות רבות של input/output, והוא לומד נטייה חדשה. לא בהכרח "ידע" חדש, אלא דרך תגובה. אם לימדתם אותו לכתוב תקצירי תמיכה בעברית במבנה קבוע, הוא ייטה לייצר את המבנה הזה גם בלי prompt ענק. אם לימדתם אותו להחזיר JSON עם שדות מסוימים, יש סיכוי טוב יותר שהוא יעמוד בזה. אם לימדתם אותו לענות כמו מותג מסוים, הטון עשוי להפוך עקבי יותר.

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

במערכת אמיתית, שלוש הדרכים גם יכולות לעבוד יחד. אפשר להתחיל ב-prompt שמגדיר את תפקיד המודל, להוסיף RAG שמביא מידע לקוח עדכני, ואז להשתמש ב-fine-tuning כדי שהמודל יענה תמיד בסגנון התמיכה של החברה. אבל הסדר חשוב. לא מתחילים מהשכבה הכבדה. מתחילים מהשכבה שמוכיחה שהבעיה קיימת ומצמצמת אי-ודאות.

חשבו על מוקד תמיכה של SaaS ישראלי. אם המודל לא יודע מה המחיר של החבילה החדשה, זה RAG או API. אם המודל יודע את המחיר אבל כותב תשובה קרה ולא אנושית, זה אולי prompt. אם אחרי עשרים prompts הוא עדיין נשמע לא כמו החברה, חוזר על ניסוחים גנריים, ולא מצליח לשמור על מבנה תגובה, זה מתחיל להריח כמו fine-tuning. הריח הזה צריך להיות מבוסס על דוגמאות, לא על תחושה.

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

עץ ההחלטה: חמש שאלות לפני fine-tuning

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

שאלה 1: האם הבעיה נפתרת ב-prompt קצר וברור? אם כן, אין fine-tuning. Prompt שעובד הוא לא פתרון נחות. הוא פתרון מצוין. אם אתם יכולים לתקן את הבעיה בשתי פסקאות system prompt, בדוגמה אחת, או בהגבלת פורמט, קחו את הניצחון. מודל מאומן דורש תחזוקה. Prompt דורש מסמך.

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

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

שאלה 4: האם הכשל הוא התנהגות חוזרת למרות prompt טוב? כאן fine-tuning נכנס לתמונה. אם בדקתם prompt טוב, הוספתם דוגמאות, צמצמתם משימות, ועדיין המודל נשבר באותה צורה, יש סיבה לחשוב שהבעיה אינה רק הוראה. למשל: המודל תמיד מתחיל במבוא ארוך, מתעלם מסגנון המותג, שובר JSON, או לא מפנים שיטת reasoning ייחודית.

שאלה 5: האם יש לכם דרך למדוד שיפור? אם לא, עוצרים. Fine-tuning בלי מדד הוא פרויקט תחושה. אתם צריכים held-out set: דוגמאות שלא נכנסות לאימון, עם תשובה רצויה או קריטריוני שיפוט. גם 20 דוגמאות טובות יכולות להספיק להתחלה. בלי זה, לא תדעו אם המודל החדש טוב יותר או רק מוכר לכם יותר.

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

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

Prompt first: מתי system prompt מספיק

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

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

נניח שיש לכם מוצר SaaS ישראלי, והמודל כותב תשובות תמיכה ארוכות מדי. לפני fine-tuning, נסו system prompt כמו: "אתה נציג תמיכה של חברה ישראלית. ענה בעברית קצרה, עד 120 מילים. התחל באמפתיה קצרה, ואז תן 3 צעדים. אל תציע החזר כספי בלי שהמשתמש ביקש. אם חסר מידע, שאל שאלה אחת." זה לא קסם. אבל אם זה פותר 80% מהמקרים, אין סיבה לאמן.

Prompt first מתאים במיוחד כאשר הידע כבר נמצא ב-context, כאשר המשימה אינה חוזרת מיליוני פעמים, וכאשר הדרישה היא סגנונית אבל פשוטה. למשל: "כתוב בעברית בגובה העיניים", "החזר bullet points בלבד", "אל תשתמש בסופרלטיבים", "הוסף שאלה בסוף". אלו הוראות שהרבה מודלים חזקים ב-2026 מצליחים לבצע היטב בלי fine-tuning.

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

הבדיקה המעשית היא פשוטה: בנו prompt משופר, הריצו אותו על 10 דוגמאות קשות, וסמנו כמה עברו. אם עברו 8 או יותר, כנראה תישארו ב-prompt. אם עברו 4-7, בדקו האם הכישלונות קשורים לידע או להתנהגות. אם עברו פחות מ-4, ייתכן שהמודל הבסיסי לא מתאים או שהמשימה לא מוגדרת. גם אז fine-tuning אינו אוטומטי; לפעמים צריך מודל בסיס אחר.

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

בדיקת prompt טובה גם מפרידה בין סוגי כישלון. אחרי כל דוגמה, אל תכתבו רק עבר/נכשל. כתבו למה נכשל: ארוך מדי, טון לא מתאים, שדה חסר, ידע לא נכון, סירוב לא מוצדק, או reasoning לא עקבי. אחרי עשר דוגמאות תראו דפוס. אם רוב הכישלונות הם אורך וטון, prompt או fine-tuning רלוונטיים. אם רוב הכישלונות הם עובדות חסרות, אתם לא בכיוון של fine-tuning. אם הכישלונות הם שדות JSON חסרים למרות הוראה ברורה, מתחיל להיות case לאימון.

עוד כלל שימושי: אל תשוו prompt גרוע למודל מאומן עתידי דמיוני. השוו prompt טוב למה שאימון אמור לתקן. זה נשמע טריוויאלי, אבל הרבה החלטות נעשות מול strawman. אנשים אומרים "ה-prompt שלנו לא עובד", ואז מסתבר שה-prompt אומר רק "כתוב בסגנון שלנו" בלי דוגמאות ובלי הגדרת סגנון. Fine-tuning אינו תחליף להגדרת דרישה. אם אתם לא יודעים להסביר את הסגנון, גם dataset לא יפתור את זה היטב.

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

אם אתם עובדים בעברית, בדקו גם מעבר בין עברית לאנגלית. הרבה מודלים נשמעים טוב באנגלית אבל מאבדים טון בעברית, או להפך: הם שומרים על עברית טבעית אבל שוברים מונחים מקצועיים. בפרויקטי brand voice ישראליים, הכשל האמיתי הוא לעיתים לא "עברית" אלא היחס בין עברית, English technical terms וקצב משפטים. Prompt baseline צריך לכלול את זה, אחרת תאמנו על בעיה שלא מדדתם.

הסיבה שאנחנו מתחילים כאן היא משמעת. Vibe Coders אוהבים לקפוץ לבנייה, וזה טוב. אבל fine-tuning הוא בנייה עם inertia. ברגע שיש dataset, training script, adapters ו-eval, קשה יותר להודות שהבעיה הייתה prompt. לכן הפרק מאלץ אתכם להוציא את האופציה הזולה מהדרך בצורה מכובדת.

RAG first: מתי הבעיה היא ידע, מסמכים או citations

RAG, או Retrieval-Augmented Generation, הוא הפתרון כאשר המודל צריך לענות על בסיס חומר שנמצא מחוץ לזיכרון שלו. זה יכול להיות מאגר מסמכי חברה, קטלוג מוצרים, knowledge base, חוזים, מאמרים, נתוני לקוח, או מסמכי מדיניות. במקום להכניס את הכול לאימון, מחפשים בזמן אמת את החלקים הרלוונטיים ומכניסים אותם ל-context.

הדבר החשוב: RAG פותר בעיית מקור. Fine-tuning פותר בעיית הרגל. אם אתם צריכים שהמודל יידע שהמחיר של חבילת Pro השתנה מ-199 ש"ח ל-249 ש"ח, אל תאמןו אותו. עדכנו מסמך או בסיס נתונים. אם אתם צריכים שהוא יביא סעיף מתוך חוזה ויציין מאיפה הוא לקח אותו, אל תאמןו אותו. תנו לו retrieval עם citation.

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

יש גם חסרונות. RAG דורש תחזוקה. צריך לבחור chunk size, לייצר embeddings, לבדוק top-k, לטפל במסמכים כפולים, ולוודא שהמודל לא מתעלם מה-context. הוא יכול להיכשל כאשר השליפה מביאה קטע לא נכון. הוא גם מוסיף latency ועלות. לכן RAG אינו "הפתרון הרציני" לכל דבר. הוא הפתרון הנכון כאשר מקור ועדכניות חשובים יותר מהרגל תגובה.

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

עוד דוגמה: חברת ecommerce רוצה צ'אט שממליץ מוצרים מהמלאי. המלאי משתנה. מחיר משתנה. משלוחים משתנים. זה לא fine-tuning. אתם צריכים retrieval או API לקטלוג. אפשר לאמן מודל על טון מכירתי או על מבנה תשובה, אבל לא על מלאי חי. מי שמאמן על מלאי יוצר מערכת שתישמע בטוחה ותטעה בדיוק במקום שבו אסור לטעות.

הקריטריון הפשוט: אם אתם צריכים לעדכן את התשובה בלי לאמן מחדש, RAG. אם אתם צריכים להראות מקור, RAG. אם אתם צריכים למחוק מידע בעתיד, RAG. אם אתם צריכים שהמודל יאמץ דפוס התנהגות גם כשהמידע כבר נמצא ב-context, fine-tuning יכול להיכנס, אבל רק אחרי שה-retrieval עובד.

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

דרך בדיקה פשוטה: קחו עשר שאלות שמייצגות משתמשים אמיתיים, ולכל שאלה כתבו איזה מסמך או סעיף אמור להישלף. הריצו retrieval בלבד, בלי לתת למודל לנסח תשובה, ובדקו אם המקור הנכון מופיע בתוצאות העליונות. אם המקור לא מופיע, הבעיה היא indexing, chunking או metadata. אם המקור מופיע אבל התשובה לא משתמשת בו, הבעיה היא prompt או reasoning. רק אם שני אלה עובדים וההתנהגות עדיין לא עקבית, fine-tuning חוזר לשולחן.

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

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

המסר אינו "RAG תמיד לפני fine-tuning". המסר הוא "RAG לפני fine-tuning כשמקור הידע הוא הבעיה". אם הידע יציב, ציבורי, ומופיע בכל prompt, RAG אולי מיותר. אם ההתנהגות היא הבעיה, RAG לא ישנה את אופי המודל. ההחלטה הטובה נולדת מהאבחנה, לא מהעדפה אישית לכלי.

Fine-tuning first: מתי באמת צריך שינוי התנהגותי עמיד

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

המקרה הראשון הוא brand voice. עסק ישראלי קטן יכול לרצות מודל שכותב כמו הצוות שלו: עברית טבעית, קצת אנגלית מקצועית, בלי התלהבות מלאכותית, בלי מילים כמו "מהפכני", ועם קצב משפטים מסוים. Prompt יכול לעזור, אבל אם אתם מייצרים מאות פוסטים, תגובות, ניוזלטרים ותסריטים, איכות עקבית עשויה להצדיק fine-tuning על דוגמאות טובות.

המקרה השני הוא schema compliance. אם המודל חייב להחזיר JSON תקין לפי schema קבוע, בלי שדות חסרים, בלי טקסט לפני או אחרי, ועם ערכים מדויקים, fine-tuning יכול לשפר עקביות. זה לא מחליף validation בקוד. תמיד צריך validator. אבל כאשר מודל בסיס שוב ושוב שובר פורמט למרות prompt טוב, דוגמאות אימון יכולות ללמד אותו את ההרגל.

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

בכל שלושת המקרים יש תנאי: אתם צריכים דוגמאות איכותיות. Fine-tuning אינו מחלץ איכות מתוך dataset חלש. אם יש לכם 30 דוגמאות מעורבבות, לא אחידות, עם טעויות, המודל ילמד בלבול. בפרק 3 נבנה dataset, אבל כבר עכשיו חשוב להבין: ההחלטה להתאמן היא גם התחייבות להכין נתונים. אין fine-tuning טוב בלי data discipline.

עוד תנאי: צריך held-out set. אם אתם מאמנים על כל הדוגמאות שיש לכם, ואז בודקים על אותן דוגמאות, אתם מודדים זיכרון. לא שיפור. שמרו לפחות 20 דוגמאות בצד. עבור כל אחת, הגדירו מה ייחשב הצלחה. ב-brand voice זה יכול להיות rubric. ב-JSON זה validator. ב-reasoning זה תשובה רצויה או שיפוט אנושי.

Fine-tuning מתאים במיוחד כאשר המשימה חוזרת הרבה. אם אתם צריכים עשר תשובות בחודש, אולי prompt מספיק. אם אתם צריכים אלפי תשובות, consistency הופכת לערך עסקי. ככל שהשימוש חוזר, כך שווה יותר להעביר את ההרגל מה-prompt לתוך מודל או adapter. זה לא רק איכות. זה גם חיסכון ב-context ובתחזוקת prompts ארוכים.

ועדיין, גם כש-fine-tuning מתאים, הוא לא בהכרח צריך להיות hosted. הקורס הזה בנוי סביב OSS כי ב-2026 הכלים החינמיים חזקים מספיק לרוב הלומדים: Unsloth, PEFT, TRL, Axolotl, Colab ו-Kaggle. Hosted יכול להיות טוב כשצריך endpoint מיידי או אין סבלנות לתשתית, אבל ברירת המחדל שלנו תהיה ללמוד את העיקרון ולבנות בעצמנו.

נוף 2026: מה חי, מה נסגר, ומה מסוכן לבנות עליו

חלק מההחלטה הוא להבין את הנוף. ב-2026, fine-tuning כבר אינו אומר "נכנסים לאיזה API גדול ולוחצים train". חלק מהמסלולים שהיו פופולריים במדריכים ישנים השתנו או נסגרו. חלק מהמסלולים החינמיים בקוד פתוח נעשו טובים יותר. וחלק מהמסלולים hosted עדיין קיימים, אבל דורשים חישוב עלות לפי tokens processed ולא לפי תחושה.

לפי מחקר הקורס, OpenAI fine-tuning מסומן כמסלול שנמצא ב-wind-down מאז 2026-05-08 ולא נגיש כמסלול עבודה פתוח ללקוחות חדשים. לקוחות קיימים תלויים במדיניות דפרקציה של מודלי הבסיס. זה לא אומר שאין לאף אחד בעולם מודל fine-tuned של OpenAI. זה אומר שלקורס הזה, שמלמד מסלול שאפשר להתחיל היום בלי תלות בחשבון ישן, לא נכון לבנות על OpenAI fine-tuning.

Gemini דומה מבחינת החלטה מעשית: מחקר הקורס מסמן את fine-tuning ב-Gemini API/AI Studio כלא זמין במסלול צרכני רגיל מאז 2025-05-27. דפי billing עדכניים עוסקים בגישה למודלים, tiers, prepay/postpay ו-spend caps, לא במסלול fine-tuning ללומד. לכן בפרק הזה Gemini הוא כלי prompt/RAG/API, לא יעד fine-tuning לקורס.

המסלול hosted הבולט שנשאר רלוונטי הוא Together AI. לפי דף התמחור שנבדק ב-2026-06-01, fine-tuning עד 16B מתומחר per 1M tokens processed: $0.48 ל-LoRA SFT, $0.54 ל-full SFT, $1.20 ל-LoRA DPO ו-$1.35 ל-full DPO. זה זול ביחס להרבה תשתיות, אבל זה לא תמיד "כמה שקלים וזהו". העלות היא פונקציה של גודל dataset, epochs ו-validation.

המסלול OSS הוא ברירת המחדל של הקורס. Unsloth מציע notebooks ל-Colab/Kaggle, PEFT מטפל ב-adapters, TRL v1.0 מאחד SFT/DPO/ORPO/GRPO, ו-Axolotl נותן מסלול YAML יותר production-grade. היתרון: אפשר ללמוד את העיקרון, לשמור שליטה, ולהריץ ניסויים קטנים ב-$0 על Kaggle או Colab כשיש GPU זמין. החיסרון: צריך לעבוד בתוך notebook, להבין קצת קבצים, ולנהל טעויות בעצמכם.

Hosted מול OSS הוא לא שאלה מוסרית. זו שאלה של זמן, שליטה, נתונים ותקציב. אם אתם יועצים שמכינים demo ללקוח מחר בבוקר, hosted יכול להיות שווה. אם אתם לומדים את התחום, רוצים להבין מה קורה, או עובדים עם נתונים רגישים, OSS נותן יותר שליטה. אם אין לכם מדד הצלחה, אף אחד מהמסלולים לא נכון עדיין.

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

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

ב-OSS, הסיכון שונה. הכלי לא בהכרח נסגר, אבל גרסאות משתנות. Notebook שעבד לפני כמה חודשים יכול להישבר בגלל dependency, שינוי tokenizer, או API של Trainer. לכן גם במסלול החינמי צריך לשמור גרסאות: שם מודל, גרסת ספרייה, commit של notebook אם יש, ותאריך הרצה. זה נשמע מוגזם לפרויקט קטן, עד שמנסים לשחזר תוצאה טובה ולא יודעים איך.

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

החלטה בוגרת ב-2026 נראית כך: לומדים על OSS כדי להבין את המכניקה, משתמשים ב-hosted כשנוחות וזמן מצדיקים זאת, ולא בונים על ספקים שמסלול fine-tuning שלהם לא ברור. זה גם יכין אתכם לפרקים הבאים. גם אם בסוף תבחרו hosted, תבינו מה קורה מאחורי הקלעים: dataset, tokens, epochs, adapters, evaluation ו-deployment.

הדבר המסוכן ביותר הוא מדריך ישן. ב-AI, מדריך בן שנה יכול להיות היסטוריה. אם tutorial אומר "פתחו את מסך fine-tuning ב-Gemini" או "לחצו על OpenAI fine-tuning החדש", בדקו תאריך. אם הוא לפני שינוי המדיניות, אל תבנו עליו. זה נכון במיוחד ללקוחות משלמים: ההבדל בין demo לבין workflow production הוא שהשני צריך לשרוד שינויי ספק.

עלות, פרטיות וסיכון: ההחלטה הישראלית הקטנה

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

עלות hosted נראית לפעמים זולה מאוד. $0.48 למיליון tokens נשמע כמעט כלום; בהמרה דוגמתית לפי 3.7 ש"ח לדולר זה בערך 1.8 ש"ח לפני מע"מ, עמלות ושינויי שער. אבל זו לא עלות "ל-run" בכל מצב. זה per 1M tokens processed. אם יש לכם dataset של 1M tokens, שלושה epochs ו-validation, העלות כבר גדלה. אם המודל גדול יותר או DPO, המחיר משתנה.

ב-OSS העלות הישירה יכולה להיות $0, אבל אין דבר כזה חינם לגמרי. יש זמן, תסכול, זמינות GPU, ניהול קבצים, נפילות session, ותחזוקה. Kaggle יכול לתת שעות GPU חינמיות, Colab יכול לתת T4, אבל זה לא SLA. לפרויקט למידה זה מעולה. לפרויקט לקוח עם דדליין מחר בבוקר, hosted או GPU שכור יכולים להיות החלטה עסקית טובה.

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

עוד סיכון הוא תחזוקת המודל אחרי האימון. מי אחראי לבדוק שהוא לא נשבר כשמחליפים base model? מי שומר את dataset? מי יודע לשחזר את run? איפה נשמר adapter? האם יש גרסה? אם התשובה היא "נראה אחר כך", fine-tuning כנראה מוקדם מדי. Prompt ו-RAG קלים יותר לשנות. מודל מאומן דורש discipline.

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

הפרק הזה אינו ייעוץ משפטי או פיננסי, אבל הוא כן דורש אחריות. אל תתנו למילה AI להוריד סטנדרט. אם לא הייתם מעלים מסמך לקוח ל-Google Drive ציבורי, אל תעלו אותו ל-training job בלי להבין את ההסכם. אם לא הייתם מבטיחים מחיר בלי לבדוק מחירון, אל תבטיחו cost של fine-tuning בלי לספור tokens.

תרגול: סווג/י שלוש משימות אמיתיות שלך

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

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

לכל משימה מלאו חמש עמודות. סוג הכשל: הוראות, ידע או התנהגות. דינמיות הידע: קבוע, משתנה חודשית, משתנה שבועית, משתנה בזמן אמת. פרטיות: ציבורי, פנימי, לקוחות, רגיש. מדד הצלחה: איך תבדקו שיפור. פתרון ראשון: prompt, RAG, fine-tune OSS, hosted, או עצירה.

העמודה החשובה ביותר היא "למה לא האפשרויות האחרות". אם בחרתם RAG, כתבו למה prompt לא מספיק ולמה fine-tuning לא נכון. אם בחרתם fine-tuning, כתבו למה prompt טוב נכשל ולמה RAG לא הבעיה. זה מכריח אתכם לחשוב כמו ארכיטקט, לא כמו מי שרוצה לשחק עם כלי חדש.

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

דוגמה מייצגת נוספת: סטארטאפ B2B קטן רוצה לסווג פניות מכירה נכנסות. אם הסיווג תלוי במידע שנמצא במייל עצמו ובקריטריונים פנימיים יציבים, fine-tuning או אפילו prompt חזק יכולים לעבוד. אם הסיווג תלוי בנתונים חיים מתוך CRM, כמו גודל לקוח, שלב pipeline או מוצר שנרכש, צריך retrieval או API. אם המודל פשוט לא מבין את שמות החבילות שלכם, ייתכן ש-RAG מספיק. אם הוא מבין אבל מדרג leads בסגנון שונה מהצוות, fine-tuning מתחיל להיות רלוונטי.

דוגמה שלישית: יוצר תוכן ישראלי רוצה מודל שכותב פתיחים לסרטונים בקול שלו. הידע כמעט לא משנה; הסגנון משנה מאוד. אם יש הרבה דוגמאות טובות, ואם אפשר למדוד איכות לפי rubric של טון, קצב, אורך ומבנה hook, זה מועמד יפה ל-fine-tuning קטן. אבל אם היוצר רוצה שהמודל יתייחס לכל טרנד TikTok חדש, הטרנדים עצמם לא שייכים לאימון. הם שייכים למקור עדכני שנכנס ל-context.

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

כשתמלאו את הטבלה, אל תתביישו לבחור "לא ידוע". זו תשובה טובה. "לא ידוע" אומר שיש ניסוי מקדים. אם אינכם יודעים האם prompt מספיק, הניסוי הבא הוא prompt baseline. אם אינכם יודעים האם הידע דינמי, בדקו מי מעדכן אותו ובאיזו תדירות. אם אינכם יודעים האם יש מספיק דוגמאות, ספרו אותן. החלטת fine-tuning טובה לא מוחקת אי-ודאות; היא הופכת אותה למשימות בדיקה קטנות.

העמודה "מדד הצלחה" היא המקום שבו רעיונות חלשים מתגלים. אם אינכם מצליחים לכתוב מדד, אתם לא מוכנים לאימון. מדד לא חייב להיות מושלם או אקדמי. הוא יכול להיות: "מתוך 20 inputs, לפחות 18 outputs הם JSON תקין", "שלושה אנשי צוות מדרגים 15 תשובות מעל 4 מתוך 5 בטון מותג", או "אף תשובה לא ממציאה מקור". המדד צריך להיות מספיק ברור כדי לעצור ויכוח.

העמודה "למה לא שתי האפשרויות האחרות" היא אימון חשיבה. אם בחרתם fine-tuning, כתבו למה prompt לא מספיק ולמה RAG לא פותר את הבעיה. אם קשה לכם לענות, כנראה הבחירה מוקדמת. אם בחרתם RAG, כתבו למה אימון יהיה מסוכן או מיותר. אם בחרתם prompt, כתבו מה יגרום לכם לשקול מסלול כבד יותר בעתיד. כך הטבלה הופכת למסמך חי, לא רק תרגיל.

בסוף, המועמד שלכם צריך להיות צר. לא "מודל שירות לקוחות לחברה" אלא "מודל שמנסח תגובת פתיחה וסיכום צעדים לפניות billing בעברית, עד 120 מילים, לפי 300 דוגמאות מאושרות, ונמדד על 20 פניות חדשות". הצרות הזו לא מגבילה אתכם; היא מאפשרת הצלחה. מודלים קטנים לומדים משימות צרות טוב יותר ממשימות ערפל, וגם אתם תלמדו מהר יותר.

בסוף התרגיל בחרו מועמד אחד בלבד להמשך הקורס. כן, רק אחד. אם יש לכם חמישה רעיונות, שמרו אותם בצד. הקורס צריך project thread חד. בפרק 2 נבדוק אם המועמד נכנס על GPU חינמי ומה המשמעות של LoRA/QLoRA. בפרק 3 נבנה dataset. בפרק 4 נאמן. אם תבחרו מועמד עמום, כל הפרקים יהיו עמומים.

מועמד טוב לפרק הבא נראה כך: "מודל קטן שכותב תשובות תמיכה בעברית בסגנון החברה, לפי דוגמאות ציבוריות/מאושרות, עם held-out set של 20 פניות, ומדד הצלחה של טון + מבנה + אורך." מועמד פחות טוב: "מודל שיודע הכול על החברה." הראשון התנהגותי ומדיד. השני הוא ערפל.

שגרת עבודה: לפני כל רעיון ל-fine-tuning

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

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

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

בפרויקטים קטנים, decision log גם מונע "זחילת fine-tuning". מתחילים עם משימה צרה, ואז מישהו מוסיף "אם כבר, שילמד גם את כל הידע שלנו", ואז עוד אדם מוסיף "ושיכתוב גם פוסטים", ובסוף יש dataset מעורבב שאף מודל קטן לא יכול ללמוד היטב. אם כל שינוי scope חייב להופיע בטבלה עם סיבה ומדד, הרבה הרחבות מיותרות נופלות לבד.

שגרה טובה כוללת גם handoff. אם היום אתם עובדים לבד ומחר תכניסו עוד מפתח, יועץ או לקוח, הוא צריך להבין מה כבר נבדק. שמרו את כרטיס הבעיה, עץ ההחלטה, שלוש המשימות, prompt baseline והמדד בתיקייה אחת. תנו שמות פשוטים: problem-card, decision-tree, task-classification, baseline-results. בפרקים הבאים נוסיף dataset ו-training artifacts לאותה שרשרת. ככה הפרויקט נשאר ניתן לשחזור.

עוד כלל: אל תתנו להצלחה קטנה להפוך אוטומטית ל-production. אם prompt baseline שיפר תוצאות, מצוין; הוא עדיין צריך בדיקה על דוגמאות חדשות. אם RAG הביא מקור נכון, מצוין; עדיין צריך לראות שהמודל לא ממציא סביבו. אם fine-tuning קטן ישפר held-out set בהמשך, מצוין; עדיין צריך לבדוק שהוא לא שכח יכולות אחרות. השגרה היא מה שמחזיק את ההתלהבות בתוך מסגרת בטוחה.

לבסוף, קבעו לעצמכם כלל עצירה. למשל: אם שני ניסויי prompt עוברים את המדד, לא מאמנים. אם retrieval נכשל להביא מקור נכון, לא מאמנים עד שמתקנים retrieval. אם אין 200 דוגמאות איכותיות או דרך לייצר אותן בפרק 3, לא מאמנים עדיין. כלל עצירה אינו פסימיות. הוא מאפשר לכם לומר כן ל-fine-tuning כשכל התנאים באמת קיימים.

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