סוכני AI שעובדים באמת: ניהול קונטקסט ומיומנויות מודולריות

סוכני AI שעובדים באמת: ניהול קונטקסט ומיומנויות מודולריות

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

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

נקודות מפתח

• פרומפטים מונוליטיים הם האויב של אמינות ותקציב.
• ספקי קונטקסט (Context Providers) מאפשרים לסוכן לגשת רק לנתונים הדרושים למשימה הספציפית.
• מיומנויות מודולריות (Skills) מפרידות בין הלוגיקה של "איך לבצע" לבין המידע של "מה לדעת".
• צמיחה דורשת הפרדה ברורה בין ליבת הסוכן לבין הכלים החיצוניים שלו.

למה סוכן ה-AI הנוכחי שלכם כנראה נכשל

אם בניתם סוכן שלוקח מסמך של 10,000 מילה ומנסה לענות על שאלות לגביו במכה אחת, אתם עושים את זה לא נכון. ה-"Context Window" הוא לא דלי שצריך למלא עד הסוף. כשדוחסים יותר מדי מידע לפרומפט אחד, המודל מאבד ריכוז. הוא סובל מתופעת ה-"Lost in the Middle", שבה הוא פשוט מתעלם מהנתונים שנמצאים במרכז הטקסט שלכם.

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

⁨AI Strategy Consulting service⁩

האמנות של זיכרון סלקטיבי: ספקי קונטקסט

תחשבו על ספק קונטקסט (Context Provider) כעל ספרן. במקום שהסוכן יסחב כל ספר בספרייה, הוא מבקש מהספרן את הדף הספציפי שהוא צריך. במונחים טכניים, זה אומר שימוש ב-RAG (Retrieval-Augmented Generation) או שאילתות לבסיס נתונים שמופעלות רק כשזה רלוונטי.

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

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

מיומנויות מודולריות: גישת האולר השוויצרי

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

דמיינו סוכן AI לנסיעות.

מיומנות אחת היא "חיפוש טיסות". מיומנות שנייה היא "הזמנת מלון". שלישית היא "המרה של מטבע".

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

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

⁨Automations for SMBs⁩

העלות הנסתרת של סוכנים "חכמים"

יש מלכודת בעולם ה-AI: האמונה שמודל חכם יותר (כמו GPT-4o או Claude 3.5) פותר את כל הבעיות. הוא לא. אם הארכיטקטורה שלכם מבולגנת, מודל חכם יותר פשוט יעשה טעויות יקרות יותר.

אנחנו רואים לעיתים קרובות עסקים קטנים ובינוניים שבוהים בחשבון API של 500 דולר בחודש עבור כלי שחוסך להם רק חמש שעות עבודה. זו השקעה גרועה. על ידי הטמעת מיומנויות מודולריות וניהול קונטקסט חכם, ראינו מקרים שבהם עלות ה-API ירדה ב-80% בזמן שהדיוק עלה.

פרגמטיות פירושה בחירת הכלי הנכון למשימה. לפעמים, "מיומנות" בכלל לא צריכה מודל שפה. היא יכולה להיות סקריפט פשוט בפייתון. מערכת אג'נטית אמיתית יודעת מתי להשתמש ב-AI ומתי להשתמש במשפט if-then פשוט.

איך להתחיל לבנות סוכנים טובים יותר היום

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

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

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

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

שאלות ותשובות (FAQ)

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

ש: איך אני יודע אם אני צריך ספק קונטקסט? אם הפרומפטים שלכם הופכים לארוכים מ-2,000 מילה או אם עלויות ה-API שלכם גדלות מהר יותר מהשימוש שלכם, אתם צריכים אחד.

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

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

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