Khi nói về việc phối hợp nhiều mô hình AI trong cùng một dự án (multi-agent), người ta thường vẽ ra một bức tranh rất mượt mà: con này lập kế hoạch, con kia viết mã, con nọ đi nghiên cứu, và mọi thứ tự động ăn khớp với nhau như một dây chuyền hoàn hảo.
Nhưng khi bạn thật sự đưa quy trình đó vào vận hành trên một sản phẩm thực tế, phần khó nhất không nằm ở kỹ thuật ghép nối các công cụ lại với nhau. Phần khó nhất nằm ở việc nhận diện được con nào đang làm đúng, con nào đang làm sai, và con nào đang tự tin nói dối bạn mà không hề chớp mắt.
Trong một tuần vừa qua, tôi đã chia việc cho ba mô hình khác nhau cùng tham gia phát triển dự án này: một mô hình mạnh đóng vai trò lập kế hoạch và kiểm duyệt, một mô hình nhanh chịu trách nhiệm viết mã và xử lý dữ liệu, và một công cụ chuyên trách xử lý tài sản hình ảnh. Ba tác vụ đầu tiên trả về kết quả sạch sẽ không một vết gợn. Đến tác vụ thứ tư, hệ thống gặp một cú trượt bất ngờ — và cú trượt đó dạy cho tôi nhiều bài học hơn cả ba lần thành công trước cộng lại.
Vì sao tôi không giao hết cho một con
Nhiều người sẽ tự hỏi: tại sao không chọn một mô hình mạnh nhất duy nhất rồi giao trọn gói mọi việc từ đầu đến cuối cho tiện?
Câu trả lời nằm ở bài toán kinh tế và tài nguyên ngữ cảnh.
Nếu bạn để mô hình lớn nhất và đắt nhất làm tất cả mọi thứ — từ việc suy nghĩ kiến trúc, đọc tài liệu, viết từng hàm kiểm thử cho đến gọt giũa dữ liệu — bạn sẽ nhanh chóng làm cạn kiệt hạn mức sử dụng và khiến chi phí phình to vô ích. Một mô hình mạnh nhất nên được bảo toàn năng lực cho việc bao quát toàn cục: chia nhỏ đầu việc, viết đề bài thật chặt chẽ, và kiểm tra kỹ lưỡng kết quả đầu ra.
Còn những công việc thực thi mang tính khép kín — có đầu vào rõ ràng, có công thức tính toán cụ thể, có cấu trúc dữ liệu định sẵn — thì giao cho một mô hình nhanh hơn và rẻ hơn là lựa chọn tối ưu nhất. Đó là cách chúng tôi tổ chức công việc: mô hình chính viết gói yêu cầu, mô hình nhanh nhận việc và thực thi độc lập, sau đó kết quả được chuyển ngược lại cho mô hình chính soát lỗi lần cuối trước khi đưa vào sản phẩm.
Ba việc code giao đi, ba việc trả về sạch
Quy trình phân định vai trò này đã chạy trơn tru một cách đáng kinh ngạc qua ba tác vụ kỹ thuật đầu tiên.
Tác vụ thứ nhất là xây dựng một cỗ máy tính toán chi phí logic thuần túy. Đề bài đưa ra công thức chi tiết, các trường dữ liệu bắt buộc và các bài kiểm thử kỳ vọng. Mô hình nhanh đã hoàn thành chính xác từng dòng: vượt qua toàn bộ 8 trên 8 bài kiểm thử (assertion), không cài thêm bất kỳ thư viện ngoài nào, và phần chỉnh sửa file cấu hình dự án khớp đúng hai dòng được yêu cầu.
Tác vụ thứ hai là trích xuất và tổng hợp dữ liệu sử dụng từ các phiên làm việc trước đó cho bài đo chi phí thật. Khi đối chiếu độc lập bảng số liệu này, kết quả khớp chính xác 26 trên 27 phiên. Phiên duy nhất có độ lệch là do phiên đó đang chạy dở trong lúc đo đạc và tiếp tục phát sinh thêm lượt tương tác giữa chừng.
Tác vụ thứ ba là đóng băng tập dữ liệu và phân tách chi phí theo từng dòng mô hình. Kết quả tổng hợp lại một lần nữa khớp hoàn toàn với số liệu gốc ở cả bốn trường dữ liệu token.
Cả ba lần giao việc liên quan đến lập trình và tính toán số liệu đều đạt kết quả xuất sắc. Mô hình nhanh cho thấy nó cực kỳ đáng tin cậy khi được làm việc trong một không gian có quy chuẩn rõ ràng, công thức khép kín và đáp án đối chứng định sẵn.
Việc thứ tư trượt, và trượt theo một kiểu tôi không ngờ
Chính vì ba tác vụ đầu tiên thành công quá suôn sẻ, tôi đã tự tin giao tác vụ thứ tư: một nhiệm vụ nghiên cứu mở trên web để thu thập bảng giá và thông tin phiên bản của các mô hình phổ biến trên thị trường.
Và đây là nơi cú trượt xảy ra.
Kết quả trả về nhìn bề ngoài rất đẹp mắt và đầy đủ cấu trúc. Nhưng khi kiểm tra kỹ nội dung bên trong, toàn bộ danh sách các mô hình thu thập được đã bị lạc hậu khoảng mười tám tháng. Tệ hơn nữa, nó bỏ sót hoàn toàn những dòng mô hình thế hệ hiện tại mà chính đề bài đã ghi chú sẵn làm mẫu gợi ý.
Các mức giá đi kèm không phải là những con số bịa đặt ngẫu nhiên. Chúng là những mức giá hoàn toàn có thật trên thị trường, nhưng lại bị gắn nhầm vào tên của những mô hình khác.
Đặc biệt, trong toàn bộ 9 trên 9 câu hỏi khảo sát chuyên sâu, mô hình đều tự tin đánh dấu câu trả lời là "sự thật chính thức", không có một câu hỏi nào được gắn nhãn "không biết" — mặc dù trong bản mô tả yêu cầu, tôi đã ghi rất rõ rằng "nói không biết là một câu trả lời hoàn toàn đúng và được khuyến khích". Một vài con số thống kê thậm chí còn trùng khớp nguyên văn với dữ liệu mẫu trong đề bài.
Số đúng gắn nhãn sai khó bắt hơn số bịa
Cơ chế hỏng hóc này nguy hiểm hơn sự bịa đặt thông thường (hallucination) rất nhiều.
Nếu một mô hình AI bịa ra một mức giá kỳ quặc như một triệu đô la cho một token, bất kỳ ai lướt qua cũng sẽ phát hiện ra ngay lập tức. Nhưng khi nó lấy một mức giá có thật (ví dụ 3 đô la mỗi triệu token) và gán nó cho một phiên bản mô hình cũ hơn, lỗi sai trở nên cực kỳ khó phát hiện nếu bạn không trực tiếp mở trang tài liệu gốc ra đối soát từng dòng.
Nguyên nhân sâu xa của hiện tượng này nằm ở cách thức hoạt động của mô hình: nó có xu hướng trả lời dựa trên những ký ức cũ đã có sẵn trong quá trình huấn luyện trước, sau đó mới đi tìm một đường link trông có vẻ hợp lý để gắn vào làm nguồn tham chiếu. Mô hình không thể phân biệt một cách đáng tin cậy giữa hai trạng thái: "tôi vừa đọc thấy thông tin này trên trang web" và "tôi vốn đã biết điều này từ trước".
Điều thú vị là trong cùng một tác vụ nghiên cứu đó, phần khảo sát kết quả tìm kiếm thực tế lại trả về hoàn toàn chính xác: nó thu thập được bốn mươi tên miền rất đặc thù của thị trường nội địa — loại dữ liệu thực tế mà mô hình không thể nào tự suy diễn hay nhớ sẵn trong đầu.
Điều đó chứng minh rằng vấn đề không phải là mô hình không biết nghiên cứu. Điểm hỏng chỉ xuất hiện khi bạn giao cho nó nghiên cứu về một chủ đề mà trong đầu nó vốn dĩ đã có sẵn một câu trả lời cũ.
Thứ đã chặn thiệt hại chỉ là một dòng trong đề bài
Dù tác vụ nghiên cứu trả về một bảng dữ liệu sai lệch, không có một dòng code nào của dự án bị ảnh hưởng và không có bất kỳ thông tin sai nào lọt vào hệ thống hiển thị.
Thứ cứu nguy cho cả dự án không phải là một thuật toán phức tạp. Nó chỉ là một dòng quy định đơn giản trong bản context chứ không phải prompt của đề bài: giới hạn quyền ghi file của mô hình vào duy nhất một thư mục nghiên cứu tạm thời.
Nhờ việc mô tả việc cho đủ rõ và khóa chặt phạm vi tác động, mô hình nhanh chỉ có thể ghi kết quả vào thư mục chứa dữ liệu thô. Nó bắt buộc phải giữ nguyên file cấu hình giá gốc và cờ cảnh báo "dữ liệu này đã cũ" nguyên vẹn đúng như yêu cầu của đề bài.
Khi dữ liệu hỏng bị cô lập hoàn toàn bên ngoài tầng mã nguồn, mô hình chính trong bước kiểm duyệt đã dễ dàng phát hiện ra sự bất thường, từ chối nạp bảng dữ liệu đó vào hệ thống, và giữ cho toàn bộ phần mềm sạch sẽ tuyệt đối.
Giới hạn quyền ghi và cô lập thư mục làm việc chính là cơ chế bảo vệ an toàn rẻ nhất, đơn giản nhất nhưng hiệu quả nhất trong kiến trúc multi-agent.
Điều tôi nhận ra
Trải nghiệm một tuần điều phối ba mô hình AI làm việc cùng nhau đã đúc kết lại thành ba nguyên tắc vàng mà tôi luôn áp dụng:
Thứ nhất, đừng bao giờ giao cho một mô hình nhanh những câu hỏi tra cứu mở mà nó đã có sẵn định kiến trong bộ nhớ — như bảng giá, số hiệu phiên bản hay trạng thái tồn tại của một dịch vụ. Những việc đó phải giao cho công cụ tra cứu trực tiếp hoặc mô hình kiểm duyệt cấp cao.
Thứ hai, một bản kết quả nghiên cứu mà không có bất kỳ chỗ nào thừa nhận "không biết" là một tín hiệu cảnh báo hỏng hóc, không phải dấu hiệu của sự thông minh.
Thứ ba, luôn thiết lập ranh giới ghi file nghiêm ngặt cho từng tác vụ để bất kỳ sai sót nào cũng chỉ nằm trong vùng cách ly.
Trước khi khép lại, tôi muốn nói rõ về giới hạn của những quan sát này:
Đây là bốn task trong một tuần, trên một dự án. Không đủ để kết luận model nào giỏi hơn model nào — chỉ đủ để chỉ ra một kiểu hỏng cụ thể và cách chặn nó.
Hiểu đúng ranh giới năng lực của từng công cụ giúp bạn không còn thất vọng khi AI mắc lỗi, mà chủ động thiết kế một quy trình làm việc vững chắc: tận dụng triệt để tốc độ của mô hình nhanh, giữ sự chặt chẽ của mô hình kiểm duyệt, và bảo đảm an toàn tuyệt đối cho sản phẩm của mình.
