הבלוג של ינון פרק

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

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

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

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

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

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

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

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

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

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

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

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

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

3. חשבו על העומס - שיחה עם סוכן תופסת Thread וחיבור רשת כי הגולשים מחכים לתשובה שמגיעה ב Streaming. זו תבנית עבודה יחסית חדשה ולכן עלינו לבדוק שכל השרשרת עובדת כמו שצריך איתה. שימו סביבת Staging תגייסו חברים ותעמיסו הודעות על השרת לפני שמגיעים למשתמשים אמיתיים כדי לראות מה נשבר. לכל חברות הענן יש היום פתרונות Deployment לסוכנים שווה לבדוק אותם לפני שאתם מקימים סביבה משלכם.

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

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

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

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

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

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

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

יש לכם עוד? ספרו לי בתגובות בטלגרם.

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

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

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

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

קוד הדוגמה בקישור:

https://github.com/ynonp/pydanticai-demos/tree/main/08-interactice-telegram-quiz-agent

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

https://github.com/ynonp/pydanticai-demos/tree/main/07-minicoder

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

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

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