Microsoft วัดเอง: GPT-6 Astra แพงกว่า Claude Sonnet 4.6 ถึง 5.3 เท่าแล้วได้คะแนนต่ำกว่า — และ "สกิล" ที่ใส่เข้าไปคือสิ่งที่พลิกผลว่าโมเดลไหนชนะ

วันที่ 9 กันยายน 2026 Waldek Mastykarz เผยแพร่บทความบนบล็อกนักพัฒนาของ Microsoft ชื่อ “Your work might not need the smartest model” ที่ไม่ได้เป็นบทความความเห็นลอย ๆ แต่แนบผลวัดจริงพร้อมต้นทุนต่อรันเป็นดอลลาร์ คำถามที่เขาตั้งไว้ตรงไปตรงมา: พอ GPT-6 Astra ออกมา หลายทีมตั้งเป็นค่าเริ่มต้นทันทีแล้วคาดว่าจะได้ผลดีที่สุดทุกครั้ง — ความคาดหวังนั้นควรถูกทดสอบ เพราะส่วนที่ดีขึ้นต้องคุ้มกับส่วนที่จ่ายเพิ่ม

สิ่งที่ทำให้บทความนี้ต่างจากบทวิเคราะห์ทั่วไปคือ Microsoft ยอมพิมพ์ตัวเลขที่ทำให้โมเดลของพันธมิตรตัวเองดูไม่คุ้มในสองในสามเคส และยอมเปิดวิธีวัดให้ตรวจสอบได้ว่าเป็นการวัดในสภาพแวดล้อมแบบไหน

ตัวเลข: สามเคส ห้ารันต่อโปรไฟล์

การทดลองเทียบ GPT-6 Astra กับ Claude Sonnet 4.6 ซึ่งบทความเรียกว่า “โมเดลที่ใช้กันทั่วไป” โดยรันทั้งคู่ใน GitHub Copilot Chat บน Visual Studio Code บน Windows ด้วยการตั้งค่าสถานการณ์เดียวกัน และรันโปรไฟล์ละห้าครั้ง ต้นทุนต่อรันคำนวณจากราคา GitHub Copilot ณ เวลาที่เขียน ส่วนคะแนนคุณภาพเป็นค่าที่ปัดแล้ว:

งาน	Claude Sonnet 4.6	GPT-6 Astra	ผล
อัปเกรด JDK 8 → JDK 25 (ใส่สกิล migration ตัวเดียวกัน)	97% ที่ $12.71/รัน	93% ที่ $67.33/รัน	ต่ำกว่าราว 4 จุด ที่ต้นทุน 5.3 เท่า
อัปเกรด SPFx เป็น v1.22.0 (คำสั่ง CLI เดียวกัน)	98% ที่ $1.03/รัน	98% ที่ $2.49/รัน	คะแนนปัดแล้วเท่ากัน ที่ต้นทุน 2.4 เท่า
อัปเกรด SPFx v1.21.1 → v1.22.2 (ใส่สกิล SPFx ตัวเดียวกัน)	98% ที่ $0.92/รัน	99% ที่ $5.14/รัน	สูงกว่าราว 1 จุด ที่ต้นทุน 5.6 เท่า

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

ส่วนที่สำคัญกว่าตาราง: สกิลเป็นตัวพลิกผล

ย่อหน้าที่ควรอ่านซ้ำที่สุดอยู่ถัดจากตาราง เพราะมันเปลี่ยนความหมายของทั้งตาราง — เมื่อรันเคส JDK โดยไม่ใส่ extension เพิ่ม ผลออกมาต่างไปคนละเรื่อง:

Astra ได้ 93% เทียบกับ Sonnet ที่ 76% ที่ต้นทุน $8.59 เทียบ $1.68 ต่อรัน

นั่นคือในสภาพเปล่า ๆ Astra นำอยู่ 17 จุด แต่พอใส่สกิล migration เข้าไปให้ทั้งคู่ Sonnet กระโดดจาก 76% ไป 97% ขณะที่ Astra ขยับจาก 93% ไปเพียง 93% — ลำดับกลับหัว และต้นทุนของทั้งคู่พุ่งขึ้นพร้อมกัน (Astra จาก $8.59 เป็น $67.33) บทความสรุปประเด็นนี้ไว้ว่า “คำแนะนำที่ทีมคุณใช้ต้องถูกประเมินไปพร้อมกับตัวโมเดล”

แปลเป็นภาษานักพัฒนา: การเลือกโมเดลกับการเขียนสกิลไม่ใช่สองการตัดสินใจที่แยกกัน ผลลัพธ์ที่คุณเห็นคือผลของคู่ (โมเดล × สกิล) และการเปรียบเทียบโมเดลที่ไม่ระบุว่าใส่สกิลอะไรเข้าไปด้วยนั้นแทบไม่มีความหมาย นี่ยังสอดคล้องกับสิ่งที่บล็อกนี้เคยรายงานจากการทดลองของ Dan Luu เมื่อ 7 ก.ย. ที่พบว่าสกิลทางการของบริษัทสองชุดทำให้ผลแย่ลงทั้งคู่ — สกิลมีผลจริง แต่ทิศทางของผลไม่ได้เป็นบวกเสมอไป

ข้อจำกัดที่บทความระบุเอง

บทความไม่ได้ขายผลนี้เกินตัว และระบุข้อจำกัดไว้ครบ ซึ่งควรอ่านคู่กับตารางเสมอ:

• ห้ารันต่อโปรไฟล์คือ “มุมมองเบื้องต้น” ผู้เขียนบอกเองว่าการจะยืนยันว่าความต่างระดับหนึ่งจุดเชื่อถือได้จริงต้องประเมินเพิ่มอีก
• คะแนนรวมไม่เท่ากับความเสี่ยง — คะแนนคุณภาพรวมวัดผลเทียบเกณฑ์ที่ตั้งไว้ ส่วนการประเมินความเสี่ยงว่าเอเจนต์จะทำอะไรที่ทำลายของต้องใช้หลักฐานเฉพาะเรื่องความล้มเหลวนั้น ๆ และงานที่มีผลกระทบสูงต้องมีมนุษย์อนุมัติประกอบ
• สภาพแวดล้อมมีผล — ระบบปฏิบัติการหรือการตั้งค่าเอเจนต์ที่ต่างกันเปลี่ยนผลได้ ทั้งหมดนี้วัดบน Windows ใน VS Code ผ่าน Copilot Chat จึงไม่ใช่ผลที่ย้ายไปใช้กับ CLI หรือ IDE อื่นได้ทันที
• เบนช์มาร์กสาธารณะวัดชุดงานของมันเอง ในสภาพแวดล้อมของมันเอง รีโปและชุดเอเจนต์ของคุณให้ผลต่างออกไปได้

คำแนะนำเชิงกระบวนการที่บทความให้คือให้ตั้งเกณฑ์ก่อนรัน ว่าโมเดลต้องทำอะไรให้ถูกและทีมรับความล้มเหลวได้แค่ไหน เพื่อจะได้ตัดสินผลโดยไม่ถูกอคติที่มีต่อโมเดลตัวโปรดครอบงำ จากนั้นจึงหา “minimal viable model” คือโมเดลที่ถูกที่สุดที่ยังผ่านเกณฑ์ และมีอีกสองข้อที่ปฏิบัติได้จริง: ถ้าโมเดลห้าตัวชนะคนละงานแต่ต่างกันน้อยมาก การจ่ายเพิ่ม $0.02 ต่องานเพื่อใช้ตัวเดียวทั้งหมดอาจคุ้มกว่า เพราะได้เวิร์กโฟลว์เดียวที่คาดเดาได้ และคำตอบที่ได้ “มีวันหมดอายุ” — อัปเดตเอเจนต์ ส่วนขยายใหม่ หรือราคาที่เปลี่ยน ทำให้การตัดสินใจของเดือนที่แล้วกลายเป็นการจ่ายแพงเกินจำเป็นได้

มุมมอง AI Curator

ค่าที่แท้จริงของบทความนี้ไม่ได้อยู่ที่ “Sonnet ชนะ Astra” — ห้ารันต่อโปรไฟล์บนสามงานอัปเกรดโค้ดยืนยันอะไรระดับนั้นไม่ได้ และผู้เขียนก็บอกเองแล้ว ค่าที่แท้จริงอยู่ที่ตัวเลขต้นทุนที่พิมพ์ออกมาเป็นดอลลาร์ต่อรัน เพราะมันคือสิ่งที่หายไปจากบทสนทนาเรื่องโมเดลเกือบทั้งหมด เราคุ้นกับการเทียบคะแนนบน SWE-bench หรือ Terminal-Bench โดยไม่มีช่องราคาข้างกัน พอเห็น $67.33 ต่อการอัปเกรด JDK หนึ่งครั้ง วางข้าง $12.71 ที่ให้คะแนนสูงกว่า คำถามก็เปลี่ยนจาก “โมเดลไหนเก่งสุด” เป็น “งานนี้คุ้มจ่ายเท่าไร” ซึ่งเป็นคำถามที่ถูกกว่า

สำหรับทีมไทยและอาเซียน ความต่าง 5 เท่านี้ไม่ได้แปลเป็นตัวเลขเดียวกับทีมที่ซานฟรานซิสโก เพราะราคาต่อโทเคนตั้งเป็นดอลลาร์เท่ากันทั่วโลกในขณะที่งบทีมและรายได้ต่อหัวไม่เท่ากัน งานอัปเกรดที่ทีมอเมริกันมองว่า “จ่าย $67 แล้วจบก็ถูกกว่าจ้างคน” อาจเป็นการตัดสินใจคนละแบบเมื่อคิดเป็นเงินบาทเทียบกับค่าแรงวิศวกรในกรุงเทพฯ ข้อดีคือวิธีที่บทความเสนอนั้นทำตามได้เลยและแทบไม่มีต้นทุน: เก็บสถานการณ์ตัวแทนของทีมไว้สักสามถึงห้าเคส กำหนดเกณฑ์ผ่านให้ชัดก่อนรัน แล้ววัดซ้ำทุกครั้งที่โมเดล เอเจนต์ หรือราคาขยับ — ถ้าตอบได้ว่างานประจำของทีมต้องการโมเดลระดับไหนจริง ๆ คุณก็เลิกจ่ายค่าโมเดลแนวหน้าให้กับงานที่โมเดลชั้นกลางทำได้เท่ากัน

ประเด็นที่ควรจำไปใช้มากที่สุดคือเรื่องที่ สกิลเป็นตัวพลิกลำดับ ตอนนี้แทบทุกทีมกำลังสะสม AGENTS.md, instruction files และ skill ต่าง ๆ กันคนละกอง โดยสมมติเงียบ ๆ ว่ามันช่วยเสมอและช่วยทุกโมเดลเท่ากัน ผลของ Microsoft บอกว่าไม่ใช่ทั้งสองข้อ: สกิลเดียวกันดัน Sonnet ขึ้น 21 จุดแต่ไม่ขยับ Astra เลย และดันต้นทุนของทั้งคู่ขึ้นพร้อมกัน แปลว่าคำแนะนำที่คุณเขียนอาจกำลังอุดหนุนโมเดลตัวหนึ่งอยู่โดยที่คุณไม่รู้ตัว ถ้าจะเปลี่ยนโมเดลเริ่มต้นของทีมเมื่อไร ต้องวัดใหม่ทั้งคู่พร้อมสกิลชุดปัจจุบัน ไม่ใช่ย้ายค่าเริ่มต้นแล้วคาดว่าของเดิมจะทำงานเหมือนเดิม

แหล่งข่าว

• Your work might not need the smartest model — Waldek Mastykarz, Microsoft for Developers (9 ก.ย. 2026)
• Microsoft for Developers — บล็อกนักพัฒนาต้นทาง
• ผลทดลองของ Dan Luu ที่พบว่าสกิลทางการทำให้ผลแย่ลง (บล็อกนี้ 8 ก.ย. 2026)