הבעיה: העבודה גרה בלשונית
נגיד שבניתם כלי שמסכם מסמכים. הלקוח מעלה קובץ, רואה גלגל מסתובב, יוצא לפגישה וסוגר את הלשונית. כשהוא חוזר, המסך ריק. הוא לא יודע אם הסיכום עוד רץ, אם הוא נכשל, או שצריך להעלות את הקובץ שוב.
הבעיה היא לא שה-AI איטי. הבעיה היא שהעבודה תלויה בחיבור אחד פתוח בין הדפדפן לשרת, ואין לה שם, מספר או מצב שאפשר לחזור אליו.
המטרה: להפריד בין “קיבלנו את הבקשה” לבין “סיימנו לבצע אותה”.
מה זה עיבוד אסינכרוני
תחשבו על בית קפה. מזמינים, מקבלים מספר הזמנה ומתרחקים מהקופה. זה עובד רק אם ההזמנה באמת נרשמה במטבח לפני שאמרו לכם “קיבלנו”. מספר על פתק בלי הזמנה במטבח לא יעזור לאף אחד.
באפליקציה זה נראה כך: השרת שומר את הקובץ ואת המשימה, ורק אז עונה מיד עם אישור קבלה ומזהה משימה. העבודה עצמה נעשית אחר כך, בתהליך נפרד, והמסך בודק את המצב לפי אותו מזהה.
| בבית הקפה | באפליקציה |
|---|---|
| הקופה | השרת (API) שמקבל את הבקשה |
| ההזמנה רשומה במטבח | קובץ ומשימה שמורים במקום שלא תלוי בלשונית |
| מספר ההזמנה | מזהה משימה, למשל job_27 |
| רשימת ההזמנות שמחכות | התור (queue) |
| הבריסטה | עובד הרקע (worker) |
| הלוח עם המספרים | מסך סטטוס: ממתין, בעבודה, הושלם, נכשל |
מה זה לא עושה: זה לא מאיץ את ה-AI. זה מנתק את העבודה מההמתנה מול המסך.
תרשים הזרימה
שבעה שלבים, ארבעה שחקנים. הלשונית יכולה להיסגר אחרי שלב 3.
השלבים במילים
1. המשתמש מעלה קובץ ולוחץ “סכם”.
2. השרת שומר את הקובץ באחסון ויוצר רשומת משימה במצב “ממתין”. רק אחרי ששתי השמירות הצליחו ממשיכים.
3. השרת עונה מיד: 202 Accepted ומזהה משימה. זו ההבטחה “קיבלנו”, לא “סיימנו”.
4. לתור נכנסת הודעה קטנה עם מזהה המשימה והפניה לקובץ. לא את כל המסמך.
5. עובד הרקע לוקח את ההודעה, מעדכן “בעבודה”, מייצר סיכום, שומר תוצאה ומעדכן “הושלם”.
6. אם העובד נפל באמצע, התור מחזיר את המשימה. לפני שמתחילים שוב, בודקים מה כבר נשמר.
7. המשתמש חוזר מתי שהוא רוצה, פותח את המשימה לפי המזהה ורואה סטטוס ותוצאה. רק אם המשימה שלו.
כך זה נראה בתיעוד של Microsoft, שקורא לזה Asynchronous Request-Reply:
POST מקבל 202, ואז GET לכתובת הסטטוס עד שהתוצאה מוכנה.
מה בונים בפועל
1. קלט ומשימה שנשמרים לפני אישור
הקובץ נשמר באחסון, ולמשימה יש מזהה ומצב. לא מודיעים “התקבל” לפני שהשמירה הצליחה. אם הקובץ והמשימה נשמרים בשני מקומות שונים, צריך לתכנן גם מה קורה כשרק אחד מהם הצליח.
2. תור עמיד
שירות שמחזיק משימות עד שעובד לוקח אותן. לא מערך בזיכרון של הדפדפן ולא משתנה בשרת שנעלם באתחול. שירות מנוהל מספיק ברוב המקרים.
3. הפניה, לא מטען
בתור שמים את מזהה המשימה ואת המיקום של הקובץ. המסמך עצמו נשאר באחסון. ל-Microsoft יש לזה שם: Claim Check.
await queue.send({ jobId: "job_27", file: "uploads/f_91.pdf" });4. עובד רקע שיודע ליפול
תהליך נפרד שלוקח משימה, שומר סטטוס ותוצאה, ומתמודד עם כשל. תורים רבים מוסרים הודעה לפחות פעם אחת, כלומר לפעמים יותר מפעם אחת. לכן העובד צריך לבדוק אם כבר יש תוצאה לפני שהוא מייצר אותה שוב. זה בדיוק העיקרון מפרק 1.
5. מסך סטטוס עם הרשאות
ממתין, בעבודה, הושלם או נכשל, לפי אותו מזהה. מזהה שקשה לנחש הוא לא הרשאה: גם הסטטוס וגם התוצאה נבדקים מול בעל המשימה.
6. ניסיונות חוזרים מוגבלים
מספר ניסיונות מוגדר, השהיה ביניהם, ומצב “נכשל” ברור בסוף. לא לולאה אינסופית ולא ניסיון חוזר על שגיאה שלא תשתנה.
הפרומפט לסוכן הקוד
מעתיקים כמו שהוא לסוכן הקוד שלכם (Claude Code או כל סוכן אחר), בתוך הפרויקט:
נתח את תהליך יצירת הסיכום בפרויקט. אל תחליף תשתית בלי להסביר למה.
הצע את הדרך הפשוטה ביותר לשמור קובץ ומשימה באופן עמיד לפני אישור הקבלה, להחזיר מזהה משימה, ולעבד אותה בנפרד מהדפדפן.
שמור סטטוס (ממתין, בעבודה, הושלם, נכשל) ותוצאה, ואכוף גישה לפי בעל המשימה.
תכנן מה קורה אם רק חלק מהשמירה מצליח.
הוסף timeout, ניסיונות חוזרים מוגבלים וטיפול בטוח בעיבוד חוזר של אותה משימה, לפי התיעוד של השירות שבחרת.
כתוב בדיקות עם ספק AI דמה, בסביבת בדיקה בלבד: סגירת לשונית, אתחול עובד וכשל זמני.
אל תבצע פעולות בסביבת ייצור ואל תגרום לחיובים. החזר תוצאות אמיתיות של הבדיקות ומה עדיין לא נבדק.
הגרסה הקצרה מהסרטון, אם רוצים רק לבדוק אפליקציה קיימת:
בסביבת הבדיקה: שמור קובץ ומשימה לפני אישור קבלה. סגור לשונית ואתחל את עובד הרקע. הוכח שאפשר לחזור לסטטוס ולתוצאה.
תשע בדיקות קבלה
תנו לסוכן להריץ את כולן בסביבת בדיקה עם ספק AI דמה, ובקשו ממנו להראות את הפלט ולא רק לכתוב “עבר”.
| # | בדיקה | איך בודקים | מה צריך לראות |
|---|---|---|---|
| 1 | סגירת לשונית | שולחים קובץ, מקבלים מזהה, סוגרים את הלשונית ופותחים את המשימה מחדש | אותה משימה עם אותו סטטוס. לא התחלה מאפס |
| 2 | אתחול עובד | מכבים את עובד הרקע באמצע עבודה ומפעילים אותו שוב | המשימה לא נעלמה, ממשיכה או מתחילה מחדש בצורה מסודרת |
| 3 | כשל זמני של הספק | ספק ה-AI הדמה נכשל פעם אחת ואז מצליח | ניסיון חוזר אחד או שניים, ואז הושלם |
| 4 | כשל קבוע | קובץ שהספק לא יכול לעבד בכלל | מצב נכשל עם הודעה ברורה. לא לולאה אינסופית |
| 5 | עיבוד כפול | מוסרים את אותה משימה לתור פעמיים | תוצאה אחת. אין חיוב, מייל או דוח כפול |
| 6 | משתמש אחר | משתמש ב פותח את הסטטוס והתוצאה של משימה של משתמש א, עם המזהה הנכון | 403 או 404. שום פרט לא נחשף |
| 7 | תור מתמלא | שולחים כמות קטנה ומוגבלת של משימות בבת אחת | הן ממתינות ומעובדות לפי הסדר, והמשתמש רואה “ממתין” ולא שגיאה |
| 8 | שמירה חלקית | הקובץ נשמר אבל יצירת המשימה נכשלת | אין אישור קבלה שקרי, והקובץ היתום מטופל או נמחק |
| 9 | תוצאה נשמרה לפני ניתוק | העובד שומר תוצאה ונופל לפני שעדכן סטטוס | חוזרים לסטטוס ורואים את התוצאה הקיימת, בלי לייצר אותה שוב |
מה תור לא מבטיח
- הוא לא מאיץ את העבודה. אותו סיכום לוקח אותו זמן.
- הוא לא מבטיח “בדיוק פעם אחת”. צריך לתכנן עיבוד חוזר בטוח.
- 202 Accepted לא אומר שהעבודה הצליחה. הוא אומר שהיא נשמרה ותטופל.
- מסך סטטוס יפה לא עוזר אם המשימה לא נשמרה באמת.
- לא כל פעולה צריכה תור. משהו שמסתיים בשנייה יכול להישאר רגיל.
טיפים
- בקשו מהסוכן לצייר לכם את הזרימה לפני שהוא כותב קוד. אם הוא לא יודע איפה המשימה נשמרת, גם הקוד לא יידע.
- הריצו את בדיקה 1 בעצמכם בדפדפן: שלחו קובץ, סגרו לשונית, חזרו. זו הבדיקה שהלקוח יעשה ראשון.
- תנו למזהה המשימה להופיע בכתובת, למשל summarize.app/jobs/job_27. ככה אפשר לשמור אותו, לשלוח אותו או לחזור אליו.
- שמרו בשורת המשימה מתי נוצרה, כמה ניסיונות היו ומה השגיאה האחרונה. זה חוסך שעות של ניחושים.
- מחקו קבצים ותוצאות ישנים לפי מדיניות. אחסון שרק גדל הוא בעיה של עוד חודשיים.
לינקים
- Asynchronous Request-Reply: learn.microsoft.com
- Claim Check: learn.microsoft.com
- Background jobs: learn.microsoft.com
- Amazon SQS at-least-once delivery: docs.aws.amazon.com
- פרק 1 בסדרה, תשלום כפול ואידמפוטנטיות: המדריך
- הבדיקות כאן הן התאמה לימודית שלנו, לא בדיקות שכבר רצו על האפליקציה שלכם.
