Đã đăng vào Aug 20th, 4:27 a.m. 91 phút đọc

Máy Dịch Entropy: Đi Tìm Bản Chất Thật Sự Của Generative AI

Lưu ý trước khi đọc: Bài viết này không dành cho tất cả mọi người. Nếu bạn đang tìm kiếm một bài giải thích AI theo kiểu "dễ hiểu cho mọi đối tượng" - đây không phải bài đó. Các tác giả không cố gắng đơn giản hóa thay vào đó chúng tôi cố gắng làm rõ bản chất của vấn đề. Bài viết hướng đến những người đã dùng AI đủ lâu để bắt đầu thấy nó kỳ lạ - những lúc nó làm đúng một cách thần kỳ, và những lúc nó sai một cách khó hiểu.

Mẹo đọc nhanh: Nếu bạn muốn đi thẳng vào phần cốt lõi nhất - bản chất thật sự của Generative AI dưới góc nhìn Entropy - hãy nhảy thẳng đến Phần 3. Hai phần đầu là nền tảng lập luận, nhưng phần 3 mới là trọng tâm!

Mở đầu: Sự Phân Mảnh Trong Nhận Thức Về AI

Kể từ sự bùng nổ của ChatGPT vào cuối năm 2022, Generative AI luôn là tâm điểm của giới công nghệ. Dẫu vậy, nhận thức về bản chất của công nghệ này vẫn có sự phân hóa rõ rệt giữa các nhóm đối tượng khác nhau:

Các nhà nghiên cứu và kỹ sư thường nhìn nhận AI qua lăng kính toán học thuần túy: ma trận trọng số, hàm mất mát và tối ưu hóa phân phối xác suất.
Công chúng và người dùng đại chúng có xu hướng nhân cách hóa AI thành một thực thể thông minh có khả năng "tư duy" và "thấu hiểu".
Cộng đồng lập trình viên thường coi đây là một công cụ hỗ trợ sinh mã và hỗ trợ làm phần mềm (code generation) mạnh mẽ nhưng đôi khi thiếu tính chính xác.

Sự thiếu đồng nhất trong cách tiếp cận này dẫn đến việc đặt kỳ vọng sai lệch và sử dụng công cụ không đúng mục đích. Bài viết này đề xuất một lăng kính phân tích mang tính hệ thống hơn dựa trên Lý thuyết thông tin (Information Theory): coi Generative AI là một hệ thống dịch chuyển entropy (Entropy Translation System). Cách tiếp cận này sẽ giúp giải thích một cách logic cả những khả năng vượt trội lẫn những giới hạn cốt lõi của AI hiện đại.

1. Góc Nhìn I: Ảo Ảnh Nhân Cách Hóa – Kỳ Vọng Sai Lầm Từ Giao Diện Chat

1.1. Câu Chuyện Mà Công Chúng Được Nghe

Khi một công nghệ mới xuất hiện, truyền thông không có thời gian để giải thích cơ chế đứng đằng sau nó. Và thực tế, người dùng đại chúng cũng chẳng mấy quan tâm về điều đó. Bởi vậy, truyền thông kể câu chuyện. Và câu chuyện về AI từ 2022 đến nay có một cốt truyện rất nhất quán: một thực thể thông minh mới đã xuất hiện, và nó có thể làm mọi thứ.

Từ đó, công chúng hình thành một mental model: AI là một "người" siêu thông minh có thể trả lời mọi câu hỏi, viết mọi thứ, lập kế hoạch mọi dự án, và dần dần sẽ thay thế con người trong hầu hết công việc. Đây là một mental model hoàn toàn sai về mặt kỹ thuật — nhưng lại cực kỳ hữu ích về mặt marketing.

Hệ quả là hàng triệu người bắt đầu tương tác với AI như tương tác với một con người: hỏi ý kiến cá nhân, nhờ đưa ra quyết định cuộc đời, thậm chí còn tin tưởng vô điều kiện vào các con số và trích dẫn mà model tạo ra. Để rồi cuối cùng, họ thất vọng khi nó "nói dối" — dù nó chưa bao giờ có khả năng nói thật hay nói dối, vì nó không có khái niệm về sự thật.

Hai câu chuyện điển hình minh họa cho sự nguy hiểm của ảo ảnh này:

Trường hợp 1 — Luật sư và những tiền lệ pháp không có thật (2023): Một luật sư tại New York đã dùng ChatGPT để chuẩn bị hồ sơ tòa án. ChatGPT tự tin trích dẫn hàng loạt tiền lệ pháp lý — tên vụ án, số báo cáo, trích dẫn chi tiết nhưng hoàn toàn không có thật. Tòa án phát hiện ra, luật sư bị phạt 5.000 USD và bị đưa ra trước hội đồng kỷ luật¹. AI không "nói dối" có chủ ý — nó chỉ làm đúng việc nó được huấn luyện: sinh ra chuỗi từ có xác suất cao nhất, và các tiền lệ kia là thứ "nghe có vẻ" giống thật nhất.

Trường hợp 2 — Google Bard sai về kính viễn vọng James Webb (2023): Trong một quảng cáo chính thức, Google Bard — đối thủ của ChatGPT — đã trả lời câu hỏi "kính viễn vọng James Webb chụp được bức ảnh đầu tiên về một hành tinh ngoài hệ Mặt Trời?" với câu trả lời hoàn toàn sai (thực tế đó là ảnh của kính ESO, chụp năm 2004). Lỗi này khiến cổ phiếu Alphabet mất 100 tỷ USD trong một ngày². Một câu trả lời sai, từ một mô hình không hề có khái niệm "đúng" hay "sai" — nhưng hậu quả thì đánh thẳng vào tài chính của doanh nghiệp.

1.2. Ông Thực Tập Sinh Biết Tuốt Nhưng Hay Làm Sai

Trong giới developer, câu chuyện về AI có một biến thể đặc trưng và "đau thương" hơn nhiều. Hãy tưởng tượng công ty bạn mới chào đón một cậu thực tập sinh mới. Cậu ta đã đọc toàn bộ Stack Overflow, tất cả GitHub public repos, mọi tutorial trên internet. Khi bạn hỏi về bất kỳ công nghệ nào, cậu ta đều có câu trả lời — tự tin, lưu loát, đầy đủ. Nhưng khi bạn giao cho cậu ta một bài toán khổng lồ như "đọc toàn bộ codebase, sửa mọi bug và viết tài liệu", thứ trả về là một thảm họa theo đúng nghĩa đen.

Cậu ta tự ý đổi logic của các module cốt lõi để "sửa bug" nhưng lại làm vỡ luồng xác thực mà không hề hay biết. Cậu ta sinh ra một bộ tài liệu cực kỳ trau chuốt, văn phong bay bổng nhưng các tham số và hàm bên trong hoàn toàn do cậu ta tự tưởng tượng ra. Và cậu ta làm tất cả những thứ đó với sự tự tin tuyệt đối, không một lời cảnh báo hay báo trước. Đây chính xác là chân dung của một LLM (Mô hình ngôn ngữ lớn) khi rơi vào tay một developer dùng sai cách.

Cơn ác mộng này không "độc quyền" ở giới tech. Dù bạn là content marketer, nhà thiết kế hay bất kỳ ai, việc dùng AI mà không hiểu bản chất của nó đều dẫn đến kết quả tương tự: một bản kế hoạch dày công nhưng số liệu toàn bịa đặt, một bộ nhận diện thương hiệu đẹp mắt nhưng không hề nhất quán. Sự đổ vỡ này không đến từ năng lực của công nghệ, mà đến từ sự ảo tưởng lẫn kỳ vọng của người dùng. Chính khoảng cách giữa "thực tế những gì AI có thể làm" và "kỳ vọng chúng ta áp đặt lên nó" đã sinh ra những sai lầm kinh điển mà hầu như ai mới bắt đầu cũng đều mắc phải.

1.3. Những Sai Lầm Điển Hình

Khi đối xử với một "thực tập sinh biết tuốt" như một vị cứu tinh toàn năng, người dùng thường rơi vào ba cái bẫy tư duy dưới đây:

Lỗi #1: Prompt một việc lớn, kỳ vọng kết quả hoàn hảo.

Để bạn đọc dễ hình dung, chúng tôi sẽ lấy một ví dụ khởi đầu mang tính đại diện xuyên suốt các góc nhìn: Bạn đưa ra một yêu cầu đầy tham vọng cho AI:

"Hãy đọc toàn bộ codebase của tôi, tìm tất cả các bug, sửa chúng, rồi viết documentation cho toàn bộ project."

Đây không phải là một task. Đây là một ước mơ. Mỗi từ trong câu đó — "tất cả", "toàn bộ", "rồi" — là một tín hiệu cho thấy lượng thông tin và sự hỗn độn ở đầu vào đang quá lớn. Để hiểu rõ hơn tại sao điều này lại dẫn đến thất bại, tác giả sẽ đề cập chi tiết ở phần sau, khi cùng tìm hiểu về khái niệm "Entropy".

Lỗi #2: Sử dụng kết quả mà không kiểm chứng.

Văn phong càng trôi chảy, nguy cơ càng cao. AI sinh ra câu trả lời có vẻ hợp lý nhất — không phải đúng nhất — nên người dùng nhận output và áp dụng ngay mà không rà soát. Hậu quả điển hình: lập trình viên merge code AI "sửa bug" vào nhánh chính mà không chạy unit test, để rồi toàn bộ sụp đổ vì AI đã xóa các hàm xử lý ngoại lệ nhằm làm code "ngắn gọn hơn". Hoặc team documentation xuất bản ngay bộ tài liệu API do AI viết, để rồi cả team gọi sai endpoint vì các tham số hoàn toàn do AI tưởng tượng.

Lỗi #3: Nhầm lẫn giữa "nghe có lý" và "đúng".

Đây là cái bẫy nguy hiểm nhất. AI ưu tiên sự trôi chảy của ngôn ngữ hơn sự thật khách quan — đây là hệ quả trực tiếp từ bản chất dự đoán xác suất của nó (sẽ được phân tích ở Góc nhìn II). Một AI có thể tuôn trào những đoạn diễn giải API cực kỳ chi tiết, đan xen biểu đồ chuỗi chuyên nghiệp, nhưng các hàm và tham số được liệt kê chỉ là sản phẩm của ảo giác. Nó cũng có thể phân tích nguyên nhân gốc rễ của một bug đa luồng bằng thuật ngữ hàn lâm — để rồi người đọc nhận ra phương thức đồng bộ hóa được đề xuất hoàn toàn không tồn tại trong framework.

Cả ba lỗi trên đều chung một gốc rễ: Chúng ta đang đánh giá AI dựa trên vẻ bề ngoài (sự lưu loát) chứ không phải bản chất (cơ chế xử lý thông tin). Để không biến AI thành một cỗ máy phá hoại, chúng ta cần tái định hình lại: Đâu là lằn ranh giữa một kỳ vọng đúng mực và một ảo tưởng tai hại?

1.4. Khi Nào Thì Kỳ Vọng Vào AI Là Đúng?

Trước khi đi sâu vào bản chất kỹ thuật của AI, cần có một câu trả lời thực dụng: kỳ vọng thế nào là hợp lý ngay từ bây giờ, với những gì AI hiện tại có thể làm được tốt?

AI thực sự xuất sắc khi:

Bạn cần sinh một lượng lớn nội dung mẫu — và sẵn sàng kiểm tra sau đó. Draft email, outline bài viết, tạo test data — những việc mà "đúng 80% và sửa sau" nhanh hơn "tự làm từ đầu".
Bạn cần khám phá một lĩnh vực xa lạ. AI có thể cho bạn cái nhìn tổng quan về một chủ đề bạn chưa biết — nhưng hãy kiểm tra lại mọi thông tin từ nguồn chính thống.
Bạn cần một "bộ não thứ hai" để brainstorm. AI không sáng tạo theo nghĩa con người, nhưng nó có thể gợi ý những hướng đi mà bạn chưa nghĩ tới — nhờ vào khả năng kết hợp các pattern từ hàng triệu nguồn khác nhau.

AI thực sự tệ khi:

Yêu cầu sự chính xác tuyệt đối (Không có biên độ sai số): Nếu bạn cần một câu trả lời đúng 100% ngay lập tức mà không có thời gian hoặc năng lực kiểm tra lại, việc dùng AI là một công thức tự sát.
Xử lý tri thức chuyên biệt, nội bộ: AI không biết gì về kiến trúc codebase riêng, quy trình vận hành bảo mật hay những dữ liệu ngầm chưa từng được công bố của tổ chức bạn. Nó sẽ dùng logic của "thiên hạ" để giải bài toán của "riêng bạn" — và đó là lúc lỗi logic xuất hiện.

Nhận ra giới hạn của AI không phải để hạ thấp nó, mà là để đặt nó vào đúng vị trí của một công cụ hỗ trợ đắc lực. Nhưng có bao giờ bạn tự hỏi: Tại sao một hệ thống thông minh đến mức đọc hiểu được cả kho tàng tri thức nhân loại, lại có thể ngớ ngẩn đi bịa ra một tham số không tồn tại? Tại sao nó có thể viết văn hay như một nhà văn nhưng lại làm toán sai như một đứa trẻ tiểu học?

Câu trả lời không nằm ở khía cạnh tâm lý hay hành vi. Để hiểu tại sao AI lại "vừa thông thái vừa khờ khạo" đến thế, chúng ta phải cởi bỏ lớp áo bọc lấp lánh của từ ngữ mang tên "Trí tuệ nhân tạo", để bước vào bản chất thực sự của nó ở chương sau. Nơi không có phép màu, không có tư duy, mà chỉ có những con số.

Chào mừng bạn đến với Góc nhìn II: Lăng Kính Toán Học – Không Có "Phép Màu", Chỉ Có Xác Suất.

2. Góc Nhìn II: Lăng Kính Toán Học – Không Có "Phép Màu", Chỉ Có Xác Suất

2.1. Bên Trong Phòng Thí Nghiệm

Nếu bạn có cơ may hỏi được một researcher tại Google DeepMind hoặc Anthropic rằng "AI là gì?", câu trả lời sẽ không có gì huyền bí. Họ sẽ bảo bạn: đây là một hàm số. Một hàm số rất lớn, rất phức tạp. Về mặt toán học, nó là một phép tính xác suất khổng lồ.

Cụ thể hơn: một Large Language Model (LLM) là một hàm xác suất có điều kiện:

P(token_tiếp_theo | toàn_bộ_ngữ_cảnh_trước_đó)

Nói nôm na: cho tôi xem toàn bộ những gì đã được viết, tôi sẽ cho bạn biết từ tiếp theo có xác suất là gì. Điều đáng chú ý là khi hàm số này đủ lớn, nó không dừng lại ở việc ghi nhớ các cặp từ đi liền nhau: bên trong không gian vector hình thành những cấu trúc biểu diễn có tổ chức — thứ mà giới nghiên cứu gọi là mô hình thế giới (world model).

Đây không chỉ là một cách nói ẩn dụ. Trong một thí nghiệm được trích dẫn nhiều, Li et al. (2022) huấn luyện một mô hình chỉ trên các chuỗi nước đi hợp lệ của cờ Othello — không hề cho nó biết luật chơi hay hình dạng bàn cờ. Khi mổ xẻ các lớp ẩn, nhóm nghiên cứu tìm thấy một biểu diễn nội tại của trạng thái bàn cờ, và can thiệp trực tiếp vào biểu diễn đó làm thay đổi nước đi mà mô hình dự đoán³. Nói cách khác, việc dự đoán token tiếp theo đủ tốt có thể buộc mô hình phải tự dựng lên một mô hình nội tại về cái đã sinh ra dữ liệu.

Ở mức trực giác quen thuộc hơn: hãy hỏi một LLM "Một người ném quả bóng lên không. Điều gì xảy ra tiếp theo?". Mô hình không tra cứu vật lý — nó dự đoán token tiếp theo dựa trên hàng triệu mô tả về bóng rơi trong dữ liệu huấn luyện. Nó "biết" bóng sẽ rơi xuống, không phải vì nắm định luật Newton, mà vì pattern "bóng lên → bóng xuống" xuất hiện đủ nhiều và đủ nhất quán.

Có thể ví von LLM với Định lý con khỉ vô hạn (Infinite Monkey Theorem) — rằng nếu một con khỉ gõ bừa lên máy đánh chữ đủ lâu, nó sẽ tạo ra kiệt tác. LLM là một phiên bản "cải tiến" của con khỉ đó: nó không gõ ngẫu nhiên, mà gõ theo một phân phối xác suất cực kỳ tinh vi được đúc kết từ kho tàng văn bản của nhân loại. Nhưng cần nói rõ để tránh hiểu nhầm: đây vẫn là ước lượng thống kê theo ngữ cảnh, không phải suy luận theo nghĩa con người. Khác biệt so với con khỉ nằm ở chất lượng của phân phối xác suất, không nằm ở việc có hay không một quá trình tư duy.

Người làm AI biết điều này. Họ biết rằng khi model "trả lời" một câu hỏi toán học, nó không "tính toán" theo nghĩa truyền thống — nó đang ước lượng xem chuỗi ký tự nào có xác suất xuất hiện cao nhất sau prompt đó, dựa trên pattern từ dữ liệu huấn luyện. Trường hợp đẹp nhất, chuỗi đó là đáp án đúng. Đôi khi không. Chính bởi vậy, khi chúng ta hỏi AI đôi khi nó sẽ đưa ra những câu trả lời khác hoàn toàn mong đợi của chúng ta, thậm chí hiểu sai ngữ cảnh.

2.2. Scaling Laws Và Sự Khiêm Tốn Bất Đắc Dĩ

Điều thú vị là cách các mô hình khổng lồ đạt được những bước nhảy vọt về chất lượng khi gia tăng quy mô. Sự tiến hóa này diễn ra theo hai quy luật song hành: sự trơn tru có thể dự đoán (Scaling Laws) và năng lực bộc phát (Emergent Capabilities).

a. Sự trơn tru có thể dự đoán: Scaling Laws

Năm 2020, nhóm nghiên cứu tại OpenAI công bố tài liệu nền tảng "Scaling Laws for Neural Language Models"⁴. Bài báo chứng minh một định lý định lượng: hiệu năng của mô hình (đo lường qua việc giảm thiểu Cross-Entropy Loss) tuân theo một quy luật lũy thừa (power-law) cực kỳ trơn tru và nhất quán dựa trên ba biến số chính:

Số lượng tham số (N - Parameters)
Kích thước tập dữ liệu huấn luyện (D - Dataset Size)
Tổng ngân sách tính toán (C - Compute Budget)

Nói một cách dễ hiểu: bạn càng đổ nhiều tiền mua GPU, nạp càng nhiều văn bản và tăng kích thước ma trận trọng số, tỷ lệ lỗi của mô hình khi dự đoán token tiếp theo sẽ giảm xuống một cách đều đặn. Đường cong này chuẩn xác đến mức các kỹ sư có thể dự đoán trước chính xác mức Loss của một mô hình 100 tỷ tham số ngay từ khi mới chạy thử nghiệm trên phiên bản 1 tỷ tham số.

Hình 1: Đồ thị Scaling Laws trích từ nghiên cứu của Kaplan et al. (2020) — "Scaling Laws for Neural Language Models". Nguồn: Kaplan, J., McCandlish, S., Henighan, T., Brown, T. B., Chess, B., Child, R., ... & Amodei, D. (2020). arXiv preprint arXiv:2001.08361.

Giải thích đồ thị: Hình 1 là đồ thị log-log biểu diễn mối quan hệ giữa Test Loss (trục tung, đơn vị nats) và tổng ngân sách tính toán (trục hoành, đơn vị PF-days — petaflop/ngày). Mỗi đường cong tương ứng với một tỷ lệ phân bổ khác nhau giữa số tham số (N) và kích thước dữ liệu (D). Điểm đáng chú ý là tất cả các đường cong đều hội tụ về một xu hướng chung: Test Loss giảm đều đặn theo quy luật lũy thừa (power-law) khi compute budget tăng — không có điểm gãy, không có bước nhảy đột biến. Điều này cho thấy việc tăng quy mô mô hình (cả tham số lẫn dữ liệu) là một con đường giảm Loss có thể dự đoán trước một cách chính xác. Đây là nền tảng định lượng cho chiến lược "càng to càng tốt" (bigger is better) của các phòng nghiên cứu AI.

b. Bước nhảy vọt đột biến: Năng lực bộc phát (Emergent Capabilities)

Thế nhưng, việc giảm đều đặn tỷ lệ lỗi dự đoán từ vựng lại dẫn đến một hiện tượng kỳ lạ thứ hai: Emergent Capabilities (Năng lực bộc phát). Đây là những khả năng phức tạp không hề tồn tại ở các mô hình nhỏ, nhưng đột ngột xuất hiện (phase transition) khi mô hình vượt qua một ngưỡng quy mô tới hạn nhất định.

Hình 2: Đồ thị Emergent Capabilities minh họa sự khác biệt giữa quy luật mở rộng trơn tru của Scaling Laws (đường xanh lá) và các bước nhảy đột biến của năng lực bộc phát (đường xanh dương). Ý tưởng đồ thị dựa trên các phát hiện trong nghiên cứu của Wei, J., et al. (2022)⁵ và Schaeffer et al. (2023)⁶ — công trình thứ hai lập luận rằng một phần "tính bộc phát" đến từ cách chọn thang đo đánh giá, chứ không hoàn toàn từ bản thân mô hình.

Giải thích đồ thị: Hình 2 so sánh hai dạng hành vi khác nhau của mô hình ngôn ngữ lớn khi quy mô tăng dần. Đường xanh lá cây (trơn tru) thể hiện Scaling Laws: Test Loss giảm đều đặn khi tăng số tham số — đây là xu hướng có thể dự đoán trước. Đường xanh dương (bậc thang) thể hiện Emergent Capabilities: hiệu năng trên các tác vụ phức tạp (như suy luận toán học, lập luận đa bước) gần như bằng 0 ở mô hình nhỏ, nhưng đột ngột tăng vọt sau một ngưỡng quy mô tới hạn nhất định. Sự xuất hiện đột ngột này — còn gọi là phase transition — là lý do khiến việc phát hiện ra các năng lực mới của AI thường mang tính bất ngờ và khó dự đoán, đồng thời cũng là nguồn gốc của những lầm tưởng về "sự thức tỉnh" của AI trong mắt công chúng.

Theo các nghiên cứu chuyên sâu về kỹ thuật lập luận chuỗi (tiêu biểu là công trình của Jason Wei et al., 2022)⁵, khả năng áp dụng Chain-of-Thought (CoT) — phương pháp yêu cầu mô hình tự diễn giải tường minh các bước trung gian trước khi đưa ra kết luận — chính là một năng lực bộc phát điển hình.

Hãy đặt điều này vào bối cảnh bài toán mỏ neo ở Lỗi #1.

Ở các mô hình nhỏ (dưới ngưỡng tới hạn): Nếu bạn áp dụng kỹ thuật CoT ép mô hình suy luận, nó vẫn ngoan ngoãn xuất ra các chuỗi văn bản phân tích. Thế nhưng, do "bộ nhớ" trọng số quá mỏng manh, luồng suy luận này nhanh chóng bị đứt gãy. Mô hình rơi vào trạng thái mất phương hướng, các bước logic mâu thuẫn lẫn nhau hoặc ngập tràn ảo giác (hallucination), dẫn đến toàn bộ chuỗi tác vụ thất bại thảm hại.
Ở các siêu mô hình (trên ngưỡng tới hạn): Nhờ mật độ liên kết nơ-ron đủ dày đặc để gánh vác các ma trận tri thức phức tạp, mô hình bỗng nhiên bộc phát khả năng duy trì tính chặt chẽ của toàn bộ luồng tư duy. Với bài toán dự án khổng lồ trên, thay vì đoán bừa một giải pháp chắp vá, nó sẽ tự động chẻ nhỏ và thực thi tuần tự các bước chiến lược cực kỳ sắc bén:
1. Rà soát tổng thể: Phân tích cây thư mục để lập bản đồ phụ thuộc giữa các module lõi.
2. Phát hiện và xử lý bug: Rà soát từng luồng thực thi, kiểm tra điều kiện đầu vào/đầu ra và tiến hành vá lỗi mà không làm ảnh hưởng đến cơ chế xác thực.
3. Xây dựng tài liệu: Ánh xạ mã nguồn sau tinh chỉnh thành hệ thống tài liệu kỹ thuật hoàn chỉnh và chuẩn xác.

Dù mang lại những đột phá đáng kinh ngạc, cơ chế bộc phát này đồng thời gieo rắc một thách thức kiến trúc nan giải: chúng ta không thể dự đoán chính xác khi nào một năng lực mới sẽ xuất hiện, cũng như không thể đảm bảo tuyệt đối tính đúng đắn của nó trong mọi tình huống. Từ góc độ kỹ thuật thuần túy, đây vẫn là một hộp đen rủi ro. Còn từ góc độ truyền thông, sự kỳ diệu bất ngờ này lại vô tình trở thành chất xúc tác hoàn hảo thổi bùng lên những lầm tưởng huyễn hoặc về trí tuệ nhân tạo tổng quát (AGI).

Vấn đề then chốt là: ngay cả khi scaling laws tiếp tục đưa chúng ta đến những mô hình lớn hơn nữa, chúng vẫn không giải quyết được bài toán "hộp đen" — ta không thể kiểm soát từng bước trong quá trình suy luận của model, không thể biết chính xác tại sao nó sai, và không thể đảm bảo nó sẽ luôn đúng trong mọi tình huống. Đây là vấn đề mà kiến trúc phân tầng dựa trên entropy — sẽ được đề xuất ở phần sau nhắm đến giải quyết.

2.3. Những Giới Hạn Cốt Lõi Của Mô Hình Xác Suất

Dù mạnh mẽ, các mô hình Generative AI hiện tại vẫn mang trong mình những giới hạn cốt lõi — và tất cả đều bắt nguồn từ cùng một gốc: bản chất xác suất của chúng.

Xu hướng "Bịa đặt" (Hallucination): Model luôn cố gắng tạo ra chuỗi từ nghe có vẻ hợp lý nhất, ngay cả khi thông tin đó không có thật. Nó không có khái niệm về "sự thật" — chỉ có "xác suất". Đây không phải lỗi, mà là đặc tính bẩm sinh: khi bị hỏi một điều nó không biết, nó không thể nói "không biết", vì "không biết" không phải là một token có sẵn trong không gian output của nó — nó buộc phải sinh ra thứ gì đó xác suất cao nhất.
Không có bộ nhớ thực sự (No persistent memory): Model không tự lưu lại ký ức giữa các phiên trò chuyện. Mỗi phiên là một "tờ giấy trắng" — vì về mặt toán học, nó không có trạng thái nội tại. Cái gọi là "nhớ ngữ cảnh" thực chất là việc bạn đưa lại toàn bộ lịch sử vào prompt. (Kỹ thuật RAG và mở rộng context window đang cải thiện điều này, nhưng không thay đổi bản chất.)
Lập luận dựa trên thống kê, không phải logic: Một AI có thể trả lời đúng một bài toán tích phân, nhưng không phải vì nó "giải" theo nghĩa con người hiểu. Nó đang ước lượng chuỗi ký tự có xác suất cao nhất sau prompt đó — dựa trên hàng triệu lời giải nó thấy trong dữ liệu huấn luyện. Nó giống một học sinh thuộc làu đáp án mẫu hơn là một nhà toán học.
Không có khả năng tự kiểm tra (Self-correction hạn chế): Model hiếm khi tự nhận thức được mình đang sai trong quá trình sinh output — vì nó không có "vòng lặp phản hồi" nội bộ. Để sửa lỗi, cần có cơ chế bên ngoài (như một vòng lặp kiểm định riêng) hoặc được thiết kế ngay từ prompt (như Chain-of-Thought). Đây là lý do tại sao một mô hình có thể viết một bài luận dài 10 trang đầy lỗi sai mà vẫn tiếp tục viết một cách tự tin.

Những giới hạn này không phải khiếm khuyết tạm thời — chúng là hệ quả không thể tách rời của việc xây dựng "trí thông minh" trên nền tảng dự đoán xác suất. Và để thực sự thấu hiểu cơ chế đằng sau sự mong manh lẫn sức mạnh đó, chúng ta cần lùi lại một bước và nhìn AI qua một lăng kính toàn diện hơn — lăng kính của Lý thuyết thông tin và khái niệm Entropy.

3. Góc Nhìn III: Bản Chất Thật – AI Là Một Hệ Thống Dịch Chuyển Entropy

3.1. Entropy Là Gì Trong Thế Giới Thông Tin

Trong vật lý nhiệt động lực học, entropy là thước đo độ hỗn loạn của hệ thống — mức độ mà năng lượng bị phân tán không thể sử dụng được. Một ly nước nóng đặt trong phòng lạnh sẽ dần nguội đi: entropy của hệ thống tăng lên, năng lượng nhiệt lan tỏa cho đến khi đạt trạng thái cân bằng hỗn độn nhất có thể.

Nhà toán học Claude Shannon đã mượn khái niệm này vào năm 1948 để mô tả một hiện tượng tương tự trong thế giới thông tin: Information Entropy — mức độ hỗn loạn, mơ hồ, và không thể đoán trước của một thông điệp.

Entropy thông tin cao = thông điệp mang nhiều sự không chắc chắn, nhiều cách hiểu, nhiều khả năng. Entropy thông tin thấp = thông điệp được nén chặt, tường minh, tất định.

Để hiểu rõ hơn chúng tôi đang muốn nói gì, hãy xem hai cách diễn đạt cùng một ý:

Entropy cao — ngôn ngữ tự nhiên: "Tôi muốn bạn tạo ra một biến số có giá trị bằng mười"
Entropy thấp — code: var a = 10;

Cả hai chứa cùng một lượng thông tin ngữ nghĩa. Nhưng câu đầu tiên chứa đầy sự dư thừa, mơ hồ (biến số là gì? bằng mười là integer hay float?), và không gian để hiểu sai. Câu thứ hai là tất định: chỉ có đúng một cách hiểu duy nhất. Một ví dụ khác để thấy rõ sự khác biệt này. Hãy so sánh hai prompt sau đây:

Prompt entropy cao: "Viết một trang web bán hàng cho tôi."
Prompt entropy thấp: "Viết một file HTML tên index.html với một form đăng nhập gồm hai trường (email, password) và một nút submit. Dùng Tailwind CSS để style."

Cả hai đều yêu cầu viết mã nguồn web. Nhưng prompt đầu tiên chứa một không gian mơ hồ khổng lồ: "trang web bán hàng" có nghĩa là gì? Bao nhiêu trang? Có giỏ hàng không? Có thanh toán không? Cần backend không? Dùng framework gì? Mỗi câu hỏi không được trả lời là một bậc entropy mới — và model buộc phải "đoán" tất cả.

Kết quả là prompt đầu tiên thường sinh ra một trang web chung chung, đầy mã thừa và thiếu chính xác. Prompt thứ hai, dù dài hơn, lại cho ra kết quả đúng ngay lần đầu — bởi vì entropy đầu vào đã được giảm xuống mức tối thiểu trước khi AI bắt đầu xử lý. Bây giờ, hãy nhìn lại yêu cầu ở Lỗi #1: "tìm tất cả các bug, sửa chúng, rồi viết documentation cho toàn bộ project". Về mặt định lượng khái niệm, câu lệnh mang tính tự nhiên này chứa đựng một lượng hỗn độn khổng lồ — có thể lên tới hàng nghìn, thậm chí hàng chục nghìn đơn vị entropy do chứa vô số kịch bản mập mờ, rẽ nhánh chưa được xác định. Thế nào là "tất cả"? Tiêu chuẩn nào định nghĩa một dòng code là "bug"? "Toàn bộ" là bao gồm cả những thư viện bên ngoài hay chỉ code do bạn viết?

Tuy nhiên, kết quả mong muốn của người dùng lại đòi hỏi AI phải nén lập tức mớ hỗn độn hàng chục nghìn entropy đó về đúng mức 1 entropy (trạng thái mã nguồn và tài liệu cực kỳ rõ ràng, tường minh, tất định và chạy chính xác tuyệt đối) ngay lập tức chỉ sau một câu lệnh. Sự chênh lệch khủng khiếp giữa đầu vào (hàng chục nghìn entropy) và đầu ra kỳ vọng (1 entropy) trong một bước nhảy đơn lẻ chính là nguyên nhân cốt lõi khiến AI bị "quá tải" và tất yếu dẫn đến thất bại hoặc sinh ra ảo giác.

Hình 3: Minh họa "bước nhảy entropy tử thần" — một prompt duy nhất bắt AI phải dịch từ trạng thái entropy cực cao (codebase hỗn độn) xuống entropy cực thấp (kết quả tất định) trong một bước duy nhất. Đây là nguyên nhân gốc rễ của hầu hết các thất bại khi dùng AI sai cách.

Giải thích hình: Bên trái — khối mã nguồn hỗn độn với các dấu hỏi chấm rải rác, đại diện cho entropy ~1,000,000 của toàn bộ codebase cùng prompt mơ hồ. Bên phải — kết quả kỳ vọng gọn gàng với code sạch, tài liệu chuẩn xác, compiler xác nhận không lỗi (entropy ~1). Giữa là vách đá tử thần với dấu X — một bước nhảy duy nhất không thể thực hiện nổi.

Đây là điểm mấu chốt để hiểu bản chất của Generative AI.

3.2. Định Nghĩa: Generative AI Là Máy Dịch Entropy

Nếu phải định nghĩa Generative AI trong một câu, đây sẽ là câu đó:

Generative AI là một công cụ dịch entropy — biến dữ liệu đầu vào có entropy biểu diễn cao thành dữ liệu đầu ra có entropy biểu diễn thấp, với điều kiện đầu vào và đầu ra được định tính và cố định trước.

Đây không phải là sự hạ thấp hay coi nhẹ. Đây là sự minh xác. Và sự minh xác này thay đổi mọi thứ.

Mục 3.1 đã cho thấy hai đầu của phép dịch đó: đầu vào là một câu lệnh mơ hồ cùng hàng trăm file mã nguồn (entropy cực cao); đầu ra kỳ vọng là mã sạch và tài liệu chuẩn xác — trạng thái tất định (deterministic), nơi compiler chạy được và bất kỳ ai đọc tài liệu cũng hiểu đúng một cách duy nhất (entropy cực thấp). AI đóng vai trò một bộ lọc, một máy nén: nó lấy cái "ý muốn" mập mờ của bạn và dịch ra thành kết quả tuân thủ cú pháp nghiêm ngặt của ngôn ngữ lập trình.

Nhưng "dịch entropy" không đồng nghĩa với "tạo ra thông tin". Đây là chỗ dễ hiểu nhầm nhất, và để tránh mâu thuẫn, cần tách bạch hai loại entropy hoàn toàn khác nhau:

Entropy biểu diễn (representational entropy) — sự dư thừa và lỏng lẻo trong cách diễn đạt. Câu "Tôi muốn bạn tạo ra một biến số có giá trị bằng mười" và var a = 10; mang cùng một nội dung, nhưng cách thứ nhất dài hơn và cho phép nhiều cách hiểu hơn. Loại entropy này giảm được — và đó chính xác là việc AI làm: nén, chuẩn hóa, đưa về một dạng biểu diễn tất định.
Entropy ngữ nghĩa chưa xác định (unspecified semantic entropy) — những gì bạn chưa hề nói ra. Sắp xếp cái gì? Mảng lớn hay nhỏ? Ưu tiên bộ nhớ hay tốc độ? Loại entropy này không giảm được, đơn giản vì thông tin đó không tồn tại ở đầu vào. Model không thể suy ra; nó chỉ có thể lấp chỗ trống bằng phương án phổ biến nhất trong dữ liệu huấn luyện.

Gộp lại thành một câu: AI nén được cách bạn nói, nhưng không tạo ra được điều bạn chưa nói. Mọi khoảng trống ngữ nghĩa bạn để lại đều sẽ được lấp bằng một prior thống kê — và đó chính là nơi ảo giác (hallucination) sinh ra.

Vì vậy, khi bạn đưa vào một prompt hời hợt như "Viết cho tôi một hàm sắp xếp" (không nói rõ sắp xếp cái gì, mảng lớn hay nhỏ, tối ưu bộ nhớ hay tốc độ), thứ bạn nhận về là một đoạn code chung chung, "vô thưởng vô phạt" lấy từ xác suất cao nhất trên StackOverflow — không phải vì AI kém, mà vì phần entropy quyết định chất lượng đáp án chưa bao giờ được cung cấp. Câu trả lời đó có thể được bọc trong một lớp vỏ ngôn từ trôi chảy và tự tin, nhưng sự mơ hồ bên dưới thì vẫn nguyên vẹn.

3.3. Nguyên Lý Gradient Entropy — Chìa Khóa Dùng AI Đúng

Từ định nghĩa trên, chúng ta rút ra một nguyên lý thực hành quan trọng nhất khi làm việc với Generative AI:

Nguyên lý Gradient Entropy: AI hoạt động tốt nhất khi entropy được giảm dần qua nhiều bước nhỏ, thay vì một bước nhảy lớn duy nhất.

Đây là lý do tại sao cách dùng AI hiệu quả nhất không phải là đưa một yêu cầu khổng lồ và chờ đợi phép màu. Mà là chia nhỏ yêu cầu đó thành một chuỗi các bước, mỗi bước chỉ giảm entropy vừa phải so với bước trước.

Hãy quay lại ví dụ xuyên suốt ở Lỗi #1.

Cách sai (một bước nhảy entropy khổng lồ): Đưa nguyên câu lệnh đó cho AI. Entropy input: ~1,000,000. Entropy output kỳ vọng: ~1. Mô hình gần như chắc chắn sẽ thất bại vì sự chênh lệch entropy quá lớn.

Cách đúng (gradient entropy giảm dần):

Bước 1 — Xác định phạm vi: "Hãy phân tích cấu trúc thư mục này, chỉ định danh sách các file module chính." (Entropy giảm từ 1,000,000 → 10,000)
Bước 2 — Rà soát module cụ thể: "Trong file OrderService.cs, hãy tìm các đoạn code không xử lý exception." (Entropy giảm từ 10,000 → 100)
Bước 3 — Sửa cục bộ: "Tại dòng 45, thêm try-catch cho đoạn gọi API thanh toán." (Entropy giảm từ 100 → 5)
Bước 4 — Kiểm tra chéo: "Hãy verify rằng đoạn sửa này không làm hỏng luồng xác thực ở file AuthService.cs." (Entropy đầu vào đã ở mức thấp, xác suất thành công rất cao)

Mỗi bước trong chuỗi này có một gradient entropy hợp lý — sự chênh lệch giữa entropy đầu vào và đầu ra của mỗi bước vừa đủ để model xử lý mà không bị quá tải. Kết quả cuối cùng đạt được qua tổng của nhiều bước nhỏ đáng tin cậy, thay vì một bước nhảy đầy rủi ro.

Hình 4: Minh họa Nguyên lý Gradient Entropy. Bên trái — cách sai: prompt duy nhất yêu cầu AI nhảy từ entropy ~1,000,000 xuống ~1, dẫn đến thất bại hoặc ảo giác. Bên phải — cách đúng: chia thành 4 bước nhỏ, mỗi bước chỉ giảm entropy một lượng vừa phải, dẫn đến kết quả thành công.

Giải thích hình: Hình vẽ so sánh hai cách tiếp cận với cùng một bài toán "đọc toàn bộ codebase, sửa bug, viết tài liệu". Cách sai (trái): một mũi tên đỏ thẳng từ đỉnh cao entropy xuống đáy — đảm bảo thất bại. Cách đúng (phải): cầu thang 4 bậc — (1) phân tích thư mục (1M → 10K), (2) rà soát module (10K → 100), (3) sửa cục bộ (100 → 5), (4) kiểm tra chéo (entropy đã thấp → xác suất cao).

Hệ quả thực tiễn: Nếu bạn thấy AI đang cho kết quả kém, câu hỏi đầu tiên không phải là "model này có tốt không?" mà là "entropy trong prompt của tôi có đang quá cao không?". Đây là khác biệt cốt lõi giữa người dùng AI giỏi và người dùng AI trung bình.

3.4. "Regex Cho Nhà Giàu"

Khi nhìn nhận AI như một máy dịch Entropy, chúng ta có thể gọi nó bằng một cái tên thực tế hơn: "Regex cho nhà giàu".

Hình 5: Minh họa phép ẩn dụ "Regex cho nhà giàu". Bên trái — Regex như đoàn tàu hỏa: nhanh, chính xác tuyệt đối, chi phí gần như bằng 0 nhưng chỉ chạy trên đúng đường ray đã định. Bên phải — Generative AI như chiếc trực thăng: linh hoạt, xử lý mọi địa hình nhưng chi phí cực kỳ đắt đỏ.

Giải thích hình: Hình vẽ đặt hai công cụ cạnh nhau để thấy sự đánh đổi. Train (Regex): thân tàu vững chãi, chạy trên đường ray cố định — tượng trưng cho pattern cứng, không bao giờ sai nhưng cũng không linh hoạt. Helicopter (AI): bay trên mọi địa hình phức tạp — tượng trưng cho khả năng xử lý ngữ cảnh mềm, linh hoạt nhưng tốn kém. Dòng chữ phía dưới nhấn mạnh nguyên tắc vàng: dùng công cụ đúng cho đúng việc.

Nếu như Regex dùng các quy tắc logic cứng nhắc để xử lý chuỗi ký tự với chi phí tính toán gần như bằng không, thì Generative AI chấp nhận tiêu tốn một lượng tài nguyên khổng lồ để đổi lấy khả năng xử lý các pattern "mềm" — tức là ngữ cảnh và ý nghĩa ngôn từ.

Nó không sinh ra để thay thế các công cụ truyền thống. Nó chỉ đơn giản là mở rộng biên giới xử lý thông tin đến những nơi mà các quy tắc cứng bất lực. Việc gọi AI là "Regex cho nhà giàu" không phải để chế nhạo, mà là một lời nhắc nhở quan trọng về mặt kiến trúc: đừng dùng một công cụ đắt đỏ ở những nơi mà các quy tắc logic cơ bản cũng đủ sức giải quyết.

Để thấy rõ hơn sự khác biệt mang tính bản chất này, chúng ta có thể đặt chúng lên bàn cân (Lưu ý: Sự so sánh này chỉ là tương đối)

	Regex	Generative AI
Đầu vào	Chuỗi ký tự theo pattern cứng	Văn bản/code theo ngữ cảnh mềm
Đầu ra	Chuỗi đã được thay thế/trích xuất	Văn bản/code đã được biến đổi
Điểm mạnh	Nhanh, tất định, không mơ hồ	Linh hoạt, chịu được input "bẩn", xử lý ngữ cảnh
Điểm yếu	Giòn, dễ vỡ khi input lệch pattern	Tốn kém, xác suất, khó kiểm soát
Chi phí	Gần như bằng 0	Cực kỳ cao

Hãy tưởng tượng Regex như một đoàn tàu hỏa chạy trên đường ray. Nó cực kỳ nhanh, chính xác và tốn rất ít năng lượng. Nhưng nó chỉ chạy được trên đúng tuyến đường đã đặt sẵn; chỉ cần một sai lệch nhỏ trên đường ray, nó sẽ trật bánh.

Trong khi đó, Generative AI giống như một chiếc trực thăng. Chi phí vận hành, bảo dưỡng và nhiên liệu của nó cực kỳ đắt đỏ. Nhưng bù lại, nó có thể bay đến bất cứ đâu, bất chấp địa hình phức tạp hay thời tiết mờ mịt.

Nếu bạn chỉ cần đi từ ga A đến ga B trên một lộ trình cố định, việc gọi trực thăng là một sự lãng phí vô nghĩa.

Một dẫn chứng cụ thể: bạn cần trích xuất tất cả địa chỉ email từ một file log 100MB. Đây là một pattern hoàn toàn cố định — email nào cũng có cấu trúc tên_người_dùng@tên_miền.đuôi. Một câu lệnh regex như:

[\w.+-]+@[\w-]+\.[\w.]+

— có thể hiểu nôm na là: "một chuỗi gồm chữ cái, số, dấu chấm, dấu cộng hoặc dấu gạch ngang (tên người dùng), theo sau là dấu @, rồi một chuỗi chữ cái/số/gạch ngang (tên miền), một dấu chấm, và cuối cùng là chữ cái/số/dấu chấm (đuôi như .com, .co.uk)" — chạy trong chưa đầy 0.1 giây với độ chính xác 100%. Nó không bao giờ nhầm, không bao giờ bỏ sót, không bao giờ bịa ra email không có thật.

Trong khi đó, dùng AI để làm cùng việc này không chỉ chậm hơn hàng nghìn lần, mà còn có thể bỏ sót email hoặc tưởng tượng ra email không tồn tại — vì AI làm việc dựa trên xác suất, không phải quy tắc cứng.

Ngược lại, nếu bạn cần hiểu ngữ cảnh của một đoạn code lỗi và đề xuất cách sửa — ví dụ, phát hiện rằng một biến local bị shadowing bởi một biến toàn cục, dẫn đến logic sai — thì regex hoàn toàn bất lực. Đây là lúc cần một "chiếc trực thăng" AI.

Nguyên tắc vàng: Nếu bạn có thể diễn tả vấn đề bằng một luật logic cứng (if-else, regex, AST pattern) — hãy dùng luật cứng. Chỉ dùng AI khi vấn đề cần hiểu ngữ cảnh hoặc xử lý sự mơ hồ.

3.5. Cơ Chế Bên Trong — "Attention Is All You Need" Qua Lăng Kính Entropy

Năm 2017, một nhóm kỹ sư tại Google Brain công bố bài báo có lẽ là quan trọng nhất trong lịch sử AI hiện đại: **"Attention Is All You Need"**⁷. Bài báo giới thiệu kiến trúc Transformer — nền tảng của mọi LLM hiện đại, từ GPT đến Claude đến Gemini.

Tên bài báo là một tuyên ngôn kỹ thuật: bạn không cần mạng hồi quy (recurrent networks), không cần mạng tích chập (convolution) — chỉ cần attention là đủ. Nhưng tại sao? Và attention là gì khi nhìn qua lăng kính entropy?

Cơ chế Attention là gì?

Trong kiến trúc Transformer, mỗi từ/ký hiệu (token) trong đầu vào (input) được biểu diễn qua ba vector: Query (Q - Câu hỏi), Key (K - Từ khóa), và Value (V - Giá trị). Phép tính attention diễn ra như sau:

Attention(Q, K, V) = softmax(QKᵀ / √d_k) · V

Nhìn vào công thức này từ góc độ entropy:

QKᵀ tính độ tương đồng giữa từng cặp token trong ngữ cảnh. Đây là bước đo lường mức độ liên quan — nói cách khác, bước đầu tiên của việc lọc entropy: từ toàn bộ ngữ cảnh, cái gì quan trọng với cái gì?
softmax(...) chuẩn hóa các điểm tương đồng đó thành một phân phối xác suất. Đây chính xác là thứ Shannon đã mô tả — entropy của phân phối attention cho biết mô hình đang "tập trung" (entropy thấp, một vài token quan trọng) hay "phân tán" (entropy cao, không biết cái gì quan trọng hơn).
V áp dụng phân phối đó để tổng hợp thông tin. Token đầu ra là tổ hợp có trọng số của Value — nghĩa là thông tin đã được nén, entropy đã được giảm theo đúng nghĩa của lý thuyết thông tin.

Nếu bạn đọc cảm thấy những công thức toán học trên quá phức tạp, hãy hình dung cơ chế Attention qua một hình tượng gắn liền với công việc của chúng ta: Người thủ thư mẫn cán trong một kho lưu trữ mã nguồn khổng lồ.

Hãy tưởng tượng bạn đang ở giai đoạn rà soát lỗi của bài toán mỏ neo. Bạn đứng giữa một kho lưu trữ codebase khổng lồ với hàng ngàn tập tin mã nguồn, tài liệu kỹ thuật xếp lộn xộn (Entropy cực cao). Bạn không biết đoạn logic gây lỗi nằm ở đâu. Lúc này, cơ chế Attention hoạt động giống như một người thủ thư thông minh giúp bạn giải quyết đống hỗn độn đó qua 3 bước (tương ứng với Q, K, V):

Query (Q - Câu hỏi): Bạn đưa ra vấn đề truy vấn: "Hàm xử lý đơn hàng đang bị báo lỗi ngắt kết nối (TimeoutException)".
Key (K - Từ khóa/Đặc trưng): Người thủ thư lướt qua toàn bộ các module, file logic, định nghĩa hàm để rà soát nơi nào có các đặc trưng liên quan đến "gọi API", "kết nối", hoặc "timeout". Hệ thống tính toán độ khớp (attention score) giữa truy vấn và từng vùng mã nguồn.
Value (V - Giá trị thực tế): Người thủ thư trích xuất chính xác khối code thiết lập kết nối mạng đang thiếu tham số thời gian chờ để đưa vào ngữ cảnh xử lý.

Nhờ có "người thủ thư" Attention, từ một kho lưu trữ mông lung ban đầu, bạn cô đọng lại được đúng vài khối mã nguồn cần thiết. Trong AI cũng vậy, cơ chế này giúp mô hình loại bỏ sự hỗn loạn, biết tập trung vào những vùng thông tin quan trọng nhất để hiểu đúng bối cảnh và đưa ra giải pháp chính xác.

Hình 6: Sơ đồ cơ chế Attention trong kiến trúc Transformer. Ba vector Query (Q), Key (K), Value (V) tương tác qua phép tính softmax(QKᵀ/√d_k)·V để xác định mức độ quan trọng của từng token trong ngữ cảnh — đây chính là cơ chế giảm entropy cốt lõi của Generative AI.

Giải thích hình: Sơ đồ trực quan hóa luồng xử lý Attention: từ ngữ cảnh đầu vào (input sequence), mỗi token được gán ba vai trò Query, Key, Value. Bước softmax tính toán attention score (heatmap đỏ) — mức độ liên quan giữa từng cặp token. Kết quả là tổ hợp trọng số của Value, tạo ra token đầu ra đã được làm rõ ngữ nghĩa (entropy giảm). Dòng chữ "Cơ chế Attention" nhấn mạnh việc lọc thông tin từ hỗn độn sang trật tự.

Tại sao đây là giảm thiểu entropy (entropy reduction)?

Hãy hình dung một bối cảnh thông tin trong mã nguồn: "Hàm tính toán gọi đến dịch vụ thanh toán. Nó bị lỗi ngắt kết nối."

Khi mô hình xử lý từ "Nó", cơ chế attention cần quyết định "Nó" đang ám chỉ (refer) đến cái gì — bản thân "Hàm tính toán" nội bộ hay "Dịch vụ thanh toán" bên ngoài?

Trạng thái ban đầu (Entropy cao): Khi chưa xét sâu đến ngữ cảnh, từ "Nó" có thể là "Hàm tính toán" hoặc "Dịch vụ thanh toán". Xác suất phân bổ đều (ví dụ 50/50). Đây là trạng thái có độ bất định tối đa (Entropy cực đại).
Quá trình Attention: Mô hình tính toán mối liên hệ giữa "Nó" và cụm từ "bị lỗi ngắt kết nối" kết hợp với động từ "gọi đến". Vì trong tri thức lập trình, lỗi ngắt kết nối (connection timeout) đặc trưng cho các cuộc gọi ra dịch vụ bên ngoài hơn là logic hàm nội bộ, điểm chú ý (attention score) cho "Dịch vụ thanh toán" sẽ được đẩy lên cao vượt trội.
Trạng thái sau Attention (Entropy thấp): Xác suất được cập nhật, dồn về phía "Dịch vụ thanh toán" (ví dụ 95% Dịch vụ thanh toán, 5% Hàm tính toán).

Sự dịch chuyển từ phân phối đều (mơ hồ) sang phân phối có đỉnh nhọn (tường minh) chính là quá trình giảm thiểu entropy. Đầu ra của từ "Nó" sau attention đã được giải quyết về mặt ngữ nghĩa: từ "Nó" (mơ hồ) → "Nó = Dịch vụ thanh toán" (tường minh).

Lưu ý: Mô hình còn sử dụng nhiều "đầu" chú ý (Multi-Head Attention) và mã hóa vị trí (Positional Encoding) để xử lý nhiều khía cạnh và thứ tự của câu cùng lúc. Nhưng cái đó không tiện đề cập sâu hơn vì có thể gây lan man trong bài viết.

Tại Sao "All You Need"?

Câu trả lời bây giờ trở nên rõ ràng: attention là cơ chế đủ mạnh để mô hình hóa bất kỳ phép biến đổi entropy nào giữa đầu vào và đầu ra — từ dịch ngôn ngữ, đến sinh code, đến trả lời câu hỏi. Nó thay thế các phương pháp cũ để trở thành "tất cả những gì bạn cần". Toàn bộ kiến trúc của LLM được xây dựng để tìm, lọc, và tổng hợp thông tin từ entropy cao sang entropy thấp — thông qua cơ chế attention lặp đi lặp lại qua nhiều lớp.

3.6. Hai Nguyên Lý Của Máy Dịch Entropy

Từ toàn bộ phân tích về cơ chế Attention và các nguyên lý entropy ở các phần trước, chúng ta có thể đúc kết bản chất của Generative AI thành hai nguyên lý hướng dẫn (guiding principles). Đây không phải là các định luật toán học đã được chứng minh chặt chẽ theo nghĩa hình thức, mà là một khung tư duy (mental framework) được rút ra từ sự kết hợp giữa lý thuyết thông tin Shannon và các quan sát thực nghiệm trong quá trình làm việc với LLM. Chúng tôi tin rằng hai nguyên lý này đủ mạnh để giải thích và dự đoán hành vi của AI trong phần lớn các tình huống thực tế:

Nguyên lý I — Bảo toàn entropy ngữ nghĩa: AI nén được entropy biểu diễn, nhưng không tự sinh ra được phần ngữ nghĩa mà bạn chưa cung cấp. Biến một đoạn mô tả dài dòng thành một dòng code tất định là việc AI làm rất tốt — đó là nén cách diễn đạt. Nhưng những gì bạn không nói ra (sắp xếp cái gì, ràng buộc nào, ưu tiên gì) thì không có phép màu nào tạo ra được; model chỉ lấp chỗ trống bằng phương án phổ biến nhất trong dữ liệu huấn luyện. Muốn kết quả chính xác, bạn phải cung cấp đủ ngữ nghĩa ngay từ prompt — dù AI có che giấu sự mơ hồ đó khéo đến đâu dưới lớp vỏ ngôn từ trôi chảy.

Nguyên lý II — Gradient Entropy: Mỗi tác vụ AI chỉ nên giảm entropy một lượng vừa phải, tương xứng với năng lực của mô hình. Ép một mô hình nhảy từ entropy rất cao xuống rất thấp trong một bước duy nhất là công thức dẫn đến thất bại. Chia nhỏ thành các bước, mỗi bước giảm entropy một bậc, là con đường đáng tin cậy hơn.

Lưu ý về các con số entropy trong bài viết: Các giá trị entropy được sử dụng xuyên suốt bài viết (ví dụ: 1,000,000 → 10,000 → 100 → 5 → 1) là các giá trị minh họa mang tính tương đối, nhằm trực quan hóa mức độ chênh lệch giữa các bước — chúng không phải là kết quả đo lường bằng công thức Shannon Entropy (H = -Σ p(x) log p(x)) hay bất kỳ metric định lượng nào khác. Trong thực tế, việc đo lường chính xác "entropy của một prompt" vẫn là một bài toán mở. Mục đích của các con số này là giúp bạn đọc nắm bắt trực giác về tỷ lệ giảm entropy giữa các bước, chứ không phải giá trị tuyệt đối.

Hai nguyên lý này, tuy đơn giản, giải thích được hầu hết các hiện tượng "kỳ lạ" mà người dùng gặp phải:

Hiện tượng	Giải thích qua Entropy
AI "nói dối" (Hallucination)	Khi phần ngữ nghĩa cần thiết không được cung cấp, AI vẫn buộc phải sinh output — nó lấp chỗ trống bằng đường xác suất cao nhất, dù sai.
AI làm đúng việc dễ, sai việc khó	Việc dễ có entropy thấp (phạm vi hẹp). Việc khó có entropy cao — nếu prompt vẫn giữ nguyên độ chi tiết, tỷ lệ thành công giảm.
Chain-of-Thought giúp AI lý luận tốt hơn	CoT là cơ chế giảm entropy từng bước: thay vì nhảy từ câu hỏi → đáp án, model đi qua các bước trung gian, mỗi bước chỉ giảm entropy một ít.
Cùng prompt nhưng kết quả khác nhau	Bản chất xác suất: cùng entropy đầu vào, model có thể rơi vào các cực địa phương khác nhau trong không gian output.
Fine-tune làm model "ngu đi" ở tác vụ khác	Khi ép model vào một phạm vi entropy quá hẹp, nó mất khả năng bao phủ các vùng entropy khác (xem Phần 4).

Bảng trên cho thấy: hầu hết các "vấn đề" của AI đều có thể truy nguyên về một nguyên nhân duy nhất — sự chênh lệch entropy không được quản lý đúng cách giữa đầu vào, quá trình xử lý, và đầu ra.

Chính từ các nguyên lý này, một nghịch lý lớn hiện ra.

Hãy nhìn lại hình tượng "ông thủ thư" ở phần 3.5. Hãy tưởng tượng thư viện của bạn chứa tất cả mọi thứ trên đời: từ thơ ca, hội họa, đến y học và lập trình (như các mô hình GPT-4 hay Claude hiện nay). Để nuôi một "ông thủ thư" có cái đầu to chứa được ngần ấy tri thức, chi phí bạn phải trả là cực kỳ đắt đỏ.

Chưa kể, dưới góc độ entropy: vì mô hình tổng quát biết mọi thứ, nên không gian xác suất đầu ra của nó cực kỳ rộng lớn (entropy ban đầu cực cao). Khi bạn chỉ hỏi một câu ngắn về lập trình, mô hình vẫn phải kích hoạt một mạng lưới khổng lồ và tốn tài nguyên để "bóp nghẹt" hàng triệu khả năng không liên quan khác nhằm cô đọng lại đáp án. Quá trình này không chỉ gây lãng phí tính toán, mà còn dễ để lại "vết nhiễu" từ các pattern ngoại lai lọt vào kết quả, khiến câu trả lời kém sắc bén hơn một chuyên gia chỉ học đúng một nghề.

Điều này dẫn chúng ta đến một câu hỏi kiến trúc: liệu có cách nào thoát khỏi nghịch lý của sự tổng quát — một cách thiết kế hệ thống AI tuân thủ đúng nguyên lý entropy mà chúng ta vừa xây dựng?

4. Hướng Đề Xuất: Kiến Trúc Phân Tầng Dựa Trên Entropy

Từ góc nhìn entropy, chúng ta đã thấy rằng AI là một máy dịch chuyển entropy — và nó hoạt động tốt nhất khi entropy được giảm dần qua từng bước nhỏ (Gradient Entropy).

Vậy câu hỏi đặt ra là: nếu nguyên lý này đúng, tại sao hầu hết các hệ thống AI hiện tại lại được thiết kế theo hướng ngược lại — một model duy nhất gánh vác toàn bộ quy trình từ hiểu yêu cầu đến sinh kết quả? Câu trả lời nằm ở ba vấn đề mà phần này sẽ phân tích: chi phí không tương xứng, thiếu khả năng kiểm soát, và bỏ qua các công cụ tất định đã có sẵn.

Thay vì chấp nhận những hạn chế này như một "cái giá phải trả", chúng tôi đề xuất một hướng tiếp cận kiến trúc khác: phân tầng quy trình xử lý theo entropy. Ý tưởng cốt lõi rất đơn giản — hãy để mỗi tầng chỉ xử lý một lượng entropy vừa phải, và dùng đúng công cụ cho đúng mức độ phức tạp.

Phần này không đi sâu vào chi tiết triển khai, mà tập trung vào logic kiến trúc và lý do tại sao nó vượt trội so với mô hình "một model cho mọi thứ" hiện tại.

4.1. Khi Scaling Laws Không Còn Là Lời Giải

Scaling laws đã chứng minh một sự thật không thể phủ nhận: tăng quy mô mô hình (nhiều tham số hơn, nhiều dữ liệu hơn, nhiều compute hơn) giúp giảm loss một cách đều đặn và dự đoán được. Đây là nền tảng cho sức mạnh của GPT-4, Claude, Gemini và mọi LLM hiện đại.

Nhưng scaling laws giải quyết bài toán "làm sao để model giỏi hơn ở mọi thứ" — không phải "làm sao để model đáng tin cậy cho một tác vụ cụ thể". Và đây chính là điểm mấu chốt.

Dưới đây là ba vấn đề mà scaling laws — dù có tiến xa đến đâu — cũng không thể giải quyết:

Vấn đề #1 — Chi phí không tương xứng với độ chính xác.

Hãy thử một phép so sánh đơn giản:

Mô hình	Tham số	Chi phí inference	Đặc điểm
Model tổng quát lớp đầu (GPT-4 API)	Không công bố *	~$0.03 / 1K token (API)	Cần internet, latency vài giây, phải kích hoạt toàn bộ mạng nơ-ron cho mọi tác vụ — kể cả việc đơn giản như đổi tên biến.
Llama 3.1 8B (self-host)	8.03 tỷ (công bố)	~$0.0002 / 1K token	Vẫn là model tổng quát, không gian output vẫn chứa hàng nghìn kỹ năng không liên quan.
NLM 500MB (fine-tuned)	0.5 tỷ	~$0 (chạy local CPU)	Latency < 50ms, toàn bộ tham số dồn vào một tác vụ duy nhất — entropy đầu ra gần như bằng 0.

* OpenAI chưa từng công bố số tham số của GPT-4 hay GPT-4o mini. Các con số "~1.7 nghìn tỷ" và "~8 tỷ" lưu truyền trên truyền thông đều là ước tính rò rỉ chưa được xác nhận, nên chúng tôi không dùng chúng làm căn cứ định lượng. Lập luận dưới đây chỉ dựa trên một dữ kiện đã được công bố: chi phí trên mỗi token của model API lớp đầu cao hơn model 8B self-host khoảng hai bậc độ lớn.

Nghịch lý ở đây là: model càng to, càng tốn kém, nhưng không tự động chính xác hơn cho một tác vụ hẹp. Lý do nằm ở entropy:

Mô hình càng tổng quát, không gian output của nó càng rộng — entropy càng cao — và do đó càng khó kiểm soát cho một tác vụ cụ thể.

Một GPT-4 cùng lúc phải "giỏi" hàng nghìn kỹ năng: làm thơ, giải toán, viết code Python, dịch tiếng Pháp, phân tích luật, tư vấn tâm lý... Khi bạn chỉ cần nó đổi tên biến trong C#, toàn bộ khả năng còn lại trở thành "nhiễu". Model vẫn phải kích hoạt hàng tỷ tham số — bao gồm cả những vùng chuyên trách thơ ca hay luật pháp — chỉ để quyết định xem một biến tên x nên đổi thành customerId hay không.

Chi phí vận hành vi mô này không chỉ là tiền. Nó còn là năng lượng, là thời gian chờ đợi, là sự phụ thuộc vào hạ tầng đám mây. Một tác vụ đơn giản có thể được xử lý trong 50ms trên CPU local lại phải gọi lên đám mây, tốn 2-5 giây và tiêu tốn hàng nghìn lần năng lượng hơn mức cần thiết.

Vấn đề #2 — Thiếu kiểm soát và khó gỡ lỗi.

Một model đơn lẻ xử lý toàn bộ pipeline là một hộp đen (black box). Khi kết quả sai, bạn không biết lỗi xảy ra ở đâu: do hiểu sai yêu cầu? do chọn sai thư viện? do sinh sai cú pháp? Không có "vết" (trace) để lần theo, không có ranh giới trách nhiệm rõ ràng giữa các công đoạn.

Trong kiến trúc phần mềm truyền thống, mỗi module có một trách nhiệm duy nhất — bạn biết chính xác module nào hỏng khi hệ thống gặp lỗi. Với một model lớn duy nhất, mọi thứ đều là lỗi của "cái model" — và bạn không thể làm gì hơn ngoài việc re-prompt và hy vọng.

Vấn đề #3 — Không tận dụng được các công cụ tất định.

Như đã phân tích ở mục 3.4, Regex và các công cụ xử lý cứng (deterministic tools) nhanh hơn AI hàng nghìn lần, rẻ hơn và không bao giờ sai với pattern đã định. Thế nhưng, khi dùng một model duy nhất cho mọi thứ, bạn buộc nó phải xử lý cả những việc đáng lẽ có thể giải bằng một dòng regex — một sự lãng phí kép: vừa đắt hơn, vừa kém chính xác hơn. Điều này dẫn đến một nhận định quan trọng:

4.2. Đề Xuất: Kiến Trúc Phân Tầng Entropy

Hình 7: Sơ đồ kiến trúc phân tầng entropy — một pipeline 4 tầng với entropy giảm dần: Orchestration (model lớn) → Domain Expert (model trung bình) → Micro-execution (model nhỏ / quy tắc cứng) → Verification (compiler / linter). Mỗi tầng chỉ chịu trách nhiệm giảm một lượng entropy vừa phải.

Giải thích hình: Sơ đồ pipeline hình tháp từ trên xuống. Tầng 1 (Orchestration) — model tổng quát tiếp nhận yêu cầu mơ hồ (entropy cao), phân rã thành tiểu tác vụ. Tầng 2 (Domain Expert) — model chuyên biệt xử lý từng miền hẹp. Tầng 3 (Micro-execution) — model nhỏ hoặc regex/AST thực thi thao tác tất định. Tầng 4 (Verification) — compiler/linter kiểm định lần cuối, không có AI. Mũi tên feedback từ tầng 4 ngược lên tầng 2-3 cho phép tự sửa lỗi mà không cần khởi động lại toàn bộ pipeline.

Thay vì bắt một model duy nhất gánh vác mọi thứ, một kiến trúc AI được thiết kế đúng nên vận hành qua các tầng với entropy giảm dần — mỗi tầng chỉ xử lý một phần công việc tương xứng với năng lực của nó:

Tầng Orchestration (Model lớn, entropy cao → trung bình):

Tiếp nhận yêu cầu ngôn ngữ tự nhiên phức tạp.
Nhiệm vụ: hiểu ý đồ, phân rã thành các tiểu tác vụ.
Đây là nơi duy nhất cần "sự thông minh tổng quát" — và cũng là nơi scaling laws phát huy tác dụng tối đa.
Dẫn chứng: GPT-4 có thể hiểu một câu lệnh mơ hồ như "sửa bug trong codebase" và phân rã nó thành các bước cụ thể nhờ khả năng suy luận (reasoning) bộc phát từ quy mô lớn.
Chi phí: Đây là tầng đắt nhất trong toàn bộ pipeline — cần model tổng quát ở lớp lớn nhất, gọi qua API cloud với giá ~$0.01–0.03/1K token (tham khảo GPT-4, Claude Opus). Tuy nhiên, tầng này chỉ được gọi một lần duy nhất cho mỗi yêu cầu, và output của nó chỉ là một danh sách tác vụ ngắn gọn (vài trăm token), nên tổng chi phí thực tế cho mỗi lần gọi thường chỉ vài cent.

Tầng Domain Expert (Model trung bình, entropy trung bình → thấp):

Xử lý từng tiểu tác vụ trong một phạm vi kiến thức hẹp.
Được fine-tune hoặc prompt chuyên biệt cho một domain (ví dụ: chỉ xử lý code C#, chỉ phân tích log, chỉ viết documentation).
Entropy không gian đầu ra đã bị thu hẹp đáng kể so với tầng 1.
Dẫn chứng: Trong phạm vi hẹp là sinh mã, một model chuyên biệt cỡ nhỏ có thể sánh ngang model tổng quát lớn hơn nhiều lần. Theo báo cáo của nhóm DeepSeek⁸, DeepSeek-Coder-6.7B-Instruct đạt 78.6% pass@1 trên HumanEval (Python), cao hơn GPT-3.5-Turbo (76.2%) đo trên cùng benchmark — dù trên MBPP thì lại thấp hơn (65.4% so với 70.8%). Cần đọc con số này đúng phạm vi của nó: đây là benchmark sinh hàm ngắn, không phải bằng chứng về năng lực tổng quát.
Chi phí: Rẻ hơn tầng 1 khoảng 10–100 lần. Các model 7B–70B có thể tự host trên GPU tầm trung (ví dụ: một NVIDIA A10G xử lý model 7B với giá ~$0.0001–0.001/1K token), hoặc gọi qua các API giá rẻ như DeepSeek, Together AI. Nếu self-host, chi phí cố định theo tháng thay vì tính theo token — càng dùng nhiều càng rẻ.

Tầng Micro-execution (Model nhỏ / quy tắc cứng, entropy thấp → zero):

Thực thi các thao tác tất định (đổi tên biến, format code, kiểm tra cú pháp).
Có thể là NLM (Nano Language Model) chạy local, hoặc đơn giản là Regex + AST Parser.
Entropy output = gần như zero — kết quả tất định, có thể kiểm chứng.
Dẫn chứng: Một mô hình BERT nhỏ (110M tham số) fine-tuned cho tác vụ phát hiện lỗi cú pháp có thể chạy trên CPU laptop với latency < 50ms, trong khi GPT-4 cần vài giây và kết nối internet.
Chi phí: Gần như bằng 0 khi dùng quy tắc cứng (regex, AST parser). Với NLM (~100M–500M tham số), model chạy hoàn toàn trên CPU người dùng, không cần GPU, không cần internet, không phát sinh chi phí API. Chi phí duy nhất là tài nguyên máy cục bộ — tương đương chạy một ứng dụng desktop nhẹ. Latency < 50ms cho mỗi thao tác.

Tầng Kiểm định (Zero entropy):

Chốt chặn cuối: compiler, linter, unit test.
Nếu phát hiện lỗi, gửi feedback ngược về tầng trên để tự sửa.
Không có AI ở tầng này — chỉ có logic tất định, không thể sai.
Chi phí: Bằng 0 về mặt inference AI. Compiler, linter, và test runner là các công cụ tất định đã có sẵn trong mọi toolchain phần mềm — chạy trong mili-giây, không tốn tài nguyên đáng kể. Đây là tầng "miễn phí" nhưng lại mang giá trị bảo chứng cao nhất trong toàn pipeline.

Nguyên lý vận hành: mỗi tầng chỉ giảm entropy một lượng vừa phải — không tầng nào phải thực hiện một "bước nhảy entropy tử thần". Kiến trúc này giống như một dây chuyền sản xuất, nơi nguyên liệu thô (high entropy) được tinh chế dần qua từng công đoạn.

4.3. Hướng Đến Job Runtime — Mô Hình Thực Thi Bất Đồng Bộ

Kiến trúc phân tầng trên gợi ý một mô hình thực thi khác biệt căn bản với giao diện chat truyền thống:

Thay vì stream (AI gõ từng chữ trong thời gian thực), hệ thống nên vận hành theo cơ chế job bất đồng bộ: nhận yêu cầu → xử lý ngầm → trả kết quả đã kiểm định.

Mô hình này có một số ưu điểm:

Xử lý song song: Các tiểu tác vụ độc lập có thể chạy đồng thời trên nhiều model nhỏ, thay vì chờ một model lớn xử lý tuần tự.
Kiểm định trước khi trả: Mọi output đều được xác thực qua compiler/linter trước khi đến tay người dùng — không có khái niệm "AI nói gì thì tin đó".
Rollback vi mô: Nếu một tiểu tác vụ thất bại, chỉ rollback và chạy lại tác vụ đó, thay vì phải làm lại toàn bộ.

4.4. Tóm Lược: Từ Lý Thuyết Đến Kiến Trúc

Tầng	Công cụ gợi ý	Entropy (minh họa)*	Chi phí ước tính	Vai trò
Orchestration	GPT-4, Claude Opus	1,000,000 → 1,000	~$0.01–0.03 / 1K token (API)	Hiểu & phân rã yêu cầu
Domain Expert	CodeLlama, DeepSeek-Coder (7B-70B)	1,000 → 50	~$0.0001–0.001 / 1K token	Xử lý chuyên biệt
Micro-execution	NLM, BERT small, Regex, AST	50 → ~1	~$0 (chạy local CPU)	Thực thi tất định
Verification	Compiler, Linter, Unit Test	~1 → 1 (đã kiểm định)	$0 (công cụ tất định)	Bảo chứng chất lượng

Các giá trị entropy là con số minh họa tương đối — xem lưu ý tại mục 3.6.

Không một model đơn lẻ nào, dù lớn đến đâu (dù scaling laws có đưa nó đến đâu), có thể vượt qua kiến trúc phân tầng này về độ tin cậy và hiệu quả chi phí — bởi vì một model đơn lẻ buộc phải vi phạm Nguyên lý II về Gradient Entropy.

5. Kết Luận: Trả Công Cụ Về Đúng Vị Trí Của Nó

Sau tất cả những tranh luận, Generative AI không phải là một vị thần toàn năng có thể giải quyết mọi bài toán chỉ bằng một câu lệnh mơ hồ. Nó cũng không phải là một trò bịp bợm vô nghĩa chỉ biết lặp lại các xác suất vô hồn. Nó là một máy dịch Entropy — một chiếc cầu nối kỳ diệu giữa thế giới ngôn ngữ tự nhiên hỗn độn của con người và thế giới logic tất định của máy tính. Ba góc nhìn mà chúng ta thảo luận ở đầu bài không hề mâu thuẫn. Người làm AI đúng khi chỉ ra bản chất xác suất của nó. Người dùng đúng khi kinh ngạc trước khả năng ứng biến linh hoạt. Và người thiết kế hệ thống đúng khi nhìn thấy ở nó một công cụ cần được kiểm soát nghiêm ngặt. Bản chất của AI không thay đổi. Thứ cần thay đổi là cách chúng ta thiết kế hệ thống xung quanh nó. Nếu Generative AI là một máy dịch Entropy, thì một hệ thống phần mềm cần được cấu trúc như thế nào để tận dụng nó mà không bị nuốt chửng bởi sự hỗn độn? Làm sao để kiểm soát một công cụ mang tính xác suất và ép nó tạo ra những kết quả có tính tất định tiệm cận 100%? Đó không còn là câu hỏi triết lý. Đó là một bài toán kiến trúc cụ thể. Khi chúng ta dũng cảm bóc tách lớp màn "ma thuật", trả AI về đúng vị trí của nó — một tầng dịch chuyển Entropy trong một kiến trúc phân tầng nghiêm ngặt — chúng ta sẽ mở ra những cách tiếp cận hoàn toàn mới, nơi AI đóng vai trò là những bánh răng dịch chuyển thông tin mượt mà trong một cỗ máy được kiểm soát chất lượng tuyệt đối.

Bài viết này là một phần trong chuỗi nghiên cứu về kiến trúc cAgent và NLM (Nano Language Model) — hệ thống agent thế hệ mới được xây dựng trên nền tảng triết lý Entropy Translation. Bài tiếp theo: "Phẫu Thuật Từ Điển: Sự Vô Lý Của Vocab Lớn Trên Các Model Nhỏ".

Lời ngỏ: Những gì trình bày ở đây là một lăng kính, không phải một chân lý. Mô hình "máy dịch Entropy" tỏ ra hữu ích với chúng tôi khi thiết kế hệ thống, nhưng chắc chắn vẫn còn chỗ chưa chặt chẽ, đặc biệt ở phần định lượng entropy và ở kiến trúc phân tầng còn đang trong giai đoạn đề xuất. Nếu bạn thấy điểm nào sai, thiếu, hoặc có trải nghiệm thực tế đi ngược lại lập luận trong bài, rất mong nhận được góp ý ở phần bình luận. Mọi phản biện đều giúp bài viết và cả kiến trúc mà chúng tôi đang xây dựng trở nên tốt hơn.

Tác giả: Trần Đình Lâm Anh (anhtdl@alf.vn), Nguyễn Thế Chiến (chiennt@alf.vn)

Tài liệu tham khảo

¹ Mata v. Avianca, Inc., No. 22-cv-1461 (S.D.N.Y. June 22, 2023) — Opinion sanctioning lawyers Schwartz and LoDuca for submitting fictitious ChatGPT-generated legal citations. Xem thêm: Bloomberg Law, "Fake ChatGPT Cases Cost Lawyers $5,000 Plus Embarrassment" (June 22, 2023).

² BBC News, "Google's Bard AI bot mistake wipes $100bn off shares" (February 8, 2023). Xem thêm: CNN Business, "Google shares lose $100 billion after company's AI chatbot makes an error during demo" (February 8, 2023).

³ Li, K., Hopkins, A. K., Bau, D., Viégas, F., Pfister, H., & Wattenberg, M. (2022). Emergent World Representations: Exploring a Sequence Model Trained on a Synthetic Task. arXiv preprint arXiv:2210.13382 (ICLR 2023).

⁴ Kaplan, J., McCandlish, S., Henighan, T., Brown, T. B., Chess, B., Child, R., ... & Amodei, D. (2020). Scaling laws for neural language models. arXiv preprint arXiv:2001.08361.

⁵ Wei, J., Wang, X., Schuurmans, D., Bosma, M., Chi, E., Le, Q., & Zhou, D. (2022). Chain of thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35, 24824-24837.

⁶ Schaeffer, R., Miranda, B., & Koyejo, S. (2023). Are Emergent Abilities of Large Language Models a Mirage? In Advances in Neural Information Processing Systems (NeurIPS).

⁷ Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., ... & Polosukhin, I. (2017). Attention is all you need. In Advances in Neural Information Processing Systems.

⁸ Guo, D., Zhu, Q., Yang, D., Xie, Z., Dong, K., Zhang, W., et al. (2024). DeepSeek-Coder: When the Large Language Model Meets Programming — The Rise of Code Intelligence. arXiv preprint arXiv:2401.14196.

Xem thêm: Luo, Y., et al. (2023). An Empirical Study of Catastrophic Forgetting in Large Language Models During Continual Learning. arXiv preprint arXiv:2308.08747.