Kiến trúc Semantic Layer và sự kết hợp với AI Agent
Kiến trúc Semantic Layer và sự kết hợp với AI Agent
1. Bối cảnh
Trong các hệ thống dữ liệu doanh nghiệp, một câu hỏi tưởng chừng đơn giản như:
“Doanh thu tháng này của từng khu vực là bao nhiêu?”
thực tế có thể rất khó trả lời một cách nhất quán.
Dữ liệu có thể nằm trong nhiều bảng khác nhau:
ordersorder_itemscustomersproductsbranchespayments
Trong khi đó, người dùng nghiệp vụ không quan tâm dữ liệu nằm ở bảng nào. Họ quan tâm đến các khái niệm như:
- Doanh thu
- Khách hàng
- Sản phẩm
- Khu vực
- Lợi nhuận
- Tăng trưởng
- Khách hàng mới
Vấn đề lớn hơn xuất hiện khi mỗi hệ thống tự định nghĩa các khái niệm này.
BI Dashboard có một công thức tính Revenue.
Data Analyst có một câu SQL khác.
Backend Service lại có logic riêng.
AI Agent tự sinh SQL và có thể hiểu Revenue theo một cách hoàn toàn khác.
Kết quả là:
cùng một câu hỏi nhưng có thể xuất hiện nhiều câu trả lời khác nhau.
Semantic Layer được xây dựng để giải quyết vấn đề này.
2. Semantic Layer là gì?
Semantic Layer là một lớp abstraction nằm giữa nguồn dữ liệu vật lý và các ứng dụng sử dụng dữ liệu.
Thay vì để người dùng hoặc ứng dụng làm việc trực tiếp với:
Database
↓
Table
↓
Column
Semantic Layer cung cấp một mô hình gần với ngôn ngữ nghiệp vụ:
Business Domain
↓
Semantic Model
↓
Entity
↓
Dimension / Measure / Metric
Ví dụ, thay vì yêu cầu người dùng biết:
SUM(order_items.quantity * order_items.unit_price)
Semantic Layer có thể định nghĩa:
Metric: Revenue
Description: Tổng doanh thu bán hàng
Aggregation: SUM
Expression:
order_items.quantity * order_items.unit_price
Từ thời điểm đó, Dashboard, API, Data Analyst và AI Agent đều có thể sử dụng cùng một định nghĩa Revenue.
Semantic Layer vì vậy không đơn thuần là metadata.
Nó là:
Business abstraction + semantic metadata + query semantics + governance layer
nằm phía trên hệ thống dữ liệu.
3. Kiến trúc tổng thể của Semantic Layer
Một kiến trúc Semantic Layer hoàn chỉnh có thể được chia thành các lớp:
┌───────────────────────────────────────────────┐
│ Consumption Layer │
│ │
│ Dashboard │ BI │ API │ Application │ AI Agent │
└───────────────────────┬───────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ Semantic API Layer │
│ │
│ Query API │ Metadata API │ Search API │
│ Metric API │ AI Context API │
└───────────────────────┬───────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ Semantic Layer │
│ │
│ Models │
│ Entities │
│ Dimensions │
│ Measures │
│ Metrics │
│ Relationships │
│ Hierarchies │
│ Business Terms │
│ Enum / Value Mapping │
│ Security Policies │
└───────────────────────┬───────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ Semantic Query Engine │
│ │
│ Query Planner │
│ Join Planner │
│ Metric Resolver │
│ Filter Resolver │
│ SQL Generator │
│ Query Validator │
└───────────────────────┬───────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ Data Layer │
│ │
│ PostgreSQL │ SQL Server │ Oracle │ ClickHouse │
│ BigQuery │ Snowflake │ Data Lake │ APIs │
└───────────────────────────────────────────────┘
Điểm quan trọng là application phía trên không cần hiểu toàn bộ cấu trúc vật lý của database.
Application chỉ cần hiểu Semantic Model.
4. Metadata Layer – nền móng của Semantic Layer
Trung tâm của Semantic Layer là Metadata Repository.
Một Semantic Model có thể được mô hình hóa như sau:
SemanticModel
├── Entities
│ ├── Dimensions
│ ├── Measures
│ └── Attributes
│
├── Relationships
│
├── Metrics
│
├── Hierarchies
│
├── Business Terms
│
├── Value Mappings
│
└── Security Policies
Ví dụ:
Model: Sales
Entity: Order
order_id
order_date
status
customer_id
Entity: Customer
customer_id
customer_name
region
Relationship:
Order.customer_id
→ Customer.customer_id
Measure:
revenue
Metric:
total_revenue = SUM(revenue)
Dimension:
order_date
customer
region
order_status
Điều này tạo ra một semantic graph mô tả ý nghĩa và quan hệ giữa các dữ liệu.
5. Entity, Dimension, Measure và Metric
Một Semantic Layer tốt cần phân biệt rõ các khái niệm này.
Entity
Entity đại diện cho một đối tượng nghiệp vụ.
Ví dụ:
Customer
Order
Product
Employee
Organization
Invoice
Entity không nhất thiết tương ứng 1:1 với một database table.
Một Entity có thể được xây dựng từ nhiều bảng.
Dimension
Dimension là thuộc tính được sử dụng để:
- filter
- group
- slice
- drill down
Ví dụ:
Customer.Name
Customer.Region
Product.Category
Order.Status
Order.Date
Measure
Measure là giá trị số có thể aggregate.
Ví dụ:
Order.Amount
Order.Quantity
Order.Discount
với aggregation:
SUM
COUNT
COUNT DISTINCT
AVG
MIN
MAX
Metric
Metric là một khái niệm nghiệp vụ được định nghĩa dựa trên Measure hoặc các Metric khác.
Ví dụ:
Revenue
Profit
Profit Margin
Customer Acquisition Cost
Average Order Value
Conversion Rate
Ví dụ:
Revenue
= SUM(Order.Amount)
Profit
= Revenue - Cost
Profit Margin
= Profit / Revenue
Average Order Value
= Revenue / Order Count
Metric chính là một trong những thành phần quan trọng nhất giúp doanh nghiệp xây dựng Single Source of Truth.
6. Relationship và Join Graph
Một trong những vấn đề khó nhất của Semantic Layer là JOIN.
Giả sử có:
Customer
│
│ 1:N
▼
Order
│
│ 1:N
▼
OrderItem
│
│ N:1
▼
Product
Semantic Layer cần lưu metadata về relationship:
from_entity
to_entity
relationship_type
ONE_TO_ONE
ONE_TO_MANY
MANY_TO_ONE
MANY_TO_MANY
join_type
INNER
LEFT
join_expression
Từ đó Semantic Query Engine có thể xây dựng một Join Graph.
Ví dụ người dùng hỏi:
Revenue by Customer Region
Engine xác định:
Revenue
→ OrderItem
Customer Region
→ Customer
Sau đó tìm đường:
OrderItem
→ Order
→ Customer
và tự động sinh JOIN phù hợp.
Đây là điểm rất quan trọng khi kết hợp Semantic Layer với AI.
AI không nên tự suy đoán JOIN dựa trên tên column.
Semantic Layer phải cung cấp relationship graph hợp lệ.
7. Xử lý Enum và Business Value
Database thường lưu:
status = 0
status = 1
status = 2
Trong khi người dùng hiểu:
0 → Draft
1 → Active
2 → Cancelled
Semantic Layer nên hỗ trợ Value Mapping:
Dimension: Order.Status
Physical column:
orders.status
Type:
ENUM
Values:
0 → Draft
1 → Active
2 → Cancelled
AI Agent sau đó có thể hiểu câu:
Show cancelled orders
và chuyển thành:
Order.Status = "Cancelled"
Semantic Engine chịu trách nhiệm translate thành:
orders.status = 2
Điều này tốt hơn nhiều so với việc đưa trực tiếp schema database cho LLM và hy vọng model hiểu status = 2 nghĩa là gì.
8. Semantic Query Engine
Semantic Query Engine là thành phần thực thi trung tâm.
Luồng xử lý có thể là:
Semantic Query
│
▼
Semantic Parser
│
▼
Metadata Resolver
│
▼
Metric Resolver
│
▼
Relationship Resolver
│
▼
Join Planner
│
▼
Filter Resolver
│
▼
Security Policy
│
▼
Query Planner
│
▼
SQL Generator
│
▼
Database
Ví dụ client gửi:
{
"model": "sales",
"metrics": [
"revenue"
],
"dimensions": [
"customer.region"
],
"filters": [
{
"field": "order.status",
"operator": "=",
"value": "Completed"
}
]
}
Semantic Query Engine có thể sinh:
SELECT
customer.region,
SUM(order_item.quantity * order_item.price) AS revenue
FROM order_item
JOIN orders
ON order_item.order_id = orders.id
JOIN customer
ON orders.customer_id = customer.id
WHERE orders.status = 1
GROUP BY customer.region;
Client không cần biết:
- table name
- physical column
- JOIN
- enum value
- metric formula
Đó là trách nhiệm của Semantic Layer.
9. Semantic Layer kết hợp với AI
Sự xuất hiện của LLM làm Semantic Layer trở nên quan trọng hơn trước.
Một kiến trúc phổ biến hiện nay là:
User
│
▼
AI Assistant
│
▼
AI Agent
│
┌──────────┴───────────┐
│ │
▼ ▼
Semantic Discovery Semantic Query
│ │
└──────────┬───────────┘
▼
Semantic Layer
│
▼
Semantic Query Engine
│
▼
Data
Thay vì cho AI truy cập trực tiếp database:
LLM
↓
Generate SQL
↓
Database
ta đưa Semantic Layer vào giữa:
LLM / Agent
↓
Semantic API
↓
Semantic Layer
↓
Query Engine
↓
Database
Đây là khác biệt kiến trúc rất quan trọng.
10. Vì sao không nên để AI Agent query trực tiếp Database?
Một cách triển khai Text-to-SQL đơn giản thường là:
User Question
↓
LLM
↓
Database Schema
↓
Generate SQL
↓
Database
Cách này hoạt động tốt trong demo nhưng gặp nhiều vấn đề khi đưa vào hệ thống doanh nghiệp.
Ví dụ user hỏi:
Doanh thu năm nay là bao nhiêu?
LLM phải tự suy luận:
Revenue nằm ở đâu?
orders.total_amount?
payments.amount?
invoice.amount?
Có tính VAT không?
Có trừ refund không?
Cancelled order có được tính không?
Currency conversion thế nào?
Database schema không chứa đủ những kiến thức này.
Semantic Layer thì có thể chứa:
Metric:
Revenue
Definition:
Gross sales excluding cancelled orders,
after discount and before VAT.
Owner:
Finance
Certified:
true
Do đó AI không cần tự phát minh business logic.
11. Semantic Layer trở thành Grounding Layer cho AI
Trong kiến trúc AI, Semantic Layer có thể đóng vai trò:
Grounding Layer cho structured enterprise data.
AI Agent không cần biết toàn bộ database.
Agent chỉ cần hỏi Semantic Layer:
What metrics exist?
Semantic Layer trả:
Revenue
Profit
Order Count
Customer Count
Average Order Value
Agent tiếp tục:
Describe Revenue
Semantic Layer trả:
Revenue
Description:
Total completed sales excluding cancelled orders.
Dimensions:
Date
Customer
Region
Product
Category
Supported filters:
Date
Region
Product
Order Status
Agent lúc này có đủ context để lập kế hoạch truy vấn.
12. Semantic Discovery cho AI Agent
Không nên đưa toàn bộ Semantic Model vào prompt.
Một hệ thống enterprise có thể có:
500 models
5,000 entities
50,000 fields
10,000 metrics
Việc nhét toàn bộ metadata vào context vừa tốn token vừa làm giảm độ chính xác.
Thay vào đó cần có Semantic Discovery Service.
User Question
│
▼
Agent
│
▼
Semantic Search
│
▼
Relevant Models
│
▼
Relevant Metrics
│
▼
Relevant Dimensions
Ví dụ:
User:
Doanh thu theo khu vực tháng này
Semantic Search có thể trả:
Model:
Sales
Metric:
Revenue
Dimensions:
Region
Order Date
Agent chỉ nhận context cần thiết.
13. Semantic Catalog + Vector Search
Semantic metadata có thể được index vào Search Engine hoặc Vector Database.
Ví dụ index:
SemanticModel
Entity
Dimension
Metric
BusinessTerm
Description
Synonym
Example
Metric:
name:
revenue
display_name:
Doanh thu
synonyms:
sales
turnover
doanh số
tổng doanh thu
Khi user hỏi:
Tổng doanh số miền Bắc
Semantic Search có thể map:
doanh số
↓
Revenue
miền Bắc
↓
Region
Hybrid Search thường phù hợp hơn pure vector search:
Keyword Search
+
Vector Search
+
Metadata Filter
+
Semantic Ranking
14. Kiến trúc AI Agent hoàn chỉnh
Một kiến trúc mạnh hơn có thể được tổ chức:
User
│
▼
┌──────────────┐
│ AI Gateway │
└──────┬───────┘
│
▼
┌──────────────┐
│ Agent Runtime│
└──────┬───────┘
│
┌────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Semantic Knowledge External
Tools RAG Tools
│
▼
┌───────────────────┐
│ Semantic Discovery│
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Semantic Metadata │
│ Catalog │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Semantic Query API│
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Query Planner │
│ Metric Resolver │
│ Join Planner │
│ Policy Engine │
│ SQL Generator │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Data Sources │
└───────────────────┘
AI Agent trở thành lớp reasoning và orchestration.
Semantic Layer trở thành lớp business knowledge và deterministic data execution.
Hai thành phần có trách nhiệm khác nhau.
15. Tool-based architecture cho AI Agent
Không nên cho LLM generate SQL trực tiếp ngay từ đầu.
Thay vào đó Agent nên được cung cấp một tập tools có kiểm soát.
Ví dụ:
search_semantic_models()
search_metrics()
get_model()
get_metric()
get_dimensions()
get_relationships()
get_dimension_values()
validate_query()
execute_semantic_query()
Một cuộc hội thoại có thể chạy như sau.
User:
Cho tôi doanh thu theo tỉnh trong quý này
Agent gọi:
search_metrics("doanh thu")
nhận:
sales.revenue
Agent gọi:
get_dimensions("sales")
nhận:
customer.province
order.date
product.category
Agent tạo Semantic Query:
{
"metric": "sales.revenue",
"dimensions": [
"customer.province"
],
"time_dimension": "order.date",
"time_range": "current_quarter"
}
Sau đó:
validate_query(...)
và cuối cùng:
execute_semantic_query(...)
Agent không cần tự viết:
SELECT ...
FROM ...
JOIN ...
Semantic Engine chịu trách nhiệm phần đó.
16. Agent Planning
Với câu hỏi phức tạp hơn:
Tại sao doanh thu miền Bắc tháng này giảm?
Agent có thể lập kế hoạch:
Goal
│
├── Query Revenue this month
│
├── Query Revenue previous month
│
├── Compare by Province
│
├── Compare by Product Category
│
├── Compare Order Count
│
├── Compare Average Order Value
│
└── Generate explanation
Các bước query đều sử dụng Semantic Layer.
LLM chịu trách nhiệm:
Reasoning
Planning
Tool selection
Interpretation
Explanation
Semantic Layer chịu trách nhiệm:
Business definitions
Metrics
Dimensions
Relationships
Data access
Query generation
Security
Đây là ranh giới trách nhiệm rất quan trọng.
17. Semantic Layer không thay thế RAG
Semantic Layer và RAG giải quyết hai loại dữ liệu khác nhau.
Semantic Layer phù hợp với:
Structured Data
Revenue
Orders
Customers
Products
Transactions
Metrics
KPIs
RAG phù hợp với:
Unstructured Data
Documents
Policies
Contracts
Manuals
Emails
Reports
Knowledge Base
Một Enterprise AI Agent tốt thường cần cả hai:
AI Agent
│
┌───────────┴───────────┐
│ │
▼ ▼
Semantic Layer RAG
│ │
▼ ▼
Structured Data Unstructured Data
Ví dụ user hỏi:
Doanh thu tháng này giảm bao nhiêu
và chính sách bán hàng nào có thể liên quan?
Agent có thể:
Semantic Layer
↓
Revenue decreased 12%
RAG
↓
Retrieve pricing / promotion policies
Agent
↓
Synthesize answer
18. Security và Governance
Đây là phần bắt buộc trong hệ thống enterprise.
AI Agent không được trở thành con đường bypass security.
Semantic Layer cần hỗ trợ:
Authentication
Authorization
Model-level permission
Entity-level permission
Field-level security
Row-level security
Metric-level permission
Data masking
Ví dụ:
User A
Region:
Hanoi
Policy:
Sales.Region = User.Region
Dù Agent yêu cầu:
Revenue for all regions
Semantic Engine vẫn tự động áp dụng:
WHERE region = 'Hanoi'
AI không có quyền bỏ policy.
19. Semantic Query Intermediate Representation
Một thiết kế quan trọng là không nên chuyển trực tiếp:
Natural Language → SQL
Nên có một Intermediate Representation:
Natural Language
↓
Semantic Query
↓
Logical Query Plan
↓
Physical Query Plan
↓
SQL
Ví dụ Semantic Query:
{
"model": "sales",
"metrics": [
"revenue"
],
"dimensions": [
"customer.region"
],
"filters": [
{
"field": "order.status",
"operator": "eq",
"value": "completed"
}
],
"time": {
"dimension": "order.date",
"range": "this_month"
}
}
Đây là boundary rất tốt giữa AI và Data Platform.
AI sinh intent có cấu trúc.
Semantic Engine quyết định cách thực thi intent đó.
20. Kiến trúc Production đề xuất
Ở mức production, toàn bộ hệ thống có thể được tổ chức thành:
┌────────────────────────────────────────────────────┐
│ User / Application │
└────────────────────────┬───────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ AI Layer │
│ │
│ LLM Gateway │
│ Agent Runtime │
│ Planner │
│ Tool Calling │
│ Conversation Context │
│ Guardrails │
└────────────────────────┬───────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ Semantic AI Gateway │
│ │
│ Semantic Search │
│ Metadata Discovery │
│ Business Term Resolution │
│ Metric Discovery │
│ Value Resolution │
│ Query Validation │
└────────────────────────┬───────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ Semantic Layer │
│ │
│ Semantic Models │
│ Entities │
│ Dimensions │
│ Measures │
│ Metrics │
│ Relationships │
│ Hierarchies │
│ Enum Mapping │
│ Business Glossary │
│ Security Policies │
└────────────────────────┬───────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ Semantic Query Engine │
│ │
│ Semantic Parser │
│ Metric Resolver │
│ Relationship Resolver │
│ Join Graph │
│ Query Planner │
│ Policy Engine │
│ SQL Generator │
│ Query Validator │
│ Query Optimizer │
└────────────────────────┬───────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ Data Layer │
│ │
│ PostgreSQL │
│ SQL Server │
│ Oracle │
│ ClickHouse │
│ Snowflake │
│ BigQuery │
│ Data Lake │
└────────────────────────────────────────────────────┘
Song song với đó có thể tồn tại:
Semantic Metadata
│
▼
Search Index
+
Vector Index
│
▼
Semantic Discovery
│
▼
AI Agent
21. Phân chia trách nhiệm giữa AI và Semantic Layer
Một nguyên tắc thiết kế quan trọng là:
AI nên reasoning, Semantic Layer nên quyết định semantics.
AI chịu trách nhiệm:
Understanding natural language
Intent recognition
Planning
Tool selection
Multi-step reasoning
Result interpretation
Natural-language explanation
Semantic Layer chịu trách nhiệm:
Business definition
Metric calculation
Relationship
Join
Aggregation
Enum mapping
Data type
Query generation
Security
Governance
Database chịu trách nhiệm:
Storage
Filtering
Join execution
Aggregation
Query optimization
Việc giữ ranh giới này giúp hệ thống dễ kiểm soát hơn đáng kể.
22. Semantic Layer như một Business Knowledge Graph
Khi Semantic Layer phát triển đủ lớn, có thể nhìn nó như một dạng Business Knowledge Graph.
Ví dụ:
Customer
│
├── places → Order
│ │
│ ├── contains → Product
│ │
│ └── contributes_to → Revenue
│
└── belongs_to → Region
Metric cũng nằm trong graph:
Revenue
│
├── calculated_from → Order Amount
├── filtered_by → Order Status
├── analyzed_by → Region
├── analyzed_by → Product
└── analyzed_by → Time
Business term:
"Sales"
"Turnover"
"Doanh số"
│
└── synonym_of → Revenue
Graph này cực kỳ hữu ích cho AI vì nó cung cấp context có cấu trúc thay vì chỉ cung cấp database schema.
23. Semantic Layer cho Agentic Analytics
Khi kết hợp Semantic Layer với Agent, hệ thống không còn chỉ hỗ trợ:
Question → Query → Answer
mà có thể tiến tới:
Question
↓
Understand
↓
Plan
↓
Discover Semantic Model
↓
Generate Semantic Queries
↓
Execute multiple analyses
↓
Compare
↓
Reason
↓
Generate Insight
Ví dụ:
User:
Tại sao doanh thu tháng 9 giảm?
Agent có thể tự xây dựng analysis plan:
1. Revenue MoM
2. Revenue by Region
3. Revenue by Product
4. Order Count
5. Average Order Value
6. New vs Existing Customers
Sau đó thực hiện nhiều Semantic Queries và tổng hợp kết quả.
Đây chính là bước chuyển từ:
BI → Conversational BI → AI Analytics Agent.
24. Kiến trúc mục tiêu
Nếu xây dựng một nền tảng Semantic Layer mới có AI Agent, kiến trúc mục tiêu nên đi theo hướng:
┌───────────────┐
│ USER │
└───────┬───────┘
│
▼
┌───────────────┐
│ AI AGENT │
│ │
│ Understand │
│ Plan │
│ Reason │
│ Explain │
└───────┬───────┘
│
│ Tool Calling
▼
┌──────────────────────┐
│ SEMANTIC AI GATEWAY │
│ │
│ Discover │
│ Search │
│ Resolve │
│ Validate │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ SEMANTIC LAYER │
│ │
│ Business Models │
│ Entities │
│ Dimensions │
│ Metrics │
│ Relationships │
│ Business Glossary │
│ Security │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ SEMANTIC QUERY ENGINE│
│ │
│ Resolve │
│ Plan │
│ Join │
│ Secure │
│ Generate SQL │
│ Execute │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ DATA SOURCES │
└──────────────────────┘
Trong kiến trúc này:
LLM không phải nơi chứa business logic.
Prompt không phải nơi định nghĩa metric.
AI Agent không phải SQL Engine.
Business logic nằm trong Semantic Layer.
AI sử dụng Semantic Layer như một tập các business-aware tools để hiểu và truy vấn dữ liệu.
25. Kết luận
Semantic Layer ban đầu được xây dựng để giải quyết bài toán thống nhất định nghĩa dữ liệu giữa BI, Analytics và các ứng dụng.
Nhưng trong kỷ nguyên Generative AI, vai trò của Semantic Layer trở nên lớn hơn.
Nó có thể trở thành:
Business Knowledge Layer
+
Data Governance Layer
+
AI Grounding Layer
+
Query Abstraction Layer
cho toàn bộ hệ thống AI doanh nghiệp.
Kiến trúc quan trọng nhất không phải:
User
↓
LLM
↓
SQL
↓
Database
mà là:
User
↓
AI Agent
↓
Semantic Discovery
↓
Semantic Query
↓
Semantic Layer
↓
Query Engine
↓
Data
AI đảm nhiệm phần reasoning.
Semantic Layer đảm nhiệm phần meaning.
Query Engine đảm nhiệm phần execution.
Database đảm nhiệm phần data.
Khi các trách nhiệm này được tách biệt rõ ràng, doanh nghiệp có thể xây dựng AI Agent có khả năng truy vấn và phân tích dữ liệu nhưng vẫn duy trì được tính nhất quán của metric, kiểm soát JOIN, business logic, phân quyền và governance.
Có thể xem đây là sự chuyển dịch từ:
Database-centric Architecture
↓
Semantic-centric Architecture
↓
Agentic Data Architecture
Và trong kiến trúc cuối cùng đó, Semantic Layer không chỉ phục vụ BI.
Semantic Layer trở thành ngôn ngữ chung giữa dữ liệu, business và AI.
All rights reserved
