סוכן שמצליח לפתוח קריאה, לעדכן סטטוס או להסביר חריגה בדמו יכול להפוך מהר מאוד לנקודת סיכון במוצר חי. השאלה איך משלבים סוכן AI תפעולי אינה מתחילה בבחירת מודל או בכתיבת prompt. היא מתחילה בגבולות: איזה מידע מותר לסוכן לראות, אילו פעולות מותר לו להציע או לבצע, איך מוכיחים שעל כל תשובה אפשר לסמוך, ומה קורה כשהוא לא בטוח.
במוצר SaaS, סוכן תפעולי אינו רק ממשק שיחה. הוא רכיב תוכנה שמקבל הקשר מהמשתמש, ניגש לנתונים ולמערכות דרך API, ולעתים מפעיל פעולה בעלת השפעה אמיתית. לכן ארכיטקטורה נכונה צריכה להתייחס אליו כמו לכל שירות production אחר: הרשאות, לוגים, ניטור, בדיקות, טיפול בכשל והפצה מבוקרת.
קודם מגדירים את גבול האחריות של הסוכן
הטעות הנפוצה היא להגדיר סוכן לפי היכולת הטכנית שלו: "הוא יכול לקרוא מסמכים ולקרוא ל-API". ההגדרה הנכונה היא תפעולית: איזה תהליך הוא אמור לקצר, מי המשתמש שמפעיל אותו, ואילו החלטות נשארות אצל האדם.
לדוגמה, סוכן יכול לאסוף את פרטי התקלה, להציג נתוני חשבון מאומתים ולהציע את הפעולה הבאה. זה שונה מאוד מסוכן שסוגר קריאה, משנה מסלול חיוב או מעדכן הגדרה אצל לקוח ללא אישור. בשני המקרים אולי משתמשים באותו מודל, אבל פרופיל הסיכון והמערכת שסביבו שונים לחלוטין.
כדאי להתחיל בתרחיש צר ומדיד. לא "לטפל בפניות תמיכה", אלא "לסכם את סטטוס האינטגרציה של הלקוח ולהציע בדיקות על בסיס נתוני ה-tenant שלו". הגדרה כזו מאפשרת לקבוע מהו מידע רלוונטי, מהי תשובה נכונה, ואיזו פעולה מותרת.
הרשאות אינן הוראה בתוך prompt
אם הסוכן מקבל מזהה משתמש מה-frontend ואז מחליט בעצמו איזה נתונים לחפש, יש בעיית אבטחה בסיסית. גם prompt מפורט שאומר "אל תציג מידע של לקוחות אחרים" אינו מנגנון הרשאות. מודל שפה אינו שכבת authorization.
ההרשאות חייבות להיאכף בשרת, לפני retrieval ולפני כל קריאת כלי. השרת צריך להפיק את זהות המשתמש מה-session המאומת, לגזור ממנה tenant, תפקיד והיקף גישה, ולהעביר לכל שאילתה מסנן מחייב. אותו עיקרון חל על API שמבצע פעולה: הסוכן לא מקבל מפתח-על, אלא קורא לפעולה מוגדרת עם הרשאות זהות לאלו של המשתמש או עם הרשאה שירותית מצומצמת ומבוקרת.
במערכת מרובת לקוחות, בודקים במפורש תרחישי בידוד: משתמש רגיל מול מנהל מערכת, שני משתמשים מלקוחות שונים עם שמות דומים, מסמך ששייך לחשבון שסגר מנוי, וקובץ שקיבל הרשאה זמנית. אלה אינם מקרי קצה. אלה בדיוק המקומות שבהם דמו מוצלח עלול לדלוף ל-production לא בטוח.
איך משלבים סוכן AI תפעולי עם RAG אמין
כאשר הסוכן צריך להסביר מדיניות, סטטוס או נתונים מתוך ידע פנימי, לרוב משתמשים ב-RAG. זהו מנגנון שבו המערכת מאתרת קטעי מידע רלוונטיים לפני יצירת התשובה, ומעבירה אותם למודל כהקשר. RAG טוב אינו רק vector database שמחזיר כמה קטעים שנראים דומים לשאלה.
קודם בודקים את איכות המקור. האם המסמכים מפוצלים באופן ששומר על המשמעות? האם קיימים metadata כמו מוצר, גרסה, tenant, שפה, תאריך ותוקף? האם המידע הישן מודר מהחיפוש? לאחר מכן בודקים retrieval עצמו: האם החיפוש מוצא את המקור הנכון עבור ניסוחים שונים, שמות פנימיים וקיצורים שהלקוחות באמת משתמשים בהם.
הסוכן צריך לקבל את המקורות בצורתם הנכונה, ולחזור למשתמש עם ציטוטים ברורים. ציטוט אינו קישוט. הוא מאפשר למשתמש לבדוק את הבסיס לתשובה, ולצוות שלכם להבין במהירות אם התקלה נמצאת במקור, ב-retrieval או בניסוח של המודל.
יש מקרים שבהם RAG אינו הפתרון הנכון. אם המשתמש שואל "מה מצב הייצוא שלי כרגע?", מקור האמת הוא בדרך כלל API או מסד הנתונים התפעולי, לא מסמך מאונדקס. הסוכן יכול לשלב בין ידע סטטי לנתונים חיים, אבל צריך להבדיל ביניהם בתשובה. אחרת הוא עלול להציג מידע ישן כאילו נשלף עכשיו.
כלי פעולה: מהסבר לביצוע, עם עצירה נכונה
סוכן תפעולי משתמש בדרך כלל ב-tools: פונקציות שהמערכת חושפת למודל, כגון `getAccountStatus`, `createSupportTicket` או `retrySync`. לכל tool צריך חוזה ברור: פרמטרים תקינים, אימות הרשאות, תשובות צפויות, טיפול בשגיאות וגבולות קצב. אין לתת למודל גישה כללית למסד נתונים או ל-API פנימי רק כדי לחסוך שכבת שירות מסודרת.
כאשר פעולה משנה מצב, מומלץ להפריד בין הכנה לביצוע. הסוכן יכול להציג: "מצאתי שלוש הזמנות שעומדות בקריטריון. לאשר ביטול?" ורק לאחר אישור מפורש לשלוח את הקריאה. בפעולות רגישות יותר, כמו שינוי הרשאות או מחיקה, אפשר לדרוש אישור נוסף, להציג סיכום השפעה, או להעביר את הפעולה למסלול אנושי.
גם idempotency חשובה. אם המשתמש לחץ פעמיים, אם המודל חזר על tool call, או אם התגובה נקטעה, הפעולה לא אמורה להתבצע פעמיים. זהו כלל backend מוכר, אבל בסוכנים הוא נשכח לעתים כי השיחה עצמה נראית טבעית ולא כמו API רגיל.
מודדים איכות לפני שמרחיבים גישה
בלי evals, כלומר סט בדיקות שיטתי לתשובות ולהתנהגות הסוכן, אין דרך לדעת אם שינוי ב-prompt, במודל או ב-retrieval שיפר את המערכת או קלקל אותה. בדיקה ידנית של כמה שאלות מוכרות אינה מספיקה, במיוחד כשמדובר בהרשאות ובפעולות.
בונים סט תרחישים שמבוסס על שימוש אמיתי: שאלות עם תשובה קיימת, שאלות שאין להן מקור, בקשות עם ניסוח מעורפל, מסמכים סותרים, משתמש ללא הרשאה, וכשלי API. לכל תרחיש מגדירים ציפייה: תשובה עם מקור נכון, בקשת הבהרה, סירוב, או פעולה שמחכה לאישור.
לא כל מדד חייב להיות אוטומטי. אפשר לשלב בדיקות קוד שמוודאות שלא נחשף tenant זר, הערכת איכות של retrieval, ובדיקה אנושית מדגמית של ניסוח ותועלת. העיקר הוא שיהיה baseline קבוע לפני שינוי, ושגרסה חדשה לא תגיע לכל הלקוחות בלי השוואה אליו.
עלות וזמן תגובה הם החלטות ארכיטקטוניות
סוכן איטי או יקר אינו בהכרח תוצאה של מודל לא מתאים. לעתים הבעיה היא רצף ארוך של קריאות: חיפוש, reranking, שלוש קריאות tools, מודל גדול מדי, ואז ניסיון חוזר שלא מתועד. כדי לשפר את המצב צריך לפרק trace אמיתי ולמדוד את זמני השלב והעלות שלו, במקום לנחש.
לפעמים מודל קטן מספיק לסיווג הכוונה או לחילוץ פרמטרים, ורק תשובה מורכבת דורשת מודל חזק יותר. לפעמים אפשר לצמצם את כמות ההקשר, לשמור תוצאות חיפוש קצרות טווח, או לשנות flow כך שלא כל שאלה תפעיל את כל הכלים. אבל קיצוץ אגרסיבי בהקשר עלול לפגוע בדיוק ובציטוטים. הבחירה תלויה ברמת הסיכון של המשימה ובמה שהמשתמש צריך לקבל בזמן אמת.
חשוב גם להגדיר fallback. אם כלי חיצוני לא זמין, עדיף שהסוכן יאמר שאינו יכול לאמת את המצב כרגע, מאשר להשלים תשובה מהזיכרון. אם retrieval לא מצא מקור באיכות מספקת, התגובה הנכונה היא לעתים שאלה מבהירה או הפניה למסלול תמיכה, לא תשובה בטוחה מדי.
משחררים בהדרגה ומנהלים את הסוכן כמו שירות production
לפני הפצה רחבה, מפעילים את הסוכן על קבוצת משתמשים מצומצמת או במצב שבו הוא מציע פעולה אך אינו מבצע אותה. כך אפשר לראות אילו בקשות מגיעות באמת, אילו tools נכשלים, ואיפה המשתמשים מאבדים אמון. לוגים צריכים לתעד את גרסת המערכת, המקורות שנשלפו, הקריאות לכלים, זמני תגובה, עלות ותוצאת הפעולה - תוך שמירה על מדיניות פרטיות והימנעות מלוגים שמכילים מידע רגיש ללא צורך.
כדאי שתהיה גם דרך לבטל כלי בעייתי, להחליף גרסת prompt ולחזור לגרסה קודמת בלי פריסה מורכבת. סוכן תפעולי משתנה לעתים קרובות יותר משירות עסקי רגיל, ולכן יכולת rollback ובקרת גרסאות אינן תוספת נחמדה אלא חלק מהיציבות.
ב-DevCo Solutions אנחנו מתחילים מבדיקה של הזרימה הקיימת: מאיפה מגיע המידע, איפה נאכפות ההרשאות, מה הסוכן באמת יכול לבצע, ואיך אתם יודעים שתשובה טובה נשארת טובה לאחר שינוי. אם יש לכם יכולת AI שכבר חיה במוצר ואתם רוצים להפוך אותה לשירות אמין ומדיד, השלב הבא הוא לשלוח פנייה קצרה דרך טופס יצירת הקשר באתר. נבחן יחד את נקודת הסיכון המעשית ביותר לפני שמרחיבים את היכולת.