סוכן LLM איננו צ'אטבוט עם גישה לכמה מסמכים. בהקשר תפעולי, זו תוכנה שיכולה לפרש בקשה, לשלוף את ההקשר הנכון, לבצע פעולות מאושרות במערכות עסקיות ולהפיק תוצאה שניתנת לביקורת. ההבחנה הזו מגדירה איך לבנות סוכני LLM שיוצרים ערך ולא רק הדגמות מרשימות.
עבור COO, מנהל מוצר או מנהל טכנולוגי, המטרה היא לעיתים רחוקות “להוסיף AI”. המטרה היא בדרך כלל לקצר את זמן הטיפול, לבטל עבודה חוזרת, לשפר את עקביות ההחלטות או להסיר צוואר בקבוק בין מערכות מפוצלות. הסוכן מועיל רק כשהוא עונה על הדרישה התפעולית הזו.
התחילו מתהליך עבודה, לא ממודל
פרויקטי הסוכנים החזקים ביותר מתחילים בתהליך צר וחוזר שיש לו בעלים ברור ועלות מדידה. דוגמאות כוללות סיווג פניות תמיכה נכנסות, חילוץ נתונים ממסמכים פיננסיים, הכנת סיכומי חיתום, בדיקת הזמנות מול כללי מדיניות או ניסוח עדכוני CRM אחרי שיחות מכירה.
בחרו תהליך עבודה שבו הסוכן יכול לתרום תרומה משמעותית, אבל שבו ההשלכות של טעות מובנות. סוכן למיון פניות תמיכה יכול לנתב בקשות ולהכין תשובות עם שלב אישור אנושי. סוכן פיננסי עשוי לחלץ שדות מחשבוניות ולסמן חריגים, בזמן שאדם נשאר אחראי על אישור התשלום. אלה פרופילי סיכון שונים, ואין להנדס אותם באותה דרך.
לפני שבוחרים מודל או פריימוורק, תעדו את התהליך הנוכחי. זהו את האירוע המפעיל, את הקלטים הנדרשים, את המערכות המעורבות, את נקודות האישור, את החריגים ואת התוצר הסופי. לאחר מכן קבעו נקודת ייחוס: זמן טיפול ממוצע, שיעור שגיאות, נפח צבר, עלות לתיק או השפעה על ההכנסות. בלי נקודת ייחוס קשה להוכיח שהסוכן שיפר את התפעול.
הגדירו את התפקיד והגבולות של הסוכן
LLM יעיל בפירוש שפה לא מובנית, בסיכום מידע, בהסקה על פני הקשר שסופק ובבחירה מתוך אפשרויות מוגבלות. הוא פחות אמין כשמבקשים ממנו להמציא עובדות, לבצע חישובים מדויקים בלי אימות או לבצע שינויים בלתי מוגבלים ברשומות קריטיות.
סוכן בייצור צריך חוזה תפעולי כתוב. החוזה צריך לקבוע מה מותר לסוכן לעשות, באילו מקורות הוא יכול להשתמש, מתי הוא חייב לבקש מידע נוסף, מה הוא חייב להסלים ואילו פעולות דורשות אישור. החוזה הופך לבסיס לפרומפטים, להרשאות הכלים, לבדיקות ולניטור.
לדוגמה, סוכן לקליטת תביעות עשוי להיות מורשה לקרוא מסמכי הגשה, לחלץ שדות לסכמה מובנית, לזהות מידע חסר וליצור טיוטת רשומה במערכת ניהול תיקים. הוא לא אמור לאשר תביעה, לשנות סכום תשלום או לגשת לרשומות לקוח לא קשורות. גבולות ברורים מונעים את תרחיש הכשל הנפוץ של מתן גישה רחבה לסוכן לפני שהתנהגותו הוכחה.
בנו את המערכת סביב כלים ונתונים מהימנים
המודל הוא רכיב אחד בפתרון. הערך העסקי נובע בדרך כלל משכבת האינטגרציה שסביבו.
סוכן צריך כלים כדי לתקשר עם מערכות מאושרות: CRM, ERP, פלטפורמת תמיכה, מאגר מסמכים, מסד נתונים פנימי, שירות דוא״ל או אפליקציה קניינית. כל כלי צריך לחשוף פעולה מוגבלת ומוגדרת היטב. במקום לתת לסוכן גישה בלתי מוגבלת למסד הנתונים, ספקו פונקציות כמו `get_customer_account`, `create_support_ticket`, `search_policy_documents` או `update_order_status`.
לתכנון הזה יש יתרונות מעשיים. הוא מגביל את רדיוס הנזק של החלטה שגויה, מקל על אכיפת הרשאות ומייצר רשומות ביקורת נקיות יותר. הוא גם מקל על בדיקת הסוכן, כי לכל פעולה יש קלטים מוגדרים ופלטים צפויים.
גישה לנתונים דורשת משמעת שווה. אחזור מבסיס ידע פנימי צריך לכבד את הרשאות המסמכים, את עדכניות המקורות ואת הגבולות בין מחלקות. מודל שיכול לשלוף מסמך מדיניות מהשנה שעברה עלול לספק תשובה סבירה אבל שגויה. ניהול גרסאות, מטא-דאטה, בקרות גישה וציטוט מקורות בתהליך העבודה הפנימי של הסוכן עוזרים למנוע זאת.
בארגונים רבים, הארכיטקטורה הנכונה משלבת אחזור עם שאילתות ישירות למערכות. סוכן שירות לקוחות עשוי להשתמש במאמרי בסיס הידע להנחיות מדיניות, ואז לקרוא ל-CRM ולמערכת ההזמנות כדי לקבל פרטי חשבון עדכניים. מקור אחד מסביר את הכלל; האחר מאשר את העובדות.
השתמשו בבקרות דטרמיניסטיות היכן שהן חשובות
לא כל החלטה צריכה לעבור להסקה של מודל שפה. כללים עסקיים יציבים ומפורשים צריכים להישאר דטרמיניסטיים.
אם הזמנה מעל סכום מסוים דורשת אישור מנהל, אכפו את הכלל הזה בלוגיקת האפליקציה. אם סכום חשבונית חייב להתאים לשורות הפריטים, אמתו זאת בקוד. אם למשתמש אין הרשאה לצפות ברשומה, שכבת ההרשאות צריכה לחסום את הגישה עוד לפני שהמודל רואה את התוכן.
זהו עיקרון ארכיטקטוני קריטי: השתמשו ב-LLM לעמימות ולשפה, ובתוכנה רגילה לכללים, לחישובים, להרשאות ולטרנזקציות. סוכנים הופכים לאמינים יותר כשלא מבקשים מהם להתנהג כמו מערכת הפעלה לכל מטרה.
גם את הבדיקה האנושית צריך לתכנן במכוון. בדיקה איננה סימן לכך שהפרויקט לא הצליח לבצע אוטומציה. זו בקרת סיכון שאפשר להחיל באופן סלקטיבי. דרשו אישור לפלטים ברמת ודאות נמוכה, לעסקאות בערך גבוה, לחריגי מדיניות, לתקשורת רגישה או לפעולות שקשה לבטל. עם הזמן, נתוני ההערכה עשויים להראות שקטגוריות מסוימות יכולות לעבור מבדיקה חובה לביצוע אוטומטי.
תכננו למצב, לחריגים ולהתאוששות
תהליכי עבודה אמיתיים לא מסתיימים אחרי פרומפט אחד ותשובה אחת. ייתכן שסוכן יצטרך לבקש מסמך חסר, לחכות לתשובת לקוח, לנסות שוב API שאינו זמין, להעביר תיק למומחה או לחדש עבודה אחרי אישור.
זה מחייב ניהול מצב מפורש. שמרו את סטטוס תהליך העבודה, הקלטים שבהם נעשה שימוש, קריאות הכלים שבוצעו, פלטי המודל, האישורים, השגיאות והפעולה הבאה. מנוע תהליכי עבודה עמיד או backend של האפליקציה צריכים לנהל את התהליך, ולא היסטוריית הצ'אט של המודל כמקור האמת.
טיפול בחריגים הוא לעיתים קרובות המקום שבו פרויקטי ייצור מצליחים או נכשלים. הגדירו מה קורה כשמערכת מקור אינה זמינה, כשהמידע שאוחזר סותר, כשהמודל מחזיר פורמט לא תקין או כשהסוכן מגיע לסף ודאות שהוא לא יכול לעמוד בו. ברירת המחדל הבטוחה ביותר היא לא לנחש. צרו רשומת חריג, שמרו את ההקשר ונתבו את התיק לאדם או לתור הנכונים.
העריכו לפני הייצור, והמשיכו להעריך
סוכן שנראה מדויק בכמה דוגמאות שנבחרו בקפידה איננו מוכן לשימוש עסקי חי. בנו מערך הערכה ממקרים אמיתיים ואנונימיים שמייצגים עבודה רגילה, מקרי קצה, קלטים חלקיים, בקשות עמומות ודפוסי כשל מוכרים.
מדדו יותר מאיכות התשובות. בהתאם לתהליך העבודה, מדדים מועילים כוללים דיוק חילוץ שדות, שיעור ניתוב נכון, עמידה במדיניות, הצלחת קריאות כלים, איכות ההסלמה, זמן עד לפתרון ועלות לכל משימה שהושלמה. בסוכנים שפונים ללקוחות, מדדו גם אם התשובה התבססה על מקורות מאושרים ואם הסוכן נמנע מטענות לא מבוססות.
הבדיקות צריכות לכלול קלטים עוינים. משתמשים עלולים להדביק הוראות לא רלוונטיות בתוך מסמכים, לבקש מהסוכן להתעלם מהמדיניות או לספק תוכן זדוני דרך ערוצי מייל ותמיכה. הסוכן חייב להתייחס לתוכן חיצוני כאל נתונים, לא כאל סמכות. הגנות מפני prompt injection, הרשאות ברמת הכלי, אימות פלטים ובידוד הוראות רגישות הם חלק מתכנון הייצור.
אחרי ההשקה, נטרו את הביצועים באופן רציף. ספקי מודלים משתנים, נתונים פנימיים משתנים, ממשקי API מתפתחים והתנהגות המשתמשים בלתי צפויה. עקבו אחרי כשלים, בדקו מדגם של החלטות, נתחו הסלמות וקיימו תהליך שחרור מבוקר לפרומפטים, למודלים, לכלים ולמדיניות. סוכן הוא יכולת תפעולית, לא פיצ'ר חד-פעמי.
בחרו את מסלול האספקה הנכון
פיילוט מתאים כשתהליך העבודה מובן אבל רף האיכות, מורכבות האינטגרציה או הסיכון באימוץ המשתמשים עדיין לא ודאיים. פיילוט צריך להתחבר למערכות אמיתיות היכן שאפשר, להשתמש בנתונים מייצגים ולהגדיר מדד הצלחה. אב-טיפוס שרק מדגים שיחה עונה לעיתים רחוקות על השאלות שחשובות לעסק.
בתהליכי עבודה בנפח גבוה או רגישים לרגולציה, השקיעו מוקדם יותר בארכיטקטורה, בניהול זהויות, בתיעוד, ב-QA ובהקשחת האינטגרציה. זה דורש יותר מאמץ מהוכחת היתכנות מהירה, אבל חוסך בנייה מחדש של הפתרון אחרי שבעלי העניין מחליטים שהוא חייב לטפל בנתוני ייצור.
ב-Invatechs, המיקוד המעשי הוא אוטומציה מוחשית, לא הייפ AI גנרי: חיבור סוכן למערכות שבהן העבודה כבר מתבצעת, אכיפת בקרות עסקיות ומדידה אם התהליך באמת משתפר. המודל חשוב, אבל תהליך העבודה שסופק חשוב יותר.
הסוכן הראשון הטוב ביותר הוא לעיתים רחוקות השאפתני ביותר. הוא זה שמסיר נטל תפעולי גלוי, פועל בתוך בקרות ברורות ונותן לארגון ראיות לאן האוטומציה צריכה להתקדם בהמשך.
