: fatal error: libcob.h: No such file or directory
10 | #include <libcob.h>
| ^~~~~~~~~~
compilation terminated.
The error fatal error: libcob.h: No such file or directory means the COBOL compiler (cobc) found your code, but the C compiler (which GnuCOBOL uses under the hood) can’t find the necessary “header files” to finish building the program.
Adding these to Environment Variables like previous step
Variable Name
Variable Value
COB_CFLAGS
-I D:\Msys2\ucrt64\include
COB_LDFLAGS
-L D:\Msys2\ucrt64\lib
-I (Include): Points to the folder containing libcob.h.
-L (Library): Points to the folder containing the actual library files (.lib or .a).
If you got (nanosleep64 could not be located) may indicate: your system is confused between two different versions of the C compiler.
The nanosleep64 error is a classic sign that a program compiled with one Windows runtime (like UCRT) is trying to link with an incompatible version of a library.
You could run this command
where gcc
If the output show more than one directory path, it may appear your computer have 2 installed GCC place
To solve this:
You need to tell Windows that the D: drive tools are the priority.
Search for “Edit the system environment variables” in your Start Menu and open it.
Click Environment Variables.
In the System variables (bottom) list, find the one named Path and click Edit.
Find C:\Msys2\ucrt64\bin in the list. (the path you added in installation step)
Click the “Move Up” button repeatedly until it is at the very top of the list (above the other bin directory in where gcc command).
Click OK on all windows.
Close your current Command Prompt and open a new one for the change to take effect.
I have a love-hate relationship with browser tabs. I need a lot of them to work, but once I pass the 30-tab mark, my browser bar becomes useless.
Google Chrome actually experimented with an auto-grouping feature a while back, but they removed it. I tried finding alternatives on the Chrome Web Store, but they all had the same problem: They were lazy.
Most existing extensions group tabs based on the domain, even they calling LLM to group it. If they see youtube.com, they dump it in a “YouTube” folder. This is useless for me. If I have 5 tabs open for “Lofi Music” and 5 tabs open for “Python Tutorials,” those shouldn’t be in the same group. One is Work, the other is Background Noise.
I realized that to actually organize tabs, the software needs to read the page, not just the URL. So I spent my free time building Group Tab AI.
How it actually works
I didn’t want to over-engineer this, but I needed it to be smart. When you click the button, the extension doesn’t just look at the link. It injects a script to grab the “context” of the page, the H1 title, the meta description, and a snippet of the body text.
It sends that data to an LLM (I set it up to work with either OpenAI or Gemini). Because it reads the content, it can tell that a GitHub page for a “React Library” is different from a GitHub page for “Tracking Issues.”
I’m using Google Gemini 2.0 Flash for this mostly, with the thinkingBudget set to 0. It’s fast enough that by the time I blink, the tabs are sorted.
I spent nights tweaking prompts to make it focus on tasks, not domains with extra context from the website contents along with careful prompt to let them reasoning and choose. For example, if you’re a dev, it might make groups like “Bug Hunting” or “API Docs.” Designers get “Mockups” or “Inspo.” It works for anyone,
students with class notes, marketers with campaigns.
The feature I actually wanted: It learns
This is the part I’m most proud of. I know AI isn’t perfect. It’s going to mess up. It might group a design blog under “Development” instead of “Inspiration.”
Usually, with AI tools, you just have to live with the bad output. But I built a Learning System into this.
If the AI groups something wrong, I manually move the tab to the right group.
The extension records that move.
After I’ve corrected it a few times, I can click a button to “Analyze Behavior.”
The system looks at my corrections and rewrites its own system prompt.
Next time I run it, it knows: “Oh, he likes to keep his ‘Localhost’ tabs separate from his ‘Production’ tabs,” because it updated its own instructions based on my manual fixes.
The Tech Stack
For the frontend devs out there, I built this using Plasmo. It’s basically the Next.js of browser extensions, makes working with React and TypeScript in a chrome-extension environment actually bearable.
Everything is local. Your API keys are stored in your browser, and the learning data (your grouping habits) stays on your machine.
Try it out
It’s open source (GPL-3.0). I built it because I needed it, but if you’re tired of domain-based grouping that doesn’t actually help, give it a shot.
Kaggle’s setup is amazing for quick experiments but not great when you start treating your work like an actual project. You get one main notebook. That’s it.
If you want to use your own .py files, you basically have to zip them up, upload them as a dataset, and then import from that path. It’s clunky and hard to maintain. Change one line of code? You need to re-upload the dataset again.
I saw this frustration all over the web, in Kaggle forums, Stack Overflow threads, even Reddit. Everyone was hacking their way around it, trying things like chained kernels or huge notebooks with thousands of lines of code. Nobody seemed happy with it.
So I went down the rabbit hole. Read a bunch of Medium posts, watched YouTube tutorials, skimmed corporate engineering blogs. I noticed a pattern: real ML pipelines in the wild are automated. They have CI/CD. They deploy cleanly. But for personal Kaggle projects, nobody had built something simple and usable.
That’s when it clicked, I could write a small tool that did the boring part for me. A script that could take my local project, package it up neatly, and push it to Kaggle as a dataset and a runnable notebook automatically.
Building kaggle-auto-deploy
The idea was simple:
Collect all project files.
Upload them as a Kaggle dataset.
Auto-generate a notebook that sets everything up and runs main.py.
Push it, version it, done.
So that’s what I built. A small CLI tool:
python kaggle_deploy.py ./my_project
For example, I used it on a small housing price predictor I’d built.
Behind the scenes, it ties into Git too, so every deployment matches a commit. No more “which version did I upload again?” moments.
git clone https://github.com/yourusername/kaggle-auto-deploy.git
cd kaggle-auto-deploy
Make it Executable (Linux/Mac)
chmod +x kaggle_deployer.py
Optional: Add to PATH (Linux/Mac)
# Add to ~/.bashrc or ~/.zshrc
export PATH="$PATH:/path/to/kaggle_deployer"
Usage
Basic Usage
python kaggle_deployer.py /path/to/your/project
Sample Project
This repository includes a sample project called housing_price_predictor that demonstrates how to structure a multi-file Python project for deployment to Kaggle.
python kaggle_deploy.py ./housing_price_predictor
Project Structure
housing_price_predictor/
├── main.py # Entry point
├── data_loader.py # Data loading and preprocessing
├── model.py # Model training and evaluation
├── utils/
│ └── helpers.py # Utility functions
├── data/
│ └── housing.csv # Sample data
└── requirements.txt # Dependencies
Running the Sample Project
# Run locally
cd housing_price_predictor
python main.py
# Deploy to Kaggle
python kaggle_deployer.py ./housing_price_predictor
Như đã sơ lược qua ở phần trước, HTTP/2 Server Push (gọi tắt là HTTP/2 push) cho phép máy chủ (server) gửi thêm tài nguyên mà client (trình duyệt) chưa yêu cầu. Trước HTTP/2, HTTP chỉ là “hỏi-đáp đơn giản”: Trình duyệt yêu cầu một trang web, server trả về, rồi trình duyệt phải tải trang đó, phân tích, và yêu cầu thêm tài nguyên như CSS, JavaScript, font chữ, hình ảnh.
Ví dụ: Khi bạn mở một trang blog, trình duyệt tải HTML trước, rồi mới “thấy” cần CSS từ việc HTML khai báo rằng css cần thiết. Quá trình này tạo ra ít nhất một vòng lặp (round-trip) thừa, làm chậm thời gian hiển thị ban đầu (initial paint). Hình ảnh thì không sao (trang vẫn load với chỗ trống), nhưng CSS hay JS “critical” (quan trọng cho rendering) sẽ khiến trang “treo” đến khi tải xong.
Với HTTP/2 multiplexing (đa kênh), các yêu cầu song song giúp tốt hơn HTTP/1, nhưng vẫn cần round-trip thứ hai. HTTP/2 push “phá vỡ quy tắc” bằng cách server gửi luôn tài nguyên phụ ngay từ đầu, giảm thời gian tải từ 2 round-trip xuống còn 1.
Hình dung qua ví dụ waterfall diagram (biểu đồ thác nước):
Không push: HTML tải xong → Phân tích → Yêu cầu CSS/JS → Chờ tải → Render.
Có push: Server gửi HTML + CSS/JS cùng lúc → Render ngay!
Inline CSS
Để giảm độ trễ, các lập trình viên thường inline các tài nguyên quan trọng ngay vào HTML, nhờ đó trình duyệt có thể bắt đầu render ngay sau khi phân tích trang gốc, thay vì chờ tải thêm tài nguyên.
Tuy nhiên, inline CSS/JS tiềm ẩn nhiều hạn chế:
Khi cần sửa critical CSS (ví dụ redesign), phải cập nhật từng trang chứ không chỉ 1 file chung.
Thường chỉ chứa các style cần thiết cho lần render đầu; toàn bộ stylesheet được tải sau để giảm độ lớn mã inline.
Cần công cụ phân tích để trích đúng những phần “critical” công việc phức tạp.
Dẫn đến trùng lặp: mỗi trang website đều chứa CSS critical riêng, thay vì dùng file có thể cache giữa các trang.
Sau đó nội dung critical CSS còn được giữ trong stylesheet chính, gây trùng lặp trong mỗi trang, không chỉ giữa các trang.
Để tải CSS không quan trọng, cần dùng JavaScript thay vì thẻ <link>, bởi thẻ link nhúng CSS thông thường sẽ block rendering; thẻ link không hỗ trợ async.
Làm rõ hơn cơ chế HTTP/2 Push
HTTP/2 push phá bỏ quy tắc “1 request = 1 response”. Máy chủ có thể trả về nhiều tài nguyên kèm theo một yêu cầu. Ví dụ:
– Client: “Cho tôi trang này.” – Server: “Được thôi, đây là trang HTML, thêm cả CSS và JS cần thiết để bắt đầu rendering”.
Thể hiện dưới dạng waterfall: các tài nguyên không đến đúng lúc, có khoảng cách nhỏ giữa chúng, nhưng tổng thời gian gần 1 vòng chứ không phải 2 như trước.
Tương tự, chuỗi flow request–response có thể thấy như hình dưới, có thể thấy rõ sự tiết kiệm thời gian khi gửi các tài nguyên quan trọng cùng với trang ban đầu.
HTTP/2 Push không thay thế được WebSockets hay SSE
Điểm then chốt: push chỉ xảy ra khi có request ban đầu từ client, server không thể tự ý push bất kỳ lúc nào. WebSockets hay SSE cho phép two-way communication, nhưng HTTP/2 không thật sự hai chiều, mọi thứ đều do client khởi đầu. Sau khi stream request đầu kết thúc, server không thể tiếp tục push trừ khi client gửi request mới. Vì vậy, HTTP/2 push không thay thế WebSocket hay SSE theo chuẩn hiện tại
Cơ chế hoạt động của HTTP/2 Push trong trình duyệt
Trình duyệt xử lý HTTP/2 push lại theo một cách khác. Tài nguyên không được đẩy thẳng đến trang web, mà được đẩy vào một khu vực cache đặc biệt. Trang web vẫn được xử lý bình thường. Khi cần tài nguyên, trình duyệt kiểm tra cache, nếu có sẵn thì tải từ cache thay vì gửi yêu cầu tới server.
Cơ chế chi tiết phụ thuộc vào từng trình duyệt và không được nêu rõ trong spec HTTP/2, nhưng hầu hết hiện nay triển khai một HTTP/2 push cache riêng biệt, khác với HTTP cache thông thường
Cách hoạt động của push cache
Các tài nguyên được đẩy sẽ nằm trong một vùng nhớ riêng (HTTP/2 push cache) chờ trình duyệt yêu cầu. Khi được truy cập, tài nguyên sẽ được đưa vào trang và nếu có header phù hợp sẽ được đồng thời lưu vào HTTP cache để sử dụng sau này.
Một điểm đặc biệt: các trình duyệt dựa trên Chromium (Chrome, Opera) không cache tài nguyên nếu certificate không đáng tin (như tự ký self-signed, hiển thị ổ khoá đỏ), dù người dùng có bỏ qua lỗi. Để HTTP/2 Push hoạt động, bạn cần certificate hợp lệ (ổ khoá xanh)
Quá trình kiểm tra cache của trình duyệt theo thứ tự như sau: image cache → preload cache → service worker → HTTP cache → HTTP/2 push cache. Nếu tài nguyên đã có sẵn ở cache HTTP chính (mặc dù phiên bản mới đã bị push), trình duyệt vẫn ưu tiên dùng bản cũ theo cache-control (Jake Archibald) Service worker còn được kiểm sau preload cache
Image cache (cache hình ảnh):
Là cache tạm, nằm trong bộ nhớ (in-memory) chỉ phục vụ cho trang hiện tại.
Nó giúp trình duyệt không phải tải lại cùng một ảnh nếu trang tham chiếu tới ảnh đó nhiều lần.
Khi người dùng rời khỏi trang, cache này bị hủy.
Preload cache:
Cũng là cache tạm, trong bộ nhớ và chỉ gắn với một trang.
Dùng để giữ các tài nguyên được preload (sẽ nói kỹ hơn ở chương 6).
Lưu ý: không nên preload tài nguyên cho trang khác, vì preload cache không dùng chung giữa các trang.
Service Worker cache:
Service Worker là một loại ứng dụng nền, chạy độc lập với web page, đóng vai trò trung gian giữa web page và server.
Nó cho phép web hoạt động giống native app hơn, ví dụ vẫn có thể hoạt động khi mất mạng.
Service Worker có hệ thống cache riêng, gắn với domain.
HTTP cache (cache truyền thống):
Đây là cache chính mà lập trình viên quen thuộc nhất.
Nó được lưu trên đĩa (persistent), chia sẻ giữa nhiều trang, có dung lượng giới hạn và được dùng cho tất cả domain.
HTTP/2 push cache:
Đây là cache tạm, nằm trong bộ nhớ, gắn liền với một kết nối (connection).
Nếu server push styles.css, file này sẽ được đưa vào HTTP/2 push cache. Sau đó, khi trình duyệt thấy cần styles.css, nó không hề “biết” hay quan tâm rằng server đã push sẵn file này. Trình duyệt vẫn kiểm tra toàn bộ cache theo thứ tự:
Image cache
Preload cache
Service Worker cache
HTTP cache
HTTP/2 push cache
Nếu trong HTTP cache chính đã có một bản styles.css hợp lệ, thì trình duyệt sẽ lấy từ đó kể cả khi trong push cache đang có bản mới hơn.
Bạn có thể dùng công cụ chrome://net-export (nói trong mục 4.3.1) để xem tổng hợp các tài nguyên đã được push nhưng chưa được sử dụng (unclaimed push resources) trong tất cả các trang đang mở
Nếu một kết nối bị đóng, push cache cũng mất theo, khác với HTTP cache. Một cách hiểu ngắn gọn: push cache chỉ tồn tại gắn với kết nối. Khi kết nối không tái sử dụng, tài nguyên push có thể bị lãng phí. Một lần tài nguyên được sử dụng (“claimed”), nó sẽ bị loại khỏi push cache. Nhưng nếu có cache-control phù hợp, vẫn có thể lưu trong HTTP cache. Thậm chí tài nguyên không thể cache theo HTTP (no-cache, no-store) vẫn có thể được push và đọc từ push cache, bởi đây không thực sự là “cache” truyền thống mà là vùng đệm tạm thời
HTTP/2 Push Cache và những vấn đề phát sinh
Push cache gắn liền với connection
HTTP/2 push cache gắn trực tiếp với một kết nối (connection). Điều này dẫn đến:
Nếu kết nối không được dùng → tài nguyên push cũng không được dùng.
Nếu kết nối bị mất → push cache và tất cả tài nguyên chưa dùng cũng mất → việc push bị lãng phí.
Nếu trình duyệt mở thêm một kết nối khác → tài nguyên push có thể sẽ không được dùng.
HTTP/2 thiết kế để chỉ có một connection duy nhất, nên thoạt nhìn có vẻ không có vấn đề. Nhưng thực tế các trình duyệt triển khai khác nhau:
Chrome, Firefox: chia sẻ connection giữa các tab.
Edge: mỗi tab dùng connection riêng.
Safari: có thể mở nhiều connection ngay trong cùng một tab.
Ngoài ra, các request không kèm thông tin xác thực (noncredentialed) thường được gửi trên một connection riêng. Do đó:
Không thể push font cross-origin (từ domain khác, kể cả domain shard) vì chúng phải đi qua noncredentialed request.
Do Push cache hoạt động ở mức connection, chứ không phải mức page. Vì vậy, tuy về lý thuyết bạn có thể push tài nguyên cho trang sẽ load sau, nhưng trên thực tế điều này gần như vô ích, vì cache ngắn hạn và có thể mất khi kết nối rớt.
Push cache khác với HTTP cache
Khi một tài nguyên được lấy ra khỏi push cache, nó sẽ bị xóa khỏi đó và không thể dùng lại từ push cache lần nữa. Nhưng nếu tài nguyên có cache-control hợp lệ, nó sẽ được lưu vào HTTP cache chính để dùng sau.
Push cache có thể chứa cả tài nguyên không cache được (ví dụ header no-cache hoặc no-store). Đây là điểm khác với HTTP cache truyền thống.
Chính vì vậy, push cache không thực sự là cache theo đúng nghĩa, mà giống như một “kho tạm chứa request”
RST_STREAM – Cách từ chối tài nguyên bị push
Trình duyệt có thể từ chối một tài nguyên đang bị push bằng cách gửi một RST_STREAM frame với mã CANCEL hoặc REFUSED_STREAM. Điều này xảy ra khi:
Trình duyệt đã có sẵn tài nguyên trong cache.
Người dùng rời khỏi trang khi nó vẫn đang load → không cần tải thêm tài nguyên nữa.
Tuy nhiên, RST_STREAM có hạn chế:
Việc gửi tín hiệu RST_STREAM mất thời gian → trong lúc đó server vẫn tiếp tục gửi data (HEADERS, DATA frames). Có thể cả file đã được gửi xong trước khi server kịp ngừng lại.
Đây chỉ là tín hiệu điều khiển, không mạnh bằng việc cắt hẳn connection (HTTP/2 không cho phép ngắt connection vì sẽ ảnh hưởng tới tất cả stream khác).
Vì vậy, RST_STREAM không phải giải pháp hiệu quả để ngăn chặn việc push sai tài nguyên.
Ví dụ:
Nếu push một ảnh rất lớn nhưng trang đã được cập nhật không dùng ảnh đó nữa → trình duyệt vẫn tải hết ảnh về nhưng không dùng, gây lãng phí băng thông.
Thậm chí bạn còn không biết mình đang push nhầm, vì một số công cụ (DevTools) có thể không hiển thị tài nguyên bị push mà không dùng.
Client có thể tắt push bằng cách đặt SETTINGS_ENABLE_PUSH = 0 trong khung SETTINGS. Khi đó, server không được phép gửi PUSH_PROMISE nữa.
Request được push phải là cacheable methods (thường là GET, HEAD, hoặc một số POST đặc biệt).
Request được push phải là safe methods (thường là GET hoặc HEAD).
Request được push không được có request body (nhưng response thường có body).
Request được push chỉ được gửi đến những domain mà server có thẩm quyền (authoritative).
Chỉ server mới có quyền push, client không được push.
Resource chỉ có thể được push như phản hồi cho một request hiện tại. Server không thể tự phát khởi một push nếu không có request nào đang diễn ra.
Thực tế, vì các quy tắc trên, chỉ có GET request là thường được push.
Giới hạn về authority nghĩa là bạn chỉ được phép push tài nguyên mà server trực tiếp hoặc gián tiếp phục vụ. Ví dụ, nếu trang của bạn dùng Bootstrap từ getbootstrap.com hoặc jQuery từ jquery.com, thì server của bạn không thể push trực tiếp. Bạn có thể proxy các request đó qua server của mình, nhưng khi đó bạn phải sửa tất cả các tham chiếu để trỏ về server của bạn. Ở tình huống đó, tốt hơn hết là host luôn file đó tại chỗ thay vì tạo thêm phức tạp với proxy.
HTTP/2 Push được thiết kế để tối ưu hiệu năng, nhưng nếu lạm dụng, nó có thể làm chậm hiệu năng vì lãng phí băng thông để push những tài nguyên mà client không dùng, thay vì ưu tiên cho những tài nguyên cần thiết.
Lý tưởng nhất, chỉ nên push tài nguyên quan trọng (critical assets) mà trang chắc chắn cần.
Không nên push:
Tài nguyên không được sử dụng.
Tài nguyên mà client không thể dùng (ví dụ: image format không hỗ trợ).
Tài nguyên chỉ dùng trong một số điều kiện (ví dụ: hình ảnh cho màn hình lớn).
Nhóm Chrome đã viết một tài liệu chi tiết về “nên push cái gì” (Chrome doc on HTTP/2 Push), trong đó họ khuyến nghị:
“Chỉ push mức tối thiểu cần thiết để lấp đầy thời gian mạng rảnh, và không hơn.”
Push chỉ để tận dụng thời gian mạng rảnh (idle network time).
Không nên push toàn bộ tài nguyên mà trang cần, vì như vậy sẽ ghi đè cơ chế ưu tiên tải (prioritization) vốn được trình duyệt tối ưu tốt hơn.
Internet đã trở thành một phần không thể thiếu trong cuộc sống hàng ngày. Mua sắm, ngân hàng, giao tiếp và giải trí đều phụ thuộc vào internet, và với sự phát triển của Internet vạn vật (IoT), ngày càng có nhiều thiết bị được kết nối trực tuyến, nơi chúng có thể được truy cập từ xa. Truy cập này được thực hiện nhờ một số công nghệ, bao gồm Giao thức Truyền Siêu văn bản (HTTP), đây là một phương pháp chính để yêu cầu truy cập vào các ứng dụng và tài nguyên web từ xa.
Mục đích sử dụng chính và đầu tiên của HTTP: để yêu cầu các trang web. Khi bạn mở một trang web trong trình duyệt của mình, dù trình duyệt đó trên pc/laptop, tablet, điện thoại di động hoặc bất kỳ thiết bị nào khác cho phép truy cập internet (tủ lạnh, tivi, …), rất nhiều thứ đang diễn ra.
Giả sử bạn khởi động trình duyệt và truy cập www.google.com. Trong vòng vài giây, những điều sau sẽ xảy ra
Bước 1: DNS, IPv4, IPv5, IPv6, IPv1-3
Khi bạn gõ www.google.com vào trình duyệt, nó không tự biết Google ở đâu. Trình duyệt sẽ nhờ đến một “cuốn danh bạ” đặc biệt gọi là DNS (Domain Name System). Công việc của DNS rất đơn giản: biến cái tên thân thiện với con người (www.google.com) thành một dãy số mà máy tính hiểu được, gọi là địa chỉ IP.
Tên miền giống như tên người trong danh bạ: “Google”.
Địa chỉ IP giống như số điện thoại: máy tính chỉ biết gọi bằng số, chứ không hiểu tên.
Hiện nay có hai “kiểu số điện thoại” chính:
IPv4: dạng cũ, ví dụ 216.58.192.4. Nhìn khá ngắn gọn, con người còn đọc được.
IPv6: dạng mới, ví dụ 2607:f8b0:4005:801:0:0:0:2004. Dài ngoằng, chỉ máy tính mới “thích” đọc. IPv6 sinh ra vì IPv4 gần như đã “hết số”, giống như khi một thành phố phải thêm mã vùng điện thoại mới vì dân cư quá đông.
Một fact: vì internet là toàn cầu, Google (và các công ty lớn khác) đặt máy chủ khắp nơi trên thế giới. DNS sẽ thông minh chọn cho bạn địa chỉ IP của máy chủ gần nhất, để tốc độ truy cập nhanh hơn. Thế nên một người ở Mỹ và một người ở châu Âu có thể nhận được IP hoàn toàn khác nhau khi cùng gõ www.google.com.
Điều gì đã xảy ra với IPv5?
Mỗi thiết bị kết nối Internet đều cần một địa chỉ IP duy nhất, giống như mỗi ngôi nhà cần một số nhà riêng.
Với IPv4, ta có khoảng 4,3 tỷ “số nhà” (2³² địa chỉ). Khi Internet mới ra đời, con số đó nghe như vô tận.
Nhưng rồi máy tính cá nhân, điện thoại thông minh, camera an ninh, đồng hồ thông minh, tủ lạnh IoT… tất cả đều cần một địa chỉ. Điều này khiến kho địa chỉ IPv4 gần như cạn kiệt.
Buộc phải mở ra một hệ thống đánh số mới rộng hơn. IPv6 chính là “hệ thống số nhà mở rộng” đó, với 128 bit, đủ để cấp địa chỉ cho hầu như mọi hạt cát trên trái đất. (2^128)
Bạn có thể thấy hơi lạ: chúng ta có IPv4, rồi nhảy thẳng sang IPv6. Thế IPv5 biến đi đâu? Và tại sao chẳng ai nhắc tới IPv1–IPv3?
Thực ra mọi gói tin Internet đều có một trường nhỏ ở đầu (4 bit) để ghi phiên bản. Về lý thuyết, chỉ có tối đa 15 phiên bản (0–15). (Có thể thấy ở ảnh dưới, phần Version đầu tiên)
IPv6: giải quyết triệt để vấn đề “hết số nhà” trên Internet, đồng thời bổ sung nhiều tính năng mới. Đây mới là “người kế nhiệm” thực sự.
IPv0–IPv3: chỉ là các phiên bản thử nghiệm ban đầu. Không cái nào trở thành chuẩn chính thức.
IPv4: phiên bản đầu tiên thực sự phổ biến, đưa Internet bùng nổ như chúng ta thấy ngày nay.
IPv5: từng tồn tại dưới cái tên Internet Stream Protocol. Nó được thiết kế cho âm thanh và video theo thời gian thực (kiểu như những gì sau này VoIP làm). Nhưng nó sớm bị bỏ xó, vì vẫn mắc đúng nhược điểm của IPv4: không đủ không gian địa chỉ.
Vậy nên, IPv5 không “mất tích” mà chỉ dừng lại ở mức thử nghiệm. Thế giới chọn đi thẳng từ IPv4 sang IPv6 để giải quyết triệt để vấn đề cạn kiệt địa chỉ.
Bước 2: Tạo kết nối TCP/IP
Sau khi có địa chỉ IP, trình duyệt sẽ tìm cách kết nối đến máy chủ web. Kết nối này thường chạy qua:
Cổng 80 cho HTTP (truyền thống).
Cổng 443 cho HTTPS (phiên bản an toàn, có mã hóa).
Ngày nay hầu hết các trang web (kể cả Google) đều bắt buộc HTTPS nhờ công nghệ HSTS. Nghĩa là, ngay cả khi bạn gõ http://..., trình duyệt cũng sẽ tự động nâng cấp sang HTTPS.
TCP và IP phối hợp thế nào?
IP giống như địa chỉ nhà, đảm bảo gói tin tìm đúng nơi đến.
TCP giống như dịch vụ giao hàng uy tín: luôn hỏi “Bạn có nhận đủ chưa?”, nếu thiếu thì gửi lại.
Khi kết hợp, ta có TCP/IP, hai thứ làm nên xương sống Internet.
Một địa chỉ IP, nhiều dịch vụ
Một máy chủ có thể phục vụ nhiều “dịch vụ” khác nhau (web, email, FTP…). Để phân biệt, nó dùng cổng/port , giống như từ 1 địa chỉ nhà, chúng ta có thể chỉ tới số phòng, tầng, …
HTTP → cổng 80
HTTPS → cổng 443
HTTP
Khi kết nối TCP/IP đã ổn định, trình duyệt mới bắt đầu dùng HTTP để gửi yêu cầu: “Hãy cho tôi trang chủ Google”. Lúc này mới đến phần giao tiếp cấp ứng dụng mà ta thường nghe đến nhiều nhất.
Bước 3-10: Yêu cầu máy chủ phản hồi và trình duyệt bắt đầu “vẽ” trang
Sau khi trình duyệt gửi yêu cầu, máy chủ Google phản hồi. Nội dung phản hồi thường là HTML – ngôn ngữ mô tả cấu trúc của trang web.
HTML giống như bộ khung của một ngôi nhà: nó chia trang thành các phần (thẻ <div>, <p>, <h1>…), và kèm theo đường dẫn tới những vật liệu khác để hoàn thiện ngôi nhà:
CSS (màu sắc, kiểu dáng)
JavaScript (hành vi, tương tác)
Hình ảnh, font chữ, video…
Mã phản hồi và chuyển hướng
Không phải lúc nào máy chủ cũng trả về ngay một trang HTML:
Nếu bạn truy cập http://www.google.com, máy chủ sẽ gửi lại mã 301/302 để chuyển hướng bạn sang https://www.google.com.
Nếu bạn gõ nhầm, như www.google.com/nonexistent, bạn sẽ gặp mã 404 Not Found – giống như hỏi thủ thư một cuốn sách không có trong thư viện.
Trình duyệt dựng DOM
Khi nhận được HTML, trình duyệt sẽ phân tích và xây dựng DOM (Document Object Model) – bản đồ nội bộ của trang. Trong quá trình đọc HTML, nó phát hiện thêm tài nguyên cần tải (CSS, JS, hình ảnh…).
Google khá “nhẹ nhàng”: chỉ khoảng 16 tài nguyên bổ sung.
Trang trung bình: khoảng 75 tài nguyên (theo HTTP Archive).
Facebook? Có thể lên tới hàng trăm tài nguyên – mỗi ảnh, script, quảng cáo đều phải gọi thêm.
Mỗi tài nguyên lại đi qua vòng lặp yêu cầu–phản hồi như ban đầu, khiến duyệt web chậm dần. Đây cũng là lý do HTTP/2 ra đời: gom nhiều yêu cầu để tải nhanh hơn.
Khi nào thì “bắt đầu vẽ”
Trình duyệt không đợi tải hết tất cả mới hiển thị, mà sẽ render dần dần:
Hãy tưởng tượng bạn xem họa sĩ vẽ tranh: ban đầu chỉ có khung, sau đó thêm màu, rồi chi tiết. Nếu vẽ dở dang mà đưa cho bạn xem, bức tranh cứ đổi hình dáng liên tục – đó chính là cảm giác khi trang web “nhảy”.
Tải nền
Ngay cả sau khi trang “trông như đã xong”, trình duyệt vẫn âm thầm tải thêm:
Ảnh, script theo dõi, quảng cáo…
Tính năng động: ví dụ Google gợi ý kết quả tìm kiếm ngay khi bạn gõ, hay Facebook tự động hiện bài mới.
Những thứ này chạy ngầm trong nền (AJAX, fetch API, WebSocket…), khiến web ngày nay giống ứng dụng thật sự chứ không chỉ là trang tĩnh.
HTTP là gì
Vào thập niên 1930, kỹ sư điện Vannevar Bush (MIT) đã lo ngại rằng khối lượng thông tin con người tạo ra vượt xa khả năng tiêu thụ. Trong bài tiểu luận As We May Think (1945), ông hình dung ra một thiết bị gọi là memex – nơi mọi tri thức được lưu trữ, có thể tra cứu nhanh chóng và liên kết với nhau giống như cách bộ não kết nối ý tưởng. Memex không bao giờ thành hiện thực, nhưng khái niệm “kết nối thông tin có ngữ cảnh” đã gieo mầm cho thế hệ sau.
Đến những năm 1960, Ted Nelson đưa ra thuật ngữ hypertext – tập hợp văn bản/hình ảnh liên kết phức tạp mà giấy in không thể thể hiện. Nelson mơ về một “docuverse”, nơi thông tin được liên kết, không bao giờ bị xóa, và mọi người đều có thể truy cập. Dù dự án Xanadu của ông không thành công, nhưng nó đã tạo cảm hứng mạnh mẽ.
Năm 1989, tại CERN, Tim Berners-Lee muốn một cách để quản lý thông tin từ các thí nghiệm khổng lồ. Ông kết hợp ý tưởng hypertext (liên kết tự do) và hypermedia (không giới hạn ở chữ viết) để đề xuất một hệ thống “phổ quát” , chính là nền móng của World Wide Web. Và từ đây, HTTP (Hypertext Transfer Protocol) ra đời.
HTTP (Hypertext Transfer Protocol) đúng như tên gọi, ban đầu được tạo ra chỉ để chuyển các tài liệu “siêu văn bản” – tức là những trang có thể chứa liên kết sang trang khác. Nhưng chẳng bao lâu, người ta nhận ra rằng nó cũng có thể dùng để gửi những thứ khác như hình ảnh, âm thanh, video…
Vì vậy, chữ Hypertext trong tên ngày nay không còn quá chính xác, nhưng cái tên HTTP đã ăn sâu nên không ai đổi nữa.
Điều quan trọng là HTTP hoạt động dựa trên kết nối mạng ổn định (thường qua TCP/IP). Nó không quan tâm đến cách bạn nối dây mạng, Wi-Fi hay Ethernet thế nào, tất cả việc đó do các tầng giao thức bên dưới lo. HTTP chỉ tập trung làm một việc: nhận yêu cầu từ trình duyệt và trả về phản hồi từ máy chủ.
Điểm mạnh của HTTP chính là sự đơn giản. Trình duyệt gửi yêu cầu, máy chủ trả lời – thế thôi. Chính sự giản đơn này giúp web phát triển thần tốc, dù sau này phải đánh đổi một chút để tối ưu hiệu năng (như trong HTTP/2, HTTP/3).
Cú pháp HTTP cơ bản
Một yêu cầu HTTP, ở mức đơn giản nhất, chỉ là một dòng văn bản. Ví dụ:
GET /page.html↵
Ở đây:
GET là phương thức (cách bạn “xin” dữ liệu).
/page.html là tài nguyên bạn muốn.
Dấu xuống dòng (↵) cho biết bạn đã gõ xong.
Thế là đủ. Khi đó, trình duyệt đã có kết nối TCP/IP với máy chủ rồi, nên nó chỉ cần nói: “Ê, cho tôi file này với!”
HTTP 0.9
Phiên bản đầu tiên, HTTP/0.9 (1991), chỉ biết làm đúng điều này: gửi GET, nhận file HTML, rồi đóng kết nối. Nhìn lại, bạn có thể thấy lạ: “Sao phải viết GET nữa? Chẳng phải mặc định nó chỉ có một lệnh duy nhất đó sao?” Nhưng chính nhờ tầm nhìn xa, sau này các nhà thiết kế bổ sung thêm nhiều phương thức khác (POST, HEAD…), nên cú pháp ban đầu vẫn giữ được tính mở rộng, chạy được với cả các phiên bản http cũ.
HTTP 1.0
HTTP/0.9 chỉ biết GET một file HTML rồi thôi, nhưng đến HTTP/1.0 (1996), web đã có thêm cơ bắp.
Ba phương thức mới quen mặt
GET (nâng cấp): Giờ đây không chỉ tải trang HTML, mà còn có thể yêu cầu ảnh, nhạc, video… Ngoài ra, GET còn “thông minh” hơn: có thể hỏi “file này có thay đổi từ lần cuối tôi tải không?” Nếu không, máy chủ chỉ trả lời “yên tâm, bản cũ còn dùng được” (giúp tiết kiệm băng thông).
HEAD: Giống như soi bìa sách thay vì đọc cả cuốn. Client chỉ lấy metadata (header HTTP) để kiểm tra thông tin: file còn tồn tại không, có đổi mới không…
POST: Đây là bước đột phá. Client có thể gửi dữ liệu lên server, ví dụ form đăng nhập hay đơn hàng mua sắm. Khác với GET, giao thức POST mang dữ liệu trong body request, kín đáo hơn (dù vẫn phải gửi qua HTTPS mới thật sự an toàn).
Header: lời nhắn gửi kèm yêu cầu
HTTP/1.0 bổ sung header – những dòng thông tin thêm để client “dặn dò” server. Ví dụ:
Tôi đang dùng trình duyệt tên “MyAwesomeWebBrowser 1.1”
Đây chính là cơ chế giúp web mở rộng: chỉ cần thêm header mới là có thể dạy client/server hiểu thêm “ngôn ngữ” mà không phá vỡ giao thức.
Mã phản hồi: server biết cách trả lời
HTTP/0.9 không có khái niệm mã phản hồi. Nếu lỗi thì server chỉ nhét thông báo vào HTML. Sang HTTP/1.0, lần đầu tiên xuất hiện status code, ba chữ số huyền thoại:
Các mã 2xx, 3xx, 4xx, 5xx chia thành từng nhóm rõ ràng, biến HTTP thành một cuộc hội thoại có quy tắc: client hỏi, server đáp, không phải đoán mò nữa.
2xx – Thành công
200 OK: Mọi thứ ngon lành, dữ liệu đây.
201 Created: POST thành công, đã tạo tài nguyên mới.
202 Accepted: Server nhận rồi, đang xử lý, bạn đợi chút.
204 No Content: Yêu cầu thành công nhưng không có gì để gửi lại (ví dụ: xóa một record).
3xx – Chuyển hướng
300 Multiple Choices: Có nhiều đường, bạn chọn.
301 Moved Permanently: Tài nguyên đã dọn nhà vĩnh viễn (Location header chỉ đường).
302 Moved Temporarily: Tạm thời dọn nhà.
304 Not Modified: File chưa đổi từ lần cuối, cứ dùng bản cũ.
4xx – Lỗi từ phía client
400 Bad Request: Server không hiểu bạn nói gì, sửa cú pháp đi.
401 Unauthorized: Bạn chưa đăng nhập.
403 Forbidden: Đăng nhập rồi nhưng không có quyền.
404 Not Found: Nổi tiếng nhất – giống như bấm số điện thoại sai: “Thuê bao không tồn tại.”
5xx – Lỗi từ phía server
500 Internal Server Error: Lỗi chung chỉ về việc server lỗi
501 Not Implemented: Server không biết xử lý yêu cầu này.
502 Bad Gateway: Proxy/gateway hỏi downstream server nhưng nhận lỗi.
503 Service Unavailable: Server quá tải hoặc đang bảo trì, quay lại sau.
HTTP 1.1
Vì thế, HTTP/1.1 ra đời năm 1997, chỉ 9 tháng sau khi HTTP/1.0 được chuẩn hóa. Nó không thay đổi tận gốc như từ 0.9 → 1.0, nhưng đã tinh chỉnh, bổ sung và quan trọng nhất: đặt ra tiêu chuẩn chính thức cho toàn bộ thế giới web, vốn đang bùng nổ mạnh mẽ.
Đến nay, HTTP/1.1 đã trải qua nhiều lần sửa đổi:
RFC 2068 (1997) – bản đầu tiên
RFC 2616 (1999) – cập nhật và thay thế
RFCs 7230–7235 (2014) – chỉnh sửa, chi tiết hóa hơn (305 trang, gần 100.000 từ!)
Điều này cho thấy: giao thức tưởng chừng “đơn giản” lại phức tạp đến mức cần một bộ luật khổng lồ để mọi trình duyệt, máy chủ, proxy trên thế giới cùng “nói chung một ngôn ngữ”.
Những thay đổi quan trọng trong HTTP/1.1
1. Host header bắt buộc
Trong HTTP/1.0, client gửi request kiểu:
GET /index.html HTTP/1.0
Server hiểu là: à, nó đang xin file index.html từ chính website mà nó đang kết nối đến. Nhưng khi web phát triển, một server có thể chạy hàng trăm website khác nhau trên cùng một địa chỉ IP (virtual hosting). Làm sao server biết client muốn example.com/index.html hay blog.example.com/index.html?
Giải pháp: thêm Host header.
GET / HTTP/1.1
Host: www.google.com
Từ HTTP/1.1 trở đi, mọi request bắt buộc phải có Host. Nhờ đó:
Một server duy nhất có thể phục vụ nhiều website.
Tiết kiệm tài nguyên IP (IPv4 vốn khan hiếm).
Nếu không có bước này, có thể web sẽ “ngốn” sạch IPv4 từ rất sớm. Ngược lại, nếu hồi đó người ta không chọn giải pháp Host header, mà bắt client phải gửi URL đầy đủ (absolute-form), thì web có thể đã ép buộc sang IPv6 sớm hơn 20 năm.
2. Kết nối bền vững (Persistent connections / Keep-Alive)
HTTP ban đầu hoạt động theo kiểu: một request → một response → đóng kết nối.
Nhưng khi web nhiều hình ảnh, CSS, JS, việc liên tục đóng/mở kết nối TCP cực kỳ lãng phí. Mỗi lần bắt tay TCP tốn thêm vài trăm mili-giây, nhân lên hàng chục file thì người dùng sẽ “chờ dài cổ”.
HTTP/1.1 thay đổi mặc định:
Mọi kết nối được giữ mở trừ khi server nói rõ “Connection: close”.
Client có thể gửi tiếp nhiều request trên cùng một kết nối.
GET /style.css HTTP/1.1
Host: www.example.com
GET /script.js HTTP/1.1
Host: www.example.com
Trình duyệt có thể “nạp đơn hàng” liên tục thay vì phải xếp hàng lại từ đầu.
Tuy nhiên, điều này đòi hỏi phải có thêm cách xác định “đâu là hết dữ liệu” (vì không còn dấu hiệu đóng kết nối nữa). Do đó, HTTP/1.1 dùng 1 header Content-Length hoặc chunked transfer encoding để báo độ dài nội dung. Khi đó, các bên có thể từ content length và dữ liệu đã nhận được để biết bao giờ là kết thúc.
3. Pipelining (nhưng thất bại)
HTTP/1.1 còn đưa ra ý tưởng pipelining: client gửi nhiều request “một lèo” mà không chờ phản hồi, server trả kết quả theo thứ tự.
Ví dụ:
Gửi cùng lúc request cho CSS, JS, ảnh.
Server trả về lần lượt CSS → JS → ảnh.
Nghe thì hay, nhưng thực tế bị head-of-line blocking: nếu request đầu tiên bị chậm (ví dụ truy vấn DB lâu), thì mọi request sau bị kẹt. Thêm nữa, hỗ trợ pipelining ở proxy và server thường kém (thậm chí lỗi). Vì vậy, pipelining gần như “chết yểu”, không được các trình duyệt phổ biến bật mặc định.
4. Bộ nhớ đệm (Caching) thông minh hơn
Trong HTTP/1.0, chỉ có header Expires: <date>. Nghĩa là:
Nếu quá ngày đó → tài nguyên hết hạn, phải tải lại từ server.
Nó cứng nhắc, ví dụ bạn muốn cho cache tồn tại 30 phút tính từ lúc tải thì không làm được (vì Expires cần một mốc thời gian cố định).
HTTP/1.1 thì mềm dẻo hơn nhờ Cache-Control:
max-age=600 → cache trong vòng 600 giây (10 phút).
no-cache → client vẫn lưu cache nhưng luôn xác thực lại với server trước khi dùng.
must-revalidate → nếu cache hết hạn thì bắt buộc hỏi server, không được tự ý dùng lại.
public / private → phân biệt cache dùng chung (CDN, proxy) hay chỉ cho trình duyệt người dùng.
Ví dụ thực tế:
File CSS/JS ít thay đổi → Cache-Control: max-age=604800 (1 tuần).
Ảnh profile user (có thể đổi nhưng không thường xuyên) → Cache-Control: max-age=86400, must-revalidate.
Điểm mạnh: giúp tăng tốc độ web, giảm tải server, nhưng vẫn linh hoạt để dữ liệu quan trọng luôn mới.
5. Nhiều method và tính năng mới
HTTP/1.1 bổ sung khá nhiều method để phù hợp với web ngày càng phức tạp:
Method mới
PUT: ghi đè hoặc tạo tài nguyên ở URL cụ thể.
DELETE: xóa tài nguyên.
OPTIONS: hỏi server xem URL đó hỗ trợ những method nào (cần cho CORS).
TRACE: gửi request để server trả lại toàn bộ nội dung nó nhận → debug.
CONNECT: dùng cho tunneling (thường thấy khi HTTPS đi qua proxy).
Proxy support Cho phép request/response đi qua nhiều server trung gian (caching proxy, load balancer, CDN).
Authentication Có sẵn cơ chế như Basic và Digest Authentication để bảo vệ tài nguyên.
Cookies HTTP vốn stateless (mỗi request độc lập, không nhớ “ai với ai”). Cookie giúp “nhớ” trạng thái (user đã login, giỏ hàng, session…).
Charset & Content-Language Giúp server khai báo tài liệu dùng encoding gì (UTF-8, ISO-8859-1…) và ngôn ngữ (en, vi…).
Status code mới Bổ sung thêm nhiều mã: 409 Conflict, 410 Gone, 100 Continue… để mô tả chính xác hơn tình huống.
Trailing headers & mở rộng headers vô hạn Cho phép thêm metadata bổ sung sau phần body (dùng trong chunked transfer). HTTP/1.1 cũng gỡ bỏ giới hạn số lượng header → dễ mở rộng (các API hiện nay tận dụng điều này rất nhiều, như Authorization, X-Request-ID, Content-Security-Policy).
Các vấn đề của HTTP/1.1
Sau khi HTTP/1.1 được chuẩn hóa, nó trở thành nền móng của web suốt 20 năm. Nhưng chính sự bùng nổ website đã làm lộ rõ giới hạn của giao thức này.
Năm 2010, trang web trung bình ~ 700 KB, khoảng 50 request.
Đến 2018, tăng lên gần 1.8 MB, hơn 80–90 request.
Một số website lớn:
Wikipedia: chỉ 7 request, 0.06 MB (rất tối ưu).
Facebook: 172 request, 2.2 MB.
Amazon: 136 request, 4.46 MB.
Yahoo: 240 request, 3.8 MB.
Nguyên nhân: website ngày càng giàu media (ảnh, video), nhiều framework và script, và dùng AJAX để cập nhật động liên tục.
Các vấn đề performance của HTTP/1.1 và cách giải quyết tạm thời vào thời điểm này
Hãy tưởng tượng bạn mở một trang web rất đơn giản: chỉ có một ít văn bản và hai tấm hình.
Mỗi yêu cầu (request) từ trình duyệt đến server tốn 50ms để di chuyển qua mạng internet.
Máy chủ lấy dữ liệu từ file server, xử lý trong 10ms rồi trả về.
Trình duyệt khi nhận được ảnh, xử lý thêm 10ms trước khi gửi tiếp yêu cầu mới.
Tổng cộng, để hiển thị xong trang này cần 360ms. Trong đó chỉ 60ms là thời gian xử lý thực sự ở máy khách và máy chủ; còn lại 300ms (hơn 80%) chỉ để… chờ dữ liệu qua lại trên đường truyền. Trong lúc chờ, cả server lẫn trình duyệt đều “ngồi chơi xơi nước”
Điều bất hợp lý lộ rõ ở mốc 120ms: trình duyệt vừa gửi yêu cầu lấy ảnh số 1 và biết chắc là sẽ cần ảnh số 2, nhưng không thể gửi ngay. Nó buộc phải chờ ảnh 1 trả về xong, kết nối mới “rảnh” để gửi tiếp yêu cầu ảnh 2 vào lúc 240ms. Cách vận hành này làm mọi thứ chậm hẳn đi.
Trình duyệt hiện đại thường mở 6 kết nối / domain. Nếu website có nhiều file, chúng được tải trên 6 “đường ống” cùng lúc.
Dùng nhiều kết nối HTTP
Để tăng hơn nữa, nhiều trang web dùng domain sharding: chia file ra các subdomain như static.example.com, cdn.example.com… Như vậy mỗi domain được thêm 6 kết nối, tăng khả năng song song.
Ví dụ: StackOverflow tải:
jQuery từ Google,
Script/CSS từ cdn.static.net,
Ảnh từ i.stack.imgur.com.
Nhưng: giải pháp này lại tạo ra gánh nặng:
TCP handshake: mỗi kết nối mới cần 3 bước SYN → SYN-ACK → ACK (tốn 1.5 round-trip).
TCP slow start: kết nối mới ban đầu chỉ gửi ít gói, tăng dần khi chứng minh mạng chịu tải. Nghĩa là request/response đầu tiên thường bị “thắt cổ chai”.
HTTPS handshake: thêm vài vòng trao đổi nữa để thiết lập mã hóa.
Mozilla từng thống kê: 74% kết nối HTTP/1 chỉ dùng cho 1 transaction duy nhất → tức nhiều kết nối mở ra xong gần như bỏ phí.
Kết luận: mở nhiều kết nối giúp đỡ phần nào, nhưng chỉ là giải pháp tình thế. Nó tự tạo thêm chi phí (handshake, slow start, bộ nhớ) trong khi bản chất vấn đề vẫn là độ trễ.
Giảm số lượng request
Cách khác: thay vì tăng kết nối, hãy giảm số lần gọi.
Cache: dùng HTTP header Cache-Control, Expires để client lưu lại file, không tải lại nữa.
Sprite images: gộp nhiều icon nhỏ thành một ảnh lớn rồi dùng CSS để “cắt” ra (TinyPNG hay dùng cách này).
Concatenate & Minify: gộp nhiều file CSS/JS → một file duy nhất, đồng thời xóa khoảng trắng, comment.
Inline: chèn CSS/JS/ảnh trực tiếp vào HTML (dùng <style>, <svg>, hoặc base64).
Nhược điểm:
Phức tạp: tạo sprite, gộp file cần phải triển khai từ trước.
Lãng phí: tải cả sprite 100 icon trong khi chỉ cần 2.
Cache khó quản lý: một thay đổi nhỏ buộc user tải lại cả file lớn (dù chỉ đổi một dòng CSS).
SPDY
Nguồn gốc: năm 2009, Google (Mike Belshe & Robert Peon) giới thiệu SPDY (đọc là “speedy”). Họ chạy thử nghiệm trên bản sao của 25 trang web lớn nhất và thấy cải thiện tốc độ tải trang rất rõ rệt, tới mức hai chữ số phần trăm trong nhiều trường hợp.
Ý tưởng chính của SPDY: không thay đổi “nghĩa” của HTTP (vẫn có GET/POST/headers/body), nhưng thay đổi cách đóng gói và gửi các yêu cầu/response sao cho nhanh hơn và hiệu quả hơn với mạng hiện có. SPDY làm 4 việc quan trọng:
Multiplexing (đa luồng trên một kết nối):
Trước HTTP/1.1: trình duyệt mở nhiều kết nối TCP (mỗi tên miền thường ~6 kết nối đồng thời). Mỗi kết nối chỉ xử lý lần lượt một yêu cầu → xuất hiện “waterfall” (đọan thác): các nhóm tài nguyên phải chờ lượt.
SPDY: mọi request/response được chia thành các streams nhỏ, gửi xen kẽ qua một kết nối TCP duy nhất. Kết quả: tài nguyên có thể được gửi song song mà không cần mở thêm TCP connection.
Request prioritization (ưu tiên yêu cầu):
Không phải mọi tài nguyên đều quan trọng như nhau. SPDY cho phép trình duyệt nói với server tài nguyên nào quan trọng hơn (ví dụ: CSS quan trọng hơn ảnh nền). Server có thể ưu tiên gửi trước các stream quan trọng.
Header compression:
HTTP/1.1 gửi header dạng text cho từng yêu cầu, với nhiều request, header trùng lặp (cookie, user-agent, accept,…) gây lãng phí. SPDY nén header để giảm kích thước và số byte truyền.
Nếu mỗi request gửi một header Cookie: SESS=... dài 200 B, 360 request = 72 KB chỉ cho cookie. Header compression giảm con số này mạnh mẽ.
Server push (đẩy từ server):
Server có thể “đẩy” các tài nguyên mà nó dự đoán client sẽ cần (ví dụ: CSS, JS) ngay khi client yêu cầu HTML, tránh vòng lặp client → server hỏi “tôi cần CSS không?” → server mới trả.
Vì các tính năng như multiplexing và framing yêu cầu cấu trúc nhỏ gọn, chính xác và dễ phân mảnh, điều khó/không thể làm tốt khi gửi toàn bộ theo dạng text line-based (như HTTP/1.x). Binary framing cho phép định nghĩa các frame nhỏ (HEADERS, DATA, SETTINGS, WINDOW_UPDATE, v.v.) để truyền và ghép lại chính xác.
Kết quả thực tế: triển khai SPDY ở Chrome và trên các dịch vụ Google cho thấy tốc độ tải trang cải thiện rõ rệt; nhiều browser/server khác cũng nhanh chóng bổ sung hỗ trợ. Tuy nhiên SPDY chỉ là bước trung gian: nó chứng minh các ý tưởng thực tế và trở thành nền tảng để chuẩn hóa HTTP/2.
Ảnh: Sau khi HTTP/2 ra đời, SPDY bắt đầu giảm xuống
HTTP/2
SPDY chứng minh rằng các cải tiến có thể làm được, IETF (HTTP Working Group) dựa trên SPDY khi soạn HTTP/2 (bản draft đầu vào cuối 2012). HTTP/2 giữ hầu hết ý tưởng tốt của SPDY nhưng chuẩn hoá chúng, bổ sung một số cải tiến (ví dụ HPACK cho header compression) và xử lý các chi tiết tương thích/ bảo mật.
Tại sao dùng HTTP/2 thay vì HTTP/1.2?
HTTP/2 được tạo ra để giải quyết các vấn đề hiệu suất của HTTP/1, và phiên bản mới này thêm vào các khái niệm sau:
Giao thức nhị phân thay vì văn bản.
Ghép kênh (multiplexed) thay vì đồng bộ (synchronous).
Kiểm soát dòng chảy (flow control).
Ưu tiên luồng (stream prioritization).
Nén tiêu đề (header compression).
Đẩy từ máy chủ (server push).
Những khái niệm này (sẽ được mô tả chi tiết hơn trong chương) là những thay đổi cơ bản, phá vỡ tính tương thích ngược; nghĩa là, máy chủ web HTTP/1.0 có thể hiểu tin nhắn HTTP/1.1 và bỏ qua các chức năng thừa, nhưng điều này không đúng với tin nhắn HTTP/2, vì chúng có cấu trúc và định dạng khác. Vì lý do đó, HTTP/2 được coi là bản nâng cấp lớn..
Nhị phân thay vì văn bản
Một khác biệt chính giữa HTTP/1 và HTTP/2 là HTTP/2 là giao thức nhị phân dựa gói, trong khi HTTP/1 hoàn toàn dựa văn bản. Giao thức dựa văn bản dễ hiểu cho con người nhưng khó phân tích cho máy tính. Điều này chấp nhận được cho giao thức yêu cầu-phản hồi đơn giản mà HTTP bắt đầu, nhưng ngày càng hạn chế cho internet hiện đại.
Với giao thức văn bản, yêu cầu phải gửi và phản hồi nhận đầy đủ trước khi xử lý yêu cầu khác. HTTP hoạt động thế này 20 năm qua, dù có cải tiến nhỏ. HTTP/1.0 giới thiệu thân HTTP nhị phân, ví dụ, nơi hình ảnh và media khác có thể gửi trong phản hồi, và HTTP/1.1 giới thiệu pipelining và mã hóa chunked. Mã hóa chunked cho phép gửi phần thân tin nhắn trước, phần còn lại theo sau khi sẵn sàng. Thân HTTP chia thành chunk, và client nhận chunked response (hoặc server nhận chunked request) có thể bắt đầu xử lý trước khi nhận đầy đủ. Kỹ thuật này thường dùng khi độ dài dữ liệu tạo động không biết trước. Cả chunked encoding và pipelining có vấn đề chặn đầu hàng (HOL blocking), nơi tin nhắn đầu hàng ngăn phản hồi sau gửi, chưa kể pipelining không được hỗ trợ tốt trong thế giới thực.
HTTP/1.1
Định dạng: toàn bộ request/response là văn bản (ASCII/UTF-8).
Request line: GET /index.html HTTP/1.1
Headers: Host: example.com\r\n...
Body: theo sau, độ dài được báo bằng Content-Length hoặc chunked encoding.
Kết quả:
Parser phải đọc dấu hiệu kết thúc dòng (\r\n) để tách header.
Nếu header/body to, trình duyệt phải chờ nhiều (buffering).
Chỉ một request/response được xử lý trên một TCP connection tại một thời điểm → dễ nghẽn (head-of-line blocking).
Không có khái niệm “frame type”, tất cả đều là text nối tiếp nhau.
HTTP/2 – mọi thứ là frame
Cấu trúc rõ ràng, nhị phân: mỗi frame có header 9 byte cố định + payload.
Length (3 byte): kích thước payload.
Type (1 byte): phân loại (DATA, HEADERS, SETTINGS, PING, …).
Flags (1 byte): đánh dấu (END_STREAM, END_HEADERS, …).
Stream ID (4 byte, thực tế 31 bit): thuộc về stream nào.
Payload: dữ liệu thực (body, header block, …).
Ưu điểm:
Parser biết ngay độ dài frame → không cần scan ký tự xuống dòng.
Có thể ghép nhiều request/response song song trên một TCP connection (multiplexing, sẽ giải thích thêm ở dưới), nhờ phân biệt bằng stream ID.
Cho phép mở rộng: frame mới có thể được định nghĩa thêm mà không phá chuẩn.
Có nhiều loại frame khác nhau cho mục đích cụ thể: HEADERS, DATA, PRIORITY, WINDOW_UPDATE, PUSH_PROMISE… → kiểm soát chi tiết mà h1.1 không làm được.
Cấu trúc frame header (9 bytes đầu):
Length (3 bytes): độ dài payload.
Type (1 byte): loại frame (HEADERS, DATA, SETTINGS, …).
Flags (1 byte): cờ tùy theo frame type.
R (1 bit): reserved, không dùng.
Stream Identifier (31 bits): xác định stream mà frame thuộc về.
Payload: dữ liệu thực, độ dài như Length.
Frame types (10 chuẩn + mở rộng):
DATA (0x0): payload chính.
HEADERS (0x1): HTTP headers + priority.
PRIORITY (0x2): thay đổi độ ưu tiên, dependency.
RST_STREAM (0x3): kết thúc stream (thường khi lỗi).
SETTINGS (0x4): config connection.
PUSH_PROMISE (0x5): server thông báo sẽ push object.
PING (0x6): test RTT.
GOAWAY (0x7): đóng connection, không nhận stream mới.
WINDOW_UPDATE (0x8): điều khiển flow (bytes còn có thể nhận).
CONTINUATION (0x9): nối thêm headers khi HEADERS quá dài.
Extension frames: cho phép mở rộng mà không phá protocol.
t= 1646 [st= 1] HTTP2_SESSION_RECV_SETTINGS
t= 1647 [st= 2] HTTP2_SESSION_RECV_SETTING
--> id = "1 (SETTINGS_HEADER_TABLE_SIZE)"
--> value = 4096
t= 1647 [st= 2] HTTP2_SESSION_RECV_SETTING
--> id = "5 (SETTINGS_MAX_FRAME_SIZE)"
--> value = 16384
t= 1647 [st= 2] HTTP2_SESSION_RECV_SETTING
--> id = "6 (SETTINGS_MAX_HEADER_LIST_SIZE)"
--> value = 131072
t= 1647 [st= 2] HTTP2_SESSION_RECV_SETTING
--> id = "3 (SETTINGS_MAX_CONCURRENT_STREAMS)"
--> value = 100
t= 1647 [st= 2] HTTP2_SESSION_RECV_SETTING
--> id = "4 (SETTINGS_INITIAL_WINDOW_SIZE)"
--> value = 65536
Ghép kênh (multiplexing) trên một kết nối
Ý tưởng chính: HTTP/2 biến mỗi yêu cầu thành một luồng (stream) riêng, và tất cả luồng đi chung một “đường ống TCP duy nhất”.
Yêu cầu được cắt thành các khung (frame) nhỏ.
Mỗi khung có ID luồng để biết nó thuộc yêu cầu nào.
Server và client chỉ việc ghép các khung lại → tái tạo thành thông điệp HTTP hoàn chỉnh.
Lợi ích:
Không bị nghẽn đầu hàng (head-of-line blocking ở mức HTTP): Nếu một yêu cầu chậm (ví dụ tải ảnh lớn), nó không làm tắc nghẽn các yêu cầu khác. Server có thể trả xen kẽ: một khung ảnh, rồi một khung CSS, rồi tiếp tục ảnh…
Chỉ cần một kết nối TCP duy nhất cho mọi tài nguyên → giảm overhead handshake, giảm tiêu tốn tài nguyên.
Server có thể quyết định ưu tiên: gửi CSS/JS quan trọng trước, hình ảnh phụ sau → tăng tốc độ hiển thị trang.
Server phải trả đúng thứ tự: CSS → JS → PNG. Nếu file CSS to hoặc bị trễ, hai file sau cũng kẹt lại.
Với HTTP/2 multiplexing:
Client gửi cả 3 yêu cầu trên cùng một kết nối.
Server có thể trả: một phần CSS → một phần JS → một phần PNG → tiếp tục CSS…
Trình duyệt nhận được khung CSS đầu tiên thì đã có thể render ngay, không cần chờ toàn bộ CSS tải xong.
Bên trái (Client): trình duyệt gửi nhiều request (GET /styles.css, GET /script.js, GET /image.jpg…).
Giữa (HTTP/2 layer): tất cả request/response đều đi qua một kết nối TCP duy nhất nhưng được đóng gói thành nhiều stream. Mỗi stream lại chia nhỏ thành nhiều frame.
Bên phải (Server): server nhận request từ nhiều stream cùng lúc, xử lý rồi trả response xen kẽ trở lại trên cùng kết nối TCP.
Bước 1: Client gửi request
Client tạo 3 request:
Request 2 → GET /styles.css → Stream 5
Request 3 → GET /script.js → Stream 7
Request 4 → GET /image.jpg → Stream 9
Mỗi request sẽ được đánh số ID luồng (stream ID). Ở đây: 5, 7, 9 (client luôn tạo ID lẻ).
Bước 2: HTTP/2 framing layer đóng gói
Request không gửi nguyên khối, mà bị chia nhỏ thành frames:
Các frame từ nhiều stream có thể xếp nối tiếp nhau trên cùng kết nối TCP.
Ví dụ: thay vì phải gửi toàn bộ styles.css rồi mới đến script.js, rồi mới đến image.jpg, HTTP/2 sẽ gửi xen kẽ: một frame của Stream 5 (styles.css), sau đó một frame của Stream 7 (script.js), rồi một frame của Stream 9 (image.jpg)…
Bước 3: Server nhận và xử lý
Server đọc các frame, ghép lại theo stream ID để tái tạo thành request đầy đủ.
Sau đó server xử lý và tạo response.
Bước 4: Server trả response xen kẽ
Response cũng được cắt thành frames, rồi trả về client.
Các stream response không cần giữ đúng thứ tự yêu cầu ban đầu.
Server có thể ưu tiên gửi nhanh CSS (quan trọng để render trang) trước khi trả ảnh JPG.
Trong hình: Stream 5 và Stream 7 response đi xen kẽ nhau, trong khi Stream 9 (ảnh JPG) response nối tiếp.
Bạn có thể hình dung:
HTTP/1.1 giống như có 6 cái ống nước riêng, mỗi ống chỉ chảy được một loại nước. Nếu một ống nghẹt thì nước loại đó tắc hết.
HTTP/2 giống như một ống nước lớn duy nhất, trong đó dòng chảy có nhiều màu khác nhau (đỏ = ảnh, vàng = CSS, xanh = JS). Các giọt nước khác màu có thể luân phiên chạy trong cùng một ống, và khi đến đích thì được lọc ra đúng “xô” tương ứng.
Stream prioritization (Ưu tiên dòng)
HTTP/1.x:
Trình duyệt phải “xếp hàng” tài nguyên vì giới hạn 6 kết nối/host.
Muốn ưu tiên CSS/JS quan trọng thì chỉ đơn giản gửi sớm hơn. Nhưng nếu kết nối đã đầy, thì phải đợi → cơ chế ưu tiên thô sơ, bị giới hạn bởi số kết nối.
HTTP/2:
Có thể gửi hàng trăm stream một lúc trên cùng một kết nối.
Nếu không có ưu tiên, dễ lãng phí băng thông: ví dụ hình ảnh (không critical) lại chiếm chỗ trước CSS (critical).
Cơ chế ưu tiên: Client gửi “hints” về độ ưu tiên (priority) → server chọn phân bổ tài nguyên.
Ví dụ: nếu cả CSS và ảnh đang chờ, server sẽ gửi nhiều frame CSS hơn để trình duyệt render trang sớm.
Ưu tiên mềm: không phải “gửi cái này trước, cái kia sau”, mà là chia băng thông nhiều–ít giữa các stream.
Flow control
Ta đã thấy ở Multiplexing nghĩa là nhiều stream chia sẻ cùng một TCP. Nhưng nếu client đọc chậm (ví dụ đang pause video), mà server vẫn dồn dữ liệu video về → nghẽn buffer, mất gói, phải retransmit → phí công.
TCP vốn đã có cơ chế window size để tránh sender “dội” dữ liệu quá nhiều so với khả năng nhận của receiver.
Nhưng: TCP coi cả kết nối như một dòng duy nhất. Nếu một luồng dữ liệu (ví dụ video) bị nghẽn, thì nó kéo theo tất cả dữ liệu khác trên cùng connection → “head-of-line blocking”.
HTTP/2 chia nhỏ kết nối thành nhiều stream (mỗi request/response).
Mỗi stream có cửa sổ riêng (window size), mặc định 65,535 byte.
Cơ chế:
Server chỉ được gửi tối đa số byte trong cửa sổ.
Khi client xử lý xong một phần dữ liệu, nó báo lại bằng WINDOW_UPDATE frame → tăng cửa sổ, cho phép server gửi tiếp.
Kết quả: stream nào “chậm” (ví dụ video đang pause) thì chỉ bị tạm ngừng riêng, không ảnh hưởng các stream khác (CSS, JS vẫn chạy bình thường).
Giả sử stream #11 là video, stream #13 là CSS:
Ban đầu: cả hai có window = 65,535.
Server gửi:
Video 10 KB → cửa sổ video còn 55,535.
CSS 20 KB → cửa sổ CSS còn 45,535.
Client pause video → không gửi WINDOW_UPDATE cho stream #11 → video tạm “đóng băng”.
Nhưng client vẫn gửi WINDOW_UPDATE cho stream #13 → CSS tiếp tục tải bình thường.
This entry is part 7 of 8 in the series SWE Học A.I
Huấn luyện (Train)
Khi huấn luyện một bộ phân loại bằng học có giám sát (supervised learning), mỗi mẫu dữ liệu đều có một nhãn (label) được gán thủ công, mô tả lớp mà mẫu đó thuộc về. Tập hợp tất cả các mẫu dữ liệu dùng để học, cùng với nhãn của chúng, được gọi là tập huấn luyện (training set).
Chúng ta sẽ lần lượt trình bày từng mẫu trong tập huấn luyện cho bộ phân loại. Với mỗi mẫu, hệ thống nhận các đặc trưng (features) của mẫu và dự đoán lớp của nó.
Nếu dự đoán đúng (tức là khớp với nhãn đã gán), chúng ta chuyển sang mẫu tiếp theo. Nếu dự đoán sai, chúng ta cung cấp đầu ra của bộ phân loại và nhãn đúng trở lại cho nó.
Như ảnh trên, ta có thể thấy, trong quá trình huấn luyện, chúng ta sẽ cần điều chỉnh các tham số (parameter) của bộ phân loại để tăng khả năng dự đoán đúng nhãn. Điều này dẫn đến một bài toán tối ưu hóa (optimization problem), nơi mục tiêu là giảm thiểu sai số hoặc tối đa hóa xác suất xảy ra của dữ liệu. Một kỹ thuật phổ biến để giải bài toán này là phương pháp giảm gradient (gradient descent).
Gradient descent
Ta có một hàm số [latex]f[/latex] nhận đầu vào là một vector các số thực và trả về một số thực duy nhất. Một ví dụ đơn giản là hàm tính tổng bình phương các phần tử trong vector:
Python
from scratch.linear_algebra import Vector, dotdefsum_of_squares(v: Vector)->float:"""Tính tổng bình phương các phần tử trong vector v"""returndot(v, v)
Mục tiêu là tìm vector [latex]v[/latex] sao cho hàm [latex]f(v)[/latex] đạt giá trị lớn nhất (tối đa hóa) hoặc nhỏ nhất (tối thiểu hóa). Gradient (vector của các đạo hàm riêng [latex]\nabla f[/latex]) cho biết hướng làm hàm số tăng nhanh nhất. Ý tưởng của phương pháp giảm gradient là:
Chọn một điểm xuất phát ngẫu nhiên.
Tính gradient tại điểm đó.
Di chuyển một bước nhỏ theo hướng gradient (để tối đa hóa) hoặc ngược hướng (để tối thiểu hóa).
Lặp lại quá trình với điểm mới.
Trong hình trên thể hiện một hàm hai biến [latex]f(x, y) = x^2 + y^2[/latex], có dạng hình paraboloid lồi hướng lên, với điểm thấp nhất nằm tại gốc tọa độ [latex](0, 0, 0)[/latex].
Các mũi tên tam giác đỏ thể hiện các bước di chuyển của thuật toán. Tại mỗi bước, gradient được tính và điểm hiện tại được cập nhật theo hướng:
trong đó [latex]\eta[/latex] là tốc độ học (learning rate).
Ước lượng gradient
Nếu hàm [latex]f[/latex] chỉ có một biến, đạo hàm tại điểm [latex]x[/latex] đo lường sự thay đổi của [latex]f(x)[/latex] khi [latex]x[/latex] thay đổi một lượng rất nhỏ.
[latex]
\frac{f(x + h) – f(x)}{h}
[/latex]
Đây gọi là thương số sai phân.
[latex]h[/latex]: là một bước nhỏ (ví dụ: 0.001).
[latex]f(x+h)[/latex]: là giá trị hàm khi đi thêm một chút từ [latex]x[/latex].
[latex]f(x+h) – f(x)[/latex]: là phần thay đổi.
Chia cho [latex]h[/latex] để biết “mỗi bước nhỏ thay đổi bao nhiêu” → chính là độ dốc (gradient)
Đường cong màu xám là đồ thị của hàm [latex]f(x)[/latex].
Hai điểm được đánh dấu:
[latex](x, f(x))[/latex] – điểm gốc.
[latex](x + h, f(x + h))[/latex] – điểm gần đó.
Tam giác màu xanh dương thể hiện:
Đáy tam giác là [latex]h[/latex]
Chiều cao là [latex]f(x+h) – f(x)[/latex]
Độ dốc của đoạn thẳng là:
[latex]
\frac{f(x+h) – f(x)}{h}
[/latex]
→ chính là ước lượng đạo hàm tại [latex]x[/latex].
Khi hàm [latex]f[/latex] có nhiều biến, ta tính đạo hàm riêng (partial derivative) cho từng biến, giữ các biến khác cố định:
Python
defpartial_difference_quotient(f: Callable[[Vector],float],v: Vector,i:int,h:float)->float:"""Tính thương số sai phân riêng thứ i của hàm f tại vector v""" w =[v_j +(h if j == i else0)for j, v_j inenumerate(v)]return(f(w)-f(v))/ hdefestimate_gradient(f: Callable[[Vector],float],v: Vector,h:float=0.0001):return[partial_difference_quotient(f, v, i, h)for i inrange(len(v))]
Lưu ý: Việc ước lượng gradient bằng thương số sai phân tốn nhiều tài nguyên tính toán, đặc biệt với vector có kích thước lớn. Trong thực tế, người ta thường tính gradient trực tiếp bằng toán học để tối ưu hiệu suất.
Sử dụng Gradient để Tối Ưu Hóa Hàm Số
Rõ ràng rằng hàm tổng bình phương (sum of squares) đạt giá trị nhỏ nhất khi đầu vào là một vector toàn số không. Tuy nhiên, giả sử chúng ta chưa biết điều này, chúng ta có thể sử dụng gradient để tìm giá trị tối thiểu trong không gian các vector ba chiều. Bắt đầu từ một điểm ngẫu nhiên, ta thực hiện các bước nhỏ theo hướng ngược với gradient cho đến khi gradient đạt giá trị rất nhỏ.
Python
from scratch.linear_algebra import distance, add, scalar_multiplydefgradient_step(v: Vector,gradient: Vector,step_size:float)-> Vector:"""Di chuyển một khoảng `step_size` theo hướng `gradient` từ điểm `v`"""assertlen(v)==len(gradient) step =scalar_multiply(step_size, gradient)returnadd(v, step)defsum_of_squares_gradient(v: Vector)-> Vector:"""Tính gradient của hàm tổng bình phương"""return[2* v_i for v_i in v]# Chọn điểm bắt đầu ngẫu nhiênv =[random.uniform(-10,10)for i inrange(3)]for epoch inrange(1000): grad =sum_of_squares_gradient(v)# Tính gradient tại v v =gradient_step(v, grad,-0.01)# Bước ngược hướng gradientprint(epoch, v)assertdistance(v,[0,0,0])<0.001# v gần với [0, 0, 0]
Nếu thực thi đoạn code trên, vector v sẽ tiến gần đến [0, 0, 0]. Số lượng epoch càng lớn, kết quả càng chính xác.
Kiểm Thử (Test)
Chúng ta bắt đầu với một hệ thống có các tham số được khởi tạo ngẫu nhiên. Sau đó, chúng ta huấn luyện nó bằng dữ liệu trong tập huấn luyện. Khi hệ thống được triển khai ra thế giới thực, nó sẽ đối mặt với dữ liệu thực tế (deployment data, release data, hoặc user data).
Chúng ta muốn biết hệ thống sẽ hoạt động tốt như thế nào trên dữ liệu thực tế trước khi triển khai. Không cần độ chính xác hoàn hảo, nhưng thường chúng ta mong hệ thống đạt hoặc vượt một ngưỡng chất lượng nhất định. Làm sao để ước lượng chất lượng dự đoán của hệ thống trước khi triển khai?
Hệ thống cần hoạt động tốt trên tập huấn luyện, nhưng nếu chỉ đánh giá độ chính xác dựa trên dữ liệu này, chúng ta thường bị đánh lừa.
Giả sử chúng ta dùng bộ phân loại có giám sát để xử lý ảnh chó. Với mỗi ảnh, hệ thống sẽ gán nhãn xác định giống chó. Mục tiêu là triển khai hệ thống trực tuyến để người dùng có thể kéo ảnh chó của họ vào trình duyệt và nhận về giống chó hoặc nhãn “giống hỗn hợp (mixed breed)”.
Để huấn luyện, chúng ta thu thập 1.000 ảnh chó thuần chủng, mỗi ảnh được chuyên gia gắn nhãn. Chúng ta cho hệ thống xem cả 1.000 ảnh, lặp đi lặp lại qua nhiều epoch (lần lặp), thường xáo trộn thứ tự ảnh mỗi lần lặp để tránh trình tự lặp lại. Nếu hệ thống được thiết kế tốt, nó sẽ dần đạt kết quả chính xác hơn, ví dụ đạt 99% trong việc xác định giống chó trên tập huấn luyện.
Tuy nhiên, điều này không có nghĩa hệ thống sẽ đạt 99% chính xác khi triển khai trực tuyến. Vấn đề là hệ thống có thể đã khai thác các mối quan hệ đặc biệt trong tập huấn luyện, nhưng không đúng với dữ liệu nói chung.
Ví dụ, giả sử các ảnh chó Poodle trong tập huấn luyện đều có một cục bông ở đuôi, trong khi các giống khác thì không. Hệ thống nhận ra điều này và chỉ cần tìm cục bông để phân loại Poodle, thay vì xem xét các đặc trưng như kích thước chân, hình dạng mũi, v.v. Quy tắc này giúp phân loại đúng 100% ảnh Poodle trong tập huấn luyện, nhưng không phải cách chúng ta mong muốn. Hệ thống được cho là đã “học cách gian lận” (cheating)
Một ví dụ khác: Giả sử tất cả ảnh chó Yorkshire Terrier (Yorkie) trong tập huấn luyện đều được chụp khi chó ngồi trên ghế sofa, và không ảnh nào của giống khác có sofa. Hệ thống có thể học rằng nếu có sofa trong ảnh, đó là Yorkie. Quy tắc này hoạt động hoàn hảo trên tập huấn luyện.
Khi triển khai, nếu ai đó gửi ảnh một chú chó Great Dane đứng trước trang trí lễ hội với những quả bóng trắng hoặc một chú Husky nằm trên sofa, hệ thống có thể nhầm quả bóng trắng ở đuôi Great Dane là cục bông và gọi đó là Poodle, hoặc thấy sofa và gọi Husky là Yorkie.
Đây không chỉ là vấn đề lý thuyết. Một ví dụ nổi tiếng từ những năm 1960 (Muehlhauser 2011) kể về một hệ thống học máy nhận diện xe tăng trong ảnh cây cối. Hệ thống được cho là nhận diện xe tăng hoàn hảo, nhưng sau đó phát hiện rằng ảnh có xe tăng được chụp vào ngày nắng, còn ảnh không xe tăng chụp vào ngày âm u. Hệ thống chỉ phân biệt trời sáng và tối, không liên quan gì đến xe tăng.
Đây là lý do tại sao chỉ nhìn vào hiệu suất trên tập huấn luyện không đủ để dự đoán hiệu suất thực tế. Hệ thống có thể học các đặc điểm kỳ lạ (idiosyncrasies) trong tập huấn luyện và sử dụng chúng làm quy tắc, nhưng thất bại với dữ liệu mới không có những đặc điểm đó. Hiện tượng này được gọi là quá khớp (overfitting), hay thường gọi là “gian lận” (cheating)
Dữ liệu kiểm thử (Test Data)
Cách tốt nhất để xác định hiệu suất của hệ thống trên dữ liệu mới, chưa từng thấy là thử nghiệm nó trên dữ liệu kiểm thử (test data hoặc test set). Dữ liệu kiểm thử sẽ không được cho vào trong quá trình huấn luyện, vì vậy từ góc nhìn của hệ thống, chúng sẽ là các dữ liệu mới hoàn toàn.
Dữ liệu kiểm thử phải đại diện cho dữ liệu thực tế mà hệ thống sẽ gặp khi triển khai. Quy trình thông thường là huấn luyện hệ thống trên tập huấn luyện cho đến khi đạt hiệu suất tốt nhất có thể, sau đó đánh giá trên tập kiểm thử để dự đoán hiệu suất thực tế.
Nếu hiệu suất trên tập kiểm thử không đủ tốt, chúng ta cần cải thiện hệ thống, thường bằng cách thu thập thêm dữ liệu và huấn luyện lại. Thêm dữ liệu cũng giúp đa dạng hóa tập huấn luyện, ví dụ, tìm chó không phải Poodle có cục bông ở đuôi hoặc chó không phải Yorkie trên sofa, buộc hệ thống tìm cách phân loại khác để tránh quá khớp.
Do đó, chúng ta tách dữ liệu kiểm thử khỏi tập huấn luyện ngay từ đầu và chỉ sử dụng nó một lần sau khi huấn luyện hoàn tất. Nếu hệ thống không đạt yêu cầu trên tập kiểm thử, chúng ta phải bắt đầu lại với hệ thống mới được khởi tạo ngẫu nhiên, huấn luyện với dữ liệu mới hoặc lâu hơn, rồi đánh giá lại trên tập kiểm thử.
Thông thường, chúng ta tạo tập kiểm thử bằng cách chia tập dữ liệu gốc thành hai phần: tập huấn luyện (khoảng 75%) và tập kiểm thử (25%). Việc chọn mẫu thường ngẫu nhiên, nhưng có thể dùng thuật toán phức tạp hơn để đảm bảo mỗi tập đại diện tốt cho dữ liệu gốc.
Dữ Liệu Xác Thực (Validation Data)
Trong quy trình trên, chúng ta huấn luyện hệ thống, sau đó dừng lại và đánh giá trên tập kiểm thử. Nếu hiệu suất không đủ, chúng ta bắt đầu lại. Cách này hiệu quả nhưng chậm.
Trong thực tế, chúng ta thường muốn ước lượng hiệu suất hệ thống trong quá trình huấn luyện để dừng lại khi đạt mục tiêu. Vì vậy, chúng ta chia dữ liệu gốc thành ba tập: tập huấn luyện (training set), tập xác thực (validation set), và tập kiểm thử (test set), thường theo tỷ lệ 60% – 20% – 20%
Quy trình mới là: huấn luyện qua một epoch trên tập huấn luyện, sau đó đánh giá hiệu suất trên tập xác thực. Việc này được lặp lại sau mỗi epoch, gây rò rỉ dữ liệu, nhưng tập xác thực chỉ dùng để ước lượng không chính thức. Hiệu suất trên tập xác thực giúp chúng ta theo dõi quá trình học của hệ thống. Khi thấy hiệu suất đủ tốt, chúng ta dùng tập kiểm thử một lần để đánh giá chính xác.
Tập xác thực cũng hữu ích khi tìm kiếm siêu tham số (hyperparameters) – các biến được cài đặt trước để kiểm soát hoạt động của hệ thống, như mức độ cập nhật tham số sau lỗi hoặc độ phức tạp của bộ phân loại. Với mỗi bộ siêu tham số, chúng ta huấn luyện trên tập huấn luyện và đánh giá trên tập xác thực. Kết quả từ tập xác thực giúp quyết định khi nào dừng huấn luyện. Khi hiệu suất đạt yêu cầu, chúng ta dùng tập kiểm thử để đánh giá cuối cùng.
Quy trình này là một vòng lặp: chọn siêu tham số, huấn luyện, đánh giá trên tập xác thực, lặp lại với bộ siêu tham số mới, và cuối cùng chọn hệ thống tốt nhất để kiểm tra trên tập kiểm thử.
Vì tập xác thực đã ảnh hưởng đến việc chọn siêu tham số. Dù bộ phân loại không học trực tiếp từ tập xác thực, dữ liệu này đã “rò rỉ” vào quá trình chọn bộ phân loại tốt nhất. Để đánh giá chính xác trên dữ liệu hoàn toàn mới, không có cách nào khác ngoài việc dùng tập kiểm thử vào cuối cùng.
Xác Thực Chéo (Cross-Validation)
Trong phần trước, chúng ta đã dành gần một nửa dữ liệu huấn luyện để làm tập xác thực và kiểm tra. Điều này không thành vấn đề khi chúng ta có lượng dữ liệu đủ lớn để chia. Nhưng nếu tập dữ liệu của chúng ta nhỏ và không thể thu thập thêm dữ liệu thì sao?
Nếu chúng ta chấp nhận một ước lượng về hiệu suất của hệ thống thay vì một phép đo đáng tin cậy, chúng ta không cần phải để dành một tập kiểm tra riêng. Thực tế, chúng ta có thể huấn luyện trên toàn bộ dữ liệu đầu vào và vẫn dự đoán được hiệu suất trên dữ liệu mới.
Kỹ thuật thực hiện công việc này được gọi là xác thực chéo (cross-validation) hoặc xác thực luân phiên (rotation validation).
Ý tưởng cốt lõi là chạy một vòng lặp lặp đi lặp lại việc huấn luyện hệ thống từ đầu và sau đó kiểm tra nó. Mỗi lần lặp, chúng ta chia toàn bộ dữ liệu đầu vào thành một tập huấn luyện tạm thời và một tập xác thực tạm thời. Điều quan trọng là các tập này được tạo khác nhau trong mỗi lần lặp. Điều này cho phép chúng ta sử dụng toàn bộ dữ liệu để huấn luyện (mặc dù không phải tất cả cùng một lúc, như sẽ thấy sau).
Chúng ta bắt đầu bằng cách xây dựng một bộ phân loại mới. Dữ liệu đầu vào được chia thành tập huấn luyện tạm thời và tập xác thực tạm thời. Chúng ta huấn luyện hệ thống trên tập huấn luyện tạm thời và đánh giá nó bằng tập kiểm tra tạm thời, từ đó thu được điểm số về hiệu suất của bộ phân loại. Sau đó, chúng ta lặp lại vòng lặp, nhưng lần này chia dữ liệu thành các tập huấn luyện và kiểm tra tạm thời khác. Khi đã hoàn thành tất cả các lần lặp, trung bình của các điểm số này là ước lượng hiệu suất tổng thể của bộ phân loại.
Nhờ xác thực chéo, chúng ta có thể huấn luyện trên toàn bộ dữ liệu (mặc dù không phải tất cả trong mỗi lần lặp) và vẫn có được một phép đo khách quan về chất lượng hệ thống từ tập kiểm tra riêng. Thuật toán này không gặp vấn đề rò rỉ dữ liệu (data leakage) vì mỗi lần lặp, chúng ta tạo một bộ phân loại mới, và tập kiểm tra tạm thời cho bộ phân loại đó chứa dữ liệu hoàn toàn mới, chưa từng được sử dụng bởi bộ phân loại cụ thể đó, do đó việc sử dụng nó để đánh giá hiệu suất là công bằng. Tuy nhiên, nhược điểm của kỹ thuật này là ước lượng cuối cùng về độ chính xác của hệ thống không đáng tin cậy bằng khi sử dụng tập kiểm tra riêng.
Có nhiều thuật toán khác nhau để xây dựng các tập huấn luyện và xác thực tạm thời. Có thể điểm qua 1 số phương pháp phổ biến:
Xác Thực Chéo K-Fold
Phương pháp phổ biến nhất để xây dựng các tập dữ liệu tạm thời cho xác thực chéo được gọi là xác thực chéo k-fold. Ở đây, chữ “k” không phải là chữ cái đầu của một từ, mà đại diện cho một số nguyên (ví dụ, chúng ta có thể thực hiện “xác thực chéo 2-fold” hoặc “xác thực chéo 5-fold”). Thông thường, giá trị của k là số lần chúng ta muốn lặp lại vòng lặp.
Thuật toán bắt đầu trước khi vòng lặp xác thực chéo diễn ra. Chúng ta lấy dữ liệu huấn luyện và chia nó thành một loạt các nhóm có kích thước bằng nhau. Mỗi mẫu dữ liệu được đặt vào đúng một nhóm, và tất cả các nhóm có kích thước giống nhau (trừ một nhóm nhỏ hơn ở cuối nếu không thể chia đều dữ liệu).
Để hình dung, hãy tưởng tượng bạn viết tất cả các mẫu trong tập huấn luyện lên một tờ giấy dài, sau đó gấp tờ giấy đó thành một số phần bằng nhau. Mỗi lần gấp tạo ra một nếp, và phần vật liệu giữa các nếp được gọi là một fold.
Hãy sử dụng năm fold này để xem vòng lặp diễn ra như thế nào. Lần đầu tiên qua vòng lặp, chúng ta coi các mẫu trong Fold 2 đến Fold 5 là tập huấn luyện tạm thời, và các mẫu trong Fold 1 là tập kiểm tra tạm thời. Nghĩa là, chúng ta huấn luyện bộ phân loại với các mẫu trong Fold 2 đến Fold 5, sau đó đánh giá nó với các mẫu trong Fold 1.
Lần tiếp theo qua vòng lặp, bắt đầu với một bộ phân loại mới được khởi tạo với các số ngẫu nhiên, chúng ta sử dụng các mẫu trong Fold 1, 3, 4, và 5 làm tập huấn luyện tạm thời, và các mẫu trong Fold 2 làm tập kiểm tra tạm thời. Chúng ta huấn luyện và kiểm tra như thường lệ với hai tập này, và tiếp tục với các fold còn lại.
This entry is part 3 of 8 in the series SWE Học A.I
Xác suất
Xác suất thể hiện mức độ tin tưởng rằng một sự kiện sẽ xảy ra, thường được biểu thị dưới dạng phần trăm. Một số câu hỏi có thể cần câu trả lời bằng xác suất:
Khả năng tung được 7 lần mặt sấp trong 10 lần tung đồng xu công bằng là bao nhiêu?
Nếu rút một lá bài thì khả năng nhận được một lá Át (A) là bao nhiêu?
Cách phổ biến nhất để biểu thị xác suất là dưới dạng phần trăm, ví dụ: “Có 70% khả năng chuyến bay Vietjet sẽ bị trễ.”
Gọi xác suất này là [latex]P(X)[/latex], trong đó [latex]X[/latex] là sự kiện quan tâm. Tuy nhiên, trong thực tế, thường thấy nó được biểu thị dưới dạng số thập phân (trong trường hợp này là 0.7), và giá trị này phải nằm trong khoảng từ 0.0 đến 1.0.
Khả năng xảy ra (likelihood) tương tự như xác suất.
Có thể phân biệt bằng cách nhận xét xác suất là việc định lượng dự đoán về các sự kiện chưa xảy ra, trong khi khả năng xảy ra là đo lường tần suất của các sự kiện đã xảy ra. Trong thống kê và học máy, chúng ta thường sử dụng khả năng xảy ra – likelihood (dữ liệu từ quá khứ) để dự đoán xác suất (tương lai).
Xác suất của một sự kiện xảy ra phải nằm nghiêm ngặt trong khoảng từ 0% đến 100%, hoặc từ 0.0 đến 1.0. Về mặt logic, điều này có nghĩa là xác suất một sự kiện không xảy ra được tính bằng cách lấy 1.0 trừ đi xác suất của sự kiện đó:
[latex]P(\text{không } X) = 1 – P(X)[/latex]
Nếu xác suất trời mưa hôm nay là 0.3 (30%) → xác suất không mưa là 1 – 0.3 = 0.7 (70%).
Nếu xác suất bạn đến đúng giờ là 90% → xác suất đi trễ là 10%.
Đây là một điểm khác biệt nữa giữa xác suất và khả năng xảy ra. Tổng xác suất của tất cả các kết quả loại trừ lẫn nhau (mutually exclusive outcomes) của một sự kiện (nghĩa là chỉ một kết quả có thể xảy ra, không phải nhiều kết quả cùng lúc) phải bằng 1.0 hoặc 100%. Tuy nhiên, khả năng xảy ra không tuân theo quy tắc này.
Xác suất & Thống kê
Giả sử có một con xúc xắc 6 mặt, nhưng nó không công bằng, với mặt số 4 có xác suất xuất hiện cao hơn. Bạn tung xúc xắc 100 lần và ghi lại kết quả như sau:
Số 1: 15 lần
Số 2: 10 lần
Số 3: 10 lần
Số 4: 40 lần
Số 5: 15 lần
Số 6: 10 lần
Dựa trên dữ liệu này, xác suất thực nghiệm (empirical probability) của việc tung được số 4 là:
Có thể thấy, xác suất là lý thuyết thuần túy về mức độ có khả năng một sự kiện sẽ xảy ra và không cần dữ liệu. Khi dự đoán kết quả của việc tung một con xúc xắc 6 mặt và được số 4. Với tư duy xác suất thuần túy, ta chỉ cần nói rằng xúc xắc có sáu mặt. Giả sử mỗi mặt có khả năng xảy ra như nhau, nên xác suất được số 4 là [latex]\frac{1}{6}[/latex], tức là 16.666%.
Nhưng khi nói về thống kê, có thể thấy thống kê không thể tồn tại nếu không có dữ liệu và sử dụng dữ liệu để khám phá xác suất cũng như cung cấp các công cụ để mô tả dữ liệu. Chúng ta cần tung xúc xắc để thu thập dữ liệu. Nếu chúng ta tung được 30 lần hoặc nhiều hơn, càng nhiều lần càng tốt, chỉ khi đó chúng ta mới có dữ liệu để xác định xác suất được số 4.” Cách tiếp cận này có vẻ ngớ ngẩn nếu giả định xúc xắc công bằng, nhưng nếu xúc xắc không công bằng thì sao? Trong trường hợp đó, thu thập dữ liệu là cách duy nhất để khám phá xác suất tung được số 4.
Xác Suất Kết Hợp (Joint Probabilities)
Giả sử ta có một đồng xu công bằng và một con xúc xắc sáu mặt công bằng. Ta muốn tính xác suất tung được mặt sấp (heads) trên đồng xu và tung được số 6 trên xúc xắc. Đây là hai xác suất riêng biệt của hai sự kiện độc lập, nhưng chúng ta muốn tìm xác suất cả hai sự kiện xảy ra cùng nhau. Đây được gọi là xác suất kết hợp (joint probability).
Với đồng xu có hai mặt, xác suất tung được mặt sấp là [latex]\frac{1}{2}[/latex]. Với xúc xắc sáu mặt, xác suất tung được số 6 là [latex]\frac{1}{6}[/latex]. Nếu hai sự kiện này độc lập (independent, nghĩa là sự kiện này không ảnh hưởng đến sự kiện kia), xác suất kết hợp được tính bằng cách nhân hai xác suất với nhau:
[latex]P(\text{mặt sấp và số 6}) = P(\text{mặt sấp}) \times P(\text{số 6}) = \frac{1}{2} \times \frac{1}{6} = \frac{1}{12}[/latex]
Để hiểu rõ hơn, chúng ta có thể liệt kê tất cả các kết quả có thể xảy ra khi tung đồng xu và xúc xắc.
Đồng xu: S (sấp, heads), N (ngửa, tails)
Xúc xắc: 1, 2, 3, 4, 5, 6
Kết hợp tất cả các khả năng, ta được 12 kết quả:
S1, S2, S3, S4, S5, S6(*), N1, N2, N3, N4, N5, N6
Kết quả mong muốn là S6 (mặt sấp và số 6), được đánh dấu bằng dấu sao (*). Vì chỉ có 1 kết quả mong muốn trong tổng số 12 kết quả có thể, xác suất là [latex]\frac{1}{12}[/latex]. Điều này phù hợp với phép nhân ở trên, được gọi là quy tắc nhân (product rule):
[latex]P(A \text{ AND } B) = P(A) \times P(B) \text{ (nếu } A \text{ và } B \text{ độc lập)}[/latex]
Xác Suất Hợp (Union Probabilities)
Xác suất kết hợp liên quan đến toán tử AND, nhưng nếu chúng ta muốn tính xác suất xảy ra sự kiện A hoặc sự kiện B? Đây được gọi là xác suất hợp (union probability), tương ứng với toán tử OR trong logic.
Trường hợp sự kiện loại trừ lẫn nhau (Mutually Exclusive Events)
Sự kiện loại trừ lẫn nhau là những sự kiện không thể xảy ra đồng thời. Ví dụ, khi tung một xúc xắc, ta không thể đồng thời được số 4 và số 6. Xác suất hợp trong trường hợp này đơn giản là cộng xác suất của từng sự kiện:
[latex]P(\text{số 4 OR số 6}) = P(\text{số 4}) + P(\text{số 6}) = \frac{1}{6} + \frac{1}{6} = \frac{2}{6} = \frac{1}{3}[/latex]
Trường hợp sự kiện không loại trừ lẫn nhau (Non-Mutually Exclusive Events)
Với các sự kiện có thể xảy ra đồng thời, việc tính xác suất hợp phức tạp hơn. Quay lại ví dụ đồng xu và xúc xắc, giả sử ta muốn tính xác suất tung được mặt sấp OR số 6. Liệt kê lại tất cả các kết quả:
S1, S2, S3, S4, S5, S6, N1, N2, N3, N4, N5, N6
Chúng ta quan tâm đến tất cả các kết quả có mặt sấp (S1, S2, S3, S4, S5, S6) hoặc số 6 (S6, N6). Đếm các kết quả thỏa mãn: S1, S2, S3, S4, S5, S6, N6, tổng cộng 7/12.
Kết quả này sai vì S6 đã bị đếm hai lần (trong cả nhóm mặt sấp và nhóm số 6). Để khắc phục, chúng ta sử dụng quy tắc tổng (sum rule):
[latex]P(A \text{ OR } B) = P(A) + P(B) – P(A \text{ AND } B)[/latex]
Áp dụng vào ví dụ:
[latex]P(\text{mặt sấp OR số 6}) = P(\text{mặt sấp}) + P(\text{số 6}) – P(\text{mặt sấp AND số 6}) = \frac{1}{2} + \frac{1}{6} – \frac{1}{12} = \frac{6}{12} + \frac{2}{12} – \frac{1}{12} = \frac{7}{12}[/latex]
Xác Suất Có Điều Kiện và Định lý Bayes (Conditional Probability and Bayes’ Theorem)
Xác suất có điều kiện (conditional probability) là xác suất của sự kiện A xảy ra khi biết rằng sự kiện B đã xảy ra, ký hiệu là [latex]P(A|B)[/latex]. Ví dụ, một nghiên cứu tuyên bố rằng 85% bệnh nhân ung thư uống cà phê. Điều này nghe có vẻ khá đáng lo ngại
Định nghĩa xác suất này là [latex]P(\text{uống cà phê} | \text{ung thư}) = 0.85[/latex]. Nhưng điều chúng ta thực sự quan tâm là xác suất ngược lại: [latex]P(\text{ung thư} | \text{uống cà phê})[/latex]. (Bao nhiêu người uống cafe mắc bệnh ung thư)
Sử dụng Định lý Bayes
Định lý Bayes cho phép “lật ngược” xác suất có điều kiện:
Kết quả cho thấy xác suất một người uống cà phê bị ung thư chỉ là 0.65%, rất thấp so với 85% ban đầu. Điều này minh họa rằng hướng của điều kiện rất quan trọng.
Naive Bayes
Định lý Bayes là nền tảng của thuật toán Naive Bayes, một phương pháp học máy phổ biến để phân loại. Thuật toán này giả định các đặc trưng (features) độc lập với nhau, giúp đơn giản hóa tính toán. Ví dụ, trong phân loại văn bản, Naive Bayes có thể dự đoán một bài đánh giá là tích cực hay tiêu cực dựa trên các từ xuất hiện.
Minh họa đơn giản
Giả sử ta xây dựng một mô hình để phân loại email. Ta có dữ liệu:
60% email là spam.
Từ “miễn phí” xuất hiện trong 50% email spam và 10% email không spam.
Tính xác suất một email chứa từ “miễn phí” là spam:
[latex]P(\text{không spam})[/latex]: Xác suất một email không phải spam (ví dụ: 70% email không spam).
[latex]P(\text{miễn phí} \mid \text{không spam})[/latex]: Xác suất email có từ “miễn phí” nếu nó không spam (ví dụ: 10% email không spam có từ “miễn phí”).
Email chứa từ “miễn phí” có 88.2% khả năng là spam.
Phân phối nhị thức (Binomial Distribution)
Giả sử ta đang phát triển một động cơ mới và đã thực hiện 1 bài kiểm tra với 10 lần thử. Kết quả là 8 lần thành công và 2 lần thất bại:
✓ ✓ ✓ ✓ ✓ ✘ ✓ ✘ ✓ ✓
Ta kỳ vọng động cơ mới có thể đạt tỷ lệ thành công 90%, nhưng dữ liệu cho thấy chỉ đạt 80% (8 lần thành công trong 10 lần thử trong bài kiểm tra). Mỗi bài kiểm tra tốn thời gian và chi phí, nên ta quyết định quay lại bàn thiết kế để cải tiến.
Tuy nhiên, một kỹ sư trong nhóm cho rằng cần thêm bài kiểm tra và lập luận: “Chúng ta chỉ biết chắc khi thử nhiều hơn. Điều gì xảy ra nếu các bài kiểm tra tiếp theo đạt 9 lần thử hoặc 10 lần thử thành công? Ví dụ, nếu tung đồng xu 10 lần và được 8 lần mặt ngửa, điều đó không có nghĩa đồng xu bị ‘cố định’ ở 80% ngửa trong tất cả các lần.”
Ngay cả với đồng xu công bằng, 10 lần tung không phải lúc nào cũng chia đều kết quả. Xác suất có 5 lần mặt ngửa thường xuyên xảy ra, nhưng ta cũng có thể được 3, 4, 6, hoặc 7 lần. Thậm chí 10 lần mặt ngửa cũng có thể xảy ra, dù rất hiếm. Vậy làm thế nào để xác định?
Và ta có phân phối nhị thức, dùng để đo lường khả năng đạt được [latex]k[/latex] lần thành công trong [latex]n[/latex] lần thử với xác suất thành công là [latex]p[/latex].
Ta có hình ảnh [latex]n=10[/latex] lần kiểm tra. Phân phối nhị thức được cài đặt [latex]p=0.9[/latex], hay với mỗi lần kiểm tra, ta có tỉ lệ 90% máy sẽ chạy thành công, và 10% thất bại. (Như kỳ vọng về máy). Và theo biểu đồ, có xác suất đạt 8 lần thành công trong 10 lần là 0,1937 (19,37%).
Phân phối nhị thức là một mô hình xác suất dùng để tính khả năng đạt được đúng [latex]k[/latex] lần thành công trong [latex]n[/latex] lần thử, khi:
Mỗi lần thử độc lập với nhau.
Mỗi lần thử chỉ có hai kết quả: thành công (success) hoặc thất bại (failure) theo [latex]p[/latex] cố định.
[latex]n[/latex]: Số lần thử (trials). Trong ví dụ, [latex]n = 10[/latex] (10 bài kiểm tra).
[latex]k[/latex]: Số lần thành công mong muốn. Ví dụ, [latex]k = 8[/latex] (8 lần thành công).
[latex]p[/latex]: Xác suất thành công mỗi lần thử. Ví dụ, [latex]p = 0.9[/latex] (90%).
[latex]1-p[/latex]: Xác suất thất bại mỗi lần thử, ở đây là [latex]0.1[/latex].
[latex]{n \choose k}[/latex]: Tổ hợp chập [latex]k[/latex] của [latex]n[/latex], tức số cách chọn [latex]k[/latex] lần thành công trong [latex]n[/latex] lần thử, được tính bằng:
[latex]n[/latex] (số lần thử): Quy mô của thí nghiệm. Số lần thử càng lớn, kết quả càng ổn định và gần với [latex]p[/latex].
[latex]k[/latex] (số lần thành công): Số lần mong muốn đạt được kết quả “thành công”. Ví dụ, mong muốn biết xác suất đúng 8 lần thành công.
[latex]p[/latex] (xác suất thành công): Tỷ lệ kỳ vọng của sự kiện thành công. Trong ví dụ, [latex]p=0,9[/latex] là tỷ lệ thành công mong muốn của động cơ.
[latex]1-p[/latex] (xác suất thất bại): Tỷ lệ thất bại, bổ sung cho [latex]p[/latex].
Ta muốn kiểm tra xem việc đạt 8 lần thành công trên 10 lần thử có hợp lý không, nếu giả định rằng động cơ thực sự có xác suất thành công là 90%. Sử dụng phân phối nhị thức, ta tính xác suất đúng 8 lần thành công như sau:
Xác suất đạt đúng 8 lần thành công là 19,37%, không phải quá thấp. Tuy nhiên, để đánh giá rủi ro, ta cần tính xác suất đạt 8 hoặc ít hơn lần thành công:
Điều đó có nghĩa là ngay cả khi tỷ lệ thành công thực sự là 90%, thì vẫn có 26,39% khả năng động cơ chỉ đạt 8 hoặc ít hơn lần thành công trong 10 lần thử. Vì vậy việc thử nghiệm nhiều hơn theo ý ban đầu là hợp lý, chưa thể khẳng định cần cải tiến động cơ ngay chỉ với 10 lần thử.
Phương sai, độ lệch chuẩn và phân phối Chuẩn (Normal Distribution)
Phương sai và Độ lệch chuẩn
Trong thống kê, khi mô tả dữ liệu, chúng ta thường quan tâm đến việc đo lường độ chênh lệch giữa giá trị trung bình (mean) và từng điểm dữ liệu. Điều này giúp chúng ta hiểu dữ liệu phân bố “rải rác” như thế nào.
Ví dụ, giả sử ta muốn nghiên cứu số lượng thú cưng mà nhân viên trong văn phòng của ta sở hữu (đây là tổng thể, không phải mẫu). Văn phòng có 7 nhân viên, và số lượng thú cưng họ sở hữu lần lượt là: [0, 1, 5, 7, 9, 10, 14]. Trung bình số thú cưng là:
Hãy trừ giá trị trung bình này khỏi mỗi điểm dữ liệu để xem mỗi giá trị cách trung bình bao xa:
Thông tin này hữu ích vì nó cho chúng ta cảm nhận về mức độ phân tán của dữ liệu. Tuy nhiên, làm thế nào để tổng hợp các độ chênh lệch này thành một con số duy nhất để mô tả mức độ phân tán?
Một ý tưởng là lấy trung bình của các độ chênh lệch, nhưng các giá trị âm và dương sẽ triệt tiêu lẫn nhau khi cộng lại. Chúng ta có thể lấy giá trị tuyệt đối (loại bỏ dấu âm), nhưng một cách tiếp cận tốt hơn là bình phương các độ chênh lệch trước khi cộng. Bình phương không chỉ loại bỏ giá trị âm (vì bình phương số âm cho kết quả dương), mà còn làm nổi bật các độ chênh lệch lớn hơn và dễ xử lý hơn về mặt toán học (đạo hàm của giá trị tuyệt đối không đơn giản). Sau đó, lấy trung bình của các giá trị bình phương này để được phương sai (variance), một thước đo mức độ phân tán của dữ liệu.
[latex]x_i[/latex] là từng giá trị trong tập dữ liệu.
[latex]n[/latex] là số lượng phần tử.
Phương sai của số thú cưng là khoảng 21.39. Nhưng con số này có ý nghĩa gì? Phương sai cao cho thấy dữ liệu phân tán nhiều, nhưng vì chúng ta đã bình phương các độ chênh lệch, giá trị này không còn cùng đơn vị với dữ liệu gốc (số thú cưng). Để đưa nó về thang đo ban đầu, chúng ta lấy căn bậc hai của phương sai, được gọi là độ lệch chuẩn (standard deviation):
[latex] \sigma = \sqrt{\sigma^2} [/latex]
Độ lệch chuẩn là khoảng 4.62 thú cưng. Điều này có nghĩa là trung bình, số lượng thú cưng của nhân viên dao động khoảng ±4.62 quanh giá trị trung bình 6.571. Độ lệch chuẩn dễ diễn giải hơn vì nó cùng đơn vị với dữ liệu gốc.
Phân phối liên tục
Hầu hết các ví dụ xác suất từ đầu bài đều là biến rời rạc. Ví dụ:
Tung xúc xắc: có đúng 6 kết quả có thể (1, 2, 3, 4, 5, 6)
Tung đồng xu: có đúng 2 kết quả có thể (ngửa, sấp)
Rút bài: có đúng 52 lá bài khác nhau
NNhưng trong thực tế, nhiều thứ không thể đếm được như vậy:
Bạn đến trạm xe bus. Xe sẽ đến sau bao lâu?
2 phút? 2.5 phút? 2.37 phút? 2.371846 phút?
Thời gian có thể là bất kỳ số nào từ 0 đến 15 phút (chu kỳ xe bus)
Không có “danh sách” cụ thể các thời gian có thể như với xúc xắc
Nhiệt độ ở Sài Gòn hôm nay là bao nhiêu?
32°C? 32.1°C? 32.15°C? 32.1543°C?
Nhiệt độ có thể là bất kỳ số nào trong khoảng (ví dụ 25°C đến 38°C)
Bạn có thể đo chính xác đến hàng triệu chữ số thập phân nếu muốn
Tốc độ mạng wifi của bạn bây giờ là bao nhiêu Mbps?
Tốc độ luôn thay đổi và có thể là bất kỳ số nào trong một khoảng
50.2 Mbps? 50.28374 Mbps? 50.283746291 Mbps?
Đặc điểm của Biến Liên tục:
Vô số giá trị có thể: Ngay cả trong khoảng nhỏ như [1, 2], vẫn có vô số số thực
Không thể liệt kê: Không thể viết danh sách tất cả giá trị có thể như với xúc xắc
Độ chính xác tùy ý: Bạn luôn có thể đo chính xác hơn bằng cách thêm chữ số thập phân
Điều quan trọng: Với biến liên tục, xác suất để có chính xác một giá trị cụ thể (như đúng 32.0000000°C) thực tế là 0. Thay vào đó, ta chỉ có thể tính xác suất trong các khoảng (như từ 31.5°C đến 32.5°C).
Thay vì tìm xác suất của một giá trị chính xác, chúng ta chỉ tính xác suất trong các khoảng:
Không tìm xác suất cân nặng chính xác 72.8 kg
Mà tìm xác suất cân nặng từ 72.7 đến 72.9 kg
Hàm mật độ xác suất (PDF)
Hàm mật độ xác suất (PDF) cho chúng ta biết “mật độ” của xác suất tại từng điểm trên đường cong phân phối. Nói cách khác, PDF cho biết một giá trị cụ thể có khả năng xuất hiện “dày đặc” như thế nào.
Hình dung PDF như bản đồ mật độ dân số của một thành phố:
Những khu vực có PDF cao = khu vực đông dân
Những khu vực có PDF thấp = khu vực ít dân
Nhưng để biết có bao nhiêu người sống trong một khu vực cụ thể, ta phải tính diện tích khu vực đó
Tính Xác suất thực tế = Diện tích dưới Đường cong
Để tìm xác suất thực sự, chúng ta cần tính diện tích dưới đường cong PDF:
Xác suất (từ a đến b) = Diện tích dưới đường cong PDF từ a đến b
Ví dụ về cân nặng khi xem xét nhiều cân nặng của chú chó Golden Retriever:
Để tìm xác suất cân nặng từ 62 đến 66 pound
Chúng ta tính diện tích dưới đường cong PDF trong khoảng [62, 66]
Hàm Phân bố Tích lũy (CDF)
Do trục dọc của PDF không phải là xác suất mà là mật độ xác suất. Để tính xác suất, chúng ta cần tích phân một khoảng giá trị [latex]x[/latex] để tìm diện tích dưới đường cong.
Phân phối Chuẩn (Normal Distribution)
Phân phối chuẩn, hay còn gọi là phân phối Gaussian, là một phân phối xác suất hình chuông đối xứng, với phần lớn giá trị tập trung quanh trung bình và độ phân tán được xác định bởi độ lệch chuẩn. Các “đuôi” của phân phối mỏng dần khi xa trung bình.
Phân phối chuẩn là phân phối hình chuông kinh điển, được xác định hoàn toàn bởi hai tham số: trung bình [latex]\mu[/latex] (mean) và độ lệch chuẩn [latex]\sigma[/latex] (standard deviation). Trung bình cho biết tâm của đường cong chuông nằm ở đâu, còn độ lệch chuẩn biểu thị độ “rộng” của nó.
Ví dụ, hãy xem xét cân nặng của giống chó Golden Retriever. Giả sử trung bình cân nặng là 64.43 pound và độ lệch chuẩn là 2.99 pound
Giả sử chúng ta lấy mẫu cân nặng của 50 con Golden Retriever trưởng thành và vẽ chúng trên trục số
Chúng ta nhận thấy các giá trị tập trung gần trung bình, và càng xa trung bình thì càng ít giá trị. Để hình dung rõ hơn, chúng ta có thể tạo một biểu đồ tần suất (histogram), chia các giá trị vào các “thùng” (bin) có độ dài bằng nhau. chúng ta thử chia thùng với độ dài 0.5 pound. (Ví dụ 57.4 – 57.9 gộp thành chung 1 bin)
Biểu đồ này không cho thấy hình dạng rõ ràng vì các thùng quá nhỏ và mẫu không đủ lớn. Hãy thử tăng kích thước thùng lên 3 pound
Bây giờ, chúng ta thấy một hình chuông rõ ràng. Cho thấy mẫu có khả năng tuân theo phân phối chuẩn. Nếu điều chỉnh kích thước thùng phù hợp và chuẩn hóa để tổng diện tích bằng 1 (yêu cầu của phân phối xác suất), chúng ta sẽ có một đường cong chuông gần đúng, như trong hình dưới:
Đặc điểm của Phân phối Chuẩn
Phân phối chuẩn có các đặc điểm quan trọng sau:
Tính đối xứng: Hai bên đối xứng quanh trung bình.
Tập trung quanh trung bình: Phần lớn giá trị nằm gần trung bình.
Độ phân tán: Được xác định bởi độ lệch chuẩn.
Đuôi mỏng dần: Xác suất giảm dần khi xa trung bình, nhưng không bao giờ chạm 0.
Hàm mật độ xác suất (PDF) của phân phối chuẩn
Hàm mật độ xác suất cho phân phối chuẩn trông như sau:
Ví dụ, để tìm xác suất một con Golden Retriever có cân nặng từ 62 đến 66 pound, chúng ta cần tính diện tích dưới đường cong trong khoảng này
Hàm CDF, với hình dạng cong chữ S (gọi là đường cong sigmoid), biểu thị diện tích dưới đường cong PDF cho đến một giá trị x nhất định
Khi tính diện tích từ âm vô cực đến giá trị trung bình 64.43, hàm CDF cho kết quả chính xác là 0.5, tương ứng với 50%! – Tương ứng xác suất 50% một chú chó Golden Retriever có cân nặng rơi vào một nửa bên trái [- âm vô cực, 64.43]
Tính hàm CDF cho phân bố chuẩn trong Python
Python
from scipy.stats import normmean =64.43# giá trị trung bìnhstd_dev =2.99# độ lệch chuẩnx = norm.cdf(64.43, mean, std_dev)print(x)# in ra 0.5
Ta có thể tính diện tích của một khoảng giữa bằng cách trừ hai giá trị diện tích. Nếu muốn tìm xác suất quan sát được một chú chó Golden Retriever có cân nặng từ 62 đến 66 pound, ta tính diện tích đến 66 và trừ đi diện tích đến 62.
Python
from scipy.stats import normmean =64.43std_dev =2.99x = norm.cdf(66, mean, std_dev)- norm.cdf(62, mean, std_dev)print(x)# in ra 0.4920450147062894
Hàm CDF nghịch đảo (Inverse CDF)
Từ hàm CDF, ta có thể tính xác suất một chú chó Golden Retriever có cân nặng từ khoảng [a,b] là 40% hay x. Ví dụ, đôi lúc ta muốn trả lời các câu hỏi như:
Ta muốn tìm cân nặng mà 95% chó Golden Retriever nằm dưới mức đó.
Python
from scipy.stats import normx = norm.ppf(.95,loc=64.43,scale=2.99)print(x)# 69.3481123445849
Điểm Z (Z-Scores)
Việc chuẩn hóa một phân bố chuẩn sao cho giá trị trung bình bằng 0 và độ lệch chuẩn bằng 1, gọi là phân bố chuẩn tắc (standard normal distribution), là rất phổ biến. Điều này giúp dễ dàng so sánh độ phân tán của một phân bố chuẩn với phân bố chuẩn khác, ngay cả khi chúng có giá trị trung bình và phương sai khác nhau.
Điều đặc biệt quan trọng với phân bố chuẩn tắc là nó biểu diễn tất cả giá trị x dưới dạng số độ lệch chuẩn, gọi là điểm Z (Z-scores). Việc chuyển một giá trị x thành điểm Z sử dụng công thức chuẩn hóa cơ bản:
[latex]z = \frac{x – \mu}{\sigma} [/latex]
Ví dụ: Ta có hai ngôi nhà từ hai khu vực khác nhau. Khu A có giá trị trung bình của nhà là 140,000 USD và độ lệch chuẩn 3,000 USD. Khu B có giá trị trung bình 800,000 USD và độ lệch chuẩn 10,000 USD.
Bây giờ, ta có hai ngôi nhà: Nhà A từ khu A trị giá 150,000 USD và nhà B từ khu B trị giá 815,000 USD. Ngôi nhà nào đắt hơn so với giá trung bình của khu vực của nó?
Nếu biểu diễn hai giá trị này dưới dạng số độ lệch chuẩn, ta có thể so sánh chúng so với giá trị trung bình của khu vực. Sử dụng công thức điểm Z:
Như vậy, nhà ở khu A thực sự đắt hơn nhiều so với khu vực của nó so với nhà ở khu B, vì chúng có điểm Z lần lượt là 3.333 và 1.5.
Dưới đây là cách chuyển đổi giá trị x từ một phân bố với trung bình và độ lệch chuẩn cho trước thành điểm Z và ngược lại.
Python
defz_score(x,mean,std):return(x - mean)/ stddefz_to_x(z,mean,std):return(z * std)+ meanmean =140000std_dev =3000x =150000# Chuyển thành điểm Z và ngược lạiz =z_score(x, mean, std_dev)back_to_x =z_to_x(z, mean, std_dev)print("Z-Score: {}".format(z))# Z-Score: 3.3333333333333335print("Back to X: {}".format(back_to_x))# Back to X: 150000.0
Hệ số biến thiên (Coefficient of Variation)
Một công cụ hữu ích để đo độ phân tán là hệ số biến thiên (coefficient of variation). Nó so sánh hai phân bố và định lượng mức độ phân tán của mỗi phân bố. Công thức đơn giản: chia độ lệch chuẩn cho giá trị trung bình.
Như vậy, khu A, dù rẻ hơn khu B, có độ phân tán cao hơn, nghĩa là giá nhà ở khu A đa dạng hơn khu B.
Định Lý Giới Hạn Trung Tâm (Central Limit Theorem)
Phân phối chuẩn (normal distribution) hữu ích vì nó xuất hiện rất nhiều trong tự nhiên, chẳng hạn như cân nặng của giống chó Golden Retriever trưởng thành. Tuy nhiên, điều thú vị hơn là phân phối chuẩn còn xuất hiện trong các bối cảnh không liên quan đến tổng thể tự nhiên. Khi chúng ta lấy mẫu đủ lớn từ một tổng thể, ngay cả khi tổng thể đó không tuân theo phân phối chuẩn, phân phối chuẩn vẫn sẽ xuất hiện.
Hãy tưởng tượng ta đang đo lường một tổng thể hoàn toàn ngẫu nhiên và đồng nhất (uniformly random), nơi mọi giá trị từ 0.0 đến 1.0 đều có khả năng xảy ra như nhau, không có giá trị nào được ưu tiên. Điều kỳ diệu xảy ra khi chúng ta lấy các mẫu lớn dần từ tổng thể này, tính trung bình của mỗi mẫu, và vẽ chúng thành biểu đồ histogram:
Python
# Các mẫu từ phân phối đồng nhất sẽ có trung bình tạo thành phân phối chuẩn.import randomimport plotly.express as pxsample_size =31sample_count =1000# Định lý giới hạn trung tâm, 1000 mẫu, mỗi mẫu chứa 31 số ngẫu nhiên từ 0.0 đến 1.0x_values =[(sum([random.uniform(0.0,1.0)for i inrange(sample_size)])/ sample_size)for _ inrange(sample_count)]y_values =[1for _ inrange(sample_count)]px.histogram(x=x_values,y=y_values,nbins=20).show()
Tại sao các số ngẫu nhiên đồng nhất, khi được lấy mẫu theo nhóm 31 và tính trung bình, lại tạo ra một phân phối gần giống phân phối chuẩn? Chẳng phải mọi số đều có khả năng xảy ra như nhau, và phân phối phải phẳng (flat) thay vì hình chuông (bell-curved) sao?
Đây chính là sự khác biệt giữa biến ngẫu nhiên đơn lẻ và thống kê của tập hợp biến ngẫu nhiên.
Giải thích hiện tượng: Các số riêng lẻ trong mẫu không tạo ra phân phối chuẩn; chúng tạo ra phân phối đồng nhất (uniform distribution), nơi mọi giá trị đều có xác suất như nhau. Tuy nhiên, khi chúng ta nhóm các số này thành mẫu và tính trung bình, trung bình của các mẫu này sẽ tạo ra một phân phối chuẩn.
A) Nguyên lý tổ hợp (Combinatorial Principle)
Khi lấy mẫu n số từ phân phối đồng nhất [0,1], có vô số cách để tạo ra trung bình ≈ 0.5
Chỉ có rất ít cách để tạo ra trung bình cực trị (gần 0 hoặc gần 1)
Ví dụ: Để có trung bình = 0.1 với 31 số, hầu hết các số phải rất nhỏ (xác suất thấp)
Để có trung bình = 0.5, các số có thể phân bố đa dạng (xác suất cao)
B) Quy luật số lớn (Law of Large Numbers)
Khi kích thước mẫu tăng, trung bình mẫu hội tụ về kỳ vọng của tổng thể
Với phân phối đồng nhất [0,1]: E(X) = 0.5
Độ biến thiên của trung bình giảm theo tỷ lệ 1/√n
Đây chính là định lý giới hạn trung tâm, khẳng định rằng những điều thú vị xảy ra khi chúng ta lấy mẫu đủ lớn từ một tổng thể, tính trung bình của mỗi mẫu, và vẽ chúng thành phân phối:
Trung bình của các trung bình mẫu bằng trung bình tổng thể.
Nếu tổng thể tuân theo phân phối chuẩn, thì trung bình mẫu cũng sẽ tuân theo phân phối chuẩn.
Nếu tổng thể không tuân theo phân phối chuẩn, nhưng kích thước mẫu lớn hơn 30, trung bình mẫu vẫn sẽ gần giống phân phối chuẩn.
Độ lệch chuẩn của trung bình mẫu bằng độ lệch chuẩn tổng thể chia cho căn bậc hai của kích thước mẫu ([latex]\frac{\sigma}{\sqrt{n}}[/latex])
Những đặc tính này cho phép chúng ta suy ra các thông tin hữu ích về tổng thể dựa trên mẫu, ngay cả khi tổng thể không tuân theo phân phối chuẩn. Nếu bạn chỉnh sửa mã trên và thử với kích thước mẫu nhỏ như 1 hoặc 2, bạn sẽ không thấy phân phối chuẩn xuất hiện. Nhưng khi kích thước mẫu đạt 31 trở lên, phân phối sẽ dần hội tụ về phân phối chuẩn:
Số 31 là con số tiêu chuẩn trong thống kê vì đây thường là điểm mà phân phối mẫu hội tụ về phân phối tổng thể, đặc biệt khi đo lường trung bình mẫu hoặc các tham số khác. Khi mẫu có ít hơn 31 phần tử, ta có thể sử dụng phân phối T (T-distribution) thay vì phân phối chuẩn, vì phân phối T có đuôi dày hơn (fatter tails) khi kích thước mẫu nhỏ, phản ánh sự bất định lớn hơn.
Khoảng Tin Cậy (Confidence Intervals)
Khoảng tin cậy là một phép tính phạm vi cho thấy chúng ta tin tưởng bao nhiêu phần trăm rằng trung bình mẫu (hoặc tham số khác) nằm trong một phạm vi của trung bình tổng thể.
Ví dụ: Dựa trên mẫu gồm 31 con chó Golden Retriever với trung bình mẫu là 64.408 và độ lệch chuẩn mẫu là 2.05, ta tin tưởng 95% rằng trung bình tổng thể nằm trong khoảng từ 63.686 đến 65.1296. Làm thế nào ta biết được điều này?
Bước 1: Chọn mức tin cậy (Level of Confidence – LOC)
Ta muốn tin tưởng 95% rằng trung bình mẫu nằm trong phạm vi trung bình tổng thể mà ta sẽ tính toán. Đây là mức tin cậy. Chúng ta có thể tận dụng định lý giới hạn trung tâm để suy ra phạm vi này. Trước tiên, ta cần giá trị z tới hạn (critical z-value), tức là phạm vi đối xứng trong phân phối chuẩn đơn vị (standard normal distribution) chứa 95% xác suất ở trung tâm
Chúng ta sử dụng hàm CDF ngược (inverse CDF). Để có 95% diện tích đối xứng ở trung tâm, chúng ta loại bỏ 5% diện tích ở hai đuôi. Chia đôi 5% này, mỗi đuôi sẽ chứa 2.5% diện tích. Do đó, các giá trị diện tích cần tra cứu là 0.025 và 0.975
Chúng ta tra cứu giá trị x cho diện tích 0.025 và 0.975, từ đó xác định phạm vi trung tâm chứa 95% diện tích. Giá trị z dưới và trên sẽ đối xứng nhau
Kết quả là ±1.95996, tức giá trị z tới hạn bao quát 95% xác suất ở trung tâm của phân phối chuẩn đơn vị. Tiếp theo, ta sử dụng định lý giới hạn trung tâm để tính sai số biên (margin of error – E), tức là phạm vi quanh trung bình mẫu chứa trung bình tổng thể ở mức tin cậy đó. Với mẫu 31 con Golden Retriever có trung bình 64.408 và độ lệch chuẩn 2.05, công thức tính sai số biên là:
[latex]E = z \cdot \frac{s}{\sqrt{n}}[/latex]
Áp dụng sai số biên này vào trung bình mẫu, chúng ta sẽ có khoảng tin cậy.
Python
from math import sqrtfrom scipy.stats import normdefcritical_z_value(p): norm_dist =norm(loc=0.0,scale=1.0) left_tail_area =(1.0- p)/2.0 upper_area =1.0-((1.0- p)/2.0)return norm_dist.ppf(left_tail_area), norm_dist.ppf(upper_area)defconfidence_interval(p,sample_mean,sample_std,n):# Kích thước mẫu phải lớn hơn 30 lower, upper =critical_z_value(p) lower_ci = lower *(sample_std /sqrt(n)) upper_ci = upper *(sample_std /sqrt(n))return sample_mean - lower_ci, sample_mean + upper_ciprint(confidence_interval(p=.95,sample_mean=64.408,sample_std=2.05,n=31))# (63.68635915701992, 65.12964084298008)
Cách diễn giải: Dựa trên mẫu 31 con Golden Retriever với trung bình mẫu 64.408 và độ lệch chuẩn mẫu 2.05, ta tin tưởng 95% rằng trung bình tổng thể nằm trong khoảng từ 63.686 đến 65.1296. Đây là khoảng tin cậy của chúng ta.
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ụ:
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]
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à:
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à:
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]
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:
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:
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ố
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:
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:
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)
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.
![[HTTP/2] Phần 2: Tìm hiểu thêm Server Push](https://quochung.cyou/wp-content/uploads/2025/08/image-24.png "[HTTP/2] Phần 2: Tìm hiểu thêm Server Push 28")
![[HTTP/2] Phần 1: Tìm hiểu hành trình đi lên HTTP/2](https://quochung.cyou/wp-content/uploads/2025/08/image-3.png "[HTTP/2] Phần 1: Tìm hiểu hành trình đi lên HTTP/2 37")
![[SWE học A.I] Phần 8: Model Training & Evaluation](https://quochung.cyou/wp-content/uploads/2025/06/image-18.png "[SWE học A.I] Phần 8: Model Training & Evaluation 56")
![[SWE học A.I] Phần 3: Một số khái niệm suất thống kê](https://quochung.cyou/wp-content/uploads/2025/06/image-44.png "[SWE học A.I] Phần 3: Một số khái niệm suất thống kê 70")
![[SWE học A.I] Phần 2: Một số khái niệm toán học](https://quochung.cyou/wp-content/uploads/2025/06/image.png "[SWE học A.I] Phần 2: Một số khái niệm toán học 91")
![[SWE học A.I] Phần 1: Sơ lược tiếp cận các mô hình A.I](https://quochung.cyou/wp-content/uploads/2025/05/image-14.png "[SWE học A.I] Phần 1: Sơ lược tiếp cận các mô hình A.I 112")
