פיתוח מערכת הסקת AI על בלוקצ'יין

מדוע הסקת מסקנות AI on-chain שוברת את הפרודקשן

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

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

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

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

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

מה נותן הוצאת האינפרנס לבלוקצ'יין

בדיקוּת של מסקנות במקום אמון במפעיל

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

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

התאוששות לאחר כשל של צומת

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

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

כלכלה והיקף

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

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

מה זה משנה עבור המוצר

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

אפשרויות ארכיטקטורת אינפרנץ': השוואה

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

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

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

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

כיצד אנו מטמיעים מערכת אינפרנס: שלבים

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

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

תכנון הסכמה והגדרת הצמתים

הסכמה קובעת כיצד הבקשה מגיעה לרשת, מי מבצע את החישוב וכיצד התוצאה מאומתת. אנו בוחרים בין on-chain AI inference מלא לבין אפשרות היברידית עם הוכחת נכונות — ההבדל בעלות הגז ובדרישות לחומרת הצמתים.

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

1. ביקורת המודל הנוכחי: מודדים השהיה, נפח נתוני קלט, שיעור פעולות לא-דטרמיניסטיות.
2. תכנון הסכמה: מפזרים את החישוב בין החוזה, האורקל והמבצע החיצוני.
3. הגדרת הצמתים: תצורת לקוח, סנכרון, מגבלות, מדיניות ניסיונות חוזרים.
4. פריסה ברשת בדיקה: הרצת תרחישים עם אי-התאמה בתוצאות וכשל צומת.
5. בדיקה ברשת בדיקה: הרצות עומס, מדידת גז, השוואת תשובות בין הוולידטורים.
6. מסירה: תיעוד תצורה, הוראות לעדכון המודל, ניתוח תקלות.

מה אנו בודקים לפני המסירה

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

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

ארטיפקטים ותיעוד לאחר ההטמעה

הטמעת on-chain AI inference אינה מסתיימת בהרצת המערכת — הלקוח מקבל סט ארטיפקטים שלפיהם ניתן להפעיל את המערכת, להרחיב אותה ולהעביר אותה לצוות אחר ללא הסכמות בעל פה. להלן מה בדיוק נשאר בידיים לאחר המסירה.

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

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

מקרה בוחן: האצת האינפרנס פי שלושה

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

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

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

מדדים לפני ואחרי

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

במה שונה on-chain inference מ-off-chain?

ההבדל המרכזי הוא היכן פיזית מבוצעת המודל. ב-on-chain inference החישוב מתבצע בתוך חוזה חכם: נתוני הקלט ומשקולות המודל מעובדים בתוך הרשת עצמה, והתוצאה נרשמת במצב החוזה. ב-off-chain inference המודל מחושב מחוץ לרשת, ולתוך החוזה נכנסים רק התוצאה וההוכחה לנכונותה. המצב הראשון מעניק שקיפות מקסימלית, והשני — ביצועים מעשיים.

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

אימות התוצאה — הוא מה שמקשר בין שני המצבים. Off-chain inference אינו אומר "סמוך על המבצע": התוצאה מאושרת קריפטוגרפית. המבצע מפרסם את פלט המודל יחד עם הוכחה — либо אינטראקטיבית (בוררות באמצעות ערעור), либо קומפקטית קריפטוגרפית, שהחוזה מאמת במספר פעולות קבוע. החוזה אינו מחשב מחדש את המודל, אלא מאמת את ההוכחה — זה זול בסדרי גודל.

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

בחירת המצב היא בחירה בין עלות החישוב לעלות האמון. אם המודל קומפקטי והתוצאה נדרשת בתוך הרשת עצמה — מחשבים on-chain. אם המודל כבד — מחשבים off-chain, ואל החוזה מוציאים את הווריפיקציה, שמבטיחה שהתוצאה לא הוחלפה.

ספקות טכניים נפוצים

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

האם ניתן לעדכן מודל ללא השבתה?

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

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

מהן המגבלות על תפוקת הצומת הפרוס?

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

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

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

בואו נדון במשימת האינפרנס שלכם

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

תארו את המשימה בצורה חופשית — בהמשך נשאל שאלות ממוקדות ונציע קו עבודה של on-chain AI inference המותאם לתרחיש שלכם.

מה תקבלו בתפוקה:

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

תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.