סוכני AI בצד שרת - מה זה ואיך בונים¶
"סוכן AI" נשמע כמו מונח שקשור בעיקר למודל השפה עצמו - כמה חכם הוא, איזה פרומפט נותנים לו. בפועל, ברגע שרוצים להריץ סוכן כזה במערכת אמיתית שמשרתת משתמשים, רוב העבודה עוברת להיות בעיה של הנדסת צד שרת רגילה - ניהול מצב, קריאות API, טיפול בשגיאות, ואבטחה. מי שבא מרקע בקאנד דווקא נמצא בעמדה טובה להבין את זה.
מה ההבדל בין סוכן AI לבין קריאה רגילה למודל שפה¶
קריאה רגילה למודל שפה היא שיחה חד פעמית - שולחים שאלה, מקבלים תשובה, זהו. סוכן הוא משהו אחר - הוא יכול לבצע כמה שלבים ברצף, להחליט בעצמו אילו כלים להפעיל בדרך, ולהמשיך לפעול עד שהוא מגיע לתוצאה. למשל, סוכן שמטפל בבקשת שירות לקוחות יכול לבד להחליט לבדוק את מצב ההזמנה במסד הנתונים, לבדוק מדיניות החזרים, ורק אז לענות למשתמש - הכל בלי שמישהו כתב את הרצף הזה ידנית מראש.
זה מה שנקרא tool calling או function calling - נותנים למודל רשימה של פעולות שהוא יכול לבקש לבצע, והוא מחליט בעצמו מתי ובאיזה סדר להשתמש בהן.
מבנה בסיסי של סוכן בצד שרת¶
ברמה הבסיסית, שרת שמריץ סוכן AI כולל כמה רכיבים. יש נקודת קצה שמקבלת בקשה מהמשתמש. יש שכבה שמנהלת את ההיסטוריה של השיחה, כי המודל צריך הקשר כדי להבין מה כבר קרה. יש שכבה שמגדירה אילו כלים זמינים לסוכן ומה כל כלי עושה. ויש לולאה שרצה עד שהסוכן מחליט שהוא סיים - שולחים למודל את המצב הנוכחי, הוא עונה או מבקש להפעיל כלי, אם הוא ביקש כלי מריצים אותו ומחזירים את התוצאה חזרה, וחוזר חלילה.
הלולאה הזו היא הלב של כל מערכת סוכנים, וזו בדיוק הסיבה שזו בעיה של תכנון בקאנד - צריך לנהל אותה בצורה אמינה, לדעת מתי לעצור אותה, ולוודא שהיא לא נתקעת בלולאה אינסופית.
הכלים - הגבול בין הסוכן למערכת האמיתית¶
כל כלי שנותנים לסוכן הוא בעצם פונקציה רגילה בקוד שלכם - שאילתה למסד נתונים, קריאה ל-API חיצוני, פעולת כתיבה. הסוכן לא ניגש ישירות לשום דבר, הוא רק מבקש להפעיל כלי עם פרמטרים מסוימים, והקוד שלכם הוא זה שמבצע את הפעולה בפועל ומחזיר תוצאה. זה נקודה קריטית להבין - הסוכן לא "עושה" כלום בעצמו, הוא רק מחליט מה לבקש, וצריך שכבת בקרה שלכם בין ההחלטה שלו לבין הביצוע בפועל.
למה אבטחה ובקרה קריטיות כאן במיוחד¶
בדיוק כי הסוכן מחליט בעצמו אילו כלים להפעיל, חייבים להתייחס לכל קריאה שלו כמו לקלט לא מהימן ממשתמש - בדיוק כמו שלא סומכים על קלט גולמי מהדפדפן. אם נתתם לסוכן כלי שמוחק רשומות ממסד הנתונים, הוא יכול, תיאורטית, להחליט להפעיל אותו במקום לא צפוי. לכן כדאי להגביל הרשאות לפי מינימום נדרש, לדרוש אישור אנושי לפעולות מסוכנות, ולתעד (log) כל קריאה לכלי כדי שיהיה אפשר לבדוק בדיעבד מה הסוכן עשה ולמה.
ניהול מצב ועלות - האתגר שממשיך אחרי ההשקה הראשונה¶
שיחה עם סוכן שממשיכה כמה שלבים צוברת הקשר ארוך יותר ויותר, וכל קריאה למודל כוללת את כל ההיסטוריה עד כה. זה אומר שגם זמן התגובה וגם העלות גדלים ככל שהשיחה מתארכת. פתרונות נפוצים כוללים סיכום שיחות ארוכות כדי לצמצם את ההקשר, והגבלת מספר הצעדים שהסוכן יכול לבצע ברצף אחד, כדי למנוע מצב שבו הוא "מסתובב" בלי להתקדם לתוצאה.
איך לומדים לבנות את זה נכון¶
בניית סוכן AI בצד שרת דורשת שילוב בין הבנת ה-API של מודלי השפה לבין עקרונות בסיסיים של הנדסת בקאנד - ניהול מצב, אבטחה, וטיפול בשגיאות. בקורס צד-שרת לומדים את היסודות שמאפשרים לבנות מערכות כאלה נכון, לא רק לחבר קריאה למודל ולקוות לטוב.
מתכננים לשלב סוכן AI בפרויקט שלכם ולא בטוחים איך להתחיל? זה בדיוק סוג הדיון שקורה בדיסקורד שלנו.
לסיכום¶
סוכן AI בצד שרת הוא בעיקר לולאה שרצה בין מודל שפה לבין כלים שהקוד שלכם חושף, כשהקוד שלכם אחראי לתווך, לאבטח, ולבקר את כל מה שקורה בדרך. זה לא קסם, זו בעיה הנדסית מוכרת עם שכבה חדשה - וברגע שמבינים אותה כך, קל הרבה יותר לבנות סוכן שעובד באמינות, ולא רק דמו מרשים.