פיתוח מבוסס-הערכה

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

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

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

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

הגדרת הבעיה

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

• סוג הקלט: טיוטה של פוסט בבלוג
• פורמט הפלט: מערך JSON עם 3 כותרות של פוסטים
• הנחיות: פחות מ-128 תווים, בניסוח ידידותי

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

הגדרת ערך בסיס

כותבים את ההנחיה הראשונה. מתחילים עם zero-shot וכוללים הוראות ברורות, פורמט פלט ומשתנה placeholder לתוכן הקלט.

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

יצירת מערכת הערכה

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

כדי לבצע הערכה יעילה, סביר להניח שתצטרכו כמה כלי מדידה.

הגדרת מדדי ההערכה

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

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

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

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

בחירת השופטים

קריטריונים שונים להערכה דורשים מעריכים שונים:

• בדיקות מבוססות-קוד מתאימות במיוחד לפלט דטרמיניסטי או מבוסס-כללים. לדוגמה, אפשר לסרוק כותרות כדי למצוא מילים שרוצים להימנע מהן, לבדוק את מספר התווים או לאמת את מבנה ה-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.

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

בדיקת ההבנה