Tháng trước tôi dẫn một đồng nghiệp vừa chuyển vị trí làm nguyên mẫu chăm sóc khách hàng thông minh, yêu cầu rất đơn giản: người dùng đặt câu hỏi, mô hình trả lời, có chút ghi nhớ ngữ cảnh, có thể gõ streaming. Nghe có vẻ hai ngày là xong, kết quả là cậu ấy lần lượt vấp phải ở chỗ viết cứng API Key, logic retry, và tích hợp streaming. Tôi tổng hợp toàn bộ quy trình thành bài này, xem như ghi chú khi dẫn người mới.
Bước một: Phân tích yêu cầu trước, rồi chọn mô hình
Đừng viết code ngay từ đầu. Nhu cầu năng lực của chăm sóc khách hàng thông minh chia thành ba phần: nhận diện ý định, hỏi đáp kiến thức, trò chuyện nhiều lượt. Nhận diện ý định cần nhanh, cần rẻ, dùng DeepSeek-V3 hoặc API Qwen là đủ; hỏi đáp kiến thức liên quan đến tài liệu riêng của bạn, phải đi qua RAG, mô hình yêu cầu hiểu ngữ cảnh dài; trò chuyện nhiều lượt yêu cầu cao về giọng điệu, Claude 4 Sonnet hoặc GPT-4o ổn định hơn.
Cách làm của tôi là trước tiên dùng một mô hình đa dụng chạy thông toàn bộ pipeline, rồi thay thế từng mục. Định tuyến đa mô hình của SiCore TokenWorks lúc này rất tiện, cùng một bộ code đổi tên mô hình là có thể so sánh hiệu quả, không cần đổi xác thực. Chọn API mô hình lớn không phải chọn cái mạnh nhất, mà là chọn cái phù hợp nhất với nhiệm vụ.
Bước hai: Quản lý Key, đừng viết vào code
Viết cứng Key vào mã nguồn là lỗi phổ biến nhất của người mới. Một khi commit lên git, coi như công khai. Cách đúng là biến môi trường cộng với phân cấp tệp cấu hình: cục bộ dùng .env, kiểm thử và sản xuất dùng trung tâm cấu hình hoặc dịch vụ quản lý khóa.
Cô lập đa môi trường cần nhớ ba điểm: phát triển, kiểm thử, sản xuất dùng Key khác nhau; mỗi Key đặt giới hạn hạn mức riêng; Key sản xuất chỉ cấp cho phía máy chủ, phía trước vĩnh viễn không lấy được. Trong dự án của chúng tôi dùng SiCore TokenWorks, một Key là có thể gọi GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao và các mô hình chủ lưu khác, tiết kiệm được rắc rối bảo trì nhiều bộ xác thực, chuyển Key đa môi trường cũng chỉ là đổi một biến.
Bước ba: Đóng gói gọi và retry lỗi
Code gọi thẳng SDK không thể bảo trì được. Đóng gói một lớp, xử lý thống nhất timeout, giới hạn tốc độ, retry. Ý tưởng như sau: bọc gọi mô hình thành một hàm, tham số là messages và tên mô hình, bên trong bắt ba loại lỗi——timeout mạng, 429 giới hạn tốc độ, 5xx lỗi phía máy chủ.
Chiến lược retry dùng lùi theo cấp số nhân, lần đầu chờ 1 giây, lần hai 2 giây, lần ba 4 giây, tối đa ba lần. 429 cần xử lý đặc biệt, xem header retry-after trả về. Đừng retry tất cả các lỗi, lỗi tham số retry một trăm lần cũng vô ích. Giá trị của gateway mô hình nằm ở lớp này, gom retry, giảm cấp, log lại một chỗ, code nghiệp vụ chỉ việc lấy kết quả.
Nhắc nhở cái bẫy: retry phải idempotent. Nếu gọi có tác dụng phụ (ví dụ ghi database), trước khi retry phải xác nhận lần trước có thực sự thất bại không.
Bước bốn: Đầu ra streaming và tích hợp phía trước
Cốt lõi trải nghiệm chăm sóc khách hàng là "hiệu ứng máy đánh chữ". Phía máy chủ dùng SSE đẩy token từng khối cho phía trước, phía trước dùng EventSource hoặc ReadableStream của fetch để nhận.
Điểm then chốt phía sau: đặt stream=True, phân tích từng khối delta trả về, gặp [DONE] thì kết thúc. Điểm then chốt phía trước: đừng setState mỗi khi nhận một ký tự, gom 20 đến 50 mili giây rồi render theo lô, nếu không trang sẽ giật như slide.
Còn một cái bẫy nữa, trong quá trình streaming người dùng có thể đóng trang. Phía máy chủ phải lắng nghe sự kiện ngắt kết nối, kịp thời hủy yêu cầu thượng nguồn, nếu không là đốt token vô ích. Dưới hình thức tính phí theo lượng, sự lãng phí này tích tiểu thành đại.
Bước năm: Giám sát chi phí và cảnh báo
Trước khi lên production phải đặt event tracking. Mỗi lần gọi ghi lại: tên mô hình, số token đầu vào, số token đầu ra, thời gian, có retry hay không. Những dữ liệu này tích một tuần, bạn mới biết tiền tiêu vào đâu.
Cảnh báo đặt hai đường: chi phí một ngày vượt ngưỡng thì báo động, token một lần gọi bất thường thì báo động. Có lần một người dùng dán cả một bài tài liệu vào, một lần nhập mấy vạn token, nếu không có cảnh báo thì hóa đơn cuối tháng sẽ rất khó coi.
Kinh nghiệm tiết kiệm tiền: những nhiệm vụ tần suất cao độ khó thấp như nhận diện ý định, chuyển sang mô hình nội địa rẻ, chi phí giảm được một khúc. Mua theo lô cộng với điều phối năng lượng xanh, là lý do giá của các nền tảng tổng hợp như SiCore TokenWorks thấp hơn mua trực tiếp chính thức, chúng tôi so sánh ra, khoảng cách ở các tình huống gọi tần suất cao là rõ rệt.
Tóm lại một câu: khó khăn của nguyên mẫu chăm sóc khách hàng thông minh không nằm ở mô hình, mà ở chi tiết kỹ thuật. Quản Key tốt, viết retry đúng, tích hợp streaming ổn, theo dõi chi phí chặt, còn lại là chỉnh prompt. Muốn đi sâu vào tích hợp thống nhất đa mô hình và triển khai định tuyến mô hình, có thể tiếp tục xem theo hướng API gateway mô hình lớn.