- ความสามารถ Text-to-SQL ที่ขับเคลื่อนด้วย Gemini ถูกนำไปใช้เพื่อเพิ่มประสิทธิภาพการทำงานของทั้งนักพัฒนาและผู้ใช้ที่ไม่ใช่สายเทคนิคทั่วทั้ง Google Cloud
- ในสภาพแวดล้อมจริง การสร้าง SQL ที่แม่นยำทำได้ยากเนื่องจาก การขาดบริบทธุรกิจ การตีความเจตนาของผู้ใช้ที่ยาก และความแตกต่างของ SQL dialect
- Google นำเทคนิคอย่าง การค้นคืนข้อมูลอัจฉริยะ การเรียนรู้จากบริบท และการจัดชั้นเชิงความหมาย มาใช้เพื่อแก้ปัญหานี้
- ข้อจำกัดของตัวโมเดลเอง ถูกชดเชยด้วยวิธีอย่างการสร้างหลายคำตอบแล้วเลือกคำตอบที่ดีที่สุด (self-consistency), การตรวจสอบแล้ว re-prompt และการฝึกตาม SQL dialect แต่ละแบบ
- ในด้าน การประเมินและวัดผลการปรับปรุง มีทั้งการใช้ benchmark ภายในและแนวทางใช้ LLM เป็นผู้ตัดสิน เพื่อเพิ่มความพร้อมสำหรับการใช้งานจริง
Techniques for improving text-to-SQL
การแปลงข้อความเป็น SQL: สถานะปัจจุบันของ Google Cloud
- องค์กรใช้ SQL เพื่อให้ได้ข้อมูลเชิงลึกจากข้อมูลอย่างรวดเร็วและแม่นยำ
- Gemini มอบความสามารถ text-to-SQL ที่สร้าง SQL ได้โดยตรงจากภาษาธรรมชาติ
- ความสามารถนี้มีประโยชน์ไม่เพียงกับนักพัฒนา แต่ยังรวมถึงผู้ใช้ที่ไม่ใช่สายเทคนิคด้วย
- ปัจจุบันมีความสามารถนี้ใน BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI และอื่น ๆ
ความท้าทายหลักของเทคโนโลยี Text-to-SQL
1. ความยากในการให้บริบทธุรกิจ
- เพื่อเขียน SQL ได้อย่างแม่นยำ จำเป็นต้อง ให้คอนเท็กซ์ที่เพียงพอแก่ LLM เช่น โครงสร้างฐานข้อมูล ความหมายของคอลัมน์ และเนื้อหาของข้อมูลจริง
- คอนเท็กซ์ต้องครอบคลุมทั้งข้อมูลที่ชัดเจน (เช่น schema, ข้อมูลคอลัมน์) และข้อมูลโดยนัย (เช่น ความหมายทางธุรกิจของข้อมูลบางประเภท)
- วิธี ฝึก LLM อย่างต่อเนื่อง (fine-tuning) ให้ทันกับการเปลี่ยนแปลงของโครงสร้างฐานข้อมูล ชุดข้อมูล หรือ schema นั้นมีต้นทุนสูงในทางปฏิบัติ
- ความรู้ทางธุรกิจหรือข้อมูลเชิงความหมายมักไม่ได้ถูกจัดระเบียบไว้อย่างเหมาะสม และการแปลงสิ่งเหล่านี้ให้เป็นข้อมูลฝึกก็ทำได้ยากเช่นกัน
- ตัวอย่าง: หาก DBA ไม่รู้ความหมายของ
pcat_extension table ที่มี cat_id2 = 'Footwear' ก็จะไม่สามารถเขียน SQL เพื่อค้นหายอดขายรองเท้าได้ — LLM ก็เช่นกัน หากขาดคอนเท็กซ์ก็มีความเสี่ยงจะสร้าง query ที่ไม่ถูกต้อง
2. ปัญหาในการตีความเจตนาของผู้ใช้
- คำถามภาษาธรรมชาติมัก ขาดความชัดเจนเมื่อเทียบกับ SQL
- ในการทำงานจริง นักวิเคราะห์ข้อมูลหรือวิศวกรสามารถถามต่อเพื่อให้คำถามชัดเจนขึ้นได้ แต่ LLM มักมีแนวโน้มจะสร้างคำตอบทันทีจากคำถามที่ได้รับ จึงมี ความเสี่ยงต่อข้อมูลหลอน (hallucination)
- สำหรับคำถามอย่าง “รองเท้าที่ขายดีที่สุดคืออะไร?” รายละเอียดอย่างเกณฑ์ของคำว่า ‘ขายดีที่สุด’ (จำนวนคำสั่งซื้อ, ยอดขาย ฯลฯ) หรือจำนวนผลลัพธ์ที่ต้องการนั้นยังคลุมเครือ
- ผู้ใช้ที่มีทักษะทางเทคนิคอาจใช้ SQL แบบคร่าว ๆ เป็นจุดเริ่มต้นได้ แต่สำหรับผู้ใช้ทั่วไป SQL ที่ทำงานได้อย่างถูกต้อง สำคัญกว่า
- เพื่อให้ทำงานได้อย่างมีประสิทธิภาพ LLM ควรรองรับ คำถามต่อเนื่อง, การอธิบายเหตุผล, และ การแนะนำผู้ใช้ เพื่อให้เข้าใจเจตนาของผู้ใช้ได้ชัดเจน
3. ข้อจำกัดด้านการสร้างของ LLM
- LLM มีจุดแข็งในงานอย่าง การสรุปเอกสารและการดึงข้อมูล แต่ยังมีข้ออ่อนในเรื่องไวยากรณ์ SQL ที่แม่นยำหรือฟีเจอร์ SQL ที่ไม่ค่อยได้ใช้
- ไวยากรณ์แตกต่างกันไปตาม SQL dialect และแม้ความแตกต่างเล็กน้อยก็ต้องการความแม่นยำสูง
- ตัวอย่าง: ใน BigQuery ใช้
EXTRACT(MONTH FROM timestamp_column) แต่ใน MySQL ต้องใช้ MONTH(timestamp_column)
- การสร้าง SQL ให้สอดคล้องกับ ข้อกำหนดที่ซับซ้อน อย่างสม่ำเสมอยังเป็นโจทย์ที่ไม่ง่ายสำหรับ LLM
เทคนิคของ Google Cloud ในการยกระดับ Text-to-SQL
ปัญหา: schema และบริบทธุรกิจ
- การค้นหาและจัดอันดับตามความหมาย
- การเรียนรู้ภายในบริบท
- การสุ่มตัวอย่างและการเชื่อมโยงข้อมูล
- การสร้างชั้นเชิงความหมาย
- การวิเคราะห์รูปแบบการใช้งานและประวัติ
ปัญหา: การตีความเจตนาของผู้ใช้
- การทำให้คำถามชัดเจนผ่าน LLM
- ระบุเอนทิตี ตรวจสอบข้อมูลที่เกี่ยวข้อง แล้วชี้นำไปสู่คำถามต่อที่เหมาะสม
ปัญหา: การเอาชนะข้อจำกัดของ LLM
- ใช้ Self-consistency เพื่อสร้างหลาย query แล้วเลือกคำตอบที่ดีที่สุด
- การตรวจสอบความถูกต้องและ re-prompt
- การเรียนรู้จากบริบทที่มีตัวอย่าง SQL dialect รวมอยู่ด้วย
- การ fine-tune โมเดล
ตัวอย่างการประยุกต์ใช้เทคนิคหลัก
โมเดลที่รับรู้ SQL
- Gemini ใช้เวอร์ชันที่ผ่านการ fine-tune หลายแบบเพื่อสร้าง SQL คุณภาพสูง
- มีการ ผสมผสานเวอร์ชันโมเดลและการปรับแต่งเฉพาะทาง เพื่อให้ได้ความแม่นยำสำหรับแต่ละ SQL dialect
การทำให้คำถามของผู้ใช้ชัดเจนขึ้น (Disambiguation)
- เมื่อคำถามกำกวม จะมีการ สร้างคำถามเพื่อขอความชัดเจนเพิ่ม
- ตัวอย่าง: "รองเท้าที่ขายดีที่สุด?" → “อิงจากจำนวนคำสั่งซื้อหรือยอดขาย?”
การค้นหาตามความหมายและการสร้างบริบท
- ใช้ vector search ที่อิงการจับคู่ความหมายหลายขั้นตอน เพื่อระบุตารางและคอลัมน์ที่เกี่ยวข้อง
- สร้าง prompt โดยรวมประวัติ query ของผู้ใช้ ตัวอย่างกฎทางธุรกิจ และข้อมูลอื่นที่เกี่ยวข้อง
- รองรับ context window ขนาดยาว จึงสามารถรับมือกับ schema ขนาดใหญ่ได้
การตรวจสอบและการสร้างใหม่
- ตรวจจับข้อผิดพลาดอย่างชัดเจนด้วย การ parse และ Dry-run ของ query ที่ LLM สร้างขึ้น
- หากตรวจพบข้อผิดพลาด จะใช้ re-prompt เพื่อชี้นำให้แก้ไข
Self-consistency
- แทนที่จะสร้าง query เดียว จะ สร้างหลาย query ด้วยหลายแนวทาง
- หากหลายโมเดลแนะนำ query เดียวกัน ก็จะช่วย เพิ่มความแม่นยำ
การประเมินและการวัดประสิทธิภาพ
- benchmark ที่มีอยู่เดิม (เช่น BIRD-bench) มีประโยชน์ แต่ยังมี ข้อจำกัดในการสะท้อน schema จริง
- Google ได้สร้างชุด synthetic benchmark ของตนเองขึ้นมา
กลยุทธ์การประเมิน
- ครอบคลุม SQL dialect และฟีเจอร์ของแต่ละ engine: รวมถึงงานนอกเหนือจาก query เช่น DDL, DML และงานดูแลระบบ
- ตัวชี้วัดการประเมิน: ปฏิกิริยาของผู้ใช้, ตัวชี้วัดแบบออฟไลน์, และ LLM-as-a-judge
- การประเมินอย่างต่อเนื่อง: ช่วยตรวจสอบประสิทธิผลของโมเดลใหม่และเทคนิค prompt ใหม่ได้อย่างรวดเร็ว
สรุป
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
มีข้อกังวลเกี่ยวกับเป้าหมายสูงสุดของการแปลงข้อความเป็น SQL ว่าต้องการสร้างผู้ช่วยให้กับนักวิเคราะห์ข้อมูล หรืออยากได้อินไซต์ทางธุรกิจโดยไม่ต้องผ่านนักวิเคราะห์กันแน่ ถ้าเป็นอย่างหลัง ต่อให้พัฒนาไปไกลแค่ไหน คนที่ไม่ใช่ผู้เชี่ยวชาญก็ไม่มีทางตัดสินความถูกต้องและความเพียงพอของ SQL ได้ คำถามอย่าง "ทำไมธุรกรรมอีคอมเมิร์ซเมื่อวานถึงอยู่ที่ 80%?", "ทำไมต้นทุนการได้มาซึ่งลูกค้าถึงสูงขึ้น?", "ทำไมแคมเปญในนิวยอร์กถึงทำได้แย่กว่าซานฟรานซิสโก?" เป็นคำถามที่อยู่นอกขอบเขตของ text2sql
ในทางปฏิบัติดูจะใกล้เคียงกับเป้าหมายแบบที่สอง แต่ผลลัพธ์ยังไม่เป็นไปตามที่คาดหวัง ธุรกิจมักอยากปรับรายงานในช่วงท้าย แต่เพราะขาดนักวิเคราะห์จึงไม่ได้ข้อมูลที่ต้องการทันเวลา เลยพยายามแก้ด้วย "ความเร็วไม่จำกัด" แต่ปัญหาจริงคือไม่ได้คิดเรื่องเมตริกให้มากพอ ข้อมูลมีความซับซ้อน ความรู้ทางธุรกิจถูกเก็บแบบแฝงอยู่นอกระบบ และโครงสร้างพื้นฐานด้านข้อมูลยังไม่ดีพอ ทำให้การวิเคราะห์ใช้เวลานาน ผู้นำด้านการวิเคราะห์ที่ฉลาดจึงอาศัยกระแส AI เพื่อผลักดันการลงทุนในโครงสร้างพื้นฐานพื้นฐาน
มองว่าคำถามข้างต้นแต่แรกก็ไม่ใช่ปัญหาที่แก้ด้วย SQL ได้ SQL โดยหลักแล้วตอบคำถามประเภท "อะไร(what)" มากกว่า ไม่ได้ตอบ "ทำไม(why)" เป้าหมายของ text2sql คือช่วยลดเวลาที่นักวิเคราะห์ใช้กับ "อะไร" เพื่อให้ไปโฟกัสกับ "ทำไม" ได้มากขึ้น
เห็นด้วย แต่ผมคิดว่าภาษาธรรมชาติอาจกลายเป็นอินพุตสากลของระบบ LLM ได้ และ text2sql สามารถเป็นฐานของการดึงข้อมูลมาใช้ประกอบคำตอบสำหรับคำถามที่ซับซ้อนกว่าได้ ในระยะสั้นมันคือเครื่องมือช่วยงาน แต่ในระยะยาวเป้าคือวางรากฐานสำหรับระบบอัตโนมัติ การเปรียบเทียบผลลัพธ์ และการรวมเข้ากับเวิร์กโฟลว์ที่ใหญ่กว่า หัวใจสำคัญคือการปูพื้นฐานให้ตอบคำถามลักษณะนี้ได้ ซึ่งยังมีงานให้ทำอีกมาก
อัลกอริทึมใดก็ตามที่มนุษย์ทำได้ ก็สามารถสร้างและทดสอบได้ หากมีนักวิเคราะห์ 10 คน แต่ละคนก็มีความเข้าใจฐานข้อมูล ธุรกิจ และระดับความสามารถต่างกัน ระบบอัตโนมัติอย่างน้อยก็ช่วยกำหนดมาตรฐานที่รับประกันทักษะและความรู้ขั้นต่ำ ทำให้นักวิเคราะห์ใหม่สร้างผลงานที่ดีขึ้นได้ทันที การพัฒนาระบบร่วมกับผู้เชี่ยวชาญ การทดสอบมัน และทำให้ AI ตีความ trade-off, บั๊ก และเปรียบเทียบกับผลที่คาดหวังได้ เป็นเป้าหมายที่มีประโยชน์ อินไซต์หรือ ‘taste’ อาจทำให้เป็นอัตโนมัติได้ยาก แต่ถ้าผู้เชี่ยวชาญโดเมนมีระบบอัตโนมัติที่ออกแบบมาดีและมีเซนส์ต่อผลลัพธ์ที่สมเหตุสมผล ก็ไปได้ไกลมาก แม้ไม่สมบูรณ์แบบ แต่นั่นคือเป้าหมายของผม
แชร์ประสบการณ์การใช้โมเดล OpenAI 4o โดยส่งทั้งแนวทางธุรกิจ คำศัพท์เฉพาะในอุตสาหกรรม และคำอธิบายตารางกับ foreign key เข้าไปในพรอมป์ต จากนั้นมันก็สร้าง query join ที่ซับซ้อนและคืนผลลัพธ์ได้ เป้าหมายคือให้ผลลัพธ์แก่ผู้ใช้ที่ไม่รู้ SQL แต่ก็แสดง SQL เองให้ดูเป็นข้อมูลอ้างอิงด้วย
AI ไม่จำเป็นต้องสร้าง SQL ที่สมบูรณ์แบบ ในกรณีของผม ต่อให้เอาต์พุตตรวจสอบด้วยโค้ดได้ ผมก็ไม่คัดลอกไปใช้ตรง ๆ เพราะเสี่ยงต่อความคลาดเคลื่อนเชิงความหมายเล็กน้อย ผมใช้มันให้ช่วยเสนอแนวทาง แล้วอ้างอิงจากนั้นเพื่อเขียน SQL ใหม่เองตั้งแต่ต้น
แชร์ประสบการณ์การใช้ Gemini รุ่นล่าสุดใน Google AI Studio ซึ่งน่าประทับใจและพลิกเกมอย่างมาก ผลลัพธ์ด้านโค้ดจาก Claude และ ChatGPT ให้ความรู้สึกเหมือนมาจากคนละศตวรรษ แค่เดือนก่อนยังคิดว่า Claude ยอดเยี่ยมมาก แต่ตอนนี้ไม่รู้จะเขียนโค้ดต่อไปอย่างไรหากไม่มี Google Gemini, Gemini AI Studio คือการก้าวกระโดดครั้งใหญ่ของการเขียนโปรแกรม
แปลกใจที่ผู้คนจำนวนมากยังไม่ตระหนักถึงการเปลี่ยนแปลงนี้ Claude ก็จัดการงานเล็ก ๆ ได้ดี แต่พอเป็นปัญหาซับซ้อน Gemini นำห่างอย่างชัดเจน โดยเฉพาะความสามารถในการจัดการคอนเท็กซ์ที่น่าประทับใจมาก ผมไม่ได้ใช้แค่เป็น coding agent แต่ยังใช้ Gemini อ่านต้นฉบับยาว 85,000 คำแบบ beta reading และได้รับรายงานฟีดแบ็กระดับผู้เชี่ยวชาญแทบจะเรียลไทม์
สัปดาห์นี้รู้สึกว่า Gemini Pro ฟรีเหมือนจะปิดโหมด reasoning ไปแล้ว ถ้าทำให้มันไม่หยุดก่อนเขียนโค้ดหรือไม่ทำให้มันสรุปกว้างเกินไป มันก็มีประโยชน์มาก อย่างไรก็ตาม Gemini มีแนวโน้มจะเขียนโค้ดเยอะเกินจำเป็น วิธีที่ผมใช้หลัก ๆ คือไม่ได้ยึดติดกับการให้มันลงมือเขียนโค้ด แต่ใช้ Gemini เพื่อสำรวจเชิงสถาปัตยกรรมแทน เช่น กรณีทำบริการสมัครสมาชิกด้วย Stripe ผมสามารถรับข้อมูลเดิมที่ตรงกับ tech stack และ use case ของตัวเองในบริบทที่เหมาะสม จนเปลี่ยนทิศทางการออกแบบได้ก่อนจะเขียนโค้ดแม้แต่บรรทัดเดียว
คำตอบคือ “ใช้ semantic layer” นี่คือวิธีที่มีประสิทธิภาพที่สุดในการส่งต่อบริบทที่ถูกต้อง และเป็นจุดที่เหมาะที่สุดสำหรับการให้มนุษย์เข้ามาแทรกแซง ถ้ามนุษย์นิยามตัวชี้วัดหลักทั้งหมดไว้อย่างชัดเจน LLM ก็จะหยิบไปใช้ได้เสมอ เช่น ถ้านิยาม MAU ไว้ LLM ก็จะสร้างคิวรีตามนิยามนั้น หากเขียนคิวรีเป็น JSON แทน SQL, LLM จะให้ผลลัพธ์ได้สม่ำเสมอกว่ามาก เราใช้ cube ซึ่งเป็น semantic layer แบบโอเพนซอร์สที่ดีที่สุด ยังมีตัวเลือกแบบปิดซอร์สจากผู้ขายรายอื่นด้วย บริษัทเก่าของผมเคยเขียนบล็อกเกี่ยวกับเรื่องนี้ แต่ตอนนี้บริษัทที่เข้าซื้อกิจการได้หยุดโฮสต์ไปแล้ว
การใช้ AI สร้าง SQL ในงานจริงมีความเสี่ยง คนที่ไม่รู้ SQL อาจสร้างคิวรีผิดจนส่งผลร้ายแรงต่อเซิร์ฟเวอร์ได้ ฐานข้อมูลของทีมเราใหญ่สำหรับมาตรฐานนักพัฒนาส่วนใหญ่ แต่ไม่ถึงกับมหึมา แม้บางครั้งจะขอให้ AI ช่วยปรับคิวรีที่ optimize แล้วให้ดีขึ้น แต่มันก็ไม่เคยให้คำตอบที่ดีกว่าเลย บางครั้ง AI ก็พูดมั่วหรือเสนอสิ่งที่ใช้จริงไม่ได้ ให้ความรู้สึกเหมือนนกแก้วโง่ ๆ ที่เอาแต่ทวนเรื่องที่เคยได้ยินมา
คิดว่าถ้ามีความสามารถให้ AI แปลงข้อความเป็น regular expression ได้จะสะดวกมาก
ในบรรดาเครื่องมือ AI ทั้งหมดที่เคยใช้ สิ่งที่น่าผิดหวังที่สุดคือ Gemini ที่ฝังมาใน BigQuery แม้ชื่อคอลัมน์จะชัดเจนและมีคำอธิบายดี มันก็ยังเข้าใกล้การแก้ปัญหาไม่ได้เลย
ภาษาที่ผมเขียนคิวรีมากที่สุดจนถึงตอนนี้คือ SQL ต่อให้ขอให้ AI เขียนคิวรีให้ เวลาที่ต้องใช้เกลาและแก้ผลลัพธ์ก็ยังมากกว่าการเขียนเองเยอะ อีกเรื่องหนึ่งคือผมอยากได้ฟีเจอร์สักอย่างที่ช่วยให้เขียน SQL ได้เร็วขึ้นมาก DSL ของบริษัทเรามีโอเปอเรเตอร์ที่ auto join ตาม foreign key ซึ่งสะดวกมาก ส่วนที่น่ารำคาญที่สุดของการเขียน SQL คือการต้องเขียน join 10 หรือ 20 ตัวขึ้นไปด้วยมือ เรื่องอื่นเทียบกันแล้วยังไม่ยากเท่าไร
จากประสบการณ์ ถ้ามีข้อจำกัดที่ชัดเจนและกำหนด foreign key ไว้ดี แทบทุกอย่างก็จบ AI ต้องอาศัยข้อจำกัดที่ชัดเจนในแต่ละตารางเพื่อทำความเข้าใจโครงสร้างความเชื่อมโยงทั้งหมดได้อย่างถูกต้อง SQL เป็นสเปกที่แม่นยำมาก แต่ก็เพราะแบบนั้นเอง ถ้า constraints และ foreign key ไม่ได้กำหนดไว้อย่างดี AI ก็ไม่สามารถให้คำตอบที่ถูกต้องได้
ตอนนี้มันกลายเป็นเรื่องค่อนข้างง่ายแล้วสำหรับ foundation model แทบทุกตัว ถ้าใส่คอมเมนต์ใน schema ของตารางไว้ดี การขอให้สร้างคิวรีก็เป็นเรื่องง่าย
ถ้าสร้าง scaffolding รอบโมเดลด้วยไลบรารี smolagents ก็ใช้งานได้ค่อนข้างสะดวก มีบทความหนึ่งบอกว่า text2sql ดูเรียบง่ายในเดโม แต่การนำไปใช้กับเคสจริงที่ซับซ้อนนั้นยากมาก
Step 1: schema มีหลายพันตารางและแทบไม่มีคอมเมนต์เลย, Step 2...
เห็นด้วยมาก ตอนนี้แทบไม่มีความเป็นเวทมนตร์อะไรแล้ว DDL สำหรับสร้างตารางจริง ๆ ก็เป็นคำอธิบายที่แม่นยำของตารางอยู่แล้ว จนแทบไม่ต้องการอะไรมากกว่านั้น หากอธิบายคิวรีที่ต้องการอย่างละเอียด LLM ส่วนใหญ่ก็สร้างคิวรีได้ไม่ยาก
ในโพสต์ "Show HN: We open sourced our entire text-to-SQL product" (2024) มีแหล่งอ้างอิงที่ยอดเยี่ยม เช่น awesome-Text2SQL และ Awesome-code-llm > Benchmarks > Text to SQL