Google ชี้ Gemini thinkingLevel LOW ถูกกว่าค่าเริ่มต้นเกินครึ่ง ตอบถูกครบ 50 จาก 50 งาน

เพดาน maxOutputTokens ไม่ใช่ตัวคุมการคิดแบบ Gemini thinkingLevel LOW

หลายทีมคิดว่าจำกัด maxOutputTokens ต่ำจะทำให้โมเดลคิดน้อยลงกับงานง่าย ข้อมูลของ Google ชี้ตรงข้าม กับงานง่าย 27 งานที่ Jev ตัดสินว่า SIMPLE โมเดลใช้โทเคนคิดเฉลี่ย 185.6 เมื่อจำกัด 300 โทเคน และ 179.7 เมื่อจำกัด 4,096 ต้นทุนรวม 27 งานเป็น 0.02018 และ 0.01957 ดอลลาร์ ส่วน Gemini thinkingLevel LOW ใช้โทเคนคิดเฉลี่ยเพียง 35.3 และต้นทุน 0.00496 ดอลลาร์ ขณะที่ Flash-Lite ไม่คิดเลยและต้นทุน 0.00063 ดอลลาร์

เพดานยังทำให้งานยาก 7 จาก 25 งานพัง หกงานโมเดลหมดที่ขณะยังคิดอยู่และไม่ตอบ อีกงานบีบการคิดจนตอบผิด

กฎคีย์เวิร์ดพังเมื่อเจองานใหม่

ทีมเขียนกฎ regex กับความยาวพรอมต์ที่คัดงานยากได้ 15 จาก 16 งาน (93.8%) แต่เมื่อตรึงโค้ดแล้วทดสอบ 34 งานที่ไม่เคยเห็นใน 7 กลุ่ม ความแม่นยำตกเหลือ 70.6% เพราะงานง่าย เช่น ดึงพอร์ตจาก Kubernetes YAML ยาวเกิน 35 คำจึงถูกส่งไปโมเดลแพงเกินจำเป็น ส่วนงานตามรอยหลายขั้นที่สั้นไม่มีคำที่กฎจับจึงถูกส่งไปทางง่าย Jev แก้ได้เมื่อถามคำถามใช่หรือไม่ที่เจาะจงข้อเดียว แทนถามกว้างว่างานง่ายหรือยาก

ตัวจัดเส้นทาง Jev ส่งทุกงานไป Flash-Lite ก่อน และส่งเฉพาะที่ถูกตัดสินว่าซับซ้อนไป Flash แบบ Gemini thinkingLevel LOW Flash-Lite เพียงอย่างเดียวพลาด 6 จาก 25 งานยาก Jev จับได้ครบทั้ง 6 ผลคือตอบถูก 50 จาก 50 ที่ 0.02287 ดอลลาร์ ถูกกว่า Gemini thinkingLevel LOW อย่างเดียวราว 13% และเร็วกว่าราว 46% (คำนวณเอง) Google บอกว่าบนพรอมต์สั้นเช่นนี้ผลต่างต้นทุนต่องานเล็กน้อย ประโยชน์ที่ใหญ่กว่าคือเวลารอ

แคชบริบทกับตัวจัดเส้นทางดึงไปคนละทาง

Google เตือนว่าเอเจนต์จริงมักส่งบริบทก้อนใหญ่ซ้ำทุกรอบ เช่น แผนที่ของคลังโค้ดและนิยามเครื่องมือ การแคชบริบทบน Agent Platform ลดค่าส่งซ้ำ 75% ถึง 90% แต่แคชผูกกับโมเดลเดียว ถ้าสลับ Flash-Lite กับ Flash ทุกรอบ จะต้องมีสองแคชหรือเสียส่วนลด จึงควรจัดเส้นทางเฉพาะงานสั้นที่ครบในตัว เช่น แยกวิเคราะห์ล็อกหรือตรวจสคีมา และคงรอบที่พึ่งบริบทหนักไว้กับโมเดลเดียว Google ยังพบว่าการตั้งค่า Pro ปฏิเสธโจทย์ตรวจความปลอดภัยโค้ดสั้น 2 ข้อที่ Flash ตอบได้ ทีมที่ใช้เอเจนต์ตรวจความปลอดภัยจึงควรทดสอบโจทย์เหล่านั้นกับการตั้งค่าที่จะใช้จริง

ผลต่อองค์กรไทยที่ใช้ Gemini thinkingLevel LOW

ข้อมูลเป็นการรันเดียวกับ 50 โจทย์ ไม่ใช่มาตรฐานของงานทั่วไป ข้อเสนอต่อไปนี้ส่วนที่ 1 ถึง 3 สอดคล้องกับ Google และส่วนที่ 4 ถึง 5 เป็นความเห็นของเรา

1. ตั้ง Gemini thinkingLevel LOW ก่อน แล้ววัดคำตอบกับงานจริง แทนการลดเพดานโทเคน
2. เปลี่ยนจากพารามิเตอร์เดิมไปใช้ Gemini thinkingLevel LOW โมเดล Gemini 3 ขึ้นไปใช้ thinkingLevel ซึ่งสัมพันธ์กับการย้ายจาก Gemini 2.5 ตามข่าวGemini 2.5 Pro ถูกส่งต่อ 1 ธันวาคม
3. เก็บร่องรอยการใช้โทเคนก่อนและหลังเปิด Gemini thinkingLevel LOW ส่งจำนวนโทเคนคิดของเอเจนต์ไป Cloud Logging และ BigQuery เพื่อดูว่างานใดกินงบ
4. ตั้งชุดโจทย์ของตัวเอง รวมงานภาษาไทยและงานภายในองค์กร แล้วแยกชุดสำหรับเขียนกฎกับชุดสำหรับทดสอบ เพราะกฎที่เขียนจากตัวอย่างเดิมจะตกเมื่อเจองานใหม่
5. คิดต้นทุนต่องานสำเร็จ ไม่ดูเฉพาะราคาต่อโทเคนหรือจำนวนครั้งที่เรียก

ติดตามข่าว AI อื่น ๆ ได้ที่หมวด AI

บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง

Google ชี้ว่าตัวจำแนกขนาดเล็กรันเองบนเครื่องของตนได้ โดยโมเดลที่โฮสต์เองคิดเงินเป็นชั่วโมง GPU ไม่ใช่ตามโทเคน องค์กรที่อยากทดลองทางนี้ประเมินสเปกกับโมเดลที่เลือกก่อน GPU Server ของ THAI DATA CLOUD ให้เช่า NVIDIA Tesla T4 และ V100 สำหรับงาน AI บน Data Center มาตรฐาน ISO 27001 (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)