לפי מדריך טכני שפרסם דניאל קוואנג (Daniel Quang) בבלוג של AWS, אימון בשיטת Multi-Turn Reinforcement Learning (MTRL) ב-Amazon SageMaker AI מאפשר לאמן מודלים עבור משימות של סוכני בינה מלאכותית (Agentic tasks). במשימות כאלה, סוכן נוקט רצף פעולות שבו כל שלב תלוי בפעולות שקדמו לו, לעיתים רחוקות ישנו רצף חיקוי נכון יחיד, והמשוב האמין היחיד הוא האם הרצף כולו הצליח. כוונון עדין מונחה (Supervised fine-tuning) אינו כולל תוויות למצבים כאלה, ולמידת חיזוק של פנייה בודדת אינה יכולה לתגמל החלטה שהתקבלה שלושה שלבים לפני התוצאה הסופית. שירות MTRL ב-SageMaker AI מאמן מודלים על בסיס האות הזה, כאשר המשתמש אינו מגדיר את מסלול הפעולות הרצוי אלא רק את אופן ניקוד התוצאה.
כדוגמה מלווה משמש המשחק Wordle, שבו לשחקן יש שישה ניסיונות לנחש מילה נסתרת בת חמש אותיות, ולאחר כל ניחוש מתקבל משוב שבו אות נצבעת בירוק אם היא במיקום הנכון, בצהוב אם היא במילה אך במיקום אחר, ובאפור אם אינה במילה. בניסוי המתואר במדריך, אימון MTRL העלה את שיעור הפתרון של המודל gpt-oss-20b מ-61 אחוז ל-84 אחוז על מילים שלא נכללו באימון במאמץ החשיבה המוגדר כברירת מחדל, ומ-15 אחוז ל-69 אחוז במאמץ חשיבה נמוך, בעלות טוקנים של כ-339 דולר.
ארכיטקטורת הפתרון, מודלים נתמכים ומודל התמחור
המערכת מורכבת משני חלקים עיקריים: שירות SageMaker AI מנהל את עבודת האימון (Training job) ואת מודל המדיניות (Policy model), ואילו Amazon Bedrock AgentCore מארח את הסוכן, את סביבת המשחק ואת פונקציית התגמול (Reward function). עבור כל תהליך פריסה ודגימה (Rollout), שירות MTRL מפעיל את סביבת ההרצה של AgentCore עם שורת אימון אחת המחזיקה מילה סודית. סוכן Strands בסביבת ההרצה פונה למודל המדיניות דרך נקודת קצה תואמת OpenAI של SageMaker Job Runtime. המודל מבצע עד שישה ניחושים דרך כלי ייעודי בשם guess_word, ולאחר כל ניחוש הסביבה מחזירה משוב פר אות וסיכום של המידע הידוע. כשהמשחק מסתיים, הסוכן מחזיר תגמול יחיד. אלגוריתם Group Relative Policy Optimization (GRPO) משתמש בפיזור התגמולים על פני כמה הרצות של אותה מילה כדי לעדכן מתאם LoRA על גבי מודל המדיניות.
במועד כתיבת המדריך, השירות פועל במודל Serverless ותומך בארבעה מודלי בסיס שכל אחד מהם מאומן עם מתאם LoRA: המודלים Amazon Nova 2 Lite ו-GPT-OSS-20B נתמכים באזורים US East (N. Virginia) ו-US West (Oregon), בעוד שהמודלים Gemma 4 31B (בגרסת instruction-tuned) ו-Qwen 3.6 27B נתמכים באזור US West (Oregon). במדריך נבחר המודל GPT-OSS-20B מכיוון שהוא בעל המחיר הנמוך ביותר לטוקן מבין הארבעה ומאמץ החשיבה שלו ניתן לשליטה פר בקשה.
התמחור מחושב לפי מיליון טוקנים בשלושה ממדים: Prefill (טוקני קלט הנקראים מחדש בכל תור ומצטברים במשימות מרובות שלבים), Sample (טוקנים שהמודל מייצר, כולל טוקני חשיבה), ו-Train (טוקנים המעובדים במעבר לאחור שמעדכן את מתאם ה-LoRA). ריצת האימון שכללה 100 צעדים צרכה 491.6 מיליון טוקני prefill (בעלות של 58.99 דולר לפי 0.12 דולר למיליון), 159.7 מיליון טוקני sample (בעלות של 47.92 דולר לפי 0.30 דולר למיליון), ו-643.3 מיליון טוקני train (בעלות של 231.59 דולר לפי 0.36 דולר למיליון), בסך כולל של 338.50 דולר על פני 105,486 הרצות במשך 12 שעות ו-40 דקות. צריכת vCPU וזיכרון בסביבת AgentCore חויבה בנפרד בסכום של כ-79 דולר.
הגדרת הרשאות, פריסת הסוכן ואימות סביבת ההרצה
תהליך ההגדרה מתחיל ביצירת שני תפקידי IAM:
- תפקיד סביבת ההרצה של הסוכן (Agent runtime role): נוצר באמצעות הפקודה agentcore deploy, נותן אמון ב-bedrock-agentcore.amazonaws.com ומחייב את המדיניות המנוהלת AmazonSageMakerJobRuntimeAccess.
- תפקיד עבודת האימון (Training job role): מוגדר על ידי המשתמש, נדרש לתת אמון ב-job.sagemaker.amazonaws.com עם הפעולות sts:AssumeRole ו-sts:TagSession, ומחייב את המדיניות AmazonSageMakerJobFullAccess. המדריך מציין כי ה-Principal הוא job.sagemaker.amazonaws.com ולא sagemaker.amazonaws.com הכללי, ששימוש בו מוביל לשגיאת Could not assume role.
הסוכן כולו מוגדר בקובץ פייתון יחיד (main.py) ונפרס באמצעות ה-CLI של AgentCore (הדורש Python 3.10 ומעלה, uv ו-Node 20 ומעלה, כאשר במכונה שמפעילה את העבודה נדרשת גרסת botocore 1.43.37 ומעלה). סביבת ההרצה קוראת שני משתני סביבה: REASONING_EFFORT המוגדר ל-low כדי להפחית את שימוש הטוקנים ב-63 עד 83 אחוזים לעומת medium, ו-REASONING_PROMPT_HINT המוגדר ל-true כדי להוסיף רמז להנחיית המערכת. נקודת הכניסה של הפונקציה עוטפת את הדקורטור sagemaker_rft_handler בתוך BedrockAgentCoreApp ו-app.entrypoint@, כאשר הדקורטור של נקודת הכניסה חייב להיות החיצוני ביותר כדי להפעיל שרת HTTP ולמנוע שגיאת Timeout לאחר 30 שניות.
לפני הקצאת משאבי אימון, המחברים ממליצים לבצע בדיקת תקינות (Smoke test) באמצעות פקודת aws bedrock-agentcore invoke-agent-runtime עם מזהה חשבון עדכני. הבדיקה שולחת מזהה מדומה של עבודה (Fake job ARN) ומוודאת שביומני CloudWatch מתקבלת שגיאת 400 עם הכיתוב Could not find job, המאשרת כי שלבי הפענוח, האימות והדיווח פעילים כראוי ומחזירים תגמול של -1.5.
הכנת מערך הנתונים והרצת האימון
מערך הנתונים של MTRL אינו מכיל תגובות יעד, תמלילים או תוויות, אלא שורות משימה בלבד. כל שורה כוללת מחרוזת בפורמט JSON עם שלושה שדות: הנחיה (prompt) המוצגת למודל, תשובה סודית (answer) המשמשת רק את הסביבה ופונקציית התגמול ואינה נחשפת למודל, ומזהה שורה (id). בדוגמה נוצרו 640 מילות אימון (חמישה מקבצים של 128) ו-128 מילות אימות ללא חפיפה ביניהן, והקבצים הועלו ל-Amazon S3. השירות תומך גם בפורמטים Apache Parquet, מערכי JSON ו-CSV.
עבודת האימון מופעלת באמצעות המחלקה MultiTurnRLTrainer מחבילת sagemaker-train. בהגדרות הניסוי נקבעו דריסות לשלושה היפר-פרמטרים: ערך sampling_max_tokens הוגדר ל-8192 (המקסימום בשירות) במקום ברירת המחדל של 4096 כדי למנוע מצב שבו המודל מסיים את מכסת הטוקנים בשלב החשיבה לפני קריאת הכלי הראשונה; max_epochs הוגדר ל-20; ו-max_steps הוגדר ל-100 (640 שורות עם גודל מקבץ גלובלי של 128 מייצרות 5 צעדים לכל epoch, ועם ערך ברירת מחדל של group_size השווה ל-8, כל צעד מריץ 1,024 משחקים). בנוסף, נדרשת הגדרת אפליקציית MLflow לקבלת המדדים. המדריך מזהיר מפורשות שלא לבצע פריסה מחדש של הסוכן בזמן ריצת עבודת האימון, שכן אתחול סביבת ההרצה גורם להפסקת בקשות הדגימה ולכישלון העבודה כולה.
ניטור, הערכת ביצועים בסביבת הגשה וניקוי משאבים
במהלך האימון, השירות מתעד סטטיסטיקות תגמול, טוקנים ותורות בכל צעד ומריץ אימות בכל מספר צעדים מוגדר. המדד המרכזי למעקב הוא val/reward/pass_at_1, המייצג את שיעור המילים שנפתרו מתוך מערך האימות. תגמול האימון עלה לכ-0.57+ בתוך 15 צעדים והתייצב שם. שיעור הפתרון באימות עלה מ-2 אחוזים ל-31 אחוזים בעשרת הצעדים הראשונים, ולאחר מכן נע בין 35 ל-48 אחוזים.
בדיקת הערכה (JobCategory המוגדר כ-AgentRFTEvaluation) מאפשרת לבחון את המודל המאומן או את מודל הבסיס בסביבת הגשה (Serving settings) שבה ניתן לבחור את הטמפרטורה, להבדיל מאימות האימון המקובע לטמפרטורה 0:
- בטמפרטורה 0 שני המודלים מסיימים לעיתים קרובות ללא פתרון בשני מאמצי החשיבה.
- עם הפעלת דגימה בטמפרטורה 1.0 ובמאמץ חשיבה בינוני (medium), המודל המאומן פתר 84 אחוזים מהמילים שלא נכללו באימון, לעומת 61 אחוזים במודל הבסיס.
- מתאם ה-LoRA הוסיף בין 14 ל-54 נקודות אחוז בשיעור הפתרון בכל אחת מארבע הגדרות הפיענוח שנבדקו. המחברים ממליצים לבצע הערכה בהגדרות ההגשה המיועדות בפועל, מאחר שעקומת האימות בטמפרטורה 0 הציגה שיעור פתרון סופי של 37 אחוז בלבד, בעוד שבהגדרות הגשה עם טמפרטורה 1.0 ומאמץ בינוני השיעור עמד על 84 אחוז. בדיקות ההערכה הללו ארכו כשעה ועלותן הייתה כ-1.20 דולר בטוקנים. בסיום התהליך, עבודות האימון וההערכה מפסיקות לחייב כשהן מסתיימות, אך סביבת ההרצה של AgentCore, תפקיד ה-IAM שלה, אפליקציית MLflow ואובייקטי ה-S3 ממשיכים להתקיים, והמדריך מספק פקודות למחיקתם.
לקחים מתכנון פונקציית התגמול ותקלות אימון
תכנון פונקציית התגמול דרש תיקון לאחר שהתכנון הראשוני סכם ניקוד עבור כל ניחוש בנפרד לאורך כל המשחק ויצר שני עיוותים: משחק שהסתיים בהפסד הניב תגמול חיובי של כ-0.49+ בעקבות בונוסים מצטברים, ופתרון בניחוש הראשון קיבל ציון נמוך יותר (0.99+) מפתרון בניחוש השלישי (1.61+). התיקון הפריד בין רכיב תוצאה דומיננטי לבין רכיב עיצוב תגמול (shaping) מוגבל: הנוסחה שיושמה היא reward = outcome + w * clip(shaping, -1, 1), כאשר המשקל w נקבע ל-0.04 עבור פתרון ו-0.15 עבור הפסד. רכיב התוצאה מעניק בין 1.05 ל-1.55 בהתאם למהירות הפתרון (1.55 בניחוש ראשון ועד 1.05 בניחוש שישי), הפסד לאחר שישה ניחושים מעניק ציון של -0.5, ואי-ביצוע ניחוש תקין מעניק ציון של -1.5. רכיב העיצוב כולל קנסות על סתירת אותיות ידועות ובונוסים על ניסוי אותיות חדשות וצמצום מרחב האפשרויות. משקל הפתרון הנמוך (0.04) מבטיח שפתרון מהיר יותר תמיד יקבל ציון גבוה יותר מפתרון איטי, ושכל פתרון ידורג מעל כל הפסד.
בנוסף, המחברים פירטו ארבע תקלות שגרמו לכישלון ריצות אימון:
- עומס על אסימוני Bearer: יצירת אסימון עם session חדש בכל קריאה גרמה למחסור במשאבי ספק ההרשאות ב-32 הרצות מקבילות, בעוד שמירה במטמון לשעה גרמה לשגיאות 403 בעת החלפת אישורים. הפתרון היה שימוש ב-session בעל רענון עצמי, מטמון קצר וחתימה מחדש בעת שגיאת 403.
- ניתוק מודל המדיניות: כאשר קריאות המודל נכשלו באימות, השירות ביטל את העבודה כולה עם השגיאה No sampling requests were received. על הסוכן להחזיר תמיד תגמול (למשל -1.5) ולא סטטוס שגיאה.
- גלישת קריאות כלים לטקסט רגיל: קצב למידה גבוה גרם למודל להפיק קריאות כלים כטקסט חופשי במקום מבנה תקין, מה שהוביל לרצפת תגמול קבועה ולהיעלמות הגרדיאנט. הסוכן עודכן לחלץ ניחושים מטקסט גולמי עם קנס עיצוב קל.
- התייצבות מוקדמת (Plateau): תגמול האימון הפסיק לעלות סביב צעד 15 ותגמול האימות נעצר סביב צעד 30. המחברים ציינו כי בעתיד יש לבחון שימוש בתוכנית לימודים (Curriculum) המזינה משחקים עם ניחושים קודמים או הגדלת מספר ההרצות למילה מעבר לערך ברירת המחדל של 8.