בין בקשת לקוח לפעולה של סוכן AI יש הרבה החלטות קטנות. מודל חדש של AWS מבקש לטפל בהן בלי להזעיק בכל פעם מודל שפה גדול.
🔗 קישור למוצר: Strands Decider 2B
לא כל החלטה של בינה מלאכותית צריכה להגיע עם פסקה מנומקת. לפעמים תוכנה צריכה לדעת רק אם פנייה שייכת למחלקת הגבייה, אם חסר פרט לפני ביצוע פעולה, או איזה כלי להפעיל עכשיו. דווקא בצומת הזה, הפחות זוהר מצ'אט שמנסח תשובות מרשימות, AWS מציגה את Strands Decider 2B: מודל שמוותר על כתיבה חופשית ומתמקד בהחלטות מוגדרות. TechCrunch דיווח על ההשקה כחלק מהגל החדש סביב מודלים דמויי Jev. מבחינת מי שבונה מוצר, השאלה המסקרנת היא פשוטה: האם באמת צריך מנוע גדול ויקר בכל פעם שהתוכנה מגיעה לצומת קטן?
המודל הושק ב־1 באוקטובר במסגרת Strands Labs. לפי הודעת צוות Strands, הוא כולל שני מיליארד פרמטרים, מתאים להרצה מקומית על מעבד או כרטיס גרפי, וזמין עם קוד, משקולות, נתוני אימון ותסריטי אימון. הוא בוחר מתוך תשובות שמוגדרות מראש או מעניק ציון מספרי, ומחזיר גם מידע על מידת הביטחון בהחלטה. בבדיקות שהצוות פרסם נמדד זמן תגובה חציוני של כ־115 מילישניות על RTX 3090; במשימות קטנות על מחשב MacBook עם שבב M3 דווח על כ־153 מילישניות. אלו מדידות של המפתחים, בתנאים מסוימים, ולא הבטחה לזמן תגובה זהה בכל מערכת. ההחלפה מגיעה עם מגבלה מהותית: המודל אינו מייצר טקסט, ולכן אינו תחליף לצ'אטבוט, לכתיבת קוד או לסיכום מסמכים. תפקידו מצומצם בכוונה.
ההקשר הרחב הוא Jev של TypeSafe AI, שהעלה לתשומת הלב את קטגוריית מודלי ההחלטות, המכונה גם System One. הרעיון הוא להפריד בין הבנת מצב לבין יצירת תשובה ארוכה: רכיב אחד מעריך אפשרויות, והקוד מחליט כיצד להשתמש בתוצאה. בהסבר שפורסם ב־AWS Builder Center מודגש שמודלי שפה רגילים כבר מסוגלים להחזיר פלט מובנה. לכן, עצם קבלת תשובה בפורמט שהתוכנה יכולה לקרוא אינה החידוש המספיק. המבחן הוא אם המודל המתמחה מספק שילוב טוב יותר של דיוק, מהירות, עלות ומידת ביטחון שימושית. ההשוואה המוצעת שם כוללת גם כללים רגילים בקוד ומסווגים מסורתיים. זו נקודה חשובה: לפעמים הפתרון הנכון לצומת בתוכנה הוא עדיין תנאי פשוט, בלי מודל נוסף ובלי התלהבות נוספת.
לסוכני AI ההפרדה הזאת עשויה להיות שימושית במיוחד, משום שהם עוברים מהצגת תשובות להפעלת כלים. בניתוח מעשי של המבנה הזה, אפשר לחשוב על שכבת החלטה שבודקת אם בקשת הלקוח מלאה לפני שהמערכת ממשיכה, או מנתבת פנייה לצוות מתאים לפני שמודל גדול מנסח תשובה. אבל יש כאן שני סוגי נכונות שצריך להפריד ביניהם: תשובה יכולה להיות תקינה מבחינת הפורמט ועדיין שגויה מבחינת התוכן. בחירה מתוך רשימה אינה מוכיחה שהבחירה נכונה, וציון ביטחון אינו הרשאה לבצע פעולה. אם מערכת בחרה במסלול הלא נכון, העובדה שעשתה זאת במהירות לא תעזור ללקוח. לכן הערך של רכיב כזה תלוי גם במה שהתוכנה עושה כשהוא מתלבט, ואילו החלטות היא בכלל מאפשרת לו לקבל.
עבור חברה ישראלית שמפתחת שירות לקוחות, כלי תפעול או מוצר עם סוכני AI, המשמעות האפשרית היא כלכלית וארכיטקטונית. זו הערכה, לא נתון חיסכון שפורסם: אם חלק מההחלטות השגרתיות יעבור לרכיב מקומי, ייתכן שאפשר יהיה לצמצם קריאות לשירותי מודלים חיצוניים ולקצר שלבים בתהליך. אלא שהרצה מקומית עולה גם היא כסף — בחומרה, בתחזוקה ובזמן פיתוח — ויש להוסיף לחשבון את מחיר הטעויות. היתרון האפשרי בפרטיות מוגבל אף הוא: רכיב מקומי יכול לצמצם העברת מידע בשלב מסוים, אבל אינו הופך אוטומטית את כל המוצר למקומי. ואם הסוכן ממשיך אחר כך לשירות ענן, צריך לבדוק איזה מידע עובר אליו. הבחירה העסקית צריכה להישען על התהליך המלא, ולא רק על עלות ההחלטה הבודדת.
יש גם מבחן מקומי מאוד שההשקה אינה פותרת עבור הקורא הישראלי: עברית. המקורות שנבדקו אינם מציגים כאן תוצאות ייעודיות לעברית, ולכן אין בסיס להבטיח ביצועים טובים בפניות עם סלנג, שגיאות כתיב או שילוב של עברית ואנגלית. לפני שילוב במוצר כדאי להשוות חלופות על פניות מייצגות ולבדוק במיוחד מקרים שבהם החלטה שגויה גוררת פעולה יקרה או שירות גרוע. המודל עצמו כבר זמין בעמוד הרשמי של Strands ב־Hugging Face, כך שמפתחים יכולים להתחיל לבחון אותו. האפשרות המעניינת היא לחלק את העבודה בין מודלים לפי סוג המשימה: החלטות מוגבלות לרכיב קטן, ומשימות מורכבות למודל מתאים יותר. עכשיו נשאר לבדוק אם החלוקה הזאת עובדת גם מחוץ להדגמה — ובעברית של לקוח שלא קרא את הוראות השימוש.
