החלק הקשה ב-AI לארגונים הוא בדרך כלל לא הדמו הראשון. החלק הקשה הוא להפוך את המערכת לשימושית בתוך מגבלות עסקיות אמיתיות: זהות, בעלות על נתונים, תיעוד, זמינות, עלות, ניהול שינוי ואחריות.
הדפוס הזה ברור במיוחד בסביבות רגולטוריות ועתירות אינטגרציה. עבודה בהקשרים של ארגונים כמו Shva ו-Bituah Yashir, ושיתוף פעולה עם Dofinity, מחזקים לקח מעשי: AI חייב לכבד את מודל התפעול של הארגון לפני שהוא יכול לשפר אותו.
באיזה תהליך כדאי להתחיל פרויקט AI ארגוני?
מפת דרך ל-AI ארגוני צריכה להתחיל מתהליכים שבהם תמיכה טובה יותר בהחלטות, אוטומציה או איכות חיפוש יכולות לשנות תפוקה, סיכון או חוויית לקוח. השאלה השימושית היא לא "איפה אפשר להוסיף AI?", אלא "איזו החלטה, העברה או בדיקה איטית, יקרה או לא עקבית מדי?"
מועמדים טובים להתחלה כוללים משתמשים ברורים, קלטים חוזרים, תוצאות מדידות וכאב תפעולי קיים. מועמדים חלשים נשענים על ידע עמום, בעלות לא ברורה או נתונים שאסור לחשוף.
האם צריך אוטומציה, אחזור מידע או סוכן AI?
בחרו ארכיטקטורה לפי העבודה הנדרשת. חוקים קבועים מתאימים למשימות עם קלטים והחלטות ידועים. יצירה בשילוב אחזור מידע (RAG) מספקת למודל חומר רלוונטי ממקורות מידע. תהליך AI מוגדר פועל לפי שלבים שנקבעו בקוד; סוכן AI בוחר במהלך הריצה את הצעדים והכלים הבאים. אחזור מידע יכול להשתלב גם בתהליך מוגדר וגם בסוכן.
| צורך | גישה להתחלה | מה לבדוק |
|---|---|---|
| הפעלת חוקים ידועים או העברת נתונים מובנים | אוטומציה רגילה | בדיקת קלט, ניסיונות חוזרים והתאוששות |
| מענה על שאלות מתוך מסמכים מאושרים | אחזור מידע בשילוב מודל | הרשאות למקורות, רלוונטיות האחזור וביסוס התשובות |
| טיפול בבקשה בשלבים ידועים | תהליך AI מוגדר | בדיקות בין השלבים ובקרה אנושית לפי הצורך |
| בחירת הפעולה הבאה לפי תוצאות משתנות | סוכן AI עם גבולות פעולה | הרשאות כלים, תנאי עצירה, הערכה ועלות תפעול |
הטבלה מסייעת לתכנון ואינה דירוג של רמת הבשלות. לרקע הטכני ראו את ההבחנה של Anthropic בין תהליכים לסוכנים ואת מדריך Microsoft לתכנון ולהערכת RAG.
מתכננים ממשל לפני שהפיילוט הופך לייצור
הכי קל להוסיף ממשל כשהמערכת עדיין קטנה. צריך להגדיר מי הבעלים של מקרה השימוש, מי מאשר את התנהגות המודל, באילו נתונים מותר להשתמש, אילו פעולות דורשות אישור אנושי ואילו ראיות חייבות להישמר לביקורת או ניתוח אירועים.
זה חשוב במיוחד במערכות Agentic. צ'אטבוט שעונה על שאלות הוא פרופיל סיכון אחד. מערכת ששולפת נתוני לקוחות, פותחת קריאות, מנסחת הודעות או מפעילה פעולות עסקיות צריכה הרשאות, נקודות אישור, לוגים, מסלולי חזרה ומגבלות מפורשות.
מה מפריד בין אב-טיפוס AI למערכת ייצור?
| תחום | אב-טיפוס | ייצור |
|---|---|---|
| נתונים | מדגם שנבחר ידנית או גישת מפתח רחבה | מקורות מאושרים עם הרשאות לפי משתמש |
| איכות | בדיקה לא פורמלית של תשובות | מקרי בדיקה מייצגים, קטגוריות כשל וספי שחרור |
| פעולות | קריאה בלבד או סימולציה | כלים מוגבלים, ולידציה, אישורים, לוגים ונתיבי ביטול |
| תפעול | הבונה עוקב אחרי המערכת | בעלים מוגדרים, ניטור, בקרת עלות, חלופות ותגובה לתקלות |
מתייחסים לאינטגרציה כחלק מרכזי בארכיטקטורה
AI ארגוני הוא לרוב פרויקט אינטגרציה עם ממשק AI. הארכיטקטורה חייבת לחבר מודלים למערכות מקור אמינות, API, תורים, מאגרי מסמכים, זהות לקוחות, ניטור ותהליכי תמיכה.
איכות אחזור חשובה, אבל גם אמינות בסיסית: מזהים יציבים, גרסאות לפרומפטים, התנהגות חלופית דטרמיניסטית, מגבלות קצב, ניהול סודות, גבולות בין דיירים ובעלות ברורה כשמערכת upstream משתנה.
בונים לולאת הערכה שהעסק מבין
AI לייצור צריך הערכה עמוקה יותר מ-"התשובה נראית טובה". צריך להגדיר סטים לבדיקה מתוך התהליך האמיתי, לעקוב אחרי קטגוריות כשל, להשוות שינויי מודל ופרומפט, לבדוק מקרי קצה עם מומחי תוכן ולמדוד תוצאות שמעניינות הנהלה.
לולאת ההערכה צריכה לכלול אותות טכניים כמו latency ועלות, אבל גם אותות עסקיים כמו שיעור הסלמות, קבלת המלצות על ידי בודקים, הפרות מדיניות, זמן מחזור והשפעה על לקוחות.
איך מודדים את העלות של תוצאת AI שימושית?
מדדו עלות לתוצאה שאושרה, לצד שיעור הבקשות שהניבו תוצאה מאושרת. חלקו את העלות הכוללת של העבודה שנמדדה במספר התוצאות שעומדות בקריטריונים שהוגדרו. כללו עלויות מודל ותשתית, ניסיונות חוזרים ובדיקה אנושית באותה תקופה.
דוגמה להמחשה בלבד, שאינה תוצאת לקוח של TSI או הצעת מחיר: אם 100 בקשות עלו 20 דולר בשימוש במודל ובתשתית ועוד 80 דולר בזמן בדיקה, ו-80 תוצאות אושרו, העלות לתוצאה מאושרת היא 100 חלקי 80, כלומר 1.25 דולר. שיעור האישור הוא 80%. עקבו בנפרד אחר כשלי הרשאות ושגיאות חמורות אחרות כדי שהממוצע לא יסתיר אותן.
מכינים את הצוות לבעלות על המערכת
יישום AI לא מסתיים כשהגרסה הראשונה עולה לאוויר. הארגון צריך אנשים שיכולים לנטר איכות, לכוון פרומפטים ואחזור, לבדוק אירועים, לעדכן אינטגרציות, לנהל הרשאות ולהחליט מתי תהליך צריך להישאר אנושי.
בארגונים רבים המשמעות היא בניית יכולת פלטפורמה קטנה סביב AI: תבניות משותפות לזהות, אחזור, כלים, הערכות, ניטור ופריסה. כך צוותי מוצר יכולים לספק מקרי שימוש בלי לבנות מחדש את אותן בקרות סיכון בכל פעם.
מסלול מעשי ל-AI ארגוני
- בחרו תהליך אחד עם כאב תפעולי ברור ובעלים אחראים.
- מפו גישה לנתונים, הרשאות, מגבלות רגולציה ופעולות משתמשים לפני בחירת המודל.
- תכננו ארכיטקטורת ייצור סביב זהות, אחזור, כלים, לוגים, הערכה והתנהגות חלופית.
- השיקו עם בקרה אנושית במקומות שבהם הסיכון משמעותי, והפחיתו חיכוך רק כשהראיות תומכות בכך.
- צרו מודל תפעולי לצוות כדי שהמערכת תוכל להשתפר בבטחה לאחר הגרסה הראשונה.
מה חייב להיות נכון לפני השחרור?
- לתהליך יש בעלים עסקיים ותוצאה מדידה.
- לכל מקור נתונים וכלי יש גבול הרשאה מפורש.
- פעולות בעלות השפעה גבוהה דורשות אישור אנושי או בקרה מוצדקת.
- מקרי הערכה מכסים בקשות נפוצות וכשלים מוכרים.
- הלוגים כוללים את המודל, הפרומפט, הראיות, קריאות הכלים והתוצאה הדרושים לחקירה.
- הצוות יודע כיצד המערכת נכשלת, עוברת לחלופה ומושבתת.
כך AI הופך פחות לניסוי צדדי ויותר ליכולת ארגונית יציבה. TSI Integration תומכת במסלול המלא באמצעות אסטרטגיה וארכיטקטורת AI, יישום AI לייצור ובניית צוותי פיתוח.