Gemini เปลี่ยนวิธีอ่านวิดีโอ — จากไล่ดูทีละเฟรมเป็นให้โมเดลเลือกเองว่าจะดูตรงไหน ลดโทเคน 88% แต่ค่าใช้จ่ายลดแค่ 66%

1 กันยายน 2026 Google เปิดความสามารถชื่อ agentic video understanding ให้โมเดล Gemini สามตัว และมันไม่ใช่โมเดลใหม่ — เป็นการเปลี่ยน วิธีที่โมเดลกินวิดีโอ ซึ่งเป็นจุดที่กินเงินจริงในงานวิดีโอมาตลอด

เดิมที Gemini อ่านวิดีโอแบบ static: สุ่มเฟรมออกมาที่อัตราคงที่ (ดีฟอลต์ 1 เฟรมต่อวินาที ปรับได้ผ่าน API) แล้วยัดทุกเฟรมเข้าคอนเท็กซ์ตั้งแต่ต้นจนจบ วิดีโอบรรยาย 90 นาทีจึงกลายเป็นเฟรมห้าพันกว่าเฟรมที่ต้องจ่ายเงินทั้งหมด ต่อให้คำถามคือ “อาจารย์พูดถึงหัวข้อ X ตอนนาทีไหน” ก็ตาม

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

เปิดใช้อย่างไร และได้กับโมเดลไหน

การเปลี่ยนคือคอนฟิกตัวเดียวในคำขอ — ตั้งค่า "processing" เป็น "agentic" แทนโหมดดีฟอลต์ {"type": "static"}

• โมเดลที่รองรับ: Gemini 3.7 Flash, 3.6 Flash และ 3.5 Flash-Lite (โหมด static ยังใช้ได้กับทุกโมเดล)
• API: ใช้ได้ทั้ง Interactions API และ GenerateContent API ผ่าน Google AI Studio และ Gemini Enterprise Agent Platform
• ความยาวที่รับได้: โมเดลคอนเท็กซ์ 1M รับวิดีโอ ยาวถึง 3 ชั่วโมง ที่ media resolution ต่ำ หรือ 1 ชั่วโมง ที่ resolution สูง
• ขนาดไฟล์: ผ่าน File API ได้ 20GB สำหรับบัญชีเสียเงิน และ 2GB สำหรับฟรี
• ราคา: ไม่มีค่าฟีเจอร์เพิ่ม คิดตามราคาโทเคนปกติ
• สถานะ: ตัว agentic processing เองขึ้นเป็น GA แล้ว ส่วนที่ยังติดป้าย Preview คือการรับ URL ของ YouTube โดยตรง ซึ่งตอนนี้ยังไม่คิดเงิน โดยเอกสารเขียนไว้ตรง ๆ ว่า “ราคาและ rate limit มีแนวโน้มจะเปลี่ยน”

รายการโมเดลที่รองรับมีจุดที่ควรสังเกต: มีแต่ชั้น Flash ทั้งสามตัว ไม่มี Pro ความสามารถนี้จึงลงที่รุ่นถูกก่อน ซึ่งเข้ากับเรื่องราวด้านต้นทุนดี แต่ก็แปลว่าเพดานความแม่นยำที่ได้คือเพดานของ Flash ไม่ใช่เพดานของ Gemini

ตัวเลขสามตัวที่ไม่เท่ากัน — และช่องว่างระหว่างมันคือประเด็น

Google อ้างผลจากเบนช์มาร์กวิดีโอมาตรฐานไว้สามตัว:

ตัวชี้วัด	ที่อ้าง
โทเคนที่ใช้	น้อยลง ถึง 88%
ค่าใช้จ่ายในการวิเคราะห์	ถูกลง ถึง 66%
ความแม่นยำ	ดีขึ้น ถึง 7%

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

ประเด็นเชิงปฏิบัติจึงตรงไปตรงมา: ถ้าจะตั้งงบ ให้ตั้งจาก 66% ไม่ใช่ 88% ตัวเลขโทเคนคือตัวเลขที่สวยกว่าและถูกพาดหัวมากกว่า แต่ตัวเลขที่ปรากฏบนบิลคือตัวหลัง

ข้อสังเกตที่สองคือคำว่า “ถึง” (up to) ติดอยู่ทั้งสามตัว และ Google ระบุเองว่าผลจะเด่นชัดเป็นพิเศษ “กับวิดีโอยาว — ตั้งแต่คู่มือ how-to 10 นาที ไปจนถึงเลกเชอร์ 90 นาทีและการบันทึกหลายชั่วโมง” อ่านกลับด้านคือ วิดีโอสั้นแทบไม่ได้อะไร ซึ่งสมเหตุสมผล — คลิป 30 วินาทีไม่มีอะไรให้ข้าม การเพิ่มลูปตัดสินใจเข้าไปอาจแพงกว่าการดูทั้งคลิปด้วยซ้ำ

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

สิ่งที่เปลี่ยนไปในเชิงวิศวกรรม

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

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

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

มุมมอง AI Curator

ผมคิดว่าเรื่องนี้ควรถูกอ่านเป็นตัวอย่างของแนวโน้มที่ใหญ่กว่าวิดีโอ — การย้าย “การเลือกว่าจะอ่านอะไร” จากโค้ดของเราเข้าไปอยู่ในโมเดล

สองปีที่ผ่านมา วิธีทำงานกับวิดีโอยาวคือ เราเป็นคนเขียน retrieval เอง: ตัดคลิป ทำ embedding ทำ index หาช่วงที่เกี่ยว แล้วค่อยส่งเฉพาะช่วงนั้นให้โมเดล นั่นคือไปป์ไลน์ RAG-สำหรับ-วิดีโอที่หลายทีมสร้างเอง สิ่งที่ Google ทำรอบนี้คือ ดูดไปป์ไลน์นั้นเข้าไปไว้หลังคอนฟิกตัวเดียว ซึ่งเป็นข่าวดีสำหรับความเร็วในการสร้างของ และเป็นข่าวร้ายสำหรับสตาร์ตอัปที่ขายชั้นนั้นเป็นผลิตภัณฑ์ — รูปแบบเดิมที่เราเห็นซ้ำมาหลายรอบ

สำหรับไทยและอาเซียน ผมคิดว่านี่คือหนึ่งในฟีเจอร์ที่ตรงกับลักษณะเนื้อหาในภูมิภาคมากผิดปกติ เพราะของยาวคือของที่เรามีเยอะ — ไลฟ์ขายของบน TikTok/Facebook ที่ยาวสามสี่ชั่วโมง, คลิปบันทึกการประชุมและการอบรมของหน่วยงานรัฐ, เลกเชอร์ออนไลน์, รายการทีวีย้อนหลัง, กล้องวงจรปิดในโรงงานและร้านค้า ทั้งหมดนี้คืองานที่ มีคุณค่าชัดเจนแต่ไม่เคยคุ้มค่าประมวลผล เพราะต้นทุนต่อชั่วโมงสูงเกินไป การลดต้นทุนสองในสามไม่ได้แค่ทำให้ของเดิมถูกลง แต่ทำให้เคสที่เคยติดลบข้ามเส้นมาเป็นบวก — โดยเฉพาะงานประเภท “หาช่วงที่เกิดเหตุ” ซึ่งเป็นเคสที่ agentic ได้เปรียบมากที่สุด

แต่มีข้อควรระวังที่เฉพาะกับภาษาไทย: เมื่อโมเดลมีสิทธิ์เลือกใช้ทรานสคริปต์แทนเฟรม มันจะเลือกทางที่ถูกที่สุดเมื่อทำได้ และคุณภาพการถอดเสียงไทย — โดยเฉพาะเมื่อมีคำทับศัพท์ ชื่อสินค้า ภาษาถิ่น หรือเสียงรบกวนแบบไลฟ์ขายของ — ยังไม่เท่าภาษาอังกฤษ ผลคือความเสี่ยงที่ระบบจะ ประหยัดสำเร็จแต่ตอบผิด โดยไม่มีสัญญาณเตือน ทีมที่จะใช้จริงควรวัดสองอย่างคู่กันเสมอ ไม่ใช่วัดแค่โทเคนที่ประหยัดได้: ความแม่นบนคลิปภาษาไทยของตัวเอง และ ความแม่นเมื่อบังคับให้ใช้เฟรมอย่างเดียว เพื่อจะรู้ว่าส่วนต่างมาจากไหน

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

แหล่งข่าว

• Google — Introducing agentic video understanding with Gemini (1 ก.ย. 2026)
• Gemini API docs — Video understanding (คอนฟิก processing: agentic, ลิมิตความยาวและขนาดไฟล์)
• Gemini API changelog — รายการเปลี่ยนแปลงวันที่ 1 ก.ย. 2026
• The Decoder — Google Gemini’s new agent-based video analysis cuts token usage by up to 88 percent