Sau khi mô hình nguồn mở bị hạn chế, điều đầu tiên cần độc lập là lớp trung lập của mô hình.
Không thành vấn đề nếu mô hình có thể được thay đổi. Điều thực sự rắc rối là hành vi mặc định được mã hóa cứng trong mã.
Khi một mô hình nguồn mở bắt đầu bị hạn chế, điều đầu tiên lộ ra thường không phải là mục tải xuống mà là các giả định mặc định trong mã. Tên mô hình đã được thay đổi, nhưng giao diện vẫn còn đó, nhưng quy trình nghiệp vụ không còn đồng bộ với hành vi cũ: định dạng đầu ra, chuỗi lệnh gọi hàm, âm từ chối, độ dài ngữ cảnh, tham số lấy mẫu, bất kỳ một trong số chúng có thể được xem riêng lẻ, nhưng xếp chồng chúng lại với nhau sẽ kéo toàn bộ liên kết.
Loại vấn đề này thường khó được coi là một vấn đề kiến trúc. Trong giai đoạn phát triển mình chỉ thấy “chạy được”. Sau khi lên mạng, tôi phát hiện ra rằng việc lựa chọn mô hình đã được ghi vào logic nghiệp vụ. Một số trường chỉ thích ứng với một định dạng trả về, một số lần thử lại chỉ nhận ra một phương pháp từ chối và một số trường dự phòng ngoại lệ được đặt mặc định thành mô hình ban đầu để đưa ra giải thích dài hơn. Một khi các hạn chế được áp đặt, tất cả những đống ẩn này đều bị lộ.
Hành vi mặc định sẽ gắn mô hình với doanh nghiệp
Trong giai đoạn truy cập, mô hình thường được coi là thêm SDK, kết nối API và thêm lời nhắc. Sau khi được kết nối, điều khó dọn dẹp nhất không phải là lệnh gọi mà là các nhánh đã phát triển xung quanh hành vi mặc định. Liệu đầu ra có phải hoàn toàn là JSON hay không, liệu lệnh gọi công cụ có nên được thử lại sau khi thất bại hay không, nơi cần cắt ngắn đầu vào quá dài và lớp nào để đặt lời nhắc kiểm soát rủi ro. Những vấn đề này thường rơi vào mã doanh nghiệp.
Khi một mô hình nguồn mở bị hạn chế hoặc bị xóa khỏi giá hoặc hình ảnh cục bộ và phiên bản ngược dòng bắt đầu phân nhánh, các hành vi mặc định này không còn đáng tin cậy nữa. Nhìn bề ngoài, nó chỉ là thay đổi mô hình, nhưng bên dưới cần phải thay đổi phân tích cú pháp, giám sát, khôi phục và thử nghiệm cùng một lúc. Phần khó nhất không phải là viết thêm vài dòng chuyển thể mà là bộ giả định ban đầu không được đánh dấu rõ ràng từ đầu đến cuối.
Vai trò của lớp trung lập là truyền bá các giả định ngầm
Các lớp trung lập với mô hình không trừu tượng vì mục đích trừu tượng. Chức năng của nó rất đơn giản: đặt các từ nhắc nhở, xác minh lược đồ, định tuyến, thử lại, hạ cấp, ghi nhật ký và đánh giá ở một nơi, sao cho những khác biệt về mô hình trước tiên sẽ vượt qua cùng một tập hợp các ranh giới. Bằng cách này, ngay cả khi mô hình được thay thế bằng đám mây, nguồn mở, suy luận cục bộ hoặc các nhà cung cấp khác, doanh nghiệp vẫn sẽ thấy một hợp đồng đầu vào và đầu ra thống nhất.
Một khi lớp này được thiết lập, nhiều điều vốn chưa rõ ràng sẽ đột nhiên trở nên rõ ràng. Trường nào là giá trị bắt buộc, trường nào chỉ là tùy chọn mô hình, lỗi nào có thể thử lại, lỗi nào phải được khôi phục, ngữ cảnh nào sẽ bị cắt bớt và chỉ báo nào thực sự có thể so sánh được, tất cả sẽ thay đổi từ “được ghi nhớ theo kinh nghiệm” thành “bị hạn chế bởi giao diện”. Tác động do mô hình hạn chế gây ra không còn được nhập trực tiếp vào mã doanh nghiệp mà trước tiên được nhập vào lớp trung lập.
Không phải tất cả các cảnh đều xứng đáng với lớp này
Một số cảnh không cần các lớp quá dày. Tóm tắt một lần, tạo tạm thời, thử nghiệm nội bộ và chuỗi công cụ được khóa hoàn toàn theo mô hình đơn, chỉ cần kết nối mô hình ở những nơi này là đủ. Việc xây dựng một lớp trung tính hoàn chỉnh cho một quy trình tồn tại trong thời gian ngắn sẽ chỉ khiến chi phí vượt mức trước đó.
Lớp này cần thiết để mô hình thực sự tham gia vào quá trình đánh giá hoạt động kinh doanh. Chẳng hạn như trích xuất, định tuyến, thực thi công cụ, phản hồi dịch vụ khách hàng, hỗ trợ đánh giá và viết lại hàng loạt. Trong những tình huống này, mô hình không phải là một món đồ chơi mà là một phần của quá trình. Miễn là mô hình có thể thay đổi hoặc các ràng buộc bên ngoài có thể làm mất ổn định một lối vào nhất định, lớp trung tính không phải là vật trang trí mà là bức tường giữ sự thay đổi trong các ranh giới.
Điều thực sự buộc mô hình nguồn mở bị hạn chế không phải là sự thay thế của một nhà cung cấp cụ thể, mà là liệu nhóm có coi “sự khác biệt về mô hình” như những công dân hạng nhất hay không. Hành vi mặc định trong mã càng sớm được dàn trải thì sau này nó sẽ càng ít thụ động hơn khi thay đổi mô hình. Mô hình có thể thay đổi, nhưng ranh giới không thể tuân theo.
What to read next
Want more posts about AI?
Posts in the same category are usually the best next step for reading more on this topic.
View same categoryWant to keep following #AI?
Tags are useful for related tools, specific problems, and similar troubleshooting notes.
View same tagWant to explore another direction?
If you are not sure what to read next, return to the homepage and start from categories, topics, or latest updates.
Back home