Google เปิด autofinetune — ให้เอเจนต์จูน Gemma บน TPU ข้ามคืนด้วย program.md ไฟล์เดียว แต่ results.tsv ในรีโปบอกว่า SFT ขยับ 3.7 จุด และกำไร RL กว่าครึ่งมาจากรูปแบบคำตอบ

เมื่อ 11 ก.ย. 2026 Wei Wei นัก Developer Advocate ของ Google เผยแพร่บทความบน Google Developers Blog แนะนำ autofinetune — การนำไอเดียของ autoresearch ที่ให้เอเจนต์ทดลอง pre-training เองเป็นลูป มาใช้กับ post-training ทั้ง Supervised Fine-Tuning และ RL แบบ GRPO บนสแตกของ Google ทั้งชุด: ไลบรารี Tunix (JAX), โมเดล Gemma และ Cloud TPU โดยใช้ Antigravity CLI กับ Gemini Flash 3.7 เป็นตัวขับเอเจนต์ ภาพที่บทความขายคือ “เขียนสเปก Markdown ไฟล์เดียวก่อนนอน ตื่นมาเจอการทดลองหลายสิบรอบที่ commit ผลดีไว้ใน Git แล้ว”

โค้ด ตัวอย่าง program.md และไฟล์ผลลัพธ์จริงอยู่ในรีโป windmaple/autofinetune (MIT) ซึ่งทำให้เราเปิดดูได้ว่าเอเจนต์ทำอะไรไปบ้างในแต่ละรอบ ไม่ต้องอาศัยแค่กราฟในบทความ

ลูปทำงานอย่างไร

โครงสร้างมีสามชิ้น:

1. program.md — “สนาม” ที่มนุษย์เขียน: เป้าหมาย ขอบเขต เกณฑ์วัด และข้อห้าม
2. run.py — สคริปต์ fine-tune ไฟล์เดียวที่เป็นไฟล์เดียวที่เอเจนต์แก้ได้
3. results.tsv — บันทึกทุกการทดลองเป็น commit hash, คะแนน, keep/discard และคำอธิบาย

คำสั่งใน program.md ของเคส SFT เขียนว่า “LOOP FOREVER”: ดู git state → แก้ run.py ตามไอเดีย → commit → รัน → บันทึกผล → ถ้าคะแนนดีขึ้นให้เก็บ commit ไว้ ถ้าเท่าเดิมหรือแย่ลงให้ git reset กลับ เอเจนต์ปรับ LoRA rank/alpha, เลเยอร์เป้าหมาย, learning rate, schedule, optimizer, batch size และ seed ได้ แต่ห้ามแตะ dataset, จำนวน epoch และสถาปัตยกรรมโมเดล

เคส 1: SFT บน FunctionGemma 270M

จูน google/functiongemma-270m-it บนชุดข้อมูล google/mobile-actions (สร้าง function call สั่งงานมือถือ) บน Cloud TPU v5e-1 รอบละไม่กี่นาที รวม 20 การทดลองในเวลาไม่กี่ชั่วโมง

ใน SFT_results.tsv ความแม่นยำขยับจาก 86.58% → 90.32% (+3.74 จุด) มี 7 การทดลองที่ถูกเก็บ และ 13 ครั้งถูกทิ้ง ก้าวที่ได้มากที่สุดคือก้าวแรก — เพิ่ม attn_vec_einsum เข้าไปใน LoRA target พร้อมตั้ง rank=16, alpha=32 (+1.77 จุด) ที่เหลือเป็นการไล่ปรับ learning rate, warmup, weight decay และ gradient clipping ทีละนิด ผลดีที่สุดมาถึงในการทดลองที่ 12 จากนั้นอีก 8 รอบถูกทิ้งทั้งหมด รายละเอียดเล็ก ๆ ที่น่าสนใจคือ program.md แซวไว้ว่า “ได้ยินว่า Muon กำลังมาแรง” แต่ในบันทึกไม่มีรอบไหนลอง Muon เลย เอเจนต์ลองแค่ nadamw

เคส 2: GRPO บน Gemma 3 1B สำหรับคณิตศาสตร์

เคสที่ยากกว่าคือเอาตัวอย่าง GRPO ของ Tunix ที่เทรน Gemma 3 1B บน GSM8K มาให้เอเจนต์จูนบน TPU v6e-1 รอบละราวสองชั่วโมง ราว 40 การทดลองในเวลา 2–3 วัน ตัวชี้วัดคือ Post_RL_metric = numerical accuracy + format accuracy (บวกกันตรง ๆ)

	numerical	format	รวม
baseline	49.22	87.50	136.72
ดีที่สุด	55.86	95.70	151.56
เปลี่ยนแปลง	+6.64	+8.20	+14.84 (~+10.9%)

บทความสรุปว่า “reward รวมดีขึ้นราว 10%” ซึ่งตรงกับตัวเลข แต่เมื่อแยกดูจะเห็นว่า กำไรกว่าครึ่งมาจากการตอบให้ถูกรูปแบบ ไม่ใช่การคิดเลขถูกขึ้น คะแนนทุกค่าในไฟล์เป็นทวีคูณของ 1/256 ชุดประเมินจึงน่าจะมี 256 ข้อ (เป็นการอนุมานของเรา) ส่วนที่ numerical accuracy เพิ่มขึ้นจึงเท่ากับตอบถูกเพิ่มราว 17 ข้อ

ข้อสังเกตอื่นจาก RL_results.tsv:

• หนึ่งในห้าก้าวที่ถูกเก็บ (จาก 43 การทดลองหลัง baseline ในไฟล์) คือ การเขียน system prompt ใหม่ ให้คิดทีละขั้น — เป็นการปรับ prompt ไม่ใช่ hyperparameter ของการเทรน
• รอบที่ได้ numerical accuracy สูงที่สุด (57.81) ถูกทิ้ง เพราะ format accuracy ตกลงจนคะแนนรวมไม่ชนะ การตั้งน้ำหนักของตัวชี้วัดจึงกำหนดทิศทางของเอเจนต์โดยตรง
• การตั้ง TOP_P=0.95 ทำให้ numerical accuracy ร่วงเหลือ 16.4% — เอเจนต์ถอยกลับได้เพราะลูปบังคับให้ reset

มุมมอง AI Curator

รูปแบบ program.md + ไฟล์เดียวที่แก้ได้ + results.tsv + git keep/reset เป็นแพตเทิร์นที่ดีและ ไม่ผูกกับสแตกของ Google ทีมไทยที่มี GPU ตัวเดียวเอาไปใช้กับ Claude Code หรือ Codex คู่กับ Unsloth หรือ TRL ได้ทันที จุดแข็งจริงคือความโปร่งใส — ทุกการทดลองมี commit และบรรทัดใน TSV ให้ย้อนดูได้ ต่างจากการจูนด้วยมือที่ผลหายไปกับ notebook

แต่ลูปแบบนี้มีกับดักทางสถิติที่บทความไม่ได้พูดถึง: เอเจนต์ เลือกผู้ชนะจากการรันครั้งเดียวบนชุดประเมินเดียวกับที่ใช้รายงานผล ในเคส SFT การเปลี่ยนแค่ seed=42 ทำให้คะแนนต่างจาก config เดิม 0.10 จุด ซึ่งพอ ๆ กับก้าว “keep” หลายก้าว (+0.10 ถึง +0.21) ส่วนหนึ่งของเส้นกราฟที่ไต่ขึ้นจึงอาจเป็นสัญญาณรบกวนที่ถูกคัดมาเก็บ (winner’s curse) ถ้าจะเอาไปใช้จริง ควรเพิ่มสามอย่างใน program.md: แยก test set ที่เอเจนต์ไม่เคยเห็น ไว้วัดตอนจบ, รัน config ที่ดีที่สุด 3 อันดับซ้ำด้วยหลาย seed ก่อนประกาศผล และตั้ง เกณฑ์ขั้นต่ำของการปรับปรุง ที่ต้องเกินระดับ noise ถึงจะนับว่าชนะ

อีกบทเรียนคือ เอเจนต์จะ optimize สิ่งที่คุณวัด ไม่ใช่สิ่งที่คุณตั้งใจ ตัวชี้วัดที่ให้ format กับความถูกต้องมีน้ำหนักเท่ากันทำให้ลูปนี้เก่งเรื่องจัดรูปแบบมากกว่าคิดเลข สำหรับงานภาษาไทยอย่าง function calling บนมือถือด้วยโมเดลจิ๋วอย่าง FunctionGemma 270M ต้องเตรียมชุดข้อมูลภาษาไทยเอง เพราะ mobile-actions เป็นภาษาอังกฤษ แต่ต้นทุนการลองลูปนี้กับโมเดลขนาดนี้ต่ำพอที่ทีมเล็กจะทดลองได้ในคืนเดียว — ขอแค่ออกแบบตัวชี้วัดให้ดีก่อนเข้านอน

แหล่งข่าว

• Google Developers Blog — Autonomous LLM post-training with Tunix on TPUs (11 ก.ย. 2026)
• windmaple/autofinetune — GitHub (program.md และ sample_runs)
• google/tunix — GitHub