ทีมที่สร้างเอเจนต์เขียนโค้ดซึ่งต้องวางแผนและเรียกเครื่องมือหลายขั้น มักติดอยู่ระหว่างสองตัวเลือก

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

Gemini 3.7 Flash พยายามเข้ามาอยู่ตรงกลางช่องว่างนี้ ณ ตอนเปิดตัว Google เรียกมันว่าโมเดลตัวหลักหรือเครื่องทำงานประจำของระบบ (workhorse model) ที่ฉลาดที่สุดของบริษัทจนถึงเวลานั้นสำหรับงานเขียนโค้ดและเอเจนต์ หมายถึงโมเดลที่รับงานส่วนใหญ่ได้ทุกวัน โดยไม่ต้องส่งทุกคำขอไปหาโมเดลระดับบนสุด

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

รอบนี้ Flash ไม่ได้แปลว่าคิดตื้น

Google เปิดตัว 3.7 Flash หลัง 3.6 Flash เพียงสามสัปดาห์ โดยระบุว่าโมเดลพัฒนาต่อจากรุ่นก่อนด้วยการปรับอัลกอริทึมเพื่อเสริมความสามารถด้านการให้เหตุผล

Model Card ระบุจุดที่มีผลต่อการออกแบบระบบไว้ชัดเจนสามอย่าง

• รับข้อความ รูปภาพ เสียง และวิดีโอ
• รับบริบทยาวสูงสุด 1 ล้านโทเค็น และส่งข้อความออกได้สูงสุด 64K โทเค็น
• ปรับระดับการคิดตามจุดสมดุลระหว่างคุณภาพ ต้นทุน และเวลารอได้

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

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

คะแนนที่ดีขึ้นอยู่ในโจทย์ของเอเจนต์

คะแนนชุดทดสอบ (benchmark) ที่ Google เผยแพร่ชี้ว่า 3.7 Flash ดีขึ้นจาก 3.6 Flash หลายจุดที่เกี่ยวกับการเขียนโค้ดและเดินงานหลายขั้น

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

เมื่อนำคะแนนเหล่านี้มามองร่วมกัน ภาพที่ Google นำเสนอไม่ได้หยุดอยู่ที่การเติมโค้ด แต่ขยับจาก “ตอบคำถามเขียนโปรแกรม” ไปหา “รับเป้าหมายแล้วทำงานผ่านเครื่องมือ”

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

อย่างไรก็ตาม 3.7 Flash ไม่ได้ชนะทุกตาราง ใน CharXiv Reasoning แบบไม่ใช้เครื่องมือ รุ่นใหม่ได้ 84.5% เทียบกับ 85.2% ของ 3.6 Flash และเมื่อนับการใช้เครื่องมือได้ 88.7% เทียบกับ 89.4% ส่วน DeepSWE และ Terminal-bench บางชุดยังตาม GPT-5.6 Terra ในตารางเปรียบเทียบของ Google

ดังนั้นคำว่า “โมเดลตัวหลัก” ไม่ได้แปลว่า “โมเดลที่เก่งที่สุดทุกงาน” แต่หมายถึงโมเดลที่สมดุลพอจะรับปริมาณงานส่วนใหญ่ ส่วนทีมต้องกำหนดเกณฑ์ให้ระบบส่งงานที่ยากหรือเสี่ยงเกินขอบเขตไปยังโมเดลอื่นหรือให้คนตรวจ

ราคาต่อโทเค็นต่ำ แต่ต้องดูจำนวนรอบด้วย

ราคาแนะนำช่วงเปิดตัวอยู่ที่ 0.75 ดอลลาร์ต่ออินพุต 1 ล้านโทเค็น และ 3.75 ดอลลาร์ต่อเอาต์พุต 1 ล้านโทเค็น ถึงวันที่ 31 ธันวาคม 2026 จากนั้น Model Card ระบุว่าจะปรับเป็น 1.50 และ 7.50 ดอลลาร์ตามลำดับตั้งแต่ 1 มกราคม 2027

ตัวเลขนี้ช่วยให้ลองวาง 3.7 Flash ไว้หน้าสุดของเวิร์กโฟลว์ได้ง่ายขึ้น แต่การคำนวณต้นทุนในระบบใช้งานจริงไม่ควรหยุดที่ราคาต่อโทเค็น ให้รวมอย่างน้อยห้าส่วน

1. จำนวนโทเค็นที่ใช้จริงต่อคำขอ
2. จำนวนครั้งที่เอเจนต์เรียกโมเดลต่อหนึ่งงาน
3. จำนวนครั้งที่เอเจนต์เรียกเครื่องมือต่อหนึ่งงาน โดยเก็บแยกจากจำนวนครั้งที่เรียกโมเดล
4. จำนวนครั้งที่ต้องลองใหม่เมื่อผลลัพธ์ใช้ต่อไม่ได้
5. เวลาที่คนต้องเข้ามาตรวจ แก้ หรือเริ่มงานใหม่

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

วาง 3.7 Flash เป็นสามชั้น ไม่ใช่คำตอบเดียว

ถ้าจะใช้ 3.7 Flash เป็นโมเดลตัวหลัก ลองออกแบบเส้นทางงานเป็นสามชั้น

1. ใช้เป็นค่าเริ่มต้นสำหรับงานที่ย้อนกลับได้

ส่งงานประจำที่ตรวจผลได้และแก้กลับได้ให้ 3.7 Flash ก่อน เช่น สำรวจ codebase, เขียนชุดแก้ไขรอบแรก, รันเครื่องมือวินิจฉัย, สรุปเอกสาร หรือประกอบข้อมูลจากหลายไฟล์

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

2. เพิ่มระดับการคิดเมื่องานเริ่มแตกแขนง

งานที่ต้องวางแผนหลายขั้น เรียกเครื่องมือหลายชนิด หรือแก้ปัญหาที่มีสมมติฐานหลายทาง ควรได้ระดับการคิดมากขึ้น แทนที่จะเปลี่ยนโมเดลทันที

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

3. ยกระดับงานเมื่อความเสี่ยงเกินขอบเขต

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

จุดยกระดับไม่ใช่สัญญาณว่า Flash ล้มเหลว แต่เป็นส่วนหนึ่งของระบบที่ดี โมเดลตัวหลักไม่จำเป็นต้องทำทุกอย่างเอง ขอเพียงรับงานส่วนใหญ่ได้ แล้วให้ระบบส่งงานที่เกินขอบเขตไปถูกที่

ข้อจำกัดที่ต้องออกแบบไว้ตั้งแต่แรก

Model Card ของ Google ระบุว่า 3.7 Flash ยังมีข้อจำกัดพื้นฐานของโมเดล รวมถึงการสร้างข้อมูลผิด (hallucination) และอาจช้าหรือหมดเวลารอ (timeout) เป็นบางครั้ง

Knowledge cutoff หลักอยู่ที่มีนาคม 2026 แต่บางโดเมนอาจมีความรู้จำกัดถึงมกราคม 2025 งานที่ต้องใช้ข้อมูลใหม่จึงควรต่อแหล่งค้นหาและบังคับให้ส่งหลักฐานกลับมา ไม่ควรหวังว่าความจำในโมเดลจะทันเหตุการณ์เสมอ

อีกจุดที่ควรระวังคือเอกสารอาจอัปเดตไม่พร้อมกัน ณ เวลาที่เก็บข้อมูลสำหรับบทความนี้ หน้า “โมเดล Gemini ล่าสุด” ของ Gemini API ยังแสดงตัวอย่าง gemini-3.6-flash และยังไม่ให้ model ID หรือตัวอย่างย้ายระบบสำหรับ 3.7 Flash ก่อนแก้การตั้งค่าของระบบใช้งานจริง ให้ตรวจหน้าเอกสารและ AI Studio ล่าสุดอีกครั้ง แทนการเดาชื่อโมเดลจากรูปแบบเดิม

ด้านความปลอดภัย Google รายงานว่าผลโดยรวมใกล้เคียง 3.6 Flash และโมเดลไม่ถึงระดับความสามารถวิกฤตที่บริษัทติดตาม แต่ผลประเมินเหล่านี้ไม่แทนมาตรการป้องกันของแอป ทีมยังต้องจำกัดสิทธิ์เครื่องมือ แยกสภาพแวดล้อมทดสอบออกจากระบบใช้งานจริง บังคับให้คนอนุมัติก่อนเอเจนต์รันคำสั่งที่ย้อนกลับไม่ได้ และเก็บบันทึกการเรียกเครื่องมือไว้ตรวจสอบย้อนหลัง

เช็กลิสต์ก่อนเลื่อนให้เป็นโมเดลตัวหลัก

ก่อนเปลี่ยนเส้นทางส่งงานของระบบ ให้ตอบคำถามเหล่านี้จากการทดลองของทีมเอง

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

Gemini 3.7 Flash น่าสนใจเพราะมันไม่ได้บังคับให้เราเลือกระหว่าง “เร็ว” กับ “คิดเป็น” แบบเด็ดขาด โมเดลพยายามให้ทีมใช้ความเร็วเป็นฐาน แล้วเพิ่มแรงคิดเฉพาะจุดที่จำเป็น

ถ้าการทดสอบงานชุดเดียวกันยืนยันว่า 3.7 Flash ใช้รอบแก้น้อยกว่าโมเดลหรือการตั้งค่าเดิม มันก็มีโอกาสเป็นโมเดลตัวหลักที่ดี ไม่ใช่เพราะชนะทุกคะแนนทดสอบ แต่เพราะช่วยให้งานส่วนใหญ่เดินถึงเส้นชัยด้วยต้นทุนที่คุมได้ ขณะที่ระบบยังส่งงานที่เกินเกณฑ์ความเสี่ยงไปยังโมเดลอื่นหรือให้คนตรวจ

ที่มา: Google: Introducing Gemini 3.7 Flash, Google AI for Developers: การใช้โมเดล Gemini ล่าสุด และ Google DeepMind: Gemini 3.7 Flash Model Card