[SWE học A.I] Phần 6: Machine Learning Classification

This entry is part 5 of 8 in the series SWE Học A.I

Phân Loại (Classification)

Phân loại là một ứng dụng quan trọng của học máy (machine learning), trong đó chúng ta xem xét một tập hợp các đầu vào, so sánh mỗi đầu vào với một danh sách các lớp (hoặc danh mục) có thể có, và gán mỗi đầu vào vào lớp có khả năng cao nhất.

Quá trình này được gọi là phân loại hoặc phân danh mục, và được thực hiện bởi một bộ phân loại (classifier). Chúng ta có thể sử dụng các lớp để thực hiện các tác vụ đa dạng như nhận diện từ ngữ mà ai đó nói qua điện thoại, xác định loài động vật xuất hiện trong ảnh, hoặc đánh giá một trái cây đã chín hay chưa.

Một cách phổ biến để huấn luyện một bộ phân loại là sử dụng học có giám sát (supervised learning). bắt đầu bằng việc thu thập một tập hợp các mẫu dữ liệu mà chúng ta muốn phân loại, gọi là tập huấn luyện (training set). Đồng thời, chúng ta chuẩn bị một danh sách các lớp hoặc danh mục, chẳng hạn như các loài động vật có thể xuất hiện trong ảnh hoặc thể loại nhạc được gán cho một mẫu âm thanh. Sau đó, chúng ta xem xét từng mẫu trong tập huấn luyện và quyết định lớp nào nên được gán cho mẫu đó. Đây được gọi là nhãn (label) của mẫu.

ID	Ảnh (mô tả)	Đặc trưng (Features)	Nhãn (Label)
1	Ảnh con vật có lông, 4 chân	[lông: có, chân: 4, bay: không, sủa: có]	Chó
2	Ảnh con vật có cánh, biết bay	[lông: không, chân: 2, bay: có, sủa: không]	Chim
3	Ảnh con vật có lông, 4 chân	[lông: có, chân: 4, bay: không, sủa: không]	Mèo
4	Ảnh con vật có mai cứng	[lông: không, chân: 4, bay: không, sủa: không]	Rùa

Tiếp theo, chúng ta cung cấp từng mẫu cho máy tính, từng mẫu một, nhưng không cung cấp nhãn. Máy tính xử lý mẫu và đưa ra dự đoán về lớp mà mẫu đó nên được gán. Sau đó, chúng ta so sánh dự đoán của máy tính với nhãn của chúng ta. Nếu dự đoán của bộ phân loại không khớp với nhãn, chúng ta điều chỉnh bộ phân loại một chút để nó có khả năng dự đoán đúng lớp nếu gặp lại mẫu này.

Quá trình này được gọi là huấn luyện (training), và chúng ta nói rằng hệ thống đang học (learning). Chúng ta lặp lại quá trình này nhiều lần, thường với hàng nghìn hoặc thậm chí hàng triệu mẫu, được tái sử dụng nhiều lần. Mục tiêu là cải thiện dần thuật toán cho đến khi các dự đoán của nó khớp với nhãn của chúng ta đủ thường xuyên để chúng ta cảm thấy nó sẵn sàng được áp dụng vào thực tế, nơi nó sẽ phân loại chính xác các mẫu mới mà nó chưa từng thấy. Khi đó, chúng ta kiểm tra bộ phân loại với dữ liệu mới để xem nó hoạt động tốt như thế nào và liệu nó đã sẵn sàng để sử dụng thực tế hay chưa.

Phân loại hai phần (Binary Classification)

Để bắt đầu, giả sử dữ liệu đầu vào chỉ thuộc về hai lớp khác nhau. Việc sử dụng hai lớp giúp đơn giản hóa việc thảo luận về phân loại mà không bỏ sót bất kỳ điểm cốt lõi nào. Vì chỉ có hai nhãn (hoặc lớp) khả thi cho mỗi đầu vào, chúng ta gọi đây là phân loại nhị phân (binary classification).

Nhóm kỹ thuật đầu tiên mà chúng ta sẽ xem xét được gọi chung là phương pháp ranh giới (boundary methods). Ý tưởng đằng sau các phương pháp này là chúng ta có thể quan sát các mẫu đầu vào được vẽ trên mặt phẳng và tìm một đường thẳng hoặc đường cong chia không gian sao cho tất cả các mẫu thuộc một nhãn nằm ở một bên của đường cong (hoặc ranh giới), và tất cả các mẫu thuộc nhãn kia nằm ở bên còn lại.

Giả sử chúng ta là nông dân trồng táo. Mỗi quả táo có thể là táo ngọt hoặc táo chua. Nếu chúng ta đo trọng lượng và đường kính của mỗi quả táo, ta có thể phân loại được loại của chúng. Giả sử rằng một chuyên gia nếm thử có thể phân biệt chính xác táo ngọt và táo chua – công việc của máy phân loại là mô phỏng khả năng đó. Với dữ liệu huấn luyện về trọng lượng và đường kính, chúng ta có thể vẽ điểm dữ liệu trên mặt phẳng và tìm một đường (thẳng hoặc cong) để phân chia hai loại táo. Mỗi điểm mới nằm về phía nào thì được gán nhãn tương ứng

Khi có táo mới (chưa biết vị), chúng ta chỉ cần xem nó nằm ở bên nào của đường thẳng khi được vẽ trên biểu đồ. Những quả nằm ở phía “ngọt” sẽ được gán lớp “táo ngọt”, và những quả ở phía “chua” sẽ được gán lớp “táo chua”

Khi phân chia như vậy, chúng ta gọi các phần trên mặt phẳng là vùng quyết định (decision regions) hoặc miền, và đường phân chia là ranh giới quyết định (decision boundaries).

Phân loại Đa lớp (Multiclass Classification)

Phân loại nhị phân (binary classification) thường đơn giản và nhanh hơn so với phân loại đa lớp (multiclass classification). Tuy nhiên, trong thực tế, phần lớn dữ liệu có nhiều hơn hai lớp.

May mắn thay, thay vì xây dựng một mô hình phân loại đa lớp phức tạp, chúng ta có thể tạo ra một tập hợp các bộ phân loại nhị phân và kết hợp kết quả của chúng để đưa ra câu trả lời đa lớp.

Một-chọi-tất-cả (One-versus-Rest)

Phương pháp này còn được gọi là Một-chọi-tất-cả (OvR), Một-chọi-hết (OvA), Một-đối-kháng-tất-cả (OAA) hoặc phương pháp liên quan nhị phân (binary relevance method). Giả sử chúng ta có năm lớp dữ liệu, được đặt tên từ A đến E. Thay vì xây dựng một bộ phân loại đa lớp phức tạp để gán một trong năm nhãn này, chúng ta sẽ tạo ra năm bộ phân loại nhị phân đơn giản hơn, mỗi bộ tập trung vào một lớp cụ thể, được đặt tên từ A đến E.

Bộ phân loại A xác định liệu một mẫu dữ liệu có thuộc lớp A hay không. Vì đây là bộ phân loại nhị phân, nó tạo ra một ranh giới quyết định (decision boundary) chia không gian dữ liệu thành hai vùng: lớp A và tất cả các lớp còn lại (B, C, D, E). Tên gọi “Một-chọi-tất-cả” bắt nguồn từ đây: lớp A là “một”, còn các lớp B đến E là “tất cả”.
Tương tự, Bộ phân loại B xác định liệu mẫu thuộc lớp B hay không, Bộ phân loại C kiểm tra lớp C, và cứ thế cho đến lớp E.

Các vùng quyết định của năm bộ phân loại nhị phân. Màu sắc từ tím đến hồng thể hiện xác suất tăng dần rằng một điểm thuộc vào lớp tương ứng.

Để phân loại một mẫu mới, chúng ta chạy mẫu đó qua cả năm bộ phân loại nhị phân, mỗi bộ trả về xác suất mẫu thuộc vào lớp tương ứng. Lớp có xác suất cao nhất sẽ được gán cho mẫu.

Trong ví dụ này, bốn bộ phân loại đầu tiên trả về xác suất thấp, trong khi bộ phân loại cho lớp E gán xác suất cao hơn, do đó mẫu được dự đoán thuộc lớp E.

Giả sử bạn cần phân loại ảnh thành năm loài: chó, mèo, chim, cá và thỏ. Thay vì xây dựng một mô hình phân loại phức tạp, bạn tạo năm bộ phân loại nhị phân:

Bộ phân loại “chó” xác định liệu ảnh có phải là chó hay không (tức là chó so với mèo, chim, cá, thỏ).
Tương tự cho các loài còn lại.

Khi một ảnh mới được đưa vào, mỗi bộ phân loại sẽ trả về một xác suất. Giả sử xác suất là:

Chó: 0.1
Mèo: 0.3
Chim: 0.15
Cá: 0.05
Thỏ: 0.7

Ảnh sẽ được gán nhãn là “thỏ” vì xác suất cao nhất là 0.7.

Ưu điểm và nhược điểm

Tuy nhiên, với phần cứng hỗ trợ xử lý song song, thời gian có thể được tối ưu tương đương với thời gian của một bộ phân loại.

Ưu điểm:

Khái niệm đơn giản, dễ hiểu.

Tốc độ xử lý nhanh, đặc biệt khi có thể chạy song song các bộ phân loại trên phần cứng phù hợp.

Nhược điểm:

Cần huấn luyện năm bộ phân loại thay vì một.

Mỗi mẫu phải được chạy qua năm bộ phân loại để xác định lớp, điều này có thể tốn thời gian khi số lớp lớn hoặc ranh giới phân loại phức tạp.

Một-chọi-một (One-versus-One)

Phương pháp thứ hai, Một-chọi-một (OvO), sử dụng nhiều bộ phân loại nhị phân so với ý tưởng OvR. Ý tưởng chính là xem xét từng cặp lớp trong dữ liệu và xây dựng một bộ phân loại nhị phân cho cặp lớp đó. Vì số lượng cặp lớp tăng nhanh khi số lớp tăng, số lượng bộ phân loại cũng tăng đáng kể. Để đơn giản, hãy xét ví dụ với bốn lớp (A, B, C, D)

Quy trình như sau:

Bộ phân loại A-B: Được huấn luyện chỉ với dữ liệu từ lớp A và B, bỏ qua các mẫu không thuộc A hoặc B. Bộ phân loại này tạo ranh giới phân tách giữa A và B, gán mọi điểm dữ liệu vào A hoặc B, ngay cả khi điểm đó thuộc lớp khác.
Tiếp tục xây dựng các bộ phân loại cho các cặp khác: A-C, A-D, B-C, B-D, và C-D. Kết quả là sáu bộ phân loại nhị phân, mỗi bộ xác định mẫu thuộc vào một trong hai lớp cụ thể.

Hàng trên: Bộ phân loại cho A-B, A-C, A-D. Hàng giữa: Bộ phân loại cho B-C, B-D. Hàng dưới: Bộ phân loại cho C-D.

Để phân loại một mẫu mới, chúng ta chạy mẫu qua cả sáu bộ phân loại. Mỗi bộ phân loại “bỏ phiếu” cho một trong hai lớp, và lớp nhận được nhiều phiếu nhất sẽ là nhãn dự đoán.

Hàng trên: Các phiếu là A, A, A.
Hàng giữa: Các phiếu là C, B.
Hàng dưới: Phiếu là C.

Kết quả: Lớp A nhận 3 phiếu, B nhận 1, C nhận 2, D nhận 0. Do đó, mẫu được dự đoán thuộc lớp A.

Ưu điểm và nhược điểm

Ưu điểm:
- Cung cấp cái nhìn rõ ràng hơn về cách mẫu được đánh giá qua từng cặp lớp, tăng tính minh bạch và khả năng giải thích (explainability).
- Hữu ích khi các lớp có sự chồng lấn phức tạp, giúp con người dễ hiểu kết quả hơn.
Nhược điểm:
- Số lượng bộ phân loại tăng nhanh theo số lớp. Ví dụ:
  - 4 lớp: 6 bộ phân loại.
  - 5 lớp: 10 bộ phân loại.
  - 20 lớp: 190 bộ phân loại.
  - 30 lớp: 435 bộ phân loại.

Phân cụm (Clustering)

Phân cụm có nhãn

Phân cụm là một phương pháp giúp tổ chức dữ liệu thành các nhóm tương tự nhau. Chúng ta đã biết rằng một cách để phân loại các mẫu dữ liệu mới là chia không gian thành các vùng khác nhau, sau đó kiểm tra xem một điểm thuộc vùng nào. Tuy nhiên, một cách tiếp cận khác là nhóm chính dữ liệu huấn luyện thành các cụm (clusters), tức là các tập hợp có đặc điểm tương đồng. Nếu dữ liệu của chúng ta có nhãn (labels), làm thế nào để sử dụng nhãn này để tạo các cụm?

Dữ liệu có năm nhãn khác nhau, được biểu thị bằng màu sắc. Với các nhóm tách biệt rõ ràng, chúng ta có thể tạo cụm bằng cách vẽ một đường bao quanh mỗi tập hợp điểm, như ở hình giữa. Nếu mở rộng các đường này cho đến khi chúng giao nhau, sao cho mỗi điểm trên lưới được gán màu theo cụm gần nhất, chúng ta có thể bao phủ toàn bộ không gian như ở hình bên phải.

Phân cụm không nhãn

Phương pháp trên yêu cầu dữ liệu có nhãn. Nhưng nếu dữ liệu không có nhãn thì sao? Trong trường hợp này, chúng ta có thể tự động nhóm dữ liệu không nhãn thành các cụm và áp dụng kỹ thuật vừa mô tả. Đây là một dạng học không giám sát (unsupervised learning), nơi dữ liệu không có nhãn sẵn.

Khi sử dụng thuật toán để tự động tạo cụm từ dữ liệu không nhãn, chúng ta cần chỉ định số lượng cụm mong muốn, thường được ký hiệu bằng chữ k (một ký hiệu tùy ý, không mang ý nghĩa cụ thể). Giá trị k là một siêu tham số (hyperparameter), tức là giá trị chúng ta chọn trước khi huấn luyện hệ thống.

Giá trị k quyết định thuật toán sẽ chia dữ liệu thành bao nhiêu vùng (hay bao nhiêu lớp). Vì thuật toán sử dụng trung bình hình học (geometric means) của các nhóm điểm để tạo cụm, nó được gọi là phân cụm k-means.

Ưu và nhược điểm của việc chọn k

Việc tự do chọn giá trị k vừa là lợi thế vừa là thách thức.

Lợi thế: Nếu chúng ta biết trước số lượng cụm cần thiết, chúng ta có thể chỉ định và thuật toán sẽ tạo ra kết quả phù hợp. Tuy nhiên, máy tính không biết ranh giới cụm nên dù chia thành k phần, kết quả có thể không đúng như kỳ vọng. Nếu dữ liệu tách biệt tốt, với các nhóm cách xa nhau, kết quả thường khớp với dự đoán. Nhưng nếu ranh giới cụm mờ hoặc chồng lấn, kết quả có thể bất ngờ.
Thách thức: Nếu không biết số lượng cụm phù hợp, việc chọn k quá thấp sẽ không tách biệt dữ liệu hiệu quả, còn chọn k quá cao sẽ khiến các điểm dữ liệu tương tự bị phân vào các lớp khác nhau.

Với 200 điểm không nhãn, được sắp xếp rõ ràng thành năm nhóm.

Bây giờ, với các k khác nhau, ta có:

Không ngạc nhiên khi k = 5 cho kết quả tốt nhất trong ví dụ này, vì ranh giới cụm dễ nhận thấy. Tuy nhiên, với dữ liệu phức tạp hơn, đặc biệt khi có hơn hai hoặc ba chiều, việc xác định số cụm tối ưu trước đó gần như bất khả thi.

Tối ưu hóa giá trị k

May mắn thay, chúng ta có thể huấn luyện mô hình phân cụm nhiều lần với các giá trị k khác nhau. Bằng cách đo lường chất lượng kết quả, quá trình điều chỉnh siêu tham số (hyperparameter tuning) giúp tự động tìm giá trị k tốt nhất. Nhược điểm là quá trình này tốn tài nguyên tính toán và thời gian. Do đó, việc trực quan hóa dữ liệu trước khi phân cụm rất hữu ích. Nếu chọn được giá trị k tối ưu hoặc một phạm vi giá trị khả thi ngay từ đầu, chúng ta có thể tiết kiệm thời gian và công sức.

Giả lập luồng hoạt động

Thuật toán k-means hoạt động theo các bước sau:

Khởi tạo: Chọn ngẫu nhiên k điểm làm tâm cụm (centroids).
Gán cụm: Gán mỗi điểm dữ liệu vào cụm có tâm gần nhất, dựa trên khoảng cách Euclidean: [latex]d(x, c) = \sqrt{\sum_{i=1}^{n} (x_i – c_i)^2}[/latex]
Cập nhật tâm cụm: Tính lại tâm cụm bằng trung bình của các điểm trong mỗi cụm: [latex]c_j = \frac{1}{n_j} \sum_{i=1}^{n_j} x_i[/latex]
Lặp lại: Lặp bước 2 và 3 cho đến khi tâm cụm không thay đổi hoặc đạt số lần lặp tối đa.

Hãy tưởng tượng bạn là chủ một quán cà phê và có dữ liệu về 10 khách hàng, được biểu thị bằng hai thông tin:

Số tiền chi tiêu (nghìn đồng) mỗi lần ghé quán.
Số lần ghé quán mỗi tháng.

Dữ liệu không có nhãn, nghĩa là bạn không biết trước khách hàng thuộc nhóm nào (như khách VIP, khách thường, v.v.). Mục tiêu là dùng k-means để chia 10 khách này thành 4 cụm dựa trên thói quen của họ.

Dữ liệu mẫu

Dưới đây là 10 điểm dữ liệu (mỗi điểm là một khách hàng):

Khách hàng	Chi tiêu (nghìn đồng)	Số lần ghé quán
A	50	2
B	60	3
C	55	1
D	200	10
E	220	12
F	210	11
G	100	5
H	110	6
I	300	3
J	310	4

Giả lập chạy thuật toán k-means với k = 4

Bước 1: Khởi tạo tâm cụm

Thuật toán chọn ngẫu nhiên 4 điểm làm tâm cụm ban đầu. Giả sử các tâm cụm được chọn là:

Tâm 1: (50, 2) – Khách A
Tâm 2: (200, 10) – Khách D
Tâm 3: (100, 5) – Khách G
Tâm 4: (300, 3) – Khách I

Bước 2: Gán cụm

Mỗi khách hàng được gán vào cụm có tâm gần nhất, dựa trên khoảng cách Euclidean. Công thức khoảng cách giữa hai điểm ((x_1, y_1)) và ((x_2, y_2)) là:

[ [latex]d = \sqrt{(x_2 – x_1)^2 + (y_2 – y_1)^2}[/latex] ]

Ví dụ, tính khoảng cách từ khách B (60, 3) đến Tâm 1 (50, 2):

[ [latex]d = \sqrt{(60 – 50)^2 + (3 – 2)^2} = \sqrt{10^2 + 1^2} = \sqrt{101} \approx 10.05[/latex] ]

Tương tự, tính khoảng cách từ B đến các tâm còn lại và gán B vào cụm có khoảng cách nhỏ nhất. Sau khi tính toán (giả sử kết quả), các khách hàng được gán như sau:

Cụm 1 (Tâm: 50, 2): Khách A, B, C
Cụm 2 (Tâm: 200, 10): Khách D, E, F
Cụm 3 (Tâm: 100, 5): Khách G, H
Cụm 4 (Tâm: 300, 3): Khách I, J

Bước 3: Cập nhật tâm cụm

Tính lại tâm cụm bằng trung bình tọa độ của các điểm trong cụm:

Cụm 1 (A: 50, 2; B: 60, 3; C: 55, 1):
- Trung bình x: ((50 + 60 + 55) / 3 = 55)
- Trung bình y: ((2 + 3 + 1) / 3 = 2)
- Tâm mới: (55, 2)
Cụm 2 (D: 200, 10; E: 220, 12; F: 210, 11):
- Trung bình x: ((200 + 220 + 210) / 3 = 210)
- Trung bình y: ((10 + 12 + 11) / 3 = 11)
- Tâm mới: (210, 11)
Cụm 3 (G: 100, 5; H: 110, 6):
- Trung bình x: ((100 + 110) / 2 = 105)
- Trung bình y: ((5 + 6) / 2 = 5.5)
- Tâm mới: (105, 5.5)
Cụm 4 (I: 300, 3; J: 310, 4):
- Trung bình x: ((300 + 310) / 2 = 305)
- Trung bình y: ((3 + 4) / 2 = 3.5)
- Tâm mới: (305, 3.5)

Bước 4: Lặp lại

Lặp lại bước 2 và 3 với các tâm cụm mới. Giả sử sau vài lần lặp, các tâm cụm không thay đổi nữa, ta được kết quả cuối cùng:

Cụm 1: Khách A, B, C (khách chi tiêu ít, ghé ít)
Cụm 2: Khách D, E, F (khách chi tiêu nhiều, ghé thường xuyên)
Cụm 3: Khách G, H (khách chi tiêu trung bình, ghé trung bình)
Cụm 4: Khách I, J (khách chi tiêu rất nhiều, ghé ít)

Kết quả:

Cụm 1: Khách hàng tiết kiệm, ít ghé quán – có thể là sinh viên hoặc khách vãng lai.
Cụm 2: Khách VIP, chi tiêu nhiều và ghé thường xuyên – nên ưu tiên chăm sóc.
Cụm 3: Khách trung thành nhưng chi tiêu vừa phải – có tiềm năng tăng chi tiêu.
Cụm 4: Khách chi tiêu lớn nhưng hiếm ghé – có thể là khách du lịch hoặc khách đặc biệt.

[SWE học A.I] Phần 2: Một số khái niệm toán học

This entry is part 2 of 8 in the series SWE Học A.I

Tổng hợp (Summations)

Tổng hợp (summation) được biểu diễn bằng ký hiệu sigma [latex]\sum[/latex] và được dùng để cộng các phần tử lại với nhau.

Ví dụ, nếu ta muốn lặp qua các số từ 1 đến 5, nhân mỗi số với 2, rồi cộng tổng lại, cách biểu diễn bằng tổng hợp sẽ như sau:

[latex]\sum_{i=1}^{5} 2i[/latex]

Tổng hợp [latex]\sum[/latex] có nghĩa là “cộng một loạt các phần tử lại với nhau”, sử dụng chỉ số i và giá trị tối đa n để biểu thị mỗi lần lặp.

Lũy thừa (Exponents)

Lũy thừa (exponentiation) là phép nhân một số với chính nó một số lần nhất định. Ví dụ, khi ta nâng 2 lên lũy thừa 3 (biểu diễn là [latex]2^3[/latex]), điều đó có nghĩa là nhân ba số 2 với nhau:

[latex]2^3 = 2 \cdot 2 \cdot 2 = 8[/latex]

Cơ số (base): Là giá trị được nâng lên lũy thừa (trong ví dụ trên là 2).
Số mũ (exponent): Là số lần cơ số được nhân với chính nó (trong ví dụ trên là 3).

Các thuộc tính của lũy thừa

1. Quy tắc nhân (Product Rule)

Khi nhân hai lũy thừa có cùng cơ số, ta cộng các số mũ lại. Ví dụ:

[latex]2^2 \cdot 2^3 = 2^{2+3} = 2^5 = 32[/latex]

Giải thích:

[latex]2^2 = 4[/latex], [latex]2^3 = 8[/latex].
[latex]4 \cdot 8 = 32[/latex], hoặc trực tiếp: [latex]2^5 = 32[/latex].
Quy tắc này chỉ áp dụng khi các lũy thừa có cùng cơ số.

2. Quy tắc chia (Quotient Rule)

Khi chia hai lũy thừa có cùng cơ số, ta trừ số mũ. Ví dụ:

[latex]\frac{x^5}{x^2} = x^{5-2} = x^3[/latex]

Giải thích:

Khi chia, các thừa số giống nhau ở tử số và mẫu số triệt tiêu, để lại [latex]x^3[/latex].

3. Lũy thừa âm (Negative Exponents)

Lũy thừa âm biểu thị nghịch đảo của lũy thừa dương. Ví dụ:

[latex]x^{-3} = \frac{1}{x^3}[/latex]

Ví dụ:

[latex]\frac{x^5}{x^7} = x^{5-7} = x^{-2} = \frac{1}{x^2}[/latex].
Quy tắc nhân vẫn áp dụng cho lũy thừa âm: [latex]x^5 \cdot x^{-3} = x^{5+(-3)} = x^2[/latex].

4. Lũy thừa bằng 0

Bất kỳ số nào (khác 0) nâng lên lũy thừa 0 đều bằng 1:

[latex]x^0 = 1[/latex]

Giải thích:

Xét [latex]\frac{x^3}{x^3} = x^{3-3} = x^0[/latex]. Vì một số chia cho chính nó bằng 1, nên [latex]x^0 = 1[/latex].
Thuộc tính này đảm bảo tính nhất quán trong các quy tắc lũy thừa.

5. Lũy thừa của lũy thừa (Power Rule)

Khi một lũy thừa được nâng lên một lũy thừa khác, ta nhân các số mũ:

[latex]x^3 = x^{2 \cdot 3} = x^6[/latex]

Giải thích:

[latex]x^3 = x^2 \cdot x^2 \cdot x^2 = x^6[/latex].

6. Lũy thừa phân số (Fractional Exponents)

Lũy thừa phân số biểu thị căn (root). Ví dụ:

Căn bậc hai: [latex]\sqrt{4} = 4^{\frac{1}{2}} = 2[/latex], vì [latex]2 \cdot 2 = 4[/latex].
Căn bậc ba: [latex]\sqrt[3]{8} = 8^{\frac{1}{3}} = 2[/latex], vì [latex]2 \cdot 2 \cdot 2 = 8[/latex].

Ví dụ:

[latex]8^{\frac{2}{3}}[/latex] nghĩa là lấy căn bậc ba của 8, rồi bình phương:
- [latex]\sqrt[3]{8} = 2[/latex].
- [latex]2^2 = 4[/latex].
- Do đó, [latex]8^{\frac{2}{3}} = 4[/latex].

Lũy thừa vô tỷ: Lũy thừa với số mũ vô tỷ, như [latex]2^\pi[/latex], có thể được tính xấp xỉ bằng cách sử dụng số hữu tỷ gần đúng. Ví dụ:

[latex]2^\pi \approx 2^{3.1415926535} \approx 8.824977827[/latex]2

Logarit (Logarithms)

Logarit (logarithm) là một hàm toán học tìm số mũ của một cơ số cụ thể để đạt được một số nhất định. Ví dụ, câu hỏi “2 mũ bao nhiêu bằng 8?” được biểu diễn là:

[latex]2^x = 8[/latex]

Câu trả lời là [latex]x = 3[/latex], vì [latex]2^3 = 8[/latex]. Cách biểu diễn bằng logarit là:

[latex]\log_2(8) = 3[/latex]

Trong Python, nếu không chỉ định cơ số, hàm log() sử dụng cơ số là số Euler [latex]e \approx 2.718[/latex], phổ biến trong khoa học dữ liệu (data science).
Trong các lĩnh vực như đo lường động đất, cơ số mặc định thường là 10.

Giải thích:

Cơ số (base) là 2.
Logarit tìm số mũ (3) để [latex]2^3 = 8[/latex].

Toán tử	Thuộc tính lũy thừa	Thuộc tính logarit
Nhân	[latex]x^a \cdot x^b = x^{a+b}[/latex]	[latex]\log_b (xy) = \log_b x + \log_b y[/latex]
Chia	[latex]\frac{x^a}{x^b} = x^{a-b}[/latex]	[latex]\log_b \left(\frac{x}{y}\right) = \log_b x – \log_b y[/latex]
Lũy thừa	[latex]x^a \cdot x^b = x^{a \cdot b}[/latex]	[latex]\log_b (x^a) = a \log_b x[/latex]
Lũy thừa 0	[latex]x^0 = 1[/latex]	Không xác định
Nghịch đảo	[latex]x^{-a} = \frac{1}{x^a}[/latex]	[latex]\log_b \left(\frac{1}{x}\right) = -\log_b x[/latex]

Số Euler và Logarit Tự nhiên

Số Euler, ký hiệu [latex]e[/latex], là một hằng số toán học với giá trị xấp xỉ 2.71828, có vai trò quan trọng trong giải tích và các lĩnh vực liên quan.

Tính chất đặc biệt của số Euler nằm ở chỗ đạo hàm của hàm mũ [latex]e^x[/latex] chính là chính nó, giúp đơn giản hóa các phép tính trong các bài toán liên quan đến hàm mũ và logarit.

Xác suất thống kê

Bằng cách nghiên cứu và phân tích dữ liệu đầu vào, chúng ta có thể lựa chọn các thuật toán học máy phù hợp nhất. Những ý tưởng và công cụ hỗ trợ phân tích này thường được tập hợp dưới khái niệm xác suất thống kê. Các khái niệm và ngôn ngữ xác suất thống kê thống kê xuất hiện khắp nơi trong lĩnh vực học máy, từ các bài báo học thuật, chú thích trong mã nguồn, đến tài liệu của các thư viện phần mềm.

Sự ngẫu nhiên (Randomness)

Số ngẫu nhiên đóng vai trò quan trọng trong nhiều thuật toán học máy. Chúng được sử dụng để khởi tạo hệ thống, điều khiển các bước trong quá trình học, và đôi khi còn ảnh hưởng đến kết quả đầu ra.

Việc chọn số ngẫu nhiên đúng cách là yếu tố quyết định: nó có thể tạo ra sự khác biệt giữa một hệ thống học được từ dữ liệu và cho ra kết quả hữu ích, với một hệ thống không học được gì.

Thay vì chọn các số một cách tùy tiện, chúng ta sử dụng nhiều công cụ để kiểm soát loại số cần dùng và cách chọn chúng.

Thông thường, chúng ta chọn một số ngẫu nhiên trong khoảng giới hạn bởi giá trị tối thiểu và tối đa, như khi ai đó yêu cầu bạn “chọn một số từ 1 đến 10”. Trong ví dụ này, lựa chọn của chúng ta bị giới hạn trong một tập hợp hữu hạn các số nguyên từ 1 đến 10. Tuy nhiên, trong thực tế, chúng ta thường làm việc với số thực, có thể nằm giữa các số nguyên. Trong khoảng từ 1 đến 10, có 10 số nguyên, nhưng số lượng số thực là vô hạn.

Khi nói về các tập hợp số, dù ngẫu nhiên hay không, chúng ta thường đề cập đến giá trị trung bình của chúng. Đây là cách đơn giản để mô tả đặc trưng của tập hợp. Có ba cách phổ biến để tính giá trị trung bình, và chúng thường được sử dụng, nên chúng ta sẽ làm rõ tại đây. Hãy lấy ví dụ một danh sách gồm năm số: 1, 3, 4, 4, 13.

Trung bình cộng (mean) là giá trị mà chúng ta thường hiểu là “trung bình” trong ngôn ngữ hàng ngày. Nó được tính bằng cách cộng tất cả các phần tử trong danh sách và chia cho số lượng phần tử. Trong ví dụ, tổng các phần tử là 1 + 3 + 4 + 4 + 13 = 25. Có năm phần tử, nên trung bình cộng là 25 / 5 = 5.
Mốt (mode) là giá trị xuất hiện nhiều nhất trong danh sách. Trong ví dụ, số 4 xuất hiện hai lần, trong khi các số khác chỉ xuất hiện một lần, nên 4 là mốt. Nếu không có giá trị nào xuất hiện nhiều hơn các giá trị khác, danh sách được coi là không có mốt.
Trung vị (median) là giá trị nằm ở giữa khi danh sách được sắp xếp từ nhỏ đến lớn. Trong danh sách đã sắp xếp của chúng ta (1, 3, 4, 4, 13), số 4 nằm ở giữa, nên 4 là trung vị. Nếu danh sách có số phần tử chẵn, trung vị là trung bình cộng của hai phần tử ở giữa. Ví dụ, với danh sách 1, 3, 4, 8, trung vị là (3 + 4) / 2 = 3,5.

Biến ngẫu nhiên và phân phối xác suất (Random Variables and Probability Distributions)

Giả sử bạn là một nhiếp ảnh gia được giao nhiệm vụ chụp ảnh cho một bài báo về bãi xe phế liệu, tập trung vào các xe tải và ô tô hỏng.

Bạn đến một bãi xe chứa nhiều phương tiện hỏng hóc. Sau khi trò chuyện với chủ bãi, bạn đồng ý trả tiền để cô ấy mang từng chiếc xe đến cho bạn chụp ảnh. Để thêm phần thú vị, cô ấy sử dụng một bánh xe quay cũ trong văn phòng, với mỗi khe trên bánh xe đại diện cho một chiếc xe trong bãi, được đánh số từ 1.

Mỗi lần bạn trả tiền, cô ấy quay bánh xe. Khi bánh xe dừng, cô ấy ghi lại số ở vị trí trên cùng, lái xe kéo đến và mang chiếc xe tương ứng đến cho bạn. Bạn chụp ảnh, sau đó cô ấy đưa xe trở lại bãi. Nếu muốn chụp chiếc xe khác, bạn trả tiền, cô ấy quay bánh xe, và quy trình lặp lại.

Giả sử bài báo yêu cầu bạn chụp ảnh năm loại xe khác nhau: sedan, bán tải (pickup), minivan, SUV, và wagon. Với mỗi loại xe, bạn muốn biết xác suất nhận được loại xe đó khi bánh xe quay. Để tính toán, bạn đi kiểm tra từng chiếc xe trong bãi và phân loại chúng vào năm nhóm này. Kết quả được thể hiện như sau:

Trong gần 950 chiếc xe, minivan chiếm số lượng lớn nhất, tiếp theo là xe bán tải, wagon, sedan, và SUV. Vì mỗi chiếc xe có cơ hội được chọn như nhau, khi quay bánh xe, khả năng cao nhất bạn sẽ nhận được một chiếc minivan.

Nhưng cụ thể, khả năng nhận được minivan cao hơn bao nhiêu?

Để xác định xác suất nhận được từng loại xe, chúng ta chia số lượng xe của mỗi loại cho tổng số xe.

Xác định số lượng từng loại xe
Ví dụ:

Minivan: 320 chiếc
Pickup: 210 chiếc
Wagon: 180 chiếc
Sedan: 130 chiếc
SUV: 110 chiếc
Tổng cộng: 950 chiếc

Tính xác suất bằng cách chia số lượng mỗi loại xe cho tổng số xe

Minivan: 320 / 950 ≈ 0.337
Pickup: 210 / 950 ≈ 0.221
Wagon: 180 / 950 ≈ 0.189
Sedan: 130 / 950 ≈ 0.137
SUV: 110 / 950 ≈ 0.116

Chuyển sang phần trăm bằng cách nhân với 100

Minivan: 0.337 × 100 = 33.7%
Pickup: 22.1%
Wagon: 18.9%
Sedan: 13.7%

Kết quả này cho biết xác suất nhận được từng loại xe, như được minh họa dưới đây:

Tổng các xác suất của năm loại xe bằng 1,0, thể hiện quy tắc cơ bản của xác suất: các giá trị phải nằm trong khoảng từ 0 đến 1 và tổng bằng 1.

Dựa trên phân phối xác suất này, chúng ta có thể hình dung một bánh xe quay đơn giản hơn, như sau:

Xác suất để con trỏ dừng ở một vùng nhất định tỷ lệ với phần chu vi của vùng đó, được vẽ theo tỷ lệ giống như trong phân phối xác suất.

Thông thường, khi tạo số ngẫu nhiên trên máy tính, chúng ta không sử dụng bánh xe quay mà dựa vào phần mềm để mô phỏng quá trình này. Chẳng hạn, chúng ta có thể cung cấp cho một hàm thư viện danh sách các giá trị, như độ cao của các cột trong phân phối xác suất, và yêu cầu trả về một giá trị. Chúng ta kỳ vọng sẽ nhận được minivan khoảng 34% thời gian, xe bán tải khoảng 26% thời gian, v.v.

Biến ngẫu nhiên

Việc chọn một giá trị ngẫu nhiên từ danh sách các lựa chọn, mỗi lựa chọn có xác suất riêng, đòi hỏi một quy trình cụ thể. Để tiện lợi, chúng ta gói gọn quá trình này vào một khái niệm gọi là biến ngẫu nhiên. (random variable)

Quá trình chọn một giá trị từ phân phối được gọi là rút một giá trị từ biến ngẫu nhiên.

Hàm khối xác suất

Chúng ta đã gọi biểu đồ xác suất là phân phối xác suất, nhưng nó cũng có thể được xem như một hàm. Khi gọi hàm này, nó trả về một loại xe với xác suất tương ứng. Khi chỉ có một số lượng hữu hạn giá trị trả về, như năm loại xe trong ví dụ, chúng ta gọi đó là hàm khối xác suất (probability mass function – pmf) hoặc phân phối xác suất rời rạc. Các thuật ngữ này nhấn mạnh rằng chỉ có một số lượng cố định các kết quả có thể xảy ra.

Chúng ta cũng có thể tạo ra các phân phối xác suất liên tục, thường được sử dụng khi khởi tạo các giá trị trong mạng nơ-ron.

Hãy lấy ví dụ: giả sử bạn muốn biết lượng dầu còn lại trong mỗi chiếc xe mà chủ bãi mang đến. Lượng dầu là một biến liên tục, vì nó có thể là bất kỳ số thực nào.

Biểu đồ phân phối xác suất liên tục cho phép chúng ta tính xác suất nhận được một giá trị trong một khoảng nhất định bằng cách tính diện tích dưới đường cong trong khoảng đó. Chẳng hạn, để tìm xác suất nhận được một chiếc xe có 0,45 đơn vị dầu, chúng ta không chỉ nhìn vào giá trị tại 0,45 mà xem xét một khoảng nhỏ, ví dụ từ 0,44 đến 0,46, và tính diện tích dưới đường cong trong khoảng này. Điều này có nghĩa là đường cong có thể có giá trị lớn hơn 1, miễn là tổng diện tích dưới toàn bộ đường cong bằng 1.

Phân phối như thế này được gọi là phân phối xác suất liên tục (continuous probability distribution – cpd) hoặc hàm mật độ xác suất (probability density function – pdf). Đôi khi, thuật ngữ “hàm mật độ xác suất” được sử dụng một cách không chính thức cho cả phân phối rời rạc, nhưng ngữ cảnh thường giúp làm rõ ý nghĩa.

Hiệp phương sai và Tương quan (Covariance and Correlation)

Đôi khi các biến số có thể liên quan với nhau theo những cách thú vị. Hãy tưởng tượng một biến cho chúng ta biết nhiệt độ bên ngoài, và biến kia cho biết khả năng có tuyết rơi. Khi nhiệt độ rất cao, khả năng có tuyết gần như bằng không – việc biết được giá trị của một biến sẽ tiết lộ thông tin quý giá về biến kia. Trong trường hợp này, mối quan hệ mang tính âm tính: khi nhiệt độ tăng cao, khả năng có tuyết giảm xuống, và ngược lại.

Mặt khác, biến thứ hai có thể cho chúng ta biết số lượng người bơi dự kiến tại hồ địa phương. Mối liên hệ giữa nhiệt độ và số người bơi mang tính dương tính, bởi vì trong những ngày ấm áp hơn, chúng ta sẽ thấy nhiều người bơi hơn, và ngược lại.

Khả năng phát hiện những mối quan hệ này và đo lường sức mạnh của chúng có giá trị thực tiễn to lớn. Giả sử chúng ta đang lên kế hoạch huấn luyện một thuật toán để trích xuất thông tin từ tập dữ liệu. Nếu phát hiện ra hai giá trị trong dữ liệu có mối liên hệ chặt chẽ (như nhiệt độ và khả năng có tuyết), chúng ta có thể loại bỏ một trong hai biến đó khỏi dữ liệu vì nó thừa thãi. Điều này không chỉ cải thiện tốc độ huấn luyện mà còn có thể nâng cao chất lượng kết quả.

Trong phần này, chúng ta sẽ khám phá một phép đo gọi là hiệp phương sai (covariance), được các nhà toán học phát triển để xác định sức mạnh của những mối quan hệ này. Chúng ta cũng sẽ tìm hiểu một biến thể gọi là tương quan (correlation), thường hữu ích hơn vì nó không phụ thuộc vào quy mô của các con số liên quan.

Hiệp phương sai

Hãy tưởng tượng chúng ta có hai biến và nhận thấy một mô hình số học cụ thể liên quan đến chúng. Khi giá trị của một biến tăng, biến kia tăng theo một bội số cố định của lượng đó, và điều tương tự xảy ra khi một trong hai biến giảm.

Ví dụ cụ thể: giả sử biến A tăng 3 đơn vị, và biến B tăng 6 đơn vị. Sau đó, B tăng 4 đơn vị, và A tăng 2 đơn vị. Tiếp theo, A giảm 4 đơn vị, và B giảm 8 đơn vị. Trong mọi trường hợp, B tăng hoặc giảm gấp đôi lượng mà A tăng hoặc giảm, vì vậy bội số cố định của chúng ta là 2.

Khi chúng ta quan sát thấy mối quan hệ như vậy (với bất kỳ bội số nào, không chỉ riêng số 2), chúng ta nói rằng hai biến này đồng biến (covary). Chúng ta đo lường sức mạnh của mối liên hệ giữa hai biến, hay tính nhất quán mà chúng đồng biến, bằng một con số gọi là hiệp phương sai. Nếu phát hiện ra rằng khi một giá trị tăng hoặc giảm, giá trị kia cũng làm điều tương tự theo một lượng có thể dự đoán được, thì hiệp phương sai là một số dương, và chúng ta nói rằng hai biến đang thể hiện hiệp phương sai dương.

Cách cổ điển để thảo luận về hiệp phương sai là vẽ các điểm trong không gian 2D

Ở đây chúng ta thấy hai tập hợp điểm đồng biến khác nhau. Mỗi điểm có tọa độ x và y, nhưng chúng chỉ là đại diện cho bất kỳ hai biến nào chúng ta muốn so sánh. Sự thay đổi của y theo dõi sự thay đổi của x càng nhất quán, hiệp phương sai càng mạnh.

Nếu một giá trị giảm bất cứ khi nào giá trị kia tăng, chúng ta nói các biến có hiệp phương sai âm.

Nếu hai biến không có chuyển động khớp nhau một cách nhất quán như vậy, thì hiệp phương sai bằng không.

Khái niệm hiệp phương sai của chúng ta chỉ nắm bắt được mối quan hệ giữa các biến khi sự thay đổi của chúng là bội số của nhau. Hình trên cho thấy rằng có thể có một mô hình rõ ràng trong dữ liệu (ở đây các chấm tạo thành một phần của hình tròn), nhưng hiệp phương sai vẫn bằng không vì các mối quan hệ rất không nhất quán.

Tương quan

Hiệp phương sai là một khái niệm hữu ích, nhưng nó có một vấn đề. Do cách nó được định nghĩa về mặt toán học, nó không tính đến mối quan hệ giữa các đơn vị của hai biến, điều này khiến chúng ta khó so sánh sức mạnh của các hiệp phương sai khác nhau.

Ví dụ, giả sử chúng ta đo một tá biến mô tả một cây đàn guitar: độ dày của gỗ, chiều dài của cần đàn, thời gian một nốt nhạc cộng hưởng, lực căng trên dây đàn, v.v. Chúng ta có thể tìm thấy hiệp phương sai giữa các cặp phép đo khác nhau, nhưng không thể so sánh một cách có ý nghĩa lượng hiệp phương sai để tìm ra cặp nào có mối quan hệ mạnh nhất và yếu nhất. Ngay cả thang đo cũng quan trọng: nếu chúng ta tìm hiệp phương sai cho một cặp phép đo bằng centimet và hiệp phương sai cho một cặp phép đo khác bằng inch, chúng ta không thể so sánh những giá trị đó để nói cặp nào đồng biến mạnh hơn.

Dấu của hiệp phương sai là tất cả những gì chúng ta học được: giá trị dương có nghĩa là mối quan hệ dương, giá trị âm có nghĩa là mối quan hệ âm, và số không có nghĩa là không có mối quan hệ. Chỉ có dấu là một vấn đề, bởi vì chúng ta thực sự muốn so sánh các tập hợp biến khác nhau.

Sau đó, chúng ta có thể tìm ra thông tin hữu ích như biến nào có tương quan dương và âm mạnh nhất và yếu nhất. Chúng ta có thể sử dụng thông tin đó để cắt giảm kích thước tập dữ liệu của mình, ví dụ, bằng cách loại bỏ một trong các phép đo trong một hoặc nhiều cặp có liên quan chặt chẽ.

Để có được một phép đo cho phép chúng ta thực hiện những so sánh này, chúng ta có thể tính toán một con số hơi khác gọi là hệ số tương quan (correlation coefficient), hay đơn giản là tương quan. Giá trị này bắt đầu với hiệp phương sai nhưng bao gồm một bước tính toán bổ sung. Kết quả là một con số không phụ thuộc vào các đơn vị được chọn cho các biến. Chúng ta có thể nghĩ về tương quan như một phiên bản được chia tỷ lệ của hiệp phương sai, luôn cho chúng ta một giá trị giữa −1 và 1. Giá trị +1 cho chúng ta biết chúng ta có tương quan dương hoàn hảo, trong khi giá trị −1 cho chúng ta biết chúng ta có tương quan âm hoàn hảo.

Tương quan dương hoàn hảo dễ nhận biết: tất cả các chấm nằm dọc theo một đường thẳng di chuyển theo hướng đông bắc-tây nam.

Loại mối quan hệ nào giữa các điểm mang lại cho chúng ta tương quan dương, nhưng ở đâu đó trong khoảng từ 0 đến 1? Đó là khi giá trị y tiếp tục tăng với x, nhưng tỷ lệ sẽ không cố định. Chúng ta có thể không dự đoán được nó thay đổi bao nhiều, nhưng chúng ta biết rằng sự tăng của x gây ra sự tăng của y, và sự giảm của x gây ra sự giảm của y.

Hình trên cho thấy biểu đồ chấm cho một số giá trị dương của tương quan giữa 0 và 1. Các chấm càng gần với việc rơi trên một đường thẳng, giá trị tương quan càng gần với 1. Chúng ta nói rằng nếu giá trị gần số không thì tương quan yếu (hoặc thấp), nếu nó khoảng 0.5 thì trung bình, và nếu nó gần 1 thì mạnh (hoặc cao).

Bây giờ hãy xem xét giá trị tương quan bằng không. Tương quan bằng không có nghĩa là không có mối quan hệ giữa sự thay đổi của một biến và sự thay đổi của biến kia. Chúng ta không thể dự đoán điều gì sẽ xảy ra. Nhớ lại rằng tương quan chỉ là một phiên bản được chia tỷ lệ của hiệp phương sai, vì vậy khi hiệp phương sai bằng không, tương quan cũng vậy.

Tương quan âm giống như tương quan dương, chỉ khác là các biến di chuyển theo hướng ngược nhau: khi x tăng, y giảm. Giống như với tương quan dương, nếu giá trị gần số không thì tương quan yếu (hoặc thấp), nếu nó khoảng −0.5 thì trung bình, và nếu nó gần −1 thì mạnh (hoặc cao).

Khi hai biến có tương quan dương hoặc âm hoàn hảo (tức là giá trị +1 và −1), chúng ta nói rằng các biến được tương quan tuyến tính, bởi vì (như chúng ta đã thấy) các điểm nằm trên một đường thẳng. Các biến được mô tả bởi bất kỳ giá trị nào khác của tương quan được cho là tương quan phi tuyến tính.

Đạo hàm (Derivative)

Một trong những khía cạnh quan trọng nhất của một đường cong là đạo hàm của nó. Đạo hàm cung cấp thông tin về hình dạng của đường cong tại bất kỳ điểm nào trên đó. Trong phần này, chúng ta sẽ xem xét các ý tưởng cốt lõi dẫn đến khái niệm đạo hàm.

Cực đại và cực tiểu (Maximums and Minimums)

Trong học máy, một nhiệm vụ quan trọng là giảm thiểu sai số của hệ thống. Nói rộng ra, ta muốn tìm cực đại (điểm cao nhất) hoặc cực tiểu (điểm thấp nhất) của đường cong trên toàn bộ chiều dài của nó. Nếu đây là điểm cao nhất hoặc thấp nhất của cả đường cong, ta gọi chúng là cực đại toàn cục (global maximum) và cực tiểu toàn cục (global minimum).

Để đơn giản hóa, ta tập trung vào vùng lân cận của một điểm. Hãy tưởng tượng ta đứng tại một điểm trên đường cong và bước sang trái. Nếu con đường dốc lên, ta đi tiếp cho đến khi nó dốc xuống, rồi dừng lại. Nếu con đường dốc xuống, ta dừng khi nó bắt đầu dốc lên. Ta làm tương tự khi bước sang phải. Kết quả, ta có ba điểm: điểm xuất phát, điểm dừng bên trái, và điểm dừng bên phải.

Để hiểu sâu hơn về đạo hàm, ta cần làm quen với đường tiếp tuyến. Hãy hình dung đường cong như một con đường uốn lượn. Tại mỗi điểm, ta có thể vẽ một đường thẳng. Đường tiếp tuyến này cho biết con đường đang dốc lên, dốc xuống, hay nằm ngang tại điểm đó.

Điều kỳ diệu là tại các điểm cực đại hoặc cực tiểu cục bộ, đường tiếp tuyến luôn nằm ngang, với độ dốc bằng 0. Vì vậy, để tìm cực đại và cực tiểu, ta chỉ cần tìm những điểm mà đường tiếp tuyến nằm ngang.

Để vẽ đường tiếp tuyến, ta chọn một điểm, bước một khoảng nhỏ sang trái và phải trên đường cong, đánh dấu hai điểm, rồi nối chúng bằng một đường thẳng. Khi kéo hai điểm này lại gần điểm ban đầu, đường thẳng sẽ trở thành đường tiếp tuyến. Độ dốc của đường này chính là đạo hàm.

Đạo hàm không chỉ là một khái niệm toán học trừu tượng, mà còn là công cụ cốt lõi trong học máy. Khi ta muốn giảm sai số, ta sử dụng đạo hàm để xác định hướng di chuyển trên đường cong.

Nếu đạo hàm dương, ta di chuyển ngược hướng để tìm cực tiểu.

Nếu đạo hàm âm, ta di chuyển theo hướng dương.

Bằng cách lặp lại quá trình này, ta tiến gần đến điểm có đạo hàm bằng 0 – nơi cực đại hoặc cực tiểu cục bộ nằm

Đạo hàm riêng (Partial Derivatives)

Thay vì tính độ dốc trên một hàm một chiều, đạo hàm riêng tính độ dốc theo từng biến, giả sử các biến còn lại được giữ không đổi.

Hãy xem xét hàm [latex]f(x, y) = 2x^3 + 3y^3[/latex]. Đạo hàm riêng theo [latex]x[/latex] và [latex]y[/latex] lần lượt là:

[latex]\frac{\partial f}{\partial x} = 6x^2[/latex]

[latex]\frac{\partial f}{\partial y} = 9y^2[/latex]

Khi làm việc với các hàm đa biến, khái niệm gradient (gradient vector) trở nên quan trọng. Gradient là một vectơ bao gồm tất cả các đạo hàm riêng theo từng biến, chỉ ra hướng và độ lớn của sự thay đổi nhanh nhất của hàm. Với hàm [latex]f(x, y)[/latex], gradient được biểu diễn là:

[latex]\nabla f = \left( \frac{\partial f}{\partial x}, \frac{\partial f}{\partial y} \right)[/latex]

Trong trường hợp [latex]f(x, y) = 2x^3 + 3y^3[/latex], gradient tại một điểm [latex](x, y)[/latex] là:

[latex]\nabla f = (6x^2, 9y^2)[/latex]

Ví dụ, tại điểm [latex](1, 2)[/latex]:

[latex]\frac{\partial f}{\partial x} = 6 \cdot 1^2 = 6[/latex]
[latex]\frac{\partial f}{\partial y} = 9 \cdot 2^2 = 36[/latex]
Gradient: [latex]\nabla f = (6, 36)[/latex]

Gradient không chỉ cho biết độ dốc theo từng hướng mà còn chỉ ra hướng tăng trưởng nhanh nhất của hàm. Điều này rất quan trọng trong các thuật toán tối ưu hóa như gradient descent, nơi gradient được sử dụng để cập nhật các tham số nhằm giảm thiểu hàm mất mát.

Đây là một bề mặt cong với các giá trị [latex]z = f(x, y)[/latex] thay đổi theo [latex]x[/latex] và [latex]y[/latex]. Một số điểm đáng chú ý:

Trục [latex]x[/latex] và [latex]y[/latex] đại diện cho các biến đầu vào, trong khi trục [latex]z[/latex] thể hiện giá trị của hàm.
Màu sắc thay đổi (từ xanh đậm đến vàng) cho thấy sự thay đổi của giá trị [latex]z[/latex], với các vùng màu vàng thường là đỉnh hoặc đáy của bề mặt.
Độ dốc của bề mặt tại một điểm (ví dụ tại [latex](x, y) = (1, 2)[/latex]) có thể được biểu diễn bằng gradient, với thành phần [latex]6[/latex] theo [latex]x[/latex] và [latex]36[/latex] theo [latex]y[/latex].

Quy tắc Chuỗi (Chain Rule).

Giả sử bạn có hai hàm số sau:

Hàm thứ nhất: [latex]y = x^2 + 1[/latex]
Hàm thứ hai: [latex]z = y^3 – 2[/latex]

Lưu ý rằng hai hàm này có mối liên kết, vì biến [latex]y[/latex] là đầu ra của hàm thứ nhất nhưng lại là đầu vào của hàm thứ hai. Do đó, chúng ta có thể thay hàm [latex]y[/latex] vào hàm [latex]z[/latex] như sau:

[latex]z = (x^2 + 1)^3 – 2[/latex]

Vậy đạo hàm của [latex]z[/latex] theo [latex]x[/latex] là gì? Chúng ta đã có biểu thức thay thế biểu diễn [latex]z[/latex] theo [latex]x[/latex]

Kết quả: [latex]6x(x^2 + 1)^2[/latex]

Vậy đạo hàm của [latex]z[/latex] theo [latex]x[/latex] là:

[latex]\frac{dz}{dx} = 6x(x^2 + 1)^2[/latex]

Tuy nhiên, hãy thử một cách tiếp cận khác. Nếu chúng ta tính riêng đạo hàm của hàm [latex]y[/latex] và hàm [latex]z[/latex], sau đó nhân chúng với nhau, điều này cũng tạo ra đạo hàm của [latex]z[/latex] theo [latex]x[/latex]! Hãy thử làm:

Đạo hàm của [latex]y = x^2 + 1[/latex] theo [latex]x[/latex]: [latex]\frac{dy}{dx} = 2x[/latex]
Đạo hàm của [latex]z = y^3 – 2[/latex] theo [latex]y[/latex]: [latex]\frac{dz}{dy} = 3y^2[/latex]
Theo quy tắc chuỗi: [latex]\frac{dz}{dx} = \frac{dz}{dy} \cdot \frac{dy}{dx} = 3y^2 \cdot 2x = 6xy^2[/latex]

Biểu thức [latex]6xy^2[/latex] trông có vẻ khác với [latex]6x(x^2 + 1)^2[/latex], nhưng đó chỉ vì chúng ta chưa thay hàm [latex]y = x^2 + 1[/latex] vào. Hãy thay [latex]y[/latex] để biểu diễn toàn bộ đạo hàm theo [latex]x[/latex]:

[latex]6xy^2 = 6x(x^2 + 1)^2[/latex]

Kết quả này trùng khớp với đạo hàm đã tính trước đó!

Đây chính là quy tắc chuỗi, quy tắc này phát biểu rằng: với một hàm [latex]y[/latex] (có biến đầu vào là [latex]x[/latex]) được đưa vào một hàm khác [latex]z[/latex] (có biến đầu vào là [latex]y[/latex]), chúng ta có thể tìm đạo hàm của [latex]z[/latex] theo [latex]x[/latex] bằng cách nhân hai đạo hàm tương ứng:

[latex]\frac{dz}{dx} = \frac{dz}{dy} \cdot \frac{dy}{dx}[/latex]

Reference:

Essential Math for Data Science (Thomas Nield)
Deep Learning (Andrew Glassner)

[SWE học A.I] Phần 1: Sơ lược tiếp cận các mô hình A.I

This entry is part 1 of 8 in the series SWE Học A.I

Học máy (Machine Learning) là gì?

Học máy, nói một cách đơn giản, là một tập hợp những kỹ thuật mà máy tính dùng để “học” từ dữ liệu. Dữ liệu ở đây có thể là bất cứ thứ gì được biểu diễn bằng số. Có thể là giá cổ phiếu biến động qua từng ngày, khối lượng của các hành tinh, chiều cao của mọi người đến hội chợ, hay thậm chí là âm thanh khi bạn nói “Alo” vào điện thoại, những bức ảnh chụp hoa lá, mèo con, hay cả nội dung một bài báo, một cuốn tiểu thuyết. Thậm chí, sở thích nghe nhạc, xem phim, hay hành vi của bạn – như việc bạn hay đi dạo công viên hay thích ăn phở vào cuối tuần – cũng có thể được mã hóa thành số và trở thành dữ liệu.

Mục tiêu của học máy là tìm ra những thông tin “có ý nghĩa” từ đống dữ liệu đó. Nhưng “có ý nghĩa” là thế nào? Tùy bạn thôi! Có khi là tìm ra quy luật ẩn trong dữ liệu, như đoán xem bạn sẽ thích bộ phim nào dựa trên những phim bạn đã xem và chấm điểm. Hoặc là nhận diện chữ viết tay trên một mẩu giấy, hay chỉ cần vài nốt nhạc là biết ngay bài hát đó là gì. Tóm lại, học máy giúp máy tính “hiểu” và dự đoán dựa trên dữ liệu, giống như cách bạn nhận ra một người bạn cũ qua vài đặc điểm quen thuộc.

Giả sử chúng ta có một bảng dữ liệu ghi lại thông tin về thói quen xem phim của một nhóm người:

Người dùng	Phim đã xem	Thể loại yêu thích	Điểm chấm trung bình
A	Inception, Interstellar, Tenet	Khoa học viễn tưởng	9.0
B	The Notebook, Titanic, La La Land	Lãng mạn, Tình cảm	8.5
C	The Dark Knight, Joker, Logan	Hành động, Tâm lý	9.2
D	Coco, Encanto, Inside Out	Hoạt hình, Gia đình	8.8
E	Inception, The Matrix, Blade Runner	Khoa học viễn tưởng	9.1

Từ bảng dữ liệu trên, ta có thể “nhìn thấy” một số điều thú vị. Ví dụ, người dùng A và E có điểm chấm khá cao và cùng yêu thích thể loại khoa học viễn tưởng. Từ đó, một hệ thống học máy có thể đề xuất cho người dùng A những bộ phim như The Matrix hoặc Blade Runner – vốn đã được người dùng E yêu thích. Hay ngược lại, với người dùng mới có hành vi tương tự A, hệ thống có thể dự đoán họ sẽ thích Interstellar chẳng hạn.

Chính từ những mẫu dữ liệu tưởng chừng đơn giản như thế này, học máy có thể học được mối liên hệ giữa “sở thích” và “nội dung”, để từ đó đưa ra những đề xuất, dự đoán, hay thậm chí là tự động phân loại, nhận diện xu hướng mà con người khó nhìn thấy bằng mắt thường.

Hệ chuyên gia (Expert System)

Ngày xưa, khi học sâu (deep learning) chưa có được sự chú ý nhiều như bây giờ, người ta hay dùng hệ chuyên gia để dạy máy tính học từ dữ liệu.

Hệ chuyên gia là gì? Nó giống như một chương trình máy tính được thiết kế để bắt chước cách suy nghĩ của các chuyên gia con người – như bác sĩ, kỹ sư, hay thậm chí là nhạc sĩ. Ý tưởng là bạn quan sát một chuyên gia làm việc, xem họ làm gì, làm như thế nào, đôi khi còn yêu cầu họ kể lại quy trình suy nghĩ của mình. Từ đó, bạn tạo ra một bộ quy tắc để máy tính làm theo. Hy vọng là máy tính sẽ “bắt chước” được công việc của chuyên gia chỉ bằng cách tuân theo những quy tắc đó.

Ví dụ thực tế: Nhận diện số 7

Giả sử chúng ta muốn dạy máy tính nhận diện số 7 viết tay. Sau khi hỏi han, quan sát nhiều người, bạn có thể nghĩ ra ba quy tắc nhỏ để nhận diện số 7:

một, số 7 thường có một đường ngang ở gần đỉnh;
hai, nó có một đường chéo từ đông bắc xuống tây nam;
và ba, hai đường đó gặp nhau ở góc trên bên phải.

Nhưng đời không như mơ! Một ngày, bạn gặp một số 7 kỳ lạ.

Số 7 này có thêm một đường ngang cắt qua đường chéo ở giữa.

Bộ quy tắc ban đầu của chúng ta không nhận ra đây là số 7, vì chúng ta chưa nghĩ tới trường hợp đặc biệt này. Thế là phải thêm một quy tắc mới. Nhưng rồi lại có số 7 khác, với kiểu viết khác, và bạn lại phải thêm quy tắc nữa. Cứ thế, việc tạo ra một bộ quy tắc đầy đủ cho một vấn đề phức tạp trở thành một nhiệm vụ bất khả thi. Bạn phải đào bới những suy luận mà ngay cả chuyên gia cũng không nhận ra, biến chúng thành hàng tá quy tắc, rồi chỉnh sửa, gỡ lỗi, bổ sung cho những trường hợp bị bỏ sót.

Quá nhiều quy tắc

Tìm ra bộ quy tắc hoàn chỉnh không phải chuyện dễ. Chuyên gia con người thường làm việc theo trực giác, và những ngoại lệ hay trường hợp đặc biệt thì vô vàn.

Bạn thử tưởng tượng mà xem: làm sao viết được bộ quy tắc để máy tính bắt chước cách một bác sĩ X-quang đọc phim MRI để xác định một vết mờ là lành tính hay không? Hay cách một nhân viên điều khiển không lưu xử lý hàng loạt chuyến bay trong giờ cao điểm? Hoặc cách ai đó lái xe an toàn trong cơn bão lớn?

Đã vậy, công nghệ, luật lệ, hay thói quen xã hội còn thay đổi liên tục, khiến bạn phải luôn cập nhật, sửa chữa bộ quy tắc rối như tơ vò này.

Hệ chuyên gia có thể hoạt động tốt trong một số trường hợp, nhưng để áp dụng rộng rãi thì quá khó. Với những trường hợp như này, “học sâu” (deep learning) có thể thể hiện được năng lực của nó. Với đủ dữ liệu huấn luyện, các thuật toán học sâu tự tìm ra quy tắc mà không cần chúng ta phải chỉ từng bước.

Bạn không cần nói với máy tính rằng số 2 trông thế nào, hay số 7 ra sao – nó tự học từ dữ liệu. Nó có thể xác định vết mờ trên MRI là lành tính hay không, đánh giá một bức ảnh chụp từ điện thoại có phơi sáng đúng không, hay xác minh một đoạn văn có phải do một nhân vật lịch sử viết hay không.

Học có giám sát (Supervised Learning)

Nói một cách đơn giản, học máy (machine learning) là xây dựng các thuật toán để tìm ra mối quan hệ trong dữ liệu.

Học có giám sát là một phần của học máy, tập trung vào việc tìm mối liên hệ giữa các đặc điểm đã được đo lường sẵn. Chẳng hạn, trong chương này, mình sẽ nói về một bài toán thực tế: tìm mối liên hệ giữa các đặc điểm của một ngôi nhà (như số phòng, diện tích, hay khoảng cách đến trường học) và giá trị của ngôi nhà.

Giả sử ta muốn tạo một hệ thống, gọi là bộ phân loại hình ảnh, để nhận ra đồ vật chính trong ảnh. Mình sẽ đưa máy một bộ sưu tập ảnh, mỗi ảnh đi kèm một nhãn – như ảnh con hổ có nhãn “hổ”, ảnh con mèo có nhãn “mèo”, và chúng ta kì vọng khi thấy một hình ảnh con hổ khác chưa có trong bộ sưu tập, hệ thống có thể biết được nó là hổ hay mèo.

Hoặc, nếu mình có một cuốn sổ ghi lại các công thức nấu ăn và chấm điểm xem mình thích món nào, thì công thức là dữ liệu đầu vào, còn điểm số là nhãn. Sau khi được huấn luyện với cả tá dữ liệu như thế, máy có thể nhìn một công thức mới và đoán món này có ngon theo khẩu vị của mình không.

Máy Tính “Nghĩ” Như Thế Nào?

Thực chất, máy tính không hiểu món ăn ngon dở ra sao, cũng chẳng biết con hổ trông thế nào ngoài đời. Nó chỉ nhìn vào dữ liệu bạn đưa, tìm các mẫu (patterns) trong đó, và học cách khớp dữ liệu với nhãn. Khi bạn đưa vào một bức ảnh hay công thức mới, máy sẽ dùng những “quy tắc” nó học được để chọn nhãn phù hợp nhất. Nếu máy đoán đúng đủ nhiều lần, mình gọi là nó đã được huấn luyện tốt.

Nhìn vào ảnh trên, nơi một bộ phân loại hình ảnh đã được huấn luyện thử phân tích bốn bức ảnh lấy từ trên mạng. Máy chưa từng thấy những bức ảnh này bao giờ. Với mỗi bức, nó đưa ra xác suất cho 1.000 nhãn mà nó biết. Chẳng hạn, bức ảnh ở góc trên bên trái là một chùm chuối. Lý tưởng thì máy sẽ trả về nhãn “chùm chuối”, nhưng vì nó không được huấn luyện với nhãn này, nó chỉ chọn được nhãn gần nhất là “chuối”. Giống như khi bạn chỉ biết từ “mèo” và không biết từ “mèo tam thể”, bạn sẽ gọi con mèo tam thể là “mèo” thôi.

Cách Dữ Liệu Được Sắp Xếp

Mỗi đặc điểm cần được đo lường chính xác và biểu diễn bằng số. Số phòng hay diện tích thì dễ, vì chúng đã là số. Nhưng nếu bạn có thông tin kiểu như mô tả bằng ngôn ngữ tự nhiên về khu phố từ TripAdvisor, việc chuyển chúng thành số sẽ phức tạp hơn nhiều. Chuyển đổi đúng cách là yếu tố quyết định xem bạn có tìm ra được mối quan hệ hay không. Với khái niệm mơ hồ như “giá trị ngôi nhà”, mình thường chọn một con số cụ thể, như giá bán.

Khi đã có các đặc điểm dưới dạng số, mình cần tổ chức chúng sao cho dễ xử lý. Cách phổ biến là biểu diễn mỗi ngôi nhà bằng một hàng số (gọi là một “quan sát”), rồi xếp các hàng này thành từng lô (batch) dữ liệu.

Mỗi hàng là một tập hợp các đặc điểm (features), như số phòng, diện tích, hay khoảng cách đến trường. Quá trình chuyển các đặc điểm thực tế (như “nhà gạch đỏ”) thành số được gọi là kỹ thuật đặc trưng (feature engineering).

Giả sử chúng ta đang thu thập dữ liệu để dự đoán giá bán của các ngôi nhà. Dưới đây là một bảng thể hiện dữ liệu đã được xử lý thành dạng số:

ID nhà	Số phòng ngủ	Diện tích (m²)	Khoảng cách đến trường (km)	Loại tường	Có sân vườn	Điểm đánh giá khu phố	Giá bán (triệu VND)
1	3	120	0.5	1 (gạch đỏ)	1 (có)	8.2	3.200
2	2	80	1.2	0 (xi măng)	0 (không)	7.1	2.400
3	4	150	0.3	1 (gạch đỏ)	1 (có)	8.9	4.100
4	1	60	2.0	0 (xi măng)	0 (không)	6.5	1.800

Ở đây, các thông tin dạng mô tả như “loại tường” (gạch đỏ hay xi măng), hay “có sân vườn” (có/không) đã được chuyển thành số – một bước quan trọng trong feature engineering.

Từ bảng dữ liệu trên, ta có thể thấy: những ngôi nhà có diện tích lớn hơn, gần trường học hơn, và nằm trong khu phố có điểm đánh giá cao thường có giá bán cao hơn. Điều này cho thấy tầm quan trọng của việc chuyển đổi và biểu diễn đúng các đặc điểm thành dạng số: chỉ khi dữ liệu được tổ chức một cách chính xác, mô hình học máy mới có thể nhận ra các mối liên hệ như vậy để đưa ra dự đoán hợp lý.

Học không giám sát (Unsupervised Learning)

Ta đã đi qua việc giúp máy tính học được từ những dữ liệu đã được đánh nhãn (label) rõ ràng, dễ sử dụng. Tuy nhiên nếu bạn có một đống dữ liệu mà chẳng có nhãn hay gợi ý gì – giống như một mớ đồ vật lộn xộn, không biết thuộc về đâu. Lúc này, chúng ta có thể dùng học không giám sát. (Unsupervised Learning)

Các thuật toán này sẽ tự mày mò, tìm ra mối liên hệ giữa các mẩu dữ liệu mà chẳng cần ai chỉ bảo “cái này là gì, cái kia là gì”.

Ví dụ:

Khi đang đào móng cho một ngôi nhà mới thì phát hiện cả đống bình gốm cổ, mỗi cái có hoa văn khác nhau. Mình gọi bạn khảo cổ đến, nhưng cô ấy chẳng nhận ra hoa văn nào cả (dữ liệu không có nhãn). Có cái trông giống nhau, có cái lại khác biệt hoàn toàn.

Để sắp xếp đống lộn xộn này, cô ấy đã tiếp cận bằng một cách khác, dù không nhận ra hay biết về bất kì kí hiệu nào trên các món đồ cổ, nên cô không biết những món đồ này tới từ thời đại nào, quý giá hay không. Tuy nhiên, nhìn vào những kí hiệu, trang trí, ta thấy chúng có vẻ giống nhau?, và xuất phát từ 1 phong cách nào đó. Lúc này, nhà khảo cổ chia các phần có vẻ giống nhau thành từng cụm, từng nhóm.

Kĩ thuật này đưa các dữ liệu thành các nhóm liên quan (cụm), nên ta gọi quá trình này là phân cụm (clustering), hay gọi thuật toán này là thuật toán phân cụm (clustering algorithm)

Ngoài ra, học không giám sát còn giúp làm đẹp dữ liệu, như xóa nhiễu trên ảnh chụp bằng điện thoại, hay nén dữ liệu để tiết kiệm không gian mà vẫn giữ được chất lượng – giống như cách file MP3 lưu âm thanh hay JPG lưu ảnh vậy.

Ảnh chụp từ điện thoại thường có nhiễu (noise) do ánh sáng yếu, cảm biến kém, chuyển động, v.v. Học không giám sát có thể tự học cách tách tín hiệu gốc (hình ảnh thật) khỏi nhiễu mà không cần dữ liệu “sạch” để so sánh. Thông thường bài toán này hoạt động nhờ máy chỉ giữ lại thông tin phổ biến, đặc trưng, không thay đổi, còn phần ngẫu nhiên (nhiễu) sẽ bị mất đi.
Giống như file MP3 hay JPG: giữ phần quan trọng (tai người/ mắt người cảm nhận được). Loại bỏ phần dư thừa (âm thanh ngoài khả năng nghe, màu sắc không phân biệt được…).

Học tăng cường (Reinforcement Learning)

Hãy tưởng tượng bạn đang chơi một trò chơi phức tạp, như cờ vua hay sáng tác một bản nhạc. Bạn đứng trước một tình huống: nước đi tiếp theo nên là gì, hay nốt nhạc tiếp theo nên chọn ra sao? Chẳng có một đáp án nào hoàn toàn “đúng” cả. Nhưng bạn có thể cảm nhận rằng một lựa chọn thì “tốt hơn” cái kia. (thử một nốt nhạc khác và khi nghe lại thấy bài nhạc có vẻ hay hơn)

Vậy làm sao để máy tính tự tìm ra cách tốt nhất? Chúng ta để nó thử nghiệm, sai lầm, và học hỏi.

Học tăng cường là khi bạn không đưa ra một hướng dẫn chi tiết kiểu “làm thế này, thế kia”. Thay vào đó, bạn chỉ cần đánh giá những gì máy tính thử nghiệm. Máy tính sẽ dựa vào những đánh giá đó để tìm ra cách hành động tốt nhất, từng bước một, hướng tới kết quả mà chúng ta mong muốn.

Ví dụ:

Nhiệm vụ của chúng ta là quyết định xem thang máy nên “đậu” ở đâu khi không có người gọi, và khi ai đó bấm nút gọi thang, chiếc thang nào sẽ được điều động. Mục tiêu? Làm sao để thời gian chờ trung bình của mọi người là ngắn nhất.

Vấn đề là, làm sao biết được cách sắp xếp thang máy tốt nhất? Chuyện này phụ thuộc hoàn toàn vào thói quen của mọi người trong tòa nhà.

Buổi sáng, có lẽ mọi người đổ xô đến làm việc, nên thang máy nên chờ sẵn ở tầng một để đón khách. Nhưng đến giờ ăn trưa, mọi người lại muốn ra ngoài, vậy thì thang máy nên “canh” ở các tầng trên, sẵn sàng đưa mọi người xuống tầng trệt. À, mà nếu trời mưa thì sao? Có khi mọi người lại muốn lên căng-tin ở tầng cao nhất để ăn trưa. Mỗi ngày, mỗi giờ, tình hình cứ thay đổi liên tục. Vậy thì làm sao tìm được một “chiến lược” hoàn hảo?

Thực chất, chẳng có một chiến lược nào hoàn hảo cả.

Học tăng cường là một giải pháp với ý tưởng: máy tính sẽ tự nghĩ ra một kế hoạch, hoặc thử thay đổi một chút từ kế hoạch hiện tại, rồi kiểm tra xem nó hoạt động tốt thế nào.

Ví dụ

Hãy tưởng tượng bạn có một robot giao hàng trong một siêu thị nhỏ. Nhiệm vụ của robot là giao một đơn hàng từ kho hàng (điểm xuất phát) đến quầy thanh toán (điểm đích). Siêu thị có 3 con đường để đi:

Đường C: Qua khu đồ đông lạnh, trung bình về cả độ dài và đông người.

Đường A: Qua khu rau củ, ngắn nhưng đông khách, dễ bị chậm.

Đường B: Qua khu đồ khô, đường dài hơn nhưng ít người.

Robot sẽ thử đi từng đường, nhận phản hồi là thời gian đi mất bao lâu, và học để chọn đường nhanh nhất qua nhiều lần thử.

Giả lập dữ liệu (thực tế, robot không biết trước):

Đường A: 30 giây (ngắn nhưng đông, dễ chậm).
Đường B: 50 giây (dài hơn, ít người).
Đường C: 40 giây (trung bình).

Phản hồi (thưởng): Robot được điểm dựa trên thời gian:

Điểm = 100 – thời gian (giây). Nghĩa là đi càng nhanh, điểm càng cao.
- Đường A: 100 – 30 = 70 điểm.
- Đường B: 100 – 50 = 50 điểm.
- Đường C: 100 – 40 = 60 điểm.

Mỗi lần, robot chọn một đường, đo thời gian, tính điểm, và ghi nhớ để cải thiện.

Lần thử 1:

Robot chọn ngẫu nhiên: Đường A.
Thời gian: 30 giây.
Điểm: 100 – 30 = 70 điểm.

Lần thử 2:

Robot chọn: Đường B.
Thời gian: 50 giây.
Điểm: 100 – 50 = 50 điểm.

Lần thử 3:

Robot chọn: Đường C.
Thời gian: 40 giây.
Điểm: 100 – 40 = 60 điểm.

Lần thử 4:

Robot quay lại thử Đường A (để kiểm tra lại).
Thời gian: 30 giây.
Điểm: 70 điểm.

Lần thử 5:

Robot thử Đường C lần nữa (vì nó từng cho 60 điểm, khá ổn).
Thời gian: 40 giây.
Điểm: 60 điểm.

Bây giờ, giả sử vào giờ cao điểm (buổi trưa), khu rau củ (Đường A) trở nên rất đông, làm thời gian tăng lên. Dữ liệu mới:

Đường A: 60 giây (đông khách) → Điểm: 100 – 60 = 40 điểm.
Đường B: 50 giây (vẫn ít người) → Điểm: 100 – 50 = 50 điểm.
Đường C: 40 giây (trung bình) → Điểm: 100 – 40 = 60 điểm.

Robot tiếp tục thử:

Lần thử 6:

Robot chọn Đường A (vì trước đó nó tốt nhất).
Thời gian: 60 giây (do đông khách).
Điểm: 100 – 60 = 40 điểm.

Lần thử 7:

Robot chọn Đường C.
Thời gian: 40 giây.
Điểm: 60 điểm.

Lần thử 8:

Robot chọn Đường B.
Thời gian: 50 giây.
Điểm: 50 điểm.

Kết quả sau 8 lần thử

Robot nhận ra: Vào giờ cao điểm, Đường C là lựa chọn tốt nhất (60 điểm, 40 giây).
Robot sẽ ưu tiên Đường C vào giờ trưa, nhưng vẫn thử các đường khác để cập nhật nếu tình hình thay đổi (ví dụ: khu đồ khô bỗng dưng đông vào giờ khác).
Ta đã có 1 hệ thống biết nên sử dụng đường nào theo tham số thời gian, thông minh hơn là chỉ luôn sử dụng 1 bộ quy tắc

Áp dụng vào ví dụ thang máy

Giờ quay lại ví dụ thang máy trong tòa nhà. Giả sử có 3 thang máy và ta phải quyết định thang nào đi đến tầng được gọi (ví dụ: tầng 5).

Hành động: Gửi thang máy A, B, hoặc C đến tầng 5.
Phản hồi: Đo thời gian chờ của khách (thang nào đến nhanh thì được “thưởng” điểm cao).
Học hỏi: Máy tính thử gửi từng thang, đo thời gian chờ, và ghi nhớ thang nào nhanh nhất.
Qua nhiều lần thử, máy tính sẽ biết: “Nếu khách gọi ở tầng 5, gửi thang B vì nó gần nhất, chờ chỉ 10 giây, tốt hơn thang A (20 giây) hay thang C (15 giây).”

Học sâu (Deep Learning)

Thuật ngữ “học sâu” chỉ các thuật toán học máy sử dụng nhiều tầng tính toán, hay còn gọi là các tầng.

Khi một hệ thống học sâu gắn tên cho một khuôn mặt trong ảnh, nó không biết khuôn mặt là gì, con người là gì, hay thậm chí con người có tồn tại hay không. Máy tính chỉ đo lường các điểm ảnh và, dựa trên các mẫu học được từ dữ liệu huấn luyện, đưa ra nhãn phù hợp nhất.

Dần dần, qua hàng ngàn lần thử, mạng học được cách tạo ra kết quả chính xác. Nếu làm tốt, mạng sẽ đưa ra câu trả lời đúng cho hầu hết dữ liệu huấn luyện, sẵn sàng để trở thành một trợ thủ đắc lực – như nhận diện hình ảnh trên mạng xã hội hay dự đoán giá cổ phiếu.

Ví dụ

Dạy máy đoán táo hay cam
Giả sử bạn muốn máy phân biệt táo và cam dựa trên hai đặc điểm:

Kích thước: Táo thì nhỏ hơn, còn cam thì có kích thước lớn hơn. Đặt nhỏ thì là 1, lớn thì là 2
Màu sắc: Táo thì có sắc đỏ, cam thì có màu cam. Đặt đỏ là 1, cam là 2.

Vậy giả sử nếu ai đó bảo ta rằng họ có 1 quả, và kích thước đâu đó là 1.2, và màu sắc thì khá là đỏ (khoảng 1.2, và không có nhiều ánh cam), vậy ta có thể đoán, có vẻ nó là quả táo

Tập dữ liệu giả (4 ví dụ bạn đưa cho máy):

Ví dụ 1: Kích thước 1, màu 1 → Táo.
Ví dụ 2: Kích thước 2, màu 2 → Cam.
Ví dụ 3: Kích thước 1, màu 1 → Táo.
Ví dụ 4: Kích thước 2, màu 2 → Cam.

Lúc này, ta có thể cho máy khởi tạo 1 phương trình đơn giản như:

Kết quả = (Kích thước × số A) + (Màu sắc × số B) – Số A và Số B là các tham số

Bước 1: Thử với ví dụ 1 (Táo: kích thước 1, màu 1)

Công thức: (1 × 0.5) + (1 × 0.3) = 0.8
Máy đoán: “Gần 1, chắc là táo!” (Đúng, nhưng chưa chắc chắn lắm).

Bước 2: Kiểm tra lỗi

Kết quả đúng phải là 1 (Táo), nhưng máy cho 0.8. Sai lệch là 0.2.
Máy nghĩ: “Mình đoán gần đúng, nhưng cần sửa công thức một chút.”

Bước 3: Điều chỉnh công thức

Máy tăng số A và B lên một chút, ví dụ: A = 0.6, B = 0.4.
Thử lại ví dụ 1: (1 × 0.6) + (1 × 0.4) = 1.0 (Đúng là táo!).

Bước 4: Thử với ví dụ 2 (Cam: kích thước 2, màu 2)

Công thức mới: (2 × 0.6) + (2 × 0.4) = 1.2 + 0.8 = 2.0
Máy đoán: “Gần 2, chắc là cam!” (Đúng).

Bước 5: Lặp lại với các ví dụ khác

Máy tiếp tục thử với ví dụ 3, 4, mỗi lần đoán sai thì điều chỉnh số A và B một chút. Qua vài chục lần, máy tìm được số A và B hoàn hảo (ví dụ: A = 0.7, B = 0.5) để đoán đúng hầu hết các trường hợp.

Kết quả sau khi học
Sau khi “học” cả 4 ví dụ, máy có công thức tốt:

Táo (kích thước 1, màu 1): (1 × 0.7) + (1 × 0.5) = 1.2 → Đoán “Táo”.
Cam (kích thước 2, màu 2): (2 × 0.7) + (2 × 0.5) = 1.4 + 1.0 = 2.4 → Đoán “Cam”.

Bây giờ, nếu bạn đưa một quả mới (kích thước 1.5, màu 1.5), máy tính:
(1.5 × 0.7) + (1.5 × 0.5) = 1.05 + 0.75 = 1.8 → Đoán “Cam” (vì gần 2 hơn).

Học sâu trong thực tế khác gì với ví dụ này?

Trong học sâu, máy không chỉ dùng 2 đặc điểm (kích thước, màu) mà có thể dùng hàng ngàn đặc điểm (như mọi chi tiết trên một bức ảnh). Công thức cũng phức tạp hơn, với nhiều tầng (layers), mỗi tầng có nhiều “hộp tính toán” (nơ-ron). Nhưng ý tưởng vẫn giống:

Đưa thông tin vào.
Máy đoán, kiểm tra lỗi, sửa công thức (trọng số).
Lặp lại nhiều lần cho đến khi đoán đúng.

Reference:

Deep Learning (Andrew Glassner)
Deep Learning from Scratch (Seth Weidman)

Setting Up n8n SSO with Self-Hosted Keycloak:

Step 1: Deploy Keycloak with Docker and PostgreSQL

1.1 Set Up PostgreSQL

Create a PostgreSQL instance for Keycloak’s data persistence.

mkdir -p ~/keycloak/postgres

Create a docker-compose.yml file for Keycloak and PostgreSQL:

version: '3.8'
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: secure_password
    volumes:
      - ./postgres:/var/lib/postgresql/data
    restart: unless-stopped
  keycloak:
    image: quay.io/keycloak/keycloak:26.0
    command: start
    environment:
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: secure_password
      KC_HOSTNAME: auth.example.com
      KC_PROXY: edge
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: admin_secure_password
    ports:
      - "8080:8080"
    depends_on:
      - postgres
    restart: unless-stopped

Save this as keycloak/docker-compose.yml. Replace secure_password and admin_secure_password with strong, unique values, and update auth.example.com to your Keycloak subdomain.

1.2 Configure Nginx for SSL

Set up Nginx as a reverse proxy to secure Keycloak with HTTPS.

Install Nginx:

sudo apt update
sudo apt install nginx

Create an Nginx configuration file:

sudo nano /etc/nginx/sites-available/keycloak

Add the following, replacing auth.example.com with your subdomain:

server {
    listen 80;
    server_name auth.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name auth.example.com;

    ssl_certificate /etc/letsencrypt/live/auth.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable the configuration:

sudo ln -s /etc/nginx/sites-available/keycloak /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Obtain an SSL certificate using Certbot:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d auth.example.com

1.3 Start Keycloak

Launch the Keycloak stack:

cd ~/keycloak
docker-compose up -d

Access the Keycloak admin console at https://auth.example.com/admin, logging in with admin and admin_secure_password. Change the admin password immediately for security.

Step 2: Configure Keycloak as a SAML Identity Provider

Keycloak will act as the Identity Provider (IdP) for n8n. We’ll configure a SAML client, and set up mappers for user attributes.

Get required information from N8N

Navigate to Settings -> SSO
Save the Entity ID and Redirect URL

Create a SAML Client for n8n

Navigate to Clients > Create Client.
Set:
- Client Type: SAML
- Client ID: (n8n’s Entity ID from previous step, matching its base URL)
- Name: n8n (Your choice)
Configure:
- Valid Redirect URIs: https://n8n.example.com/saml/acs (Redirect URI from previous step)
Settings: (Image below)
- Name ID format: Email
- Force name ID format: ON
- Force POST binding: ON
- Include AuthnStatement: ON
- Sign Document: ON
- Sign Asseration: ON
- Client Signature Required: Off
Save the client.

Configure Mappers

Mappers define how user attributes are sent to n8n.

In the n8n client, go to Clients Scope > (The entity id, ex: https://yourdomain.com/rest/sso/saml/metadata-dedicated)
Add mapper -> By configuration -> User property

2. Create the mapper like image, each one config look like this

Export SAML Metadata

Go to Realm Settings > SAML 2.0 Identity Provider Metadata.
Download the XML file or copy the metadata URL (e.g., https://auth.example.com/realms/n8n-realm/protocol/saml/descriptor).

Setup the N8N use SAML metadata

Edit metadata

Locate <md:IDPSSODescriptor WantAuthnRequestsSigned=”true” in the XML, and change true to false

Final gonna look like <md:IDPSSODescriptor WantAuthnRequestsSigned=”false”

Test Setting

Open an incognito browser window and navigate to https://n8n.example.com.
You should be redirected to Keycloak’s login page.
Log in with a Keycloak user (create one in Users > Add User if needed, ensuring the email matches an n8n user).
Upon successful authentication, you should be redirected to n8n’s dashboard.

Tìm hiểu lí do cần database, datalake, data warehouse?

Mở đầu

Trong thời đại số ngày nay, dữ liệu hiện hữu ở khắp mọi nơi và đóng vai trò cực kỳ quan trọng trong cuộc sống cũng như công việc của chúng ta. Từ việc chúng ta lướt Facebook, Tiktok hàng ngày, đặt vé xem phim online, cho đến cách các công ty lớn vận hành chuỗi cung ứng phức tạp, mọi thứ đều không ngừng tạo ra và tiêu thụ dữ liệu.

Ví dụ:

Facebook biết chúng ta khi lướt trên bảng tin, sẽ dừng lại tại bài viết nào lâu, bài viết nào thu hút sự chú ý, chủ đề nào chúng ta thường xem, bạn bè nào chúng ta thường hay tương tác
Các app đặt vé xem phim có dữ liệu về phim nào nhiều người xem, bộ phim thể loại nào thì thường được giới tính, độ tuổi nào quan tâm, ….

Nhưng bạn có bao giờ dừng lại và tự hỏi, với một khối lượng dữ liệu khổng lồ và đa dạng như vậy – từ những con số khô khan trong bảng tính Excel, các giao dịch ngân hàng, đến hình ảnh, video, bài đăng mạng xã hội, hay những dòng log hệ thống dày đặc – làm thế nào để chúng ta có thể lưu trữ, quản lý và quan trọng nhất là khai thác chúng một cách hiệu quả?

Trong mọi tổ chức, thông thường sẽ xuất hiện hai nhu cầu cốt lõi:

Xử lý các hoạt động diễn ra hàng ngày
Phân tích chiến lược dựa trên dữ liệu đã tích luỹ

OLTP và OLAP

OLTP (Online Transaction Processing) – Xử lý giao dịch trực tuyến

Hãy tưởng tượng bạn đang thực hiện một giao dịch trực tuyến: đặt một chiếc vé máy bay trên website hãng hàng không, chuyển tiền qua ứng dụng ngân hàng, hay đơn giản là mua một món hàng trên sàn thương mại điện tử.

Tất cả những hành động này đòi hỏi hệ thống phải xử lý ngay lập tức, đảm bảo tính chính xác tuyệt đối (tiền phải được chuyển đúng tài khoản, vé phải được xác nhận và không bị bán trùng) và diễn ra nhanh chóng, không làm bạn phải chờ đợi. Đó chính là bản chất của OLTP – Xử lý giao dịch trực tuyến.

OLTP tập trung vào việc xử lý một khối lượng lớn các giao dịch nhỏ, riêng lẻ diễn ra liên tục trong thời gian thực. Các ví dụ đời thường của hệ thống OLTP có ở khắp nơi quanh ta: máy tính tiền ở siêu thị (quét mã sản phẩm, trừ số lượng tồn kho, tính tiền), máy ATM rút tiền, hệ thống đặt phòng khách sạn, hay việc bạn cập nhật thông tin cá nhân trên một trang web

Đặc điểm quan trọng nhất của các hệ thống OLTP là ưu tiên tốc độ xử lý cực nhanh (thường tính bằng mili giây) và tính nhất quán của dữ liệu. Chắc chắn khách hàng sẽ không muốn tiền của mình bị “bốc hơi” hay thông tin đơn hàng bị sai lệch.

Hệ thống OLTP được thiết kế để đảm bảo điều đó. Chúng thường làm việc với dữ liệu hiện tại (trạng thái mới nhất của thông tin) và thực hiện các truy vấn tương đối đơn giản và lặp đi lặp lại, như tìm kiếm thông tin một bản ghi cụ thể (point query), thêm mới, cập nhật hoặc xóa dữ liệu dựa trên hành động của người dùng.

OLAP (Online Analytical Processing) – Xử lý phân tích trực tuyến

Tuy nhiên, từ góc nhìn của một nhà quản lý doanh nghiệp. Thay vì xử lý từng giao dịch nhỏ lẻ, bạn lại có những câu hỏi lớn hơn, mang tính chiến lược:

“Trong quý vừa qua, dòng sản phẩm nào mang lại lợi nhuận cao nhất?”
“Xu hướng mua sắm của nhóm khách hàng ở độ tuổi 25-35 là gì?”
“Chiến dịch marketing giảm giá 10% vừa rồi có thực sự hiệu quả trong việc thu hút khách hàng mới không?”

Để trả lời những câu hỏi này, không thể chỉ nhìn vào một vài giao dịch đơn lẻ. Chúng ta cần phải xem xét một khối lượng dữ liệu lịch sử khổng lồ, tổng hợp thông tin từ nhiều nguồn, và phân tích chúng từ nhiều góc độ khác nhau (ví dụ: theo thời gian, theo khu vực địa lý, theo dòng sản phẩm, theo kênh bán hàng…). Đây chính là lúc OLAP – Xử lý phân tích trực tuyến phát huy vai trò

Các hệ thống OLAP được thiết kế để hỗ trợ việc phân tích dữ liệu phức tạp, giúp khám phá các xu hướng, mẫu hình ẩn giấu và cung cấp những hiểu biết sâu sắc (insights) để hỗ trợ việc ra quyết định kinh doanh (một phần quan trọng của Business Intelligence – BI). Ví dụ về các tác vụ OLAP bao gồm: phân tích doanh thu theo vùng miền qua các năm , dự báo nhu cầu thị trường cho sản phẩm mới, phân khúc khách hàng dựa trên hành vi mua sắm, hay đánh giá hiệu quả hoạt động của các phòng ban.

Khác với OLTP, các truy vấn OLAP thường rất phức tạp, đòi hỏi quét qua hàng triệu, thậm chí hàng tỷ bản ghi để tính toán các chỉ số tổng hợp (như tổng, trung bình, đếm, tỷ lệ phần trăm). Do đó, thời gian phản hồi của các truy vấn OLAP có thể lâu hơn đáng kể, từ vài giây, vài phút đến hàng giờ, tùy thuộc vào độ phức tạp và khối lượng dữ liệu. Chúng làm việc chủ yếu với dữ liệu lịch sử được tích lũy qua thời gian.

Tại sao cần phân biệt OLTP và OLAP? Mâu thuẫn thúc đẩy sự tách biệt

Bạn có thể thắc mắc: tại sao không dùng chung một hệ thống cho cả hai việc? Câu trả lời nằm ở sự mâu thuẫn cơ bản trong nhu cầu và đặc tính của OLTP và OLAP.

Hãy hình dung thế này: Hệ thống OLTP giống như một quầy giao dịch ngân hàng luôn bận rộn, cần xử lý nhanh chóng yêu cầu nạp/rút tiền của từng khách hàng. Trong khi đó, hệ thống OLAP giống như một phòng họp lớn nơi các nhà phân tích đang xem xét sổ sách kế toán của cả năm, thực hiện những phép tính toán phức tạp để lập kế hoạch chiến lược.

Nếu cố gắng thực hiện cả hai việc trong cùng một “căn phòng” (tức là trên cùng một cơ sở dữ liệu), sẽ dẫn dàng xảy ra việc các truy vấn phân tích OLAP nặng nề, đòi hỏi nhiều tài nguyên (CPU, bộ nhớ, đọc/ghi đĩa) sẽ làm chậm hoặc thậm chí “tắc nghẽn” các giao dịch OLTP đang diễn ra.

Thử tưởng tượng giao dịch mua hàng online của bạn bị treo chỉ vì bộ phận phân tích đang chạy một báo cáo doanh thu khổng lồ trên cùng hệ thống. Điều này rõ ràng là không thể chấp nhận được đối với các hoạt động kinh doanh cốt lõi, vốn đòi hỏi sự ổn định và tốc độ

Database, Data Warehouse, Data Lake

Database (Cơ sở dữ liệu) truyền thống

Database truyền thống, đặc biệt là cơ sở dữ liệu quan hệ (Relational Database), đóng vai trò như cuốn sổ cái điện tử, là nền tảng lưu trữ dữ liệu cho hầu hết các ứng dụng mà chúng ta tương tác hàng ngày, từ mạng xã hội, ứng dụng ngân hàng đến các website thương mại điện tử. Chúng được thiết kế và tối ưu chủ yếu cho các tác vụ OLTP – xử lý giao dịch trực tuyến.

Đặc điểm chính của Database truyền thống:

Loại dữ liệu: Chúng chủ yếu làm việc với dữ liệu có cấu trúc (structured data). Đây là loại dữ liệu được tổ chức một cách gọn gàng, ngăn nắp trong các bảng (tables), với các hàng (rows) và cột (columns) được định nghĩa rõ ràng, tương tự như cách bạn tổ chức dữ liệu trong một file Excel. Ví dụ: bảng Users có các cột UserID, UserName, Email, Password; bảng Orders có OrderID, UserID, OrderDate, TotalAmount.
Schema (Lược đồ/Cấu trúc): Database truyền thống sử dụng cơ chế Schema-on-Write. Điều này có nghĩa là bạn phải định nghĩa chi tiết cấu trúc của các bảng (tên cột, kiểu dữ liệu của cột là gì – số, chữ, ngày tháng…) trước khi bạn có thể lưu trữ bất kỳ dữ liệu nào vào đó. Giống như bạn phải kẻ sẵn các cột trong sổ kế toán trước khi ghi chép các khoản thu chi vậy. Lược đồ này thường khá cứng nhắc (rigid) và việc thay đổi nó có thể phức tạp, nhưng chính sự cứng nhắc này lại giúp đảm bảo tính nhất quán và toàn vẹn của dữ liệu.
Mục đích chính: Mục tiêu hàng đầu là phục vụ các hoạt động đọc, ghi, cập nhật, xóa (CRUD – Create, Read, Update, Delete) dữ liệu một cách nhanh chóng và đáng tin cậy, hỗ trợ trực tiếp cho các giao dịch OLTP của ứng dụng. Chúng cần đảm bảo mỗi giao dịch diễn ra thành công hoặc thất bại hoàn toàn (tính nguyên tử – Atomicity) và dữ liệu luôn ở trạng thái hợp lệ.
Người dùng: Người dùng trực tiếp chính của các database này thường là các Kỹ sư Backend (Backend Engineers). Họ là những người xây dựng và bảo trì các ứng dụng, viết code để tương tác (đọc/ghi) với database. Người dùng cuối như chúng ta chỉ tương tác gián tiếp với database thông qua giao diện của ứng dụng web hoặc mobile.
Ví dụ: Cơ sở dữ liệu lưu trữ thông tin tài khoản người dùng và bài viết của một diễn đàn trực tuyến, cơ sở dữ liệu quản lý thông tin sản phẩm, đơn hàng và khách hàng của một cửa hàng online, hay cơ sở dữ liệu chứa thông tin chuyến bay, lịch trình và đặt chỗ của một hãng hàng không.

Data Warehouse (Kho dữ liệu)

Khi một doanh nghiệp phát triển, họ thường có rất nhiều hệ thống hoạt động (OLTP) khác nhau: hệ thống quản lý bán hàng (POS), hệ thống quản lý quan hệ khách hàng (CRM), hệ thống quản lý kho (Inventory), hệ thống quản lý nhân sự (HR)…

Mỗi hệ thống lại có cơ sở dữ liệu riêng, dẫn đến tình trạng dữ liệu bị phân mảnh và cô lập (data silos). Việc tổng hợp dữ liệu từ tất cả các nguồn này để có một cái nhìn toàn cảnh về tình hình kinh doanh trở nên vô cùng khó khăn. Thêm vào đó, như chúng ta đã thảo luận, việc chạy các truy vấn phân tích phức tạp (OLAP) trực tiếp trên các hệ thống OLTP đang hoạt động sẽ gây ảnh hưởng nghiêm trọng đến hiệu năng.

Để giải quyết những thách thức này, khái niệm Data Warehouse (Kho dữ liệu) đã ra đời vào cuối những năm 1980, đầu 1990. Bạn có thể hình dung Data Warehouse như một thư viện trung tâm khổng lồ, được xây dựng riêng biệt với các hệ thống hoạt động hàng ngày. Nó không trực tiếp phục vụ các giao dịch tức thời, mà nhiệm vụ chính là thu thập, tích hợp và lưu trữ dữ liệu từ nhiều nguồn OLTP khác nhau trong toàn doanh nghiệp, sau đó tối ưu hóa dữ liệu đó cho mục đích phân tích (OLAP) và Business Intelligence (BI)

Quá trình “nhập sách” vào thư viện – ETL/ELT:

Làm thế nào để dữ liệu từ các hệ thống nguồn khác nhau có thể được chuyển vào Data Warehouse một cách thống nhất? Đó là nhờ một quy trình quan trọng gọi là ETL (Extract – Transform – Load).

Extract (Trích xuất): Dữ liệu được lấy ra (trích xuất) từ các hệ thống nguồn khác nhau (database OLTP, file log, thậm chí cả dữ liệu từ các dịch vụ bên ngoài như Google Analytics hay hệ thống CRM của đối tác).
Transform (Biến đổi): Đây là bước quan trọng nhất. Dữ liệu thô được trích xuất thường không đồng nhất (ví dụ: ngày tháng có định dạng khác nhau, tên khách hàng viết hoa/thường lẫn lộn, đơn vị tiền tệ khác nhau…). Ở bước này, dữ liệu sẽ được làm sạch (loại bỏ lỗi, dữ liệu trùng lặp), chuẩn hóa (đưa về cùng một định dạng, đơn vị đo lường), tích hợp (kết hợp dữ liệu từ nhiều nguồn, ví dụ: liên kết thông tin khách hàng từ CRM với lịch sử mua hàng từ hệ thống bán lẻ), và biến đổi thành một cấu trúc (schema) phù hợp cho việc phân tích.
Load (Tải): Sau khi đã được “tút tát” sạch đẹp và đúng chuẩn, dữ liệu sẽ được tải vào Data Warehouse

Đôi khi, thứ tự có thể thay đổi một chút thành ELT (Extract – Load – Transform), tức là dữ liệu được tải vào Data Warehouse trước rồi mới thực hiện biến đổi tại đó. Cách tiếp cận này thường phổ biến hơn với các nền tảng dữ liệu hiện đại có khả năng xử lý mạnh mẽ.

Đặc điểm chính của Data Warehouse:

Loại dữ liệu: Chủ yếu lưu trữ dữ liệu có cấu trúc hoặc bán cấu trúc đã được xử lý, làm sạch và tích hợp từ nhiều nguồn khác nhau. Dữ liệu ở đây không còn ở dạng thô như lúc ban đầu.
Schema (Lược đồ/Cấu trúc): Vẫn sử dụng Schema-on-Write hoặc schema được định nghĩa trước, tương tự database truyền thống. Tuy nhiên, schema trong Data Warehouse thường được thiết kế theo mô hình hướng chủ đề (subject-oriented), tập trung vào các lĩnh vực kinh doanh cốt lõi như Bán hàng (Sales), Tiếp thị (Marketing), Tài chính (Finance), Nhân sự (HR)… thay vì theo cấu trúc của từng ứng dụng nguồn. Các mô hình phổ biến là Star Schema và Snowflake Schema, giúp tối ưu cho các truy vấn phân tích.
Mục đích chính: Phục vụ các hoạt động phân tích dữ liệu lịch sử, tạo báo cáo quản trị (BI reports), khám phá insight kinh doanh và hỗ trợ ra quyết định chiến lược (OLAP). Nó giúp trả lời các câu hỏi “Tại sao?” và “Điều gì sẽ xảy ra?”.
Người dùng: Người dùng chính là các Chuyên viên phân tích nghiệp vụ/kinh doanh (Business Analysts) , các nhà quản lý, lãnh đạo doanh nghiệp – những người cần các báo cáo tổng hợp, dashboard trực quan và những phân tích sâu sắc về tình hình hoạt động của công ty.
Tính chất dữ liệu:
- Tích hợp (Integrated): Dữ liệu từ nhiều nguồn được hợp nhất và chuẩn hóa, tạo ra một bức tranh toàn cảnh.
- Bất biến (Non-volatile): Dữ liệu trong Data Warehouse một khi đã được ghi vào thì rất hiếm khi bị cập nhật hay xóa đi. Thay vào đó, các dữ liệu mới (ví dụ: doanh số của ngày hôm qua) sẽ được nạp thêm vào. Điều này giúp lưu giữ lịch sử thay đổi của dữ liệu theo thời gian.
- Gắn nhãn thời gian (Time-variant): Dữ liệu luôn được gắn với một yếu tố thời gian (ngày, tuần, tháng, quý, năm), cho phép các nhà phân tích xem xét và so sánh dữ liệu qua các khoảng thời gian khác nhau, từ đó nhận diện xu hướng và mẫu hình phát triển.
- Thường là Read-only: Các nhà phân tích chủ yếu thực hiện các truy vấn đọc dữ liệu chứ không sửa đổi dữ liệu gốc trong kho.

Việc xây dựng Data Warehouse được xem là nỗ lực quan trọng đầu tiên của các doanh nghiệp nhằm phá vỡ các “ốc đảo dữ liệu” (data silos) và tạo ra một “nguồn sự thật duy nhất” (single source of truth) cho việc báo cáo và phân tích. Trước khi có Data Warehouse, việc tạo ra một báo cáo tổng hợp đáng tin cậy, ví dụ như kết hợp dữ liệu bán hàng từ hệ thống POS với dữ liệu chi phí marketing từ phòng Marketing và dữ liệu tồn kho từ bộ phận Logistics, là một công việc cực kỳ thủ công, tốn thời gian và dễ sai sót. Quy trình ETL tự động hóa việc tích hợp và làm sạch này, cung cấp cho các nhà phân tích một bộ dữ liệu tập trung, nhất quán và đáng tin cậy để họ có thể đặt ra những câu hỏi phức tạp hơn về hoạt động kinh doanh.

Data Lake (Hồ dữ liệu)

Data Warehouse đã giải quyết rất tốt bài toán tích hợp dữ liệu cho mục đích BI và báo cáo. Tuy nhiên, cùng với sự bùng nổ của Big Data và sự trỗi dậy của Khoa học dữ liệu (Data Science) và Học máy (Machine Learning – ML), Data Warehouse bắt đầu bộc lộ những hạn chế:

Kém linh hoạt: Cấu trúc dữ liệu (schema) phải được định nghĩa trước (Schema-on-Write) khiến việc thêm nguồn dữ liệu mới hoặc thay đổi cấu trúc trở nên tốn thời gian và công sức.
Khó xử lý dữ liệu phi cấu trúc: Data Warehouse được thiết kế chủ yếu cho dữ liệu có cấu trúc hoặc bán cấu trúc. Việc lưu trữ và phân tích các loại dữ liệu phi cấu trúc như văn bản (email, bài đăng mạng xã hội, đánh giá sản phẩm), hình ảnh, video, âm thanh, dữ liệu cảm biến (IoT)… là rất khó khăn hoặc không hiệu quả.
Chi phí lưu trữ cao: Việc lưu trữ một khối lượng dữ liệu khổng lồ, đặc biệt là dữ liệu lịch sử trong nhiều năm, trên các hệ thống Data Warehouse truyền thống có thể rất tốn kém.
Mất mát thông tin tiềm năng: Quá trình Transform trong ETL có thể làm mất đi một số chi tiết hoặc sắc thái trong dữ liệu gốc, mà những chi tiết này lại có thể hữu ích cho các mô hình Machine Learning hoặc các phân tích khám phá sâu hơn.

Để khắc phục những hạn chế này và đáp ứng nhu cầu mới của thời đại Big Data, khái niệm Data Lake (Hồ dữ liệu) đã xuất hiện.

Tương tự, Data Lake là một kho lưu trữ tập trung, có khả năng chứa mọi loại dữ liệu – từ dữ liệu có cấu trúc trong các bảng, dữ liệu bán cấu trúc như file JSON, XML, đến dữ liệu phi cấu trúc như text, ảnh, video – ở định dạng gốc (raw format) của chúng. Nó được thiết kế để xử lý khối lượng dữ liệu cực lớn (terabytes đến petabytes và hơn thế nữa) với chi phí lưu trữ thấp (thường tận dụng các dịch vụ lưu trữ đối tượng trên đám mây như Amazon S3, Google Cloud Storage).

Đặc điểm chính của Data Lake:

Loại dữ liệu: Chấp nhận tất cả các loại dữ liệu: structured, semi-structured, và unstructured. Đây là điểm khác biệt lớn nhất so với Database và Data Warehouse.
Schema (Lược đồ/Cấu trúc): Sử dụng cơ chế Schema-on-Read. Nghĩa là dữ liệu được đổ vào hồ mà không cần định nghĩa cấu trúc trước. Cấu trúc (schema) chỉ được áp dụng hoặc suy ra khi dữ liệu được đọc ra để phục vụ một mục đích phân tích cụ thể. Điều này mang lại sự linh hoạt tối đa, cho phép lưu trữ dữ liệu mới một cách nhanh chóng mà không cần lo lắng về việc phải thiết kế schema trước.
Mục đích chính:
- Lưu trữ tập trung mọi loại dữ liệu của tổ chức với chi phí thấp và khả năng mở rộng cao.
- Cung cấp “nguyên liệu thô” cho các hoạt động Khoa học dữ liệu (Data Science) và Học máy (Machine Learning), đặc biệt là huấn luyện các mô hình phức tạp đòi hỏi dữ liệu gốc, chưa qua xử lý nhiều.
- Phục vụ các tác vụ phân tích khám phá (exploratory analysis), nơi các nhà khoa học dữ liệu muốn tự do tìm tòi, khám phá dữ liệu mà không bị giới hạn bởi một cấu trúc định sẵn.
- Xử lý Big Data và các luồng dữ liệu thời gian thực (streaming data).
Người dùng: Người dùng chính của Data Lake là các Nhà khoa học dữ liệu (Data Scientists) và Kỹ sư dữ liệu (Data Engineers). Họ là những người cần truy cập vào dữ liệu gốc, đa dạng và có các công cụ để xử lý, phân tích dữ liệu này (ví dụ: Python với thư viện Pandas, Scikit-learn; R; Apache Spark…). Các Business Analysts cũng có thể sử dụng dữ liệu từ Data Lake, nhưng thường là sau khi dữ liệu đã được xử lý và đưa vào một lớp có cấu trúc hơn (ví dụ: thông qua Data Lakehouse hoặc các công cụ truy vấn SQL-on-Lake).
Lợi ích:
- Linh hoạt (Flexibility): Có thể lưu trữ mọi loại dữ liệu mà không cần định nghĩa schema trước.
- Chi phí thấp (Low Cost): Tận dụng các giải pháp lưu trữ rẻ tiền, đặc biệt là trên cloud.
- Khả năng mở rộng (Scalability): Dễ dàng mở rộng dung lượng lưu trữ khi dữ liệu tăng lên.
- Hỗ trợ đa dạng công cụ: Có thể sử dụng nhiều loại công cụ và framework phân tích khác nhau trên cùng một dữ liệu.
Thách thức – Nguy cơ “Đầm lầy dữ liệu” (Data Swamp): Chính sự linh hoạt của Data Lake cũng là con dao hai lưỡi. Nếu không có quy trình quản lý, kiểm soát chất lượng và tài liệu hóa (metadata management) tốt, Data Lake rất dễ biến thành một “đầm lầy dữ liệu” – một nơi chứa đầy dữ liệu không rõ nguồn gốc, chất lượng kém, trùng lặp, khó hiểu và không thể sử dụng được. Việc quản trị (governance) trong Data Lake là một thách thức lớn.

Sự ra đời của Data Lake đã thực sự trở thành yếu tố then chốt thúc đẩy sự phát triển mạnh mẽ của Khoa học dữ liệu và Học máy trong môi trường doanh nghiệp. Các mô hình ML phức tạp thường “thích” dữ liệu thô, nơi chúng có thể tự mình khám phá các đặc trưng (features) và mẫu hình mà con người có thể bỏ qua hoặc loại bỏ trong quá trình Transform của ETL vào Data Warehouse. Data Lake cung cấp chính xác nguồn “nguyên liệu” đa dạng, khổng lồ và linh hoạt đó, cho phép các Data Scientist tự do thử nghiệm, xây dựng và huấn luyện các mô hình dự đoán, phân loại, gợi ý… mà không bị giới hạn bởi cấu trúc cứng nhắc của Data Warehouse truyền thống.

So sánh nhanh: Data Lake, Database, Data Warehouse

Đặc điểm	Database (Cơ sở dữ liệu)	Data Warehouse (Kho dữ liệu)	Data Lake (Hồ dữ liệu)
Mục đích chính	Xử lý giao dịch trực tuyến (OLTP), hoạt động hàng ngày	Phân tích kinh doanh (BI), báo cáo quản trị, hỗ trợ ra quyết định (OLAP)	Lưu trữ mọi loại dữ liệu thô, Khoa học dữ liệu, Học máy, phân tích khám phá, Big Data
Loại dữ liệu	Chủ yếu có cấu trúc (Structured)	Có cấu trúc, bán cấu trúc (Đã được xử lý, tích hợp)	Mọi loại: Có cấu trúc, bán cấu trúc, phi cấu trúc (Structured, Semi-structured, Unstructured)
Cấu trúc dữ liệu (Schema)	Schema-on-Write (Định nghĩa trước, cứng nhắc)	Schema-on-Write (Định nghĩa trước, hướng chủ đề)	Schema-on-Read (Linh hoạt, áp dụng khi đọc)
Cách xử lý dữ liệu	Tối ưu cho đọc/ghi/cập nhật/xóa nhanh các bản ghi nhỏ	Tối ưu cho các truy vấn phức tạp, quét lượng lớn dữ liệu lịch sử (ETL/ELT trước khi tải)	Lưu trữ dữ liệu thô, xử lý linh hoạt khi cần (Thường là ELT)
Người dùng chính	Kỹ sư Backend, Ứng dụng	Chuyên viên phân tích (Business Analysts), Nhà quản lý	Nhà khoa học dữ liệu (Data Scientists), Kỹ sư dữ liệu (Data Engineers)
Tốc độ truy vấn	Rất nhanh (cho giao dịch nhỏ)	Nhanh (cho truy vấn phân tích đã tối ưu)	Có thể chậm hơn (tùy công cụ và tối ưu hóa, ưu tiên lưu trữ rẻ)
Tính linh hoạt	Thấp	Trung bình (Khó thay đổi schema)	Cao
Chi phí lưu trữ	Tùy thuộc vào quy mô, có thể cao	Thường cao	Thấp (Thiết kế cho lưu trữ rẻ)
Ví dụ điển hình	Quản lý tài khoản người dùng, đơn hàng online	Phân tích doanh thu theo quý, báo cáo hiệu quả marketing	Huấn luyện mô hình gợi ý sản phẩm, phân tích sentiment từ mạng xã hội, xử lý dữ liệu IoT

Ai/Vai trò nào làm việc với các hệ thống thông tin này?

Để những dữ liệu phức tạp này có thể được xây dựng, vận hành trơn tru và thực sự mang lại giá trị cho tổ chức, không thể thiếu vai trò của những con người với các kỹ năng chuyên môn khác nhau. Sự phát triển của các kiến trúc dữ liệu cũng kéo theo sự chuyên môn hóa ngày càng cao của các vị trí công việc trong lĩnh vực này.

Backend Engineer (Kỹ sư Backend / Lập trình viên Backend): Đây là những người thường làm việc trực tiếp nhất với các Database truyền thống (OLTP). Nhiệm vụ chính của họ là xây dựng và duy trì phần “hậu trường” (backend) của các ứng dụng web hoặc mobile – chính là những ứng dụng tạo ra và tiêu thụ dữ liệu hàng ngày. Họ viết code để ứng dụng có thể đọc, ghi, cập nhật và xóa dữ liệu trong database một cách chính xác, hiệu quả và an toàn, đảm bảo các giao dịch OLTP diễn ra suôn sẻ.
Business Analyst (Chuyên viên phân tích nghiệp vụ / kinh doanh – BA): BA là những người dùng của Data Warehouse. Họ là cầu nối giữa bộ phận kinh doanh và kỹ thuật. Sử dụng dữ liệu đã được làm sạch và tích hợp trong Data Warehouse, BA thực hiện các phân tích, tạo ra các báo cáo trực quan (dashboards), khám phá các xu hướng kinh doanh và cung cấp những insight giá trị giúp ban lãnh đạo đưa ra các quyết định sáng suốt hơn (hoạt động Business Intelligence – BI). Họ cần hiểu rõ về nghiệp vụ kinh doanh và có kỹ năng sử dụng các công cụ BI như Tableau, Power BI cũng như SQL để truy vấn dữ liệu.
Data Scientist (Nhà khoa học dữ liệu): Đây là những “nhà thám hiểm” của thế giới dữ liệu, thường làm việc nhiều nhất với Data Lake (nhưng cũng có thể khai thác cả Data Warehouse). Công việc của họ không chỉ dừng lại ở việc phân tích dữ liệu quá khứ mà còn đi sâu vào việc khám phá dữ liệu thô, áp dụng các thuật toán thống kê và Machine Learning (Học máy) để xây dựng các mô hình dự đoán, phân loại, phát hiện bất thường, hoặc tìm ra những insight hoàn toàn mới lạ mà con người khó nhận biết. Họ cũng có thể tạo ra các tính năng sản phẩm dựa trên dữ liệu, ví dụ như hệ thống gợi ý sản phẩm “người mua X cũng mua Y” trên các trang thương mại điện tử. Họ cần nền tảng vững chắc về toán, thống kê, lập trình (thường là Python hoặc R) và kiến thức về các thuật toán ML.
Data Engineer (Kỹ sư dữ liệu): Có thể nói Data Engineer là những người “thợ xây” chính của toàn bộ hạ tầng dữ liệu. Vai trò của họ cực kỳ quan trọng, đảm bảo “dòng chảy” dữ liệu được thông suốt và hiệu quả. Họ chịu trách nhiệm thiết kế, xây dựng, kiểm thử và bảo trì các “đường ống” ( dữ liệu (data pipelines), bao gồm cả việc triển khai quy trình ETL/ELT để di chuyển và biến đổi dữ liệu từ các hệ thống nguồn (OLTP) vào Data Warehouse hoặc Data Lake. Họ đảm bảo dữ liệu luôn sẵn sàng, đáng tin cậy và có thể truy cập được cho các Data Analyst và Data Scientist sử dụng. Kỹ năng cần thiết bao gồm lập trình, hiểu biết về các hệ thống database, data warehouse, data lake, các công cụ ETL và các nền tảng Big Data.
Analytics Engineer (Kỹ sư phân tích): Đây là một vai trò tương đối mới nhưng đang ngày càng trở nên quan trọng, đặc biệt trong bối cảnh của Modern Data Stack (Ngăn xếp dữ liệu hiện đại). Analytics Engineer hoạt động ở lớp trung gian, nối liền khoảng cách giữa Data Engineer và Data Analyst/Scientist. Trong khi Data Engineer tập trung vào việc xây dựng hạ tầng và đưa dữ liệu thô vào Lake/Warehouse, Analytics Engineer lại tập trung vào việc biến đổi (transform) dữ liệu thô đó thành những bộ dữ liệu (data models) sạch sẽ, có cấu trúc tốt, dễ hiểu, đáng tin cậy và được tối ưu hóa cho mục đích phân tích và báo cáo BI. Họ thường là những người rất giỏi SQL, thành thạo các công cụ mô hình hóa dữ liệu như dbt (data build tool), và có hiểu biết tốt về nhu cầu phân tích của nghiệp vụ.

Một số xu hướng mới

Data Lakehouse: Như mình đã nhắc đến ở phần so sánh, Data Lakehouse là một kiến trúc lai đầy hứa hẹn, đang thu hút nhiều sự chú ý. Mục tiêu của nó là kết hợp những ưu điểm tốt nhất của cả Data Warehouse và Data Lake vào một nền tảng duy nhất. Cụ thể, nó cố gắng mang lại sự linh hoạt và chi phí thấp của Data Lake (lưu trữ mọi loại dữ liệu trên bộ nhớ rẻ tiền như object storage) cùng với các tính năng quản lý dữ liệu mạnh mẽ của Data Warehouse như cấu trúc dữ liệu (schema enforcement), đảm bảo tính toàn vẹn giao dịch (ACID transactions), quản trị dữ liệu (data governance) và hiệu năng truy vấn SQL cao. Bằng cách này, Data Lakehouse hướng tới việc đơn giản hóa kiến trúc dữ liệu tổng thể, giảm thiểu việc sao chép dữ liệu giữa Lake và Warehouse, và cho phép nhiều loại workload khác nhau (từ BI, SQL analytics đến Data Science, ML) cùng hoạt động hiệu quả trên một bản sao dữ liệu duy nhất.
DataOps: Lấy cảm hứng từ thành công của DevOps trong lĩnh vực phát triển phần mềm, DataOps ra đời với mục tiêu áp dụng các nguyên tắc tương tự vào toàn bộ vòng đời của dữ liệu, từ khâu thu thập, xử lý, đến phân tích và cung cấp insight. DataOps nhấn mạnh vào Tự động hóa (Automation) các quy trình dữ liệu (như kiểm thử, triển khai pipeline), Giám sát (Monitoring) liên tục chất lượng và hiệu năng dữ liệu, và thúc đẩy Hợp tác (Collaboration) chặt chẽ giữa các nhóm liên quan (Data Engineers, Analysts, Scientists, nghiệp vụ). Mục tiêu cuối cùng của DataOps là tăng tốc độ đưa dữ liệu và insight đến người dùng, cải thiện chất lượng và độ tin cậy của dữ liệu, đồng thời giảm thiểu lỗi và các công việc thủ công lặp đi lặp lại.
Reverse ETL: Nếu như ETL/ELT truyền thống tập trung vào việc đưa dữ liệu VÀO Data Warehouse hoặc Data Lake để phân tích, thì Reverse ETL lại làm điều ngược lại. Nó lấy những dữ liệu đã được xử lý, làm giàu, hoặc những insight giá trị (ví dụ: điểm số khách hàng tiềm năng, phân khúc khách hàng, dự đoán churn rate) từ chính Data Warehouse/Lakehouse và đẩy chúng TRỞ LẠI các hệ thống hoạt động hàng ngày mà các bộ phận nghiệp vụ thường xuyên sử dụng, như hệ thống CRM (Quản lý quan hệ khách hàng), công cụ Marketing Automation, nền tảng quảng cáo, hay công cụ hỗ trợ khách hàng. Việc này giúp “kích hoạt” dữ liệu phân tích, biến insight thành hành động cụ thể một cách nhanh chóng và tự động, giúp các nhóm Sales, Marketing, Customer Success… có thể cá nhân hóa tương tác, tối ưu chiến dịch và cải thiện trải nghiệm khách hàng dựa trên dữ liệu cập nhật nhất.
Data Products & Data Mesh: Đây là một xu hướng mang tính chiến lược và tổ chức hơn là chỉ về công nghệ. Nó đề xuất một cách tiếp cận mới trong việc quản lý và chia sẻ dữ liệu trong các tổ chức lớn, đặc biệt là những nơi có nhiều bộ phận nghiệp vụ (domains) khác nhau. Thay vì tập trung tất cả dữ liệu và đội ngũ data vào một nhóm trung tâm (thường dẫn đến tắc nghẽn), kiến trúc Data Mesh đề xuất phân tán quyền sở hữu và trách nhiệm quản lý dữ liệu về cho chính các nhóm nghiệp vụ (domain teams) – những người hiểu rõ nhất về dữ liệu của mình. Mỗi domain team sẽ chịu trách nhiệm biến dữ liệu của họ thành các “Sản phẩm dữ liệu” (Data Products). Một Data Product không chỉ là dữ liệu thô, mà là một đơn vị logic hoàn chỉnh, bao gồm dữ liệu đã được làm sạch, mô hình hóa, có tài liệu rõ ràng, đáng tin cậy, dễ khám phá, dễ truy cập (thông qua các cổng ra – output ports được định nghĩa tốt) và có chủ sở hữu chịu trách nhiệm về chất lượng. Cách tiếp cận này nhằm mục đích tăng cường khả năng mở rộng, tính linh hoạt, chất lượng dữ liệu và giúp dữ liệu thực sự trở thành tài sản được quản lý tốt như các sản phẩm phần mềm khác trong tổ chức.

Để tổng kết lại một cách ngắn gọn nhất, bạn có thể nhớ:

Database (Cơ sở dữ liệu): Lựa chọn hàng đầu cho các hoạt động hàng ngày, cần xử lý giao dịch nhanh chóng, đáng tin cậy với dữ liệu có cấu trúc. Nó là trái tim của các ứng dụng OLTP.
Data Warehouse (Kho dữ liệu): Ngôi nhà lý tưởng cho việc phân tích kinh doanh (BI), tạo báo cáo quản trị, khám phá insight từ dữ liệu lịch sử đã được tích hợp và làm sạch, chủ yếu là dữ liệu có cấu trúc. Nó là trung tâm của các hệ thống OLAP.
Data Lake (Hồ dữ liệu): Giải pháp tối ưu khi bạn cần lưu trữ mọi loại dữ liệu (bao gồm cả phi cấu trúc) ở dạng thô, với chi phí thấp và quy mô lớn, phục vụ cho các nhu cầu phân tích nâng cao, Khoa học dữ liệu và Học máy.

Tối ưu SEO website CSR (React, Angular) bằng kĩ thuật PreCrawl

Gần đây, mình có phải gặp một bài toán khá hay, với nhu cầu là thiết kế một blog với 3 tiêu chí

Quản Lý Nội Dung Động: Các bài viết, tag, category cần được động, có thể quản lý (thêm sửa xoá mới) hoàn toàn trên giao diện để cho những người không rành về công nghệ cũng có thể vận hành được
Miễn phí: Quan trọng nhất, không được mất phí cho bất kì phần nào của hệ thống, đây là yêu cầu quan trọng nhất, vì cái này sẽ phục vụ cho 1 số tổ chức có kinh phí eo hẹp, hoặc cho cá nhân viết blog theo sở thích, … và không mong muốn chi thêm 1 khoản phí cho website (tất nhiên là không tính tới domain)
SEO: Website phải tốt cho SEO

Disclaimer: Đây không phải là một bài toán của blog mình, hiện tại blog của mình đang sử dụng WordPress, và nó tốn chi phí hàng tháng, nhưng cũng đáp ứng đủ các nhu cầu của mình.

Nếu cần Solution tối ưu nhất, hãy đi đến hướng đi cuối

Hướng đi 1: Static Site Generator (SSG)

Hướng tiếp cận đầu tiên của mình là sử dụng 1 opensource sinh ra các trang tĩnh cho blog, sau đó deploy bản được build ra lên một số trang cho host trang tĩnh miễn phí như Firebase Hosting, Github Page, …

Giải pháp này thì đã có rất nhiều open source, bạn có thể tham khảo tại đây, dưới mục Blog: https://github.com/myles/awesome-static-generators#blogs

Nhìn chung luồng này sẽ dạng như sau

Người dùng sẽ viết bài ở dạng Markdown, hoặc có thể là viết ở Notion, …
Sẽ cần 1 cái gì đó trigger thực hiện build khi viết bài xong, có thể là ci/cd tự động khi push markdown ở github, hoặc ở notion có lắng nghe sự kiện
Lúc này hệ thống sẽ build ra bản trang tĩnh, và có thể được deploy lên các trang hosting cho phép deploy trang tĩnh

Ví dụ: Hexo – Viết các file markdown, khi chạy generate sẽ sinh folder build
…

Pros

Miễn phí
SEO tốt
Có thể viết động, người dùng vận hành vào viết bài được nếu mà CI-CD đã làm hết -> Tuy nhiên vẫn chưa ở mức cao nhất là có trang quản lý riêng như mong muốn ban đầu lắm

Cons:

Đa số các giải pháp đều cần build lại ra trang tĩnh mỗi lần sửa đổi, và khi số lượng bài viết tăng lên thì càng tốn thời gian hơn.
Khi cần sửa đổi bài viết, thêm bài viết đều cần build lại, chưa thể vào xem thử tức thì
Chưa có giao diện quản lý trực quan

Hướng đi 2: NextJS

Một hướng đi thứ 2 để tối ưu SEO là sử dụng 1 framework server side rendering, có khá nhiều framework như vậy. Điển hình là NextJS.

Ta có thể sử dụng 1 database miễn phí, query bằng api để hỗ trợ trang web động.

Tuy nhiên NextJS nếu muốn build ra các dạng trang tĩnh, để có thể deploy free trên các trang host tĩnh như Github Page, Firebase Hosting, …. thì bắt buộc sẽ cần render toàn bộ trước.

Cụ thể sẽ cần sử dụng getStaticPaths, và lúc thời điểm build ra bản output, thì sẽ cần query toàn bộ bài viết ở database, và build.

Pros

Miễn phí
SEO tốt
Có thể viết động, chỉnh sửa động bằng giao diện do có thể code call api vào database động

Cons:

Thời gian build cực kì lâu, vì đa số các hosting free static site sẽ xoá toàn bộ file mỗi lần upload lên, và mỗi lần build thì cần build toàn bộ.

Hướng đi 3 – Solution: Pre-Crawl

Ở cách làm này, ta sẽ sử dụng CSR truyền thống để khi người dùng lướt web, sẽ đọc bài viết, dữ liệu được load động từ API. Và việc tạo bài viết, chuyên mục, … được admin vận hành tạo từ trang quản trị, cũng sẽ thực hiện qua API Database, ở đây sử dụng API Supabase

Mấu chốt là ví dụ như nếu sử dụng React, thì SEO sẽ rất kém, vì React đi theo dạng sử dụng đa số là JS và để JS build ra HTML. Nên các bot crawl của Google, Bing, … khi vào trang web nếu không chạy được js sẽ không load ra dữ liệu gì cả

Ví dụ hình ảnh một trang web sử dụng CSR sẽ trông như nào với Bot qua http://botsimulator.com/:

Kết quả nhận được, bot không lấy được dữ liệu gì cả, chỉ có tên trang web, keyword, desc, … đều rỗng

Phương án đề ra là ta sẽ sử dụng một luồng nghiệp vụ khác, riêng biệt, chuyên thực hiện việc đi vào các trang web như người dùng mở browser vào web vậy, sau đó cache lại các dữ liệu html vào 1 trang lưu tĩnh, lúc này khi Bot tới, ta sẽ có 1 tầng proxy kiểm tra xem có phải là Bot không, và redirect Bot sang trang tĩnh html đã được xử lý xong, còn người dùng thì đi luồng thông thường.

Có thể nhìn biểu đồ sau với các công nghệ sử dụng:

Proxy bên trên xử lý redirect: Cloudflare Worker Route + Cloudflare Worker
Lưu trữ HTML: Supabase Storage
Trang tĩnh: lưu trữ tại Cloudflare Page, dev bằng React
Thực hiện crawl trang web: Github Action
Database + API động bài viết: Supabase Database

Kết quả nhận được:

Bot sẽ crawl được các dữ liệu trong bài viết (Trong ảnh ở phần Indexable Page Text)

Pros

Miễn phí
SEO tốt
Có thể viết động, chỉnh sửa động bằng giao diện do có thể code call api vào database động
Build nhanh, do trang build ra là trang csr chỉ chứa code call api cho user <- Xử lý được hướng đi 1,2

Cons:

Sẽ cần flow crawl dữ liệu, cái này thì có thể chạy bằng manual cũng được, mình sử dụng 1 workflow trên Github Action để crawl, Github Action sẽ free 2200 phút / tháng (khoảng chạy được 1 tiếng /ngày, vì vậy sẽ cần triển khai logic dạng kiểm tra có nên crawl lại 1 trang không bằng thời gian cập nhật, … tuỳ vào nghiệp vụ)

Code triển khai + chi tiết setup với techstack bên trên

https://github.com/quochung-cyou/csr-seo-page-crawl

Save Google OAuth2 token in database with Spring Boot

Following this official document from Google: https://developers.google.com/api-client-library/java/google-api-java-client/oauth2

When integrating Google OAuth 2.0 with your Spring Boot application, the official documentation provides a comprehensive guide to leverage the GoogleCredential utility class for seamless and secure authorization. OAuth 2.0 is the industry standard for granting access to protected resources, and Google’s implementation is tailored to support various application types, ensuring flexibility across client environments.

Why OAuth 2.0 Matters

Imagine you’re building a task management application that needs to interact with a user’s Google Tasks data. OAuth 2.0 allows your app to request access only to the necessary data (e.g., “Manage your tasks”) while ensuring that the user maintains control over their privacy. The process generates an access token, which is a digital key tied specifically to your application and the user’s data. This token is scoped, meaning it limits the type and extent of access granted, thereby enhancing security. For instance, even if the token were somehow exposed, it couldn’t be used to access unrelated data like emails or photos.

Built on a Secure Foundation

The Google API Client Library for Java includes robust OAuth 2.0 packages such as:

com.google.api.client.googleapis.auth.oauth2: Core classes for implementing OAuth 2.0 flows.
com.google.api.client.googleapis.extensions.appengine.auth.oauth2: Specialized extensions for applications hosted on Google App Engine.

These packages are built on the Google OAuth 2.0 Client Library for Java, a general-purpose library offering standardized utilities to handle token acquisition, refresh, and expiration seamlessly.

A Real-World Perspective

Consider an example where a SaaS platform integrates with Google Drive to allow users to upload documents directly from their accounts. With OAuth 2.0, users authenticate their Google accounts through a secure flow, and the platform receives an access token to interact with Google Drive APIs. Instead of continuously requesting sensitive credentials, the platform uses this token to upload or retrieve files, keeping user data secure and operations streamlined.

By utilizing the detailed guidelines in Google’s documentation, you can ensure that your Spring Boot application adheres to best practices for secure OAuth 2.0 integration, offering a smooth user experience while protecting sensitive information.

Acquiring the Client Secret File

To begin integrating Google OAuth 2.0 into your application, the first crucial step is setting up a project on the Google API Console. This console serves as the central hub for managing authorization credentials, configuring API access, and ensuring proper billing setup. Whether your application runs on a web server, mobile device, desktop client, or directly in a browser, this setup process is essential.

Setting Up Credentials

Navigate to the Google API Console and create a new project. Once the project is set up, you can enable the desired APIs and generate the OAuth 2.0 client credentials, which include:

Client ID: Uniquely identifies your application during the authorization process.
Client Secret: A sensitive key used to authenticate your application, ensuring secure communication with Google’s servers.
Redirect URIs: Specify where Google will send users after they complete the authorization flow.

For detailed guidance on configuring these elements, refer to the API Console Help.

Setup a Authorization code flow

Use the authorization code flow to allow the end-user to grant your application access to their protected data on Google APIs. The protocol for this flow is specified in Authorization Code Grant.

This flow is implemented using GoogleAuthorizationCodeFlow. The steps are:

End-user logs in to your application. You will need to associate that user with a user ID that is unique for your application.
Call AuthorizationCodeFlow.loadCredential(String)) based on the user ID to check if the end-user’s credentials are already known. If so, we’re done.
If not, call AuthorizationCodeFlow.newAuthorizationUrl() and direct the end-user’s browser to an authorization page to grant your application access to their protected data.
The Google authorization server will then redirect the browser back to the redirect URL specified by your application, along with a code query parameter. Use the code parameter to request an access token using AuthorizationCodeFlow.newTokenRequest(String)).
Use AuthorizationCodeFlow.createAndStoreCredential(TokenResponse, String)) to store and obtain a credential for accessing protected resources.

Code implementation is like this

Understanding the DataStoreFactory in GoogleAuthorizationCodeFlow.Builder

When constructing a GoogleAuthorizationCodeFlow object, one of the essential components is the DataStoreFactory. This factory is responsible for persisting user credentials securely and efficiently. Google provides three types of built-in implementations, each suited for different use cases:

AppEngineDataStoreFactory: persists the credential using the Google App Engine Data Store API.
MemoryDataStoreFactory: “persists” the credential in memory, which is only useful as a short-term storage for the lifetime of the process.
FileDataStoreFactory: persists the credential in a file.

Implementing a Custom Data Store to Persist Tokens in a Database

To persist OAuth2 tokens in a database, we need to create a custom implementation of the DataStoreFactory and DataStore classes provided by Google’s OAuth2 library. Here’s a step-by-step guide:

Step 1: Create a Custom `DataStoreFactory`

The custom factory is responsible for creating instances of your DataStore. Extend AbstractDataStoreFactory to implement this logic.

Java

import com.google.api.client.util.store.AbstractDataStoreFactory;
import com.google.api.client.util.store.DataStore;

import java.io.IOException;
import java.io.Serializable;

public class DatabaseDataStoreFactory extends AbstractDataStoreFactory {

    private TokenDatabaseRepository tokenDatabaseRepository;

    public DatabaseDataStoreFactory(TokenDatabaseRepository tokenDatabaseRepository) {
        this.tokenDatabaseRepository = tokenDatabaseRepository;
    }

    @Override
    protected <V extends Serializable> DataStore<V> createDataStore(String id) throws IOException {
        return new DatabaseDataStore<>(this, id, tokenDatabaseRepository);
    }
}

Step 2: Implement the Custom DataStore

This class handles token persistence logic. Extend AbstractDataStore and implement the required methods like set(), get(), delete(), etc.

Java

import com.google.api.client.util.store.AbstractDataStore;
import com.google.api.client.util.store.DataStore;
import com.google.api.client.util.store.DataStoreFactory;

import java.io.IOException;
import java.io.Serializable;
import java.util.Collection;
import java.util.Set;

public class DatabaseDataStore<V extends Serializable> extends AbstractDataStore<V> {

    private final TokenDatabaseRepository<V> tokenDatabaseRepository;

    protected DatabaseDataStore(DataStoreFactory dataStoreFactory, String id, TokenDatabaseRepository<V> tokenDatabaseRepository) {
        super(dataStoreFactory, id);
        this.tokenDatabaseRepository = tokenDatabaseRepository;
    }

    @Override
    public int size() throws IOException {
        return tokenDatabaseRepository.size();
    }

    @Override
    public boolean isEmpty() throws IOException {
        return tokenDatabaseRepository.isEmpty();
    }

    @Override
    public boolean containsKey(String key) {
        return tokenDatabaseRepository.containsKey(key);
    }

    @Override
    public boolean containsValue(V value) {
        return tokenDatabaseRepository.containsValue(value);
    }

    @Override
    public Set<String> keySet() throws IOException {
        return tokenDatabaseRepository.keySet();
    }

    @Override
    public Collection<V> values() throws IOException {
        return tokenDatabaseRepository.values();
    }

    @Override
    public V get(String key) throws IOException {
        return tokenDatabaseRepository.get(key);
    }

    @Override
    public DataStore<V> set(String key, V value) throws IOException {
        tokenDatabaseRepository.set(key, value);
        return this;
    }

    @Override
    public DataStore<V> clear() {
        tokenDatabaseRepository.clear();
        return this;
    }

    @Override
    public DataStore<V> delete(String key) throws IOException {
        tokenDatabaseRepository.delete(key);
        return this;
    }
}

Step 3: Create the TokenRepository Interface

Leverage Spring Data JPA to handle database interactions.

Java

public interface TokenDatabaseRepository<V> {
    int size();

    boolean isEmpty();

    boolean containsKey(String key);

    boolean containsValue(V value);

    Set<String> keySet();

    Collection<V> values();

    V get(String key);

    TokenDatabaseRepository<V> set(String key, V value);

    TokenDatabaseRepository<V> clear();

    void delete(String key);


}

Java

@Repository
@RequiredArgsConstructor
public class TokenDatabaseRepositoryImpl implements TokenDatabaseRepository<StoredCredential> {

    private final TokenRepositorySql tokenRepositorySql;
    private final GoogleAuthItemMapper googleAuthItemMapper;

    @Override
    public int size() {
        return (int) tokenRepositorySql.count();
    }

    @Override
    public boolean isEmpty() {
        return tokenRepositorySql.count() == 0;
    }

    @Override
    public boolean containsKey(String key) {
        return tokenRepositorySql.existsByKey(key);
    }

    @Override
    public boolean containsValue(StoredCredential value) {
        var googleAuthItem = googleAuthItemMapper.from(value);
        return tokenRepositorySql.existsByAccessTokenAndRefreshToken(googleAuthItem.getAccessToken(), googleAuthItem.getRefreshToken());
    }

    @Override
    public Set<String> keySet() {
        return tokenRepositorySql.findAll().stream()
                .map(GoogleAuthItem::getKey)
                .collect(Collectors.toSet());
    }

    @Override
    public Collection<StoredCredential> values() {
        return tokenRepositorySql.findAll().stream()
                .map(googleAuthItemMapper::to)
                .collect(Collectors.toList());
    }

    @Override
    public StoredCredential get(String key) {
        Optional<GoogleAuthItem> optionalGoogleAuthItem = tokenRepositorySql.findById(key);
        return optionalGoogleAuthItem.map(googleAuthItemMapper::to).orElse(null);
    }

    @Override
    @Transactional
    public TokenDatabaseRepository<StoredCredential> set(String key, StoredCredential value) {
        var googleAuthItem = googleAuthItemMapper.from(value);
        googleAuthItem.setKey(key);
        tokenRepositorySql.save(googleAuthItem);
        return this;
    }

    @Override
    @Transactional
    public TokenDatabaseRepository<StoredCredential> clear() {
        tokenRepositorySql.deleteAll();
        return this;
    }

    @Override
    public void delete(String key) {
        tokenRepositorySql.deleteByKey(key);
    }
}

Java

public interface TokenRepositorySql extends JpaRepository<GoogleAuthItem, String> {

    boolean existsByKey(String key);

    boolean existsByAccessTokenAndRefreshToken(String accessToken, String refreshToken);

    void deleteByKey(String key);

}

Register a custom function in Camunda 7 with Spring Boot

Introduction to Camunda 7

Before Camunda BPM 7.18

In both approaches, you need to register your method via the function mapper. If you want to call a method from a bean using an expression like ${myBean.method()}, the process happens automatically without any additional code. However, if you prefer to use the method in the format ${runner:method()} or ${method()}, here’s how you can do it.

In the ProcessEngineConfigurationImpl class provided by Camunda, you’ll find the ExpressionManager. This class exposes all the necessary methods for you to use.

To register a new function mapper, you need to create a class that implements the FunctionMapper interface. Here’s a sample implementation to get you started.

Now, you can create a process engine plugin to initialize the function mapper when Camunda’s process engine starts configuring.

Now you can use ${jsonPath(a, b) in workflow

After Camunda BPM 7.18

After Camunda 7.18, the addFunctionMapper function was removed. You might need an alternative workaround, and this link might be helpful for you.

https://forum.camunda.io/t/how-do-i-add-functionmappers-to-expressionmanager-in-7-18/40466/2

Camunda 7 | Get history data of form in user task

Introduction to Camunda 7

Camunda 7 is a powerful, open-source platform designed for workflow and process automation. It offers a comprehensive suite of tools for managing business processes, including capabilities for modeling, automating, and optimizing workflows. One of the key features of Camunda is its ability to track and retrieve historical data, such as process variables and form data, from completed process instances. However, retrieving form data from completed instances can be tricky as Camunda 7 does not provide an out-of-the-box API for this purpose.

Retrieving Historical Data

When working with Camunda, it’s often necessary to access historical data from completed process instances. This data can include process variables and form data, which provide insights into the execution and outcomes of the process. Retrieving this data is essential for reporting, auditing, and analysis purposes.

In this solution:

The BPMN model instance is retrieved using the repositoryService.
The task is fetched from the BPMN model using the task definition key.
If the task is found, the form key is retrieved from the task attributes.
The deployment ID is obtained from the process definition query.
The form resource is retrieved using the GetDeploymentResourceCmd.
The form data is read into a map and set into the result DTO as a JSON string.

Accessing Historical Form Data

By default, Camunda 7 does not provide an out-of-the-box API to retrieve form data from completed process instances. To work around this limitation, you can use a custom approach to fetch the form data stored as process variables.

Here’s a workaround to retrieve form data:

FOSSASIA 2024 Hackathon: Housing Connector

The atmosphere at the FOSSASIA Summit 2024 was absolutely electric. Hosted at PTIT, it’s a massive gathering with over 5,000 people from 50 countries, 200+ speakers from giants like Google, Huawei, and Oracle,…. Amid all that, there’s this Web3-focused hackathon, sponsored by Chainlink and Devfolio, challenging devs to build real-world blockchain solutions in just 48 hours.

The idea came from what I see at work. Vietnam’s real estate is growing fast, the market’s supposed to double in size soon, with more young people in their 20s and 30s wanting in. But buying property? It’s expensive, and if you team up with friends or family, contracts get messy with arguments and risks. A lot of folks are shopping online now like 70% or something but trust is low. So, we made Housing Connector: a platform where small investors can pool money for properties, connect with agents, and use blockchain to keep everything clear and safe.

Basically, it works like this: Investors check out listings with details on location, costs, potential returns. They chip in what they can, sign smart contracts through Chainlink so no one’s getting screwed. When the property sells, money gets split automatically, minus a small fee, that’s how the app makes money. Agents get leads and data to sell better, and as more join, it pulls in more investors and properties. It’s a loop that could grow quick. We used React for the front end, Solidity for contracts, and stuff like Ethereum and Web3.js. Nothing fancy, just enough for a basic demo.

We submitted right at the deadline: a POC where you could “buy” a apartment in Hanoi with pooled funds. Out of over 1,000 people and 43 teams, they picked us as winners!

Honestly, it taught me a lot about teamwork under pressure. We’re proud of the prototype, even if it’s rough – built in two days, after all. Maybe we’ll keep working on it, add more features like AI for price predictions. Shoutout to FOSSASIA for the event!!!