Các mô hình AI tốt hơn và rẻ hơn liên tục ra mắt. Mô hình phù hợp khi bạn phát hành ứng dụng có thể không còn là lựa chọn tốt nhất chỉ sau vài tuần. Nhưng nếu ID của mô hình đó nằm trong ứng dụng iOS đã phát hành hoặc server đã deploy, mỗi lần nâng cấp lại trở thành một bản phát hành mới. Làm sao để giữ ứng dụng luôn cập nhật trong khi người dùng vẫn chạy các bản build cũ? Haimaker cho phép bạn cập nhật các mô hình mà ứng dụng sử dụng mà không cần deploy lại. Gửi haimaker/auto làm model ID, sau đó thay đổi mô hình mặc định hoặc các quy tắc theo prompt trong dashboard.
Vấn đề này lặp lại với mỗi lần phát hành mô hình mới. Developer cần kiểm tra chất lượng, chi phí và khả năng của mô hình, chi phí và khả năng đối với workload của họ. Khi lựa chọn mô hình nằm ngoài mã đã deploy, họ có thể áp dụng kết quả đó ngay mà không cần lên lịch thêm một bản phát hành ứng dụng hay server.
Model ID cố định sẽ lỗi thời sau khi phát hành
Một model ID cố định khiến mọi lần nâng cấp mô hình phụ thuộc vào quy trình phát hành của ứng dụng. Điều này vẫn khả thi khi bạn đang xây dựng phiên bản đầu tiên. Sau khi ra mắt, mỗi mô hình mới tiềm năng hoặc thay đổi giá đều có thể kéo theo việc sửa mã, chạy test, deploy server, hoặc gửi bản cập nhật mobile. Các mô hình mới có thể ra mắt xen giữa các lần phát hành ứng dụng.
Đối với ứng dụng iOS, model ID được nhúng trong client không thể thay đổi với người dùng chưa cài đặt bản cập nhật. Apple xem xét các bản cập nhật ứng dụng trước khi phân phối, và người dùng có thể giữ phiên bản cũ rất lâu sau khi bản build mới đã có sẵn. Chuyển API call sang backend giúp tránh đặt provider key trong ứng dụng, nhưng model ID được hard-code trên backend đó vẫn cần thay đổi cấu hình hoặc deploy lại.
Chỉ riêng một gateway endpoint thì không giải quyết được vấn đề. Nếu một request chỉ định một mô hình cố định, bên gọi vẫn bị ràng buộc với lựa chọn đó. Ví dụ, OpenRouter hỗ trợ các mô hình được đặt tên cũng như openrouter/auto router riêng của họ. Một auto-router có thể giữ lựa chọn mô hình tách khỏi mã đã deploy. Haimaker cho phép bạn điều chỉnh chính sách định tuyến cho các lớp prompt riêng sau khi ứng dụng đã phát hành.
Làm sao để ứng dụng đã deploy theo kịp các mô hình mới?
Gửi một model ID ổn định từ ứng dụng và giữ chính sách lựa chọn trong Haimaker. Một router có mô hình mặc định cho các request không khớp và các quy tắc gửi những loại prompt cụ thể đến nơi khác. Router được gán cho một API key. Khi bạn thay đổi các đích của nó, các request sau đó có thể đến các mô hình khác nhau mặc dù bên gọi đã deploy vẫn gửi haimaker/auto.
Trên sản phẩm mobile, ứng dụng nên gọi backend của bạn, và backend nên gọi Haimaker. Điều này giúp API key không nằm trên thiết bị người dùng. Ứng dụng phía server có thể áp dụng trực tiếp cùng cách làm này: mã request giữ nguyên trong khi người quản lý điều chỉnh router. Tài liệu thiết lập hướng dẫn cách tạo router, chọn mô hình mặc định, gán API key và kiểm tra request.
import OpenAI from "openai";
// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
baseURL: "https://api.haimaker.ai/v1",
apiKey: process.env.HAIMAKER_API_KEY,
});
const response = await client.chat.completions.create({
model: "haimaker/auto",
messages: [{ role: "user", content: prompt }],
});
Đoạn mã trên không cần tên mô hình mới khi mô hình mặc định thay đổi. Haimaker cache cấu hình router trong tối đa 60 giây, vì vậy hãy chờ khoảng một phút để chỉnh sửa trong dashboard áp dụng cho tất cả các request tiếp theo.
Cập nhật mô hình mặc định, sau đó định tuyến tác vụ rẻ hơn riêng biệt
Thay đổi mô hình mặc định sẽ nâng cấp toàn bộ workload. Các quy tắc cho phép bạn thực hiện thay đổi hẹp hơn khi một mô hình mới rẻ hơn hoặc tốt hơn cho một tác vụ cụ thể. Sự khác biệt này rất quan trọng: một ứng dụng có thể cần mô hình mặc định mạnh cho việc chỉnh sửa văn bản dài trong khi gửi các gợi ý tiêu đề ngắn đến mô hình chi phí thấp hơn. Cả hai quyết định đều có thể thay đổi sau khi phát hành mà không cần thay đổi model ID của bên gọi.
Hãy tưởng tượng một ứng dụng soạn thảo văn bản mà backend gửi mọi AI request qua cùng một router. Một mô hình mới ra mắt cải thiện khả năng chỉnh sửa văn bản dài, nên nhóm kiểm tra và thay đổi mô hình mặc định của router. Sau đó, một mô hình rẻ hơn xử lý gợi ý tiêu đề đủ tốt. Nhóm thêm một quy tắc với các ví dụ như “Gợi ý năm tiêu đề ngắn cho ghi chú này” và “Đặt một tiêu đề ngắn gọn cho bản nháp này,” rồi hướng quy tắc đó đến mô hình rẻ hơn. Người dùng trên phiên bản ứng dụng cũ nhận được cả hai thay đổi thông qua backend hiện có.
Đối với quy tắc dựa trên ví dụ, sử dụng 3 đến 10 prompt đại diện cho mỗi tác vụ. Prompt khớp sẽ được định tuyến đến mô hình đích của quy tắc; các request không khớp sử dụng mô hình mặc định. Cơ chế kiểm tra khả năng ngăn một quy tắc gửi request vision, tool-use hoặc structured-output đến mô hình không xử lý được. Nhật ký định tuyến hiển thị mô hình được giải quyết và quy tắc đã chọn nó. Về cơ chế đằng sau việc khớp và fallback, xem hướng dẫn định tuyến và hướng dẫn định tuyến theo chi phí của chúng tôi.
Điều này thay đổi gì cho một nhóm sau khi ra mắt?
Lợi ích chính là việc lựa chọn mô hình có thể theo workload thay vì lịch phát hành. Một nhóm có thể áp dụng mô hình mặc định mới, chuyển một lớp prompt lặp đi lặp lại sang mô hình rẻ hơn, hoặc khôi phục đích trước đó nếu kết quả kém đi. Mã server và client mobile đã cài đặt tiếp tục thực hiện cùng một API request. Công việc chuyển sang kiểm tra và đánh giá quyết định định tuyến.
| Thay đổi sau khi ra mắt | Với mô hình cố định trong mã | Với haimaker/auto |
|---|---|---|
| Mô hình tổng quát tốt hơn ra mắt | Thay đổi model ID và phát hành mã hoặc cấu hình | Kiểm tra, sau đó thay đổi mô hình mặc định của router |
| Mô hình rẻ hơn phù hợp với một lớp prompt | Thêm logic định tuyến ứng dụng và deploy | Thêm hoặc sửa quy tắc cho lớp prompt đó |
| Thay đổi mô hình làm giảm chất lượng output | Hoàn nguyên thay đổi mã hoặc cấu hình | Khôi phục đích router trước đó |
| Người dùng vẫn chạy bản build mobile cũ | Model ID nhúng vẫn cũ | Backend có thể sử dụng chính sách router hiện tại |
Điều này cũng hữu ích khi bản phát hành server đang chờ xử lý những phần việc không liên quan. Quyết định về mô hình không cần phải chờ đến đợt deploy đó. Các workload riêng biệt có thể sử dụng các router riêng bằng cách gán chúng cho các API key khác nhau; Haimaker hỗ trợ một router cho mỗi key.
Thay đổi định tuyến vẫn cần sự cân nhắc tương tự như thay đổi mã. Sandbox trong dashboard hiển thị mô hình nào sẽ được chọn cho một prompt, nhưng không đảm bảo rằng câu trả lời sẽ tốt. Chạy các prompt đại diện với mô hình đề xuất, kiểm tra output thực tế, theo dõi nhật ký mô hình được giải quyết, và quay lại đích trước đó nếu chất lượng giảm. Haimaker thay đổi việc lựa chọn mô hình; thay đổi prompt, tool schema, hoặc hành vi ứng dụng vẫn cần xử lý ở phía ứng dụng.
Giữ lựa chọn mô hình sẵn sàng cho bản phát hành tiếp theo
Tạo một router, chọn mô hình mặc định, và gán nó cho API key mà backend của bạn sử dụng. Gửi haimaker/auto trong request, sau đó kiểm tra một vài prompt đại diện cho workload. Khi mô hình mới ra mắt, đánh giá nó với các prompt đó trước khi thay đổi mô hình mặc định hoặc một quy tắc hẹp. Tài liệu Haimaker bao gồm thiết lập router, sandbox kiểm tra, và lịch sử định tuyến.
Các mô hình mới có thể ra mắt trước bản phát hành ứng dụng tiếp theo của bạn. Giữ lựa chọn mô hình trong Haimaker giúp ứng dụng luôn cập nhật trong khi developer dành chu kỳ phát hành cho những thay đổi đòi hỏi mã mới.
Câu hỏi thường gặp
Làm sao để thay đổi mô hình AI trong ứng dụng mobile đã phát hành?
Để ứng dụng gọi backend của bạn, và backend gửi model: ‘haimaker/auto’ đến Haimaker. Sau đó bạn có thể thay đổi mô hình mặc định của router hoặc các quy tắc prompt trong dashboard mà không cần gửi bản build mobile mới. Thay đổi router có thể mất tối đa 60 giây để có hiệu lực.
Việc chuyển đổi mô hình qua Haimaker có cần deploy lại server không?
Không. Nếu server đã deploy gửi model: ‘haimaker/auto’ cùng với API key được gán cho một router, bạn có thể thay đổi mô hình đích của router trong dashboard. Các thay đổi về prompt ứng dụng, định dạng request, hoặc mã nguồn vẫn cần quy trình deploy thông thường.
Tôi có thể chuyển chỉ các prompt đơn giản sang mô hình rẻ hơn không?
Có. Thêm một quy tắc với 3 đến 10 prompt mẫu cho một tác vụ đơn giản và chọn mô hình đích rẻ hơn. Haimaker kiểm tra rằng mô hình đích hỗ trợ request, trong khi các prompt không khớp quy tắc sẽ sử dụng mô hình mặc định của router.