يُعلّم معظم الضبط الدقيق (fine-tuning) النموذج أن ينتج إجابة أفضل لموجّه واحد. أما المهام الوكيلة (agentic tasks) فتختلف. فالوكيل الذي يقدّم تقرير مصروفات أو يصنّف تذكرة دعم ينفّذ سلسلة من الإجراءات، وتعتمد كل خطوة على ما سبقها. ونادراً ما توجد سلسلة صحيحة واحدة تُحاكى، والوحيد من الملاحظات الموثوق هو ما إذا كانت السلسلة بأكملها قد نجحت. فالضبط الدقيق الموجّه لا يتوفر لديه تصنيفات (labels) لذلك، ولا يمكن لتعلّم التعزيز أحادي الدور أن يُنسب الفضل إلى قرار اتُّخذ قبل ثلاث خطوات من النتيجة.
يتيح التعلّم المعزّز متعدد الأدوار (MTRL) على Amazon SageMaker AI تدريب النماذج على هذا الإشارة تحديدًا. يرسل SageMaker AI المطالبات إلى وكيل تستضيفه على Amazon Bedrock AgentCore، أو على بنيتك التحتية الخاصة، مثل Amazon Elastic Kubernetes Service (Amazon EKS) أو Amazon Elastic Compute Cloud (Amazon EC2) أو AWS Fargate، من خلال مُعِدّ AWS Lambda الأمامي (forwarder). يستخدم المثال هنا AgentCore. يستدعي الوكيل نموذج السياسة قيد التدريب، ويتصرف في بيئتك على مدار عدد من الأدوار (turns) حسب حاجة المهمة، ويُبلّغ عن مكافأة واحدة عند انتهاء الحلقة (episode). أنت لا تحدد المسار الصحيح، بل فقط كيفية تقييم النتيجة.
تستخدم هذه التدوينة Wordle, وهي لعبة يحاول فيها اللاعب تخمين كلمة مخفية من خمسة أحرف ضمن ست محاولات، كمثال. بعد كل تخمين، يتحول كل حرف إلى اللون الأخضر إذا كان في الموضع الصحيح، وأصفر إذا كان موجودًا في الكلمة لكن في موضع مختلف، ورمادي إذا لم يكن موجودًا في الكلمة. تناسب اللعبة تعلم MTRL لأن قواعدها قليلة، وكل تخمين يعتمد على ملاحظات التخمين السابق، وتُقيَّم النتيجة بشكل موضوعي. Wordle مثال تعليمي، والنماذج الرائدة تلعبها بالفعل بمهارة. عمليًا، ستستخدم MTRL لجعل نموذج صغير ومنخفض التكلفة بارعًا في مهمة متعددة الخطوات خاصة بنشاطك التجاري، مثل سير عمل داخلي لم تُدرَّب عليه النماذج العامة أبدًا. وينطبق خط الأنابيب نفسه على تلك الحالة.
في تجربتنا، رفع MTRL معدل حل gpt-oss-20b من 61 إلى 84 بالمئة على كلمات محجوزة للتقييم عند مستوى الاستدلال الافتراضي، ومن 15 إلى 69 بالمئة عند المستوى المنخفض الذي تدرّب عليه، مقابل نحو 339 دولارًا في رموز التدريب. في هذه التدوينة، نستعرض خط الأنابيب من البداية إلى النهاية: نشر الوكيل والمكافأة على AgentCore، وإعداد مجموعة البيانات، والتدريب، والمراقبة في MLflow، والتقييم عند إعدادات الخدمة. كما نشارك أخطاء تصميم المكافأة وإخفاقات التدريب التي واجهناها. تبقى مجموعات بياناتك ووكيلك ونموذجك المدرَّب في حسابك على AWS و لا تُستخدم لتدريب النماذج الأساسية. جميع الأكواد موجودة في مستودع aws-samples المرفق.
نظرة عامة على الحل
يتكون النظام من نصفين. تتولى SageMaker AI مهمة التدريب ونموذج السياسة. ويستضيف AgentCore الوكيل وبيئة Wordle ودالة المكافأة. يوضح المخطط التالي كيفية ترابطها.
الشكل 1: MTRL على SageMaker AI، حيث تستدعي مهمة التدريب الوكيل المستضاف على AgentCore مرة واحدة لكل rollout لأخذ عينات من نموذج السياسة، ولعب اللعبة، والإبلاغ عن مكافأة
في كل rollout، تستدعي خدمة MTRL بيئة تشغيل AgentCore، وهي إمكانية من إمكانات Amazon Bedrock AgentCore، بصف تدريب واحد يحتوي على كلمة سرية واحدة. يستدعي وكيل Strands في بيئة التشغيل نموذج السياسة عبر نقطة النهاية المتوافقة مع OpenAI الخاصة بـ SageMaker Job Runtime. يلعب النموذج حتى ستة تخمينات عبر أداة واحدة، guess_word, وبعد كل تخمين تعيد البيئة ملاحظات لكل حرف وملخصًا لما هو معروف. عندما تنتهي اللعبة، يعيد الوكيل مكافأة واحدة. تحسين السياسة النسبي الجماعي (GRPO) يستخدم توزيع المكافآت عبر عدة rollouts لنفس الكلمة لتحديث محوّل التكيف منخفض الرتبة (LoRA) على نموذج السياسة.
ثلاث نقاط تصميمية مهمة لما يلي:
- الوكيل والمكافأة في مكان واحد. ملف Python واحد منشور على AgentCore يحتوي على البيئة والأداة ودالة التقييم.
- تحمل مجموعة البيانات الكلمة السرية فقط. قوائم الكلمات المرفقة بالوكيل مبنية من قوائم كلمات SCOWL مفتوحة المصدر وتُستخدم للتقييم فقط.
- المكافأة مهيمنة على النتيجة. الحل يمنح 1.05–1.55 حسب السرعة، والخسارة تمنح -0.5، وعدم تقديم أي تخمين صحيح يمنح -1.5. ويكافئ حد تشكيل (shaping) صغير الاستراتيجية الجيدة داخل كل مستوى.
النماذج المدعومة ومناطق AWS
MTRL خدمة بلا خوادم: تختار نموذجًا أساسيًا وتقوم الخدمة بتوفير بنية التدريب وأخذ العينات. في وقت كتابة هذا التقرير، يدعم النماذج الأساسية التالية، ويُدرَّب كل منها باستخدام مهايئ LoRA:
| النموذج الأساسي | مناطق AWS |
| أمازون نوفا 2 لايت | شرق الولايات المتحدة (شمال فيرجينيا) (us-east-1)، غرب الولايات المتحدة (أوريغون) (us-west-2) |
GPT-OSS-20B |
شرق الولايات المتحدة (شمال فرجينيا) (us-east-1)، غرب الولايات المتحدة (أوريغون) (us-west-2) |
| Gemma 4 31B (مضبوط بالتعليمات) | غرب الولايات المتحدة (أوريغون) (us-west-2) |
| Qwen 3.6 27B | منطقة غرب الولايات المتحدة (أوريغون) (us-west-2) |
لقد اخترنا GPT-OSS-20B لأنه يتمتع بأقل سعر لكل رمز بين النماذج الأربعة ويمكن التحكم في مستوى جهده الاستدلالي لكل طلب. راجع وثائق MTRL للاطلاع على القائمة الحالية.
الأسعار
لا تختار مثيلات ولا تحجّم عنقودًا. أنت تدفع لكل مليون رمز في ثلاثة أبعاد، وتحدد الأسعار وفقًا للنموذج الأساسي:
- Prefill: رموز الإدخال التي يعالجها نموذج السياسة. وتتراكم هذه في مهمة متعددة الأدوار، لأن كل دور يعيد قراءة السجل.
- Sample: الرموز التي يولّدها نموذج السياسة، بما في ذلك رموز الاستدلال.
- Train: الرموز التي تُعالج في التمريرة الخلفية التي تُحدّث محوّل LoRA.
استهلكت عملية التشغيل المكونة من 100 خطوة 491.6 مليون رمز prefill، و159.7 مليون رمز sample، و643.3 مليون رمز train عبر 105,486 تجربة (rollout) في 12 ساعة و40 دقيقة. وبحسب GPT-OSS-20B الأسعار المعلنة في منطقة شرق الولايات المتحدة (شمال فرجينيا) (us-east-1) وقت كتابة هذا المقال، فإن ذلك يعادل حوالي $339:
| البُعد | الرموز | السعر لكل 1M | التكلفة |
| Prefill | 491,616,806 | $0.12 | $58.99 |
| Sample | 159,737,098 | $0.30 | $47.92 |
| Train | 643,308,554 | $0.36 | $231.59 |
| الإجمالي | 1,294,662,458 | $338.50 |
يستحوذ بُعد train على الحصة الأكبر ويتدرج مع طول مسار التنفيذ، لذا فإن الألعاب الأقصر والاستدلال الأقل إسهابًا يخفضان الفاتورة. ويُفوتر وقت تشغيل AgentCore بشكل منفصل مقابل vCPU والذاكرة التي يستخدمها الوكيل. وفي هذه العملية، بلغ ذلك حوالي $79، وفقًا لمقاييس استخدام Amazon CloudWatch لوقت التشغيل بأسعار us-east-1 المعلنة. DescribeJob يُبلغ عن أعداد الرموز ضمن BillableTokenUsage. راجع أسعار Amazon SageMaker AI للاطلاع على الأسعار الحالية.
المتطلبات الأساسية
لمتابعة هذا الدليل التطبيقي، تحتاج إلى ما يلي. راجع أيضًا متطلبات MTRL الأساسية.
- Python 3.10 أو أحدث، وuv، وNode 20 أو أحدث، وواجهة سطر الأوامر AgentCore (
npm install -g @aws/agentcore). راجع ابدأ استخدام Amazon Bedrock AgentCore للتثبيت ولأذونات IAM التي يحتاجها واجهة سطر الأوامر (CLI). - botocore 1.43.37 أو أحدث، على الجهاز الذي يطلق المهمة. هذه هي النسخة الأولى التي تتضمن
AgentRFTCreateJoboperation. - دوران AWS Identity and Access Management (IAM)، موصوفَين في الخطوة 1.
- حاوية Amazon Simple Storage Service (Amazon S3) في نفس المنطقة التي يعمل بها الوكيل. يجب أن تعمل مهمة التدريب أيضًا في تلك المنطقة، لأن
CreateJobيرفض ARN وقت التشغيل عبر المناطق.
الخطوة 1: إنشاء أدوار IAM
يستخدم MTRL دورين، وأحدهما لديه سياسة ثقة لا تذكرها وثائق SageMaker AI العامة.
دور وقت تشغيل الوكيل (Agent runtime role). agentcore deploy ينشئ هذا الدور نيابةً عنك. يثق في bedrock-agentcore.amazonaws.com ويحتاج إلى AmazonSageMakerJobRuntimeAccess سياسة مُدارة، والتي تتيح للوكيل استدعاء نموذج السياسة والإبلاغ عن المكافآت. يقوم حزمة CDK في مستودع العينة بإرفاق هذه السياسة تلقائيًا.
دور مهمة التدريب (Training job role). أنت تنشئ هذا الدور. يجب أن يثق في job.sagemaker.amazonaws.com بكل من sts:AssumeRole و sts:TagSession، ويحتاج إلى AmazonSageMakerJobFullAccess السياسة المُدارة.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "job.sagemaker.amazonaws.com"},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}]
}
ملاحظة: كيان الثقة هو job.sagemaker.amazonaws.com، وليس sagemaker.amazonaws.com. مع الكيان العام، CreateJob يفشل مع الرسالة "Could not assume role"، وتذكر الرسالة الكيان الصحيح فقط بعد إعادة المحاولة.
الخطوة 2: نشر الوكيل إلى Amazon Bedrock AgentCore
استنسخ مستودع العينة، وحدد حسابك ومنطقتك في Wordle/agentcore/aws-targets.json، ثم انشر:
git clone https://github.com/aws-samples/sample-multi-turn-rl-wordle
cd sample-multi-turn-rl-wordle/Wordle
agentcore validate
agentcore deploy
تبني واجهة سطر الأوامر تبعيات الوكيل لمنصة Linux ARM64 الخاصة بوقت التشغيل، وتنشئ دور التنفيذ مع AmazonSageMakerJobRuntimeAccess مرفقًا، وتنشر عبر AWS CloudFormation. نوصي بها بدلاً من تحميل حزمة التعليمات البرمجية عبر وحدة التحكم، حيث من الشائع ارتكاب أخطاء في حوالي 700 MB من التبعيات المجمعة أو في إرفاق السياسة. دوّن ARN وقت التشغيل من المخرجات لمهمة التدريب.
الشكل 2: وقت تشغيل وكيل Wordle في وحدة تحكم Amazon Bedrock AgentCore بحالة Ready
تقرأ بيئة التشغيل متغيري بيئة من agentcore.json. REASONING_EFFORT=low تضبط reasoning_effort على كل طلب إلى نموذج السياسة. في مهام التقييم لدينا، استخدم الجهد المنخفض عددًا من رموز العينات لكل لعبة أقل بنسبة 63 إلى 83 بالمئة مقارنة بالمتوسط. REASONING_PROMPT_HINT=true يضيف أيضًا "Reasoning: low" إلى موجه النظام، وهذا هو الطريقة التي يقرأ بها gpt-oss هذا الإعداد في تنسيق المحادثة Harmony الخاص به. ولا يوفر أي من المتغيرين للنموذج أي تلميح حول الكلمة السرية.
الشكل 3: متغيرات بيئة التشغيل تُظهر REASONING_EFFORT مضبوطًا على low
الوكيل ملف واحد، main.py. بصيغته المبسطة، تبدو نقطة دخوله كما يلي. بالنسبة لمهمتك الخاصة، يمكنك تغيير تحليل المهمة والأدوات والمكافأة:
app = BedrockAgentCoreApp()
@app.entrypoint # outermost: starts the HTTP server AgentCore invokes
@sagemaker_rft_handler # reports the returned reward to SageMaker AI
def handle_rollout(payload):
prompt, answer = parse_task(payload["prompt"])
game = WordleGame(answer)
@tool
def guess_word(guess: str) -> str:
"""Submit a 5-letter Wordle guess and get feedback."""
return game.guess(guess)
agent = Agent(model=build_model(), system_prompt=SYSTEM_PROMPT, tools=[guess_word])
agent(prompt)
return {"reward": game.final_reward()}
مهم: الدايكورييتور sagemaker_rft_handler لا يُشغّل خادم HTTP من تلقاء نفسه. لفّه باستخدام BedrockAgentCoreApp و @app.entrypoint، بحيث يكون دايكورييتور نقطة الدخول في الطبقة الخارجية. بدون ذلك، تنتهي مهلة كل استدعاء بعد 30 ثانية.
الخطوة 3: التحقق من بيئة التشغيل
قبل إنفاق وقت GPU، تأكد من أن السلسلة بأكملها تعمل باستخدام حمولة مشابهة لما يرسله خدمة التدريب. يتضمن المستودع واحدًا منها في Wordle/payload.json:
{
"prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"beach\", \"id\": \"smoke-test\"}",
"metadata": {
"jobArn": "arn:aws:sagemaker:us-east-1:111122223333:job/AgentRFT/smoke-test",
"rolloutId": "r1"
}
}
من المتوقع أن يفشل ARN الوظيفة الوهمي، وطريقة فشله هي الدليل. ضع معرّف حسابك الخاص فيه أولًا: بالنسبة إلى ARN وظيفة في حساب آخر، تُعيد الخدمة خطأ 403 قبل أن تتحقق مما إذا كانت الوظيفة موجودة، ويبدو ذلك وكأنه إعداد IAM معطّل. من مجلد Wordle، نفّذ:
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
sed "s/111122223333/$ACCOUNT/" payload.json > /tmp/payload.json
aws bedrock-agentcore invoke-agent-runtime \
--agent-runtime-arn <RUNTIME_ARN> \
--runtime-session-id smoke-test-$(date +%s)000000000000000 \
--payload fileb:///tmp/payload.json /dev/stdout
في سجلات Amazon CloudWatch لبيئة التشغيل، ترى الوكيل يحلّل الموجّه (prompt) ويصادق مع نقطة نهاية Job Runtime ويتلقى خطأ 400 يقول "Could not find job". يؤكد هذا الفشل أن التحليل والمصادقة والإبلاغ عن الأخطاء تعمل. يطبع الأمر نفسه القيمة {“reward”: -1.5}، لأن الوكيل لم يصل أبدًا إلى نموذج السياسة. أما الخطأ 403 الذي يقول "not authorized to access this resource" فهو يعني أن ARN الوظيفة لا يزال يشير إلى حساب آخر. وإذا كانت هناك مهلة مدتها 30 ثانية بدلًا من ذلك، فهذا يعني أن خادم HTTP لا يبدأ التشغيل (انظر الملاحظة المهمة في الخطوة 2).
الخطوة 4: تجهيز مجموعة البيانات
لا تحتوي مجموعة بيانات MTRL على أي استجابات مستهدفة أو سجلات محادثات أو تسميات. كل صف هو مهمة واحدة يحاول الوكيل تنفيذها. إليك الصفوف الثلاثة الأولى من ملف التدريب:
{"prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"riser\", \"id\": \"wordle_train_0000\"}"}
{"prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"swoon\", \"id\": \"wordle_train_0001\"}"}
{"prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"dirty\", \"id\": \"wordle_train_0002\"}"}
تقرأ الخدمة عمود prompt (أو العمود الأول) وتمرّر السلسلة إلى وكيلك كما هي، دون تحليلها. جعلنا السلسلة كائن JSON صغيرًا يتكوّن من ثلاثة حقول:
- prompt: الموجّه (instruction) الذي يعرضه الوكيل على نموذج السياسة، وهو مطابق في كل صف.
- answer: الكلمة السرية. تستخدمها بيئة التشغيل ودالة المكافأة فقط، ولا يراها نموذج السياسة أبدًا.
- id: معرّف الصف لتتبّع تنفيذ (rollout) في السجلات وصولًا إلى الصف المصدر.
يختار ملف make_dataset.py في المستودع النموذجي 640 كلمة تدريب (خمس دفعات كاملة من 128) و128 كلمة تحقق من قائمة الإجابات دون أي تداخل، بحيث يقيس معدل الحل في مجموعة التحقق قدرة التعميم. تقبل الخدمة أيضًا صيغ Apache Parquet ومصفوفات JSON وملفات CSV. ارفع كلا الملفين إلى Amazon S3:
uv run python make_dataset.py
aws s3 cp training-data.jsonl s3://<YOUR_BUCKET>/wordle-mtrl/train/
aws s3 cp validation-data.jsonl s3://<YOUR_BUCKET>/wordle-mtrl/validation/
بما أن الخدمة لا تفحص سلسلة prompt أبدًا، يمكن لمهمة إنتاجية أن تضمّن فيها قائمة رسائل كاملة أو إعدادات أدوات أو مواصفات مكافأة. راجع وثائق MTRL للاطلاع على أمثلة، بما في ذلك كيفية حماية المحتوى الحساس داخل السلسلة.
الخطوة 5: إطلاق مهمة التدريب
يستخدم المشغّل الصنف MultiTurnRLTrainer من حزمة sagemaker-train SDK. وجّهه إلى ARN بيئة التشغيل من الخطوة 2، والدور (role) من الخطوة 1، ومجموعات البيانات من الخطوة 4، وتطبيق MLflow لجمع المقاييس. تطبيق MLflow مطلوب، لذا إذا لم يكن لديك واحد، أنشئه أولًا باستخدام aws sagemaker create-mlflow-app:
uv run python run_mtrl_training.py \
--model openai-reasoning-gpt-oss-20b \
--agent-runtime-arn <RUNTIME_ARN> \
--role-arn arn:aws:iam::<ACCOUNT>:role/<JOB_ROLE> \
--train-dataset s3://<YOUR_BUCKET>/wordle-mtrl/train/training-data.jsonl \
--val-dataset s3://<YOUR_BUCKET>/wordle-mtrl/validation/validation-data.jsonl \
--s3-output-path s3://<YOUR_BUCKET>/wordle-mtrl/output/ \
--mlflow-app-arn arn:aws:sagemaker:<REGION>:<ACCOUNT>:mlflow-app/<APP_ID>
يتجاوز المُشغِّل ثلاثة معاملات فائقة ويترك كل معامل آخر على القيمة الافتراضية لـ gpt-oss-20b. فهو يضبط sampling_max_tokens على 8192، وهي الحد الأقصى للخدمة، لأنه عند القيمة الافتراضية 4096 كثيرًا ما نفدت الرموز لدى gpt-oss أثناء الاستدلال، قبل أول استدعاء للأداة. كما يضبط max_epochs على 20 و max_steps على 100: فـ 640 صفًا عند القيمة الافتراضية global_batch_size البالغة 128 يعطي 5 خطوات لكل حقبة، ومع القيمة الافتراضية group_size البالغة 8، تلعب كل خطوة 1,024 لعبة. تمر المهمة بمراحل Starting وDownloading وPending قبل الوصول إلى Training. بعد بدء التدريب، يبدأ بيئة تشغيل AgentCore لديك في استقبال استدعاءات التشغيل التجريبي.
مهم: لا تعيد نشر الوكيل أثناء تشغيل مهمة. إعادة النشر تعيد تشغيل بيئة التشغيل، ولن ترى عمليات التشغيل الجارية أي طلبات معاينة، وترفض الخدمة المهمة بأكملها.
الخطوة 6: مراقبة التدريب في MLflow
تسجل الخدمة إحصاءات المكافأة والرموز والأدوار في كل خطوة وتجري التحقق كل val_every خطوة. المقياس الذي يجب مراقبته هو val/reward/pass_at_1، أي نسبة الكلمات المحجوزة التي تم حلها. تحصل كل كلمة محلولة على درجة لا تقل عن 1.01، وبالتالي تتجاوز success_threshold الخاص بالخدمة البالغ 1.0 ويحتسبها pass@1. الرسم البياني التالي مبني من سجل MLflow لهذا التشغيل:
الشكل 4: منحنيات التدريب لتشغيل الـ 100 خطوة، بمتوسط المكافأة لكل لعبة على اليسار ومعدل الحل في التحقق على اليمين
ترتفع مكافأة التدريب إلى حوالي +0.57 خلال 15 خطوة وتبقى عند ذلك المستوى. تبقى مكافأة التحقق أدنى، ويعود ذلك في الغالب إلى درجة الحرارة 1.0 مقابل 0 وليس إلى فرط التخصيص (انظر الخطوة 7). يقفز معدل الحل في التحقق من 2 إلى 31 بالمئة في أول 10 خطوات، ثم يتراوح بين 35 و48 بالمئة. مع 128 كلمة، فإن هذه التقلبات هي في معظمها ضوضاء. لم نختبر ما إذا كانت الخطوات الإضافية تساعد عند إعدادات التقديم.
تسجل تتبعات OpenTelemetry لبيئة التشغيل في CloudWatch كل دور للنموذج وكل استدعاء أداة. إليك لعبة لعبها النموذج المدرَّب أثناء مهمة تقييم (جهد متوسط، درجة حرارة 1.0)، مع اختصار الاستدلال. كانت الكلمة السرية PASTE:
[model] Reasoning: [...] "CRANE" has 5 distinct letters: C,R,A,N,E. [...]
We'll guess "CRANE".
Tool call: guess_word(guess="CRANE")
[tool] Guess 1/6: CRANE -> C=gray, R=gray, A=yellow, N=gray, E=green
Current Knowledge:
- Correct Position (Green): _ _ _ _ E
- In Word, Wrong Position (Yellow): 'A' (at least 1)
- Not in Word (Gray): C, N, R
- Guesses Remaining: 5
[model] Reasoning: [...] "ALIVE": ends with E, includes A. Letters not C,N,R.
Tool call: guess_word(guess="ALIVE")
[tool] Guess 2/6: ALIVE -> A=yellow, L=gray, I=gray, V=gray, E=green
[model] Reasoning: [...] So positions not 1 or 3 for A. Positions left: 2,4
for A. [...] We might guess "HASTE"? [...]
Tool call: guess_word(guess="HASTE")
[tool] Guess 3/6: HASTE -> H=gray, A=green, S=green, T=green, E=green
[model] Reasoning: We have the word: _ASTE. [...] "PASTE" is a word. PASTE
fits. Also "WASTE" also fits [...] Choose "PASTE" maybe.
Tool call: guess_word(guess="PASTE")
[tool] Guess 4/6: PASTE --- all green. Correct, you solved it!
عملية تشغيل للنموذج المدرَّب من تتبعات بيئة تشغيل AgentCore. يحافظ النموذج على الحروف الخضراء في مواضعها، ولا يعيد أبدًا استخدام حرف رمادي، ويستخدم كل حرف أصفر لاستبعاد المواضع، رغم أن شيئًا في بيانات التدريب لم يريه كيف يفعل ذلك.
الخطوة 7: تقييم النموذج المدرَّب عند إعدادات التقديم
عند اكتمال المهمة، تعرض صفحتها في SageMaker AI Studio الحالة ومجموعة حزم النماذج (model package group) التي تحتوي على النموذج المدرَّب. DescribeJob، مع JobCategory مضبوطًا على AgentRFTتُعيد اسم ARN لحزمة النموذج الناتجة وأعداد الرموز القابلة للفوترة.
الشكل 5: مهمة التدريب المكتملة في SageMaker AI Studio في علامة التبويب Jobs، ثم Training، ثم Multi-turn RL
وظيفة تقييم (JobCategory مضبوطة على AgentRFTEvaluation) تشغّل مطالبات التقييم الخاصة بك عبر نفس بيئة تشغيل AgentCore ونظام المكافأة نفسه، على النموذج الأساسي أو الحزمة المدرَّبة، ويسجّل eval/reward/pass_at_1 في MLflow. وعلى عكس التحقق أثناء التدريب، يمكنك ضبط درجة الحرارة (temperature). يقوم مشغّل المستودع بتشغيل التقييمات بالتتابع، لأن الحصة الافتراضية تسمح بمهمة تقييم واحدة فقط في كل مرة (يمكنك طلب زيادة للحصة):
uv run python run_mtrl_eval.py --runs base:1.0 trained:1.0 \
--model-package-arn <OUTPUT_MODEL_PACKAGE_ARN> \
--agent-runtime-arn <RUNTIME_ARN> \
--role-arn arn:aws:iam::<ACCOUNT>:role/<JOB_ROLE> \
--dataset s3://<YOUR_BUCKET>/wordle-mtrl/validation/validation-data.jsonl \
--s3-output-path s3://<YOUR_BUCKET>/wordle-mtrl/eval/ \
--mlflow-app-arn arn:aws:sagemaker:<REGION>:<ACCOUNT>:mlflow-app/<APP_ID>
الشكل 6: جهد الاستدلال ودرجة حرارة أخذ العينات في كل مرحلة، حيث تثبّت مهمة التدريب التحقق عند درجة حرارة 0 والجهد عند القيمة المنشورة، بينما تتيح لك مهام التقييم الاختيار
استغرقت كل عملية تقييم من 128 كلمة أربع إلى سبع دقائق. يأتي جهد الاستدلال من متغيرات بيئة الوكيل، لذا لتغييره تقوم بتعديل REASONING_EFFORT، وإعادة النشر، ثم التقييم. قيّمنا كلا النموذجين عند الجهد المنخفض والمتوسط وعند درجة حرارة 0 و1.0:
الشكل 7: النموذج الأساسي مقابل النموذج المدرَّب تحت أربع إعدادات فك ترميز، مع معدل الحل على اليسار ومتوسط المكافأة لكل لعبة على اليمين
المقطع الرمادي في كل شريط هو النموذج الأساسي، والمقطع الأزرق هو الزيادة الناتجة عن التدريب. زوج الجهد المنخفض ودرجة الحرارة 0 هو التحقق الخاص بمهمة التدريب عند الخطوتين 0 و100. نتيجة النموذج المدرَّب عند الجهد المتوسط ودرجة الحرارة 1.0 هي متوسط جولتين (80 و88 بالمئة).
عند درجة الحرارة 0، غالبًا ما ينتهي كلا النموذجين اللعبة دون حل، عند أي من مستويي الجهد. ومع تمكين أخذ العينات، أضاف الجهد المتوسط 15 نقطة للنموذج المدرَّب و46 للنموذج الأساسي. أضاف المحوّل (adapter) ما بين 14 و54 نقطة في كل إعداد، وبالتالي فإن ما تعلّمه التدريب ينتقل عبر الإعدادات.
قالت منحنى التحقق الخاص بمهمة التدريب نفسها في MLflow قصة مختلفة: بلغ الذروة عند 48 بالمئة في الخطوة 90 وانتهى عند 37 بالمئة، مع تقييم عند درجة حرارة 0. توصي مرجع المَعلمات الفائقة باستخدام درجة حرارة 0 للتقييم لأن فك الترميز الجشع يجعل المنحنيات حتمية وقابلة للمقارنة عبر الجولات. نحن نُبلغ عن درجة الحرارة 1.0 لأن هذا هو الطريقة التي نخدم بها النموذج. عند الجهد المتوسط ودرجة الحرارة 1.0، يحل النموذج المدرَّب 84 بالمئة من الكلمات المحجوزة، بزيادة عن 61 بالمئة للنموذج الأساسي.
نصيحة: قيّم عند الإعدادات التي ستفترض بها النموذج. يقول منحنى التدريب إن هذا المحوّل ينتهي عند 37 بالمئة. عند إعدادات الخدمة فإنه يحل 84 بالمئة. مهام التقييم التي تُظهر ذلك كلفت حوالي 1.20 دولار من الرموز واستغرقت حوالي ساعة.
الخطوة 8: التنظيف
تتوقف مهام التدريب والتقييم عن تحصيل الرسوم عند اكتمالها، لكن بيئة تشغيل AgentCore ودور IAM الخاص بها وتطبيق MLflow وكائنات S3 تبقى قائمة. من مجلد المشروع:
# 1. Agent runtime and its execution role. remove all resets the project config;
# the next deploy sees the empty state and tears down the deployed resources.
cd sample-multi-turn-rl-wordle/Wordle
agentcore remove all
agentcore deploy
# 2. MLflow app
aws sagemaker delete-mlflow-app --arn arn:aws:sagemaker:<REGION>:<ACCOUNT>:mlflow-app/<APP_ID>
# 3. Datasets, job output, and evaluation output
aws s3 rm s3://<YOUR_BUCKET>/wordle-mtrl/ --recursive
لأن agentcore remove all يعيد كتابة الملفات تحت agentcore/، نفّذ git checkout -- agentcore/ إذا كنت تريد إعادة النشر لاحقًا. يؤدي حذف حزمة AgentCore-Wordle-default CloudFormation إلى إزالة نفس الموارد ويترك الملفات كما هي. لا تُحتسب رسوم على دور مهمة التدريب ولا على حزم النماذج.
تعمق: تصميم المكافأة
احتاجت مكافأتنا إلى تعديل واحد، والخطأ الذي ارتكبناه شائع.
جمع التصميم الأول نقاط التخمين الواحد من wordle-lora-rl على مدار اللعبة كاملة. تعمل هذه الطريقة في التقييم هناك لأن كل تخمين هو عينة تدريب مستقلة. أما عند جمعها في مكافأة واحدة لكل لعبة، فقد أنتجت انعكاسين اكتشفناهما فقط بقراءة المسارات:
- اللعبة الخاسرة كانت تمنح مكافأة موجبة. ست جولات من المكافآت بلغ مجموعها حوالي +0.49.
- الحل في الجولة 1 كان يسجل أقل من الحل في الجولة 3. الحل من التخمين الأول كان يمنح +0.99 والحل من التخمين الثالث كان يمنح +1.61، لأن الجولات الإضافية جمعت مكافآت أكثر.
يفصل الإصلاح مكوّن النتيجة المهيمن عن مكوّن تشكيل صغير ومحدود:
reward = outcome + w * clip(shaping, -1, 1), w = 0.04 if solved, else 0.15
يُحدَّد مكوّن النتيجة بالكامل من طريقة انتهاء اللعبة:
| النتيجة | القيمة |
| تم الحل في التخمين n | 1.05 + 0.5 * (6 – n) / 5، أي 1.55 في التخمين 1 نزولًا إلى 1.05 في التخمين 6 |
| لُعبت الجولات الست جميعها دون حل | -0.5 |
| لم يُجرَ أي تخمين صالح | -1.5 |
مكوّن التشكيل هو ذلك التقييم لكل تخمين، مجموعًا على اللعبة:
- عقوبات على مخالفة حرف أخضر أو أصفر أو رمادي معروف، وعلى تكرار تخمين، وعلى كلمات خارج القاموس.
- مكافأة إنتروبيا لكلمة افتتاحية قوية.
- مكافآت على تجربة أحرف جديدة وعلى تقليص مجموعة الاحتمالات المتبقية.
يُقتطع المجموع إلى [-1, 1] ويُضرب في 0.04 في حالة الحل و0.15 في حالة الخسارة، بحيث يفرّق بين الألعاب ذات النتيجة نفسها لكنه لا ينقل لعبة أبدًا إلى فئة أخرى. وبقيم تشكيل نموذجية:
| السيناريو | المكافأة |
| الحل عند المحاولة 1 | +1.550 |
| الحل عند المحاولة 3 | +1.375 |
| الحل عند المحاولة 6 | +1.069 |
| الخسارة بعد ست محاولات | -0.427 |
| لم تُقدَّم أي محاولة صالحة | -1.500 |
الحل الأسرع يتفوق الآن دائمًا على الأبطأ، وكل حل يتفوق على كل خسارة، وعدم اللعب إطلاقًا هو أسوأ النتائج. كان إصلاحنا الأول يستخدم وزنًا واحدًا قدره 0.15، مما سمح لحل عند المحاولة 3 مع التشكيل الكامل (+1.45) بأن يتفوق على حل عند المحاولة 2 مع الحد الأدنى (+1.25). وبما أن أعداد المحاولات المتجاورة تفصلها مسافة 0.1، فإن وزن حل أصغر قدره 0.04 يزيل هذا التداخل، ولا يزال أسوأ حل (+1.01) يتجاوز عتبة النجاح 1.0. ويبقى التشكيل مهمًا لأن GRPO يتعلم من تباين المكافآت داخل المجموعة، فلعبتان خاسرتان تختلفان في اتساق التلميحات لا يزالان تعلّمان النموذج شيئًا ما. وكما تنصح وثائق SageMaker AI، ابدأ بمكافأة قائمة على النتيجة، وأضف التشكيل باعتدال، وتحقق من المكافأة على مسارات حقيقية.
تعمّق: ما الذي حدث خطأً، وبالترتيب الذي ستواجهه به
كل واحدة من هذه نقّلت تكلفة تشغيل تدريبي واحد على الأقل.
- رموز الحامل (Bearer) تحت التزامن. كان إصدار رمز بجلسة botocore جديدة لكل استدعاء يُجَوّع مزوّد بيانات الاعتماد عند 32 عملية rollout متزامنة، وكان تخزين الرموز مؤقتًا لمدة ساعة يُرجع أخطاء 403 مع تدوير بيانات الاعتماد. الحل هو جلسة واحدة تُحدِّث نفسها ذاتيًا، وذاكرة مؤقتة قصيرة، وإعادة توقيع عند حدوث 403.
- عملية rollout لا تصل أبدًا إلى نموذج السياسة تُفشل المهمة كلها. عندما فشلت جميع استدعاءات النموذج في عملية rollout في المصادقة، أنهت الخدمة المهمة برسالة "لم يتم استلام أي طلبات أخذ عينات." كما أن إرجاع حالة خطأ يُفشلها أيضًا، لذا أرجِع مكافأة دائمًا. اللعبة التي يُؤخذ منها عينة من النموذج لكنه لا يُقدم محاولة صالحة أمر مقبول: فهي تحصل على -1.5، وكانت هناك 51 لعبة من هذا النوع في التشغيل المكون من 100 خطوة من أصل نحو 105,000 عملية rollout.
- استدعاءات الأدوات تنحرف إلى نص عادي. عند معدل تعلم مرتفع جدًا، كان النموذج يكتب استدعاءات الأدوات كنص، وكانت كل عملية rollout تحصل على نفس المكافأة الدنيا، فيتلاشى التدرج. يستعيد الوكيل الآن المحاولات من النص الخام مع عقوبة تنسيق بسيطة.
- الثبات (Plateau). توقفت مكافأة التدريب عن الارتفاع بعد نحو الخطوة 15، وتوقفت التحقق عن التحسن بعد نحو الخطوة 30، رغم أن التحقق عند درجة الحرارة 0 يقلل من تقدير النموذج (الخطوة 7). منهج تدريجي يزرع الألعاب بمحاولات سابقة، أو عدد عمليات rollout لكل كلمة أكبر من القيمة الافتراضية
group_sizeالبالغة 8، هو ما سنحاول تجربته تاليًا.
الخلاصة
يُدرّب MTRL على SageMaker AI نموذجًا على نتيجة حلقة كاملة. وهذا يناسب المهام الوكيلة، حيث يكون المسار الصحيح مجهولًا ولا يمكن تقييم سوى النتيجة. استخدمنا مكافأة واحدة على مستوى الحلقة. وعندما يمكن أيضًا تقييم الخطوات الوسيطة، يقبل MTRL مكافأة لكل دور عبر واجهة UpdateReward API. في هذا المنشور، وصل نموذج مفتوح الأوزان بحجم 20B إلى معدل حل يبلغ 84 في المئة عند إعدادات الخدمة، بزيادة من 61 في المئة، مقابل نحو $339 من رموز التدريب ونحو $79 من استخدام بيئة تشغيل AgentCore. أما نسبة الـ 37 في المئة التي يذكرها منحنى التدريب فهي أثر جانبي لطريقة تقييم مهمة التدريب للتحقق، لذا قيّم عند الإعدادات التي ستخدم بها.
ينطبق المسار نفسه على الإجراءات الداخلية والأدوات وسير العمل التي لم تُدرَّب عليها النماذج العامة.
للبدء، استنسخ مستودع العينة، واتبع الخطوات السابقة، وشغّل اختبار الدخان في الخطوة 3 قبل الالتزام بوقت GPU. أما بالنسبة للواجهات البرمجية الأساسية، فراجع وثائق SageMaker AI MTRL.