Text-to-SQL: ให้ทีมธุรกิจถามข้อมูลเป็นภาษาคน แบบไม่ตอบมั่ว
Text-to-SQL ทำงานอย่างไร ทำไมต้องมี semantic layer และ verified answers และองค์กรควรวางระบบอย่างไรให้คนทั่วไปถามข้อมูลได้อย่างปลอดภัย
ผู้จัดการฝ่ายรายได้ของเครือโรงแรมแห่งหนึ่งอยากรู้ว่า "อัตราการเข้าพักของโรงแรมในภูเก็ตเดือนที่แล้วเทียบปีก่อนเป็นยังไง" แต่ต้องส่งคำขอไปทีม Data แล้วรอสองวัน ความฝันของหลายองค์กรคือให้คนแบบเขาพิมพ์ถามเองแล้วได้คำตอบทันที เทคโนโลยีที่ทำให้เป็นไปได้คือ Text-to-SQL แต่ถ้าวางระบบไม่ดี มันจะตอบผิดอย่างมั่นใจ ซึ่งอันตรายกว่าไม่ตอบ
Text-to-SQL คืออะไร
Text-to-SQL คือการให้ AI แปลงคำถามภาษาธรรมดาเป็นคำสั่ง SQL แล้วรันกับฐานข้อมูลเพื่อให้คำตอบเป็นตัวเลขหรือกราฟ ต่างจากการให้ AI "เดาคำตอบ" เพราะผลลัพธ์มาจากข้อมูลจริง แต่ความถูกต้องขึ้นกับว่า AI แปลคำถามเป็น query ได้ตรงความหมายหรือไม่
กลไก: AI ต้องรู้อะไรบ้างถึงจะแปลถูก
1. Semantic layer
Semantic layer คือชั้นที่บอกความหมายทางธุรกิจของข้อมูล เช่น "อัตราการเข้าพัก" คำนวณจากห้องที่ขายได้หารห้องที่เปิดขาย ไม่ใช่ห้องทั้งหมด ถ้าไม่มีชั้นนี้ AI ต้องเดาสูตรจากชื่อคอลัมน์ และแต่ละครั้งอาจเดาไม่เหมือนกัน
2. ชุดข้อมูลที่คัดแล้ว
อย่าเปิดให้ AI เห็นทุกตารางในฐานข้อมูล ให้สร้าง view หรือ dataset เฉพาะที่สะอาดและมีชื่อชัดเจน ยิ่งตัวเลือกน้อย AI ยิ่งเลือกถูก
3. คำแนะนำและคำตอบที่ตรวจแล้ว
เครื่องมือ BI หลายตัวมีกลไกนี้ เอกสาร Microsoft Learn ระบุว่า Copilot ในแอป Power BI รองรับ "verified answers" ที่ผู้สร้างเตรียมไว้ ส่วนเอกสารของ Google ระบุว่า Conversational Analytics ใน Data Studio ให้สร้าง data agent ที่ใส่บริบทและคำแนะนำเพิ่มได้ ทั้งสองแนวคิดเหมือนกันคือ ใส่ความรู้ของคนลงไปให้ AI ใช้
Text-to-SQL ไม่ได้มาแทน Dashboard
Dashboard เหมาะกับคำถามที่ถามซ้ำทุกสัปดาห์และต้องเห็นตรงกันทั้งองค์กร ส่วน Text-to-SQL เหมาะกับคำถามเฉพาะกิจที่ไม่คุ้มสร้างรายงานใหม่ เช่น "ลูกค้าที่จองผ่านเว็บไซต์โดยตรงช่วงสงกรานต์พักเฉลี่ยกี่คืน" แนวทางที่ใช้ได้ดีคือ
- ใช้ Dashboard เป็นตัวเลขทางการที่ใช้ในที่ประชุม
- ใช้ Text-to-SQL สำรวจคำถามใหม่ ถ้าคำถามไหนถูกถามบ่อย ให้ย้ายไปเป็นกราฟใน Dashboard
- ถ้าตัวเลขจาก Text-to-SQL จะถูกใช้ตัดสินใจสำคัญ ให้ทีม Data ตรวจ query ก่อนเสมอ
ตัวอย่าง: เครือโรงแรมเปิดให้ฝ่ายขายถามข้อมูลเอง
ทีม Data สร้าง dataset การจองที่มีเพียง 15 คอลัมน์ เขียนนิยาม KPI เช่น อัตราการเข้าพัก ราคาห้องเฉลี่ย และรายได้ต่อห้องที่มีให้ขาย เพิ่มตัวอย่างคำถามพร้อมคำตอบที่ตรวจแล้ว 30 ข้อ และตั้งสิทธิ์ให้ผู้จัดการแต่ละโรงแรมเห็นเฉพาะโรงแรมตัวเอง เมื่อผู้ใช้ถามคำถามใหม่ ระบบแสดงทั้งคำตอบและคำอธิบายว่าใช้ตัวกรองอะไร ผู้ใช้จึงเห็นได้ว่า AI เข้าใจคำถามตรงหรือไม่
Text-to-SQL ที่ดีไม่ได้เริ่มจาก AI แต่เริ่มจากนิยามที่ทุกคนตกลงร่วมกัน
ข้อควรระวัง
- คำกำกวม: "เดือนที่แล้ว" "ยอดขาย" "ลูกค้าใหม่" ต้องมีนิยามกลาง ไม่เช่นนั้นแต่ละคนจะได้ตัวเลขต่างกัน
- สิทธิ์การเห็นข้อมูล: ต้องตั้ง row-level security ที่ระดับข้อมูล ไม่ใช่หวังให้ AI ปฏิเสธเอง
- ภาษาไทย: เอกสาร Microsoft Learn ระบุว่า Copilot ใน Power BI ยังไม่รองรับหลายภาษาอย่างเป็นทางการ และเอกสาร Google ระบุว่า Gemini ใน BigQuery รับ prompt ภาษาอังกฤษเท่านั้น ควรทดสอบคำถามภาษาไทยก่อนเปิดใช้จริง
- ความเชื่อมั่นเกินจริง: คำตอบที่มาพร้อมกราฟสวยดูน่าเชื่อ ให้ระบบแสดงตัวกรองและช่วงเวลาที่ใช้เสมอ
- ข้อมูลส่วนบุคคล: ไม่ควรเปิดตารางที่มีชื่อหรือเบอร์ลูกค้าให้ถามได้อิสระ
เริ่มต้นยังไง
- รวบรวมคำถามที่ทีม Data ถูกถามบ่อยที่สุด 20 ถึง 30 ข้อ
- สร้าง dataset ที่ตอบคำถามเหล่านั้นได้ พร้อมนิยาม KPI เป็นลายลักษณ์อักษร
- ตรวจคำตอบที่ถูกต้องของคำถามชุดนี้ไว้ ใช้เป็นชุดทดสอบ
- ทดลองกับผู้ใช้กลุ่มเล็ก เก็บคำถามที่ AI ตอบผิดมาปรับนิยามและคำแนะนำ
- ขยายผู้ใช้ทีละกลุ่ม และทบทวนชุดทดสอบทุกเดือน
ถ้าคุณเป็นนักวิเคราะห์ที่ต้องดูแลระบบนี้ อ่านต่อที่ ใช้ AI ช่วยเขียน SQL สำหรับนักวิเคราะห์ หรือเรียนรู้การถามข้อมูลด้วยภาษาคนจากคอร์ส Power BI Q&A ถามอะไรตอบได้ด้วย AI บน Plants.work Learn