Business Ontology của Snowflake: lớp ngữ cảnh quản trị cho AI và KPI
Snowflake giới thiệu Business Ontology, nơi doanh nghiệp định nghĩa, sở hữu và phê duyệt thuật ngữ, quan hệ và metric. Mục tiêu là để AI, Semantic Views và đội BI cùng dùng ngữ cảnh kinh doanh đã được quản trị.
Một dashboard Finance và một dashboard Sales có thể cùng hiển thị “net revenue” nhưng ra hai con số khác nhau. Không phải lúc nào đó cũng là lỗi SQL.
Có thể mỗi đội đang dùng một định nghĩa hợp lệ cho phạm vi riêng: một bên tính hoàn tiền, bên kia dùng thời điểm ghi nhận khác; một bên áp dụng toàn công ty, bên kia chỉ áp dụng cho một thương hiệu.
Rủi ro tăng lên khi một AI agent hoặc analyst mới hỏi: “Net revenue tháng này là bao nhiêu?” Nếu hệ thống không biết phải dùng định nghĩa nào, câu SQL có thể hợp lệ về cú pháp nhưng sai về ý nghĩa kinh doanh.
Snowflake vừa giới thiệu Business Ontology — dự kiến public preview — như một nơi được quản trị để đội ngũ định nghĩa, sở hữu và phê duyệt thuật ngữ, thực thể, quan hệ và metric dùng chung. Sản phẩm này thuộc Horizon Context, lớp ngữ cảnh được quản trị trong Horizon Catalog.
Với người làm BI, ý tưởng cốt lõi là tách hai câu hỏi vốn thường bị trộn lẫn:
KPI này có nghĩa gì, áp dụng ở đâu và ai chịu trách nhiệm?
KPI này được tính bằng logic nào?
Business Ontology giải quyết điểm đau nào?
Theo Snowflake, tri thức về các khái niệm như customer, order hay revenue thường nằm rải rác trong mô hình BI, dự án dbt và kinh nghiệm của những người làm lâu năm. Khi xây AI agent mới, đội ngũ dễ phải mô tả lại cùng một bối cảnh cho từng công cụ.
Business Ontology được thiết kế để tập trung hóa phần ngữ cảnh này. Các đội có thể:
Định nghĩa các thuật ngữ nghiệp vụ như customer, order và revenue.
Mô tả quan hệ giữa các khái niệm.
Chỉ định người sở hữu định nghĩa.
Đưa định nghĩa qua quy trình phê duyệt.
Liên kết định nghĩa với dữ liệu và Semantic Views triển khai chúng.
Giữ các khác biệt có chủ đích giữa finance, sales, marketing, thương hiệu hoặc khu vực.
Snowflake nêu ví dụ về net revenue: thay vì để mỗi semantic view, dashboard hoặc agent mang một phiên bản riêng, đội ngũ có thể định nghĩa thuật ngữ, gán phạm vi như “finance”, chỉ định owner, phê duyệt rồi liên kết với metric trong Semantic View tính ra chỉ số đó.
Điều này không có nghĩa mọi đội phải dùng cùng một công thức. Một doanh nghiệp nhà hàng chẳng hạn có thể có định nghĩa same-store sales khác nhau theo từng thương hiệu, miễn là từng biến thể được phê duyệt, gắn phạm vi và liên kết tới cách tính tương ứng.
| Thuật ngữ | Phạm vi minh họa | Điều cần được quản trị |
|---|---|---|
| Net revenue | Finance | Định nghĩa, owner, trạng thái phê duyệt |
| Net revenue | Brand A | Biến thể theo thương hiệu và metric liên quan |
| Net revenue | Brand B | Biến thể theo thương hiệu và metric liên quan |
Cùng một nhãn không nhất thiết đồng nghĩa với cùng công thức hoặc cùng tập dữ liệu.
Ba lớp: suy luận, quản trị nghĩa và thực thi metric
Snowflake mô tả ba lớp trong Horizon Context, với vai trò khác nhau:
| Lớp | Vai trò theo Snowflake | Ý nghĩa với đội BI |
|---|---|---|
| Snowflake Cortex Sense | Suy luận ngữ cảnh từ metadata và cách dữ liệu được sử dụng | Có thể giảm công sức mô tả thủ công mọi bảng và metric ngay từ đầu |
| Business Ontology | Quản trị ý nghĩa, phạm vi, owner và phê duyệt | Tạo nguồn tham chiếu cho định nghĩa nghiệp vụ |
| Snowflake Semantic Views | Thực thi metric | Đóng gói metric, dimension và join để agent, BI tool và SQL truy vấn |
Theo Snowflake, các lớp này không bắt buộc phải được triển khai theo một trình tự cố định. Đội ngũ có thể bắt đầu từ nhu cầu cấp bách nhất: glossary, metric có thể thực thi hoặc ngữ cảnh được suy luận tự động.
Điểm phân tách quan trọng là:
Business Ontology quản trị KPI có nghĩa gì và ai phê duyệt nó.
Semantic Views định nghĩa KPI được tính như thế nào.
Semantic Views đóng gói metric, dimension và join thành đối tượng Snowflake mà agent, công cụ BI và SQL có thể truy vấn trực tiếp. Business Ontology liên kết định nghĩa đã phê duyệt với Semantic View tính metric đó, nhưng không thay đổi công thức tính. Phần logic vẫn do owner của từng view quản lý.
Cortex Sense có thể khởi tạo ngữ cảnh, nhưng không thay thế owner
Snowflake cho biết Cortex Sense, cũng dự kiến public preview, có thể xây dựng ngữ cảnh từ metadata và các dấu hiệu sử dụng sẵn có, gồm query history, dashboard và dbt model.
Theo mô tả của Snowflake, Cortex Sense có thể:
Cập nhật kiến thức theo lịch do đội ngũ chọn.
Nhận diện tri thức xung đột và yêu cầu đội ngũ chọn nguồn đáng tin.
Tạo bản nháp ban đầu trong Business Ontology, gồm định nghĩa, quan hệ và liên kết dữ liệu được đề xuất.
Tuy nhiên, Snowflake nhấn mạnh rằng gợi ý từ AI và định nghĩa nhập từ bên ngoài chỉ là điểm khởi đầu để review. Owner có trách nhiệm mới quyết định nội dung nào trở thành chính thức.
Khi định nghĩa đã phê duyệt mâu thuẫn với điều Cortex Sense suy luận, agent sẽ dùng định nghĩa đã phê duyệt.
Đây là ranh giới đáng lưu ý khi đưa AI vào phân tích dữ liệu: AI có thể hỗ trợ tổng hợp và đề xuất ngữ cảnh, nhưng không nên tự trở thành người phê duyệt định nghĩa doanh thu, khách hàng hay lợi nhuận.
Lineage và bối cảnh xuyên công cụ
Horizon Context có các metadata connector thu thập schema, query log, định nghĩa dashboard và usage signal từ những nguồn như Tableau, Power BI, dbt, SQL Server, Sigma, Omni và PostgreSQL.
Snowflake cũng mô tả khả năng lineage xuyên nền tảng, theo dấu dữ liệu từ cơ sở dữ liệu nguồn, qua các bước biến đổi, tới dashboard hiển thị kết quả.
Với BI developer, loại bối cảnh này hướng tới các câu hỏi quen thuộc:
Con số trên dashboard bắt đầu từ dữ liệu nguồn nào?
Metric đã đi qua những bước biến đổi nào?
Thay đổi một định nghĩa có thể tác động đến đâu?
Agent đang bám vào logic nào để trả lời?
Snowflake còn cho biết họ đã hỗ trợ sáng lập Apache Ossie — một chuẩn mở, trung lập nhà cung cấp cho semantic model, đang ở giai đoạn incubating. Semantic Views có thể import và export định nghĩa Ossie. Các agent ngoài Snowflake cũng có thể truy vấn Semantic Views qua Model Context Protocol, trong khi Horizon Catalog quản trị quyền truy cập.
Khả năng tương thích thực tế vẫn phụ thuộc vào mức hỗ trợ của từng công cụ trong hệ sinh thái.
Một cách chuẩn bị cho đội BI
Bài công bố chưa nêu các bước cấu hình, API hay câu lệnh SQL cụ thể để tạo Business Ontology. Vì vậy, chưa nên suy diễn quy trình triển khai sản phẩm từ thông tin hiện có.
Tuy vậy, đội BI có thể rà soát trước những KPI thường gây tranh cãi:
Chọn một KPI hay bị hỏi lại
Ví dụ net revenue, active customer hoặc một chỉ số mà Sales và Finance thường dùng khác nhau.
Viết định nghĩa theo ngôn ngữ nghiệp vụ
Nêu rõ KPI trả lời câu hỏi gì, áp dụng trong phạm vi nào và khác gì với những metric gần nghĩa.
Chỉ định owner và người phê duyệt
Làm rõ ai chịu trách nhiệm về ý nghĩa nghiệp vụ, và ai chịu trách nhiệm về phần triển khai dữ liệu.
Liên kết định nghĩa với nơi tính toán
Xác định Semantic View hoặc logic metric đang thực thi định nghĩa đó.
Giữ riêng các biến thể hợp lệ
Nếu một KPI có phiên bản khác nhau theo thương hiệu hoặc domain, đừng ép chúng thành một con số duy nhất.
Checklist trước khi để AI trả lời KPI
[ ] KPI đã có định nghĩa business ngắn gọn và rõ phạm vi chưa?
[ ] Có owner và trạng thái phê duyệt cho định nghĩa không?
[ ] Đã phân biệt các biến thể hợp lệ theo domain, thương hiệu hoặc khu vực chưa?
[ ] Định nghĩa đã được liên kết với nơi tính metric chưa?
[ ] Đội ngũ có biết metric, dimension và join nào đang được dùng không?
[ ] Khi AI trả lời, kết quả có được đối chiếu với định nghĩa đã phê duyệt không?
Business Ontology không tự sửa mọi dashboard lệch số. Nhưng cách Snowflake định vị sản phẩm cho thấy một hướng đi rõ ràng: biến thói quen “thống nhất nghĩa KPI trước” thành ngữ cảnh có owner, governance và khả năng tái sử dụng cho cả con người lẫn AI.