Dream-RSI ของ Google/DeepMind: เอาประวัติการค้นหาที่ทำไปแล้วมาเป็น "เครื่องจำลอง" ให้เอเจนต์ซ้อมกลยุทธ์ใหม่ฟรี — ลดจำนวนครั้งที่เรียกโมเดลจาก 550 เหลือ 317

ก.ย. 2026 ทีมวิจัยร่วมระหว่าง Google, Google DeepMind, University of Maryland และ University of Virginia ปล่อยพรีปรินต์ชื่อ Dream-RSI: Recursive Self-Improvement through Evolving Worlds พร้อมหน้าโปรเจกต์ dream-rsi.com และรีโป GitHub ที่มีดาวไปแล้วกว่า 900 ดวง แนวคิดหลักเรียบง่ายจนน่าหงุดหงิดว่าทำไมเพิ่งมีคนทำ: ประวัติการค้นหาที่เอเจนต์ทำไปแล้ว คือเครื่องจำลองสภาพแวดล้อมที่ดีที่สุดที่คุณมีอยู่แล้วโดยไม่ต้องสร้างใหม่

ปัญหาที่งานนี้แก้เป็นปัญหาที่ใครเคยปล่อยเอเจนต์วิ่งยาว ๆ จะคุ้นดี: ระบบค้นพบคำตอบแบบวนลูป (เสนอ → ประเมิน → แก้ → เสนอใหม่) กินรอบเป็นพัน ๆ รอบ และสิ่งที่ตัดสินว่าจะเปลืองหรือไม่เปลือง คือกลยุทธ์การสำรวจ ไม่ใช่ตัวโมเดล ปัญหาคือกลยุทธ์แบบตายตัวปรับตัวไม่ได้เมื่อ search space ใหญ่ขึ้น ส่วนการปรับกลยุทธ์ระหว่างทางก็ติดกำแพงสองชั้น: ฟีดแบ็กมาช้าและแพง (จะรู้ว่ากลยุทธ์ดีไหม ต้องปล่อยให้มันคุมกระบวนการค้นหาทั้งกระบวนก่อน) และพื้นที่ของ “กลยุทธ์ที่เป็นไปได้” ก็กว้างมหาศาล

กลไก: ต้นไม้การค้นหาที่บันทึกไว้แล้ว = simulator ที่รันซ้ำได้ฟรี

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

ถ้าเป็นเช่นนั้น กลยุทธ์สำรวจแบบใหม่ก็สามารถ “เดิน” บนต้นไม้เดิมได้ — เลือกกิ่งคนละชุด เรียงลำดับคนละแบบ จัดกลุ่มรันขนานคนละขนาด หรือตัดสินใจหยุดคนละจุด — แล้วให้คะแนนได้ทันทีโดยไม่ต้องเรียก coding agent หรือ evaluator ใหม่แม้แต่ครั้งเดียว เพราะผลลัพธ์ทุกโหนดถูกบันทึกไว้หมดแล้ว เปเปอร์เรียกกระบวนการนี้ว่า dreaming และเทียบตรง ๆ กับตระกูล Dreamer ใน model-based RL ที่เอเจนต์เรียนรู้ dynamics model แล้วปรับ policy ด้วยการ “จินตนาการ” trajectory ภายในโมเดลนั้น

ลูปทั้งหมดมีสามขั้น:

1. Online Explore — ใช้ policy ปัจจุบันคุม coding agent ให้ขยายต้นไม้การค้นพบจริง พร้อมบันทึก trace
2. Construct Replay Simulator — แปลงต้นไม้ที่ได้เป็น simulator แล้วโยนเข้า pool
3. Dreaming-based Policy Improvement — เอเจนต์สร้าง policy ทางเลือกจำนวนมากขึ้นมา “ในหัว” แล้วรันทุกตัวบน simulator เพื่อได้ฟีดแบ็กเร็ว ๆ ก่อนเลือกตัวที่ดีที่สุดไป deploy รอบถัดไป

จุดที่ควรเน้นสำหรับคนสร้างเอเจนต์: Dream-RSI ไม่แตะโมเดลข้างใต้เลย ไม่มีการเทรน ไม่มี gradient step มันเป็น orchestration layer บาง ๆ ที่คุมแค่ว่าจะแตกกิ่งอย่างไร รันขนานกี่ตัว และหยุดเมื่อไหร่ — และตัว policy นั้นเป็น โค้ดที่รันได้ ซึ่งเอเจนต์อีกตัวเขียนแก้ให้ นั่นแปลว่าเทคนิคนี้ย้ายไปใช้กับ harness ใดก็ได้ในหลักการ

เกณฑ์ให้คะแนนตอน replay ก็ออกแบบมาตรงไปตรงมา: คุณภาพคำตอบที่ดีที่สุดที่หาเจอ ลบ จำนวนครั้งที่ต้อง generate บวก โบนัสให้ policy ที่จัดงานขนานเป็นแบตช์แทนที่จะรันทีละตัว

ตัวเลข: ประหยัดจริงในสามโดเมน

ทีมทดสอบ 8 งานใน 3 โดเมน โดยใช้ Gemini-3.1 Pro และ Gemini-3.7-Flash ผ่าน Gemini CLI เป็น discovery agent และเทียบกับ Recursive Fixed Exploration (ตั้งค่าทุกอย่างเหมือนกัน ต่างแค่ไม่ปรับ policy)

อัลกอริทึม (Lasso Regularization Path) — วัดบน 6 ชุดข้อมูล held-out ทั้งชีววิทยาและไม่ใช่ชีววิทยา

• Gemini-3.1 Pro: runtime เฉลี่ย 3,587.1 ms → 2,931.0 ms ขณะที่ใช้ agent call 317 ครั้ง เทียบกับ 550 ครั้งของ fixed exploration
• Gemini-3.7-Flash: 2,516.7 ms → 2,350.6 ms ด้วย 1,879 calls เทียบกับ 3,200
• เทียบ baseline ภายนอก: sklearn ได้ 44,180.3 ms, glmnet 13,767.5 ms, SimpleTES 3,804.8 ms ด้วยงบ 51,200 generations — Dream-RSI จึงเร็วกว่า SimpleTES ทั้งที่ใช้งบน้อยกว่าราว 162 เท่า

คณิตศาสตร์ (10 รอบ, Gemini-3.1 Pro)

• Sum–Difference: 1.145427 นำทั้ง SimpleTES และ Recursive Fixed Exploration
• Circle Packing: 2.635983 เสมอผลดีที่สุดในกลุ่มที่เทียบ (ซึ่งรวม AlphaEvolve, AlphaEvolveV2, OpenEvolve, ShinkaEvolve, ThetaEvolve, EvoX)
• Autocorrelation: 1.456375 แข่งได้ แต่เปเปอร์ระบุเองว่า SimpleTES เป็นผู้ถือ SOTA ในงานนี้ — ไม่ใช่ชนะทุกช่อง

เคอร์เนล GPU (KernelBench: VGG16, LayerNorm, ConvDiv, ConvMax)

• VGG16 และ LayerNorm: ได้ประสิทธิภาพสุดท้ายใกล้เคียงกันโดยใช้ generation น้อยลง 2.43 เท่า และ 1.79 เท่า ตามลำดับ
• ConvDiv และ ConvMax: ที่งบเท่ากัน ทำได้ดีกว่า 2.09 เท่า และ 1.44 เท่า

ผลข้างเคียงที่น่าสนใจกว่าตัวเลขหลัก

สองการวิเคราะห์เพิ่มเติมท้ายเปเปอร์มีค่ากับคนทำเอเจนต์มากกว่าตารางเบนช์:

1. การสรุปบทเรียนใส่พรอมต์ ทำให้แย่ลง ทีมลองวิธีที่คนส่วนใหญ่ทำกัน — เอาประวัติมาสรุปเป็น “คำแนะนำทิศทาง” ระดับสูงแล้วยัดเข้าพรอมต์รอบถัดไป ผลคือแย่กว่าไม่ใส่เลย ทั้งกับ Dream-RSI และกับ fixed exploration ที่งบเท่ากัน คำอธิบายของทีมคือ ในงานค้นหายาว ๆ ที่มีหลายสายวิ่งขนาน การใส่ inductive bias เชิงความหมายแรง ๆ เรื่องทิศทางอนาคตจะบีบ search space เกินไปและฆ่าความหลากหลายของการสำรวจ — ใช้ประวัติเป็น simulator ที่โต้ตอบได้ ดีกว่าใช้เป็นคำแนะนำ

2. policy ที่เรียนได้เอง มีจังหวะ “หายใจ” กราฟวิวัฒนาการบน ConvDiv แสดงว่า เมื่อผลงานกำลังดีขึ้น policy จะลดจำนวนครั้งที่ประเมินลงจาก 110 เหลือ 50 เพื่อประหยัดคอมพิวต์ แล้วเมื่อผลงานเริ่มนิ่ง มันจะเพิ่มความพยายามสำรวจกลับขึ้นมา ซึ่งตรงกับช่วงที่คะแนนกระโดดต่อ นี่เป็นพฤติกรรม explore-exploit ที่ไม่มีใครเขียนกฎให้

ข้อควรระวังก่อนเชื่อทั้งหมด

• โค้ดยังไม่ปล่อย README ระบุชัดว่า “Code is being prepared for release” และป้าย arXiv ยังเป็น “coming soon” — ตอนนี้มีแค่ไฟล์ PDF ในรีโปกับหน้าเว็บโปรเจกต์ รีโปยังไม่มีไฟล์ LICENSE ด้วย จึงยังทำซ้ำผลไม่ได้
• ยังไม่ผ่าน peer review นี่คือพรีปรินต์
• baseline หลักเป็น baseline ของตัวเอง — Recursive Fixed Exploration คือ Dream-RSI ที่ถอดส่วน dreaming ออก ซึ่งเป็น ablation ที่ตรงประเด็น แต่การเทียบกับระบบภายนอกอย่าง AlphaEvolve หรือ SimpleTES เป็นการยกตัวเลขที่เจ้าของรายงานไว้มาวาง ไม่ได้รันซ้ำเอง
• ทดสอบบน Gemini เท่านั้น ยังไม่มีหลักฐานว่าย้ายไป Claude, GPT หรือโมเดลเปิดแล้วจะได้ผลเท่ากัน

มุมมอง AI Curator

สิ่งที่ผมชอบในงานนี้คือมันชี้ไปที่ของที่ทุกทีมมีอยู่แล้วแต่ทิ้งขว้าง ทีมที่รันเอเจนต์ในโปรดักชันวันนี้ล้วนมีล็อกเต็มไปหมด — ทุกครั้งที่เอเจนต์ลองอะไรแล้วพัง มีคนจ่ายค่าโทเคนไปแล้ว และแทบทุกที่เอาล็อกนั้นไปทำได้แค่สองอย่าง: debug หรือทิ้ง Dream-RSI บอกว่าล็อกชุดนั้นคือสนามซ้อมที่จ่ายเงินไปแล้ว และคุณซ้อมบนมันได้ฟรีไม่จำกัดรอบ

ประเด็นเรื่องต้นทุนนี้สำคัญมากในบริบทไทยและ SEA เป็นพิเศษ ทีมส่วนใหญ่ในภูมิภาคไม่ได้แข่งกันที่ “มีโมเดลดีกว่า” เพราะทุกคนเรียก API เจ้าเดียวกัน แต่แข่งกันที่ ใช้โทเคนต่องานน้อยกว่า — และนี่คือชั้นที่ยังมีที่ว่างให้ปรับอีกเยอะ ตัวเลข 550 → 317 calls ที่ได้คุณภาพดีขึ้นด้วย แปลตรง ๆ เป็นบิลที่ลดลงเกือบครึ่งโดยไม่ต้องเปลี่ยนโมเดลหรือรอรุ่นถัดไป สำหรับสตาร์ทอัพที่งบจำกัด การลงทุนใน orchestration layer ให้ผลตอบแทนเร็วกว่าการอัปเกรดไปใช้โมเดลแพงกว่า

แต่ผลที่ผมคิดว่าจะถูกอ้างถึงมากที่สุดในอีกหกเดือน คือผลข้างเคียงข้อแรก — “เอาประวัติมาสรุปเป็นคำแนะนำใส่พรอมต์ แล้วแย่ลง” เพราะนั่นคือแพตเทิร์นที่คู่มือการสร้างเอเจนต์เกือบทุกเล่มสอนอยู่ตอนนี้ ตั้งแต่ memory file ไปจนถึง “lessons learned” ที่ระบบเขียนทับตัวเองทุกรอบ ถ้าผลนี้ทนต่อการทำซ้ำได้ มันแปลว่าเรากำลังใส่ inductive bias ที่ฆ่าความหลากหลายของการสำรวจเข้าไปในเอเจนต์โดยตั้งใจ แล้วเรียกมันว่าการเรียนรู้ — ข้อแตกต่างอยู่ที่ว่าประวัติควรเป็นของที่เอเจนต์เดินกลับเข้าไปสำรวจได้ ไม่ใช่ของที่ถูกย่อยเป็นข้อสรุปแล้วบังคับให้เชื่อ

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

แหล่งข่าว

• zhengkid/Dream-RSI — GitHub (รีโปทางการ + ไฟล์เปเปอร์ PDF)
• Dream-RSI: Recursive Self-Improvement through Evolving Worlds — เปเปอร์ฉบับเต็ม (PDF)
• หน้าโปรเจกต์ dream-rsi.com
• Google Deepmind’s Dream-RSI helps AI agents improve by “dreaming” about past attempts — The Decoder