การสร้างระบบแปลงข้อความเป็น SQL ที่พร้อมใช้งานจริง: บรรลุคะแนน 88.15% บน Spider 1.0

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

ในการศึกษาครั้งนี้ เราได้ทำการวัดประสิทธิภาพData Agent ของเรา บนSpider 1.0และได้ผลลัพธ์ความแม่นยำในการประมวลผล 88.15%โดยใช้ โมเดล Gemma 4 26Bบทความนี้ไม่ได้มุ่งเน้นเฉพาะคะแนนการวัดประสิทธิภาพเพียงอย่างเดียว แต่ยังแบ่งปันการตัดสินใจด้านสถาปัตยกรรม บทเรียนทางวิศวกรรม และข้อมูลเชิงลึกจากการวัดประสิทธิภาพที่อยู่เบื้องหลังผลลัพธ์เหล่านี้ด้วย

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

เพื่อประเมินความสามารถเหล่านี้ เราได้ทำการทดสอบประสิทธิภาพของData Agent ของเรา บน Spider 1.0 ซึ่งเป็นเกณฑ์มาตรฐานการแปลงข้อความเป็น SQL ที่ใช้กันอย่างแพร่หลายที่สุด โดยใช้ โมเดล Gemma 4 26Bระบบของเราได้ผลลัพธ์ความแม่นยำในการประมวลผล 88.15%ซึ่งแสดงให้เห็นว่าสถาปัตยกรรมและการจัดการบริบทมีความสำคัญไม่แพ้การเลือกโมเดล

การเลือกเกณฑ์มาตรฐานที่เหมาะสมมีความสำคัญไม่แพ้การเลือกแบบจำลองที่เหมาะสม แม้ว่าชุดข้อมูลใหม่ๆ เช่น Spider 2.0 และ BIRD จะนำเสนอสถานการณ์ระดับองค์กรที่ซับซ้อนมากขึ้น แต่ Spider 1.0 ยังคงเป็นเกณฑ์มาตรฐานที่ได้รับการยอมรับอย่างกว้างขวางที่สุดสำหรับการประเมินระบบแปลงข้อความเป็น SQL และการเปรียบเทียบผลลัพธ์ในเอกสารต่างๆ

สำหรับการประเมินเบื้องต้น เราเลือกใช้ Spider 1.0 เนื่องจากเป็นมาตรฐานที่ได้รับการยอมรับและใช้เป็นเกณฑ์พื้นฐาน ทำให้เราสามารถวัดได้ว่า Data Agent ของเราเข้าใจโครงสร้างฐานข้อมูลที่ไม่เคยพบมาก่อนได้อย่างมีประสิทธิภาพเพียงใด และสร้างคำสั่ง SQL ที่ถูกต้องภายใต้สภาวะที่สมจริงได้อย่างไร

รูปที่ 2 สรุปผลการเปรียบเทียบ Spider 1.0 กับเกณฑ์มาตรฐานการแปลงข้อความเป็น SQL ที่ใช้กันทั่วไปอื่นๆ

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

Data Agentของเราได้รับการออกแบบให้เป็นไปป์ไลน์หลายขั้นตอนที่ค่อยๆ จำกัดขอบเขตของปัญหาให้แคบลงก่อนที่จะขอให้ LLM สร้างคำสั่ง SQL แทนที่จะเปิดเผยโครงสร้างฐานข้อมูลทั้งหมดให้กับโมเดล ระบบจะดึงเฉพาะโครงสร้างและข้อมูลบริบทที่เกี่ยวข้องก่อน จากนั้นจึงสร้างคำสั่ง SQL ตรวจสอบความถูกต้องของผลลัพธ์ และแก้ไขข้อผิดพลาดทั่วไปโดยอัตโนมัติก่อนที่จะดำเนินการ

ดังแสดงในภาพที่ 3สถาปัตยกรรมประกอบด้วยสามขั้นตอนหลัก:

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

สถาปัตยกรรมที่เน้นการใช้งานจริงนี้ได้รับแรงบันดาลใจจากแนวคิดที่นำเสนอในDIN-SQLและDAIL-SQLในขณะเดียวกันก็ปรับให้เข้ากับสภาพแวดล้อมระดับองค์กรที่ความน่าเชื่อถือ ความสามารถในการอธิบาย และความแข็งแกร่งมีความสำคัญเท่าเทียมกับความแม่นยำของเกณฑ์มาตรฐาน

การเลือกโมเดลภาษาที่เหมาะสมเป็นส่วนสำคัญของกระบวนการเปรียบเทียบประสิทธิภาพของเรา แทนที่จะประเมินเพียงโมเดลเดียว เราได้ทดลองใช้โมเดลภาษาแบบโอเพนซอร์สหลากหลายรุ่น รวมถึงLlama 3.1, Qwen 2.5, DeepSeek, SQLCoder, CodeGemma, Mistral, GPT-OSSและGemma 4

เพื่อให้การเปรียบเทียบมีความยุติธรรม เราจึงประเมินแต่ละโมเดลโดยใช้ความแม่นยำในการดำเนินการ (Execution Accuracy หรือ EA)ซึ่งเป็นตัวชี้วัดมาตรฐานสำหรับการวัดประสิทธิภาพการแปลงข้อความเป็น SQL แตกต่างจากตัวชี้วัดที่อิงตามไวยากรณ์ ความแม่นยำในการดำเนินการจะวัดว่า SQL ที่สร้างขึ้นนั้นให้ผลลัพธ์เหมือนกับคำสั่ง SQL อ้างอิงหรือไม่ ทำให้เป็นตัวบ่งชี้ประสิทธิภาพในโลกแห่งความเป็นจริงที่ดีกว่า

เส้นทางการทดสอบประสิทธิภาพของเราแสดงไว้ในรูปที่ 4เราเริ่มต้นด้วยการทดลองบนเวิร์กสเตชันในพื้นที่ซึ่งติดตั้งRTX 4060 (8 GB VRAM)โดยโมเดลขนาดเล็กช่วยให้เราสามารถทดสอบซ้ำได้อย่างรวดเร็วและตรวจสอบความถูกต้องของไปป์ไลน์ของเรา หลังจากสร้างพื้นฐานที่เสถียรโดยใช้ชุดคำถาม Spider 1.0 จำนวน 233 ข้อเราจึงย้ายไปยัง GPU บนคลาวด์เพื่อประเมินโมเดลขนาดใหญ่ขึ้นบน ชุด คำถามทดสอบประสิทธิภาพทั้งหมด 2,147 ข้อวิธีการแบบเป็นขั้นตอนนี้ช่วยให้เราสามารถปรับสถาปัตยกรรมให้เหมาะสมได้อย่างมีประสิทธิภาพก่อนที่จะลงทุนในการทดสอบประสิทธิภาพขนาดใหญ่

เราได้ประเมินโมเดลขั้นสุดท้ายบนชุดทดสอบ Spider 1.0 ฉบับสมบูรณ์ ซึ่งประกอบด้วยคำถาม 2,147 ข้อ ดังแสดงในตารางที่ 1 Gemma 4 26B ได้คะแนนสูงสุด (88.15%) ตามด้วย GPT-OSS 20B (86.63%) ผลลัพธ์เหล่านี้แสดงให้เห็นว่า LLM แบบโอเพนซอร์สที่ทันสมัย ​​เมื่อรวมกับไปป์ไลน์การดึงข้อมูลและการตรวจสอบความถูกต้องที่มีประสิทธิภาพ สามารถบรรลุประสิทธิภาพการแปลงข้อความเป็น SQL ที่แข่งขันได้ในระดับสูง 

คะแนนมาตรฐานจะมีคุณค่าก็ต่อเมื่อสามารถนำไปเปรียบเทียบกับงานวิจัยที่ตีพิมพ์ก่อนหน้านี้ได้ เพื่อให้เข้าใจถึงความสำคัญของผลลัพธ์ของเราได้ดียิ่งขึ้น เราจึงได้ทบทวนทั้งงานวิจัยด้านการแปลงข้อความเป็น SQL ในปัจจุบันและเอกสารมาตรฐานที่มีการอ้างอิงอย่างกว้างขวาง

ตารางที่ 2: อัตราความแม่นยำของโมเดลโอเพนซอร์สที่รายงานในการศึกษา SQL-of-Thought บนชุดข้อมูลย่อยของ Spider แสดงให้เห็นว่า เมื่อเปรียบเทียบกันแล้ว ผลลัพธ์ 88.15% ที่ได้ในงานวิจัยนี้ อยู่ในระดับที่สูงกว่า GPT-4o Mini (87%) และใกล้เคียงกับ GPT-5 (89%)

งานวิจัยล่าสุด เช่นSQL-of-Thought [1] รายงานว่าโมเดลปิดซอร์สชั้นนำ—รวมถึงClaude Opus 3, GPT-5และGPT-4o Mini—บรรลุความแม่นยำสูงบนชุดย่อยมาตรฐาน Spider แม้ว่าการเปรียบเทียบโดยตรงควรได้รับการตีความอย่างระมัดระวังเนื่องจากความแตกต่างในการตั้งค่าการประเมิน พรอมต์ และชุดย่อยมาตรฐาน แต่ความแม่นยำในการดำเนินการ 88.15% ของเรา แสดงให้เห็นว่าโมเดลโอเพนซอร์สสามารถบรรลุประสิทธิภาพภายในช่วงการแข่งขันเดียวกันได้

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

เรายังได้เปรียบเทียบผลลัพธ์ของเรากับเฟรมเวิร์ก Text-to-SQL ที่มุ่งเน้นการผลิต เช่นDIN-SQL [3] และDAIL- SQL ซึ่งรวมโมเดลภาษาขนาดใหญ่เข้ากับเทคนิคต่างๆ เช่น การเชื่อมโยงสคีมา การออกแบบข้อความแจ้งเตือน ความสอดคล้องในตัวเอง และการแก้ไขข้อผิดพลาด

ตารางที่ 3: ผลลัพธ์ความแม่นยำในการดำเนินการของวิธีการต่างๆ บน Spider 1.0 ในการศึกษา "Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation" [2] ซึ่งเผยให้เห็นผลกระทบต่อความแม่นยำไม่เพียงแต่การเลือกโมเดลเท่านั้น แต่ยังรวมถึงเทคนิคต่างๆ เช่น การออกแบบข้อความแจ้งเตือน การเชื่อมโยงสคีมา และความสอดคล้องในตัวเองด้วย

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

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

ข้อผิดพลาดบางส่วนเกิดจากเกณฑ์มาตรฐานเอง ในบางกรณี ความไม่สอดคล้องกันในคำสั่ง SQL อ้างอิง (gold) ทำให้การคาดการณ์ที่ถูกต้องตามหลักตรรกะถูกทำเครื่องหมายว่าไม่ถูกต้อง กรณีอื่นๆ เกี่ยวข้องกับคำถามภาษาธรรมชาติที่ไม่ชัดเจน หรือสถานการณ์การตัดสินหาคำตอบที่ถูกต้องเท่ากัน ซึ่งคำสั่ง SQL หลายคำสั่งอาจให้คำตอบที่ถูกต้องเท่าเทียมกันได้

นอกจากนี้ เรายังสังเกตเห็นพฤติกรรมเฉพาะของโมเดลหลายประการ รวมถึงการแปลงประเภทที่ไม่จำเป็น การจัดการความไวต่อตัวพิมพ์ใหญ่และตัวพิมพ์เล็กที่ไม่สอดคล้องกัน และการทำให้คำสั่ง SQL ที่ง่ายอยู่แล้วซับซ้อนเกินไปในบางครั้ง ผลการค้นพบเหล่านี้ตอกย้ำความสำคัญของการรวมกลไกการตรวจสอบความถูกต้องและการแก้ไขตนเองเข้าไว้ในไปป์ไลน์ของ Data Agent

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

ความแม่นยำสูงเป็นเพียงแง่มุมหนึ่งของระบบแปลงข้อความเป็น SQL ที่พร้อมใช้งานในระดับองค์กร ในสภาพแวดล้อมขององค์กรขนาดใหญ่ ต้นทุนด้านโครงสร้างพื้นฐาน ความเป็นส่วนตัวของข้อมูล และความยืดหยุ่นในการใช้งาน ล้วนเป็นสิ่งที่ต้องพิจารณาอย่างสำคัญเช่นกัน

ข้อได้เปรียบที่สำคัญอย่างหนึ่งของแนวทางของเราคือการใช้โมเดลภาษาแบบโอเพนซอร์ส ทั้งหมด ตลอดกระบวนการพัฒนา เราสามารถทำการทดลองส่วนใหญ่ได้ในเครื่องโลคอลโดยใช้การ์ดจอRTX 4060 (VRAM 8 GB) ระดับผู้บริโภค ทำให้เราสามารถทดสอบซ้ำได้อย่างรวดเร็วโดยไม่ต้องเสียค่าใช้จ่ายใดๆ สำหรับ API หรือโทเค็น การทดสอบประสิทธิภาพขนาดใหญ่จะดำเนินการบน GPU เฉพาะบนระบบคลาวด์หลังจากที่สถาปัตยกรรมได้รับการตรวจสอบแล้วเท่านั้น

เราใช้ RunPod Secure Cloud สำหรับการประเมิน Spider 1.0 อย่างเต็มรูปแบบ การทดสอบ Gemma 4 26B ดำเนินการบนGPU A100 PCIe 80 GBในขณะที่GPT-OSS 20BทำงานบนGPU RTX 6000 48 GB

ค่าใช้จ่ายด้านโครงสร้างพื้นฐานสรุปไว้ในตารางที่ 4

แม้ว่าการทดสอบประสิทธิภาพครั้งใหญ่ที่สุดจะต้องการโครงสร้างพื้นฐานบนคลาวด์ แต่กระบวนการพัฒนาโดยรวมยังคงประหยัดต้นทุนได้ด้วยการทดลองในระดับท้องถิ่นและโมเดลโอเพนซอร์ส ที่สำคัญกว่านั้น สถาปัตยกรรมที่ได้สามารถนำไปใช้งานได้อย่างสมบูรณ์ภายในโครงสร้างพื้นฐานขององค์กรเอง ซึ่งช่วยลดการพึ่งพา API ภายนอก ในขณะเดียวกันก็ช่วยให้ควบคุมความเป็นส่วนตัวของข้อมูล การปฏิบัติตามกฎระเบียบ และต้นทุนการดำเนินงานได้ดียิ่งขึ้น

ด้วยเหตุนี้ สถาปัตยกรรมนี้จึงเหมาะสมอย่างยิ่งสำหรับองค์กรที่ดำเนินงานในสภาพแวดล้อมที่คำนึงถึงความเป็นส่วนตัว มีกฎระเบียบ หรือแยกขาดจากเครือข่ายภายนอก ซึ่งความปลอดภัยของข้อมูลและความยืดหยุ่นในการใช้งานเป็นสิ่งสำคัญอย่างยิ่ง

เกณฑ์มาตรฐานให้วิธีการที่เป็นกลางในการประเมินระบบ AI แต่ไม่ใช่เป้าหมายสูงสุด คะแนนเกณฑ์มาตรฐานที่สูงจะมีค่าก็ต่อเมื่อสามารถนำไปสู่ประสิทธิภาพที่เชื่อถือได้ในการใช้งานจริงเท่านั้น

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

ความแม่นยำในการประมวลผล 88.15%ของเราบน Spider 1.0 แสดงให้เห็นว่าโมเดลโอเพนซอร์ส เมื่อรวมกับสถาปัตยกรรมที่ออกแบบมาอย่างดี สามารถมอบประสิทธิภาพที่แข่งขันได้สูงสำหรับงานแปลงข้อความเป็น SQL ระดับองค์กร ที่สำคัญกว่านั้น คือเป็นการยืนยันหลักการออกแบบเบื้องหลังData Agent ของเรา ซึ่งสร้างขึ้นมาเพื่อให้ทำงานได้อย่างน่าเชื่อถือบนฐานข้อมูลระดับองค์กรที่ซับซ้อน ไม่ใช่แค่บนชุดข้อมูลมาตรฐานเท่านั้น

Spider 1.0 ถือเป็นก้าวสำคัญ แต่เป็นเพียงจุดเริ่มต้นของการเดินทางของเรา ขั้นตอนต่อไปของเราคือการประเมิน Data Agent บนSpider 2.0การทดสอบประสิทธิภาพในระดับองค์กรขนาดใหญ่ และที่สำคัญที่สุดคือสภาพแวดล้อมของลูกค้าจริง ซึ่งมีโครงสร้างฐานข้อมูลที่ใหญ่กว่ามากและคำถามทางธุรกิจที่ซับซ้อนกว่ามาก

วิสัยทัศน์ระยะยาวของเราไม่ใช่แค่การสร้างเครื่องมือสร้าง SQL ที่ดีกว่าเท่านั้น เรามุ่งมั่นที่จะสร้างตัวแทนข้อมูลอัจฉริยะที่ช่วยให้องค์กรต่างๆ สามารถโต้ตอบกับข้อมูลระดับองค์กรได้อย่างเป็นธรรมชาติราวกับการสื่อสารกับเพื่อนร่วมงาน โดยผสานรวมการดึงข้อมูล การให้เหตุผล การตรวจสอบความถูกต้อง และ AI ที่อธิบายได้ เข้าไว้ในแพลตฟอร์มสนับสนุนการตัดสินใจที่เชื่อถือได้

การเปรียบเทียบมาตรฐานไม่ได้หมายถึงแค่การวัดความแม่นยำเท่านั้น แต่ยังหมายถึงการทำความเข้าใจว่าทำไมระบบจึงประสบความสำเร็จหรือล้มเหลว

ตลอดการประเมิน เราพบรูปแบบข้อผิดพลาดที่เกิดขึ้นซ้ำๆ หลายประการ บางส่วนเกิดจากความกำกวมในตัววัดประสิทธิภาพเอง รวมถึงความไม่สอดคล้องกันในคำสั่ง SQL อ้างอิง และเงื่อนไขการเรียงลำดับที่ไม่ระบุชัดเจน ส่วนอื่นๆ สะท้อนให้เห็นถึงพฤติกรรมทั่วไปของ LLM เช่น การแปลงชนิดข้อมูลที่ไม่จำเป็น หรือการจัดการค่าที่คำนึงถึงตัวพิมพ์ใหญ่และตัวพิมพ์เล็กที่ไม่สอดคล้องกัน

ข้อสังเกตเหล่านี้ตอกย้ำข้อค้นพบหลักข้อหนึ่งของงานวิจัยของเรา นั่นคือสถาปัตยกรรมมีความสำคัญพอๆ กับการเลือกแบบจำลองการดึงข้อมูล การเชื่อมโยงแบบแผน การตรวจสอบความถูกต้อง และการแก้ไขตนเอง ล้วนมีส่วนช่วยต่อประสิทธิภาพโดยรวมมากพอๆ กับแบบจำลองภาษาพื้นฐาน

แม้ว่าข้อจำกัดของเกณฑ์มาตรฐานจะส่งผลต่อคะแนนสุดท้ายอย่างหลีกเลี่ยงไม่ได้ แต่การวิเคราะห์ของเราชี้ให้เห็นว่า การปรับปรุงเพิ่มเติมในการจัดการบริบทและการตรวจสอบความถูกต้อง อาจผลักดันให้ระบบบรรลุความแม่นยำในการดำเนินการเกิน 90% ได้

Spider 1.0 เป็นพื้นฐานสำคัญในการประเมิน Data Agent ของเรา แต่เป็นเพียงก้าวแรกสู่การพัฒนา AI ระดับองค์กรให้พร้อมใช้งานจริง

เป้าหมายต่อไปของเราคือการประเมินสถาปัตยกรรมบนเกณฑ์มาตรฐานที่ท้าทายยิ่งขึ้น เช่นSpider 2.0และที่สำคัญยิ่งกว่านั้นคือบนฐานข้อมูลระดับองค์กรจริง ซึ่งมีโครงสร้างข้อมูลขนาดใหญ่กว่ามาก เอกสารประกอบมักไม่สมบูรณ์ และคำถามทางธุรกิจมีความซับซ้อนกว่ามาก

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

อ้างอิง

[1] Saumya Chaturvedi, Aman Chadha, Laurent Bindschaedler arXiv. “SQL-of-Thought: Multi-agentic Text-to-SQL with Guided Error Correction.” arXiv. มิถุนายน 2026 https://arxiv.org/abs/2509.00581

[2] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, Jingren Zhou “การแปลงข้อความเป็น SQL เสริมศักยภาพโดยโมเดลภาษาขนาดใหญ่: การประเมินเกณฑ์มาตรฐาน” arXiv มิถุนายน 2026

https://arxiv.org/pdf/2308.15363 

[3] Mohammadreza Pourreza, Davood Rafiei. “DIN-SQL: การเรียนรู้แบบแยกส่วนในบริบทของการแปลงข้อความเป็น SQL พร้อมการแก้ไขตนเอง” arXiv. มิถุนายน 2026

https://arxiv.org/pdf/2304.11015

Dilşen YILDAR HAVAYLAR, 

วิศวกรซอฟต์แวร์อาวุโส, ปริญญาโท