RRSI ของ Google: ทางที่ AI agent เก่งขึ้นได้โดยไม่ต้องเปลี่ยนโมเดล แต่ต้องเปลี่ยนวิธีแก้ของมัน

โดย Nokka (นก-กา) | 3 ตุลาคม 2569

คุณเคยปรับ prompt ของ AI agent จนมันทำได้ดีขึ้นบนงานที่ทดสอบ แล้วพอเจองานจริงกลับไม่ต่างจากเดิมไหม

คุณไม่ได้คิดไปเอง และมีงานวิจัยที่เพิ่งออกมาเมื่อวันที่ 21 กันยายน 2026 ที่อธิบายว่าทำไมเรื่องนี้ถึงเกิด พร้อมเสนอทางแก้ที่ตรงจุดกว่าเดิม [1]

งานนี้ชื่อ RRSI ย่อมาจาก Regularized Recursive Self-Improvement of Agent Harnesses ทำโดยนักวิจัยจาก Google Cloud AI Research ร่วมกับ UNC-Chapel Hill, Stanford และ Washington University in St. Louis [1]

ก่อนจะไปถึงทางแก้ ผมขอปูเรื่องหนึ่งก่อน เพราะคำสำคัญที่สุดของงานนี้คือคำว่า harness และคนส่วนใหญ่ที่ใช้ agent ทุกวันยังไม่รู้ว่าตัวเองกำลังแก้อะไรอยู่

ภาพแนวคิด คือโมเดลเดียวกันที่ถูกประกอบต่างกัน ย่อมให้ผลต่างกัน

harness คือส่วนที่ทำให้โมเดลเดียวกันทำงานได้ต่างกันมาก

ในงานวิจัยนี้ เขานิยาม harness ว่าเป็นทุกอย่างที่ห่อโมเดลไว้ ประกอบด้วย prompt ที่ป้อน วิธีควบคุมลำดับการทำงาน เครื่องมือที่ให้ใช้ หน่วยความจำ และวิธีจัดการบริบท [1]

พูดง่าย ๆ คือ โมเดลคือเครื่องยนต์ ส่วน harness คือรถทั้งคัน เครื่องยนต์เดิม แต่รถที่ประกอบดีกับรถที่ประกอบแย่ ให้ผลต่างกันมหาศาล เพราะโมเดลที่แข็งแรงเท่ากันจะอ่านไฟล์ถูกหรือผิดก่อนแก้ ฟื้นตัวจากคำสั่งที่ล้มเหลวได้หรือไม่ได้ และจัดการพื้นที่ทำงานของตัวเองเป็นหรือไม่ ทั้งหมดนี้ harness เป็นผู้ชี้ขาด ไม่ใช่โมเดล [1]

และนี่คือเหตุผลที่งานนี้สำคัญกับคนที่สร้าง agent ใช้เอง ถ้าคุณกำลังคิดจะเปลี่ยนไปใช้โมเดลใหม่เพื่อให้ agent เก่งขึ้น งานนี้บอกว่าคุณกำลังมองข้ามส่วนที่แก้ได้ถูกกว่า

ปัญหา: agent เก่งขึ้นบนสนามที่มันซ้อม แต่ไม่เก่งขึ้นจริง

ก่อน RRSI มีแนวทางที่ทำกันอยู่คือให้ LLM เสนอการแก้ harness ทีละส่วน แล้ววัดผลว่าดีขึ้นไหม ถ้าดีขึ้นก็เก็บไว้ ทำซ้ำแบบนี้ไปเรื่อย ๆ วิธีนี้เรียกว่า recursive self-improvement หรือการพัฒนาตัวเองซ้ำในระดับระบบ agent [1]

ฟังดูดี แต่มีกับดัก

งานวิจัยชี้ว่าเมื่อทำแบบนี้ซ้ำ ๆ harness จะ ท่องจำงานในชุดที่ใช้ซ้อม ตัวเลขบนชุดซ้อมพุ่งขึ้นสวยงาม แต่พอเจอชุดทดสอบที่ไม่เคยเห็น กำไรนั้นหดหายหรือหายไปเลย [1]

และมีรายละเอียดที่ผมว่าสำคัญที่สุดในงานนี้ คือในบรรดาวิธีเดิมที่ทดลองเทียบ ปรากฏว่า มีถึงสองวิธีที่จบลงด้วยคะแนนต่ำกว่าจุดตั้งต้นของตัวเอง [2]

แปลว่า agent ที่ผ่านการ "พัฒนา" มาแล้ว กลายเป็นแย่กว่า agent ที่ยังไม่แก้อะไรเลย ซึ่งเป็นความล้มเหลวแบบที่คนทำ agent เจอบ่อย แต่ไม่ค่อยมีใครวัดออกมาเป็นตัวเลข

วิธีคิดของ RRSI: อย่าไปคุมว่าอะไรแก้ได้ คุมว่าการแก้เดินยังไง

จุดที่ผมชอบที่สุดของงานนี้คือการเลือกจุดเข้าแทรก

วิธีแก้ที่ตรงไปตรงมาคือห้ามไม่ให้แก้บางส่วน เช่น ห้ามแตะเครื่องมือ ห้ามแตะหน่วยความจำ แต่ RRSI ไม่ทำแบบนั้น มัน ปล่อยให้แก้ได้ทุกส่วนเหมือนเดิม แล้วไปคุมที่ตัวกระบวนการค้นหาแทน [1]

แนวคิดนี้สรุปได้ในประโยคเดียวจากหน้าเว็บของโครงการ คือ จัดระเบียบการค้นหา ไม่ใช่จัดระเบียบ harness [2]

การคุมทำสองฝั่ง ฝั่งแรกคุมตอน เสนอ การแก้ ฝั่งที่สองคุมตอน ตัดสินใจว่าจะรับ การแก้นั้น

ฝั่งเสนอ: งบแก้ที่หดลงตามเวลา

กลไกแรกคืองบแก้ที่ลดหลั่นตามเวลา เรียกว่า annealed edit budget ในรอบแรก ๆ ตัวเสนอถูกปล่อยให้รวมหลายการแก้เข้าไว้ในข้อเสนอเดียว เพราะช่วงต้นยังต้องหาว่ากลไกไหนได้ผล แต่พอเข้ารอบท้าย ๆ งบจะเหลือการแก้ที่วัดผลได้ครั้งละหนึ่งจุด [1]

เหตุผลคือถ้าปล่อยให้รวมหลายอย่างตลอดไป คุณจะไม่รู้ว่าอะไรกันแน่ที่ทำให้ดีขึ้น

กลไกที่สองคือการป้อนประวัติการแก้ทั้งหมดให้ตัวเสนอเห็น เพื่อไม่ให้มันเสนอสมมติฐานเดิมที่ถูกพิสูจน์แล้วว่าใช้ไม่ได้ซ้ำอีก [1]

กลไกที่สามคือถ้าการค้นหาติดอยู่กับที่ ระบบจะบังคับให้หันไปลองส่วนที่ยังไม่เคยถูกแตะเลย [1]

ฝั่งเลือก: ใครได้อยู่ต่อ

ฝั่งที่สองคือตอนตัดสินว่ารับการแก้ไหม และนี่คือส่วนที่ผมคิดว่าต่างจากวิธีอื่นชัดเจนที่สุด [1]

นักวิจารณ์ (critic) จะคัดข้อเสนอที่เขียนขึ้นมาเฉพาะเจาะจงกับชุดทดสอบใดชุดหนึ่งออกไป ก่อน ที่มันจะถูกนำไปวัดผลเสียอีก [1]

พื้นกันสัญญาณรบกวน (noise-adjusted floor) คือเส้นต่ำสุดที่ยอมรับได้ โดยวัดจากความผันผวนของ harness ฐานก่อนเริ่มทดลอง ระบบจะไม่รับกำไรที่ยังอยู่ในช่วงความผันผวนนั้น ป้องกันไม่ให้การค้นหาไถลลงเนินผ่านความถดถอยเล็ก ๆ ที่ดูเหมือนสัญญาณรบกวน [1]

กฎต้นทุน (cost rule) กำหนดว่าโทเคนที่เพิ่มขึ้นต้องถูกจ่ายด้วยกำไรที่วัดได้จริง [2]

เครื่องตัด (pruner) จะลบส่วนที่เคยช่วยแต่หยุดช่วยแล้วออก [1]

ฝั่งเสนอ (proposal side)
  งบแก้ลดหลั่น     รอบต้นรวมได้ รอบท้ายเหลือครั้งละหนึ่งจุด
  ประวัติการแก้    เห็นทุกสมมติฐานที่เคยถูกพิสูจน์แล้ว
  หันไปลองใหม่      ติดที่เดิมเมื่อไหร่ ให้ไปลองส่วนที่ไม่เคยแตะ

ฝั่งเลือก (selection side)
  critic        คัดข้อเสนอที่เจาะจงชุดทดสอบ ก่อนนำไปวัด
  noise floor   ไม่รับกำไรที่อยู่ในช่วงความผันผวน
  cost rule     โทเคนที่เพิ่ม ต้องจ่ายด้วยกำไรที่วัดได้
  pruner        ลบส่วนที่หยุดช่วยแล้ว

ตัวเลขที่ได้

งานนี้ทดสอบบนแปดชุดทดสอบ ครอบสามโดเมน คือการเขียนโค้ด (Terminal-Bench 2.1 และ SWE-bench Verified) พื้นที่ทำงานแบบ agent (Harvey LAB, JobBench, GDPval และ APEX-Agents) และการออกแบบทางวิศวกรรม (EngDesign และ Frontier-Eng) [1]

แปดชุดนี้ไม่ได้มีบทบาทเท่ากัน สามชุดใช้พัฒนา (evolve) ส่วนห้าชุดเป็นชุดนอกโดเมน (OOD) ที่ไม่เคยเห็นระหว่างพัฒนาเลย [1]

Harvey LAB ซึ่งเป็นหนึ่งในสามชุดที่ใช้พัฒนา ยังถูกแบ่งเป็นสองส่วน คือ 120 งานสำหรับพัฒนา และอีก 40 งานที่กันแยกไว้เป็นชุดทดสอบในโดเมนเดียวกัน เพราะฉะนั้นถ้านับตามบทบาท ชุดทดสอบที่ถูกกันไว้จะมีหกชุด และรวมกับสามชุดที่ใช้พัฒนากลายเป็นเก้าบทบาท จาก benchmark แปดตัว [1]

วิธีรันคือในแต่ละโดเมน harness จะถูกพัฒนาโดยใช้ชุดเดียว แล้วนำไปรันโดยไม่แก้อะไรเลยบนทุกชุดที่กันไว้ [1]

ผลลัพธ์ตามที่บทคัดย่อระบุ คือทำได้ดีขึ้น ถึง 14.1 คะแนน ในชุดที่ใช้พัฒนา และดีขึ้น ถึง 4.7 คะแนน ในชุดนอกโดเมน โดยใช้โทเคนน้อยกว่าการพัฒนาตัวเองแบบไม่จัดระเบียบถึง 30% [1]

หน้าเว็บของโครงการรายงานตัวเลขในอีกแบบหนึ่ง คือกำไรเฉลี่ย 4.0 คะแนน จากการพัฒนาสามครั้ง และ 3.4 คะแนน บนหกชุดที่กันไว้ พร้อมทั้งประหยัดโทเคนได้ 36% ต่อการทดลอง [2]

ตัวเลขสองชุดนี้ไม่ขัดกัน แต่ละชุดตอบคนละคำถาม 14.1 กับ 4.7 คือผลของการทดลองรายครั้งที่ทำได้สูงสุดในกลุ่มของมัน ส่วน 4.0 กับ 3.4 คือค่าเฉลี่ยที่คิดข้ามชุด สองแบบนี้เอามาเทียบกันตรง ๆ ไม่ได้ [1][2]

มีจุดหนึ่งที่ผมเข้าใจผิดตอนเขียนรอบแรก และต้องแก้ให้ตรง คือผมอ่านตัวเลข ห้า กับ หก ในต้นทางแล้วนึกว่าขัดกันเอง แท้จริงมันเป็นสองหมวดที่ต่างกัน ห้า คือจำนวนชุดนอกโดเมน ส่วน หก คือชุดทดสอบที่กันไว้ทั้งหมด ซึ่งเท่ากับห้าชุดนอกโดเมนบวกอีกหนึ่งชุดที่กันไว้ในโดเมนเดียวของ Harvey LAB [1][2]

งานวิจัยนี้อธิบายการแบ่งชุดไว้ในภาคผนวกชัดเจนว่า Harvey LAB 160 งานถูกแบ่งเป็น 120 งานสำหรับพัฒนาและ 40 งานกันไว้ ไม่ใช่ปล่อยให้ผู้อ่านเดาเอง [1]

อีกตัวเลขหนึ่งที่ผมว่าสื่อความได้ดีคือ ตารางที่หนึ่งของงาน ซึ่งทดสอบเฉพาะพื้นที่ทำงานแบบ agent สี่ชุด คือ Harvey LAB, JobBench, GDPval และ APEX-Agents [1] บนชุดนอกโดเมนสามชุดคือ JobBench, GDPval และ APEX-Agents RRSI ทำได้ 40.7, 52.3 และ 37.9 ขณะที่ HarnessX ซึ่งเป็นวิธีเดิมตัวหนึ่งในตารางเดียวกันทำได้ 36.3, 48.5 และ 34.3 [1][2]

ค่าเฉลี่ยนอกโดเมนของ RRSI อยู่ที่ 43.6 เทียบกับ 39.4 ของค่าเฉลี่ยวิธีเดิมทั้งสี่ตัว และ 39.7 ของจุดตั้งต้น [2]

ส่วนตัวเลข 22.9% นั้นเป็นของงานออกแบบทางวิศวกรรม (Frontier-Eng) ที่ RRSI ทำได้ 22.0 เทียบกับค่าเฉลี่ยวิธีเดิม 17.9 ไม่ใช่ค่าเฉลี่ยรวมทุกโดเมน ซึ่งเป็นกำไรเชิงสัดส่วนที่สูงที่สุดในสามโดเมน เพราะงานเขียนโค้ด (SWE-bench Verified) ได้เพิ่มเพียงราว 1.8% [2]

วิธีเดิมที่นำมาเทียบทั้งสี่ตัวคือ Meta-Harness, AHE, TTHE และ HarnessX [1]

คำถามที่ต้องถามก่อนเชื่อ

งานวิจัยนี้แข็งแรงกว่าที่ผมคาด แต่มีสี่ข้อที่ตัวงานเองยอมรับไว้ และผมคิดว่าผู้อ่านควรรู้ก่อนเอาไปใช้ [1]

สี่ข้อจำกัดที่งานนี้บอกเอง

หนึ่ง งานนี้ศึกษาเฉพาะกรณีที่ โมเดลหลักถูกแช่แข็ง ไม่แตะน้ำหนักโมเดลเลย จึงยังไม่ตอบคำถามว่าใช้ได้ไหมกับกรณีที่โมเดลถูกอัปเดตระหว่างกระบวนการ [1]

สอง RRSI ยังต้องพึ่ง ชุดพัฒนาที่จำกัด และต้องตั้งค่าพารามิเตอร์หลายตัว ประสิทธิผลจึงอาจขึ้นกับคุณภาพของสัญญาณตอบกลับและงบการค้นหาที่เลือก [1]

สาม แม้จะทดสอบข้ามหลายโดเมน หลายชุดทดสอบ และหลายโมเดล แต่ยังต้องมี การตรวจสอบในวงกว้างขึ้น ก่อนจะสรุปว่าใช้ได้กับสถาปัตยกรรม agent อื่น ระบบเครื่องมือที่ต่างออกไป และกระบวนการพัฒนาตัวเองที่ยาวนานกว่านี้ [1]

สี่ ตัวเลขทั้งหมดมาจากชุดทดสอบที่งานนี้เลือกเอง ซึ่งเป็นเรื่องปกติของงานวิจัย แต่หมายความว่ายังไม่มีใครทดสอบซ้ำจากข้างนอก

อะไรที่คนไทยเอาไปใช้ได้จริง

สำหรับคนที่ สร้าง agent ใช้เองในทีม งานนี้ให้กรอบคิดที่เอาไปใช้ได้ทันทีโดยไม่ต้องรันงานวิจัย

หนึ่ง แยกให้ออกว่ากำลังแก้โมเดลหรือแก้ harness ถ้าปัญหาคือ agent อ่านไฟล์ผิดหรือลืมบริบท การเปลี่ยนโมเดลอาจไม่ช่วย แต่การแก้ prompt ลำดับการทำงาน และวิธีจัดการบริบทช่วยได้

สอง วัดบนงานที่ไม่ได้เอามาซ้อม นี่คือหัวใจของงานนี้ทั้งหมด ถ้าคุณปรับ prompt จนคะแนนบนชุดทดสอบดีขึ้น แต่ไม่ได้ลองกับงานที่ไม่เคยเห็น คุณยังไม่รู้ว่าได้อะไรจริง

สาม ตั้งกฎก่อนรับการแก้ กฎของ RRSI ที่ผมว่ายกมาใช้ได้เลยคือ การแก้ที่เพิ่มต้นทุน ต้องถูกจ่ายด้วยกำไรที่วัดได้ และ ส่วนที่หยุดช่วยแล้วควรถูกตัดออก เพราะ prompt และเครื่องมือที่พอกพูนขึ้นเรื่อย ๆ คือหนี้ที่ทำให้ agent ช้าลงและเดาผิดมากขึ้น

สี่ ถ้าการแก้วนอยู่ที่เดิม ให้เปลี่ยนไปแก้ส่วนที่ยังไม่เคยแตะ ซึ่งเป็นกลไกที่ RRSI ใส่ไว้ตรง ๆ และเป็นจุดที่คนทำ agent มักไม่ทำ เพราะเรามักกลับไปแก้ prompt ซ้ำในจุดเดิม

และสำหรับคนที่ กำลังตัดสินใจจะจ่ายเงินเพื่ออัปเกรดโมเดล ผมคิดว่าคำถามที่ควรถามก่อนคือ ถ้า agent ของคุณใช้โมเดลเดิม แต่ harness ใหม่ใช้โทเคนน้อยลง 30% ผลลัพธ์จะต่างกันแค่ไหน เทียบกับการจ่ายเพิ่มเพื่อเปลี่ยนโมเดล

ถ้าคุณยังไม่แน่ใจว่าจะเริ่มวัดจากตรงไหน ลองนับดูว่าทีมคุณเคยทดสอบ agent กับงานที่ไม่ได้เอามาใช้ปรับกี่ครั้งในเดือนที่ผ่านมา

ที่ควรไปอ่านต่อ

โค้ดและหน้าโครงการ

โค้ดของงานนี้เปิดให้ใช้ที่ GitHub ของ Google Research [3] และมีหน้าโครงการที่อธิบายกลไกแต่ละชั้นได้อ่านง่ายกว่าตัวบทความวิจัย [2]

ถ้าคุณอยากลองกับ agent ที่ทีมคุณใช้อยู่ จะเริ่มจากตรงไหนก่อน? ข้อที่ง่ายที่สุดคือเลือกงานหนึ่งงานที่ทีมทำซ้ำทุกสัปดาห์ แล้ววัดผลก่อนปรับ harness หลังจากนั้นลองปรับแค่ prompt กับวิธีจัดการบริบท แล้ววัดซ้ำบนงานคนละชุดกับที่ใช้ปรับ

ผมคิดว่างานนี้จะเป็นประโยชน์ที่สุดกับคนที่กำลังสร้าง agent แล้วรู้สึกว่าปรับเท่าไรก็ไม่ไปไหน เพราะคำตอบของงานนี้คือคุณอาจไม่ได้ปรับผิด แต่คุณยังไม่ได้ตั้งกฎว่า อะไรควรถูกเก็บไว้ และอะไรควรถูกทิ้ง ถ้าคุณกำลังเจออาการนั้นอยู่ นั่นคือจุดที่ควรเริ่มอ่านงานนี้จริง ๆ

เอกสารอ้างอิง

[1] Peng Xia, Rujun Han, Zifeng Wang, Yanfei Chen, Yufan Zhuang, Yoonho Lee, Chengsong Huang, Han Yu, Zhongying CuiZhu, Yifei Ming, Huaxiu Yao, Burak Gokturk, Tomas Pfister และ Chen-Yu Lee, "RRSI: Regularized Recursive Self-Improvement of Agent Harnesses", arXiv (Google Cloud AI Research, Stanford University, Washington University in St. Louis, UNC-Chapel Hill), 21 กันยายน 2026 (ค.ศ. 2026): https://arxiv.org/abs/2609.24972

[2] Google Research, "RRSI: Regularized Recursive Self-Improvement of Agent Harnesses (project page)", regularized-rsi.com, 2026 (ค.ศ. 2026): https://regularized-rsi.com/

[3] Google Research, "RRSI: Regularized Recursive Self-Improvement of Agent Harnesses (source code)", GitHub, 2026 (ค.ศ. 2026): https://github.com/google-research/rrsi

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

---

Nokka (นก-กา) เขียนบทความนี้ด้วยความช่วยเหลือของ AI ตรวจสอบข้อมูลจากแหล่งต้นทางทุกจุดก่อนเผยแพร่