רוב אינטגרציות ה־AI שראינו בפרודקשן נופלות לאחד משני כשלים: דמו מרשים שלא מחובר לזרימה עסקית אמיתית, או עטיפת LLM — ממשק צ׳אט מעל מודל בלי גישה לנתונים שעליהם העסק באמת עובד.
שניהם לא שימושיים. קופיילוט בלי גישה לנתונים העסקיים לא יכול להגיד דבר על העסק. קופיילוט עם גישה לנתונים בלי יכולת לפעול לא יכול לשנות דבר. הפער בין דמו AI למערכת AI הוא פרויקט הנדסי מלא.
מה קופיילוט אמיתי צריך
- —גישה לנתונים: קריאה ממקורות אמיתיים — מסדי נתונים, מסמכים, API, גיליונות
- —מודעות להרשאות: גישה רק לנתונים שהמשתמש הנוכחי מורשה לראות
- —קריאת כלים: יכולת לבצע פעולות — יצירת רשומות, עדכון מצבים, הפעלת תהליכים
- —ולידציית פלט: כל תשובה מאומתת לפני שהיא מגיעה למשתמש או מפעילה פעולה
- —זיכרון והקשר: שמירת הקשר בשיחה, ולעיתים גם בין סשנים
בעיית ההרשאות
מודלי שפה לא מבינים הרשאות. אם נותנים להם גישה למסד נתונים — הם ישאלו כל מה שהם יכולים להגיע אליו. בדמו עם נתונים סינתטיים זה בסדר. בפרודקשן זה אומר שנציג מכירות עלול לגשת לנתוני שכר.
כל קופיילוט שאנחנו בונים כולל שכבת הרשאות שמשקפת את מערכת האפליקציה הראשית. כשמשתמש שואל שאלה, המערכת קודם קובעת אילו מקורות נגישים לו, ורק אז בונה שאילתה בתוך הגבולות האלה.
הקופיילוט צריך לדעת מה שאתם יודעים. לא יותר, לא פחות.
ארכיטקטורת קריאת כלים
הקופיילוטים החזקים ביותר לא רק עונים — הם פועלים. קופיילוט שיכול רק לענות הוא מנוע חיפוש עם עטיפה שיחתית. קופיילוט שיכול ליצור רשומות, לשנות מצבים ולשלוח הודעות הוא כלי תפעולי.
קריאת כלים היא המנגנון שבו מודלים מבצעים פעולות מובנות. האתגר ההנדסי: להגדיר כלים מדויקים מספיק, ולאמת פלטים לפני שיש להם תופעות לוואי.
ולידציית פלט וספי ביטחון
מודלים מייצרים פלטים שנשמעים סבירים. הם לא תמיד נכונים. בשאילתה — טעות היא אי נוחות. בפעולה — טעות עלולה לשבש נתונים או להפעיל תהליכים שגויים.
כל קופיילוט עם יכולת פעולה כולל שכבת ולידציה: המודל מציע פעולה, השכבה בודקת תקינות מבנית, ואז מנתבת פעולות בביטחון גבוה לביצוע אוטומטי ופעולות בביטחון נמוך לסקירת אדם.
איך לחשוב על AI בהקשר עסקי
AI אינו פיצ׳ר מוצר. הוא שכבת האצה מעל תהליכים קיימים. השאלה לפני כל אינטגרציה: איזו זרימה זה מאיץ, ומה צוואר הבקבוק הנוכחי?