Vanna.ai: สนทนากับฐานข้อมูล SQL

 (github.com/vanna-ai)
3 คะแนน โดย GN⁺ 2024-01-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Vanna 2.0 เป็นเครื่องมือที่แปลงคำถามภาษาธรรมชาติให้เป็น SQL และคำตอบจากข้อมูล พร้อมรองรับความปลอดภัยระดับองค์กรและการจัดการสิทธิ์ตามผู้ใช้
  • เวอร์ชันใหม่ใช้แนวทาง รับรู้ผู้ใช้ ในทุกเลเยอร์ ตั้งแต่ system prompt, การรันเครื่องมือ ไปจนถึงการกรอง SQL และมี row-level security, audit logs และ rate limiting
  • เว็บคอมโพเนนต์ <vanna-chat> สามารถฝังลงในหน้าเว็บเดิมได้ และแสดงสถานะความคืบหน้า, โค้ด SQL, ตาราง, กราฟ Plotly และสรุปภาษาธรรมชาติผ่าน การสตรีมแบบเรียลไทม์
  • รองรับ LLM หลายตัว เช่น OpenAI, Anthropic, Ollama, Azure, Google Gemini, AWS Bedrock, Mistral และฐานข้อมูลหลายชนิด เช่น PostgreSQL, MySQL, Snowflake, BigQuery, SQLite, SQL Server, DuckDB
  • เมื่อต้องการอัปเกรดจาก Vanna 0.x เป็น 2.0 API จะเปลี่ยนจากแบบที่มี VannaBase เป็นศูนย์กลางไปเป็น API แบบ Agent พร้อมเส้นทางการห่อใช้งานอย่างรวดเร็วผ่าน LegacyVannaAdapter หรือการไมเกรตแบบค่อยเป็นค่อยไป

แปลงคำถามภาษาธรรมชาติเป็นคำตอบจากข้อมูลบน SQL

  • Vanna 2.0 เป็นโปรเจกต์ที่ทำงานตามโฟลว์ “Natural language → SQL → Answers”
  • ผู้ใช้ถามด้วยภาษาธรรมชาติ และได้รับผลลัพธ์ต่อไปนี้
    • สถานะความคืบหน้าแบบสตรีมมิง
    • บล็อกโค้ด SQL
    • ตารางข้อมูลแบบอินเทอร์แอคทีฟ
    • กราฟที่ใช้ Plotly
    • สรุปเป็นภาษาธรรมชาติ
  • โดยค่าเริ่มต้น บล็อกโค้ด SQL จะแสดงเฉพาะกับ ผู้ใช้ admin เท่านั้น
  • ผลลัพธ์ทั้งหมดจะถูกสตรีมแบบเรียลไทม์ผ่านเว็บคอมโพเนนต์

ฟีเจอร์หลักที่เพิ่มใน 2.0

  • User-Aware at Every Layer

    • คิวรีจะถูกกรองโดยอัตโนมัติตามสิทธิ์ของผู้ใช้

  • Modern Web Interface

    • มีคอมโพเนนต์ <vanna-chat> ที่สร้างไว้ล่วงหน้าให้ใช้งาน

  • Streaming Responses

    • แสดงตาราง กราฟ และความคืบหน้าแบบเรียลไทม์

  • Enterprise Security

    • รวม row-level security, audit logs และ rate limiting

  • Production-Ready

    • มีการผสานกับ FastAPI, observability และ lifecycle hooks

เว็บคอมโพเนนต์และการผสานกับฟรอนต์เอนด์

  • <vanna-chat> เป็น เว็บคอมโพเนนต์ ที่สามารถฝังลงในหน้าเว็บเดิมได้
  • ตัวอย่างเป็นวิธีโหลดสคริปต์ vanna-components.js แล้วกำหนด sse-endpoint และ theme
  • สามารถใช้คุกกี้และ JWT เดิมได้
  • ทำงานได้ใน React, Vue และ HTML ทั่วไป
  • รองรับ UI แบบ responsive และธีมสว่าง/มืด

โครงสร้างความปลอดภัยแบบรับรู้ผู้ใช้

  • Vanna 2.0 ส่งต่อ ตัวตนผู้ใช้ ไปยัง system prompt, การรันเครื่องมือ และการกรอง SQL
  • ใช้แนวคิดต่อไปนี้เพื่อจัดการสิทธิ์ตามผู้ใช้
    • User Resolver: ผู้ใช้กำหนดลอจิกสำหรับดึงตัวตนผู้ใช้จากคำขอ เช่น คุกกี้, JWT
    • User-Aware Tools: ตรวจสอบสิทธิ์ของเครื่องมือตามการเป็นสมาชิกกลุ่มของผู้ใช้
    • Row-level security: กรองคิวรีโดยอัตโนมัติตามสิทธิ์ของผู้ใช้
    • Audit logs: ติดตามทุกคิวรีตามผู้ใช้เพื่อการปฏิบัติตามข้อกำหนด
    • Rate limiting: ใช้โควตาตามผู้ใช้ผ่าน lifecycle hooks

โฟลว์การทำงาน

  • โฟลว์ตัวอย่างคือผู้ใช้พิมพ์ “Show Q4 sales” ใน <vanna-chat>
  • ฟรอนต์เอนด์ส่งคำขอไปยัง /api/vanna/v2/chat_sse พร้อมข้อมูลยืนยันตัวตน
  • เซิร์ฟเวอร์ส่งข้อมูลผู้ใช้ เช่น User(id=alice, groups=[read_sales]) ไปยัง Agent
  • Agent รันเครื่องมือ SQL แบบรับรู้ผู้ใช้ และเครื่องมือจะใช้ row-level security
  • ผลลัพธ์ที่ผ่านการกรองจะถูกสตรีมเป็นตาราง กราฟ และสรุปไปแสดงใน UI

การผสานฝั่งเซิร์ฟเวอร์และการยืนยันตัวตน

  • Vanna สามารถผสานกับแอป FastAPI และระบบยืนยันตัวตนเดิมได้
  • ตัวอย่างการตั้งค่าใช้โฟลว์ดังนี้
    • สืบทอด UserResolver เพื่ออ่านโทเค็นจากเฮดเดอร์ Authorization
    • ใช้ลอจิกถอดรหัส JWT เดิมเพื่อประกอบข้อมูล ID ผู้ใช้, อีเมล และกลุ่ม
    • ลงทะเบียน AnthropicLlmService, RunSqlTool และ SqliteRunner
    • เชื่อม Agent เข้ากับบริการ LLM, tool registry และ user resolver
    • เพิ่ม chat routes ให้กับแอป FastAPI ด้วย register_chat_routes
  • หลังลงทะเบียนแล้วจะใช้งาน streaming endpoint POST /api/vanna/v2/chat_sse ได้
  • สามารถให้ GET / เว็บ UI เป็นตัวเลือกเพิ่มเติมได้
  • ฝั่งฟรอนต์เอนด์เชื่อมต่อในรูปแบบ <vanna-chat sse-endpoint="/api/vanna/v2/chat_sse"></vanna-chat>

สแตกที่รองรับ

  • LLM รองรับ OpenAI, Anthropic, Ollama, Azure, Google Gemini, AWS Bedrock, Mistral เป็นต้น
  • ฐานข้อมูล รองรับ PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, SQLite, Oracle, SQL Server, DuckDB, ClickHouse เป็นต้น
  • การยืนยันตัวตนใช้ระบบเดิมได้ตามเดิม โดยรองรับคุกกี้, JWT และ OAuth token
  • เฟรมเวิร์กรองรับ FastAPI และ Flask

ฟีเจอร์ขยาย

  • Custom tools

    • สามารถขยายคลาสพื้นฐาน Tool เพื่อเพิ่มเครื่องมือให้เหมาะกับ use case เฉพาะได้
    • ตัวอย่าง EmailTool กำหนดสิทธิ์ send_email ใน access_groups และเมื่อรันจะได้รับ context.user ที่ถูกฉีดให้อัตโนมัติ

  • Lifecycle Hooks

    • สามารถเพิ่มการตรวจสอบโควตา, การล็อกแบบกำหนดเอง และการกรองเนื้อหาในจุดสำคัญของ request lifecycle ได้

  • LLM Middlewares

    • สามารถทำ caching, prompt engineering และการติดตามค่าใช้จ่ายรอบการเรียก LLM ได้

  • Conversation Storage

    • สามารถบันทึกและค้นหาประวัติการสนทนาตามผู้ใช้ได้

  • Observability

    • มี tracing ในตัวและการผสาน metrics

  • Context Enrichers

    • สามารถเพิ่ม RAG, memory และเอกสารเพื่อเสริมคำตอบของ Agent ได้

  • Agent Configuration

    • สามารถควบคุม streaming, temperature, จำนวนรอบทำซ้ำสูงสุด เป็นต้น

use case ที่เหมาะสม

  • แอปพลิเคชันวิเคราะห์ข้อมูล ที่ต้องการอินเทอร์เฟซภาษาธรรมชาติ
  • SaaS แบบ multi-tenant ที่ต้องการสิทธิ์ตามผู้ใช้
  • ทีมที่ต้องการเว็บคอมโพเนนต์และแบ็กเอนด์ที่สร้างไว้ล่วงหน้า
  • สภาพแวดล้อมองค์กรที่มีข้อกำหนดด้านความปลอดภัยและการตรวจสอบ
  • แอปพลิเคชันที่ต้องการคำตอบแบบสตรีมมิงที่สมบูรณ์ พร้อมตาราง กราฟ และ SQL
  • แอปพลิเคชันที่ต้องผสานกับระบบยืนยันตัวตนเดิม

การไมเกรตจาก 0.x เป็น 2.0

  • Vanna 2.0 เป็น การเขียนใหม่ทั้งหมด โดยเน้น Agent ที่รับรู้ผู้ใช้และการ deploy สำหรับ production
  • การเปลี่ยนแปลงหลักมีดังนี้
    • ใช้ API แบบ Agent แทนเมธอดของคลาส VannaBase
    • ทุกคอมโพเนนต์รับรู้ตัวตนผู้ใช้
    • สตรีมคอมโพเนนต์ UI ที่มีรายละเอียด แทนข้อความและ dataframe
    • เป็นโครงสร้างแบบ web-first ที่มีคอมโพเนนต์ <vanna-chat> และเซิร์ฟเวอร์ในตัว
  • มีเส้นทางไมเกรตสองแบบ
    • ใช้ LegacyVannaAdapter ห่ออินสแตนซ์ Vanna 0.x เดิม เพื่อใช้งานเว็บ UI ใหม่ได้ทันที
    • ค่อย ๆ ย้ายไปยัง Agent API และเครื่องมือแบบใหม่
  • คู่มือแบบทีละขั้นตอนอยู่ที่ Migration Guide

เอกสารและการสนับสนุน

  • Full Documentation: คู่มือฉบับเต็มและ API reference
  • Quickstart: เริ่มต้นด้วยข้อมูลตัวอย่าง
  • Configure: เอกสารการตั้งค่า
  • GitHub Discussions: คำขอฟีเจอร์และ Q&A
  • GitHub Issues: รายงานบั๊ก
  • อีเมลสำหรับการสนับสนุนระดับองค์กรคือ support@vanna.ai
  • ไลเซนส์คือ MIT License

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

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

 
GN⁺ 2024-01-15
ความคิดเห็นจาก Hacker News

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

    • เห็นด้วยมาก ฉันเคยลองเอา AI มาต่อกับฐานข้อมูลของตัวเองเพื่อให้ “สนทนา” ได้ แต่ผลลัพธ์ไม่ค่อยดี
      ตอนที่มันตอบถูกก็น่าประทับใจ แต่ฉันเสียเวลาไปมากกับการเติมข้อมูลลงในพรอมป์ตเรื่อย ๆ เพื่ออธิบายว่าข้อมูลถูกจัดวางอย่างไร
      ไม่ได้คาดหวังว่า LLM ไหนจะเข้าใจเองอยู่แล้ว เพราะถ้าเป็นคนอื่นฉันก็คงต้องอธิบายแบบเดียวกัน การเก็บ “เอกสาร” แบบนี้ให้ทันสมัยอาจมีคุณค่า แต่ก็ไม่สามารถคาดเดาคำถามทั้งหมดที่ผู้ใช้จะถามได้ และมันพลาดบ่อยเกินไปจนฉันคิดว่าไม่ควรเปิดสิทธิ์เข้าถึง AI นี้
      ฐานข้อมูลนี้ใช้กับงานขาย ดังนั้นการปล่อยตัวเลขผิด ๆ ออกไปก็แย่พอ ๆ กับแดชบอร์ดที่ “โกหก”
      ฐานข้อมูลสำหรับเดโมไม่ได้เป็นตัวแทนของแอปพลิเคชันที่เปิดใช้จริง ดังนั้นเดโม AI เลยดูเหมือนมีอัตราความสำเร็จสูงมาก
      ถ้าฐานข้อมูลของคุณเหมือนของฉันที่มีคอลัมน์เลิกใช้แล้ว หรือมีชื่อที่ทำให้คนอื่นสับสนได้ อัตราความผิดพลาดจะสูงขึ้นมาก
    • สมมติฐานของเราคือ ตอนนี้กำลังมีทั้ง ช่วงเวลาแบบ Google และ ช่วงเวลาแบบ Tableau ค่อย ๆ เกิดขึ้นพร้อมกัน
      การจะทำให้สำเร็จจริงยังต้องมีทั้งการค้นพบและการลงมือทำอีกมาก แต่เขื่อนแตกไปแล้ว การได้ผ่านกระบวนการนี้ไปพร้อมกับลูกค้าจึงเป็นเรื่องที่น่าสนใจ
      ช่วงเวลาแบบ Google: ตอนนี้ AI สามารถเรียนรู้จากวิธีที่ทีมจัดการข้อมูลได้แล้ว ตอนที่ Google PageRank ออกมา เสิร์ชเอนจินแบบ Yahoo นั้นอาศัยการคัดสรรอย่างเข้มข้น และฝั่ง semantic web ก็กำลังใช้สคีมา XML/RDF เพื่อแมปข้อมูลทุกอย่างด้วยมือ
      Google เข้ามาแทนที่งานที่ช้าและแพง ด้วยวิธีที่ง่ายกว่า คุณภาพดีกว่า ขยายขนาดได้ และทนทานกว่า Louie.ai ก็เช่นกัน โดยถูกออกแบบให้พรีเทรนมาก่อนและเรียนรู้ต่อเนื่องจากการใช้งาน เพื่อให้คนทำงานด้านข้อมูลได้มีช่วงเวลาแบบ Google ของตัวเองเช่นกัน การมีเครื่องมือที่ทำงานไปพร้อมกับทีมเป็นสิ่งที่ทรงพลัง
      ช่วงเวลาแบบ Tableau: ทำให้เจ้าของโปรเจกต์หรือเจ้าของข้อมูลสามารถชี้นำสิ่งต่าง ๆ ได้มากขึ้นด้วยงานที่น้อยลง เดิมทีแดชบอร์ดต้องอาศัยการพัฒนาเว็บแบบคัสตอมระดับล่างจำนวนมาก แต่ Tableau ทำให้ง่ายขึ้นจน BI lead ที่เก่ง SQL และเข้าใจทั้งข้อมูลกับดีไซน์ สามารถไปได้ไกลและเร็วขึ้นมากโดยไม่ต้องมีทีมใหญ่
      การเข้าใจประเภทผู้ใช้และเพิ่ม abstraction เพื่อช่วยพวกเขา ส่งผลอย่างมากต่อความเร็วในการส่งมอบ ต้นทุน และคุณภาพ Looker ที่นำ LookML มาใช้และปูทางให้กระแส semantic layer ในปัจจุบันก็คล้ายกัน
      เพื่อให้รับประกันคุณภาพและความปลอดภัยได้ Louie.ai จึงลงทุนมากกับ abstraction ในระดับเดียวกันเพื่อทำให้ข้อมูลมีความเป็นบทสนทนามากขึ้น ส่วน AI เป็นของใหม่ แต่ฝั่ง data ops มีกรณีตัวอย่างมาก่อนเยอะแล้ว ในสภาพแวดล้อมแบบทีมหรือสถานการณ์ที่มีความเสี่ยงสูง การทำเรื่องนี้ให้ถูกต้องเป็นสิ่งสำคัญ
    • โดยรวมเห็นด้วย ผมคิดว่าควรใช้ ETL ต่อไป และสร้างคลังข้อมูลที่จัดการความละเอียดอ่อนส่วนใหญ่ที่จำเป็นสำหรับฐานข้อมูลเชิงปฏิบัติการออกไปแล้ว
      ถ้าอยู่บนคลังข้อมูลที่มีเมทาดาทาดี วิธีแบบนี้อาจทำงานได้ยอดเยี่ยม
    • ใช่เลย GPT-4 ทำได้ดีตั้งแต่แรกกับข้อมูลที่ถูกโมเดลมาอย่างดี แต่จะลำบากกับโมเดลข้อมูลที่สกปรกและไม่สมบูรณ์
      การทำเอกสารข้อมูลช่วยลดช่องว่างนั้นได้อย่างชัดเจน
      แต่ประเด็นสุดท้ายที่พูดถึงไม่ใช่เรื่องใหม่ ทีม BI รับเครดิตไป ส่วนปัญหากลับถูกโยนให้วิศวกรข้อมูล เป็นเรื่องที่มีมานานแล้ว
      ตรงกันข้าม เครื่องมืออย่าง vanna.ai หรือ getdot.ai อาจทำให้วิศวกรกับฝั่งธุรกิจใกล้กันมากขึ้นได้ นำไปสู่บทสนทนาที่ตรงไปตรงมามากขึ้น ผลกระทบที่มากขึ้น และงบประมาณที่มากขึ้น
      อนึ่ง ผมเป็นผู้ร่วมก่อตั้ง getdot.ai :)
    • ถ้า AI จะทำเรื่องนี้ได้ดีจริง มันต้องคอย “ฟัง” ข้อความ Slack การประชุมวิดีโอ การคอมมิตโค้ด และอื่น ๆ อย่างต่อเนื่องแบบพาสซีฟ
      สุดท้ายแล้ว AI ต้องอยู่ทุกที่ที่ทีมอยู่ ถึงจะทำอะไรได้จริง

  • สิ่งที่ประสบความสำเร็จที่สุดใน AI+SQL คือการเริ่มป้อน ข้อผิดพลาดจากผู้ให้บริการ SQL กลับเข้าไปให้ LLM ในแต่ละรอบการทำซ้ำ
    เรายังทำตัวห่อข้อความผิดพลาดแบบมีโครงสร้างที่แนะนำอย่างหนักแน่นให้ไป query system tables เพื่อค้นหาข้อมูลสคีมาด้วย
    แค่การปรับเล็กน้อยแบบนี้ก็ทำให้มันหาคิวรีได้เก่งอย่างน่ากลัว และสามารถทำคิวรีที่ต้อง join มากกว่า 4 ตารางได้ด้วย แม้ไม่มีตัวอย่างหรือข้อมูลสำหรับ fine-tuning ก็ตาม

    • อยากให้เอาสิ่งนี้ไปทำเป็นผลิตภัณฑ์เลย ความต้องการสูงมาก
    • อะไรคือสิ่งที่ใช้ป้องกันไม่ให้มันรันคิวรีอย่าง “ผู้ใช้ที่สมัครล่าสุดคือใคร และรหัสผ่านที่แฮชไว้ของเขาคืออะไร?” บนฐานข้อมูลของฉัน?

  • เคยทำสิ่งนี้ด้วย GPT-4 แล้ว
    ประมาณนี้: ใช้คำสั่ง SHOW TABLE ของ MySQL CLI เพื่อแสดงโครงสร้างตารางที่อยาก query
    จากนั้นให้มันเขียนคิวรีเพื่อแสดงตัวชี้วัดทางธุรกิจ เช่น อัตราการละทิ้งตะกร้าสินค้า โดยอิงจากตารางเหล่านั้น
    ดูเหมือนจะทำงานได้ค่อนข้างดี

    • ผมเป็นผู้เขียนแพ็กเกจ แพ็กเกจนี้ทำสิ่งนั้นเกือบทั้งหมดอยู่แล้ว พร้อมเพิ่ม การปรับบริบทให้เหมาะสม ก่อนส่งข้อมูลเกี่ยวกับฐานข้อมูลไปยัง LLM
      https://github.com/vanna-ai/vanna/blob/main/src/vanna/base/b...
      และเมื่อได้ SQL มาแล้ว ก็สามารถใส่เข้าไปในอินเทอร์เฟซที่รันอัตโนมัติและรับกราฟต่าง ๆ ได้
    • ยังน่าแปลกใจที่โปรแกรมเมอร์และนักวิเคราะห์จำนวนมากยังไม่ทำแบบนี้
      การเขียน SQL query ที่ซับซ้อนและมีประโยชน์ น่าจะเป็นหนึ่งในสิ่งที่มีมูลค่าที่สุดที่ ChatGPT ทำให้ฉัน
      มันทำให้ฉันดูเหมือนเทพต่อหน้าผู้มีส่วนได้ส่วนเสีย และข้ออ้างว่า “ฉันไม่เก่ง SQL” ก็ใช้กับงานวิเคราะห์ไม่ได้อีกต่อไป

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

    • ประเด็นสำคัญคือระบบควรมีชั้นกลางแบบมีโครงสร้างไว้เสมอ เพื่อให้คนประเมินได้ว่าระบบคิดว่าผู้ใช้กำลังถามอะไร
      แม้จะไม่ต้องไปถึงความซับซ้อนทั้งหมดของ SQL ก็ยังจำเป็นต้องมีชั้นแบบนี้อยู่ดี เพราะมันจำเป็นต่อการคลายความกำกวมด้วย
      “หนังของ Jon Favreau” เองก็ยังไม่ชัดเจนว่าเป็นหนังที่ Jon Favreau แสดง กำกับ หรือหมายถึง Jon Favreau คนอื่น
      แทนที่จะพยายามจัดการเรื่องสำคัญทั้งหมดจากภาษาธรรมชาติจนจบในครั้งเดียว ควรใช้ภาษาธรรมชาตินำผู้ใช้ไปสู่การผสมกันของนามธรรมย่อยๆ ที่ไม่กำกวมและให้เหตุผลได้ง่ายจะดีกว่า
    • เห็นว่ามีเหตุผลนะ แต่คนที่ยังยึดแนวคิดแบบนี้ต่อไปเรื่อยๆ น่าจะลำบากขึ้นในอนาคต
      ข้อได้เปรียบทางเทคนิคและศักยภาพนั้นเหนือกว่าปัญหาและความท้าทายอย่างชัดเจน และตัวอย่างนี้ก็เช่นกัน
      เราจำเป็นต้องปล่อยหลักการบางอย่างที่เคยมีประโยชน์ในอดีตแต่ตอนนี้ไม่เป็นเช่นนั้นแล้ว
    • ยังมีไอเดียในทิศทางตรงกันข้ามด้วย
      คือใช้ภาษาธรรมชาติที่ถูกจับไว้เป็น “ระบบเฝ้าดู” เพื่อเติมข้อมูลลง SQL เช่น มีบางอย่างคอยฟังฉัน แล้วสร้างฐานข้อมูลจากสิ่งที่ฉันพูด พร้อมจัดหมวดหมู่สิ่งของ หัวข้อ สถานที่ ผู้คน ฯลฯ ที่ถูกพูดถึง
      นับจำนวนครั้งที่เจอเหตุการณ์แบบเดียวกัน และถ้าฉันพูดว่า “ต้องซื้อของ” ก็สร้างตารางความถี่ “การซื้อของ” ขึ้นมา
      โดยพื้นฐานแล้วจะกลายเป็นการ query ทุกสิ่งที่พูดกับ Alexa และทำแผนที่พฤติกรรม นิสัย ผู้คน และสิ่งของได้
      ถ้าพูดว่า “เบอร์โทรของ Bob คือ BLAH” ก็ให้เพิ่ม Bob กับเบอร์ลงในตาราง “คนสุ่มที่เจอวันนี้” พร้อมใส่โน้ตว่า “เจอที่สวนสุนัข”
      มันคือการจดบันทึกตัวเองผ่านคำพูดให้กลายเป็นไดอารี
      ถ้าตั้งชื่อทริปว่า “Hike Mount Tam” ก็ให้บันทึกไว้ แล้วสร้างลิงก์ในตารางไปยังโฟลเดอร์รูปใน SpaceDrive9000.ai เพื่อให้มีเรื่องเล่าทั้งหมดพร้อมลิงก์รูปที่ถ่ายไว้

  • ผมก็กำลังหาวิธีแก้ปัญหาอยู่เหมือนกัน เลยติดตามผลิตภัณฑ์แนวนี้อยู่หลายตัว รวมถึงบางตัวที่ได้รับการสนับสนุนจาก YC ด้วย เป็นพื้นที่ที่น่าสนใจ
    Minds DB (YC W20) https://github.com/mindsdb/mindsdb
    Buster (YC W24) https://buster.so
    DB Pilot https://dbpilot.io
    และก็มีผลิตภัณฑ์นี้ด้วย

    • ไม่ใช่ผลิตภัณฑ์สาธารณะ แต่เมื่อไม่กี่เดือนก่อนมีงานนำเสนอจากทีม Alibaba ใน “ML⇄DB Seminar Series” ของ CMU
      พวกเขาเพิ่มการแก้ความหมายเชิงความหมายเข้าไปในโมเดลทรานส์ฟอร์เมอร์ NL2SQL ซึ่งเป็น “ขั้นตอน post-processing ที่ใช้กฎกับ SQL query ที่สร้างขึ้นครั้งแรกเพื่อระบุและแก้ไขข้อผิดพลาดด้านความหมาย”
      น่าสนใจว่าทีมลงทุน VC จะตามทันระดับความก้าวหน้าล่าสุดจากองค์กรขนาดใหญ่ได้หรือไม่
      [0] "Alibaba: Domain Knowledge Augmented AI for Databases (Jian Tan)" - https://www.youtube.com/watch?v=dsgHthzROj4&list=PLSE8ODhjZX...
      [1] "CatSQL: Towards Real World Natural Language to SQL
      Applications" - https://www.vldb.org/pvldb/vol16/p1534-fu.pdf
    • ตอนนี้กำลังทำ pilot ของ louie.ai กับองค์กรที่ค่อนข้างใหญ่หลายแห่งอยู่ ซึ่งอาจเกี่ยวข้องกัน
      กำลังขยายไปสู่การตอบสนองต่อเหตุการณ์ด้านความมั่นคงไซเบอร์ การจัดการภัยพิบัติทางธรรมชาติ การฉ้อโกงประกันภัย และงานวิเคราะห์เชิงพาณิชย์ทั่วไปอย่าง clickstream
      ต่างจากผลิตภัณฑ์ข้างบนเล็กน้อย เรามองว่าสำหรับทีมปฏิบัติการ SQL อย่างเดียวไม่พอ และยังต้องมี Python กับฐานข้อมูลเชิงปฏิบัติการอย่าง Splunk, OpenSearch, graph database และ Databricks ด้วย
      เพราะชุมชนเดิมที่มีอยู่ เราจึงลงทุนมากกว่ามากใน data visualization (GPU ฯลฯ) และเวิร์กโฟลว์ AI+กราฟ
      เราทำในรูปแบบที่ผู้ใช้ใช้งานโดยตรง คล้าย Python notebook และ dashboard แบบโต้ตอบ โดยโค้ดเป็นสิ่งที่เลือกใช้เมื่ออยากใช้หรือใช้เพื่อตรวจสอบผลลัพธ์จาก AI มากกว่า
      และยังมีรูปแบบการใช้งานแบบ embedded ใหม่สำหรับสร้างแอปและ dashboard แบบปรับแต่งที่ฝังการวิเคราะห์เชิงโต้ตอบไว้ด้วย
    • อยากให้เพิ่มIbis Birdbrainเข้าไปในรายการด้วย: https://ibis-project.github.io/ibis-birdbrain/
      Birdbrain เป็นบอตข้อมูลที่ขับเคลื่อนด้วย AI ซึ่งสร้างบน Ibis และ Marvin และรองรับ backend ฐานข้อมูลมากกว่า 18 แบบ
      รายละเอียดเพิ่มเติมดูได้ที่ https://github.com/ibis-project/ibis และ https://ibis-project.org
    • อยากให้สนใจ getdot.ai ด้วย
      เปิดตัวบน Hacker News ด้วยการวิเคราะห์ข้อมูลโพสต์ Hacker News: https://news.ycombinator.com/item?id=38709172
      ปัญหาหลักที่เห็นในพื้นที่นี้มีสองอย่าง
      1. การออกแบบอินเทอร์เฟซที่ดี: ถ้าใช้ Slack หรือ Teams ได้อยู่แล้ว ก็ไม่มีใครอยากได้เว็บแอปเพิ่มอีกตัว
      2. ต้องเรียนรู้ธุรกิจและโมเดลข้อมูลที่มักจะรกพอสมควรให้ดีพอ เพื่อจะตอบได้ถูกต้องเสมอหรือไม่ก็พูดว่า “ไม่รู้”
    • อยากรู้ว่ามีใครสรุปผลจากการลองใช้แต่ละผลิตภัณฑ์ไว้บ้างไหม
      ถ้ามีบทความที่สำรวจวงการนี้มาจนถึงตอนนี้ ผมก็อยากอ่าน

  • การมีสิ่งนี้อยู่ก็ดี แต่ก็น่ากังวลที่ใช้คำว่า “การฝึก” แม้จะใส่เครื่องหมายคำพูดก็ตาม
    ผมใช้เวลาเยอะมากในการอธิบายว่า RAG ทำงานอย่างไร และพยายามเน้นว่ามันไม่ได้รวมการฝึกหรือการปรับจูนละเอียด
    สิ่งที่ต้องมีคือการเตรียมข้อมูล การแบ่งเป็นชังก์ และการทำเวกเตอร์หากจำเป็น

    • ผมเป็นผู้เขียนแพ็กเกจ ถ้ามีข้อเสนอคำเรียกอื่นก็ยินดีรับ
      ปัญหาคือผู้ใช้ทั่วไปส่วนมากไม่เคยเจอ RAG มาก่อนเลย

  • พรอมป์ต์ค่อนข้างตรงไปตรงมา
    OpenAI: https://github.com/vanna-ai/vanna/blob/a4cdf7593ac0c584f7d74...
    Mistral: https://github.com/vanna-ai/vanna/blob/a4cdf7593ac0c584f7d74...

    • “ผลิตภัณฑ์” AI พวกนี้จำนวนมาก สุดท้ายแล้วก็แค่ป้อนข้อความให้ LLM ในรูปแบบที่ มีโครงสร้าง ใช่ไหม?

  • เยี่ยมมาก นี่เป็นแนวทางแบบ turnkey สำหรับเริ่มใช้ RAG กับ ฐานข้อมูล SQL ที่มีอยู่ได้อย่างรวดเร็ว
    พูดตรงๆ เวลาคนส่วนใหญ่บอกว่าอยากได้ “ChatGPT สำหรับธุรกิจของเรา” สิ่งที่พวกเขาต้องการจริงๆ ก็คือแบบนี้
    พวกเขาแค่อยากได้วิธีถามด้วยภาษาธรรมชาติแล้วรับคำตอบ และนี่ก็พาไปได้ไกลพอสมควร
    ดีมาก

    • ผมเป็นผู้เขียนแพ็กเกจ ขอบคุณนะ และจริงๆ แล้วนี่ก็ตรงกับสิ่งที่เราเห็นพอดี
      องค์กรต่างๆ ใช้เงินหลายล้านดอลลาร์เพื่อรวบรวมข้อมูลแบบมีโครงสร้างไว้ใน data warehouse แต่สุดท้ายก็ปล่อยทิ้งไว้ เพราะคนที่ต้องการข้อมูลไม่รู้ว่าจะ query ฐานข้อมูลอย่างไร

  • ผมเคยสร้างอะไรคล้ายๆ กันบนบริการรายงานที่ใช้ duckdb โดยรวมแล้วมันทำงานได้ดี แต่ก็เจอปัญหาบางอย่าง
    แม้ตั้งอุณหภูมิต่ำ GPT-4 ก็ยังหลุดจากตัวอย่างหรือสคีมาบ้างเป็นครั้งคราว เช่น บางทีก็ลืมตรวจสอบฟิลด์บางตัว
    บริการของเราโฮสต์ข้อมูลทั่วไป แต่ลูกค้าต้องการให้สร้างรายงานด้วยภาษาตามโดเมนของตัวเอง ถ้าพูดว่า “แสดง 10 สีอันดับบนสุด” ปัญหาคือก่อนอื่นต้องนิยามก่อนว่าสีคืออะไร ดังนั้นเราต้องสอนให้ลูกค้าช่วยชี้นำตัวสร้างรายงานไปทางคำศัพท์ทั่วไปมากขึ้นเล็กน้อย
    การดีบักพรอมป์ต์ LLM นั้นยาก ลูกค้าสามารถทำให้โมเดลสับสนได้ค่อนข้างง่าย
    สุดท้ายเราเลยต้องแสดง “คำอธิบาย” ของ query ที่สร้างขึ้นอีกครั้ง เพื่อให้เห็นว่าอะไรถูกใช้ไปบ้างในรายงาน

    • ผมกำลังสนใจจะสร้างหรือใช้งานระบบลักษณะคล้ายกันอยู่
      RAG แบบที่ Vanna.ai ใช้อยู่จะช่วยได้ไหม?
      ในกรณีที่ “บางครั้งมันลืมตรวจสอบฟิลด์บางตัว” เทคนิคพรอมป์ต์อย่าง chain-of-thought ช่วยให้ผลลัพธ์ดีขึ้นหรือเปล่า?
      ถ้าลูกค้าต้องคอยชี้นำตัวสร้างรายงานไปทางคำทั่วไปมากขึ้น คุณได้ลองอินเทอร์เฟซแบบเอเจนต์ที่ให้ LLM ถามคำถามเพิ่มก่อนตอบสุดท้ายหรือยัง?

  • ผมสงสัยว่ามีคนลองสิ่งนี้กับชุดข้อมูลของตัวเองแล้วประสบความสำเร็จไหม
    ที่บริษัท เรากำลังทำบอตที่ให้พนักงานคุยกับชุดข้อมูลแบบมีโครงสร้างภายใน ซึ่งก็คือตาราง MySQL ไม่กี่ตาราง โดยใช้เทคนิคคล้ายๆ กัน
    ในทางปฏิบัติมันก็พอใช้ได้ระดับหนึ่ง แต่มีความยากอยู่หลายอย่าง
    อย่างแรก เรามี enum และชนิดข้อมูลที่เฉพาะกับธุรกิจเยอะมาก ซึ่งไม่มีทางอยู่ในโมเดลพื้นฐานอยู่แล้ว เราเลยต้องนิยามสิ่งเหล่านี้ด้วยมือแล้วใส่ไว้ในบริบทของพรอมป์ต์ ซึ่งก็เหมือนกับการเพิ่มเอกสารใน Vanna.ai
    อย่างที่สอง คนมักถามคำถามเกี่ยวกับเวลาอย่าง “ปีที่ผ่านมาอุปสงค์เป็นเท่าไร?” ถ้าข้อมูลถูกเก็บเป็นรายไตรมาส ผมไม่รู้จะออกแบบพรอมป์ต์ให้โมเดลคำนึงถึงเวลาปัจจุบันและตีความเป็น “4 ไตรมาสล่าสุด” อย่างไร ตรงนี้พังบ่อยมาก
    อย่างที่สาม เพื่อให้มันสร้าง SQL ที่ถูกต้องสำหรับคำถามผู้ใช้ที่ฟังดูสมเหตุสมผล เราจำเป็นต้องมีตัวอย่าง SQL query ที่หลากหลายและจำนวนมาก สำหรับตาราง MySQL เพียงตารางเดียวก็ต้องใช้ 15–20 query แล้ว
    ผู้ใช้ถามได้ทุกอย่าง ดังนั้นมันต้องทนทานมาก ถ้าตารางเดียวต้องใช้บริบทขนาดนี้ การขยายไปสู่หลักสิบหรือหลักร้อยตารางก็ดูยากมาก เลยสงสัยว่ามีวิธีที่มีประสิทธิภาพกว่านี้ไหม
    อย่างที่สี่ เรากำลังใช้โมเดล Llama2 70B Gen และก็สงสัยว่ามีโมเดลอื่นที่ทำการสร้าง SQL query ได้ดีกว่านี้ไหม

    • สำหรับข้อ 2 เราใส่ตัวอย่างช่วงวันที่ที่ใช้บ่อยอย่าง “เดือนนี้”, “ปีที่แล้ว”, “ยอดสะสมตั้งแต่ต้นปี” พร้อมการคำนวณวันที่บางส่วน และตัวอย่างฟิลด์วันที่ลงไปในพรอมป์ต์เยอะมาก
      มีทั้ง timestamp และ Year, Month, Day ที่สกัดออกมา
      วันที่ปัจจุบัน: current_date()
      3 วันก่อน: current_date() - INTERVAL 3 DAY
      จุดเริ่มต้นของเดือนนี้: date_trunc('month', current_date())
      ...
      สำหรับข้อ 4 เราได้ผลดีที่สุดจาก GPT-4 และยังไม่ได้ลอง Llama ส่วน 3.5 กับ 4-turbo มีแนวโน้มจะ “ลืม” เนื้อหาเมื่อ query ซับซ้อน แต่ก็อาจยังต้องจูนเพิ่มอีก
    • หรือคุณเคยพิจารณาใช้ semantic layer แทนไหม? หรือว่าจำเป็นต้องเป็นอินเทอร์เฟซภาษาธรรมชาติเท่านั้น?