רווחים:
- יכול להשוות בין משפחת הדגמים (מהירה/מאוזנת/עוצמתית) על יכולת, מהירות ועלות
- מעצב אסטרטגיות בחירת מודל וניתוב בהתאם למורכבות המשימה
- מבסס את בחירת המודל על ראיות עם קבוצה קטנה של הערכות
ההחלטה הבודדת שקובעת את התמורה הגבוהה ביותר עבור הכסף והאיכות שלך באינטגרציה של LLM היא באיזה דגם אתה משתמש. הרפלקס הנפוץ הוא "בחר את הדגם החזק ביותר"; עם זאת, זה אומר לעתים קרובות עלויות ועיכובים מיותרים. הגישה הנכונה היא לבחור את הדגם הקל ביותר שמבצע כל משימה ולבסס את הבחירה הזו על מדידה, לא על ניחושים. ביחידה זו, תשוו את משפחת המודלים על ציר היכולת/מהירות/עלות, תקבע אסטרטגיית ניתוב מודל בהתאם למורכבות המשימה, ותוכיח את הבחירה באמצעות סט קטן של הערכות.
הבנת משפחת הדוגמניות
ספקים מציעים בדרך כלל שלושה מחלקות: מהיר/זול, יציב ועוצמתי. הקשר ביניהם מתמצה בשלושה צירים: יכולת (כוח לפתור משימות קשות), מהירות (שהייה), עלות (מחיר סמלי).
כיתה
דוגמה
כישרון
מהירות
עלות
משימות זמינות
מהר
הייקו 4.5
בינוני
גבוה מאוד
נמוך
סיווג, תיוג, סיכום קצר, התמצאות
מאוזנת
סונטה 5
גבוה
גבוה
בינוני
מטרה כללית, קידוד, זרימה רב-שלבית, רוב עבודת הסוכנים
חזק
אופוס 4.8
הגבוה ביותר
בינוני
גבוה
חשיבה מורכבת, משימות אוטונומיות ארוכות טווח, ניתוח קשה
תובנה קריטית: המודל החזק יותר אינו מתפקד טוב יותר בכל עבודה. בתיוג פשוט "דחוף או לא", הדגם החזק והדגם המהיר נותנים את אותה תשובה נכונה; ההבדל היחיד הוא שהחזק הוא פי 5 יקר ואיטי יותר. כישרון נוסף מייצר ערך רק כאשר המשימה דורשת זאת.
שלב אחר שלב: איך בוחרים דגם?
- סיווג את המשימה. האם זה שגרתי/דפוסי (תיוג, הסקה), או פתוח/רב-שלבי (ניתוח, תכנון, קוד)?
- התחל עם המועמד הקל ביותר. נסה את זה עם הדגם המהיר. אם זה מספיק, תפסיק.
- אם זה לא מספיק, עלו למעמד גבוה יותר. אם הדיוק נמוך, לכו למאוזן, אם זה לא מספיק, לכו לחזק.
- למדוד, לא לנחש. השווה את הדיוק והעלות של כל מועמד עם סט קטן של eval (להלן).
- הגדר ניתוב מחדש. במקום להתחבר לדגם בודד, חלקו את המשימה לדגם הנכון עם "נתב".
ניתוב דגם
עומסי עבודה אמיתיים מעורבים: רוב הבקשות הנכנסות הן פשוטות, חלקן קשות. חבל לשלוח את כולם לדגם החזק; שליחת כולם לדגם המהיר מפחיתה את האיכות. ניתוב פותר את זה: דגם זול (או כלל פשוט) מסווג תחילה את המשימה, ואז העבודה עוברת לדגם המתאים.
# הנחיה של נתב (עובד עם דגם זול) סווגו את הבקשה הנכנסת לפי הקושי שלה. החזר רק את ה-JSON הבא:{"difficulty": "simple|complex"}פשוט: חד-שלבי, נוסחתי, תשובה קצרה. מורכב: דורש נימוק רב-שלבי, ניתוח או דור ארוך. בקשה: """{{request}}"""
- עבור למודל פשוט → מהיר (זול, מהיר).
- עבור למודל מורכב → חזק (יקר אך הכרחי).
דפוס זה מפחית משמעותית את העלות הממוצעת מכיוון שרוב התעבורה היא בדרך כלל פשוטה.
טיפ: החלטת הפניה לא תמיד מצריכה לימודי LLM. כללים פשוטים כמו "עבור למודל מהיר אם הטקסט הוא פחות מ-20 מילים" הם גם מדריכים ומביאים אפס עלות סמלית נוספת. נסה את הכלל קודם.
קישור בין בחירה לראיות: אשכול ההשוואה הקטן
אל תבחר דגם על סמך "זה נראה לי יותר טוב". Eval (ערכת הערכה) היא קבוצה קטנה של דוגמאות שהתשובה הנכונה לגביהן ידועה; אתה מפעיל כל דגם על הסט הזה ומודד דיוק, עלות והשהייה.
# תבנית הגדרה של Eval1) אסוף 20-50 דוגמאות אמיתיות, כתוב ביד את "התשובה הנכונה" על כל אחת.2) הפעל כל דגם (מהיר/מאוזן/חזק) על סט זה.3) לכל דגם: מספר תיקונים, אסימוני תפוקה ממוצעים, עלות לכל בקשה, זמן ממוצע.4) בחר את הדגם ש"נותן דיוק מספיק הזול ביותר".
# טבלת השוואה של Eval (מילוי) דגם | דיוק | עלות לכל בקשה | משך ממוצעHaiku | ...% | ... $ | ... snSonnet | ...% | ... $ | ... snOpus | ...% | ... $ | ... שניות
הנחיה חלשה / הנחיה חזקה (החלטה על בחירת דגם)
# חלש (אין בסיס להחלטה)בואו נשתמש במודל הטוב ביותר, התקציב לא חשוב.
# STRONG (החלטה מבוססת מדידה) בהשוואה ל-50 דגימות, הייקו נתן דיוק של 96%, סונט נתן דיוק של 97%; ההבדל הוא חסר משמעות סטטיסטית. הייקו נבחר בגלל שהוא זול פי 5 ופי 2 מהיר יותר. אם הדיוק יורד מתחת ל-95%, ההחלטה לשדרג לסונט תתקבל באופן אוטומטי.
גרסה חזקה; קושר את הבחירה למספר, לסף ולכלל הסלמה. זה גם מגן על ההחלטה של היום וגם מנהל את השינוי העתידי.
שלושה מיני מארזים
מקרה 1 - בריחה מהמודל המכריע. מוקד טלפוני הפיק את כל סיכומי השיחה עם אופוס; החשבון החודשי היה גבוה. בהערכת 40 דגימות, סונט היה 1% מאחורי אופוס ברמת הדיוק, אך עלתה שליש. הם העבירו את עבודת הסיכום לסונטה; העלות החודשית ירדה מ-$9,000 ל-$3,100, ללא תלונות על איכות.
מקרה 2 - תנועה מעורבת עם הפנייה מחדש. 80% מהבקשות של צוות טכנולוגיה משפטית היו תיוג מסמכים פשוט, 20% היו ניתוח חוזים מורכב. הם שלחו את כולם לדגם העוצמתי. הם הוסיפו נתב זול והפיצו עבודות פשוטות להייקו ועבודות מורכבות לאופוס; עלות הבקשה הממוצעת ירדה ב-64%, בעוד איכות הניתוח נשמרה.
מקרה 3 - עלות ההקטנה ללא מדידה. כדי להפחית את העלות, צוות אחד הפחית מיצוי קוד רפואי מורכב ישירות למודל המהיר; הם לא העריכו. בשידור חי, הדיוק ירד מ-92% ל-78%, וכתוצאה מכך החזר של מסקנות שגויות. הם היו צריכים להתחמק קודם: המשימה הזו דרשה את המודל החזק. שיעור: גם הקטנה וגם הגבהה נעשים על ידי מדידה.
טעויות נפוצות
- רפלקס "הדגם החזק ביותר": בזבוז ועיכוב מיותר במשימות פשוטות.
- שינוי המודל ללא מדידה: גם הקטנה וגם הגדלה מסוכנים ללא eval.
- נעילה בדגם בודד: ניתוב בתנועה מעורבת הוא לרוב יעיל יותר.
- תמיד טועה בנתב ל-LLM: כללים פשוטים יכולים לעבוד ללא עלות.
- לא להגדיר סף דחיפה: מה קורה אם יש להגדיר מראש ירידה ברמת הדיוק.
- אי תיקון גרסת הדגם: רשום על איזה דגם/גרסה אתה עובד בייצור; שינוי גרסה עשוי לשנות התנהגות.
עמוק יותר: הנצחת איוואל ומשפט מצטבר
בחירת דגם אינה החלטה חד פעמית. ספקים מציגים דגמים חדשים, המחירים משתנים, תיאור התפקיד שלך מתפתח. אז הגדר את אשכול eval פעם אחת ואל תשכח; להחזיק את זה כמו יצור חי. כשיוצא דגם חדש, אתה מריץ את אותן 20-50 דגימות דרכו, מעדכן את הטבלה ומקבל שוב את ההחלטה שלך. זה מגן עליך ממלכודת "האינטואיציה המחליפת דפוסים".
הטכניקה המתקדמת השנייה היא דפוס ה-fallback / מפל. אתה נותן את המשימה לדגם הזול קודם כל; אם לפלט יש ביטחון נמוך או שכבת האימות (יחידה 11) דוחה אותו, אתה מסלים את אותה בקשה. אז רוב התעבורה נפתרת בדגם הזול, כאשר רק המיעוט הנותר הולך לדגם היקר. זה גם זול יותר וגם עמיד יותר מהגישה הקבועה של דגם יחיד.
הנקודה השלישית היא ש-eval כוללת לא רק דיוק אלא גם עלות והשהייה. אם דגם מדויק ב-1% יותר אבל יקר פי 3 ופי 2 איטי יותר, החילוף לא שווה את זה עבור רוב העבודות. קבל את ההחלטה לאורך שלושה צירים (דיוק, עלות, חביון) והגדר "סף ספיקה": "אם הדיוק הוא מעל 95%, בחר את הזול ביותר."
לבסוף, רשום באיזה דגם/גרסה השתמשת בייצור. אם יום אחד איכות הפלט תשתנה, הדבר הראשון שתסתכל עליו הוא האם גרסת הדגם השתנתה. מעקב אחר גרסאות מאפשר לאתר מהר יותר את הגורם השורשי לבעיות איכות.
אזהרה נוספת: אשכול eval צריך לייצג את עומס העבודה האמיתי שלך. הערכה המורכבת רק מדוגמאות קלות מסתתרת שבה הדוגמנית מועדת במקרים קשים ומשקה אותך באמון כוזב. הערכה טובה; הוא כולל דוגמאות קלות נפוצות כמו גם מקרים פינתיים שאתה נתקל בהם במציאות (תשומות מעורפלות, לא שלמות, סותרות). המיעוט הקשה הזה קובע את בחירת הדגם שלך, מכיוון שכל דגם ממילא מצליח ברוב הקל. שמור על Eval שלך טרי ויצוגי על ידי הזנתו מעת לעת דוגמאות אמיתיות חדשות.
לסיכום
הדגם הנכון הוא הדגם הקל ביותר שעושה את העבודה; חזק יותר הוא לא טוב יותר בכל עבודה, הוא פשוט יותר יקר ואיטי יותר. סיווג המשימה והתחיל מהמועמד הקל ביותר, חלוקת התעבורה המעורבת עם ניתוב, וביסוס הבחירה עם סט קטן של evals מפחית את העלות פעמים רבות תוך שמירה על איכות.
משימת יישום
בחר עומס עבודה. (1) סווגו את המשימה כפשוטה/מורכבת. (2) עצב ערכה קטנה של 20 דוגמאות אמיתיות (עם התשובות הנכונות שלהן). (3) ערכו תוכנית לאכלוס טבלת השוואת דיוק/עלות/זמן עבור שלוש מחלקות המודל. (4) אם יש לך תעבורה מעורבת, כתוב כלל ניתוב והגדר סף הסלמה.
רשימת בדיקה
- [ ] אני יכול להשוות את משפחת הדגמים על ציר היכולת/מהירות/עלות.
- [ ] אני יכול ליישם את עקרון "המודל המוצלח הקל ביותר".
- [ ] אני יכול להגדיר ניתוב מודל לפי מורכבות המשימה.
- [ ] עם סט קטן של eval אני יכול לאגד את הבחירה לראיות.
- [ ] אני יכול להגדיר סף שדרוג/הורדה.