# Con agent không sợ việc khó, nó sợ một câu: "cái này có ai làm rồi chưa"
Tuần này có một câu chuyện làm mình ngồi lại lâu hơn bình thường.
Một kỹ sư dựng một cụm gần năm chục con agent chạy song song trên dữ liệu quét bề mặt thô. Chúng đọc dữ liệu, dựng giả thuyết, phản biện nhau, rồi viết ra một báo cáo đủ nghiêm túc để gửi cho cơ quan chức năng của một nước. Từ ý tưởng tới lúc có thư trả lời chính thức: khoảng ba ngày.
Ai đọc tới đây cũng nghĩ cùng một câu: vậy là máy đã làm được việc của một nhóm nghiên cứu trong một quý.
Nhưng phần mình muốn nói không phải phần đó.
Vì sau đó, chính tác giả tự đính chính: khu vực ấy đã được công bố trong một bài báo khoa học từ trước. Con máy không phát hiện ra thứ chưa ai biết. Nó tái phát hiện ra thứ đã có người tìm ra rồi.
Và đây mới là chỗ mình thấy đáng viết: cả bốn mươi tám con agent đó không con nào hỏi câu hỏi rẻ nhất trong mọi câu hỏi — "cái này có ai làm rồi chưa?"
Cái máy giỏi hơn mình tưởng, ở đúng chỗ mình tưởng nó dở nhất
Để công bằng, phải nói rõ phần nó làm được, vì phần đó thật sự khó.
Dữ liệu quét bề mặt là loại dữ liệu khó chịu: mây điểm dày, nhiễu, không có nhãn, không có sẵn câu trả lời, đọc bằng mắt người thì mỏi và dễ bỏ sót. Đưa loại dữ liệu này cho một con agent là đưa một bài toán mà mình thường nghĩ "phải có chuyên gia".
Nó làm được. Và cách nó làm được cũng đáng để ý: không phải một con agent thông minh hơn, mà là bốn mươi tám lần thử trên cùng một khoảng thời gian. Mỗi con nhìn một cách, dựng một giả thuyết, rồi bị con khác phản biện. Cái mà cụm agent mua được không phải trí tuệ — mà là số lần thử.
Đây là điều mình hay nhắc: khi tự động hoá một việc khó, phần lớn giá trị ban đầu không đến từ "máy giỏi hơn người", mà từ "máy không biết mệt nên thử được nhiều hơn". Chia việc cho nhiều agent theo chức năng, cho mỗi con một loại đầu ra rõ ràng, rồi để chúng chấm chéo nhau — đó là một cấu trúc đã thành khuôn mẫu, và nó chạy được thật.
Cho nên câu chuyện này không phải chuyện máy dở. Nó là chuyện máy giỏi đúng phần mình cần, rồi sập ở một phần mình không nghĩ tới.
Chỗ nó sập không phải "bịa", mà là "không biết cái gì đã tồn tại"
Mình từng nghĩ lỗi nguy hiểm nhất của agent là bịa — nói ra một thứ không có thật, trôi chảy tới mức mình tin.
Nhưng câu chuyện này chỉ ra một lỗi khác, khó thấy hơn nhiều: nó không bịa. Nó làm đúng. Chỉ là nó không biết thế giới bên ngoài đang ở đâu.
Nghĩ kỹ thì đây là hệ quả tất yếu của cách những con máy này được tạo ra. Kiến thức của nó là một mức trung bình mờ của rất nhiều văn bản. Với câu "vùng này có di tích cổ không", nó trả lời khá tốt, vì đó là loại thông tin nằm rải rác trong dữ liệu huấn luyện. Nhưng với câu "di tích cụ thể ở toạ độ này đã được công bố trong bài báo nào, vào thời điểm nào", nó không có câu trả lời — và tệ hơn, nó không biết là mình không có câu trả lời. Nó vẫn viết ra một báo cáo rất tự tin, vì viết báo cáo là việc nó làm tốt.
Có một vòng tròn luẩn quẩn ở đây, và mình nghĩ đây là điểm quan trọng nhất của cả bài:
Nếu bạn hỏi chính con agent đó "cái này có mới không", bạn đang hỏi nó bằng chính cái kiến thức mờ mà nó dùng để tạo ra câu trả lời. Nó sẽ trả lời "có vẻ mới" — không phải vì thế giới mới, mà vì trong đầu nó, thứ đó chưa được đánh dấu là cũ. Tự hỏi mình thì không bao giờ phát hiện ra mình đã bỏ lỡ điều gì. Đó không phải giới hạn của riêng AI.
Với người làm nghiên cứu, phản xạ đầu tiên không phải "tôi làm được không" mà là "ai đã làm chưa, làm tới đâu". Đó là một nghi thức xã hội học của nghề, được dạy từ bài báo đầu tiên. Con agent không có nghi thức đó. Nó có năng lực, không có thói quen.
Vì sao đây là kiểu sai đắt nhất trong mọi thứ mình tự động hoá
Mình không kể chuyện này vì nó ly kỳ. Mình kể vì nó là cùng một lỗi mình gặp đi gặp lại trong công việc tự động hoá, chỉ khác quy mô.
Thứ nhất, nó không để lại dấu vết. Log xanh. Đầu ra đẹp. Báo cáo có mục lục, có phụ lục, có kết luận. Không một dòng nào báo "phần này có thể đã tồn tại". Loại sai mà trông đúng là loại sai không bao giờ được sửa, vì không ai có lý do để đi kiểm tra nó. Máy bịa thì mình bắt được, vì mình có phản xạ nghi ngờ. Máy đúng mà vô nghĩa thì mình không nghi.
Thứ hai, chi phí thật không nằm ở máy, mà ở niềm tin. Chạy ba ngày agent rất rẻ so với thuê người. Nhưng gửi một báo cáo "phát hiện mới" cho một cơ quan nhà nước, rồi phải đính chính — cái giá đó không tính bằng token. Trong công việc tự động hoá, phần đắt luôn là phần chạm ra ngoài: gửi đi, đăng lên, ký tên, thu tiền. Máy làm rẻ phần bên trong và làm đắt phần bên ngoài, theo đúng tỷ lệ nó làm nhanh hơn.
Thứ ba, trong làm sản phẩm, đây là cách đốt một tháng mà không ai gọi là thất bại. Bạn dựng một tính năng, thấy hay, ship, rồi phát hiện nền tảng đã tặng không nó từ bản cập nhật trước, hoặc một công cụ mã nguồn mở làm được 80% rồi. Với agent thì việc này xảy ra nhanh hơn nhiều, vì agent dựng được một bản chạy được trong vài giờ — nên vòng "xây trước, kiểm tra sau" bị nén lại tới mức gần như đồng thời. Nhanh hơn không có nghĩa là khôn hơn.
Và đây là chỗ nó chạm vào tiền một cách trực tiếp: bán "cái mới" mà không kiểm tra "cái đã có" thì đó không phải bán sản phẩm, mà là bán rủi ro cho chính mình. Khách không trả tiền cho thứ họ đã có sẵn — dù bạn làm nó đẹp hơn.
Cái cổng rẻ nhất: tra trước khi sinh
Mình không có ý nói phải dựng một hệ thống đồ sộ. Ngược lại — cái cổng này rẻ hơn mọi thứ khác trong pipeline, vì nó chạy trước khi gọi model.
Ba lớp, xếp theo giá tăng dần.
Lớp 1 — danh mục bên ngoài, tra bằng luật cứng. Trước khi cho agent đọc một byte dữ liệu nào, tra một danh mục tồn tại bên ngoài mình: kho công bố, danh mục sản phẩm, registry, changelog. Chi phí gần bằng không, và quan trọng nhất: nó không phụ thuộc vào việc model "nhớ" gì. Nhưng có một điều kiện dễ bỏ qua — danh mục phải có ngày và phiên bản. Một danh mục chỉ có "có/không" sẽ trả lời sai ngay khi có ai đó công bố thêm một mục mới. Bản đồ không có ngày là bản đồ đang nói dối một cách lịch sự.
Lớp 2 — trích dẫn bắt buộc, và một cửa "chưa biết". Mọi kết luận dạng "cái này mới" phải kèm một nguồn bên ngoài đã đối chiếu. Không có nguồn thì không được nâng lên nhãn "mới" — nó nằm ở nhãn "chưa xác định", và nhãn đó phải là một giá trị hợp lệ trong cấu trúc đầu ra, không phải một lỗi. Nếu khuôn đầu ra của bạn chỉ có "mới / không mới", bạn đã ép con máy phải chọn bừa ở đúng chỗ nó cần được im lặng.
Lớp 3 — tách hai định nghĩa "mới". "Mới với mình" và "mới với thế giới" là hai chuyện hoàn toàn khác nhau, và hầu hết hệ thống tự động trộn chúng làm một. Cái đầu là chuyện của bộ nhớ nội bộ. Cái sau là chuyện của thế giới, và chỉ có người hoặc một nguồn ngoài mới xác nhận được.
// pseudo-code minh hoạ — KHÔNG phải nguồn triển khai
ung_vien = doc_du_lieu(dau_vao)
# lớp 1: tra danh mục ngoài, rẻ, trước khi tốn token
khop = tra_danh_muc(ung_vien.khu_vuc, co_ngay=True)
if khop.trang_thai == "DA_CO":
-> ghi nhan "tai_phat_hien", DUNG (không đẩy lên bước sinh)
if khop.trang_thai == "KHONG_TRA_DUOC":
-> nhan "chua_xac_dinh", van cho đi tiếp NHƯNG không được gán "moi"
# lớp 2: bắt buộc có nguồn ngoài cho nhãn "moi"
if nhan == "moi" and not co_nguon_ngoai(ket_luan):
-> ha xuong "chua_xac_dinh"
# lớp 3: chỉ "moi với thế giới" mới được ra ngoài
if nhan == "moi_voi_the_gioi":
-> cho_nguoi_ky(ket_luan) # không hoàn tác được -> người giữ
else:
-> giu noi boCái khó không nằm ở code. Cái khó là chấp nhận rằng pipeline của mình sẽ thường xuyên trả về "chưa xác định", và đó là kết quả tốt, không phải lỗi cần tối ưu cho hết. Mình từng có một chuỗi tự động chạy nền, mỗi ngày đẻ ra một danh sách "thứ mới". Tới lúc đối chiếu với kho cũ mới thấy phần lớn đã nằm sẵn ở đó từ lâu, chỉ là mỗi lần chạy nó không ai buồn nhìn lại. Con máy không hề sai. Nó chỉ không có khái niệm "cái này đã có trong nhà mình chưa" — vì mình chưa từng đặt câu hỏi đó vào chỗ nó phải trả lời trước khi làm.
Cùng một lỗi, nhìn từ phía đo lường
Có một phiên bản khác của đúng căn bệnh này, và mình thấy nó còn phổ biến hơn: tự nghĩ ra thước đo.
Nhiều đội dựng agent xong rồi tự ngồi viết test case. Viết xong thấy xanh hết, yên tâm ship. Rồi khách gặp lỗi ở một tình huống mà không ai trong đội nghĩ ra — vì chính họ là người nghĩ ra bộ đề. Tự ra đề thì không bao giờ phát hiện được mình đã bỏ qua chương nào.
Cách sửa cũng cùng một nguyên tắc, chỉ đổi vật liệu: lấy đề bài từ thế giới thật. Có đội lấy vài trăm ticket khách hàng thật, lọc dữ liệu nhạy cảm, rồi nhờ người trực tiếp trả lời khách chọn ra vài chục cái đại diện — và label theo quyết định (đúng hàng đợi nào, được trả lời hay phải chuyển người, bắt buộc phải có thông tin gì), không label theo văn phong. Bộ đề đó nhỏ, thô, không đẹp. Nhưng nó được lấy từ chỗ mà sai thì mất khách.
Điểm chung của cả hai chuyện: câu hỏi "cái này đã có chưa" và câu hỏi "cái này đã được kiểm chứng bằng cái gì" đều không thể trả lời bằng cách hỏi lại chính con máy. Cả hai đều cần một nguồn sự thật nằm ngoài vòng suy nghĩ của nó.
Con máy không cần thông minh hơn, nó cần một bộ nhớ về thế giới không do nó tự viết
Mình vẫn nghĩ cụm bốn mươi tám agent đó là một thành tựu thật. Ba ngày cho một việc như vậy là con số mà vài năm trước không ai tin.
Nhưng bài học mình mang về không phải "agent mạnh quá". Nó là: khi máy làm được phần khó, phần còn lại của hệ thống phải gánh phần dễ mà con người làm theo phản xạ. Kiểm tra xem đã có ai làm chưa là việc dễ. Nó chỉ dễ với người, vì người được dạy phải làm thế. Với máy, nó là một bước phải được thiết kế, đặt đúng chỗ, và có quyền nói "tôi không biết".
Và có một hệ quả mình thấy khá thú vị: cái cổng này cũng là thứ dễ bán nhất trong mọi thứ mình từng nghĩ tới. Bạn không bán "agent phát hiện ra điều mới" — bán cái đó rất khó, vì thành công của nó là một sự kiện hiếm và không ai kiểm chứng được. Bạn bán "hệ của tôi không làm lại việc đã có, và nói rõ khi nó không chắc". Đó là một lời hứa đo được, kiểm được, và khách hàng hiểu ngay vì sao nó đáng tiền.
Anh em thì sao — lần gần nhất anh em tiêu mấy ngày để làm một thứ mà hoá ra đã có sẵn là khi nào? Mình rất muốn nghe mấy câu chuyện kiểu đó, vì mình tin chúng ta đều có ít nhất một cái.