- "self-serve dashboards" thực tế không hoạt động tốt. Lý do là kỹ sư hoặc nhà khoa học dữ liệu phải dành rất nhiều thời gian để viết truy vấn và chuẩn bị dashboard cho người dùng doanh nghiệp.
Vì sao "self-serve BI" không hoạt động
- SQL là công cụ "self-serve BI" duy nhất. Nhưng hầu hết các nhà cung cấp "self-serve BI" lại cố ngụy trang SQL thành một thứ khác.
- Việc viết truy vấn SQL không phải là rào cản duy nhất khiến các bên liên quan trong doanh nghiệp không thể truy vấn dữ liệu. Họ không hiểu ý nghĩa của dữ liệu, nguồn gốc của dữ liệu, cách dữ liệu được tính toán, cũng như không biết cách diễn giải và xác thực kết quả.
Thử nghiệm 1: cách tiếp cận "dropdown và checkbox" truyền thống
- Giao diện này thực chất chỉ là một nỗ lực tạo ra "SQL-by-mouse". Nó không tốt hơn SQL mà còn chậm hơn, kém tin cậy hơn, hạn chế hơn và không thể khái quát sang các công cụ khác.
- Những người như CFO sẽ không dùng giao diện này để truy vấn dữ liệu. Vì họ không có ngữ cảnh để hiểu dữ liệu và cũng không thể tự tin về kết quả.
Thử nghiệm 2: cách tiếp cận text-to-SQL
- LLM gần như quá hiệu quả trong việc dịch ngôn ngữ tự nhiên sang SQL. Ngay cả khi câu hỏi không phù hợp, nó vẫn sẽ cố tạo ra truy vấn.
- Người làm kỹ thuật sẽ nhận ra rằng câu hỏi không phù hợp và yêu cầu thêm ngữ cảnh. Họ sẽ giải thích các loại dữ liệu sẵn có và phối hợp với bộ phận kinh doanh để xây dựng những câu hỏi chính xác, hữu ích.
- LLM có thể trở thành lời giải thực sự cho "self-serve BI", nhưng chưa phải ở hình thức hiện tại. Nó cần nhiều ngữ cảnh hơn và phải thành thạo hơn trong việc thể hiện sự không chắc chắn cũng như yêu cầu thêm thông tin.
Những gì thực sự hiệu quả
- Vấn đề của "self-serve BI" không nằm ở SQL mà nằm ở ngữ cảnh và ý nghĩa của dữ liệu. Giải pháp là dạy cho mọi người hiểu về dữ liệu mà họ đang truy vấn, bất kể giao diện là gì.
- Việc yêu cầu đội ngũ kỹ thuật ghi chép toàn bộ tri thức tạo ra chi phí vận hành đáng kể và nhanh chóng trở nên lỗi thời.
- Giải pháp thực sự cho "self-serve BI" không phải là biến BI thành "self-serve" cho người không chuyên kỹ thuật, mà là giúp người làm kỹ thuật hỗ trợ các bên liên quan trong doanh nghiệp hiệu quả hơn bằng những công cụ tốt hơn.
Gợi ý về công cụ tốt hơn:
- Cung cấp LLM cho người làm kỹ thuật thay vì cho các bên liên quan trong doanh nghiệp.
- Cho phép họ tự do xử lý dữ liệu bằng các công cụ quen thuộc như Python, R, v.v.
- Giúp người làm kỹ thuật dễ dàng chia sẻ công việc của họ. Notebook và ứng dụng dữ liệu nội bộ khó chia sẻ vì phải xử lý container, dependency và hạ tầng.
1 bình luận
Ý kiến Hacker News
Vấn đề của các công cụ BI: Có trải nghiệm dùng công cụ BI nhưng cách join trong truy vấn được thiết lập sai, khiến dữ liệu hiển thị không chính xác. Điều này làm mất niềm tin vào lớp trừu tượng dành cho những người không rành SQL.
Tính hữu ích của Text-to-SQL: Vẫn hữu ích với lập trình viên, nhưng với người không phải lập trình viên thì có khả năng tạo ra truy vấn sai vì không hiểu đúng cấu trúc cơ sở dữ liệu.
Sự bất tài của tổ chức: Các báo cáo chứa lỗi và thông tin sai từ công cụ BI và AI thực sự đang được sử dụng, và điều này từng bị phê phán tương tự trong truyện tranh Dilbert.
Khả năng học của người dùng nghiệp vụ: Giả định rằng người dùng nghiệp vụ không thể hiểu mối quan hệ giữa mô hình dữ liệu và menu thả xuống là sai. Vấn đề phát sinh vì người mô hình hóa dữ liệu không hiểu rõ domain.
Kinh nghiệm cung cấp dữ liệu: Qua 24 năm kinh nghiệm cung cấp dữ liệu, chỉ có một số ít người dùng thực sự dùng công cụ, còn ban điều hành thì thích dashboard KPI hơn.
Ưu điểm của Metabase: Metabase cung cấp giao diện tốt trong số các công cụ BI, và có thể chuyển SQL được tạo bằng GUI sang SQL thuần, nên cả những người ít kỹ thuật cũng có thể dễ dùng.
Giới hạn của BI tự phục vụ: Cần nhìn nhận giới hạn của BI tự phục vụ, và giải pháp là tạo các dashboard tùy chỉnh không để lộ SQL cho người dùng nghiệp vụ.
Trải nghiệm sử dụng Metabase: Khi dùng Metabase và hướng dẫn người dùng không chuyên kỹ thuật qua các "office hours", nhiều yêu cầu đã không còn phải chuyển sang đội ngũ kỹ sư.
Sự mỉa mai của việc dùng SQL: Thật mỉa mai khi quản lý cấp cao lại không thể chạy truy vấn SQL. SQL vốn được tạo ra để nhà quản lý có thể truy vấn dữ liệu một cách dễ dàng.
Khó khăn của ETL: So với BI, việc để người dùng không chuyên kỹ thuật xử lý dữ liệu trong ETL còn khó hơn. Khi phát triển AWS Glue, người ta nhận ra cần có công cụ để người dùng kỹ thuật có thể debug vấn đề.