- "self-serve dashboards" ในความเป็นจริงมักใช้ไม่ได้ผล เพราะวิศวกรหรือ data scientist ต้องใช้เวลามากในการเขียนคิวรีและเตรียมแดชบอร์ดให้ผู้ใช้ฝั่งธุรกิจ
ทำไม "self-serve BI" ถึงใช้ไม่ได้ผล
- SQL คือเครื่องมือ "self-serve BI" เพียงตัวเดียว แต่ผู้ให้บริการ "self-serve BI" ส่วนใหญ่มักพยายามอำพราง SQL ให้ดูเหมือนเป็นอย่างอื่น
- การเขียน SQL query ไม่ใช่อุปสรรคเดียวที่ทำให้ผู้มีส่วนได้ส่วนเสียฝั่งธุรกิจไม่สามารถคิวรีข้อมูลได้ พวกเขายังไม่เข้าใจความหมาย แหล่งที่มา และวิธีการคำนวณของข้อมูล รวมถึงไม่รู้วิธีตีความและตรวจสอบผลลัพธ์
ความพยายามครั้งที่ 1: แนวทางแบบ "dropdown และ checkbox" เดิม ๆ
- อินเทอร์เฟซนี้เป็นเพียงความพยายามทำ "SQL-by-mouse" เท่านั้น ไม่ได้ดีกว่า SQL และกลับช้ากว่า ไม่น่าเชื่อถือกว่า มีข้อจำกัดมากกว่า และไม่สามารถนำไปใช้กับเครื่องมืออื่นแบบทั่วไปได้
- คนอย่าง CFO จะไม่ใช้อินเทอร์เฟซนี้เพื่อคิวรีข้อมูล เพราะพวกเขาไม่มีบริบทที่ช่วยให้เข้าใจข้อมูล และไม่มั่นใจในผลลัพธ์ที่ได้
ความพยายามครั้งที่ 2: แนวทาง text-to-SQL
- LLM มีประสิทธิภาพในการแปลภาษาธรรมชาติเป็น SQL มากเสียจนเกือบจะดีเกินไป แม้คำถามจะไม่เหมาะสม มันก็ยังพยายามสร้างคิวรีออกมา
- คนสายเทคนิคจะสังเกตได้ว่าคำถามนั้นยังไม่เหมาะสม และจะขอข้อมูลบริบทเพิ่มเติม อธิบายประเภทข้อมูลที่มีอยู่ และร่วมมือกับทีมธุรกิจเพื่อทำให้คำถามมีความแม่นยำและใช้งานได้จริง
- LLM อาจกลายเป็นโซลูชันที่แท้จริงของ "self-serve BI" ได้ แต่ยังไม่ใช่ในรูปแบบปัจจุบัน มันต้องการบริบทมากกว่านี้ และต้องเก่งขึ้นในการแสดงความไม่แน่นอนและขอข้อมูลเพิ่มเติม
สิ่งที่ได้ผลจริง
- ปัญหาของ "self-serve BI" ไม่ใช่เรื่อง SQL แต่เป็นเรื่องบริบทและความหมายของข้อมูล ทางแก้คือการสอนให้ผู้คนเข้าใจข้อมูลที่พวกเขากำลังคิวรี ไม่ว่าอินเทอร์เฟซจะเป็นแบบใดก็ตาม
- การให้ทีมเทคนิคบันทึกองค์ความรู้ทั้งหมดเป็นเอกสารก่อให้เกิดภาระงานเพิ่มมาก และเอกสารก็ล้าสมัยอย่างรวดเร็ว
- ทางออกที่แท้จริงของ "self-serve BI" ไม่ใช่การทำให้ BI เป็น "self-serve" สำหรับคนที่ไม่ใช่สายเทคนิค แต่เป็นการให้คนสายเทคนิคมีเครื่องมือที่ดีกว่าเพื่อสนับสนุนผู้มีส่วนได้ส่วนเสียฝั่งธุรกิจได้อย่างมีประสิทธิภาพยิ่งขึ้น
ข้อเสนอเกี่ยวกับเครื่องมือที่ดีกว่า:
- ให้ LLM กับคนสายเทคนิค ไม่ใช่ผู้มีส่วนได้ส่วนเสียฝั่งธุรกิจ
- เปิดให้ใช้เครื่องมือที่ถนัดอย่างอิสระ เช่น Python, R เป็นต้น เพื่อจัดการข้อมูลได้อย่างยืดหยุ่น
- ทำให้คนสายเทคนิคแชร์สิ่งที่ทำได้ง่ายขึ้น เพราะ notebook และแอปพลิเคชันข้อมูลภายในมักแชร์ได้ยาก เนื่องจากต้องจัดการกับ container, dependency และ infrastructure
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ปัญหาของเครื่องมือ BI: เคยมีประสบการณ์ใช้เครื่องมือ BI แล้วตั้งค่าการ join ของคิวรีผิด ทำให้แสดงข้อมูลผิดพลาด จนสูญเสียความเชื่อมั่นต่อชั้น abstraction ที่ทำมาสำหรับคนที่ไม่รู้ SQL มากนัก
ประโยชน์ของ Text-to-SQL: ยังคงมีประโยชน์สำหรับนักพัฒนา แต่สำหรับคนที่ไม่ใช่นักพัฒนา มีโอกาสสร้างคิวรีผิดได้เพราะไม่เข้าใจโครงสร้างฐานข้อมูลอย่างถูกต้อง
ความไร้ความสามารถขององค์กร: รายงานที่มีทั้งข้อผิดพลาดจากเครื่องมือ BI และเครื่องมือ AI รวมถึงข้อมูลที่ไม่ถูกต้อง ถูกนำไปใช้งานจริง และสิ่งนี้ก็เคยถูกวิจารณ์ในคอมิก Dilbert ในทำนองเดียวกัน
ความสามารถในการเรียนรู้ของผู้ใช้ฝั่งธุรกิจ: การตั้งสมมติฐานว่าผู้ใช้ฝั่งธุรกิจไม่สามารถเข้าใจความสัมพันธ์ระหว่าง data model กับเมนูแบบดรอปดาวน์ได้นั้นเป็นเรื่องผิด ปัญหาเกิดจาก data modeler ไม่เข้าใจโดเมนดีพอ
ประสบการณ์ในการให้บริการข้อมูล: จากประสบการณ์ให้บริการข้อมูลตลอด 24 ปี มีผู้ใช้เพียงส่วนน้อยเท่านั้นที่ใช้งานเครื่องมือจริง ขณะที่ผู้บริหารชอบแดชบอร์ด KPI มากกว่า
ข้อดีของ Metabase: Metabase มีอินเทอร์เฟซที่ดีเมื่อเทียบกับเครื่องมือ BI อื่น ๆ และสามารถแปลง SQL ที่สร้างจาก GUI ให้เป็น SQL ล้วนได้ ทำให้คนที่มีทักษะทางเทคนิคน้อยก็ใช้งานได้ง่าย
ข้อจำกัดของ self-service BI: ควรยอมรับข้อจำกัดของ self-service BI และทางออกคือสร้างแดชบอร์ดแบบปรับแต่งเฉพาะที่ไม่เปิดเผย SQL ให้ผู้ใช้ฝั่งธุรกิจเห็น
ประสบการณ์ใช้งาน Metabase: หลังจากใช้ Metabase และสอนผู้ใช้ที่ไม่ใช่สายเทคนิคผ่าน "office hour" ก็ช่วยให้คำขอจำนวนมากไม่ต้องถูกส่งต่อไปยังทีมวิศวกรรม
ความน่าขันของการใช้ SQL: เป็นเรื่องน่าขันที่ผู้บริหารระดับสูงกลับไม่สามารถรัน SQL query ได้ ทั้งที่ SQL เดิมทีถูกสร้างมาเพื่อให้ผู้จัดการสามารถ query ข้อมูลได้ง่าย
ความยากของ ETL: เมื่อเทียบกับ BI แล้ว การให้ผู้ใช้ที่ไม่ใช่สายเทคนิคจัดการข้อมูลใน ETL นั้นยากกว่า ระหว่างพัฒนา AWS Glue จึงตระหนักว่าจำเป็นต้องมีเครื่องมือให้ผู้ใช้สายเทคนิคใช้ debug ปัญหาได้