NaturalSQL-7B - โมเดลทรงพลังสำหรับแปลงภาษาธรรมชาติเป็น SQL

 (github.com/cfahlgren1)
15 คะแนน โดย xguru 2024-02-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทำได้ 76.5% บน SQL-Eval ซึ่งแสดงประสิทธิภาพดีที่สุดเมื่อเทียบตามขนาดโมเดล
    • แม้จะยังด้อยกว่า GPT-4(83%) แต่เหนือกว่า GPT-3.5-Turbo(65%) / Claude-2(64.5%)
    • สูงกว่า sqlcoder-7b(71%) และใกล้เคียงกับ sqlcoder-15b(78%)
  • มีการพัฒนา ChatDB ซึ่งเป็นเครื่องมือที่ช่วยสร้างแดชบอร์ดแบบ no-code ได้โดยไม่ต้องเขียน SQL

ตัวอย่าง

  • คำถาม: จงระบุลูกค้าที่มียอดสั่งซื้อรวมสูงที่สุดในเดือนที่แล้ว และแสดงรายการสินค้าทั้งหมดพร้อมจำนวนที่ลูกค้ารายนั้นสั่งซื้อ
  • ผลลัพธ์: 
    WITH LastMonthOrders AS (  
  SELECT o.customerid, o.orderid, op.productid, op.quantity, p.productname, op.quantity * p.unitprice AS total_order_value  
  FROM orders o  
  JOIN order_details op ON o.orderid = op.orderid  
  JOIN products p ON op.productid = p.productid  
  WHERE o.orderdate >= date_trunc('month', CURRENT_DATE) - INTERVAL '1 month'  
  AND o.orderdate < date_trunc('month', CURRENT_DATE)  
),  
CustomerTotalOrderValue AS (  
  SELECT customerid, SUM(total_order_value) AS total_value  
  FROM LastMonthOrders  
  GROUP BY customerid  
  ORDER BY total_value DESC  
  LIMIT 1  
)  
SELECT c.customerid, c.companyname, lm.productid, lm.productname, lm.quantity  
FROM CustomerTotalOrderValue ctov  
JOIN LastMonthOrders lm ON ctov.customerid = lm.customerid  
JOIN customers c ON c.customerid = lm.customerid;
  • NaturalQuery ทำงานได้ดีมากกับคำถามซับซ้อนแบบข้างต้น รวมถึงซับคิวรีและอัตราส่วน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
xguru 2024-02-07

ความเห็นจาก Hacker News

  • คะแนนประสิทธิภาพบน SQL-Eval อยู่ที่ 76.5% ซึ่งตามหลัง GPT-4 ที่ 83% และ sqlcoder-15b ที่ 78% อยู่เล็กน้อย

    • แอปพลิเคชันแบบไหนบ้างที่ AI data science intern ลักษณะนี้จะมีประโยชน์? เราจะสร้างอะไรได้ด้วย AI ที่มีความแม่นยำ 75%?
    • ในฐานะโปรแกรมเมอร์ที่ต้องคอยเปิดเอกสารอ้างอิงเวลาทำงานกับ SQL บ่อย ๆ คิดว่าน่าจะใช้ AI แบบนี้ช่วยร่าง query ฉบับแรกได้
    • โมเดลขนาดใหญ่อาจให้ผลลัพธ์ที่ดีกว่าในเคสเดียว แต่ก็สามารถรันโมเดล 15b บน m1 64GB ได้อย่างสบาย
    • ในสภาพแวดล้อมองค์กร บางครั้งก็ไม่อยากให้ข้อมูล schema หลุดเข้าไปในข้อมูลฝึกของ OpenAI และก็มีกรณีที่อยากรัน query แบบออฟไลน์ด้วย
    • ถ้าต้องรัน query จำนวนมาก โมเดลขนาดเล็กที่รันแบบโลคัลก็มีประโยชน์มาก (ช่วยลดต้นทุน)
    • การมีนักวิทยาศาสตร์ข้อมูลขนาดจิ๋วให้คนที่ไม่ใช่สายเทคนิคถามได้ก็ดูน่าสนใจ แต่ก็สงสัยว่าจะรู้ได้อย่างไรว่าคำตอบนั้นอยู่ใน 25% ที่ "ไม่ถูกต้อง"
    • อาจเพิ่มอัตราความสำเร็จโดยรวมได้ด้วยอัลกอริทึมฉันทามติแบบ RAID ที่ให้ AI หลายตัวช่วยตรวจคำตอบของกันและกัน
    • ความเห็นพวกนี้ส่วนใหญ่เป็นการเรียบเรียงความคิดของตัวเอง แต่คนอื่นอาจมีไอเดียมากกว่านี้ก็ได้ ยินดีกับการเปิดตัวของ OP!

  • คิดว่าโมเดล text-to-SQL กำลังแก้ปัญหาไม่ตรงจุด

    • ส่วนที่ยากไม่ใช่เรื่องไม่รู้ไวยากรณ์หรือไม่รู้ว่าจะเขียน query แบบ group by ยังไง แต่คือการเข้าใจความหมายของข้อมูล
    • เวลาดูตาราง 50 คอลัมน์ใน Snowflake ก็เดาไม่ได้จากชื่อคอลัมน์อย่างเดียวว่ามันคืออะไร
    • ตัวอย่างเช่น ถ้ามีตารางที่มีคอลัมน์ 10 ตัวลงท้ายด้วย ...price ทั้งหมด ก็ต้องไปเปิดวิกิหรืออ่านนิยาม DBT ถึงจะรู้ความหมายจริง ๆ
    • จึงเชื่อถือ query ที่โมเดลสร้างขึ้นไม่ได้ เพราะโมเดลเข้าใจแค่ไวยากรณ์ของ query ไม่ได้เข้าใจตัวข้อมูล

  • มีคนชี้ว่านี่ไม่ใช่โอเพนซอร์ส เพราะมีข้อจำกัดตามการใช้งาน จึงน่าจะเรียกว่า "source available" มากกว่า

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

    • นักวิเคราะห์ส่วนใหญ่น่าจะเขียนอะไรแบบนี้ได้แม้ตอนหลับอยู่
    • เคยลองใช้ ChatGPT เขียน SQL แล้วรู้สึกว่ายังธรรมดา แต่ก็น่าจะดีขึ้นแน่นอน

  • เช่นเดียวกับหลายกรณีการใช้งานของ AI มันเหมาะมากสำหรับใช้เป็น "เมล็ดตั้งต้น" โดยเฉพาะเวลาจะเสนอไอเดียอย่างการจัดกลุ่มตามช่วงค่า

    • แต่ปัญหาของฐานข้อมูลแทบทั้งหมดอยู่ที่รายละเอียด
    • แต่ละผลิตภัณฑ์ตีความคำว่า "จำนวน" ไม่เหมือนกัน (เช่น กล่องเทียบกับชิ้น) คูปองและส่วนลดก็ถูกโมเดลแบบแปลก ๆ และน้ำหนักก็อาจถูกสมมติเป็นปอนด์/กิโลกรัมแล้วปนกันโดยไม่ระบุหน่วย เป็นต้น

  • คนที่บอกว่ามันไร้ประโยชน์เพราะถูกต้องแค่ 75% ควรคำนึงถึงสองอย่างนี้:

    • นี่คือเวอร์ชันแรก และมันก็มีประโยชน์ต่อ product owner กับนักวิเคราะห์มากกว่า Airtable แบบไหนก็ตามที่นึกออกได้เป็นพันเท่าแล้ว
    • แม้อยากให้ทุกอย่างแม่นยำกับทุกโจทย์ แต่โลกเราตอนนี้ก็อยู่ในเศรษฐกิจแบบ "ดีพอใช้" อยู่แล้ว และถ้ามันใกล้เคียงพอ ก็น่าจะดีพอสำหรับธุรกิจ

  • อยากรู้ว่ามันทำได้แค่ไหนบน Bird ซึ่งเป็น benchmark ที่ซับซ้อนและสมจริงกว่า

  • จากประสบการณ์ที่เคยทำงานสายข้อมูล หลายคนมีหน้าที่รับคำถามจากผู้บริหาร เข้าใจ data warehouse มากพอที่จะเขียน SQL มาตอบคำถามนั้น และบางครั้งก็ต้องส่งคำตอบในรูปแบบที่จัดสวยงาม

    • บางครั้งยังต้องคาดเดาคำถามต่อเนื่องจากผู้บริหาร เช่น "ทำไมตัวเลขนี้ต่ำขนาดนี้? มันไม่น่าจะต่ำขนาดนั้นนะ" จึงต้องขอให้ data engineer ช่วยตรวจว่ามีบั๊กหรือไม่
    • เช่นเดียวกับ LLM ทั้งหลาย ยังไม่แน่ใจว่าสิ่งนี้จะทำให้ความรับผิดชอบนั้นง่ายขึ้นมาก หรือจะทำให้มันหายไปเลย

  • เจ๋งมาก แต่ใบอนุญาตทำให้มันดูเหมือนโอเพนซอร์สทั้งที่จริงไม่ใช่มาตรฐาน

    • ตัวโมเดลจริงอยู่ที่นี่: NaturalSQL-6.7B-v0
    • ดูเหมือนจะเป็น base model ที่ดีมาก แต่ก็สงสัยว่า text-to-sql เป็น use case ที่เหมาะกับโมเดลขนาดเล็กหรือไม่
    • พวกเราก็กำลังพัฒนาเครื่องมือในสายนี้อยู่ และหวังว่าอยากใช้ gpt-4 ที่น่าจะ "รู้คำตอบ" ได้ดีกว่า แม้แต่ gpt 3.5 ก็ยังไม่พอสำหรับงาน production

  • เจ๋งมาก แต่อยากรู้ว่าไลเซนส์นี้จะใช้ร่วมกับ Vanna ได้หรือไม่