Kết luận trong 5 giây
Điều thực sự hiệu quả trong tự động hóa bằng AI không phải là câu trả lời đầu tiên ra nhanh. Mà là ít phải làm lại nhất cho đến khi xong hẳn.
Một hệ thống sản xuất bài viết, sau vài ngày đến khoảng một tuần cải tạo dồn dập, đã đi từ "thứ nhờ AI viết rồi lưu lại" thành một nhà máy tự vận hành nhỏ, có giám sát, chạy lại, kiểm soát xung đột, lưu giữa chừng, cô lập lỗi, cổng chất lượng và quản lý bằng chứng.
Thứ phát huy tác dụng trong đợt đại tu đó là cách nghĩ dùng ultra ngay từ đầu mỗi thay đổi thiết kế lớn. Đây là chế độ không chỉ bắt GPT-5.6 Sol suy nghĩ sâu hơn, mà còn chạy song song nhiều việc cùng lúc.
Mỗi lần chạy thì nặng. Nhưng về sau những chuyện kiểu "chỗ này hóa ra hỏng từ trước", "chạy song song gây tai nạn", "không có bằng chứng", "lại phải làm lại hết" ít đi. Kết quả là tổng thời gian ngắn lại.
Nói bằng ngôn ngữ nhà máy: thời gian mỗi chu kỳ dài, nhưng tỷ lệ phải làm lại thấp, nên tổng thời gian từ đầu đến khi giao hàng (lead time) ngắn.
Lưu ý trước: Level 6 và Level 7 không phải thứ hạng chung của thế giới
Level 6 và Level 7 trong bài này không phải cấp độ trong game, cũng không phải tiêu chuẩn ISO. Đó chỉ là những cái nhãn mình đặt riêng cho hệ thống này để giải thích dễ hiểu mức độ trưởng thành của tự động hóa.
Nền tảng ý tưởng gần với "điện toán tự quản" (autonomic computing) mà IBM đã nghiên cứu từ lâu. IBM tổng kết các đặc tính chính của một hệ thống tự quản là: tự cấu hình, tự sửa chữa, tự tối ưu và tự bảo vệ.
Trong bài này, mình gọi giai đoạn hệ thống tự quay về trạng thái đúng là Level 6, và giai đoạn nó còn tự tìm cách vận hành tốt hơn trong phạm vi an toàn là Level 7.
Ban đầu chỉ là "nhờ AI viết bài". Bất giác blog mọc ra cả hàng rào
Tự động hóa viết bài thông thường rất đơn giản:
- Chạy vào giờ cố định.
- Cho AI tạo văn bản.
- Lưu thành tệp.
- Đưa lên GitHub.
- Nếu thất bại thì người vào xem.
Chừng đó đã khá tiện.
Nhưng khi số bài tăng lên, thành 12 ngôn ngữ, rồi tự động hóa cả kiểm định chất lượng, liên kết nội bộ, cập nhật và quyết định xuất bản, vấn đề đổi khác.
Trọng tâm không còn là "viết được không", mà là những câu hỏi như sau:
- Nếu hai worker (chương trình thực hiện tác vụ) cùng đụng vào một bài thì sao?
- Nếu chết giữa chừng thì tiếp tục từ đâu?
- Làm sao để việc đã thất bại không bị thử lại mãi mãi?
- Có đang dùng lại kết quả kiểm tra cũ như thể là kết quả mới không?
- AI có đang tự ý nói "người đã xác nhận" không?
- Ai chặn một bài ở trạng thái không được phép xuất bản?
- Làm sao để cả nhà máy không dừng khi một dịch vụ bên ngoài chết?
- Màn hình hiện "100 điểm", nhưng 100 điểm đó có thật sự đo trạng thái hiện tại không?
Đến đây thì không còn là "tự động hóa blog" nữa.
Đó là một hệ thống sản xuất nhỏ lấy nội dung làm nguyên liệu.
Level 6: Hỏng rồi vẫn tự quay về trạng thái đúng
Nói gọn, Level 6 của nhà máy này là cơ chế tự quay về đáp án đúng đã được cố định.
Các thành phần chính như sau.
| Cơ chế | Nếu giải thích cho học sinh cấp 2 |
|---|---|
| desired state | Quy định "đáp án đúng" dưới dạng máy đọc được |
| reconciliation | So trạng thái hiện tại với đáp án đúng, khác thì sửa |
| lease / fencing | Không để hai người tự ý làm cùng một việc cùng lúc |
| checkpoint | Lưu chính thức việc đã làm xong đến đâu |
| CAS | Không dùng trạng thái cũ để ghi đè trạng thái mới |
| transactional outbox | Xử lý sự lệch kiểu phần chính thành công mà chỉ phần thông báo thất bại |
| retry / quarantine | Lỗi tạm thời thì thử lại, dữ liệu "độc" thì cách ly |
| safe publication gate | Chưa đạt điều kiện chất lượng thì không cho xuất bản |
| failure injection | Cố ý phá hỏng để thử xem có phục hồi thật không |
| observability | Làm cho việc cái gì đang chạy, cái gì đang lỗi đo được |
Trong một ảnh chụp vận hành, cả 21 yêu cầu thiết kế của Level 6 đều PASS và điểm triển khai phần điều khiển là 100. Tuy nhiên, điểm bảo đảm, gồm cả đo lường từ bên ngoài, xác nhận của con người và thành tích dài hạn của toàn bộ worker, chỉ khoảng 69%, việc xuất bản vẫn ở HOLD và Level 7 vẫn OFF.
Chỗ này quan trọng.
100 điểm về triển khai và 100 điểm đủ để yên tâm bỏ mặc là hai chuyện khác nhau.
Dù mọi bài kiểm thử đều qua, bằng chứng cho việc đã thực sự chạy một tuần, một tháng, nửa năm thì không thể tạo ra nếu không bỏ thời gian.
Suy luận sâu của Sol và Ultra: "một người ngồi nghĩ lâu" khác với "nhiều người làm song song"
Theo mô tả chính thức của OpenAI, GPT-5.6 Sol có max để suy luận sâu, và ultra là thiết lập năng lực cao cho nhiều tác tử (agent) phối hợp theo các luồng công việc song song.
Hãy ví dụ thế này.
Khi bắt Sol suy nghĩ sâu
Nhốt một nhà thiết kế giỏi trong phòng họp.
"Không cần vội. Đọc hết mã và tài liệu. Tìm cả những chỗ mâu thuẫn. Nghĩ đến cùng."
Cách này rất mạnh.
Trường hợp Ultra
Nhà thiết kế, người triển khai, người tìm lỗi, người chuyên phá và người kiểm thử cùng chạy một lúc, cuối cùng gộp kết quả.
Nói ngắn gọn, không phải trí thông minh đơn giản nhân đôi, mà là hướng bỏ sót bị phân tán ra.
Theo số liệu OpenAI công bố, ở Terminal-Bench 2.1, GPT-5.6 Sol đạt 88,8% còn Sol Ultra đạt 91,9%. Chênh lệch là 3,1 điểm, nhưng nhìn từ phía thất bại thì từ 11,2% xuống 8,1%, tính đơn giản là tỷ lệ thất bại giảm khoảng 28%. Tất nhiên đây chỉ là một bài đánh giá, không có nghĩa là mọi công việc đều giảm 28% thất bại.
Tuy vậy, với những việc chia nhỏ được như "đọc một kho mã khổng lồ, thiết kế, triển khai, phá thử rồi kiểm chứng lại", hướng của sự chênh lệch này khá dễ thấy.
Vì sao Ultra nặng nề lại hóa ra nhanh hơn
Thời gian đến khi hoàn thành có thể hình dung đại khái như sau:
tổng lead time = triển khai lần đầu + làm lại + kiểm thử lại + xử lý sự cố + sửa hiểu nhầm
Nhiều người chỉ nhìn vào số hạng đầu tiên, "triển khai lần đầu".
Vì vậy AI trả lời trong 30 phút trông nhanh, còn AI mất 2 giờ trông chậm.
Nhưng nếu bản 2 giờ xóa được 6 giờ làm lại sẽ phát sinh về sau, thì bản 2 giờ nhanh hơn.
Ngành sản xuất cũng vậy.
Một nhà máy làm nhanh rồi loại bỏ hàng loạt ở khâu kiểm tra, rốt cuộc chậm hơn một nhà máy nâng năng lực quy trình ngay từ đầu để không tạo ra hàng lỗi.
Điều thú vị ở lần "Ultra một phát" này là phần lớn vấn đề phát hiện về sau không phải loại phải đập đi làm lại thiết kế gốc.
Những thứ được mài giũa ở các công đoạn sau, chẳng hạn:
- Muốn xem trên một trang bằng chứng rằng tất cả worker thật sự đã xử lý dữ liệu thật.
- Đừng dùng 50/50 cũ làm 50/50 của lần kiểm định mới.
- Đừng ghi đánh giá của AI thành đánh giá của con người.
- Nếu không có đo lường bên ngoài thì ghi "không rõ".
- Dù worker không làm gì, nếu đó là NOOP đúng (không có việc để làm nên cố ý đứng yên) thì đừng coi là thất bại.
Đây không phải chuyện "cột lắp ngược nên phải xây lại nhà".
Nó giống như bộ phận kiểm soát chất lượng bước vào một nhà máy đã xây xong rồi soi cả nhãn trên đường ống lẫn việc hiệu chuẩn đồng hồ đo.
Vì sao "Ultra một chảo" lại hiệu quả
Không phải là mọi thứ hoàn hảo ngay trong một lần.
Chính xác hơn, vì tư tưởng thiết kế ban đầu khá đúng nên những chỉnh sửa về sau chỉ mang tính cục bộ.
Điều quan trọng là ngay từ đầu đã đưa được những câu hỏi sau vào thiết kế:
- Nếu chạy đồng thời thì sao?
- Nếu chết giữa chừng thì sao?
- Nếu xử lý hai lần thì sao?
- Nếu ghi trong khi đang giữ trạng thái cũ thì sao?
- Nếu chỉ riêng API bên ngoài chết thì sao?
- Nếu dữ liệu lỗi quay vòng mãi thì sao?
- Nếu chính khâu kiểm tra bị hỏng thì sao?
- Nếu có kẽ hở để nói dối rằng "tất cả đều thành công" thì sao?
Thông thường, người ta học những điều này từng cái một qua sự cố trên môi trường thật.
Lần này, mình đã gây ra trước các "tai nạn lao động ảo".
Làm sập máy chủ ngay trong bài kiểm thử trước khi nó sập thật. Để CI phải khóc trước khi con người phải khóc.
Cách nghĩ này cũng hợp với chaos engineering (kỹ thuật hỗn loạn). Ở đó, trạng thái bình thường được định nghĩa theo cách đo được, những sự cố có thật ngoài đời được cố ý đưa vào, rồi kiểm tra xem trạng thái bình thường có sụp không.
Xét theo mặt bằng chung thì đến cỡ nào
Phần này không nên nói quá thì mới thú vị.
Nói "đây là hệ thống mạnh nhất thế giới" là quá lời.
Nhưng cũng không chỉ là "viết blog bằng AI".
Muốn định vị thì có thể hình dung như sau:
| Đối tượng so sánh | Khoảng cách |
|---|---|
| Nhờ AI viết bài rồi lưu lại | Đi trước khá xa |
| Tự động hóa nối tiếp kiểu Zapier / n8n | Hơn ít nhất một bậc về phục hồi sự cố và kiểm soát xung đột |
| Backend nghiêm túc của một SaaS cá nhân | Có khá nhiều yếu tố thiết kế cùng đẳng cấp |
| Nền tảng tự động hóa nội bộ của doanh nghiệp vừa và nhỏ | Hoàn toàn đáng để so sánh |
| Dịch vụ thương mại trưởng thành có SRE (kỹ sư đảm bảo độ ổn định) chuyên trách | Vẫn kém ở thành tích vận hành dài hạn, giám sát từ bên ngoài và bảo đảm an ninh |
| Hạ tầng khổng lồ cỡ Google hay Amazon | Quy mô khác hẳn một vũ trụ |
Điều lạ của một dự án cá nhân là lượng mã mọc ra cho cách ứng xử khi thất bại còn nhiều hơn cả chức năng viết bài.
Khi lease, fencing, CAS, outbox, quarantine và failure injection đến ở trong nhà máy viết bài, thì nó không còn là blog nữa mà giống một trung tâm logistics.
Level 7: Giám đốc nhà máy bắt đầu tự thử các đề xuất cải tiến
Ở Level 6, "đáp án đúng" do con người quyết định.
Hỏng thì quay về đáp án đó.
Ở Level 7, trong phạm vi của đáp án đúng, hệ thống tự tìm cách vận hành tốt hơn.
Hình dung như sau:
- Đo đồng thời chất lượng, tốc độ, chi phí, thời gian chờ và tỷ lệ thất bại.
- Làm cho các điều kiện an toàn tuyệt đối không thể thay đổi.
- Thử prompt và thứ tự xử lý mới ở chế độ shadow (chạy thử song song, không ảnh hưởng hệ thống thật).
- Nếu thấy ổn thì mở rộng bằng canary (phát hành từng bước): 5%, 20%, 100%.
- Nếu chất lượng tụt thì tự động quay lại.
- Khi độ tin cậy kém, chỉ dừng thử nghiệm, vẫn giữ sản xuất bình thường.
- Ghi vào sổ thí nghiệm đã thử gì, cái gì tốt và vì sao được áp dụng.
Cách này gần với việc kết hợp self-optimization (tự tối ưu) trong điện toán tự quản của IBM, error budget của Google SRE (lượng lỗi có thể chấp nhận trước khi phải phanh lại) và canary cùng rollback của AWS.
Tuy nhiên, không cần đưa Level 7 vào chạy thật ngay bây giờ.
Lý do rất đơn giản: mình vẫn đang thu thập thành tích dài hạn của Level 6.
Khi còn đang kiểm tra xem thiết bị có ổn định không mà đã nói với giám đốc nhà máy AI "từ hôm nay tốc độ dây chuyền cũng được tự ý đổi", thì việc tách nguyên nhân sẽ rất phiền.
Nếu làm gì bây giờ thì không phải bản thân Level 7, mà là tăng cường khả năng quan sát, gom hoạt động thực tế của toàn bộ worker lên một trang.
Tháng phải trả tiền, hãy coi là "tháng đầu tư thiết bị"
Không cần dùng Ultra cho những việc nhẹ hằng ngày.
Với sửa nhỏ, kiểm định theo khuôn mẫu, hay xử lý worker đã định sẵn, Sol thường hoặc suy luận sâu là đủ trong nhiều trường hợp.
Ultra phát huy ở những việc mà nếu thất bại thì phải làm lại rất tốn công:
- Thiết kế lại toàn bộ hệ thống
- Refactor quy mô lớn
- Tái tổ chức hệ thống worker
- Thiết kế giám sát và phục hồi
- Rà soát lại ranh giới bảo mật
- Nền tảng shadow cho Level 7
- Bổ sung số lượng lớn kiểm thử và failure injection
Vì vậy cách dùng hợp lý là ngày thường cứ vận hành nhà máy, gom các chủ đề đại tu lại, rồi đầu tư thiết bị một lượt vào thời điểm có thể dùng chế độ cao cấp.
Thay vì coi tiền AI là "phí hằng tháng để mỗi ngày thông minh hơn một chút", hãy coi nó là chi phí thi công để đập đi xây lại nền móng trong một lần.
Nghĩ vậy thì không cần so sánh giá trị của mô hình nặng chỉ qua giá mỗi câu trả lời.
Bài học lớn nhất của khoảng một tuần này
Bài học lớn nhất là đừng chỉ đo độ thông minh của AI bằng "tỷ lệ trả lời đúng".
Trong công việc thực tế, năm điều sau mới có tác dụng:
- Độ chính xác của thiết kế ban đầu — về sau có phải phá hết đi không.
- Khả năng phản biện — có tự đập được phương án của mình không.
- Tính song song — có tách được thiết kế, triển khai, kiểm thử, kiểm định để làm cùng lúc không.
- Tính bằng chứng — không phải "cảm giác là đã chạy", mà lưu lại được cái gì đã chạy.
- Khả năng phục hồi — thất bại rồi có tự quay lại mà không cần gọi người không.
Nói cách khác, một nhà máy AI tốt không phải "nhà máy không thất bại".
Đó là nhà máy coi thất bại là điều chắc chắn xảy ra, thất bại vẫn không dừng, không báo thành công giả, và quay lại được từ bất cứ đâu.
Kết luận: Nhanh là nhanh đến đích cuối cùng
Nếu chỉ kết luận lý do đi được xa thế này trong khoảng một tuần là "AI nhanh khủng khiếp" thì sẽ bỏ lỡ bản chất.
Điều có tác dụng là dồn nhiều tài nguyên tính toán vào thiết kế đầu tiên, rồi sau đó quay lại vận hành thường ngày với chi phí rẻ.
Ultra không phải nút đáp án thần kỳ. Nó giống thiết bị trả trước để dập tắt việc làm lại.
Dù mỗi lần xử lý chậm, nếu tổng thời gian đến khi hoàn thành ngắn thì vẫn là nhanh.
Và điều cần ở giai đoạn này không phải vội lắp Level 7 thông minh hơn.
Mà là để Level 6 chạy một thời gian, xem nó có thật sự tiếp tục tự làm việc không.
Khi nhà máy trông có vẻ rảnh rỗi, lúc đó hẵng trao quyền cải tiến cho giám đốc nhà máy AI.
Còn bây giờ, đưa cho giám đốc nút tự ý đổi tốc độ dây chuyền thì vui quá mức mất.
- OpenAI, GPT-5.6: https://openai.com/index/gpt-5-6/
- OpenAI, GPT-5.6 (bản tiếng Nhật): https://openai.com/ja-JP/index/gpt-5-6/
- IBM Research, Autonomic computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- IBM Research, Utility functions: https://research.ibm.com/publications/achieving-self-management-via-utility-functions
- Google SRE, Error Budget Policy: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS, Amazon ECS canary deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
