ปลดล็อกการฝึก Agentic RL สำหรับ GPT-OSS: บทเรียนจากการใช้งานจริง

ปลดล็อกการฝึก Agentic RL สำหรับ GPT-OSS: บทเรียนจากการใช้งานจริงในโลกของปัญญาประดิษฐ์ที่ก้าวหน้าอย่างรวดเร็ว โมเดลภาษาขนาดใหญ่ (LLM) ไม่ได้เป็นเพียงเครื่องมือสร้างข้อความอีกต่อไป แต่กำลังพัฒนาไปสู่การเป็น "เอเจนต์" ที่สามารถโต้ตอบกับโลกภายนอกได้ โดยเฉพาะอย่างยิ่งในแพลตฟอร์มอย่าง LinkedIn ที่ให้ความสำคัญกับ AI ในการช่วยให้มืออาชีพประสบความสำเร็จ โมเดลเหล่านี้จำเป็นต้องมีความสามารถในการประมวลผลข้อมูลที่ไม่สมบูรณ์ โต้ตอบกับบริการที่มีโครงสร้าง และปรับตัวให้เข้ากับความตั้งใจของผู้ใช้ที่เปลี่ยนแปลงไปตลอดหลายขั้นตอน แทนที่จะให้คำตอบแบบครั้งเดียวจบความสามารถเหล่านี้มีความสำคัญอย่างยิ่งสำหรับเอเจนต์ที่สนับสนุนเป้าหมายของฝ่ายบุคคล (Recruiters), ผู้ที่กำลังมองหางานและองค์ความรู้, รวมถึงผู้เรียน โดยเอเจนต์เหล่านี้อาจต้องดึงข้อมูล, ปรับปรุงคำค้นหา, ประสานงานกับเครื่องมือต่างๆ, และดำเนินงานตามขั้นตอนที่ซับซ้อน การเรียนรู้นโยบายการตัดสินใจที่แข็งแกร่งผ่านการโต้ตอบ คือหัวใจสำคัญของ Agentic Reinforcement Learning (RL) ซึ่งเป็นรากฐานที่มั่นคงสำหรับการสร้างระบบ AI ที่ปรับขนาดได้, เชื่อถือได้, และปรับตัวได้ ผ่านการปรับปรุงแบบ End-to-Endโมเดล GPT-OSS ได้แสดงให้เห็นถึงประสิทธิภาพที่เทียบเคียงได้กับ OpenAI o3-mini และ o4-mini แต่ความเหมาะสมสำหรับการฝึก Agentic RL ยังไม่ได้รับการพิสูจน์อย่างชัดเจน งานวิจัยล่าสุดส่วนใหญ่มุ่งเน้นไปที่การ Fine-tuning โดยไม่มีการเรียกใช้เครื่องมือ (Tool Calling) เช่น การ Fine-tune GPT-OSS ด้วย Hugging Face Transformers และบทแนะนำ Unsloth บทความนี้จะพาไปสำรวจเส้นทางการปลดล็อกการฝึก Agentic RL สำหรับ GPT-OSS ซึ่งเป็นโมเดลที่มีศักยภาพในการเป็นแกนหลักสำหรับแอปพลิเคชันแบบเอเจนต์ความท้าทายในการฝึก GPT-OSS ด้วย Reinforcement Learningในการทดลองของเรา เราใช้ verl เป็นเฟรมเวิร์กการฝึก ซึ่งเป็นหนึ่งในเฟรมเวิร์กที่ได้รับความนิยมสูงสุดในชุมชนโอเพนซอร์ส เราใช้ชุดข้อมูลที่นิยมใช้ในการฝึก RL เช่น gsm8k, Retool task, และ verifiable instruction following task โดยเราจะนำเสนอผลการทดลองสำหรับโมเดล GPT-OSS-20B และการแก้ไขปัญหา attention-sink fix ของเราก็สามารถใช้ได้กับ GPT-OSS-120B ด้วย นอกจากนี้ เรายังใช้โมเดล Qwen-2.5-32B เพื่อเปรียบเทียบแนวโน้มเมตริกมาตรฐานในระหว่างการฝึก RLการรับมือกับ Template การสนทนาใหม่: Harmony Chat Templateverl เป็นเฟรมเวิร์กโอเพนซอร์สที่ทีมงานเคยใช้งานและมีส่วนร่วมในการพัฒนาเพื่อส่งเสริมการฝึก Agentic RL ให้เข้าถึงได้ง่ายขึ้น เมื่อ GPT-OSS เปิดตัว Harmony Chat Template ใหม่ ขั้นตอนแรกที่สำคัญคือการตรวจสอบให้แน่ใจว่าเฟรมเวิร์กการฝึกรองรับรูปแบบข้อความและการสนทนาที่อัปเดตตามที่ Harmony กำหนดได้อย่างสมบูรณ์ ขั้นตอนนี้มีความสำคัญเพื่อให้การสร้าง Rollout, การสร้าง Trajectory, และการแยกวิเคราะห์เครื่องมือ (Tool Parsing) ยังคงมีความสอดคล้องและถูกต้องภายใต้ Template ใหม่การตรวจสอบความถูกต้องของโค้ดด้วย ReToolทีมงานใช้ ReTool เป็นตัวอย่างในการยืนยันความถูกต้องของโค้ด ReTool เป็นงาน Coding แบบเอเจนต์ที่โมเดลจะต้องแก้ปัญหาคณิตศาสตร์โดยได้รับความช่วยเหลือจากเครื่องมือ Code Compiler การตั้งค่านี้ช่วยให้โมเดลสามารถมุ่งเน้นไปที่การให้เหตุผลหลักและตรรกะของอัลกอริทึม ในขณะที่มอบหมายการคำนวณและการดำเนินการจริงให้กับเครื่องมือ ในระหว่าง Episode หนึ่ง โมเดลจะโต้ตอบกับเครื่องมือ Code หลายครั้ง โดยใช้ผลลัพธ์จากการดำเนินการเพื่อปรับปรุงโซลูชัน ในตอนท้ายของ Trajectory โมเดลจะส่งคำตอบสุดท้าย ซึ่งจะนำไปคำนวณ Rewardปัญหาที่พบ: Gradient Exploding และ Reward ไม่เพิ่มขึ้นระหว่างการฝึกช่วงแรก เราสังเกตเห็นปัญหา KL Divergence และ Entropy ที่พุ่งสูงขึ้น ควบคู่ไปกับ Reward ที่ไม่เพิ่มขึ้น ซึ่งบ่งชี้ถึงปัญหาพื้นฐานในการตั้งค่าการฝึก GPT-OSS ดังที่แสดงในภาพที่ 1การเดินทางเพื่อแก้ไขปัญหา (Debugging) ใน verl: การกู้คืนความสมบูรณ์ของ PPO On-Policyการกู้คืนความสมบูรณ์ของ PPO On-Policy: การแก้ไขปัญหา Log-Probability Mismatch ใน MoEเราให้ความสำคัญกับวิธีการแบบ On-policy เนื่องจากให้ความเสถียรที่มากกว่าและการลู่เข้าที่เชื่อถือได้ หลักการพื้นฐานของ Proximal Policy Optimization (PPO) แบบ On-policy คืออัตราส่วน Importance Sampling จะต้องเท่ากับ 1 เสมอสูตรทางคณิตศาสตร์ของ Importance Ratio คือ:$$ \text{ratio} = \frac{\pi(a \mid s)}{\pi{\text{old}}(a \mid s)} $$ข้อกำหนดนี้ทำให้มั่นใจได้ว่าการอัปเดตนโยบายจะดำเนินการเฉพาะกับข้อมูลที่สร้างขึ้นโดยนโยบายปัจจุบัน ($\pi(a \mid s) = \pi{\text{old}}(a \mid s)$) เพื่อป้องกันการ Clipping ที่ไม่ตั้งใจเราพบว่ามีค่า Clipping ที่ไม่เป็นศูนย์ในการฝึก ReTool ดังที่แสดงในภาพที่ 2 ซึ่งเกิดจากความไม่ตรงกันระหว่าง Log-probabilities สองค่า:Current log-probability: log_prob: log(π(a | s))Old log-probability: oldlogprob: log(πold(a | s))สาเหตุหลัก: Dual Forward Pass และสถาปัตยกรรม MoEก่อนเวอร์ชัน verl 0.3.0 การใช้งานอาศัยการ Forward Pass สองครั้งแยกกัน (ครั้งหนึ่งเพื่อคำนวณ current logprob และอีกครั้งเพื่อดึง stored oldlog_prob) สำหรับคู่ State-Action เดียวกันในสถาปัตยกรรม Mixture of Experts (MoE) เช่น GPT-OSS เครือข่าย Gating จะทำหน้าที่ส่งต่อ Input ไปยัง Expert ที่แตกต่างกัน เนื่องจากปัจจัยด้านการใช้งาน (เช่น ความแตกต่างเล็กน้อยของ Floating-point หรือ Stochasticity ที่ชัดเจน) การกำหนดเส้นทาง (Routing) ของ Expert อาจแตกต่างกันเล็กน้อยระหว่างสอง Pass นี้ สำหรับผู้อ่านที่สนใจสามารถศึกษาเพิ่มเติมได้จาก "Stabilizing MoE Reinforcement Learning by Aligning Training and Inference Routers"ความแตกต่างในการ Routing นี้ส่งผลให้:$$ \log(\pi(a \mid s)) \neq \log(\pi_{\text{old}}(a \mid s)) $$อัตราส่วนที่ได้จะเบี่ยงเบนไปจาก 1 ทำให้ PPO Clip ทำงานผิดพลาด และละเมิดข้อสมมติฐานหลักของ On-policyวิธีแก้ไข: การบังคับ Ratio = 1 ผ่านการแทนที่ Log-Probabilityการแก้ไขปัญหานี้ทำได้โดยการบังคับการคำนวณที่ผิดพลาดให้กลับมาถูกต้องเมื่อสภาพแวดล้อมเป็น On-policy (เช่น เมื่อ Batch Size เท่ากับ Global Batch Size) โดยการตั้งค่า oldlogprob ให้เท่ากับ log_prob ที่คำนวณใหม่ (โดย Detach เพื่อป้องกัน Gradient ไหลผ่านค่าอ้างอิง) อัตราส่วน Importance จะถูกบังคับให้กลับไปเป็น 1 ตามหลักคณิตศาสตร์ กลยุทธ์นี้ช่วยหลีกเลี่ยงความไม่เสถียรที่เกิดจากการ Routing แบบสุ่มของ MoE และรับประกันพฤติกรรม On-policy ที่เข้มงวดระหว่างการฝึก PPOการแก้ไข Training–Inference Mismatchแม้ว่าการแก้ไขปัญหา Log-Probability Mismatch จะช่วยลด Importance-Sampling Clip Ratio ให้เป็นศูนย์ แต่ Gradient Norm ยังคงพุ่งสูงขึ้นและ Reward ก็ยังไม่ปรับปรุง ในการแยกแยะปัญหา เราได้ทำให้การฝึกง่ายขึ้นโดยใช้ GSM8K ซึ่งเป็นงานแบบ Single-step ที่ไม่มีการใช้เครื่องมือแบบเอเจนต์ ความไม่เสถียรแบบเดียวกันยังคงปรากฏอยู่ (ดังที่แสดงในเส้นสีเขียวในภาพที่ 3) ซึ่งบ่งชี้ถึงปัญหาพื้นฐานในการฝึก RL แบบพื้นฐานด้วย GPT-OSS ภายใต้ verlเราตั้งสมมติฐานว่า Training–Inference Mismatch อาจเป็นสาเหตุ: ความแตกต่างระหว่างการดำเนินการขณะ Inference (ที่ Engine อย่าง vLLM และ SGLang จะปรับปรุงประสิทธิภาพสูงสุดเพื่อ Throughput) และการดำเนินการขณะ Training ภายใต้ FSDP ที่ให้ความสำคัญกับความแม่นยำและความเสถียรของตัวเลข สามารถเปลี่ยน RL ที่ควรจะเป็น On-policy ให้กลายเป็น Off-policy ได้อย่างมีประสิทธิภาพบทความนี้จะอธิบายว่าทำไมความไม่ตรงกันเช่นนี้จึงนำไปสู่ Gradient ที่ไม่เสถียรและ Reward ที่ไม่ปรับปรุง ภาพที่ 3 เปรียบเทียบการฝึกทั้งแบบที่มีและไม่มี Rollout Correction (ดูรายละเอียดเพิ่มเติมได้จากบทความ verl นี้) หลังจากใช้ Rollout Correction แล้ว พลวัตการฝึกดีขึ้นอย่างเห็นได้ชัด โดย Gradient Norm ยังคงเสถียรแทนที่จะพุ่งสูงขึ้นอย่างไรก็ตาม ดังที่แสดงในกราฟด้านซ้ายของภาพที่ 4 Reward เพิ่มขึ้นเพียงเล็กน้อย และการลู่เข้าในงาน GSM8K ที่ง่ายก็ยังคงช้ากว่ามากเมื่อเทียบกับโมเดล Dense ที่มีขนาดเล็กกว่าการตรวจสอบกลไก Attention: Attention Sink Support ใน FlashAttentionV3เพื่อแยกแยะสาเหตุให้ละเอียดยิ่งขึ้น เราได้ลอง Freeze Layer ของ Attention ระหว่างการฝึก และสังเกตเห็นพลวัตของ Reward ที่คล้ายคลึงกับ Run ที่ไม่ได้ Freeze (เส้นสีน้ำเงินเทียบกับเส้นสีเหลืองในภาพที่ 4) ซึ่งบ่งชี้ว่าการเรียนรู้ส่วนใหญ่ขับเคลื่อนโดย MoE Layers ในขณะที่กลไก Attention มีส่วนร่วมน้อยกว่าที่คาดไว้ นอกจากนี้ เรายังสังเกตเห็นความไม่ตรงกันของ Token-level Probability อย่างมีนัยสำคัญระหว่าง Inference Engine และ Distributed Training Stack ซึ่งใช้ Attention Kernel ที่แตกต่างกัน ข้อสังเกตเหล่านี้ร่วมกันกระตุ้นให้เกิดการตรวจสอบกลไก Attention อย่างลึกซึ้งยิ่งขึ้นAttention Sinks ที่ใช้ใน GPT-OSS คือพารามิเตอร์สเกลาร์ที่เรียนรู้ได้ (หนึ่งตัวต่อ Attention Head) ซึ่งทำหน้าที่เป็น "Virtual Tokens" ในการคำนวณ Softmax พวกมันช่วยให้โมเดลสามารถจัดสรร Attention Mass ไปยัง Sink ที่เรียนรู้ได้ แทนที่จะบังคับให้ Attention ทั้งหมดไปที่ Content Tokens ซึ่งได้รับการพิสูจน์แล้วว่าช่วยเพิ่มความเสถียรของ Attention ในการ Inference แบบ Streaming และการฝึกด้วย Sliding-Window Attentionหลังจากการตรวจสอบอย่างละเอียด เราพบประเด็นสำคัญหลายประการ:verl Hardcode FlashAttention v2 ไว้ใน fsdp_worker ซึ่งไม่รองรับ Attention SinksAttention Sink Backward Pass ไม่ได้รับการรองรับใน FlashAttention v2 และ v3 ดังนั้นจึงทำงานได้ไม่ถูกต้อง แม้ว่าจะเปิดใช้งาน FlashAttention v3 แล้วก็ตามเนื่องจาก Forward Pass ยังไม่ได้ถูกรวมเข้ากับ Repository FlashAttention v3 ต้นฉบับ เราจึงนำ Forward Pass จาก vLLM FlashAttention fork (PR #75) มาใช้ และได้ทำการ Implement Backward Pass เพื่อคำนวณ Sink Gradient การ Implement นี้จะเผยแพร่หลังจากการตรวจสอบภายในเสร็จสิ้นกลไก Attention กับ Sinks (GPT-OSS)ความแตกต่างที่สำคัญ: Sink มีส่วนร่วมในการทำ Normalization ของ Softmax แต่ไม่มีส่วนร่วมในการคำนวณ Outputสูตรทางคณิตศาสตร์:น้ำหนัก Attention สำหรับ Content Token j ในแถว i กำหนดโดย:$$ P{ij} = \frac{\exp(S{ij})} {\sum{j'=1}^{Nk} \exp(S{ij'}) + \exp(Sh)} $$โดยที่ Sij = Qi Kj⊤ / √d คือ Attention Scores, Pij คือ Attention Weights สำหรับ Content Tokens, และ Sh คือ Sink Parameter ที่เรียนรู้ได้สำหรับ Head hSink Probability จะถูกคำนวณแต่ไม่ถูกนำไปใช้ใน Output:$$ P{i,h} = \frac{\exp(Sh)} {\sum_{jhttps://huggingface.co/blog/LinkedIn/gpt-oss-agentic-rl