"คอมไพล์ด้วยการเทรน" — เขียนสเปกภาษาอังกฤษหนึ่งย่อหน้า ได้ฟังก์ชันที่รันบน Qwen3-0.6B ในเครื่องตัวเอง แม่น 83.6% ใช้เวลาคอมไพล์ 51 วินาที แต่การพึ่งพาผู้ให้บริการไม่ได้หายไป มันย้ายไปอยู่ที่ build time

เมื่อ 3 กันยายน 2026 Yuntian Deng และ Pengyu Nie (University of Waterloo) กับ Stuart Shieber (Harvard University) เผยแพร่ arXiv:2609.04199 ภายใต้สัญญาอนุญาต CC BY 4.0 — งานที่ผ่านการรับเข้า EMNLP 2026 System Demonstrations เสนอแนวคิดชื่อ compile by training: เขียนสเปกของฟังก์ชันเป็นภาษาอังกฤษ แล้วได้ไฟล์อาร์ติแฟกต์ที่เก็บ เวอร์ชัน แคช และรันในเครื่องตัวเองได้เหมือนโค้ดธรรมดา

ปัญหาที่เปเปอร์ตั้งไว้เป็นปัญหาที่คนสร้างระบบจริงเจอทุกวัน ตัวอย่างที่เปเปอร์ยกคือฟังก์ชันคัดกรองอีเมลที่แม็ป “Signature needed by EOD” เป็น immediate แต่แม็ปจดหมายข่าวเป็น wait — พฤติกรรมที่อธิบายง่ายแต่เขียนเป็นกฎยาก และเรียกใช้บ่อยจนการยิง API ไปหาโมเดลใหญ่ทุกครั้งไม่คุ้ม เปเปอร์เรียกงานประเภทนี้ว่างานที่ “เบลอเกินกว่าจะเขียนเป็นโค้ดปกติ แต่แคบและถี่เกินกว่าจะเรียกโมเดลใหญ่ทุกครั้ง”

กลไก: เทรนเนอร์ตอนคอมไพล์ ไม่ใช่ตอนรัน

ระบบเปิดอินเทอร์เฟซแค่สองตัว — Compile(s) รับสเปก s คืนโปรแกรม และ Run(p, x) รันโปรแกรมกับอินพุตใหม่ ภายในแบ่งเป็นสองขั้น

ขั้น	สิ่งที่เกิดขึ้น
1. สังเคราะห์ supervision	โมเดลครู (teacher) สร้างคู่ input/output จากสเปก ส่งกลับเป็น JSON แบบมีโครงสร้าง คอมไพเลอร์ตรวจแล้วปฏิเสธแบตช์ที่ผิดรูปทิ้งก่อนส่งเข้าเทรนเนอร์
2. เทรนและแพ็ก	เทรน LoRA rank 64, alpha 16 บนอินเทอร์พรีเตอร์ Qwen3-0.6B ที่ควอนไทซ์และแช่แข็งไว้ โดยตั้งต้นจากอะแดปเตอร์ที่คอมไพเลอร์เร็วของ PAW ทำนายมาให้ แล้วเทรน 100 สเต็ปด้วย cosine schedule, batch 48

ผลลัพธ์คือไฟล์ .paw ที่ห่อสเปกเดิม อะแดปเตอร์ สแคฟโฟลด์ (เทมเพลตพรอมป์ที่คอมไพเลอร์สร้าง) และเมทาดาทาของอินเทอร์พรีเตอร์เข้าด้วยกัน ทุกฟังก์ชันใช้อินเทอร์พรีเตอร์ตัวเดียวกัน — ที่ต่างกันคืออะแดปเตอร์ ซึ่งเป็นเหตุผลว่าทำไมโมเดลจึงเล็กแค่ 0.6B แล้วยังใช้งานได้หลายฟังก์ชันพร้อมกัน

จุดที่ต้องอ่านให้ชัด: เปเปอร์เขียนเองว่า “การคอมไพล์เป็นกระบวนการที่โฮสต์ไว้: สเปกของฟังก์ชันถูกส่งไปยังบริการ PAW และ API ของโมเดลครูเพื่อสร้าง supervision และเทรนโปรแกรม” — ส่วนที่รับประกันคือ “การรันผ่าน SDK ในเครื่องไม่ส่งอินพุตในอนาคตไปยัง PAW หรือโมเดลครู” ความเป็นส่วนตัวจึงครอบคลุมข้อมูลตอนรัน ไม่ใช่สเปกตอนสร้าง

ตัวเลข: 22.4% → 83.6% แต่บนสนามที่ถูกเลือกมาแล้ว

เปเปอร์วัดด้วยเมตริก LEM (LLM Exact Match) เพราะงานหลายอย่างมีคำตอบถูกได้หลายแบบ (JSON ที่เรียงคีย์ต่างกันแต่ค่าเท่ากันไม่ควรนับว่าผิด) ผู้ตัดสินเป็น GPT-5.5 ซึ่งวัดแล้วได้ความแม่น 0.977 และ Cohen’s κ = 0.946 เทียบกับป้ายกำกับ 128 ชิ้นที่ผู้เขียนติดเอง

คอมไพเลอร์	LEM บน FuzzyBench-Hard	เวลาคอมไพล์
PAW fast (amortized, forward pass เดียว)	0.224	3.5 วินาที
Compile by training	0.836	50.9 วินาที (B300)

ต้องอ่านเชิงอรรถให้ครบ: FuzzyBench-Hard คือซับเซตที่คัดมาจากข้อที่คอมไพเลอร์เร็วทำ exact match ไม่ได้เลยสักข้อ เส้นฐาน 0.224 จึงเป็นค่าที่ถูกกดให้อยู่ใกล้พื้นตั้งแต่นิยามของชุดทดสอบ ไม่ใช่ผลการวัดบน FuzzyBench เต็มชุด ส่วนต่าง 61.2 จุดเป็นเรื่องจริง แต่มันคือ “เมื่อคอมไพเลอร์เร็วล้ม การลงทุนเวลาเพิ่มช่วยได้แค่ไหน” ไม่ใช่ “ดีกว่ากันเท่าไรโดยรวม”

เวลาคอมไพล์ขึ้นกับการ์ด — 50.9 วินาทีบน B300, 68.2 วินาทีบน H200 และ 99.2 วินาทีบน RTX ในเทสต์โหลดที่ยิงงานคอมไพล์พร้อมกันสี่งาน ทั้งสี่งานเสร็จโดยมีเวลารอคิวเฉลี่ย 1.01 วินาที

ตารางที่น่าสนใจกว่าพาดหัวคือ sweep ของ supervision

การทดลอง	ค่าที่ตั้ง	LEM
ส่วนผสมครู	GPT-5.4-mini ล้วน (3600/0)	0.746
ส่วนผสมครู	2:1 mini/GPT-5.5 (2400/1200)	0.851
สเกลข้อมูล	1,440 คู่	0.821
สเกลข้อมูล	2,400 คู่	0.836
สเกลข้อมูล	3,600 คู่	0.836
สเกลข้อมูล	7,200 คู่	0.866

สองแถวกลางบอกว่าเพิ่มข้อมูลจาก 2,400 เป็น 3,600 คู่ ไม่ได้อะไรเลย (0.836 เท่าเดิม) แล้วค่อยขยับเป็น 0.866 ที่ 7,200 คู่ — และคอนฟิกที่เปิดให้ใช้จริงตั้งไว้ที่ 2,400 คู่ คือจุดที่ถูกที่สุดที่ยังได้ 0.836 ไม่ใช่จุดที่แม่นที่สุดที่วัดได้

เดโมสามตัวที่ตอบคำถามว่า “แล้วเอาไปประกอบเป็นระบบได้จริงไหม”

• paw-helper — ผู้ช่วยเว็บไซต์ที่ deploy จริง แพ็กเนื้อหามี โปรแกรมที่คอมไพล์แล้ว 30 ตัว ใช้ในเราติ้งจริง 28 ตัว และแบ็กเอนด์เดียวเสิร์ฟสี่เว็บ (เว็บส่วนตัวของผู้เขียน, วิชา CS 486 ที่ Waterloo, NeuralOS และเว็บ PAW) เมื่อนักศึกษาถามว่า “Assignment 1 เปลี่ยนอะไรบ้าง” ฟังก์ชันหนึ่งตัดสินก่อนว่าควรตอบเป็นลิงก์หรือคำตอบเขียน อีกตัวร่างคำตอบจากหน้าเว็บวิชา ขณะที่ BM25 ธรรมดาค้น Piazza ขนานกัน แล้วฟังก์ชันสุดท้ายตัดสินว่าจะคืนคำตอบไหน — เปเปอร์สรุปการแบ่งงานไว้ตรง ๆ ว่า “ฟังก์ชันที่คอมไพล์แล้วตัดสินใจเรื่องเบลอ ส่วนโค้ดธรรมดาจัดการงานที่ต้องเป๊ะ เช่น การค้นคืน การแคช และการคุมสาขา” (MIT, GitHub)
• Avatar Director — สั่งตัวละคร 3D ด้วยภาษาพูด (“jump twice, then dance”) โดยโปรแกรม PAW แปลงเป็น DSL เล็ก ๆ ที่เบราว์เซอร์ตรวจและรันเอง จากคำสั่งตรวจสอบที่เขียนด้วยมือ 44 ข้อ ได้โครงสร้างแอ็กชันตามที่คาด 43 ข้อ
• ตัวแปล English ↔ Claudish — “Claudish” คือชื่อเล่นที่ชุมชนตั้งให้สำนวนเฉพาะตัวของ Claude Code (ชอบวางคู่ตรงข้าม ชอบอุปมาเรื่อง gates, boundaries, load-bearing และคำประสมแบบ X-shaped, X-gated) ทีมเขียนสเปกทิศทางละหนึ่งย่อหน้า คอมไพล์เป็นอะแดปเตอร์ทิศทางละตัวบนอินเทอร์พรีเตอร์ 0.6B ตัวเดียวกัน แล้วเปิดบริการแปลสองทาง — ระหว่าง 22 ส.ค. ถึง 2 ก.ย. 2026 ให้บริการแปลสำเร็จ 100,747 ครั้ง (MIT, GitHub)

สิ่งที่พาดหัวข้ามไป

หนึ่ง — การพึ่งพาผู้ให้บริการไม่ได้หายไป มันย้ายที่ พาดหัวคือ “รันในเครื่อง ไม่ต้องเรียกโมเดลใหญ่” ซึ่งจริงตอนรัน แต่ตอนคอมไพล์ สเปกของคุณถูกส่งไปที่บริการ PAW และครูคือ GPT-5.4-mini กับ GPT-5.5 ถ้าบริการปิด ราคาครูขึ้น หรือสเปกของคุณเป็นความลับทางธุรกิจ เงื่อนไขเปลี่ยนทันที สิ่งที่เปลี่ยนไปจริง ๆ คือความถี่ของการพึ่งพา — จากทุกคำขอ เหลือครั้งเดียวต่อการ build ซึ่งก็มีค่ามาก แต่ไม่ใช่ศูนย์

สอง — มันคือการกลั่นโมเดลปิดลงในโมเดลเปิด ไปป์ไลน์นี้คือการเอาผลลัพธ์จากโมเดล OpenAI มาเทรนอะแดปเตอร์บน Qwen3-0.6B แล้วแจกจ่ายไฟล์นั้น เปเปอร์ไม่ได้พูดถึงข้อกำหนดการใช้งานของโมเดลครู ซึ่งเป็นคำถามที่ทีมองค์กรต้องตอบเองก่อนเอาเข้าโปรดักชัน

สาม — ผู้เขียนเตือนเรื่องความถูกต้องไว้เอง ในหัวข้อข้อจำกัด: “supervision สังเคราะห์อาจสืบทอดข้อผิดพลาดของครู แอปพลิเคชันที่ต้องการความถูกต้องแบบรับประกันควรตรวจสอบเอาต์พุตหรือคงเส้นทางควบคุมแบบกำหนดแน่นอนไว้” และยอมรับว่ายังไม่มีการศึกษาผู้ใช้อย่างเป็นระบบ

สี่ — ตัวเลข 83.6% ถูกให้คะแนนโดย LLM ผู้ตัดสินคือ GPT-5.5 ซึ่งเป็นหนึ่งในครูที่สร้างข้อมูลเทรนด้วย เปเปอร์วัดความน่าเชื่อถือของผู้ตัดสินไว้เทียบกับ 128 ตัวอย่างที่ติดป้ายเอง ซึ่งถือว่าทำการบ้านมากกว่างานส่วนใหญ่ — แต่ก็ยังเป็นตัวเลขที่ต้องอ่านคู่กับงานตรวจสอบความเสถียรของผู้ตัดสิน LLM ที่เราเขียนวันนี้ ซึ่งพบว่าคำขอเดิมทุกไบต์ให้ผลไม่เท่ากันข้ามวัน

มุมมอง AI Curator

สิ่งที่เปเปอร์นี้ทำได้ดีจริงไม่ใช่ตัวเลข 83.6% แต่คือการย้ายการปรับแต่งโมเดลจาก “สิ่งที่ทำตอนรัน” ไปเป็น “ขั้นตอนหนึ่งของการ build” ประโยคที่คมที่สุดในเปเปอร์คือ “โมเดลภาษาขนาดใหญ่ทำหน้าที่เป็นผู้สร้างเครื่องมือ ไม่ใช่สิ่งที่ต้องพึ่งพาตอนรัน” — เพราะเมื่ออะแดปเตอร์กลายเป็นอาร์ติแฟกต์ที่เก็บลง Git ได้ ทุกอย่างที่วิศวกรรมซอฟต์แวร์มีอยู่แล้วก็ตามมาฟรี ๆ: pin เวอร์ชันได้ rollback ได้ diff ได้ รันใน CI ได้ ทดสอบซ้ำได้ผลเดิม นี่คือสิ่งที่พรอมป์ในไฟล์ config ไม่เคยให้เรา

แต่คนที่จะเอาไปใช้ควรนับต้นทุนให้ครบ paw-helper ต้องใช้โปรแกรม 30 ตัวเพื่อทำผู้ช่วยเว็บหนึ่งตัว นั่นแปลว่า 30 อาร์ติแฟกต์ที่ต้องเวอร์ชัน 30 ชุดที่ต้องรีคอมไพล์เมื่อสเปกเปลี่ยน และ 30 จุดที่คุณภาพอาจถดถอยเงียบ ๆ เมื่อครูเปลี่ยนรุ่น การจัดการอะแดปเตอร์จำนวนมากคือปัญหา MLOps ที่ยังไม่มีใครแก้ให้เรียบร้อย — และมันจะเป็นงานจริงที่ทีมต้องทำ ไม่ใช่ผลข้างเคียงที่มองข้ามได้

สำหรับบริบทไทยและอาเซียน ตรรกะทางเศรษฐศาสตร์ของงานนี้ตรงกับเงื่อนไขในภูมิภาคมาก งานที่ทีมไทยทำถี่ที่สุดมักเป็นงานประเภทนี้พอดี — จัดหมวดข้อความจากลูกค้า สกัดฟิลด์จากใบเสร็จ ตัดสินว่าคำร้องนี้ควรเข้าคิวไหน — งานที่แต่ละครั้งใช้โทเคนน้อยแต่ทำวันละหลายหมื่นครั้ง ถ้าอินเทอร์พรีเตอร์เป็นโมเดล 0.6B ก็รันบนซีพียูหรือการ์ดใบเล็กในดาต้าเซ็นเตอร์ในประเทศได้ ซึ่งตอบทั้งเรื่องค่า egress ค่าเงินบาทต่อดอลลาร์ และข้อกำหนด PDPA ที่ห้ามส่งข้อมูลลูกค้าออกนอกระบบไปพร้อมกัน

ข้อควรระวังคือ Qwen3-0.6B เห็นภาษาไทยมาน้อยกว่าภาษาอังกฤษมาก และเปเปอร์นี้ทดสอบเป็นภาษาอังกฤษล้วน ใครจะลองควรวัด LEM ของตัวเองบนงานภาษาไทยจริงก่อนตัดสินใจ ไม่ใช่ยืมตัวเลข 83.6% มาใช้ตรง ๆ — แต่แนวคิดที่ว่า “จ้างโมเดลใหญ่ครั้งเดียวเพื่อสร้างเครื่องมือ แทนที่จะจ้างมันทุกครั้งที่ใช้เครื่องมือ” เป็นสิ่งที่คุ้มค่าทดลองกับงานที่คุณเรียก API ซ้ำ ๆ อยู่ตอนนี้

แหล่งข่าว

• arXiv:2609.04199 — Compile by Training: Turning Natural-Language Specifications into Local Neural Functions
• เดโมสาธารณะ — programasweights.com
• programasweights/claudish — ตัวแปล English ↔ Claudish (MIT)
• programasweights/paw-helper — ผู้ช่วยเว็บไซต์ที่ประกอบจากโปรแกรม 30 ตัว (MIT)