מעבר ל-SFT — Preference Tuning, Image LoRAs, מסלול Hosted והערכה

למה SFT הוא לא סוף הסיפור

SFT, כלומר Supervised Fine-Tuning, לימד את המודל לחקות דוגמאות טובות. אם בחרתם dataset טוב, שמרתם על chat template תקין והרצתם אימון מסודר, המודל אמור לדבר יותר כמו שרציתם, להחזיר פורמט יציב יותר, או לפתור משימה צרה טוב יותר מה-base. אבל SFT לא תמיד מלמד העדפה. הוא אומר למודל: “ככה נראית תשובה טובה”. הוא לא תמיד אומר לו: “כשיש שתי תשובות אפשריות, זו עדיפה, וזו נראית מפתה אבל לא מספיק טובה”. ההבדל הזה קטן בניסוח וגדול מאוד במוצר.

נניח שאימנתם מודל לשירות לקוחות בעברית עבור חנות אונליין ישראלית. אחרי SFT הוא יודע לפתוח בברכה, לשמור על טון מותג, ולהחזיר תשובות קצרות. אבל כשלקוח כועס דורש החזר על משלוח מאוחר, המודל עדיין נוטה לאחת משתי בעיות: או שהוא מתנצל יותר מדי ומבטיח זיכוי בלי לבדוק מדיניות, או שהוא מצטט מדיניות באופן קר שמדליק את הלקוח עוד יותר. שתי התשובות “נראות” כמו תשובות שירות. רק אחת מהן עדיפה. כאן Preference Tuning נכנס לתמונה.

בפרק הזה לא נרוץ להוסיף טכניקה רק כי היא קיימת. פרק קפסטון טוב מתחיל בשאלה ההפוכה: מה הוכחתם עד עכשיו, ומה עדיין לא הוכחתם? אם המודל כבר עומד ב-18 מתוך 20 דוגמאות held-out, אין סיבה לגעת בו רק כדי להגיד שעשיתם DPO. אם הוא נכשל שוב ושוב באותו סוג החלטה, למשל בחירה בין תשובה מועילה לבין תשובה ארוכה מדי, אז preference tuning הוא מועמד רציני. אם הבעיה היא ידע חסר, preference tuning לא יתקן אותה. אם הבעיה היא נתונים דינמיים, RAG עדיין מתאים יותר. אם הבעיה היא interface, prompt wrapper או parser, חבל לבזבז GPU.

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

בפרופיל integration אנחנו מחברים כמה שכבות: data, אימון, export, evaluation, deployment, ותחזוקה. זו הסיבה שהפרק לא יכריח אתכם להריץ DPO או ORPO בפועל. אם אתם עובדים על מודל brand voice קטן, יכול להיות שהשלב הנכון הוא בכלל להוסיף 100 דוגמאות SFT ולשפר סינון. אם אתם עובדים על assistant פנימי שמדרג פניות מכירה, preference tuning יכול להיות בדיוק השלב שמלמד אותו להעדיף תשובות קצרות, בטוחות ומועילות. אם אתם בונים מוצר ויזואלי, Image LoRA יכול להיות הרחבה חכמה יותר מאשר עוד אימון טקסט. ואם אתם צריכים למסור תוצאה מחר בבוקר, hosted fine-tuning בתשלום יכול לחסוך זמן, גם אם הוא פחות “טהור” ממסלול OSS.

הקפסטון הסופי שלכם צריך להיות קטן מספיק כדי להסתיים, אבל רציני מספיק כדי ללמד. משימה טובה היא “מודל 2B שמחזיר תשובות שירות לקוחות בטון מותג עם שלוש רמות הסלמה”, “assistant שממיר brief של לקוח לסכמת JSON קבועה”, או “מודל שיודע לכתוב תקצירי product ads בסגנון משרד קטן בתל אביב”. משימה גרועה היא “מודל כללי לעסק שלי”. היא רחבה מדי, קשה להערכה, ותגרום לכם לפרש כל פלט כרמז במקום למדוד. בפרק הזה נשתמש בשאלה צרה, dataset צר, סט בדיקה צר, והחלטת פרסום צרה. צר זה לא חיסרון; צר זה מה שמאפשר להוכיח שיפור.

Preference Tuning: DPO מול ORPO

Preference Tuning הוא משפחה של שיטות שמלמדות את המודל להעדיף תשובה אחת על אחרת. במקום dataset שבו לכל prompt יש תשובה אחת נכונה, יש לנו זוג: chosen, התשובה שאנחנו רוצים שהמודל יאמץ, ו-rejected, תשובה שנראית אפשרית אבל פחות טובה. הרעיון מתאים במיוחד כשכבר יש למודל ידע בסיסי על המשימה, אבל הוא בוחר התנהגות לא רצויה: מאריך מדי, מתנצל מדי, מחזיר פורמט כמעט נכון, או מתעלם מאילוץ עסקי.

DPO, Direct Preference Optimization, הוא המסלול המוכר יותר. הוא לוקח זוגות chosen/rejected ומעדכן את המודל כך שהסיכוי לתשובה הנבחרת יעלה ביחס לתשובה הדחויה. מבחינת ה-vibe coder, היתרון הוא שהמושג פשוט: אם אתם יודעים להראות למודל “זו תשובה טובה וזו פחות”, אתם יכולים ללמד העדפות. מבחינת הפרקטיקה, החיסרון הוא ש-DPO בדרך כלל עובד טוב אחרי שיש בסיס SFT סביר. כלומר אתם לא מתחילים מאפס; אתם משפרים התנהגות של מודל שכבר למד את הפורמט, הטון או המשימה.

ORPO, Odds Ratio Preference Optimization, מעניין במיוחד למפתח סולו כי הוא מחבר שני דברים: instruction learning והעדפה. במקום לחשוב “קודם SFT ואז DPO”, ORPO יכול להיות מסלול שמאמן ישירות על preference-style data ומקטין שלב. זה לא קסם, וזה לא אומר שהוא תמיד עדיף. אבל בפרויקט קטן על GPU חינמי, כל שלב שנחסך חשוב. אם אין לכם כוח לנהל שני אימונים, שני checkpoints ושתי הערכות, ORPO הוא מועמד. אם כבר יש לכם מודל SFT טוב מפרק 4 וזוגות preference נקיים, DPO נשאר בחירה טבעית.

ב-TRL v1.0, משפחת trainers כמו SFTTrainer, DPOTrainer ו-ORPOTrainer נועדה לתת API דומה למדי: dataset, model, tokenizer, training args, ואז train. זה נוח כי הידע מפרק 4 לא נזרק. אותם מושגים חוזרים: batch size, gradient accumulation, learning rate, max sequence length, checkpoints. מה שמשתנה הוא צורת dataset והאופן שבו loss מחושב. לכן פרק זה לא ינסה ללמד API מלא מחדש; הוא ילמד את ההחלטה. מי שמבין את ההחלטה יוכל לתת ל-AI או ל-notebook קיים להשלים syntax. מי שלא מבין את ההחלטה יריץ trainer נכון על data לא נכון ויקבל מודל משכנע אך גרוע.

חשוב להבחין בין “תשובה גרועה” לבין “תשובה rejected טובה”. תשובה rejected טובה היא לא שטות. היא תשובה שהמודל יכול באמת לבחור, והיא פחות טובה מסיבה מוגדרת. לדוגמה, אם prompt מבקש תשובת support קצרה ללקוח שרוצה החזר, chosen יכולה להיות תשובה שמכירה בתסכול, מבקשת מספר הזמנה ומסבירה מדיניות בלי להבטיח החזר. rejected יכולה להיות תשובה מנומסת מדי שמבטיחה “נזכה אותך מיד” בלי בדיקה. זו rejected טובה כי היא מפתה: היא שירותית ונעימה, אבל מסוכנת לעסק.

לעומת זאת, rejected גרועה היא תשובה ריקה, לא קשורה, או קצרה באופן מגוחך. אם chosen ארוכה, מפורטת ומקצועית, ו-rejected היא “לא יודע”, המודל עלול ללמוד פשוט שארוך עדיף מקצר. אם chosen כתובה בעברית ו-rejected באנגלית, הוא ילמד שפה ולא איכות. אם chosen כוללת JSON תקין ו-rejected כוללת prose, הוא ילמד פורמט, לא העדפה. לפעמים זה בדיוק מה שרוצים; לרוב זה זיהום. Dataset preference טוב משווה תפוחים לתפוחים: אותו prompt, אותו הקשר, הבדל איכות ברור אחד.

בפרויקטים ישראליים קטנים, preference tuning יכול להועיל במקומות מאוד ספציפיים: תגובות שירות שמאזנות בין אמפתיה למדיניות, ניסוח הצעות מחיר שלא מבטיח הנחות לא מאושרות, תיעדוף פניות מכירה לפי התאמה ולא לפי התלהבות, או כתיבת טקסטים שיווקיים שנשארים ישירים ולא “אמריקאיים” מדי. שימו לב שכל הדוגמאות הן לא “להוסיף ידע”. הן ללמד שיפוט. אם אתם רוצים שהמודל ידע את מלאי המוצרים העדכני, זה RAG או API. אם אתם רוצים שהוא יעדיף ניסוח עסקי אחראי על פני ניסוח מתלהב מדי, זה Preference.

ומה לגבי כמות? לא צריך להתחיל מ-3,000 זוגות. לקפסטון, 20-50 זוגות איכותיים יכולים להספיק להחלטה אם יש דפוס. לא בהכרח לאימון סופי, אבל בהחלט כדי לראות אם הבעיה קיימת. אם אחרי 20 זוגות אתם לא מצליחים להסביר מה הופך chosen לטוב יותר, אתם כנראה עוד לא מוכנים ל-preference tuning. חזרו ל-rubric. אם אתם מצליחים להסביר אותו בקלות, יש לכם חומר עבודה. בהמשך אפשר להרחיב עם Claude כ-teacher או judge, אבל רק אחרי שכתבתם ידנית מספיק דוגמאות כדי לדעת מה אתם מחפשים.

לבנות Dataset Preference שלא מלמד רעש

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

הפורמט הפשוט ביותר לקפסטון הוא קובץ JSONL או CSV עם עמודות: prompt, chosen, rejected, reason, category. ה-category יכול להיות style, safety, policy, format, helpfulness, brevity, או domain-judgment. אל תשתמשו ביותר מדי קטגוריות בהתחלה. חמש מספיקות. אם תבנו taxonomy מפואר מדי, תבזבזו אנרגיה על מיון במקום על דוגמאות. המטרה היא להראות למודל דפוס חוזר: “במצב כזה, תשובה שמכבדת את האילוץ העסקי עדיפה על תשובה שמנסה לרצות את המשתמש בכל מחיר”.

הנה דוגמה מייצגת, לא מקרה אמיתי: חנות ישראלית קטנה מוכרת מוצרי טיפוח ומקבלת פניות WhatsApp. Prompt: “הלקוחה כועסת כי המשלוח מתעכב ארבעה ימים ורוצה החזר עכשיו”. chosen: “אני מבין/ה שזה מתסכל. כדי לבדוק אם אפשר לפתוח זיכוי או משלוח חלופי, שלחי בבקשה מספר הזמנה וטלפון. אם המשלוח לא יצא עד סוף יום העסקים, נציע פתרון לפי מדיניות ההחזר.” rejected: “מצטערים מאוד, נזכה אותך מיד ונשלח מוצר חדש כפיצוי.” ההבדל אינו נימוס. שתי התשובות מנומסות. ההבדל הוא שהראשונה לא מבטיחה פעולה לפני בדיקה.

כדאי לבנות את ה-dataset בשלוש שכבות. שכבה ראשונה: 10 זוגות ידניים, שנכתבים לאט ומייצגים את סוגי הטעויות המרכזיים. שכבה שנייה: הרחבה ל-50-100 זוגות בעזרת Claude או מודל teacher חזק, אבל עם prompt שמאלץ אותו לשמור על סימטריה בין chosen ל-rejected. שכבה שלישית: סינון עם judge rubric. אל תבקשו מה-judge “איזו תשובה טובה יותר?” בלבד. בקשו ציון לפי קריטריונים: האם נשמרה מדיניות, האם הטון מתאים, האם אין הבטחה לא מאושרת, האם התשובה מספיק קצרה, האם הפורמט תקין. ציון רב-ממדי מקטין את הסיכוי שהמודל ילמד העדפה שטחית.

אל תערבבו משימות רחוקות מדי באותו preference dataset. אם הקפסטון שלכם הוא brand voice לבלוג טכני, אל תכניסו גם פניות support וגם מודעות ממומנות וגם הודעות LinkedIn. לכאורה זה “עוד data”; בפועל זה מרחיב את ההתנהגות בלי סיבה. עדיף dataset קטן וממוקד על dataset גדול שמלמד את המודל שהמותג שלכם הוא הכל. אם אתם חייבים כמה סוגי משימות, הוסיפו system prompt או task field ברור, ודאגו שבכל סוג יש מספיק דוגמאות. שני זוגות לקטגוריה לא מלמדים דפוס; הם מלמדים רעש.

עוד נקודה קריטית היא מידע אישי ופרטיות. אם אתם משתמשים ב-support tickets אמיתיים מישראל, הסירו שמות, טלפונים, כתובות, מספרי הזמנה, פרטי אשראי וכל מזהה אחר. אל תסתפקו ב-“זה רק אימון קטן”. dataset שמסתובב ב-notebook, ב-Hugging Face או ב-Google Drive יכול לדלוף. כתבו anonymization step בתהליך. אם אתם עובדים עם לקוח, קבלו אישור כתוב לשימוש בדוגמאות. Fine-tuning קטן עדיין נוגע ב-data אמיתי, ו-data אמיתי גורר אחריות אמיתית.

לסיום החלק הזה, הגדירו “minimum viable preference dataset” עבור הקפסטון: 10 זוגות ידניים, 20 זוגות מורחבים, ו-5 זוגות שנפסלו בכוונה עם הסבר למה. הזוגות שנפסלו חשובים לא פחות מהנכנסים. הם מוכיחים שאתם יודעים לשמור על איכות. בפרויקט אמיתי, היכולת להגיד “לא נאמן על זה” היא חלק מהמקצוענות.

Image LoRAs: הרחבה ויזואלית אופציונלית

Image LoRA הוא אותו רעיון adapter, אבל למודל תמונה. במקום ללמד מודל טקסט טון או פורמט, מלמדים מודל כמו Flux ליצור סגנון, מוצר, דמות, אריזה, או visual identity. זה יכול להיות שדרוג אדיר לקפסטון אם המוצר שלכם ויזואלי: חנות Shopify קטנה שרוצה תמונות מוצר עקביות, מותג קוסמטיקה שרוצה רקעים באותו mood, יוצר תוכן שרוצה thumbnails בסגנון קבוע, או משרד פרסום שרוצה להראות ללקוח איך נראה “סגנון המותג” לפני יום צילום.

אבל Image LoRA הוא אופציונלי לחלוטין. אם הקפסטון שלכם טקסטואלי, אל תכניסו אותו כדי להרגיש שהפרק מלא. ההחלטה הנכונה יכולה להיות “דילגנו על Image LoRA כי אין צורך מוצרי”. זו לא חולשה. זו החלטת scope. מצד שני, אם אתם בונים brand voice cloner עבור עסק קטן בישראל, יכול להיות שהשילוב של מודל טקסט + Image LoRA הוא הצעת ערך יפה: המודל כותב caption בעברית טבעית, וה-LoRA מייצר תמונת מוצר באותו look. כאן הפרק נותן לכם דרך להעריך אם זה שווה את הזמן והכסף.

יש שלושה מסלולים מעשיים. הראשון הוא kohya_ss, כלי OSS מקומי שמיועד לאימון LoRA למודלי תמונה. היתרון: חינם, שליטה מלאה, לא מעלים תמונות לשרת חיצוני. החיסרון: setup, דרייברים, VRAM, וסבלנות. לפי baseline הקורס, קיימות זרימות שמאפשרות Flux LoRA גם על GPU צרכני קטן יחסית, אבל זה אזור שמשתנה מהר וצריך לבדוק מול התיעוד המעודכן לפני שמתחייבים. השני הוא fal.ai: מעלים ZIP של תמונות, בוחרים trainer, משלמים לפי run/steps, ומקבלים LoRA usable. השלישי הוא Replicate: API נוח, flow מתועד, תשלום לפי זמן GPU, ותוצאה שמגיעה כמודל hosted או weights.

נכון ל-1 ביוני 2026, דף fal.ai של FLUX.1 LoRA Fast Training מציג עלות של $2 per training run בברירת מחדל, והדף של FLUX.2 trainer מציג נוסחה של 0.008 * steps, כך ש-1000 steps עולים $8.00. Replicate מציג תמחור לפי זמן GPU; בדוגמת Flux API הרשמית הם מדברים על תקציב קטן של 2-3 דולר לאימון, ובדף pricing מופיע H100 סביב $0.001525 לשנייה. המספרים האלה לא נועדו להיות הבטחה. הם נועדו לתת סדר גודל. לפני run בתשלום, תמיד פותחים את דף התמחור הנוכחי.

איכות Image LoRA תלויה פחות במספרים ויותר באוסף התמונות. 10-20 תמונות טובות, עקביות ומותרות לשימוש עדיפות על 80 תמונות מעורבבות. אם אתם מאמנים style, התמונות צריכות לחלוק aesthetic ברור: תאורה, צבעים, זוויות, איכות. אם אתם מאמנים מוצר, ודאו שהמוצר מופיע מזוויות שונות אבל לא נבלע ברקע. אם אתם מאמנים אדם, היזהרו במיוחד: צריך אישור, צריך להימנע משימוש מטעה, וצריך להבין ש-LoRA כזה יכול לייצר תמונות רגישות. בפרויקט לימודי, עדיף להשתמש במוצר, illustration style או נכס שלכם, לא בפנים של אדם אחר.

Trigger word הוא מילת הפעלה ייחודית שמכניסים ל-prompt כדי להפעיל את הסגנון. אל תבחרו מילה רגילה כמו “style” או “nvision”. בחרו token ייחודי, למשל “NVFTX” או “ZAFRA_STYLE”, ותעדו אותו ב-Model Card. אחרי האימון, prompt בלי trigger word אמור להתנהג קרוב יותר למודל המקורי, ו-prompt עם trigger word אמור להציג את הסגנון. אם אין הבדל, האימון חלש. אם כל דבר נראה כמו dataset גם בלי trigger, יכול להיות שה-LoRA חזק מדי או overfit.

המסלול Hosted: מתי Together AI שווה את הכסף

עד עכשיו דחפנו חזק למסלול OSS: Kaggle, Colab, Unsloth, TRL, llama.cpp, Ollama. זה עדיין המסלול הנכון לרוב הלומדים בקורס הזה, במיוחד אם המטרה היא להבין, לשלוט ולשמור על עלות $0. אבל יש רגעים שבהם hosted fine-tuning הוא לא “כניעה”, אלא החלטה עסקית. אם אתם צריכים למסור proof ללקוח מחר, אם אין לכם GPU זמין, אם dataset גדול מדי ל-session חינמי, או אם אתם רוצים מודל גדול יותר ממה שנכנס בנוחות ל-T4, תשלום קטן יכול להיות ההחלטה הזולה באמת.

Together AI הוא המסלול hosted המרכזי שנשאר רלוונטי לפי baseline הקורס. הוא מתמחר fine-tuning לפי tokens processed: training tokens כפול epochs, ועוד validation tokens אם יש evaluation במהלך job. דף התמחור הציבורי מציג קטגוריות לפי גודל מודל וסוג fine-tuning. עבור מודלים עד 16B, המספר הפשוט שנשתמש בו להערכת LoRA הוא $0.48 למיליון tokens, כאשר עמודות אחרות בטבלה מציגות מחירים גבוהים יותר לפי full/specialized/DPO. אתם לא צריכים לזכור את הטבלה בעל פה. אתם כן צריכים לזכור את העיקרון: מחיר = tokens × epochs × סוג job.

דוגמה פשוטה: dataset של 1,000 דוגמאות, ממוצע 500 tokens לדוגמה, הוא בערך 500,000 tokens לאפוק אחד. שני epochs הם מיליון tokens. אם בחרתם LoRA קטן במסלול עד 16B, סדר הגודל יכול להיות סביב $0.48 לפני validation ושינויים. זה זול מאוד יחסית לזמן שלכם, אבל אל תתבלבלו: איטרציות מצטברות. שלושה runs, validation גדול, מודל גדול יותר, או DPO יעלו יותר. לכן Hosted לא פוטר אתכם מתכנון; הוא רק מעביר את כאב ה-GPU לכאב תקציב.

Hosted דורש גם החלטות data. אם אתם מעלים dataset של לקוח לספק חיצוני, בדקו חוזה, פרטיות, PII והרשאות. אם אתם עובדים על תוכן שיווקי כללי, הסיכון קטן יותר. אם אתם עובדים על פניות support אמיתיות, medical/legal/finance, או מידע פנימי של חברה, צריך אישור. אל תשתמשו ב-“זה רק fine-tune קטן” כתירוץ. מבחינת data governance, upload הוא upload. בפרויקט אישי זה פחות דרמטי; בפרויקט לקוח זה חלק מה-scope.

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

הערכה: Held-out קודם, Benchmark אחר כך

הפרק הזה יכול להצטמצם למשפט אחד: בלי evaluation, לא עשיתם fine-tuning; עשיתם שינוי. שינוי יכול להיות שיפור, קלקול או noise. כדי לדעת, צריך למדוד. המדידה הראשונה אינה MMLU, HellaSwag או HumanEval. המדידה הראשונה היא held-out set ספציפי למשימה שלכם: 20 prompts אמיתיים או מייצגים שלא הופיעו באימון, עם rubric ברור שמגדיר מהי תשובה טובה. אם המודל שלכם נועד לכתוב תגובות support, בדקו support. אם הוא נועד להחזיר JSON, בדקו JSON. Benchmark כללי בא אחרי זה, לא לפני.

סט held-out טוב בנוי כמו מבחן קבלה. הוא לא צריך להיות ענק. הוא כן צריך לכסות edge cases. אם dataset האימון שלכם כלל פניות שירות רגילות, ה-held-out צריך לכלול לקוח כועס, לקוח שמבקש חריגה ממדיניות, שאלה חסרה פרטים, בקשה בעברית מעורבת באנגלית, ושאלה שבה התשובה הנכונה היא “צריך נציג אנושי”. אם המודל נועד לכתוב מודעות, ה-held-out צריך לכלול מוצר פשוט, מוצר רגיש, תקציב נמוך, קהל ישראלי, ודרישה לפורמט. כל prompt מקבל expected behavior, לא necessarily expected text. אנחנו מודדים יכולת, לא שינון.

הבדיקה הבסיסית היא A/B מול ה-base. מריצים אותו prompt על base ועל המודל המאומן, בלי לשנות system prompt מעבר למה שנדרש להרצה תקינה. שומרים את שתי התשובות בטבלה ומדרגים לפי rubric 0-2: 0 = נכשל, 1 = חלקי, 2 = עבר. אם יש לכם 20 prompts, הציון המקסימלי הוא 40. שיפור אמיתי הוא לא “המודל המאומן נשמע יותר כמונו”, אלא “המודל המאומן קיבל 32/40 וה-base קיבל 21/40, ובקטגוריות החשובות אין נסיגה”. אם הפער קטן, אולי האימון לא שווה. אם הפער קיים אבל יש כשל חמור אחד, אולי צריך retrain או guardrail.

כדי להקטין הטיה, אפשר לערוך blind review קטן. הסתירו איזה פלט שייך לאיזה מודל ובקשו מעצמכם או מאדם אחר לדרג. זה נשמע מוגזם לפרויקט קטן, אבל הוא חושף אמת לא נוחה: לפעמים אנחנו אוהבים את המודל המאומן כי הוא שלנו. במיוחד במודלי brand voice, הנטייה הזו חזקה. blind review של 10 דוגמאות יכול למנוע מכם לפרסם מודל שמרגיש אישי אבל פחות מועיל.

אחרי held-out מגיע regression testing. כאן נכנס lm-evaluation-harness. הכלי הזה לא יגיד אם מודל ה-support שלכם עונה נכון למדיניות החנות. הוא כן יכול לתת אינדיקציה אם fine-tuning פגע ביכולת כללית: reasoning פשוט, commonsense, מתמטיקה, code, או משימות שפה. אם אימנתם מודל 1B-3B קטן, אל תצפו לציוני benchmark מדהימים. המטרה אינה leaderboard; המטרה היא לזהות ירידה חדה מול base. אם base קיבל 0.42 ב-HellaSwag והמודל המאומן 0.21, משהו השתבש. אם שניהם דומים, וה-held-out השתפר, יש לכם סיפור טוב.

הפקודה המדויקת תלויה בסביבה ובגרסת lm-eval, אבל העיקרון נראה כך: מתקינים backend מתאים, מצביעים על model או GGUF, בוחרים tasks, מריצים עם batch קטן, ושומרים output. עבור GGUF, התיעוד מזהיר שכדאי להעביר tokenizer נפרד כדי למנוע טעינה איטית או hang. אם אתם לא בטוחים, התחילו בקטן: task אחד, limit קטן, batch size נמוך. אל תבזבזו יום על benchmark מושלם. לקפסטון מספיק regression check צנוע ומתועד.

pip install "lm_eval[hf]"
lm_eval --model hf \
  --model_args pretrained=./merged-model,tokenizer=./merged-model \
  --tasks hellaswag \
  --device cuda:0 \
  --batch_size 4 \
  --output_path eval-results

מה עושים עם התוצאות? אם held-out השתפר ואין regression משמעותי, אתם יכולים לפרסם את המודל לשימוש מוגבל. אם held-out השתפר אבל regression ירד חזק, החליטו האם זה acceptable. למודל support פנימי, אולי ירידה ב-HellaSwag פחות חשובה. למודל coding assistant, ירידה ב-HumanEval או ביכולת format היא דגל אדום. אם held-out לא השתפר, אל תנסו להציל את הסיפור עם benchmark טוב. המשימה שלכם לא השתפרה. חזרו ל-data, ל-rank, ל-template או להחלטה שאולי fine-tuning לא היה הכלי הנכון.

כדי שההחלטה לא תישאר באוויר, הגדירו מראש ספי מעבר. לדוגמה: “המודל ייחשב מוכן ל-demo אם הוא מקבל לפחות 30 מתוך 40 ב-held-out, מנצח את ה-base לפחות ב-8 נקודות, ואין אף כשל policy קריטי”. סף כזה מונע מכם להתמקח עם עצמכם אחרי התוצאות. אם קיבלתם 29, אתם יודעים שצריך עוד עבודה. אם קיבלתם 34 אבל יש כשל policy אחד שבו המודל מבטיח החזר כספי בלי הרשאה, אתם לא מפרסמים לייצור אוטומטי. אתם יכולים לפרסם לשימוש פנימי עם review אנושי. זו לא פסילה; זו התאמת רמת שימוש לרמת ראיות.

ה-rubric עצמו צריך להיות קצר מספיק כדי שתשתמשו בו, אבל מדויק מספיק כדי ללכוד איכות. בפרויקט support, rubric יכול להיות: 0 אם התשובה מטעה, מבטיחה פעולה לא מאושרת, מתעלמת מפרט חסר או מסלימה טון; 1 אם היא מועילה חלקית אבל חסר בה צעד ברור, בדיקת מדיניות או ניסוח אמפתי; 2 אם היא אמפתית, שומרת מדיניות, מבקשת נתון חסר ומציעה next step. בפרויקט JSON, rubric יכול להיות: 0 אם הפלט לא parseable או חסר שדה חובה; 1 אם ה-JSON תקין אבל הסיווג או הערך חלקיים; 2 אם ה-JSON תקין, כל השדות קיימים, וההחלטה תואמת את brief. אל תשתמשו באותו rubric לכל מודל. rubric גנרי מייצר ציונים גנריים.

שימו לב להבדל בין failure לבין preference. כישלון הוא מצב שבו המודל לא עומד בדרישה בסיסית: JSON שבור, תשובה בשפה הלא נכונה, hallucination עובדתי, או הבטחה עסקית מסוכנת. preference הוא מצב שבו שתי תשובות עוברות את המינימום, אבל אחת טובה יותר. אם המודל נכשל הרבה, אל תרוצו ל-DPO. חזרו ל-SFT, data cleanup, prompt wrapper או validation. DPO טוב בליטוש בחירה. הוא לא תחליף לתשתית לא יציבה. ORPO יכול לעזור כשיש לכם preference data חזק, אבל גם הוא לא יתקן dataset שמערבב פורמטים או prompt שלא מגדיר תפקיד.

לכן בדוח evaluation כדאי להפריד בין שלוש עמודות: pass/fail, preference margin, ו-risk. pass/fail אומר אם התשובה עומדת בדרישת מינימום. preference margin אומר כמה התשובה המאומנת טובה מה-base כאשר שתיהן עוברות. risk אומר האם הכשל מסוכן או רק לא יפה. לדוגמה, תשובה ארוכה מדי היא risk נמוך אם יש review אנושי, אבל תשובה שממציאה תנאי החזר היא risk גבוה. דוח טוב לא רק נותן ממוצע; הוא מראה איפה אסור להשתמש במודל. זה בדיוק מה שהופך אותו לכלי החלטה ולא לקישוט.

אחת הטכניקות הפשוטות ביותר היא לבנות confusion board קטן. לא confusion matrix פורמלי, אלא לוח של סוגי כשלונות: format, policy, hallucination, tone, brevity, missing question, unsafe escalation. אחרי שאתם מדרגים 20 prompts, ספרו כמה כשלונות נפלו בכל קטגוריה. אם רוב הכשלונות הם format, אל תבזבזו זמן על preference; תקנו template, parser, examples, או constrained decoding. אם רוב הכשלונות הם tone, SFT או preference יכולים לעזור. אם רוב הכשלונות הם missing knowledge, RAG או context injection כנראה חשובים יותר. הלוח הזה מחבר את פרק 1 לפרק 5: הבחירה בכלי נשארת תלויה בסוג הבעיה.

עוד דבר שכדאי למדוד הוא יציבות. הריצו לפחות חמישה prompts פעמיים עם אותו temperature נמוך, למשל 0.2 או 0.3. אם התשובות משתנות באופן שמחליף החלטה עסקית, המודל עדיין לא יציב מספיק לשימוש אוטומטי. אם הן משתנות רק בניסוח, זה בסדר. Fine-tuning לא מבטל sampling. אם אתם צריכים output דטרמיניסטי, הורידו temperature, הוסיפו schema validation, או השתמשו ב-parser חיצוני. אל תצפו מאימון לפתור כל אי-יציבות של inference. לפעמים הפתרון הנכון הוא wrapper טוב יותר סביב המודל.

בפרויקטים עם לקוחות, חשוב לתעד גם עלות בדיקה. אם לקח לכם שעה להכין held-out set ועוד שעה להריץ ולדרג, זה חלק מה-deliverable. אל תמחביאו אותו. לקוח שרואה “מודל מאומן” עשוי לחשוב שהעבודה היא רק training. בפועל, training הוא החלק הקצר. data, evaluation, deployment ו-risk review הם העבודה המקצועית. אם אתם מוכרים שירות fine-tuning, הציגו זאת כך: שלב 1 אבחון, שלב 2 dataset, שלב 3 אימון, שלב 4 evaluation, שלב 5 מסירה. המחיר שלכם צריך לשקף את כל השלבים, לא רק את עלות GPU.

אם ה-held-out set מגלה שאין שיפור, אל תתייחסו לזה ככישלון אישי. זה מידע מצוין. הוא אומר שאולי ה-base כבר מספיק טוב, שהבעיה הייתה prompt, שה-dataset לא מייצג, או שהמדד שבחרתם לא תופס את הערך. Fine-tuning מוצלח הוא לא תמיד מודל חדש. לפעמים התוצאה הטובה ביותר היא מסמך שאומר: “לא נפרסם מודל מאומן, כי prompt קצר + RAG קל נותנים 95% מהערך בלי תחזוקת model artifact”. זה נשמע פחות מרשים, אבל זו החלטה הנדסית טובה. בעולם אמיתי משלמים על החלטות טובות, לא על שימוש בכל כלי אפשרי.

כאשר כן יש שיפור, אל תרוצו מיד ל-production. התחילו בשימוש פנימי. תנו למודל לעזור לאדם, לא להחליף אותו. שמרו פלטים, תייגו תקלות, והרחיבו את ה-held-out set. אחרי שבוע של שימוש, תוכלו לדעת אם השיפור נשמר על data אמיתי. רק אז שווה לחשוב על אוטומציה רחבה יותר. זה נכון במיוחד בעברית, שבה מודלים קטנים יכולים להיראות טובים בדוגמאות קצרות ולהתקשות בטון, מגדר, code-switching ושמות ישראליים. השימוש האמיתי יגלה דברים שה-held-out הראשוני לא תפס.

הקפסטון: להרכיב מודל, הוכחה ו-Model Card

קפסטון טוב הוא לא רק מודל. הוא חבילה שאפשר לפתוח בעוד חודש ולהבין מה קרה. בתיקייה אחת צריכים להיות לפחות חמישה דברים: dataset snapshot או קישור מאובטח אליו, training config, model artifact או הוראות שחזור, evaluation report, ו-Model Card. אם יש Image LoRA או hosted run, גם הם מקבלים נספח. למה זה חשוב? כי fine-tuning הוא תהליך איטרטיבי. אם לא תדעו מה עבד, לא תדעו לשחזר. אם לא תדעו מה נכשל, תחזרו על אותה טעות.

מבנה תיקייה פשוט יכול להיראות כך: data/ לדוגמאות אימון מסוננות, eval/ ל-held-out set ותוצאות, model/ לקובץ GGUF או adapter, configs/ ל-LoRA/ORPO/DPO config, ו-docs/ ל-Model Card ולהחלטות. שמות קבצים צריכים להיות משעממים וברורים: train.jsonl, heldout-20.jsonl, ab-results.csv, model-card.md. אל תסמכו על “אני אזכור”. בעוד שבועיים יהיו לכם שלושה runs עם שמות דומים, והזיכרון יהפוך לערפל.

הוכחת Ollama היא חלק קטן אך חשוב. אם המודל רץ מקומית, הראו זאת. Modelfile מינימלי ל-GGUF יכול לכלול FROM ./model.gguf, system prompt קצר, ופרמטרים בסיסיים. לאחר מכן ollama create my-capstone-model ו-ollama run my-capstone-model. שמרו screenshot או log של prompt אחד מה-held-out set. אם אתם משתמשים adapter במקום GGUF merged, ודאו שה-base ב-FROM זהה ל-base של האימון. Ollama מזהיר ש-base mismatch יכול לייצר תוצאות erratic, וזה בדיוק סוג תקלה שנראית כמו “המודל מוזר” במקום כמו טעות deployment.

FROM ./capstone-model.gguf
SYSTEM "אתה assistant בעברית למותג קטן. ענה קצר, מדויק, ולא מבטיח פעולה עסקית בלי נתון חסר."
PARAMETER temperature 0.3
PARAMETER top_p 0.9

Model Card קצר צריך לענות על שבע שאלות: למה המודל נועד? על איזה base הוא מבוסס? איזה data נכנס? איזה data לא נכנס? איך נבדק? איפה הוא נכשל? מתי אסור להשתמש בו? אל תכתבו מסמך משפטי ארוך. כתבו עמוד אחד. אם המודל לשירות לקוחות, ציינו שהוא לא מוסמך לאשר החזרים ללא בדיקת מערכת. אם הוא לכתיבה שיווקית, ציינו שהוא לא בודק עובדות מוצריות. אם הוא coding assistant אישי, ציינו באילו repos או שפות הוא ראה דוגמאות, ומה לא נבדק. כנות כאן מגינה עליכם ועל המשתמשים.

החלטת publish היא לא בינארית כמו שהיא נשמעת. יש לפחות ארבע רמות: private experiment, internal beta, client demo, production use. מודל שעובר held-out 70% יכול להיות מצוין ל-private experiment, אבל לא ל-production. מודל שעובר 90% ועדיין נכשל בחריג משפטי אחד יכול להיות טוב לכתיבה פנימית ולא טוב לשליחה אוטומטית ללקוחות. לכן כתבו החלטה מדויקת: “מאושר לשימוש פנימי עם review אנושי”, “לא מאושר לשליחה אוטומטית”, “צריך עוד 50 זוגות preference בקטגוריית policy”. החלטה מדויקת יותר חזקה מהצהרת “המודל מוכן”.

בשלב האחרון, חברו הכל לסיפור אחד. “אימנתי מודל” הוא לא סיפור. “זיהיתי בעיית schema compliance, בניתי dataset של 300 זוגות, אימנתי QLoRA על Kaggle, המרתי ל-GGUF, בדקתי 20 prompts held-out, שיפרתי מ-21/40 ל-34/40, ולא ראיתי regression חריף ב-HellaSwag קטן” הוא סיפור. הוא מאפשר החלטה. אם אתם עושים קורס כדי למכור שירות, זה בדיוק ההבדל בין demo חובבני לבין deliverable מקצועי.

לפני שאתם קוראים לקפסטון “מוכן”, הגדירו גם גבולות שימוש. גבולות שימוש הם לא משפטים כלליים כמו “להשתמש באחריות”. הם הוראות הפעלה. לדוגמה: “המודל רשאי להציע ניסוח ראשוני לתשובת שירות, אבל אדם חייב לאשר כל תשובה שכוללת החזר, זיכוי, ביטול עסקה או חריגה ממדיניות”. או: “המודל רשאי להחזיר JSON למערכת staging, אבל production מקבל רק output שעבר validation עם schema”. או: “המודל רשאי לייצר רעיונות לתמונות מוצר, אבל לא תמונות של אנשים אמיתיים בלי אישור”. גבולות כאלה הופכים מודל קטן לכלי עבודה אמיתי, כי הם מונעים ממנו להעמיד פנים שהוא מערכת שלמה.

כדאי לחשוב על ארבעה מצבי deployment. הראשון הוא local private: המודל רץ אצלכם ב-Ollama ורק אתם משתמשים בו. זה מצוין ללמידה, כתיבה אישית, ניסוי brand voice או coding assistant קטן. השני הוא internal assisted: אדם בצוות משתמש במודל ומאשר פלטים לפני שהם יוצאים. זה מתאים לרוב הקפסטונים העסקיים. השלישי הוא semi-automated: המודל מחובר ל-workflow, אבל יש validation, fallback ו-review בנקודות סיכון. הרביעי הוא automatic production: המודל עונה או פועל בלי אדם. אל תדלגו לשלב הרביעי בקפסטון. מודל fine-tuned קטן יכול להיות מועיל מאוד בשלבים 1-3 ועדיין לא בטוח לשלב 4.

לכל מצב deployment צריכה להיות מדידת הצלחה אחרת. ב-local private, הצלחה היא שאתם באמת משתמשים במודל שלוש פעמים בשבוע והוא חוסך זמן. ב-internal assisted, הצלחה היא שאדם מאשר 70-80% מהטיוטות אחרי עריכה קלה. ב-semi-automated, הצלחה היא שה-validation תופס כשלונות ושיעור fallback נשאר סביר. ב-production אוטומטי, צריך מדדים קשוחים בהרבה: שגיאות, תלונות, false positives, עלות inference, זמני תגובה, ונוהל rollback. רוב הקורס הזה מכין אתכם להיות מצוינים בשלבים הראשונים. זה מספיק כדי ליצור ערך אמיתי.

אם אתם עובדים עם עברית, הוסיפו בדיקות שפה ספציפיות ל-Model Card. בדקו זכר/נקבה כאשר הלקוח פונה בלשון מסוימת, ערבוב עברית-אנגלית במונחי tech, שמות ישראליים, מספרי טלפון, כתובות, ש”ח, מע”מ, וסגנון שאינו נשמע כמו תרגום מאנגלית. מודל קטן יכול להצטיין ב-format ועדיין להישמע זר. אם המודל מיועד למותג ישראלי, טבעיות עברית היא לא קוסמטיקה; היא חלק מאיכות. לכן לפחות 5 מתוך 20 prompts ב-held-out צריכים להיות בעברית טבעית עם code-switching אמיתי, ולא משפטים נקיים מדי שנכתבו בשביל מבחן.

עוד רכיב שימושי הוא failure inbox. בכל פעם שהמודל נכשל בשימוש אמיתי, אל תתקנו מיד את המודל. שמרו את prompt, הפלט, expected behavior, קטגוריית כשל, ורמת סיכון. אחרי 10-20 failures, חפשו דפוס. אם כולם policy, בנו preference pairs או guardrail. אם כולם missing context, הוסיפו RAG או שדה context. אם כולם format, הוסיפו parser או examples. אם הם אקראיים, אולי הבעיה היא sampling או base חלש. failure inbox מונע מכם לעשות retrain אחרי כל כשל בודד. הוא הופך תחזוקה ל-data work ולא לפאניקה.

כאשר אתם כן מחליטים על retrain, כתבו retrain ticket קטן לפני הריצה. הוא צריך לכלול: מה הבעיה, כמה דוגמאות חדשות נוספו, איזה קובץ השתנה, איזה מדד אמור להשתפר, איזה מדד אסור שייפגע, ומה rollback plan. זה נשמע כבד, אבל אפשר לכתוב את זה בחמש דקות. בלי ticket כזה, כל run נראה כמו “ננסה ונראה”. עם ticket, כל run הוא ניסוי. ההבדל בין ניסוי לבין ניסיון הוא שיש השערה ומדד. זה נכון גם אם אתם עובדים לבד בלילה על Kaggle חינמי.

לבסוף, תעדו מה לא עשיתם. לא הרצתם DPO כי לא היו preference pairs טובים. לא השתמשתם Together כי העלות לא הצדיקה את הדדליין. לא בניתם Image LoRA כי אין נכסים ויזואליים עם זכויות. לא העליתם ל-production כי readiness score עדיין בינוני. החלטות “לא” הן חלק מה-deliverable. הן מראות שאתם שולטים בתהליך, לא נסחפים אחריו. פרק 5 נועד לתת לכם את הביטחון להגיד גם “כן, זה מוכן לשימוש מוגבל” וגם “לא, זה עדיין ניסוי”. שני המשפטים מקצועיים כשהם נשענים על evidence.

כדאי לסגור את הקפסטון עם גרסת release קטנה, גם אם היא מיועדת רק לכם. גרסה כזו כוללת שם מודל, תאריך, dataset version, evaluation report, known limits ופקודת הרצה. אל תקראו לה final; קראו לה v1, v1-safe או v1-local. השם מזכיר לכם שמודל הוא נכס חי, לא מסמך שנחתם לנצח. אם בעוד חודש תאספו עוד failures ותאמנו מחדש, תהיה לכם נקודת השוואה ברורה. בלי גרסה, כל שיפור עתידי מתערבב עם זיכרון עמום של “המודל הקודם”. עם גרסה, אתם מנהלים מוצר קטן.

שגרת עבודה מאוחדת אחרי הקורס

אחרי פרק 5, העבודה אינה “נגמרת”. היא עוברת משלב בנייה לשלב תחזוקה. מודל fine-tuned הוא נכס קטן שמזדקן: data משתנה, מחירים משתנים, tools משתנים, התנהגות משתמשים משתנה, וגם המודל base שסביבו בניתם יכול להתיישן. לכן צריך שגרה פשוטה, לא כבדה. אם השגרה מורכבת מדי, לא תעשו אותה. אם אין שגרה, לא תדעו מתי המודל הפסיק להיות טוב.

השגרה הזו מאחדת את כל הקורס. מפרק 1 אתם שומרים על ההחלטה הנכונה בין prompt, RAG ו-fine-tune. מפרק 2 אתם מכבדים VRAM ולא מתחילים אימון שאינו נכנס. מפרק 3 אתם מטפלים ב-data לפני hyperparameters. מפרק 4 אתם שומרים checkpoints ו-export מסודר. מפרק 5 אתם מודדים לפני שאתם מפרסמים. זו לא רשימת טיפים. זו דרך לעבוד בלי להפוך כל כשלון ל-drama.

אם אתם מוסרים את הקפסטון למישהו אחר, הוסיפו handoff קצר של עשר שורות. כתבו איפה נמצא המודל, איך מריצים אותו, איזה prompt בדיקה מראה שהוא עובד, מה אסור לבקש ממנו, איפה נמצא held-out set, ומה צריך לבדוק לפני retrain. handoff כזה חוסך את הבעיה הנפוצה ביותר בפרויקטי AI קטנים: רק האדם שבנה את המודל יודע מה לעשות איתו. מודל שלא ניתן למסירה הוא notebook, לא נכס. גם אם אתם עובדים לבד, כתבו את ההעברה לעצמכם העתידי. בעוד חודש, אחרי שתעברו לפרויקט אחר, ההקשר ייעלם מהר יותר ממה שנדמה לכם.

המדד האחרון הוא שימוש חוזר. שאלו: האם אפשר לקחת את התהליך הזה ולבנות מודל נוסף באותו pattern? אם כן, למדתם fine-tuning באמת. אם לא, אולי הצלחתם רק במקרה. לכן שמרו את המסמכים: decision tree, dataset checklist, training config, evaluation report, Model Card ו-routine. הם התוצר הסמוי של הקורס. המודל הוא תוצאה אחת; מערכת העבודה היא הדבר שנשאר איתכם. כאשר תבנו את המודל הבא, אל תתחילו מדף ריק. העתיקו את המבנה, החליפו משימה, החליפו rubric, ורק אז החליטו אם צריך data חדש, trainer אחר או מסלול hosted. זו הדרך להפוך פרויקט חד-פעמי ליכולת. אם התהליך ניתן להסבר, ניתן לשיפור; אם הוא ניתן לשיפור, הוא כבר לא קסם אלא מלאכה.