כלי שיחה וחיבור למערכת פותרים צרכים שונים
צוות יכול להפיק ערך מכלי AI שמסייע לכתוב טיוטה או לסכם מסמך, בלי לפתח מערכת חדשה. הצורך ב־API עולה כאשר רוצים שהיכולת תשתלב בתוך תהליך קיים: בקשה מגיעה למערכת, מידע מורשה נשלף, נוצרת הצעה, ואדם מאשר את המשך הטיפול. השאלה היא איזו עבודה צריך להסדיר, ולא רק איזה מודל לבחור.
API הוא ממשק שדרכו תוכנה מתקשרת עם שירות אחר. בחיבור AI, האפליקציה הארגונית מנהלת את המשתמש, ההקשר והפעולה, ושירות המודל מבצע משימה מוגדרת. מנוי ChatGPT ושימוש ב־API הם מסלולי חיוב נפרדים; אין להניח שמנוי לצוות מממן גם את האינטגרציה. הסבר OpenAI על חיוב ChatGPT ו־API.
בוחרים משימה עם גבולות ותוצר ברור
התחילו מצורך שאפשר לתאר במשפט: הצעת סיווג לפנייה, טיוטת תשובה המבוססת על מסמכים מאושרים או חילוץ שדות ממסמך לבדיקה. הגדירו מי משתמש בתוצר, איזו החלטה הוא מסייע לקבל ומתי התוצאה אינה טובה מספיק לשימוש.
לא כל שלב דורש AI. אם כלל קבוע פותר את הבעיה, חיבור רגיל בין מערכות עשוי להיות פשוט יותר לבדיקה ולתחזוקה. אפשר לשלב: קוד בודק שהנתונים שלמים, המודל מציע סיכום, ואדם מאשר פעולה עסקית. כך האחריות אינה מוסתרת בתוך תשובה בשפה טבעית.
לפני בחירת ספק או מודל, אספו דוגמאות מורשות שמייצגות עבודה אמיתית. כללו גם מקרים חסרים, סותרים ולא ברורים. תוצאה מרשימה בדוגמה אחת אינה מספיקה כדי להחליט שהפתרון מתאים לתהליך כולו.
מתכננים את זרימת המידע וההרשאות
שרטטו מה נכנס לתהליך, מאיזו מערכת, מי רשאי לראות אותו ולאן עובר התוצר. החיבור אינו אמור להעניק למשתמש גישה רחבה יותר מזו שנדרשת לתפקידו. בדיקת הרשאה צריכה להתבצע במערכת שמגישה את המידע, ולא להסתמך רק על הוראה טקסטואלית למודל.
OpenAI מציינת שנתוני API אינם משמשים לאימון המודלים כברירת מחדל, אלא אם הלקוח בוחר לשתף אותם. עם זאת, קיימים כללים נפרדים ללוגים ולמידע שנשמר לצורך תכונות מסוימות; ״לא משמש לאימון״ אינו אומר ״לא נשמר״. יש לבדוק את השירות, התכונה וההגדרות שבשימוש. תיעוד בקרות המידע.
שמרו מפתחות גישה בצד השרת ובמנגנון ניהול סודות מתאים, והגבילו את הרשאותיהם. אין לשתול מפתח סודי בדפדפן או בקוד שנמסר ללקוח. תכננו גם החלפת מפתחות וטיפול בחשד לחשיפה, בהתאם להנחיות הספק. הנחיות OpenAI לשמירת מפתחות API.
מפרידים בין המלצה לבין ביצוע
סיכום מידע והעברת כסף אינם אותה רמת סיכון. בתחילת הדרך מומלץ להציג תוצר לבדיקה לפני שליחה ללקוח או כתיבה למערכת עסקית. המשתמש צריך לראות את המידע שעליו נשענת ההצעה, להבין מה חסר ולתקן את התוצאה.
בפעולות אוטומטיות, הגדירו רשימה מצומצמת של פעולות מותרות ובדיקות רגילות של שדות, הרשאות ומצב הרשומה. תכננו מה יקרה אם בקשה תישלח פעמיים או אם התקבלה תשובה לאחר שהמשתמש כבר ביטל את הפעולה. למודל אין צורך לקבל שליטה כללית כדי לסייע במשימה מוגדרת.
ההנחיות של OpenAI כוללות בדיקות של קלט בעייתי וביקורת אנושית על תוצרים, במיוחד כאשר לטעות עשויה להיות השפעה משמעותית. הן אינן הופכות את המודל למקור מידע חסין שגיאות. המלצות לבטיחות ביישומי AI.
בודקים תועלת, איכות ועלות באותה מסגרת
בתרחיש היפותטי, צוות שירות מבקש טיוטת תשובה לפניית לקוח על נוהל מאושר. המערכת שולפת מסמך שהנציג רשאי לקרוא, מציגה את המקור ומסמנת שאין תשובה כשחסר מידע. הנציג בודק ומאשר; המערכת מתעדת אם נדרשה עריכה ומה הייתה סיבתה.
ההשוואה צריכה לכלול את זמן העבודה הכולל, לרבות בדיקה ותיקון, ואת התאמת התשובה למקור. מדדו גם תקלות, עלות שימוש והיקף אימוץ. הגדירו מראש אילו טעויות מחייבות עצירה ואילו אפשר לטפל בהן במסגרת שיפור רגיל.
עלות הפרויקט כוללת יותר מקריאות למודל: חיבורי מערכות, אחסון נחוץ, בדיקות, ניטור ותחזוקה. בנו תקציב לפי עומס צפוי ובדקו אותו מול שימוש בפועל. התראות אינן תמיד מנגנון עצירה, ולכן יש לוודא כיצד נאכפות המכסות שנבחרו ומה קורה כשהן מתמלאות.
שאלות נפוצות
האם חייבים לבנות מערכת חדשה?
לא. לעיתים אפשר להשתמש ביכולת קיימת בכלי הארגוני, או להוסיף ממשק קטן למערכת קיימת. בחירת פיתוח מותאם צריכה לנבוע מפער ברור בתהליך, בהרשאות או באינטגרציה.
האם צריך לאמן מודל על כל מסמכי החברה?
לא בהכרח. אפשר להתחיל בשליפה של מידע מאושר לפי הבקשה ובהעברת הקשר ממוקד. בחירת שיטת הפתרון תלויה במשימה, באיכות המקורות ובדרישות המידע, ולא בהנחה שכל פרויקט דורש אימון.
מי מתחזק את הפתרון לאחר הפיילוט?
צריך להגדיר בעל תהליך עסקי ובעל אחריות טכנית. שינוי במקור מידע, בממשק או בשירות המודל מחייב בדיקות מתאימות, תיעוד ומסלול טיפול כאשר התוצאה נפגעת.
DLTS מתכננת הטמעת AI בארגונים וחיבור מערכות. מתחילים מתהליך עסקי מוגדר, בוחנים את המידע והבקרות, ומחליטים לפי תוצאות הפיילוט אם ואיך להרחיב.