1.4 בחירת מודל וחלון הקשר הרצאה

כל תפריט בחירת מודל בצ'אט מציג כמה אפשרויות עם שמות דומים, ורוב המשתמשים פשוט משאירים את ברירת המחדל. זה בזבוז. המודלים השונים לא רק "יותר טובים" ו"פחות טובים" - הם מכוונים לתפקידים שונים, ובחירה נכונה חוסכת גם זמן וגם כסף בלי לפגוע באיכות. בהרצאה הזו נכיר את משפחת המודלים של Claude, נבין מה זה חלון הקשר - context window ולמה הוא לא רק "כמה טקסט נכנס", ונבנה אינטואיציה לעלות בtokens כדי שתדעו מתי לדאוג ומתי לא.

משפחת המודלים של Claude

בזמן כתיבת השורות האלה יש שלושה מודלים עדכניים שרלוונטיים לעבודה היומיומית:

מודל	מזהה API	מהירות	עוצמה	מתי להשתמש
Claude Haiku 4.5	claude-haiku-4-5-20251001	הכי מהיר	הכי בסיסי	משימות פשוטות, תגובה מיידית, נפח גבוה
Claude Sonnet 5	claude-sonnet-5	מהיר-בינוני	חזק מאוד	ברירת המחדל ל-90% מהעבודה
Claude Opus 4.8	claude-opus-4-8	איטי יותר	הכי חזק	בעיות קשות, החלטות ארכיטקטורה, מחקר עמוק

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

Haiku - כשמהירות היא התכונה החשובה

מודל Haiku הוא הקטן והמהיר במשפחה. הוא מצוין ל:

• סיווג טקסט (positive/negative, ספאם/לא ספאם)
• חילוץ מידע פשוט ממסמך (שם, תאריך, מספר טלפון)
• תגובות צ'אט-בוט מהירות שלא דורשות היגיון מורכב
• עיבוד נפח גבוה של בקשות זהות (אלפי בקשות דומות במקביל)

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

Sonnet - ברירת המחדל הטובה

מודל Sonnet 5 הוא נקודת האיזון: איכות קרובה מאוד לרמת Opus על משימות קידוד ואג'נטיות, במחיר ובמהירות נמוכים משמעותית. ברוב סביבות הפיתוח האמיתיות - כולל Claude Code - זו ברירת המחדל, ויש סיבה טובה לכך: היא "מספיק חכמה" לרוב המשימות התכנותיות, כתיבת טקסט, וניתוח, ומגיבה מהר מספיק לשמור על זרימת עבודה נוחה.

הכלל המעשי: התחילו תמיד ב-Sonnet. עברו ל-Opus רק כשיש סיבה קונקרטית.

Opus - כשהבעיה קשה באמת

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

המחיר: Opus איטי יותר ויקר יותר לtoken מ-Sonnet. זה לא אומר "תמיד תשתמשו ב-Opus כי הוא הכי טוב" - זה אומר שכשהמשימה מצדיקה את זה, הוא הבחירה הנכונה, ואחרת אתם משלמים פרמיה על משהו ש-Sonnet כבר פותר טוב.

חלון ההקשר - context window

הcontext window הוא כמות הטקסט (במונחי tokens - עוד רגע נסביר מה זה) שהמודל "רואה" בבת אחת: הפרומפט שלכם, כל היסטוריית השיחה, קבצים מצורפים, ותוצאות tools אם עובדים עם agent. שלושת המודלים שהזכרנו תומכים בcontext windows שונים:

מודל	הcontext window	פלט מקסימלי
Claude Haiku 4.5	200,000 tokens	עד 64,000 tokens
Claude Sonnet 5	1,000,000 tokens	עד 128,000 tokens
Claude Opus 4.8	1,000,000 tokens	עד 128,000 tokens

הcontext window גדול נשמע כמו יתרון נטו - "אפשר להכניס יותר" - אבל זה לא תמיד המצב.

מה בעצם ממלא את context window

הcontext window לא מכיל רק את השאלה שלכם. בעבודה עם agent כמו Claude Code, הוא כולל:

• הוראות המערכת - system prompt שמגדיר את התנהגות הagent
• קובץ CLAUDE.md וכל context פרויקט אחר שנטען
• היסטוריית השיחה - כל הודעה קודמת שלכם ושל המודל
• תוכן קבצים שנקראו - כל פעם שהagent קורא קובץ, התוכן שלו נכנס לcontext
• תוצאות tools - פלט של הרצת בדיקות, תוצאות חיפוש, פלט טרמינל

בשיחת צ'אט רגילה זה פשוט יותר: בעיקר הפרומפטים והתשובות שלכם, פלוס קבצים מצורפים.

למה חלון גדול יותר לא תמיד עדיף

שלוש סיבות מעשיות:

עלות - כל token בcontext משלמים עליו (בתשלום ישיר ל-API, ובעקיפין דרך מגבלות שימוש בtools שיש להם תוכנית). הcontext תפוח באורך שלא נחוץ הוא כסף מבוזבז.

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

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

המסקנה המעשית: הcontext window גדול הוא רשת ביטחון למשימות שבאמת דורשות הרבה מידע (למשל לנתח קודבייס שלם, או לעבד מסמך ענק) - לא הזמנה למלא אותו סתם. בעבודה עם Claude Code נדבר בפרק 4 על ניהול context בצורה מודעת - איפוס שיחה, קיצור, ופיצול משימות.

מודלים בתוך Claude Code

חשוב לדעת: הבחירה בין המודלים לא רלוונטית רק לצ'אט. ב-Claude Code (הכלי שנכיר לעומק בפרק 2), אפשר לבחור מודל בתחילת סשן או תוך כדי עבודה, וגם שם אותם עקרונות תקפים - Sonnet כברירת מחדל לרוב העבודה, Opus למשימות שדורשות תכנון עמוק כמו ריפקטורינג רחב או תכנון ארכיטקטורה מורכב.

יתרון נוסף שנפגוש בפרק 6: אפשר להריץ תת-סוכנים - subagents - כל אחד עם מודל שונה למשימה שמתאימה לו. לדוגמה, agent ראשי על Opus שמתכנן משימה גדולה, ומאציל חלקים שגרתיים (כתיבת בדיקות פשוטות, חיפוש בקוד) לsub-agents על Sonnet או Haiku. זו דוגמה לדפוס שנרחיב עליו בהמשך הקורס: לא צריך להחליט מודל אחד לכל הפרויקט - אפשר לחלק חכם לפי המשימה.

מה זה בכלל token

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

דוגמה להמחשה:

The word "programming" -> one or two tokens in English
The word "תכנות" (Hebrew for "programming") -> usually more than
                  one token in Hebrew, because the tokenizer breaks
                  it down using patterns it's less familiar with

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

אינטואיציה לעלות

מודלי שפה מתומחרים לפי טוקנים - בנפרד לקלט (input, מה ששולחים למודל) ולפלט (output, מה שהמודל מייצר). הפלט תמיד יקר יותר מהקלט, כי ייצור טקסט חדש "עולה" יותר חישובית מקריאה של טקסט קיים. סדר גודל גס:

מודל	קלט (למיליון tokens)	פלט (למיליון tokens)
Claude Haiku 4.5	הזול ביותר	הזול ביותר
Claude Sonnet 5	בינוני	בינוני
Claude Opus 4.8	היקר ביותר	היקר ביותר

בין המודלים יש פער של פי כמה בעלות לtoken - Haiku הוא הזול משמעותית, Sonnet באמצע, ו-Opus היקר ביותר. המשמעות המעשית: הרצה חוזרת של אותה משימה על נפח גדול (למשל לסווג עשרת אלפים פניות שירות) עלולה לעלות פי כמה אם משתמשים ב-Opus מבלי סיבה מוצדקת, לעומת Haiku או Sonnet.

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

חשיבה מורחבת - extended thinking

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

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

איך בוחרים בפועל

כמה כללים מעשיים שיעזרו לבחור נכון ברוב המקרים:

• התחילו מ-Sonnet כברירת מחדל - הוא הכי מאוזן מבחינת יכולת, מהירות ועלות עבור רוב העבודה: קידוד, כתיבה, ניתוח, שיחה.
• עברו ל-Opus כשהמשימה כוללת: ריפקטורינג רחב על פני הרבה קבצים, אבחון באג עדין וקשה לאיתור, תכנון ארכיטקטורה משמעותי, או מחקר שדורש שרשור היגיון ארוך ומורכב.
• עברו ל-Haiku כשהמשימה פשוטה, חוזרת, ובנפח גבוה - סיווג, חילוץ שדות, תגובות קצרות שלא דורשות היגיון עמוק.
• הפעילו חשיבה מורחבת כשהבעיה כוללת כמה שלבי היגיון תלויים זה בזה, ולא כשמדובר בשאלת ידע פשוטה שיש לה תשובה ישירה.
• אל תשפטו לפי "תחושת בטן" - אם לא בטוחים, נסו קודם עם Sonnet ובדקו את התוצאה. אם היא לא מספיק טובה, עלו ל-Opus. הרבה פעמים ההבדל קטן משצפוי.
• בפרויקט ארוך טווח, שקלו לשלב מודלים - למשל Opus לתכנון הראשוני והחלטות ארכיטקטורה, ו-Sonnet לביצוע היומיומי. נראה דוגמאות מעשיות לגישה הזו כשנדבר על תת-סוכנים (subagents) בפרק 6.

דוגמה מעשית להשפעת הבחירה

נניח משימה: לסכם 500 פניות תמיכה של לקוחות, כל אחת קצרה (כמה משפטים), ולהוציא קטגוריה וחומרה לכל אחת.

With Opus: very accurate result, but significantly slower and more
           expensive relative to the marginal benefit - this is a
           simple extraction task that doesn't require deep
           reasoning.

With Haiku: good result almost always, very fast, significantly
            lower cost. In rare edge cases (an ambiguous or
            unusually complex request) a miss is possible.

Recommended approach: run everything on Haiku. Filter out the
              cases where the model itself indicates uncertainty,
              and send only those to Sonnet for a second check.

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

סיכום

• שלושת המודלים הנוכחיים: Claude Haiku 4.5 (claude-haiku-4-5-20251001) המהיר והזול, Claude Sonnet 5 (claude-sonnet-5) ברירת המחדל המאוזנת, Claude Opus 4.8 (claude-opus-4-8) החזק ביותר למשימות מורכבות.
• הכלל המעשי: התחילו מ-Sonnet, עברו ל-Opus כשיש סיבה קונקרטית (מורכבות, ריפקטורינג רחב, מחקר עמוק), עברו ל-Haiku למשימות פשוטות בנפח גבוה.
• חלון הקשר - context window הוא כמות הטקסט שהמודל רואה בבת אחת - כולל הוראות מערכת, קבצים, היסטוריית שיחה ותוצאות tools, לא רק את השאלה שלכם.
• Sonnet ו-Opus תומכים בcontext window של מיליון tokens; Haiku ב-200 אלף - אבל חלון גדול יותר הוא רשת ביטחון, לא הזמנה למלא אותו סתם.
• הcontext window עמוס בפרטים לא רלוונטיים פוגע באיכות התשובה ומעלה עלות, גם אם טכנית "נכנס" בגבול.
• טוקן - token הוא יחידת טקסט חלקית - בערך 4 תווים באנגלית; עברית "עולה" יותר tokens לאותה כמות תוכן.
• תמחור הוא לפי מיליון טוקנים, בנפרד לקלט ולפלט, כשהפלט תמיד יקר יותר; ההבדל בעלות בין המודלים הוא משמעותי, במיוחד בהרצה על נפח גדול.
• דפוס יעיל: להריץ נפח גדול על מודל זול ומהיר, ולהסלים למודל חזק רק במקרים שבהם נדרשת ודאות גבוהה יותר.
• חשיבה מורחבת - extended thinking משפרת דיוק בבעיות רב-שלביות אבל מוסיפה זמן; שימושית לבעיות מורכבות, מיותרת לשאלות פשוטות.
• באותם עקרונות בחירת מודל משתמשים גם בעבודה עם Claude Code, כולל חלוקת עבודה בין מודלים שונים באמצעות תת-סוכנים - subagents.