Google เปิด Gemini-SQL2 ความสามารถแปลงภาษาเป็น SQL บน Gemini 3.1 Pro ทำ 80.04% บน BIRD leaderboard ขึ้นนำทั้งสองอันดับแรก
Google Research ประกาศเปิดตัว Gemini-SQL2 ความสามารถ text-to-SQL ที่ขับเคลื่อนด้วยโมเดล Gemini 3.1 Pro โดยทำคะแนน execution accuracy 80.04% บน BIRD Text-to-SQL Leaderboard (Single Model) ดันให้ Google ขึ้นครองทั้งอันดับ 1 และ 2 ของตาราง (Gemini-SQL2 และ Gemini-SQL ตัวเดิม) จุดสำคัญคือ Gemini-SQL2 ไม่ใช่การปล่อยโมเดลใหม่ทั้งก้อน แต่เป็น “ความสามารถ” ที่แปลงคำถามภาษาธรรมชาติให้เป็น SQL ที่ “รันได้จริงและให้ผลถูกต้อง” ไม่ใช่แค่ดูเหมือนถูก
Google ระบุว่าความเข้าใจ SQL ที่ดีขึ้นจะยกระดับความสามารถด้านภาษาธรรมชาติทั่วทั้งบริการข้อมูลของบริษัท ซึ่งชี้ไปยังเป้าหมายการผนวกเข้ากับ BigQuery Studio, AlloyDB AI และ Cloud SQL Studio ที่มี Gemini อยู่แล้ว แม้ Google ยังไม่ยืนยันว่าผลิตภัณฑ์ใดจะได้รับ Gemini-SQL2 ก่อน
ทำไม BIRD ถึงเป็นเบนช์มาร์กที่วัดของจริง
BIRD (BIg Bench for LaRge-scale Database Grounded Text-to-SQL Evaluation) เป็นมาตรฐานอุตสาหกรรมที่มีคู่คำถาม-SQL กว่า 12,751 ชุด ครอบคลุม 95 ฐานข้อมูลใน 37 สาขาวิชาชีพ รวม 33.4GB จุดที่ทำให้มันยากกว่าเบนช์เก่าอย่าง Spider คือฐานข้อมูลมี “ค่าสกปรก (dirty values)” และต้องอาศัยความรู้ภายนอกประกอบ ตัวชี้วัดหลักคือ execution accuracy — SQL ที่สร้างต้องรันได้และคืนผลตรงกับ gold query เท่านั้นจึงนับว่าถูก
บน Single Trained Model Track ที่จำกัดการใช้ framework แบบ ensemble เพื่อวัดความสามารถแกนของโมเดลล้วน ๆ สถิติเดิมของ Google Cloud (รายงาน 15 พ.ย. 2025) อยู่ที่ 76.13 การกระโดดมา 80.04 จึงเป็นก้าวที่ชัด แต่ Google เองก็ระบุว่ามนุษย์ทำได้ 92.96 เหลือช่องว่าง 12.92 จุด สะท้อนว่างานแปลภาษาเป็น SQL ที่แม่นยำระดับ production ยังไม่ใช่เรื่องที่ AI ทำแทนคนได้เต็มตัว
ยังไม่มี API — แต่บอกทิศทางชัด
Google ยังไม่ได้เผยชื่อโมเดล (model string), API, รายงานเทคนิค หรือรายละเอียดการผนวกผลิตภัณฑ์ของ Gemini-SQL2 ทำให้ตอนนี้เป็นการประกาศผลเบนช์มาร์กและทิศทางมากกว่าของที่ใช้ได้ทันที นักพัฒนาที่อยากลองแนวทาง schema-grounded ตอนนี้ยังต้องใช้โมเดล Gemini ปัจจุบันผ่าน google-genai SDK ไปก่อน แล้วค่อยสลับ model string เมื่อ Gemini-SQL2 พร้อมใช้งานจริง
มุมมอง AI Curator
Text-to-SQL คือหนึ่งในกรณีใช้งาน AI ที่ “คุ้มค่าเงียบ ๆ” ที่สุดสำหรับองค์กรไทย เพราะปลดล็อกให้ทีมธุรกิจ การตลาด หรือการเงินถามข้อมูลจากฐานข้อมูลได้เองโดยไม่ต้องรอคิว data engineer แต่ตัวเลข 80.04% มีนัยที่ต้องอ่านให้ขาด — มันแปลว่า “ราว 1 ใน 5 คำถามยังตอบผิด” ดังนั้นสำหรับงานที่ตัวเลขผูกกับการตัดสินใจเงิน ๆ ทอง ๆ การมีคนตรวจ (human-in-the-loop) ยังจำเป็น สิ่งที่ผมมองว่าสำคัญกว่าคะแนนคือแนวคิด execution-verified ที่ BIRD ผลักดัน นั่นคือการไม่เชื่อ SQL ที่ “ดูถูก” แต่ต้องรันแล้วเช็กผลจริง องค์กรไทยที่จะนำ text-to-SQL ไปใช้ควรลอกหลักการนี้มาออกแบบระบบ คือรัน query ที่โมเดลสร้างในแซนด์บ็อกซ์ จับ error แล้ว retry ก่อนแสดงผลให้ผู้ใช้ปลายทาง — เป็นด่านป้องกัน “คำตอบที่มั่นใจแต่ผิด” ที่ถูกที่สุดและได้ผลที่สุด
แหล่งข่าว:
อ่านเพิ่มในหมวด งานวิจัย
Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS