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

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

1. אתר שולח מייל לנרשמים חדשים.

2. אתר לוח מודעות מטפל במשתמש שמעלה מודעה חדשה עם תמונה. התמונה עוברת עיבוד ושינוי גודל ברקע והמודעה עולה לאתר.

3. מערכת לבניית דפי נחיתה מוציאה ברקע תעודות SSL לדומיין של משתמשים.

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

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

בעולם הישן מערכות השתמשו ב Thread Pool כדי לנהל את כל התהליכים במקביל. היה לך מאגר של 5-8 תהליכונים שרצים ברקע (20 למיטיבי לכת). כל תהליך תופס משימה, מבצע אותה, משחרר וממשיך למשימה הבאה. צריכים לשלוח מייל למישהו שנרשם? מצוין תוסיף את המשימה הזאת לתור המשימות, כשיתפנה אחד הפועלים הוא ייקח את המשימה מהתור, ישלח את המייל וימשיך למשימה הבאה. קל.

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

מה עושים? זורקים את מודל התהליכונים ועוברים למודל לא כל כך חדש של מענה אסינכרוני, או למודל קצת יותר חדש של Fibers (ברובי) או Virtual Threads (ב Java). בשני המקרים אנחנו עולים בקיבולת ומטפלים בעזרת מספר קטן של תהליכונים בעשרות אלפי בקשות במקביל. התהליכון "מקפץ" בין התשובות כמו נציג שירות שמדבר אתכם בווטסאפ, וכל פעם שיש מידע חדש מאיזשהו מודל שפה מערכת ההפעלה מעבירה את המידע לאותו תהליכון שיודע לנתב את המידע חזרה לגולש.

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

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

ActiveRecord::Base.connection_pool.release_connection
chat.complete