How high should GPT-6 Astra's thinking go? Check the benchmarks first
A Thai long post advises against defaulting to Max thinking, suggesting users compare success rate, latency, and token use across thinking levels for the same task, and clean up prompts and Skills written for older models.
“ก่อนใช้ GPT-6 Astra ที่ Max/Ultra thinking ลองดู benchmark ก่อนว่าจริงๆงานเราใช้ขนาดนั้นไหม แล้วเช็กด้วยว่า prompt กับ Skills เก่าที่ใส่ไว้ยังช่วยงานอยู่ไหม ได้ปรับให้เหมาะกับ GPT-6 Astra หรือยัง ถ้าอ่านแล้วไม่แน่ใจ post นี้แหละคำตอบเลย !” ผมอยากชวนดูสองเรื่องนี้คู่กันครับ เราจำเป็นต้องเปิด thinking สูงสุดทุกงานไหม แล้วคำสั่งที่สะสมมาตั้งแต่โมเดลรุ่นก่อน ยังช่วยงานอยู่จริงหรือเปล่า บทความ Rethinking skills and prompts for GPT-6 Astra พูดถึงเรื่องหลังได้ตรงมาก เคยไม่อ่านไฟล์ก็สั่งให้อ่านทุกครั้ง เคยทำพังก็สั่งให้ตรวจซ้ำ เคยทำเกินก็สั่งให้ถามก่อนทุกอย่าง พอเปลี่ยนโมเดลแล้ว กติกาเหล่านี้ยังอยู่ครบ แต่เราได้กลับไปดูมันหรือยัง ═══════════════════ 📊 ดู benchmark ก่อน อย่าเพิ่งกดสุด - เวลาเทียบ ผมอยากให้ดูโมเดลเดียวกัน งานเดียวกัน แล้วแต่ละระดับ thinking ทำได้ต่างกันแค่ไหน ดูทั้งงานสำเร็จไหม รอนานแค่ไหน และใช้ token เท่าไร ไม่ใช่ดูแค่คะแนนสูงสุดตัวเดียว - ถ้างานนั้น High กับ Max ได้ผลใกล้กัน แต่ Max ใช้เวลาและ token เพิ่ม เราจำเป็นต้องเปิด Max ทุกครั้งไหม สำหรับผม ความต่างที่เพิ่มมาควรช่วยงานเราจริงๆ ถึงจะคุ้ม - แต่ถ้าตารางไม่ได้แยกระดับ thinking ก็ยังบอกไม่ได้ว่า High ใกล้ Max แค่ไหนนะ อย่าเอาคะแนนสูงสุดมาแทนทุกระดับ แล้วสุดท้ายต้องลองกับงานของเราเองด้วย ═══════════════════ ⚙️ งานส่วนใหญ่ ผมแนะนำให้ลอง Medium ก่อน แต่ถ้ากลัวแตกและไม่มีเวลาแก้ ก็ใช้ High เผื่อไว้ก่อนครับ - งานส่วนใหญ่ ผมอยากให้ลอง Medium ก่อน ถ้าทำได้ครบและผ่านสิ่งที่เราต้องการ ก็ใช้ต่อได้ ยังไม่ต้องขยับขึ้นเพียงเพราะมีระดับที่สูงกว่าให้เลือก - งานที่รู้ว่ายาก โดยเฉพาะโค้ดซับซ้อน หรือไม่มีเวลามานั่งไล่แก้หลายรอบ ผมแนะนำ High เผื่อไว้ก่อน แต่ก็ยังไม่จำเป็นต้องกระโดดไป Extra High หรือ Max ตั้งแต่แรก - งาน computer use ที่ให้ AI เปิดโปรแกรม กดปุ่ม ทำงานตามขั้นตอน ผมก็แนะนำให้เริ่ม Medium เหมือนกัน ถ้ายังเอาไม่อยู่ค่อยเพิ่ม แต่เช็กก่อนด้วยว่าติดเพราะคิดไม่พอ หรือข้อมูลไม่ครบและคำสั่งตีกัน นี่เป็นแนวทางที่ผมแนะนำนะ ไม่ได้แปลว่า Medium พอทุกงาน หรือเปิด High แล้วงานจะไม่มีทางแตก การตรวจงานยังต้องมีเหมือนเดิม ═══════════════════ 💰 อย่าใช้ token หมดไปกับการกดสุดทุกงาน - การคิดเพิ่มมีต้นทุน เอกสาร OpenAI อธิบายว่าระดับที่ต่ำลงเน้นความเร็วและใช้ token น้อยลง ส่วนใครใช้ API ต้องนับ reasoning tokens ที่เราไม่เห็นในคำตอบด้วย เพราะคิดค่าบริการเป็น output tokens - Max กับ Ultra ก็ทำงานต่างกัน คู่มือ Models อธิบายว่า Max ให้โมเดลคิดกับงานมากขึ้น ส่วน Ultra ใช้ subagents หรือผู้ช่วยย่อย แบ่งงานไปทำพร้อมกัน จึงเหมาะกับงานที่แยกเป็นส่วนๆ ได้จริง ไม่ใช่เห็นชื่อ Ultra แล้วต้องเลือกไว้ก่อน - ผมเลยอยากให้เก็บงบไว้กับจุดที่ยากจริงๆ ส่วนใครใช้ผ่านแอป ให้ดูเครดิตหรือโควตาของแพ็กเกจตัวเองด้วย อย่าเอาตัวเลข token ใน API ไปคิดแทนโควตาทุกแอปตรงๆ ═══════════════════ 🧩 Skills ไม่ต้องโหลดมาทุกชุดที่เจอ - ตามบทความ ชื่อกับคำอธิบายของ Skills จะเข้าไปอยู่ใน context ให้โมเดลเลือกว่าจะใช้ตัวไหน ยิ่งติดตั้งเยอะก็ยิ่งมีข้อมูลส่วนนี้ให้อ่าน และถ้ามากเกินพื้นที่ Codex จะเริ่มย่อคำอธิบาย ทำให้ข้อมูลที่ช่วยเลือกเหลือน้อยลง - บาง Skill เขียนคำอธิบายกว้างมาก เหมือนบอกว่า “ทำอะไรก็เรียกฉันก่อน” พอมีหลายตัวแย่งกันหรือสั่งคนละทาง โมเดลก็อาจหยิบคู่มือที่ไม่ได้ช่วยงานนั้นมาอ่านเพิ่ม - คำอธิบายควรสั้นและชัดว่าใช้เมื่อไหร่ เช่น Skill สำหรับย้ายโครงสร้างฐานข้อมูล ก็บอกว่าใช้ตอนย้ายโครงสร้างฐานข้อมูล ไม่ใช่แค่แตะฐานข้อมูลนิดเดียวก็ต้องเรียกทุกครั้ง ═══════════════════ 📚 ไฟล์หลักสั้นๆ ที่เหลือค่อยอ่านตอนใช้ - ถ้า Skill มีหลายวิธีทำงาน ให้ไฟล์หลักเป็นเหมือนสารบัญ บอกว่างานแบบนี้ไปอ่านไฟล์ไหน ใช้สคริปต์อะไร แล้วค่อยเปิดรายละเอียดตอนจำเป็น นี่คือ progressive disclosure ไม่ต้องบังคับให้อ่านทั้งเล่ม ทั้งที่งานนี้ใช้แค่บทเดียว - คู่มือที่ล็อกทุกขั้นก็ต้องกลับมาดูเหมือนกัน บทความชี้ว่าขั้นตอนที่เคยช่วยโมเดลรุ่นก่อน อาจบังคับ Astra มากเกินไป ลองบอกเป้าหมายกับข้อจำกัดให้ชัด แล้วเหลือพื้นที่ให้มันเลือกวิธีทำเองบ้าง - ผู้เขียนบอกว่าปรับคำแนะนำของ skill-creator แล้ว ทั้งเรื่องคำอธิบายและการแยกรายละเอียดไปอ่านเมื่อใช้ แต่ถ้าทีมยังใช้ Sol หรือ Luna ด้วย ก็คิดถึงคนอื่นก่อนแก้ Skills กลาง อย่าปรับทุกอย่างให้เหมาะกับโมเดลที่เราใช้คนเดียว ═══════════════════ 🗂️ แก้คำผิดนิดเดียว ไม่ต้องอ่านทั้งโปรเจกต์ก่อน - AGENTS . md เป็นอีกไฟล์ที่ควรกลับไปดู เพราะเป็นกติกาที่ใช้กับงานในโปรเจกต์ ถ้าแค่แก้คำผิด แต่ต้องอ่านเอกสารทุกชุดและทำแผนผังทั้งโปรเจกต์ก่อน งานเล็กก็กลายเป็นงานใหญ่ตั้งแต่ยังไม่ได้ลงมือ - เอกสารยังควรอ่าน แค่ชี้ให้ตรงงาน เช่น แก้ระบบล็อกอินก็อ่านคู่มือส่วนนั้น และอัปเดตให้ตรงกับระบบที่ใช้อยู่ ไม่ใช่ให้โมเดลทำตามคู่มือเก่าที่ไม่ตรงกับโค้ดแล้ว - ถ้ามันหยุดหรือเปลี่ยนทางเพราะคำสั่งเก่า ลองถามตรงๆ ว่า “ติดคำสั่งจากไฟล์ไหน ข้อไหน เขียนไว้แบบนั้นจริงๆ หรือเป็นสิ่งที่ตีความเอง” คู่มือ Astra ก็แนะนำให้ไล่หาคำสั่งที่ขัดกันแบบนี้ ═══════════════════ 🧪 ตรวจให้ตรงงาน ไม่ต้องวนซ้ำเผื่อไว้ - คู่มือ Astra บอกว่าโมเดลมีแนวโน้มตรวจงานโค้ดละเอียดอยู่แล้ว คำสั่งเก่าที่สั่งให้ทดสอบทุกอย่างซ้ำๆ จึงอาจทำให้ตรวจเกินงาน โดยเฉพาะการแก้จุดเล็กๆ - ไม่ได้แปลว่าให้เลิกทดสอบนะ ให้ตรวจสิ่งที่แก้และส่วนที่อาจได้รับผลกระทบให้ครบ ถ้าเจอปัญหาก็แก้แล้วตรวจซ้ำ แต่พอผ่านแล้ว ไม่มีอะไรเปลี่ยน และไม่มีข้อสงสัยค้างอยู่ ก็ไม่ต้องวนเรื่องเดิมไปเรื่อยๆ ═══════════════════ 🎯 อยากให้ทำจนจบ ก็บอกให้ชัดว่าจบตรงไหน - บทความบอกว่า Astra อาจทำรอบแรกเสร็จแล้วกลับมารอเรา ทั้งที่เราคาดหวังให้ทำต่อ โดยเฉพาะถ้ากติกาเก่ายังเขียนว่า “ทำรอบแรกแล้วหยุดให้รีวิวก่อน” มันก็อาจหยุดตามนั้นจริงๆ - ถ้าต้องการเว็บที่ใช้ได้ คำว่าเสร็จควรรวมถึงรันได้ เปิดดูหน้าจอ ลองกดใช้งาน และแก้สิ่งที่ยังพังด้วย แนบตัวอย่างที่อยากได้และบอกสิ่งที่ต้องผ่าน ไม่ใช่ให้มันเดาว่าเราต้องการแค่โค้ดหรือของที่ใช้งานได้จริง - แยกให้ชัดว่าอะไรทำต่อได้ อะไรต้องถาม เช่น ชุดทดสอบในเครื่องที่ยืนยันว่าใช้ข้อมูลทิ้งได้และไม่เชื่อมระบบจริง ให้รัน แก้ปัญหาจากงานนี้ แล้วตรวจซ้ำได้ ส่วนการเอาขึ้นระบบจริงค่อยหยุดรออนุมัติ ไม่ต้องใช้คำว่า “ถามก่อนทุกครั้ง” ครอบทุกอย่าง ตัวอย่าง prompt สำหรับงานเว็บในพื้นที่ทดสอบ เอาไปปรับตามงานได้เลย “ทำฟังก์ชันนี้ให้รันและใช้งานได้ตามโจทย์ อ่านไฟล์ที่เกี่ยวข้องให้พอเข้าใจ ลงมือทำ เปิดดูหน้าจอ ลองใช้งาน และทดสอบส่วนที่เกี่ยวข้อง ถ้าเจอปัญหาจากสิ่งที่แก้ ให้แก้ต่อแล้วตรวจซ้ำ อย่าหยุดแค่รอบแรกที่มีโค้ด เรื่องเล็กที่ไม่เปลี่ยนผลลัพธ์สำคัญให้ตัดสินใจแล้วบอกสมมติฐานไว้ ถ้าข้อมูลที่ขาดทำให้ผลลัพธ์เปลี่ยนมากให้ถาม ทำต่อได้ในพื้นที่ทดสอบที่ไม่เชื่อมระบบจริง แต่ห้ามเผยแพร่หรือแก้ระบบจริงก่อนอนุมัติ ก่อนส่งบอกว่าทำอะไรแล้ว ตรวจอะไรผ่าน และยังติดอะไรอยู่” ═══════════════════ 🧹 ให้ Astra ช่วยตรวจ prompt เก่าได้เลย - ให้มันไล่ดู Skills, AGENTS . md และ prompt ที่ใช้ประจำ ว่ามีอะไรซ้ำ ตีกัน บังคับอ่านเกินงาน หรือทำให้หยุดก่อนจบ แล้วเสนอข้อความเดิมกับข้อความที่อยากแก้ให้เราดูก่อน กติกาสำคัญกับจุดที่ต้องขออนุมัติยังต้องอยู่ - หลังปรับ ลองกับงานตัวอย่างเดิม ดูทั้งงานผ่านไหม เร็วขึ้นไหม และใช้ token เท่าไร คำสั่งสั้นลงอย่างเดียวไม่ได้แปลว่าดีขึ้น ต้องดูผลงานด้วย - นี่คือการตรวจชุดคำสั่งตอนปรับโปรเจกต์นะ ไม่ใช่เพิ่มกฎใหม่ว่า “ก่อนทำทุกงานต้องตรวจ Skills ทั้งหมด” ไม่อย่างนั้นก็วนกลับไปปัญหาเดิม ตัวอย่าง prompt สำหรับเริ่มตรวจ “ช่วยตรวจ Skills, AGENTS . md และ prompt ในโปรเจกต์นี้ ว่ามีอะไรซ้ำ ตีกัน เขียนกว้างเกินไป บังคับให้อ่านหรือทดสอบเกินงาน หรือทำให้หยุดก่อนงานเสร็จ เสนอว่าจะปรับให้เหมาะกับ GPT-6 Astra ยังไง คำอธิบาย Skill ให้สั้นและชัดว่าใช้เมื่อไหร่ รายละเอียดที่ใช้เฉพาะบางงานให้แยกไปอ่านตอนจำเป็น เก็บกติกาสำคัญกับจุดที่ต้องขออนุมัติไว้ และคิดถึงโมเดลอื่นที่ทีมใช้ด้วย แสดงข้อความเดิมกับข้อความที่เสนอแก้พร้อมเหตุผลก่อน ยังไม่ต้องแก้ไฟล์” ═══════════════════ 💭 ในมุมมองส่วนตัวของผม ผมอยากให้เราใช้ thinking ตามงานจริงๆ Medium ทำได้ก็ใช้ Medium งานยากหรือกลัวแตกและไม่มีเวลาแก้ก็เริ่ม High ส่วนระดับที่สูงกว่านั้น เก็บไว้ใช้ตอนที่ช่วยให้งานดีขึ้นจริงๆ แล้วเวลาเปลี่ยนโมเดล อย่าลืมกลับมาอ่าน prompt กับ Skills ของตัวเองด้วย ข้อไหนยังช่วยก็เก็บไว้ ข้อไหนขวางงานก็ปรับ บอกให้ชัดว่าอยากได้อะไร ทำต่อได้ถึงไหน และแบบไหนถึงเรียกว่าเสร็จ ผมอยากเอา token ไปใช้แก้ปัญหาของงาน มากกว่าให้ AI อ่านกติกาซ้ำ ตรวจเรื่องเดิมวนไป หรือหยุดถามในสิ่งที่เราอนุญาตแล้วครับ