Chuyển đổi giữa các model AI mà không phải viết lại hệ thống

Nhà cung cấp model bạn đang dùng vừa tăng giá, nhưng đội kỹ thuật báo lại rằng đổi sang nhà cung cấp khác sẽ mất vài tuần vì code gọi model nằm rải rác khắp hệ thống, mỗi nơi viết một kiểu khác nhau. Đây chính là cái giá của việc bị khoá chân vào một nhà cung cấp, và nó khiến doanh nghiệp mất hẳn quyền thương lượng ngay khi cần nhất. Bài này hướng dẫn bạn dựng một lớp trung gian đơn giản để chuyển đổi model dễ dàng, tách prompt ra khỏi mã nguồn, và có quy trình kiểm thử để đổi model mà không lo hệ thống vỡ trận.

Vì sao doanh nghiệp bị khoá chân vào một nhà cung cấp

Tình trạng khoá chân thường không đến từ một quyết định có chủ đích, mà từ việc mỗi lập trình viên trong đội gọi thẳng API của nhà cung cấp ngay tại nơi cần dùng, không qua một lớp trung gian thống nhất nào. Sau một năm phát triển, lời gọi model xuất hiện rải rác ở hàng chục file khác nhau, mỗi nơi định dạng tham số hơi khác nhau tuỳ người viết, khiến việc đổi sang nhà cung cấp khác biến thành một dự án lớn thay vì một thay đổi cấu hình đơn giản.

Hậu quả rõ ràng nhất là mất quyền thương lượng giá. Khi nhà cung cấp biết bạn không có phương án thay thế khả thi trong ngắn hạn, họ không có động lực giữ giá cạnh tranh hay ưu đãi cho bạn. Ngược lại, một hệ thống có thể chuyển đổi model trong vài giờ thay vì vài tuần luôn có vị thế đàm phán tốt hơn nhiều. Đây không chỉ là câu chuyện kỹ thuật, mà còn là câu chuyện quản trị rủi ro kinh doanh: doanh nghiệp phụ thuộc hoàn toàn vào một nhà cung cấp giống như một cửa hàng chỉ nhập hàng từ một nhà phân phối duy nhất, hoạt động ổn định cho đến ngày nhà phân phối đó đổi chính sách mà không còn ai để thương lượng.

Dựng lớp trừu tượng cho lời gọi model

Nguyên tắc cốt lõi là toàn bộ hệ thống chỉ gọi vào một hàm hoặc một dịch vụ nội bộ duy nhất để "hỏi model", chứ không gọi thẳng API của từng nhà cung cấp ở nhiều nơi khác nhau. Lớp trung gian này nhận vào yêu cầu theo định dạng chung do chính bạn quy định, rồi bên trong nó mới chuyển đổi sang đúng định dạng của nhà cung cấp đang dùng thật.

1. 1

   Định nghĩa một định dạng yêu cầu và phản hồi chung

   Quy định rõ cấu trúc chung cho mọi lời gọi model trong hệ thống: nội dung hội thoại, tham số điều chỉnh độ sáng tạo, định dạng công cụ được phép gọi. Toàn bộ code nghiệp vụ chỉ làm việc với định dạng chung này.

2. 2

   Viết một lớp chuyển đổi riêng cho từng nhà cung cấp

   Mỗi nhà cung cấp có một lớp chuyển đổi riêng, nhận định dạng chung và dịch sang đúng định dạng API của nhà cung cấp đó, rồi dịch ngược phản hồi trả về đúng định dạng chung.

3. 3

   Đưa việc chọn nhà cung cấp ra thành cấu hình

   Nhà cung cấp và tên model đang dùng nên nằm trong file cấu hình hoặc biến môi trường, không viết cứng trong code, để đổi model chỉ cần đổi một dòng cấu hình rồi khởi động lại.

4. 4

   Cân nhắc dùng cổng API trung gian có sẵn thay vì tự viết từ đầu

   Nếu không muốn tự xây dựng và bảo trì lớp chuyển đổi này, các cổng trung gian như LiteLLM đã làm sẵn phần lớn công việc dịch định dạng giữa nhiều nhà cung cấp, giúp bạn tiết kiệm đáng kể công sức phát triển ban đầu.

Tách prompt ra khỏi mã nguồn

Một sai lầm phổ biến khác là viết prompt (câu lệnh hướng dẫn model) trực tiếp trong code dưới dạng chuỗi ký tự cố định, xen lẫn với logic nghiệp vụ. Cách này khiến việc điều chỉnh prompt khi đổi model — điều gần như luôn cần thiết vì mỗi model phản ứng khác nhau với cùng một câu lệnh — đòi hỏi phải sửa code và triển khai lại toàn bộ ứng dụng, dù bản chất chỉ là thay đổi một đoạn văn bản hướng dẫn.

Thay vào đó, hãy lưu prompt trong file cấu hình riêng hoặc một hệ thống quản lý prompt tách biệt khỏi code, đánh số phiên bản rõ ràng cho từng lần chỉnh sửa. Cách làm này mang lại hai lợi ích cùng lúc: đổi model không cần đụng vào code nghiệp vụ, và bạn có thể thử nghiệm nhiều phiên bản prompt khác nhau trên cùng một model mà không phải triển khai lại ứng dụng mỗi lần thử.

Những khác biệt thực tế cần xử lý khi đổi model

Tuy nhiều nhà cung cấp lớn hiện đã hỗ trợ định dạng giao diện API tương thích với chuẩn phổ biến trên thị trường, giúp việc chuyển đổi cơ bản dễ dàng hơn trước rất nhiều, nhưng vẫn còn những khác biệt nhỏ dễ gây lỗi nếu không kiểm tra kỹ trước khi đổi.

Quy trình kiểm thử hồi quy trước khi đổi model thật

Dựng xong lớp trung gian và tách prompt là điều kiện cần, nhưng chưa đủ để đổi model an toàn. Bạn còn cần một bộ kiểm thử hồi quy — chạy lại cùng một tập câu hỏi mẫu qua model mới trước khi đưa vào dùng thật, để phát hiện sớm những trường hợp model mới trả lời khác đi so với mong đợi.

Đây chính là lúc bộ test nội bộ mà bạn có thể dựng theo bài Cách tự đánh giá model AI bằng bộ test của chính doanh nghiệp phát huy tác dụng: chạy đúng bộ câu hỏi đó qua model mới, so sánh điểm số với model cũ, và chỉ chuyển đổi chính thức khi chất lượng trên các tiêu chí quan trọng nhất không giảm đáng kể. Nên triển khai theo hình thức chuyển dần một phần nhỏ lưu lượng sang model mới trước, theo dõi sát trong vài ngày, rồi mới chuyển toàn bộ nếu mọi thứ ổn định.

Checklist trước khi chuyển đổi model chính thức

• Toàn bộ lời gọi model trong hệ thống đi qua một lớp trung gian duy nhất
• Prompt được lưu tách biệt khỏi code, có đánh số phiên bản rõ ràng
• Đã chạy kiểm thử hồi quy trên model mới, so sánh điểm số với model cũ
• Có kế hoạch chuyển dần lưu lượng thay vì đổi toàn bộ ngay lập tức

Đầu tư dựng lớp trung gian và quy trình kiểm thử này ngay từ đầu có thể tốn thêm vài ngày công sức ban đầu, nhưng đổi lại doanh nghiệp giữ được quyền chủ động trước mọi biến động giá cả hay chất lượng dịch vụ từ phía nhà cung cấp. Nếu bạn đang cân nhắc dùng thêm model thứ hai song song với model hiện tại thay vì chỉ đổi hẳn sang model mới, bài Dùng nhiều model song song: khi nào có lợi, khi nào rối việc sẽ giúp bạn cân nhắc thêm hướng đi này, và đừng quên xem lại bài gốc AI Model là gì và doanh nghiệp nên chọn model nào cho công việc để có bức tranh tổng thể về cách chọn model phù hợp cho từng giai đoạn phát triển.

Câu hỏi thường gặp