Mở đầu — vì sao bài này quan trọng
Bạn đang đứng giữa hai thái cực. Một bên là kỹ sư ML nói về "self-attention", "positional encoding", "multi-head" như thể đó là chuyện hiển nhiên. Một bên là sếp hoặc khách hàng hỏi bạn — một AI Product Manager — những câu rất đời thường: "Tại sao model lại chậm khi văn bản dài?", "Tại sao chi phí tăng theo cấp số nhân khi tôi nhồi nhiều dữ liệu vào prompt?", "Liệu mình có thể tăng gấp đôi độ dài tài liệu mà giá không đổi không?". Nếu bạn không hiểu kiến trúc Transformer ở mức đủ sâu, bạn sẽ không trả lời được, và tệ hơn, bạn sẽ ra những quyết định sản phẩm sai lầm về chi phí, độ trễ và giới hạn tính năng.
Bài này KHÔNG biến bạn thành kỹ sư huấn luyện model. Mục tiêu là cho bạn một "mô hình tư duy" (mental model) đúng về cách Transformer hoạt động, đủ để bạn dự đoán hành vi của sản phẩm AI, giải thích cho stakeholder, và đưa ra đánh đổi kỹ thuật hợp lý. Transformer là nền tảng của gần như mọi LLM bạn đang dùng — GPT, Claude, Gemini, Llama, và cả các model Việt như PhoGPT, Vistral. Hiểu nó là hiểu "luật vật lý" của thế giới mà sản phẩm bạn đang sống trong đó.
Một lưu ý phạm vi: bài này chỉ tập trung vào kiến trúc Transformer cơ bản. Các chủ đề như danh sách foundation models cụ thể, prompt engineering, hay quản lý context window sẽ nằm ở những bài sau. Ở đây ta chỉ xây nền móng cơ chế.
Khái niệm cốt lõi
Vì sao Transformer ra đời
Năm 2017, nhóm nghiên cứu của Google công bố bài báo huyền thoại "Attention Is All You Need". Trước đó, để xử lý chuỗi (sequence) như câu văn, người ta dùng RNN và LSTM — những mạng đọc từ trái sang phải, từng từ một, ghi nhớ trạng thái khi đi qua. Vấn đề lớn của cách này có hai mặt.
Thứ nhất, xử lý tuần tự không song song hóa được. Muốn hiểu từ thứ 100, bạn phải đi qua 99 từ trước đó theo đúng thứ tự. Trên GPU — vốn mạnh ở việc tính song song hàng nghìn phép cùng lúc — điều này lãng phí khủng khiếp. Huấn luyện chậm, tốn kém.
Thứ hai, trí nhớ dài hạn kém. Khi câu dài ra, thông tin từ đầu câu bị "loãng" dần qua từng bước, model quên mất ngữ cảnh xa. Đại từ "nó" ở cuối đoạn khó nối được với danh từ ở đầu đoạn.
Transformer giải quyết cả hai cùng lúc bằng một ý tưởng táo bạo: bỏ hẳn việc đọc tuần tự, thay bằng cơ chế attention cho phép mọi từ "nhìn thẳng" vào mọi từ khác trong một bước, và làm việc đó song song. Đó là lý do cái tên bài báo nói thẳng: chỉ cần attention là đủ.
Attention — trái tim của Transformer
Hãy hình dung bạn đọc câu: "Con mèo không qua đường vì nó quá mệt." Từ "nó" chỉ con mèo. Não bạn tự động nối "nó" với "mèo". Attention chính là cơ chế toán học mô phỏng việc nối này.
Mỗi từ được biến thành ba vector: Query (tôi đang tìm gì), Key (tôi chứa thông tin gì) và Value (nội dung thực tế của tôi). Để biết từ "nó" nên chú ý đến từ nào, model lấy Query của "nó" so khớp với Key của tất cả các từ khác. Từ nào khớp cao thì được "trọng số chú ý" lớn, và model gom Value của các từ theo trọng số đó. Kết quả: biểu diễn của "nó" được làm giàu bằng thông tin từ "mèo".
Điểm mấu chốt cho PM: mỗi từ phải so khớp với mọi từ khác. Nếu câu có n từ (token), số phép so khớp tỉ lệ với n × n, tức n². Đây là nguồn gốc của hầu hết mọi giới hạn chi phí và tốc độ mà bạn sẽ gặp. Văn bản dài gấp đôi thì lượng tính toán attention tăng gấp bốn. Hãy khắc cốt con số n² này.
Multi-head Attention — nhìn nhiều góc cùng lúc
Model không chỉ chú ý theo một kiểu. Nó chạy nhiều "đầu" (head) attention song song. Một head có thể học mối quan hệ ngữ pháp (chủ ngữ — động từ), head khác học quan hệ ngữ nghĩa, head khác lại theo dõi đại từ. Giống như có nhiều chuyên gia cùng đọc một câu, mỗi người soi một khía cạnh, rồi tổng hợp lại. Đó là "multi-head".
Positional Encoding — vì attention không biết thứ tự
Vì attention nhìn mọi từ cùng lúc chứ không đọc tuần tự, model mất khái niệm về thứ tự. "Mèo đuổi chuột" và "chuột đuổi mèo" sẽ giống nhau nếu không có gì đánh dấu vị trí. Transformer thêm positional encoding — một tín hiệu vị trí gắn vào từng từ — để model biết từ nào đứng trước, từ nào đứng sau. Đây cũng là một trong những yếu tố quyết định độ dài tối đa mà model xử lý được.
Stack nhiều lớp và Feed-Forward
Một khối Transformer gồm attention cộng thêm một mạng feed-forward (xử lý từng từ độc lập để "suy nghĩ" thêm). Người ta xếp chồng hàng chục, hàng trăm khối như vậy. Lớp dưới học đặc trưng đơn giản (ngữ pháp, cú pháp), lớp trên học khái niệm trừu tượng (ý định, lập luận). Số lớp và độ rộng mỗi lớp quyết định "số tham số" — con số tỉ (billion) mà bạn thấy trong tên model, ví dụ Llama 70B nghĩa là 70 tỉ tham số.
Token — đơn vị model thực sự "nhìn"
Model không đọc chữ, nó đọc token — những mảnh từ. "Việt Nam" có thể là một token, nhưng một từ hiếm có thể bị cắt thành nhiều token. Mọi thứ về chi phí, độ dài, tốc độ đều đo bằng token, không phải bằng chữ. Tiếng Việt với dấu thường tốn nhiều token hơn tiếng Anh cho cùng một ý — đây là điều cực kỳ quan trọng với sản phẩm phục vụ người Việt, ta sẽ thấy ở phần ví dụ.
Tình huống thực tế
Ví dụ 1: Startup legal-tech Việt và bài toán n²
Một startup giả định ở TP.HCM, gọi là LuatAI, xây trợ lý đọc hợp đồng. Phiên bản đầu, họ nhồi cả hợp đồng 40 trang vào một prompt để model trả lời câu hỏi. Khi demo với khách doanh nghiệp, mọi thứ chạy mượt với hợp đồng ngắn. Nhưng khi khách dán hợp đồng dài thật, độ trễ nhảy từ 3 giây lên hơn 20 giây, và hóa đơn API tháng đó tăng gấp gần bốn lần dù số lượng câu hỏi không đổi nhiều.
Diễn giải: đội kỹ thuật ban đầu nghĩ chi phí tăng tuyến tính theo độ dài. Nhưng vì attention có độ phức tạp n², văn bản dài gấp đôi khiến phần xử lý attention nặng gấp bốn. Hợp đồng 40 trang tiếng Việt còn tốn token gấp rưỡi so với cùng nội dung tiếng Anh vì cách tách token. Họ đã định giá gói dịch vụ theo "số câu hỏi" mà quên rằng chi phí thực gắn với "số token đầu vào bình phương".
Bài học rút ra: là PM, khi nghe "cho cả tài liệu vào prompt", bạn phải bật đèn đỏ n² trong đầu. Giải pháp không phải là nhồi nhiều hơn, mà là chỉ đưa phần liên quan vào — đây chính là động lực dẫn tới RAG ở các bài sau. Và mô hình định giá phải gắn với token, không gắn với "lượt hỏi".
Ví dụ 2: Sàn TMĐT Đông Nam Á và chuyện song song hóa
Một sàn thương mại điện tử khu vực — hình dung quy mô như Tiki hay Shopee — cần phân loại 2 triệu đánh giá sản phẩm mỗi đêm thành tích cực/tiêu cực/trung tính. Đội data thử nghiệm hai hướng: một model RNN cũ họ còn giữ, và một model nền Transformer.
Khi chạy thực tế, model Transformer xử lý xong batch trong khoảng một phần ba thời gian, dù số tham số lớn hơn. Lý do nằm đúng ở kiến trúc: RNN phải đọc từng đánh giá theo thứ tự token, không tận dụng được GPU; Transformer xử lý toàn bộ token của một đánh giá song song, nên "vắt kiệt" được GPU.
Bài học rút ra: ưu thế song song hóa của Transformer không chỉ là chuyện học thuật — nó trực tiếp biến thành thời gian chạy job ngắn hơn và chi phí hạ tầng thấp hơn cho các tác vụ xử lý hàng loạt. Khi một PM cân nhắc kiến trúc cho pipeline offline quy mô lớn, đặc tính này là một lập luận tài chính, không chỉ kỹ thuật.
Ví dụ 3: Trợ lý chăm sóc khách hàng và giới hạn độ dài
Một ngân hàng số tại Việt Nam triển khai chatbot hỗ trợ. Ban đầu mọi thứ ổn, nhưng khi cuộc hội thoại kéo dài, hoặc khi họ cố nhồi toàn bộ lịch sử giao dịch của khách vào ngữ cảnh, model bắt đầu "quên" thông tin ở đầu cuộc trò chuyện hoặc báo lỗi vượt giới hạn.
Diễn giải: mỗi model Transformer có một độ dài tối đa cho phép, gắn với positional encoding và chi phí n². Đây không phải lỗi cấu hình mà là ràng buộc kiến trúc. Đội sản phẩm tưởng "cứ thêm dữ liệu là model thông minh hơn", nhưng vượt ngưỡng thì hoặc tốn kém phi lý, hoặc đơn giản là không nhét vừa.
Bài học rút ra: PM cần thiết kế luồng để tóm tắt, chọn lọc và quản lý ngữ cảnh thay vì đổ tất cả vào. Hiểu rằng "context có giới hạn vật lý" giúp bạn đặt kỳ vọng đúng với stakeholder và thiết kế tính năng khả thi.
Hướng dẫn từng bước
Đây là quy trình để bạn áp dụng hiểu biết Transformer vào quyết định sản phẩm thực tế.
Bước 1 — Quy mọi thứ về token. Trước khi ước lượng chi phí hay tốc độ bất kỳ tính năng AI nào, hãy dịch yêu cầu sang token: prompt dài bao nhiêu token, đầu ra bao nhiêu token. Nhớ tiếng Việt tốn token hơn tiếng Anh. Đây là đơn vị tiền tệ thật của thế giới Transformer.
Bước 2 — Áp luật n² để dự báo chi phí và độ trễ. Khi ai đó muốn tăng độ dài đầu vào, đừng giả định tuyến tính. Hỏi: nếu input dài gấp đôi, phần attention sẽ nặng gấp bốn — sản phẩm còn chịu nổi về tốc độ và giá không?
Bước 3 — Xác định ràng buộc độ dài tối đa. Mỗi model có giới hạn context. Liệt kê ra trường hợp xấu nhất (hội thoại dài nhất, tài liệu lớn nhất) và kiểm tra có vượt ngưỡng không. Nếu có, thiết kế cơ chế chọn lọc/tóm tắt ngay từ đầu.
Bước 4 — Quyết định đưa gì vào ngữ cảnh. Vì attention nhìn mọi token, mỗi token thừa đều tốn tiền và làm loãng sự chú ý. Nguyên tắc: chỉ đưa thông tin liên quan, không nhồi cho "an toàn".
Bước 5 — Diễn giải lại cho stakeholder bằng ngôn ngữ kinh doanh. Dịch "n²" thành "chi phí tăng theo bình phương độ dài", dịch "context limit" thành "có trần dữ liệu mỗi lượt". Đây là kỹ năng cầu nối quý giá nhất của một AI PM.
Lỗi thường gặp & mẹo
Lỗi: Tưởng chi phí tăng tuyến tính theo độ dài. Phần attention là n². Văn bản dài gấp đôi, chi phí và độ trễ attention gấp bốn. Mẹo: luôn nghĩ "bình phương" khi bàn về độ dài input.
Lỗi: Đếm bằng chữ thay vì token. Báo giá và giới hạn đều theo token. Mẹo: dùng công cụ đếm token của nhà cung cấp, và nhớ nhân hệ số cho tiếng Việt khi ước lượng nhanh.
Lỗi: Cho rằng nhồi nhiều dữ liệu thì model thông minh hơn. Quá nhiều token thừa làm loãng attention, tăng chi phí, và có thể vượt context. Mẹo: chất lượng ngữ cảnh quan trọng hơn số lượng.
Lỗi: Nhầm "số tham số lớn" với "luôn tốt hơn". Tham số nhiều thường mạnh hơn nhưng cũng chậm và đắt hơn. Mẹo: chọn kích thước model theo bài toán, không theo cảm giác.
Lỗi: Quên rằng model không có thứ tự bẩm sinh. Thứ tự đến từ positional encoding, và nó gắn với giới hạn độ dài. Mẹo: hiểu điều này để không kỳ vọng model xử lý chuỗi dài vô hạn.
Mẹo vàng: Khi bí, hãy quy mọi câu hỏi kỹ thuật về ba trục: token (đơn vị), n² (chi phí attention theo độ dài), và context limit (trần độ dài). Ba trục này giải thích được phần lớn hành vi chi phí–tốc độ–giới hạn của mọi sản phẩm LLM.
Bài tập thực hành
Bài 1 — Dự báo n². Một tính năng hiện xử lý prompt 1.000 token, mất 2 giây, tốn X đồng mỗi lượt cho phần attention. Sếp muốn tăng lên 4.000 token. Hãy ước lượng phần attention sẽ nặng lên khoảng bao nhiêu lần và giải thích vì sao, rồi viết một câu giải thích cho sếp bằng ngôn ngữ kinh doanh.
Bài 2 — Token tiếng Việt. Lấy một đoạn mô tả sản phẩm khoảng 100 chữ tiếng Việt và bản dịch tiếng Anh tương đương. Dùng một công cụ đếm token bất kỳ của nhà cung cấp LLM để đo. Ghi lại chênh lệch và rút ra ý nghĩa cho việc định giá sản phẩm phục vụ người Việt.
Bài 3 — Thiết kế trước giới hạn context. Cho chatbot ngân hàng ở Ví dụ 3, hãy phác thảo ba cơ chế giúp cuộc hội thoại dài không vượt context (gợi ý: tóm tắt định kỳ, chỉ giữ phần liên quan, loại bỏ thông tin cũ). Với mỗi cơ chế, nêu một đánh đổi.
Bài 4 — Giải thích cho người không kỹ thuật. Viết một đoạn 5–7 câu giải thích "attention" cho một giám đốc kinh doanh, không dùng công thức, chỉ dùng ẩn dụ đời thường. Mục tiêu là khiến họ hiểu vì sao văn bản dài lại đắt.
Tóm tắt
Transformer, ra đời từ bài báo "Attention Is All You Need" của Google năm 2017, thay thế RNN/LSTM nhờ hai ưu thế: xử lý song song được trên GPU và nắm bắt quan hệ xa tốt hơn. Trái tim của nó là attention — cơ chế cho mỗi token nhìn thẳng vào mọi token khác qua bộ ba Query–Key–Value — chạy nhiều đầu song song (multi-head) và bù lại sự thiếu thứ tự bằng positional encoding. Nhiều khối được xếp chồng, tạo ra hàng tỉ tham số.
Với một AI Product Manager, ba điều cần khắc cốt là: mọi thứ đo bằng token (và tiếng Việt tốn token hơn), chi phí attention tăng theo n² chứ không tuyến tính, và mỗi model có giới hạn context mang tính vật lý. Ba trục này giải thích phần lớn hành vi về chi phí, tốc độ và giới hạn tính năng mà bạn sẽ gặp mỗi ngày. Hiểu chúng, bạn không chỉ ra quyết định sản phẩm đúng hơn mà còn trở thành cầu nối đáng tin giữa đội kỹ thuật và đội kinh doanh — đúng vai trò cốt lõi của nghề.