Mô hình AI mở hay đóng: nhóm bạn muốn tự quyết điều gì?

Buổi chọn chatbot đang khá vui thì Huy hỏi một câu: “Nếu tháng sau họ đổi mô hình, mình có giữ bản hôm nay được không?” Phòng họp im vài giây. Mọi người vừa xem một màn demo mượt, nhưng chưa ai hỏi chuyện đó.

Trong tình huống giả định này, Huy phụ trách kho tài liệu của một công ty dịch vụ. Nhóm muốn nhân viên tra chính sách nhanh hơn. Hai lựa chọn còn lại là tự chạy một mô hình tải về hoặc thuê dịch vụ đóng. Bên nào cũng có người ủng hộ nhiệt tình.

Cách chọn hợp lý là liệt kê những quyết định công ty cần tự giữ, rồi kiểm tra từng phương án có đáp ứng không. Nhãn “mở” chưa đủ để bảo đảm tự chủ. Dịch vụ đóng cũng cần được xét theo điều khoản và khả năng thực tế của đúng gói sử dụng.

Bắt đầu từ việc nhóm muốn tự quyết

Huy viết lên bảng một câu hỏi rất đời thường: nhân viên mới muốn biết ngày nào được đăng ký nghỉ phép. Trợ lý phải tìm đúng chính sách hiện hành, đưa đường dẫn và nói rõ khi thiếu thông tin. Chỉ cần làm tròn việc này trước đã.

Từ đó, nhóm chốt ba yêu cầu. Tài liệu chỉ mở cho người có quyền. Khi chính sách đổi, bản cũ phải ngừng được dùng để trả lời. Khi hệ thống gặp lỗi, nhân viên vẫn tìm được văn bản gốc. Các yêu cầu nghe giản dị nhưng kiểm tra được.

Tiếp theo là quyền thay đổi phiên bản. Giả sử một bản cập nhật trả lời dài hơn, bỏ sót điều kiện thử việc. Nhóm có được tạm hoãn cập nhật hoặc quay lại bản trước không? Ai thực hiện việc đó? Câu trả lời cần đi kèm cách làm, thay vì một lời hứa “linh hoạt”.

Đừng gom mọi mong muốn vào mục bắt buộc. Nhóm có thể cần tự quản quyền đọc tài liệu, nhưng chưa cần tự sửa cấu trúc mô hình. Nếu yêu cầu nào cũng quan trọng như nhau, cuộc chọn công cụ sẽ kéo dài mà vẫn chưa biết phải đánh đổi điều gì.

Huy tách danh sách thành hai phần: điều thiếu là dừng và điều có thêm thì tốt. Cách này cũng giúp khi xem báo giá. Một tính năng nghe rất xịn nhưng không giải quyết yêu cầu nào trong danh sách có thể chờ.

Có thêm quyền thì cần lo thêm việc gì?

Trước hết cần đọc kỹ chữ “mở”. Có sản phẩm cho tải trọng số, tức phần tham số mô hình đã học, nhưng quyền sử dụng vẫn phụ thuộc giấy phép. Tải được về máy chưa nói hết quyền sửa, phân phối hoặc dùng trong sản phẩm thương mại.

Định nghĩa Open Source AI của OSI nêu các quyền dùng, nghiên cứu, sửa đổi và chia sẻ. Định nghĩa còn yêu cầu thông tin dữ liệu, mã và tham số cần thiết để chỉnh sửa hệ thống. Vì vậy, việc công bố trọng số đơn thuần chưa đủ để tự kết luận một hệ thống đáp ứng định nghĩa này.

Với phương án đang cân nhắc, hãy lưu lại giấy phép và phiên bản cụ thể để người phụ trách kiểm tra. Một bài giới thiệu gọi sản phẩm là “open” không thay được tài liệu đó. Nếu còn điểm chưa rõ về quyền sử dụng dự kiến, cần làm rõ trước khi tích hợp sâu.

Tự chạy cũng kéo theo việc chăm hệ thống. Huy phải biết ai cập nhật phần mềm, ai theo dõi máy chủ và ai xử lý khi hết dung lượng. Nếu chỉ một người biết khởi động lại dịch vụ, lịch nghỉ của người ấy bỗng trở thành vấn đề của cả nhóm.

Thử giao bản hướng dẫn vận hành cho người trực thay. Người đó có tìm được nơi xem lỗi và khôi phục bản hoạt động gần nhất không? Nếu phải gọi tác giả hướng dẫn ở mọi bước, quyền tự quản vẫn đang nằm trong đầu một người.

Với dịch vụ đóng, nhóm cần đọc phần nhà cung cấp thực sự nhận làm. Hỏi rõ cách lưu lịch sử, xuất dữ liệu, quản lý người dùng và thông báo thay đổi. Những quyền có trong gói cao hơn chưa chắc xuất hiện trong gói nhóm sắp mua.

Đừng quên tính giờ chăm hệ thống vào bảng so sánh. Mô hình tải miễn phí vẫn có thể cần máy, người vận hành và thời gian kiểm lỗi. Bài về chi phí AI ngoài tiền thuê bao giúp nhóm liệt kê phần dễ bị bỏ quên khi nhìn mỗi hóa đơn.

So hai phương án trên cùng một việc

Huy chuẩn bị một bộ câu hỏi từ tài liệu mẫu đã bỏ thông tin riêng. Có câu dễ tìm đáp án, câu cần đọc điều kiện và câu chưa có trong tài liệu. Hai phương án đều nhận cùng dữ liệu, cùng yêu cầu và cùng cách chấm.

Một câu thử là: “Em đang thử việc, cuối tháng xin nghỉ hai ngày được không?” Câu trả lời cần dẫn đúng quy định và giữ nguyên điều kiện áp dụng. Nếu thiếu dữ liệu, công cụ phải để lại chỗ cần hỏi người phụ trách. Trả lời tự tin nhưng sai thì vẫn là sai.

Nhóm ghi riêng từng lỗi: tìm nhầm văn bản, đọc sót điều kiện hay tự đoán chính sách. Việc phân loại giúp biết cần sửa kho tài liệu hay cách kết nối. Đổi mô hình liên tục sẽ khó giải quyết lỗi bắt nguồn từ một bản quy định đã hết hiệu lực.

Để thống nhất cách chấm, chọn trước vài câu trả lời mẫu được người phụ trách duyệt. Sau đó dùng cách đánh giá mô hình theo nhiệm vụ để ghi kết quả. Đừng chọn bên thắng chỉ vì câu chữ nghe thân thiện hơn.

Cho người dùng thật làm thử một lượt. Huy quan sát xem họ có mở đường dẫn nguồn không, có hiểu câu nào chưa được xác nhận không. Một câu trả lời đúng nhưng trình bày khiến người đọc hiểu nhầm vẫn cần sửa trước khi đưa vào việc hằng ngày.

Cuối buổi, thêm một phép thử hơi khó chịu: bỏ quyền đọc một tài liệu rồi hỏi lại. Kết quả có còn trích nội dung ấy không? Đây là bài kiểm tra của toàn bộ hệ thống, gồm cả phần tìm kiếm và dữ liệu lưu tạm, chứ không riêng mô hình.

Quyền kiểm soát phải dùng được khi có sự cố

Trước khi chọn, Huy đề nghị diễn tập ba việc: khóa tài khoản mẫu, xuất dữ liệu cần giữ và chuyển sang cách tra cứu thủ công. Mỗi việc có người chịu trách nhiệm và bước thực hiện rõ ràng. Làm được một lần sẽ dễ phát hiện chỗ còn thiếu.

Riêng chuyện chuyển nhà cung cấp, hãy thử mở dữ liệu đã xuất bằng một công cụ khác. Nếu nhận được một tệp nhưng không hiểu cấu trúc, nhóm chưa thật sự sẵn sàng chuyển. Cần giữ cả tài liệu nguồn, cấu hình cần thiết và hướng dẫn nối lại quy trình.

Phần chuẩn bị khả năng chuyển đổi dịch vụ AI sẽ hữu ích khi lên danh sách này. Không cần làm một kế hoạch đồ sộ. Chỉ cần trả lời được ngày mai dịch vụ dừng thì ai làm gì và nhân viên tìm thông tin ở đâu.

Trong ví dụ của Huy, lựa chọn cuối có thể là tự chạy, thuê dịch vụ hoặc thử nhỏ thêm một đợt. Điều đáng giữ là bảng yêu cầu và kết quả kiểm tra. Nhờ chúng, nhóm có thể giải thích mình chọn vì điều gì, thay vì tranh luận mãi xem bên nào “mở” hơn.