MoE không chỉ là chuyện nhiều tham số. Doanh nghiệp cần kiểm tra cách chia việc, độ ổn định và chi phí cho một kết quả dùng được.
Hãy hình dung một buổi sáng ở doanh nghiệp giao nhận hàng hóa. Khách gửi tin nhắn: “Lô hàng chưa tới, nhưng hóa đơn đã xuất. Tôi cần xử lý trước trưa.”
Người phụ trách chứng từ rất giỏi. Người theo dõi vận chuyển cũng rất giỏi. Nhưng nếu bàn tiếp nhận chỉ nhìn thấy chữ “hóa đơn” rồi chuyển toàn bộ yêu cầu sang chứng từ, khách vẫn phải chờ. Vấn đề không nằm ở việc thiếu người tài. Nó nằm ở cách công việc được hiểu và phân bổ.
Đây là tình huống giả định, nhưng nó gợi mở một câu hỏi hữu ích khi doanh nghiệp đánh giá AI: Chúng ta đang đo năng lực của từng bộ phận, hay đo cả khả năng phối hợp để tạo ra kết quả cuối cùng?
Với mô hình Mixture of Experts, gọi tắt là MoE, câu hỏi ấy đặc biệt đáng quan tâm. Một bài kiểm tra trả lời đúng chưa đủ nói rằng hệ thống sẽ đáng tin khi dữ liệu thay đổi, người dùng hỏi khác đi hoặc lượng yêu cầu tăng đột ngột.
1. MoE giống một bàn điều phối — nhưng không phải một nhóm nhân viên số
Trong một lớp MoE, bộ định tuyến, hay router, lựa chọn một số mạng con để xử lý biểu diễn của từng token. Token là đơn vị văn bản mà mô hình sử dụng, có thể là một từ hoặc một phần của từ. Các mạng con này được gọi là expert: “chuyên gia” theo nghĩa kiến trúc, không phải những người có chức danh nghề nghiệp.
Ví dụ, nghiên cứu Mixtral mô tả router chọn hai expert trong tám expert tại mỗi lớp, cho từng token. Không phải toàn bộ câu hỏi được gửi cố định đến hai “trợ lý”. Các lựa chọn có thể thay đổi trong quá trình xử lý. Nghiên cứu Mixtral of Experts.
Điểm hấp dẫn là mô hình có thể sở hữu nhiều tham số nhưng chỉ kích hoạt một phần cho từng token. Tuy nhiên, ít tính toán được kích hoạt không đồng nghĩa tổng chi phí triển khai sẽ thấp tương ứng: bộ nhớ và việc chuyển dữ liệu giữa thiết bị vẫn cần được tính đến. Phân tích kiến trúc và chi phí của Mixtral.
Quan trọng hơn, không nên tự gán tên “expert kế toán”, “expert pháp lý” hay “expert vận tải”. Phân tích định tuyến của Mixtral không tìm thấy sự phân chia rõ ràng theo chủ đề như cách hình dung đó. Phân tích routing trong nghiên cứu Mixtral.
Bàn điều phối là phép ví von để hiểu việc phân bổ tính toán. Expert bên trong MoE không mặc nhiên tương ứng với phòng ban nghiệp vụ.
Cũng cần tách hai tầng kiến trúc. Router bên trong MoE phân bổ token giữa các mạng con. Router của ứng dụng doanh nghiệp có thể chọn mô hình, công cụ hoặc quy trình xử lý một yêu cầu. Hai tầng cùng đặt ra bài toán điều phối, nhưng không phải cùng một cơ chế.
Ở tầng ứng dụng, bài Đội AI đông chưa chắc làm việc tốt: ai đang giữ nhịp? bàn thêm về phối hợp giữa các agent — một vấn đề khác với routing bên trong MoE.
Từ đây, tôi đề xuất đổi câu hỏi “AI này mạnh đến đâu?” thành: “AI này tạo ra kết quả dùng được ổn định đến đâu, trong điều kiện công việc của chúng ta?”
2. Ba nút thắt dễ bị che khuất bởi điểm trung bình
Dữ liệu quen thì làm tốt, gặp ngoại lệ thì hụt hơi
Quay lại bàn tiếp nhận. Nếu suốt thời gian học việc chỉ có yêu cầu giao hàng thông thường, người mới khó xử lý hồ sơ vừa đổi địa chỉ, vừa đổi bên nhận hóa đơn, lại thiếu mã đơn.
Với AI, hãy dùng ví dụ này để thiết kế bộ kiểm thử, thay vì chỉ gom thêm thật nhiều câu hỏi giống nhau. Một bộ dữ liệu doanh nghiệp nên có yêu cầu phổ biến, thông tin thiếu, cách viết tắt, văn bản Việt–Anh đan xen và tình huống ít gặp nhưng gây hậu quả lớn nếu làm sai.
Kết quả phải được tách theo từng nhóm. Tỷ lệ đúng cao ở câu hỏi tra cứu không bù được việc thường xuyên bỏ sót điều kiện trong yêu cầu xử lý ngoại lệ. Đối với các nhóm hiếm, cần công bố cả số mẫu; vài câu trả lời đúng chưa chứng minh được độ tin cậy.
Công việc dồn vào vài nơi, năng lực còn lại không được sử dụng tốt
Một quầy đông khách và ba quầy trống là dấu hiệu nên kiểm tra, không phải bằng chứng mọi nhân viên đều kém. Có thể cách phân luồng bất hợp lý; cũng có thể nhu cầu hôm đó vốn tập trung vào một loại việc.
Tương tự, nếu quan sát được bên trong MoE, đội kỹ thuật cần theo dõi phân bố token tới các expert theo lớp và theo nhóm dữ liệu. Hiện tượng định tuyến tập trung kéo dài vào một số ít expert có thể gợi ý expert collapse: hệ thống không khai thác được sự đa dạng tính toán như kỳ vọng.
Nhưng ít được chọn không tự động có nghĩa là expert hỏng; phân bố không đều cũng không tự động là sai. Hãy đối chiếu với cấu hình, dữ liệu và chất lượng đầu ra. Đặc biệt, một expert ít hoạt động khi mô hình đã đóng băng không tự mất kiến thức chỉ vì “ngồi không”. Cần đo, không suy diễn từ phép ví von về con người.
Vượt sức chứa: xử lý nhanh chưa chắc xử lý đủ
Ở một số cách triển khai MoE có giới hạn sức chứa, token vượt giới hạn của expert có thể không được tính toán qua expert đó. Trong Switch Transformer, biểu diễn token vẫn được chuyển tiếp qua kết nối dư. “Token dropping” ở đây không có nghĩa chữ bị xóa khỏi câu trả lời. Nghiên cứu Switch Transformers.
Không phải mọi MoE đều xử lý quá tải theo cách này. Vì vậy, đội triển khai cần kiểm tra chính sách thực tế: có giới hạn sức chứa không, khi vượt giới hạn thì bỏ qua hay xử lý theo đường khác, và có số liệu để kiểm chứng không.
Đây là kịch bản cần thử nghiệm, không phải kết luận rằng mọi MoE sẽ gặp token dropping hoặc mọi lỗi đầu ra đều do router.
Đừng thấy câu trả lời thiếu ý rồi kết luận ngay router làm sai. Lỗi có thể nằm ở dữ liệu đầu vào, tài liệu truy xuất, giới hạn đầu ra hoặc chính năng lực mô hình. Chỉ số định tuyến giúp khoanh vùng; thử nghiệm có kiểm soát mới giúp phân biệt nguyên nhân.
3. Một bảng điều hành nên nối tín hiệu kỹ thuật với việc khách hàng nhận được
Giả sử doanh nghiệp dùng AI để soạn phản hồi cho nhân viên chăm sóc khách hàng. “Thành công” không nên chỉ là API trả về mã 200 hoặc văn bản đúng định dạng.
Hãy định nghĩa rõ: bản nháp phải đúng dữ kiện, không tự hứa một thời hạn chưa được xác nhận, nhắc đủ phần việc cần xử lý và biết chuyển người phụ trách khi thiếu căn cứ. Với hành động như hoàn tiền hoặc thay đổi đơn hàng, cần thêm kiểm soát quyền và phê duyệt; một câu trả lời hay không phải giấy phép thực hiện giao dịch.
Bảng dưới đây là khung đo đề xuất, không phải một bộ ngưỡng áp dụng cho mọi doanh nghiệp:
P95, chẳng hạn, là mức thời gian mà 95% lượt đo không vượt quá; nó không phải thời gian chậm nhất. Với phản hồi dạng streaming, hãy tách thời gian xuất hiện token đầu tiên và thời gian nhận đủ kết quả. “Bắt đầu trả lời nhanh” và “xong việc đúng hạn” là hai trải nghiệm khác nhau.
Cũng không cần ép hai cách diễn đạt tương đương phải kích hoạt đúng cùng một expert. Điều doanh nghiệp cần giữ ổn định là nội dung và hành vi đáp ứng yêu cầu. Nếu đường định tuyến đổi nhưng chất lượng vẫn đạt, chưa có lý do gọi đó là lỗi.
Đừng mua cái rẻ nhất theo lượt gọi
Một phép tính giả định: hai phương án cùng nhận 10.000 yêu cầu, cùng được chấm bằng một tiêu chí nghiệp vụ.
Phương án A tốn 10 triệu đồng, có 9.000 yêu cầu đạt chuẩn: khoảng 1.111 đồng cho một yêu cầu thành công.
Phương án B tốn 8 triệu đồng, có 6.000 yêu cầu đạt chuẩn: khoảng 1.333 đồng cho một yêu cầu thành công.
Đây là số minh họa, không phải báo giá. Nếu các khoản chi trên chưa bao gồm công sửa lỗi của nhân viên, hãy tính thêm trước khi ra quyết định. Các lần thử lại phải nằm trong tổng chi phí, nhưng một yêu cầu xử lý thành công chỉ được tính một lần.
Rẻ theo lượt gọi chưa chắc rẻ theo việc hoàn thành. Và việc giảm chi phí không nên được đánh đổi bằng lỗi ở nhóm tình huống mà doanh nghiệp không chấp nhận.
Đây cũng là góc nhìn tổng chi phí sở hữu: rẻ lúc mua, chưa chắc rẻ khi sở hữu, khi quyết định phải tính cả vận hành và phần việc phát sinh.
4. Không nhìn được router vẫn có thể đánh giá nghiêm túc
Nếu chỉ dùng API, doanh nghiệp thường không có nhật ký expert bên trong. Khi đó, không nên tuyên bố đã đo “độ chính xác định tuyến MoE”, càng không lấy cách trả lời để đoán mô hình đang dùng expert nào.
Hãy làm tốt phần có thể quan sát: đầu vào, đầu ra, phiên bản mô hình, cấu hình, thời gian, chi phí và kết quả nghiệp vụ. Thử cùng nhóm câu hỏi với nhiều cách diễn đạt, nhiều độ dài ngữ cảnh và các mức tải. Dữ liệu thay đổi hay cấu hình đổi phải được ghi nhận để kết quả so sánh có ý nghĩa.
Nếu tự vận hành mô hình và có quyền truy cập sâu, mới mở thêm lớp quan sát routing. Không mặc định mỗi expert có một nhãn nghiệp vụ “đúng” để chấm. Muốn đánh giá chuyên môn của expert, cần thí nghiệm riêng và bằng chứng; tín hiệu router không phải xác suất câu trả lời đúng.
Nhật ký cũng phải phù hợp chính sách bảo mật: chỉ lưu thông tin cần thiết, che dữ liệu nhạy cảm, giới hạn quyền truy cập và thời gian lưu giữ. Quan sát tốt không đồng nghĩa sao chép toàn bộ hồ sơ khách hàng vào một nơi mới.
Ba nhánh phải được đọc cùng nhau. Một hệ thống nhanh nhưng sai, đúng nhưng thất thường, hoặc rẻ nhưng cần sửa quá nhiều đều chưa giải quyết trọn vẹn bài toán.
5. Bắt đầu từ một luồng công việc, không phải một bộ KPI khổng lồ
Với tình huống giao nhận đầu bài, tôi sẽ đề xuất một vòng thử nghiệm nhỏ:
Nếu đội dự án chưa thống nhất ai nghiệm thu và việc gì nằm ngoài phạm vi, hãy quay lại bước chốt mục tiêu, phạm vi và người quyết định trước khi chọn công nghệ. Sau đó mới triển khai vòng thử sau:
Chọn một việc có ranh giới rõ. Chẳng hạn, soạn phản hồi về trạng thái lô hàng; chưa cho AI tự sửa đơn hay tự hoàn tiền.
Lập bộ ca kiểm thử và đáp án đánh giá. Có ca thông thường, thiếu dữ liệu, yêu cầu nhiều ý và ngoại lệ. Đưa cả cách viết thực tế của khách hàng vào, sau khi xử lý dữ liệu nhạy cảm.
Chốt tiêu chí đạt và điều kiện dừng trước khi thử. Chủ quy trình nghiệp vụ chịu trách nhiệm tiêu chí chất lượng; đội kỹ thuật chịu trách nhiệm phép đo và cấu hình. Trường hợp rủi ro cao không được “bù điểm” bằng ca dễ.
Đo ở tải bình thường lẫn tải cao điểm dự kiến. Giữ các điều kiện so sánh tương đương, ghi nhận phiên bản, độ dài đầu vào và số lần thử lại. Nếu đo được expert, phân tích thêm nơi tải tập trung.
Mở phạm vi từng bước, có đường quay lại. Theo dõi lỗi mới, chuyển nhân viên khi cần và giữ phương án trước đó nếu bản cập nhật không đạt tiêu chí đã chốt.
Mục tiêu của vòng thử không phải có bảng số đẹp. Mục tiêu là biết khi nào AI làm được việc, khi nào phải hỏi thêm và khi nào không nên để AI quyết định.
Chuyên gia giỏi chưa đủ; cách phối hợp phải đáng tin
Quay lại tin nhắn lúc đầu. Khách hàng không quan tâm bên trong doanh nghiệp có bao nhiêu người giỏi. Họ cần yêu cầu được hiểu đủ, xử lý đúng và phản hồi kịp thời.
Với MoE cũng vậy, số expert hay số tham số chỉ là một phần câu chuyện. Doanh nghiệp cần nhìn cả chất lượng đầu ra, sự ổn định khi điều kiện thay đổi và chi phí để hoàn thành công việc đạt chuẩn. Khi có quyền quan sát sâu, routing giúp hiểu thêm điều gì xảy ra bên trong; khi không có, đánh giá đầu cuối vẫn là trách nhiệm không thể bỏ qua.
Nếu một yêu cầu quan trọng đến vào giờ cao điểm, hệ thống có còn tạo ra kết quả mà chúng ta dám sử dụng không? Đó là câu hỏi nên đặt trước khi mở rộng AI sang luồng công việc tiếp theo.
Nếu doanh nghiệp chỉ nhìn chi phí mỗi lượt gọi, AI rẻ có thể thành đắt khi nhân viên phải sửa lại quá nhiều. Trong luồng công việc của anh/chị, thế nào mới được tính là một kết quả AI thành công: trả lời đúng dữ kiện, hoàn tất đúng hạn, hay giảm được công sửa lỗi? Mời anh/chị chia sẻ một tình huống ngoại lệ khiến hệ thống đang làm tốt ở ca thường vẫn gặp khó.