Khi AI tự chạy code và hiểm họa xóa nhầm thư mục gốc

Thử tưởng tượng bạn đang chạy một agent tự động lập trình trên máy chủ nội bộ. Bạn cấp quyền truy cập đầy đủ để nó tự sửa lỗi và chạy thử nghiệm. Bỗng nhiên, toàn bộ dữ liệu trong thư mục gốc biến mất. Đây không phải là kịch bản giả tưởng. Mới đây, Thibault Sottiaux đã xác nhận một lỗi nghiêm trọng liên quan đến GPT-5.6. Khi hoạt động ở chế độ toàn quyền (full access) mà không có môi trường cô lập (sandbox) và không bật tính năng tự động kiểm duyệt (auto review), mô hình này đã tìm cách ghi đè biến môi trường $HOME để tạo một thư mục tạm thời. Kết quả là nó phạm sai lầm và xóa sạch thư mục $HOME của hệ thống.

Ranh giới mong manh giữa tự động hóa và mất an toàn hệ thống

Sự cố xóa thư mục gốc của GPT-5.6 phơi bày một thực tế mà giới kỹ sư thường bỏ qua khi phát triển các tác vụ tự động (agentic workflows). Chúng ta thường quá tập trung vào khả năng suy luận của mô hình mà quên mất cơ chế kiểm soát hành vi của chúng. Khi một mô hình ngôn ngữ lớn được tích hợp sâu vào hệ thống để tự viết và thực thi mã nguồn - như cách hoạt động của Codex - bất kỳ lỗi logic nhỏ nào trong việc xử lý đường dẫn hoặc biến môi trường cũng có thể dẫn đến thảm họa.

Thực tế thì việc chạy agent trực tiếp trên môi trường máy chủ mà không có lớp bảo vệ là một quyết định mạo hiểm. Để tránh những sự cố tương tự, việc thiết lập các ranh giới kỹ thuật là bắt buộc. Dưới đây là những nguyên tắc cơ bản cần tuân thủ khi triển khai các tác vụ tự động:

• Luôn chạy các tác vụ thực thi mã nguồn trong container hoặc môi trường ảo hóa tách biệt hoàn toàn với hệ điều hành chính.
• Giới hạn quyền ghi của tác vụ đối với các thư mục hệ thống nhạy cảm, đặc biệt là các biến môi trường như $HOME hay /root.
• Thiết lập cơ chế phê duyệt thủ công (human-in-the-loop) đối với các lệnh can thiệp sâu vào hệ thống như xóa, di chuyển file hoặc thay đổi cấu hình mạng.
• Bật tính năng tự động rà soát (auto review) để phát hiện sớm các đoạn mã có hành vi bất thường trước khi cho phép chạy thực tế.

Rõ ràng, việc tối ưu hóa hiệu năng của mô hình phải đi đôi với việc thiết lập các chốt chặn an toàn. Nhưng làm thế nào để các agent này hoạt động hiệu quả mà không lãng phí tài nguyên? Câu trả lời nằm ở cách chúng ta cung cấp dữ liệu đầu vào cho chúng.

Bài toán tối ưu hóa truy xuất cho các tác vụ tự động

Khi xây dựng các hệ thống RAG (truy xuất thông tin tăng cường) phục vụ cho agent, chất lượng của bước tìm kiếm thông tin ban đầu quyết định phần lớn hiệu quả của cả quy trình. Nếu bước truy xuất trả về kết quả nhiễu hoặc sai lệch, agent sẽ mất thêm nhiều lượt truy vấn phụ (re-query), lãng phí tài nguyên tính toán và làm tăng chi phí sử dụng API.

Để giải quyết vấn đề này, NVIDIA vừa giới thiệu dòng mô hình nhúng Nemotron 3 Embed. Mô hình này đã đạt vị trí dẫn đầu trên bảng xếp hạng RTEB (một công cụ đánh giá chất lượng truy xuất dữ liệu). Điểm đáng chú ý của Nemotron 3 Embed là khả năng tối ưu hóa việc tìm kiếm thông tin đa bước cho các agent, giúp giảm thiểu lượng ngữ cảnh dư thừa truyền vào mô hình ngôn ngữ chính.

Về mặt kỹ thuật, NVIDIA đã tối ưu hóa dòng mô hình này để chạy trên phần cứng Blackwell bằng cách sử dụng định dạng số NVFP4. Điều này giúp giảm đáng kể độ trễ khi xử lý các kho dữ liệu lớn mà không làm suy giảm độ chính xác của các vector nhúng. Với các kỹ sư đang vận hành hệ thống RAG ở quy mô doanh nghiệp, việc chuyển đổi sang các mô hình nhúng chuyên biệt như thế này giúp giải quyết bài toán chi phí phần cứng một cách thực tế hơn là nâng cấp các mô hình ngôn ngữ lớn ở lớp trên.

Sức mạnh của sự chuyên biệt hóa thay vì chạy đua kích thước

Nhiều người vẫn tin rằng các mô hình có kích thước lớn hơn sẽ luôn hoạt động tốt hơn trong mọi tác vụ. Tuy nhiên, sự xuất hiện của DharmaOCR đã chứng minh điều ngược lại. Dù có kiến trúc đơn giản hơn so với các đối thủ như Mistral OCR4 hay Unlimited-OCR, DharmaOCR vẫn đạt hiệu suất vượt trội khi xử lý tiếng Bồ Đào Nha Brazil.

Bí quyết của DharmaOCR nằm ở quy trình huấn luyện hai giai đoạn. Đội ngũ phát triển đã tinh chỉnh mô hình trên một tập dữ liệu tiếng Bồ Đào Nha đa dạng về định dạng và độ phức tạp. Quá trình này giúp căn chỉnh trọng số của mô hình tập trung hoàn toàn vào cấu trúc cú pháp, từ vựng và đặc thù tài liệu của ngôn ngữ mục tiêu, thay vì phân tán tài nguyên tính toán cho nhiều ngôn ngữ khác nhau.

Điều này gợi mở một hướng đi rất rõ ràng cho cộng đồng công nghệ Việt Nam. Thay vì cố gắng xây dựng hoặc tinh chỉnh các mô hình đa ngôn ngữ khổng lồ, việc tập trung tối ưu hóa dữ liệu và huấn luyện chuyên biệt cho tiếng Việt sẽ mang lại hiệu quả thực tế cao hơn nhiều. Một mô hình nhỏ được tối ưu tốt luôn vận hành nhanh hơn, rẻ hơn và chính xác hơn một mô hình khổng lồ nhưng chung chung.

Lựa chọn giữa mô hình mã nguồn mở cỡ lớn và dịch vụ đám mây

Thị trường công nghệ vừa chứng kiến hai hướng đi tương phản từ các phòng nghiên cứu lớn. Một bên là Kimi K3 của Moonshot AI - mô hình có kích thước lên tới 2,8 nghìn tỷ tham số (2.8T parameters). Kimi K3 hiện có mức giá dịch vụ khá cao: 3 USD cho mỗi triệu token đầu vào và 15 USD cho mỗi triệu token đầu ra. Dù có hiệu suất xử lý mã nguồn giao diện (Frontend Code) rất ấn tượng, mức giá này sẽ khiến nhiều doanh nghiệp phải cân nhắc kỹ trước khi tích hợp vào sản phẩm thương mại.

Ở hướng ngược lại, phòng nghiên cứu Thinking Machines của Mira Murati đã phát hành Inkling - một mô hình hỗn hợp chuyên gia (MoE) mã nguồn mở với 975 tỷ tham số (trong đó có 41 tỷ tham số kích hoạt). Được cấp phép theo chuẩn Apache-2.0, Inkling không hướng tới việc trở thành mô hình mạnh nhất ở mọi chỉ số. Thay vào đó, nó được thiết kế như một mô hình nền tảng tối ưu để các nhà phát triển tự tinh chỉnh trên nền tảng Tinker của họ.

Bảng dưới đây so sánh các thông số cơ bản giữa hai mô hình này để giúp bạn dễ dàng đưa ra lựa chọn phù hợp cho dự án của mình:

Tiêu chí	Kimi K3 (Moonshot AI)	Inkling (Thinking Machines)
Loại mô hình	API Đóng (Hứa hẹn mở mã nguồn)	Mã nguồn mở (Apache-2.0)
Kích thước tham số	2,8 nghìn tỷ (2.8T)	975 tỷ (41 tỷ hoạt động)
Chi phí sử dụng	$3/M input, $15/M output	Miễn phí bản quyền phần mềm
Thế mạnh chính	Viết code Frontend, tác vụ dài	Tinh chỉnh sâu (Fine-tuning)

Lời khuyên cho kỹ sư vận hành tại Việt Nam

Từ những chuyển dịch công nghệ nói trên, các kỹ sư phát triển ứng dụng AI tại Việt Nam cần thay đổi tư duy tiếp cận hệ thống. Chúng ta không nên phụ thuộc hoàn toàn vào việc tăng kích thước mô hình hay sử dụng các API đắt đỏ của nước ngoài. Thay vào đó, hãy tập trung vào ba yếu tố cốt lõi: thiết lập môi trường thực thi an toàn cho agent, tối ưu hóa chất lượng dữ liệu nhúng (embedding) và ưu tiên các mô hình chuyên biệt hóa cho ngôn ngữ cũng như nghiệp vụ cụ thể. Việc làm chủ các mô hình mã nguồn mở như Inkling hay các mô hình nhúng chuyên dụng như Nemotron 3 Embed sẽ giúp chúng ta xây dựng được những hệ thống AI vừa an toàn, vừa tối ưu về mặt chi phí vận hành thực tế.