Mở đầu: Ảo tưởng kiểm soát — khi phần mềm thôi chạy đều như đồng hồ

I. Từ máy bán nước đến chatbot #

Phần mềm từng chạy đều như đồng hồ: cùng đầu vào, cùng kết quả. AI và các hệ thống phân tán đã phá vỡ lời hứa đó. Loạt bài này giải thích nguyên nhân, và cách dựng hàng rào để hệ thống chỉ sai trong giới hạn đã định.

Bỏ tờ 10 nghìn vào máy bán nước, máy nhả ra một lon. Bấm cho chatbot trả lời lại cùng một câu hỏi, bạn thường nhận một câu trả lời khác. Máy bán nước mà làm vậy thì người ta gọi thợ; với chatbot, đó là đúng thiết kế.

Suốt sáu thập kỷ, phần mềm chạy như chiếc máy bán nước. Code là những câu lệnh viết sẵn kiểu if-else: nếu điều kiện này đúng thì làm việc kia. Cùng đầu vào, chạy một nghìn lần vẫn ra một kết quả; hỏng thì lần ngược được về đúng một dòng code.

Vài năm gần đây, với những bài toán khó như hiểu ngôn ngữ, người ta không còn viết if-else thủ công. Thay vào đó, họ huấn luyện mô hình AI bằng cách cho nó dự đoán trên lượng dữ liệu khổng lồ, rồi chỉnh hàng tỉ con số bên trong để lần sau bớt sai. Những con số đó gọi là trọng số; không ai viết tay chúng, kể cả người huấn luyện.

Đó là bước nhảy từ Software 1.0 sang Software 2.0¹: hành vi của phần mềm chuyển từ code do người viết sang trọng số học từ dữ liệu.

LLM là loại mô hình AI đứng sau các chatbot như ChatGPT. Mỗi lần viết thêm, nó tính xác suất cho mọi mẩu chữ có thể đứng tiếp rồi rút thăm theo đó. Nó chọn theo khả năng chứ không kiểm tra câu nào đúng, nên đọc code không còn cho biết hệ thống sẽ trả lời gì.

Người làm phần mềm vì thế mất dần quyền kiểm soát. Prompt là đoạn chỉ dẫn ta gõ cho LLM. Giờ prompt hay được chỉnh theo cảm giác: thêm câu “hãy trả lời chính xác”, chạy thử vài lần, thấy có vẻ khá hơn, không ai đo khá hơn bao nhiêu. Giới làm AI gọi thói quen đó là vibe-tuning².

Tệ hơn, mô hình có thể bịa ra một câu trả lời trôi chảy, tự tin mà sai, và không có dòng code nào để lần ngược xem vì sao. Hiện tượng đó gọi là ảo giác.

Loạt bài Ảo tưởng kiểm soát viết ra để lấy lại quyền kiểm soát đó, theo một kiểu khác. Kiểm soát từng kết quả là ảo tưởng. Thứ lấy lại được là quyền nói trước hệ thống được sai tới đâu rồi chặn ở đó, thay vì chỉ thiết kế cho lúc suôn sẻ. Nhưng AI mới là một nửa câu chuyện.

II. Loạt bài đi qua bốn chặng #

Nửa còn lại không cần tới AI. Phía sau một app giao đồ ăn thường là nhiều service nói chuyện với nhau qua mạng. Service là một phần mềm chạy trên server, lo một việc như thanh toán hay tìm tài xế. Hệ ghép kiểu này có thể đứng hình dù không bộ phận nào hỏng.

Giờ tan tầm ở TP.HCM, đường kín xe máy, cũng vậy: một cú phanh gấp có thể làm cả đoạn đường đứng lại, dù phía trước chẳng có tai nạn. Trên giấy, từng service đều chạy đúng, cũng như từng người lái đều đúng luật. Trên đường, cả đoạn vẫn đứng yên.

Tôi đi từ gốc, cái dân kỹ thuật gọi là First Principles³, và mượn công cụ từ toán và vật lý để giải thích những chuyện như vậy. Lần nào tôi cũng quay về một câu hỏi: với phần mềm, điều này nghĩa là gì. Kế hoạch hiện có 16 bài, chia bốn giai đoạn:

• Giai đoạn I — Tháo rời niềm tin cũ (Bài 01–03). LLM phá lời hứa “cùng đầu vào, cùng kết quả”. Chia hệ thống thành nhiều service làm số tình huống cần lường trước tăng vọt. Sự cố lớn hiếm khi có một nguyên nhân gốc duy nhất.
• Giai đoạn II — Bộ đồ nghề (Bài 04–07). Vì sao hệ thống càng lớn càng dễ sinh ra điểm nghẽn mà ai cũng phụ thuộc. Vì sao hệ thống tự trôi về sát mép sụp đổ, và đứng hình khi quá tải thay vì chậm dần. Bài 07 bàn về cách lỗi lan rộng trong mạng lưới.
• Giai đoạn III — Thiết kế (dự kiến Bài 08–11). Vì sao tự động thử lại yêu cầu lỗi có thể đánh sập hệ thống, cách tự thêm bớt server mà không quá tay, và Chaos Engineering. Chaos Engineering là cố ý bơm lỗi, như đầu vào rác hay một máy bị tắt ngang, để tìm chỗ gãy trước người dùng.
• Giai đoạn IV — Con người và tổ chức (dự kiến Bài 12–16). Cách chia đội ngũ in dấu lên cấu trúc phần mềm. Giới hạn của AI khi phải hiểu nguyên nhân gốc. Bài khép lại bàn về việc đổi vai: từ người thợ xây đặt từng viên gạch, sang người làm vườn đặt điều kiện và cắt tỉa.

Sáu bài đầu đã đăng. Vậy không viết code thì đọc chúng làm gì?

III. Vì sao người không viết code cũng nên đọc #

Loạt bài viết cho mọi người làm cùng một hệ thống: PM, BA, tester, designer, sinh viên, người chuyển ngành, dev mới đi làm. Bạn có thể không vận hành server, nhưng bạn có mặt ở những lúc trực giác cũ dẫn tới quyết định sai:

• Khi bàn một tính năng AI. Hãy hỏi “nó được phép sai bao nhiêu, và lúc sai thì cái gì chặn”, thay vì “nó có đúng không”.
• Khi đọc dashboard. Server báo CPU bận 80%, không lỗi nào. Hỏi tôi server còn dư bao nhiêu, phản xạ đầu tiên của tôi vẫn là “20%”. Bài 05 và 06 giải thích vì sao đó không phải 20% an toàn.
• Khi đọc báo cáo sự cố. Bài 03 giải thích vì sao một nguyên nhân gốc hiếm khi kể đủ chuyện.

Bạn không cần nền vật lý thống kê, lý thuyết đồ thị hay giải tích. Công thức và code nằm trong các khối “Đào sâu” thu gọn, kèm câu đọc bằng lời và con số cụ thể. Nếu bỏ qua hết, bạn vẫn theo sát được lập luận từ đầu tới cuối. Phần toán nằm đó để kiểm chứng lập luận, không phải để hiểu nó.

Tìm hướng dẫn dùng ChatGPT? Sai chỗ rồi. Tìm cách rào một hệ thống chỉ đúng theo xác suất? Đúng chỗ rồi.

IV. Nên bắt đầu từ Bài 01 #

Nên đọc Bài 01 trước; bài này mượn luôn tên cả loạt. Bài lập luận rằng ảo giác và việc lặp mãi một câu là hệ quả của cách LLM rút thăm từng mẩu chữ, không phải bug vá được bằng thêm một câu if. Mỗi mẩu mới viết tiếp trên các mẩu cũ, nên một mẩu sai có thể kéo cả phần sau đi theo; và không gì bảo đảm chuỗi rút thăm dừng sau bao nhiêu bước.

Rồi bài dựng ba lớp hàng rào: chặn đầu ra sai định dạng, cam kết tỉ lệ lỗi bằng số, và đặt cầu dao bên trong mô hình. Lớp thứ hai dùng Conformal Risk Control. Kỹ thuật thống kê này cho phép nói “đầu ra sai không quá 5% số lần”, tính trung bình, và kiểm chứng câu đó bằng số liệu. Cái giá là những câu mô hình không đủ chắc phải chuyển cho người xử lý.

“Sai không quá 5%” nghe khá giống một lời thanh minh soạn sẵn. Khác ở chỗ con số đó đo và kiểm lại được, còn “chắc là ổn” thì không.

Nghề viết code đang chuyển dần thành nghề thiết kế hệ thống.