354: לבנות אייג׳נטים אמינים בלי להעמיס קונטקסט

היי כולם, אני רוני ירניב ואתם על Startup for Startup. הפרק שנשמע היום הוא סשן מתוך כנס האג'נטים הגדול שקיימנו בסוף מים. בפרק, דורון בלייברג, סולושן ארכיטקט מ-AWS, מדבר על איך בונים אג'נטים ינים מבלי להמיס קונטקסט. אני רק אגיד שאם ת בו את הסשן של דורון, אז בטח תשמחו לשמוע שכל ההרצאות והסשנים מהכנס נמצאים באתר שלנו startupforstartup.com. אתם מוזמנים ללכת להזין שם. אז נעים. Startup for Startup for Startup לי קוראים דורון בלייברג, אני סולושנס ארכיטקט ב-AWS בשש שנים האחרונות, בשלוש וקצת שנים האחרונות עובד המון עם סטארטאפים ישראלים וגם לא עם סטארטאפים. הרבה על דומיינים בעולמות ה-AI, ואני גם בוטסטראפ קו-פאונדר של קודינג אג'נט שיודע לפתח פלגינים למיינקראפט למי שבעניין. ומה שאני אנסה לדבר עליו, זה גם דברים שעלו פה בשאלות, איך אנחנו יכולים לקחת את האג'נט שלנו, שיהיה כלכלי, שירוץ נכון, שנוכל לסמוך עליו, ולנסות את כל הדברים האלה גם שיהיו בצורה מאוד כלכלית. עלו פה לא מעט דברים של ניתן לו נביא את כל הדברים, וזה ב ת מה שאנחנו רואים ואחד הקשיים הגדולים עלה פה השאלה מה קורה עכשיו עם קלווד כשהם הפכו להיות מסאבסקריפשן וצריך להתחיל לצרוך למעשה API. אז אנחנו נותנים לאג'נט המון טולים, אנחנו נותנים לאג'נט הרבה פעמים את כל הקונטקסט שהוא צריך על נושא מסוים. אנחנו מריצים את האג'נט, רואים שיש טעויות, מתקנים את הטעויות, והדברים האלה מובילים בסופו של דבר לאיזשהו סוג של תסכול. יש לנו אג'נט, הוא עובד יפה לפעמים, הוא לא תמיד כלכלי ולא תמיד הוא מריץ את מה שאני מבקש ממנו, למרות שביקשתי וביקשתי יפה. אז בואו ננסה רגע אחד להבין מה הטעויות העיקריות, ושתיים איך אנחנו יכולים לתקן אותם. בעשר דקות זה כמובן לא כל הטעויות שיכולות להיות איזושהי תאימה של דברים עיקריים. אז מה אנחנו כמפתחי אג'נטים הרבה פעמים עושים לא נכון? הדבר הראשון, מניעות. אנחנו רואים הרבה פעמים, הרצנו אג'נט, קרה משהו, עשינו ניתוח של אג'נט לאחר המקרה, אל תריץ, דונט, נבר, אבויד וכולי. אנחנו צריכים לזכור שאג'נט בסופו של דבר מריץ LLM. LLM, כל מה שהוא לכאורה, כן, הולך לכיוונו, זה נושא של attention. מה אנחנו עושים כשאנחנו עושים את החסימות האלה? אנחנו למעשה קודם כל נותנים attention למה שאנחנו לא רוצים ומקווים שהשלילה תיקח אותו לכיוון אחר. אנחנו רק מעמיקים את ה-attention הזה. נושא שני הוא corrective approach. האג'נט רץ, עבדנו, ראינו, ראינו שהוא עשה טעות. אז אנחנו נכנסים לאיזשהו ניסיון לצאת מהטעות הזאתי, בדרך כלל זה נר כמו if this, then that. אם הגעת לנקודה הזאתי, בואו ננסה רגע לעשות משהו אחר. שוב פעם, למה האג'נט, למה LLM הגיע לנקודה הזאת? כי ה-attention שלו ר לו לקחת את הברנץ' X ולא ברנץ' Y. כשאנחנו עכשיו מנסים להחזיר אותו אחורה ולהגיד לו רגע, רגע, רגע, אני מבין, הייתה פה טעות, ננסה לקחת כיוון אחר, יכול להיות שהוא יצליח, יכול להיות שלא, כי ה-attention שלו, אנחנו כבר יודעים בנקודה הזאתי, הוא לא לכיוון שאנחנו רצינו. אז הסיכוי שהוא יעקב אחרי ההנחיה הזאתי משתנה. לפעמים כן, לפעמים לא, ולכן אנחנו רואים שהאג'נט עוקב או לא עוקב. דבר נוסף הוא איזשהו סוג של context rot או context מאוד מאוד גדול שנבנה לאורך זמן באג'נטים, בדרך כלל זה באג'נטים שרצים זמן ארוך מאוד, ולמעשה הקונטקסט הזה עם כל כלי נכנס עוד משהו. כל פעם שאנחנו מזריקים עוד איזשהו domain knowledge, אנחנו מכניסים עוד דברים, שכשהאג'נט התחיל, יכול להיות שהקונטקסט הזה היה רלוונטי לטסק השלישי, אבל כשאנחנו בטסק ה-30, יש פה שוב איזשהו פריקשן, איזושהי משיכה של הקונטקסט, לא לכיוונים שאנחנו צריכים את האג'נט שיעשה אותם הכי נכון עכשיו, לאיפה בפאזל הזה הוא צריך ב ת להכניס את הטסק הנוכחי, במה להשתמש. נקודה אחרונה היא למעשה לחזור על משהו שה-LLM כבר יודע. אנחנו הרבה פעמים…

רואים שיש איזושהי טעות, והאג'נט לא הצליח להבין, ואנחנו אומרים לו, הנה כל הידע על דומיין נולג' מסוים. אנחנו גורמים פה גם להתנפחות מאוד גדולה של טוקנים, יש לזה קוסט, גם כל טוקן כזה מסית אותנו מבחינת האטנשן, וגם יש לזה עלויות של איטיות וכולי, אז זה גם כן לא תמיד מביא את התוצ הרצויה. ולמעשה יש פה איזשהו סוג של פרדוקס, אוקיי? אנחנו מצד אחד רוצים להנחות, להביא לכאורה כמה שיותר ידע, כמה שיותר את מה שאנחנו כיומן, זה היינו רוצים שיקרה, אבל יש פה תחרות על האטנשן של האג'נט, על האטנשן של המודל. איך מתמודדים עם הפרדוקס הזה? אז בואו נר ארבעה עקרונות שמאפשרים לנו לנסות ולשפר את האתגרים שאנחנו בדרך כלל נופלים אליהם. הדבר הראשון הוא מודל איבליו-איישן, ופה זה עונה לרגע דווקא על הנקודה האחרונה של נולדג'. במקום לבוא ולהגיד, הנה כל המידע על לנסות ולעשות איזשהו איבליו-איישן, בנשמרק, מה המודל יודע. לא מספיק להראית את זה פעם אחת, צריך להראית את זה מספר פעמים, הרצתי שתיים, שלוש, ארבע פעמים. מה שהמודל הצליח לענות עליו טוב ארבע פעמים, כנר אין שום סיבה שאני אכניס לתוך הקונטקסט. משהו צדק שלוש מתוך הארבע, בואו ננסה לחשוב, מה שמן הסתם הוא תמיד דעה, לכן לעשות את הבדיקות, להכניס לקונטקסט רק דברים שהמודל לא יודע. משהו יודע הוא כבר מביא איתו עם המשקולות שלו. הנקודה השנייה, או הפרינציפלה השני, הוא למעשה אטנשן פול. שוב פעם, כל דבר שנמצא בקונטקסט מושך את המודל, את ההחלטות של האג'נט, לכיוונים שונים ומנוגדים. אז ראינו את הנושא של חסימות מניעות, אל תגיד מה לא, בואו נגיד מה כן, מה אני מצפה שיהיה, איך אני רוצה שזה יתנהג. אנחנו שוטלים את הכיוון ומגדילים את ההסתברות שהכיוון שאנחנו רוצים שיקרה. גם פה זה אף פעם לא מ אחוז, זה לא מבטיח, אבל זה משפר פלאים. נקודה נוספת, אם מתי לעשות את אותו קומפקשן שכבר הוזכר, לפתוח סאב אג'נטס, יש פה דברים מן הסתם, הדברים האלה הם לפעמים קצת מתנגשים, כי אם אני עושה קומפקשן, איבדתי קצת מידע, אם אני פותח סאב אג'נט, זה קונטקסט חדש, אבל צריך לדעת גם מתי ב ת כבר הקונטקסט עצמו לא נותן לנו ערך. בואו נר כמה דוגמאות. אז למשל, במקום להגיד אל תוציא לי אאוטפוט כטקסט, אל תוציא לי כג'ייסון, מה כן? תוציא לי אותו כמרקדאון. אני אומר לו מה אני רוצה. המרקדאון הפך להיות בהסתברות יותר גבוהה. Don't click, ויש פה, היו פה קצת שאלות על נושא של טראסט וכולי, Don't click internal knowledge. ובטח אם אתם מתחילים לשיים את כל הדברים שהוא לא, אוקיי? בואו תגידו לו תענה לי מנקודת המבט של היוזר. היוזר לא מכיר את התרמים האלה, אוקיי? המודל יהיה לו הרבה יותר קשה, אוקיי? לתת את הלשיים למעשה את הנתונים הפנימיים. כן, הוא יר אותם כשהוא ירוץ, אבל ה-attention שלו הוא לכיוון אחר, לא לכיוון שאנחנו דומרים לו שיש אותם, ושיש סיכוי שהוא יכול להחזיר אותם. הנקודה האחרונה זה הנושא של avoid implicit hints. זה נכון גם באופן כללי, וגם כשאנחנו עושים evaluations למודל. אם אנחנו באים ואנחנו שואלים, אנחנו רוצים לעשות איזושהי קלאסיפיקציה. האם ההתנהגות היא נכונה או לא? אם אני שואל את השאלה, כן, זה כמו בסטטיסטיקה או כשעושים סקרים, זה נפוץ לקראת הבחירות. אם אני שואל מה לא בסדר, אנחנו כבר מבינים, כן? שה-attention הוא שכנר משהו לא בסדר. צריך לשאול את השאלה בצורה שהיא יותר unbuyest. זה מאוד חשוב גם כשעושים את המודל benchmark כדי להיות unbuyest וב ת לראות מה המודל יודע או לא. עיקרון שלישי, preventive over corrective. אז ראינו, don't, if this, then that. כל אלה הם corrective, אוקיי? מאוחר מדי. שתלנו attention לכיוון הלא נכון. כמו ברפו אנחנו רוצים למנוע, לא רוצים לטפל, אוקיי? לטפל זה כבר כשמשהו קרה. לכן אנחנו נחשוב מה אנחנו מכניסים, מה ה-attention, הכיוונים שאליהם אנחנו רוצים שה-agent ילך. וה-principle האחרון הוא כל מה שנקרא progressive disclosure. אוקיי, לא להביא, בסדר?

הגענו ליעד אנחנו יודעים מה אנחנו רוצים, לא לשים את הכל על ההתחלה, לטעון את הדברים רק בזמן שצריך, ולהבין שכל חלק בפרומט שבסוף מגיע אל האג'נט עצמו או האג'נט מגיש לאל אלם, יש לו עלות משלו. הסיסטם פרומט גם מעבר לזה שיש לו אטנשן הרבה יותר גבוה מבחינת המודל נמצא בכל ריקווסט. אז נשים שם ב ת את הבר מינימום שחשוב לנו לשים. Task instructions, מה אנחנו רוצים שתהליך מסוים יעשה. אין טעם לטעון את כל הסקילים או את כל הטסקים שאנחנו רוצים שיקורים, בסוף הם לא ירוצו. אותו דבר, knowledge domain, reference files וכמובן, קצת קשה לראות בצבע, בטולים, כן? גם בטולים עצמם כשיש כבר invocation, מה כתוב על הטול, ואפילו אפשר לעשות בהוקים ממש להזריק עוד מידע שהוא מאוד ספציפי לטסק שהטול עושה כרגע, יכול לבוא מראג, knowledge base כזה ואחר. לסיכום, תנסו להיות preventive over corrective, תזכרו שמה שאתם שמים, גם אם הוא מניעה, הוא מוסיף attention דווקא למה שאתם רוצים להימנע ממנו. אז תנסו להשתמש, לא יודע, כמו בחינוך עם ילדים, מה כן, לא מה לא. האיכות של האג'נט ובטח של התוצאות של המודל יותר תלוי במה אתם שמים ולא בכמות של מה שאתם שמים, ולתת את הinstructions בזמן הנכון. תודה. Start-up for start-up.