פיתוח מוצרי AI ו-SaaS מרעיון ל-MVP ועד השקה

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

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

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

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

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

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