כשיוצרים הנחיות לאפליקציות אמיתיות, מתגלה פשרה חשובה: צריך לאזן בין תמציתיות לבין יעילות. כשכל הגורמים שווים, הנחיה תמציתית היא מהירה יותר, זולה יותר וקל יותר לתחזק אותה מאשר הנחיה ארוכה יותר. זה רלוונטי במיוחד בסביבות אינטרנט שבהן יש חשיבות לזמן האחזור ולמגבלות על טוקנים. עם זאת, אם ההנחיה שלכם מינימלית מדי, יכול להיות שלמודל יחסרו ההקשר, ההוראות או הדוגמאות כדי להפיק תוצאות באיכות גבוהה.
פיתוח מבוסס-הערכה (EDD) מאפשר לכם לעקוב באופן שיטתי אחרי האיזון הזה ולבצע בו אופטימיזציה. הוא מציע תהליך שניתן לחזור עליו ולבדוק אותו כדי לשפר את התפוקות בצעדים קטנים ובטוחים, לזהות רגרסיות ולהתאים את התנהגות המודל לציפיות של המשתמשים והמוצר לאורך זמן.
אפשר לחשוב על זה כעל פיתוח מונחה-בדיקות (TDD), שמותאם לחוסר הוודאות של AI. בניגוד לבדיקות יחידה דטרמיניסטיות, אי אפשר לקודד מראש הערכות של AI כי הפלט, גם אם הוא תקין וגם אם הוא לא תקין, יכול להיות בצורות לא צפויות.
ה-EDD גם תומך במאמצי הגילוי שלכם. בדיוק כמו שבדיקות כתיבה עוזרות להבהיר את ההתנהגות של תכונה, הגדרה של קריטריונים להערכה ובדיקה של התוצאות של המודל מאלצות אתכם להתמודד עם חוסר בהירות ולהוסיף בהדרגה פרטים ומבנה למשימות פתוחות או לא מוכרות.
הגדרת הבעיה
אפשר לנסח את הבעיה כמו חוזה API, כולל סוג הקלט, פורמט הפלט ואילוצים נוספים. לדוגמה:
- סוג הקלט: טיוטה של פוסט בבלוג
- פורמט הפלט: מערך JSON עם 3 כותרות של פוסטים
- מגבלות: פחות מ-128 תווים, שימוש בסגנון דיבור ידידותי
לאחר מכן, אוספים דוגמאות של קלט. כדי להבטיח מגוון נתונים, כדאי לכלול גם דוגמאות אידיאליות וגם קלט אמיתי ומבולגן. כדאי לחשוב על וריאציות ומקרים קיצוניים, כמו פוסטים עם אמוג'י, מבנה מוטמע והרבה קטעי קוד.
הגדרת ערך בסיס
כותבים את ההנחיה הראשונה. אפשר להתחיל עם zero-shot ולכלול:
- מחיקת ההוראה
- פורמט פלט
- Placeholder למשתנה קלט
כשמעריכים ומבצעים אופטימיזציה, מגדילים את המורכבות ומשתמשים ברכיבים אחרים ובטכניקות מתקדמות של יצירת הנחיות. קודם כל, צריך להגדיר מערכת הערכה שתכוון את מאמצי האופטימיזציה לכיוון הנכון.
יצירת מערכת הערכה
ב-TDD, מתחילים לכתוב בדיקות אחרי שמכירים את הדרישות. עם AI גנרטיבי, אין פלט סופי שאפשר לבדוק מולו, ולכן צריך להשקיע יותר מאמץ ביצירת לולאת ההערכה.
כדי לבצע הערכה יעילה, סביר להניח שתצטרכו כמה כלי מדידה.
הגדרת מדדי ההערכה
מדדי ההערכה יכולים להיות דטרמיניסטיים. לדוגמה, אפשר לבדוק אם המודל מחזיר JSON תקין או מוציא את המספר הנכון של פריטים.
עם זאת, כדאי להקדיש חלק ניכר מהזמן לזיהוי ולשיפור של מדדים סובייקטיביים או איכותיים, כמו בהירות, שימושיות, טון או יצירתיות. יכול להיות שתתחילו עם יעדים רחבים, אבל מהר מאוד תיתקלו בבעיות מורכבות יותר.
לדוגמה, נניח שגנרטור הכותרות שלכם משתמש יותר מדי בביטויים או בתבניות מסוימות, מה שמוביל לתוצאות חוזרות ורובוטיות. במקרה כזה, כדאי להגדיר מדדים חדשים כדי לעודד וריאציות ולמנוע שימוש יתר במבנים או במילות מפתח. עם הזמן, המדדים העיקריים יתייצבו ותוכלו לעקוב אחרי השיפורים.
מומלץ להסתייע בתהליך הזה במומחים שמבינים מה נחשב טוב בדומיין של האפליקציה שלכם, ויכולים לזהות מצבי כשל לא ברורים. לדוגמה, אם אתם מפתחים כלי עזר לכתיבה, כדאי לכם לשתף פעולה עם יוצר תוכן או עורך כדי לוודא שההערכה שלכם תואמת לתפיסת העולם שלהם.
בחירת השופטים
קריטריונים שונים להערכה דורשים מעריכים שונים:
- בדיקות מבוססות-קוד מתאימות לפלט דטרמיניסטי או מבוסס-כללים. לדוגמה, אפשר לסרוק כותרות כדי למצוא מילים שרוצים להימנע מהן, לבדוק את מספר התווים או לאמת את מבנה ה-JSON. הם מהירים, ניתנים להפעלה חוזרת ומושלמים לרכיבי ממשק משתמש עם פלט קבוע, כמו לחצנים או שדות טופס.
- משוב מאנשים חיוני להערכת איכויות סובייקטיביות יותר, כולל הטון, הבהירות או התועלת. במיוחד בשלבים הראשונים, בדיקה של התוצאות של המודל בעצמכם (או בעזרת מומחים בתחום) מאפשרת חזרה מהירה על התהליך. עם זאת, הגישה הזו לא מתאימה לשימוש נרחב. אחרי שתפעילו את האפליקציה, תוכלו גם לאסוף אותות מתוך האפליקציה, כמו דירוג בכוכבים, אבל בדרך כלל האותות האלה לא מדויקים וחסרים את הניואנסים שנדרשים לאופטימיזציה מדויקת.
- LLM-as-judge היא דרך ניתנת להרחבה להערכת קריטריונים סובייקטיביים באמצעות מודל AI אחר שנותן ציון או ביקורת על התוצאות. השיטה הזו מהירה יותר מבדיקה אנושית, אבל יש בה גם חסרונות: ביישום לא מתוחכם, היא יכולה להנציח ואפילו לחזק את ההטיות והפערים בידע של המודל.
חשוב לתת עדיפות לאיכות על פני כמות. בלמידת מכונה קלאסית וב-AI לחיזוי, נהוג להשתמש במיקור המונים כדי להוסיף הערות לנתונים. ב-AI גנרטיבי, לרוב אין למבצעי האנוטציות מידע על ההקשר של הדומיין. איכות גבוהה והערכה עשירה בהקשר חשובות יותר מהיקף.
הערכה ואופטימיזציה
ככל שתבדקו ותשפרו את ההנחיות מהר יותר, כך תגיעו מהר יותר למשהו שעונה על הציפיות של המשתמשים. חשוב להקפיד על אופטימיזציה מתמשכת. כדאי לנסות לשפר את ההנחיה, להעריך את התוצאה ולנסות משהו אחר.
אחרי שהמערכת תעבור לשלב הייצור, צריך להמשיך לעקוב אחרי התנהגות המשתמשים ומערכת ה-AI ולהעריך אותה. לאחר מכן, מנתחים את הנתונים האלה ומשנים אותם לשלבי אופטימיזציה.
אוטומציה של צינור ההערכה
כדי לצמצם את החיכוך בתהליך האופטימיזציה, צריך תשתית תפעולית שמבצעת הערכה אוטומטית, עוקבת אחרי שינויים ומקשרת בין פיתוח לייצור. הגישה הזו נקראת בדרך כלל LLMOps. יש פלטפורמות שיכולות לעזור באוטומציה, אבל כדאי לתכנן את תהליך העבודה האידיאלי לפני שמתחייבים לפתרון של צד שלישי.
הנה כמה רכיבים חשובים שכדאי להביא בחשבון:
- ניהול גרסאות: שמירת ההנחיות לחנות, מדדי ההערכה וקלט הבדיקה בניהול גרסאות. כדאי להתייחס אליהם כאל קוד כדי להבטיח שניתן יהיה לשחזר את התוצאות ולראות בבירור את היסטוריית השינויים.
- הערכות אוטומטיות של קבוצות: אפשר להשתמש בתהליכי עבודה (כמו GitHub Actions) כדי להריץ הערכות על כל עדכון של הנחיה וליצור דוחות השוואה.
- CI/CD להנחיות: אפשר להגביל פריסות באמצעות בדיקות אוטומטיות, כמו בדיקות דטרמיניסטיות, ציונים של LLM כשופט או אמצעי הגנה, ולחסום מיזוגים כשאיכות התוצאות יורדת.
- רישום ביומן וניטור של נתוני ייצור: תיעוד של נתוני קלט, פלט, שגיאות, זמן אחזור ושימוש בטוקנים. מעקב אחרי סטיות, דפוסים לא צפויים או עליות פתאומיות במספר הכשלים.
- קליטת משוב: איסוף אותות משתמשים (לייקים, שכתובים, נטישות) והפיכת בעיות חוזרות לתרחישי בדיקה חדשים.
- מעקב אחר ניסויים: מעקב אחר גרסאות של הנחיות, הגדרות של מודלים ותוצאות של הערכות.
ביצוע שינויים קטנים וממוקדים
בדרך כלל, שיפור ההנחיה מתחיל בשיפור השפה של ההנחיה. למשל, הם יכולים לפרט יותר את ההוראות, להבהיר את הכוונה או להסיר דו-משמעויות.
חשוב להיזהר מהתאמת יתר. טעות נפוצה היא הוספה של כללים צרים מדי לתיקון בעיות במודל. לדוגמה, אם הכלי ליצירת כותרות ממשיך ליצור כותרות שמתחילות ב-The Definitive Guide, יכול להיות שתתפתו לאסור במפורש את השימוש בביטוי הזה. במקום זאת, כדאי להפשיט את הבעיה ולהתאים את ההוראה ברמה הגבוהה יותר. לדוגמה, אם אתם רוצים שהמודל ייתן עדיפות למקוריות, למגוון או לסגנון עריכה ספציפי, כדאי להדגיש את ההעדפה הזו כדי שהמודל ילמד אותה ולא יתייחס אליה כאל חריג חד-פעמי.
דרך נוספת היא להתנסות בטכניקות הנחיה נוספות ולשלב בין הטכניקות האלה. כשבוחרים טכניקה, כדאי לשאול את עצמכם: האם הכי טוב לפתור את המשימה הזו באמצעות אנלוגיה (few-shot), נימוק שלב אחר שלב (chain-of-thought) או שיפור איטרטיבי (self-reflection)?
כשמערכת ה-EDD שלכם עוברת לייצור, היא לא אמורה להאט. אם כבר, היא צריכה להאיץ. אם המערכת שלכם מעבדת את קלט המשתמשים ומתעדת אותו, זה צריך להיות המקור הכי חשוב לתובנות. מוסיפים דפוסים חוזרים לחבילת הכלים לבדיקה, ומזהים ומיישמים באופן שוטף את השלבים הבאים למיטוב.
התובנות שלכם
פיתוח הנחיות שמבוסס על הערכה מאפשר לכם להתמודד עם אי הוודאות של ה-AI בצורה מובנית. הגדרת הבעיה בצורה ברורה, בניית מערכת הערכה מותאמת אישית וביצוע שיפורים קטנים וממוקדים מאפשרים ליצור לולאת משוב שמשפרת בהדרגה את התפוקות של המודל.
משאבים
אם אתם רוצים להטמיע LLM כשופט, מומלץ לקרוא את המאמרים הבאים:
- השוואה בין יכולות של LLM לסיכום.
- קוראים את המדריך של Hamel Husain בנושא שימוש ב-LLM כשופט.
- מומלץ לקרוא את המאמר: A Survey on LLM-as-a-Judge.
אם אתם רוצים לשפר עוד יותר את ההנחיות, אתם יכולים לקרוא מידע נוסף על פיתוח מודלים בהתאם להקשר. הפעולה הזו מתאימה במיוחד למהנדס למידת מכונה.
בדיקת ההבנה
מהי המטרה העיקרית של פיתוח מבוסס-הערכה?
למה כדאי להשתמש במודלים גדולים יותר כדי להעריך מערכת בצד הלקוח?
מהו חיסרון פוטנציאלי בשימוש במודל שפה גדול כשופט לצורך הערכה?
איזה רכיב הוא חלק מצינור מומלץ של הערכה אוטומטית?
כשבוחרים שופטים למערכת ההערכה, מהו החיסרון העיקרי בשימוש במשוב אנושי?