Khi request thành công nhưng trải nghiệm vẫn thất bại
Hãy tưởng tượng bạn đã trò chuyện với cùng một nhân vật suốt nhiều tuần. Giọng điệu ấy quen thuộc, ngôn ngữ nhất quán, câu trả lời sắc sảo và sống động.
Rồi đột nhiên, dù bạn không đổi nhân vật hay mô hình, mọi thứ bắt đầu trở nên không ổn.
Câu trả lời tiếp theo mất mười giây mới bắt đầu. Một tính năng phụ thuộc vào structured output bỗng ngừng hoạt động. Nhân vật nói lan man, chèn những đoạn từ ngôn ngữ khác, hoặc trả lời theo phong cách như thể đã bị thay bằng một mô hình yếu hơn nhiều.
Từ góc nhìn của server, không có lỗi nào xảy ra. API trả về 200 OK, token đã đến và request vẫn được tính phí.
Từ góc nhìn của người dùng, mô hình vừa trở nên tệ hơn.
Khoảng cách ấy là lý do chúng tôi xây dựng hệ thống canary probe cho nhà cung cấp và cách ly routing cho Reverie.
Một tên mô hình, nhiều môi trường inference
OpenRouter là model gateway chính của chúng tôi. Một trong những ưu điểm của nó là một mô hình có thể được nhiều nhà cung cấp inference độc lập vận hành. Nếu một nhà cung cấp không khả dụng, nơi khác có thể nhận request. Nhờ vậy, chúng tôi có thêm capacity, giá cạnh tranh và khả năng chống chịu tốt hơn so với phụ thuộc vào một endpoint duy nhất.
Nhưng điều đó cũng tạo ra một biến số vô hình.
Tên mô hình có thể không đổi, trong khi hạ tầng thực sự vận hành nó lại thay đổi theo từng request. Mỗi nhà cung cấp có thể dùng inference engine, phần cứng, mức quantization, parser, chat template, queue hoặc lớp policy bổ sung khác nhau.
Tài liệu routing nhà cung cấp của OpenRouter giải thích rằng routing mặc định cân nhắc độ khả dụng gần đây và giá, đồng thời giữ các nhà cung cấp khác làm fallback. Đây là những tín hiệu quan trọng, nhưng một endpoint vẫn có thể online, rẻ và tạo ra kết quả không chấp nhận được cho một sản phẩm cụ thể.
OpenRouter cũng đã công khai thảo luận về sự khác biệt có thể đo lường giữa các nhà cung cấp vận hành cùng một mô hình. Về lý thuyết, cùng weights ở cùng độ chính xác phải có hành vi tương tự. Trong production, vận hành một mô hình lớn rất phức tạp và khác biệt vẫn xuất hiện.
“Suy giảm mô hình” có nghĩa là gì
“Suy giảm mô hình” không phải một chẩn đoán tiêu chuẩn với duy nhất một nguyên nhân. Nó cũng không tự động có nghĩa rằng nhà cung cấp cố ý thay bằng một mô hình nhỏ hơn.
Chúng tôi dùng khái niệm này theo nghĩa vận hành: một inference endpoint bị suy giảm khi không còn duy trì hành vi, khả năng hoặc hiệu năng tương tác mà chúng tôi kỳ vọng từ mô hình được yêu cầu trên các prompt đại diện, ngay cả khi request vẫn thành công về mặt kỹ thuật.
Với Reverie, các biểu hiện rõ nhất là:
- Suy giảm latency: kết nối thành công nhưng thời gian đến token đầu tiên lâu đến mức phá vỡ cảm giác trò chuyện trực tiếp.
- Suy giảm khả năng: endpoint đáng lẽ hỗ trợ structured output lại trả văn bản sai định dạng hoặc không còn đáp ứng schema.
- Suy giảm hành vi: câu trả lời bị hỏng, thiếu mạch lạc, lặp bất thường hoặc chuyển rõ rệt sang ngôn ngữ khác.
- Không tương thích policy: host upstream thêm lớp lọc riêng, biến một cảnh Reverie hỗ trợ thành lời từ chối, câu trả lời trống hoặc nội dung bị cắt.
Có thể có nhiều nguyên nhân. Quantization với độ chính xác thấp hơn có thể ảnh hưởng các prompt khó, như tài liệu OpenRouter và nghiên cứu về quantization đã công bố. Nhưng quantization không giải thích được tất cả: bug trong inference engine hoặc tool parser, lỗi tokenizer hay chat template, queue quá tải và middleware của nhà cung cấp đều có thể quan trọng không kém. OpenRouter đã quan sát rằng với tool call, cách triển khai parser thường tạo ra khác biệt lớn hơn so với chỉ riêng độ chính xác.
Câu hỏi quan trọng không phải “nguyên nhân nào nghe đáng ngờ nhất?”, mà là “chúng ta có thể cô lập endpoint và tái hiện lỗi hay không?”.
Hai trường hợp khiến vấn đề trở nên cụ thể
Đây không phải mối lo ngại lý thuyết đối với chúng tôi.
Trong một phép so sánh được pin theo từng nhà cung cấp, một nơi đã làm hỏng phần đầu của 19 trên 20 câu trả lời bằng cách chèn dấu câu hoặc mảnh token không liên quan. Trên mười bốn host khác phục vụ cùng mô hình, vấn đề xuất hiện 0 lần trong 49 câu trả lời. Trong roleplay, ký tự đầu thường là dấu nhấn Markdown, nên chỉ một byte lạ cũng có thể phá hỏng định dạng của toàn bộ câu trả lời.
Trong thử nghiệm khác, một endpoint trộn lẫn nghiêm trọng tiếng Bồ Đào Nha và Tây Ban Nha trong 3 trên 3 lần tạo. Cùng prompt đó vẫn giữ nguyên tiếng Bồ Đào Nha trên host chính thức của mô hình và các host được kiểm tra khác trong cùng lớp độ chính xác. “Mô hình vốn thiếu nhất quán” không còn là lời giải thích hợp lý; lỗi đi theo endpoint.
Những sự cố này khó thấy vì không nhất thiết phát sinh exception. Giám sát uptime truyền thống thấy một API khỏe mạnh. Người dùng thấy một nhân vật đột nhiên không còn nói chuyện bình thường.
Câu trả lời của chúng tôi: kiểm tra từng tuyến, không chỉ mô hình
Cứ mỗi ba mươi phút, canary của chúng tôi phát hiện các nhà cung cấp đang phục vụ mô hình chat mặc định của Reverie. Sau đó, nó gửi một nhóm nhỏ request tổng hợp đến từng nhà cung cấp, chỉ pin vào nơi đó và tắt fallback.
Việc pin rất quan trọng. Nếu probe được phép fallback, một nhà cung cấp khỏe mạnh thứ hai có thể che giấu lỗi của nơi đầu tiên. Chúng tôi cần biết chính xác môi trường inference nào tạo ra kết quả.
Hệ thống kiểm tra bốn hợp đồng hẹp có thể được đánh giá bằng code.
1. Thời gian đến token đầu tiên
Trong cuộc trò chuyện streaming, throughput chỉ là một nửa trải nghiệm. Token đầu tiên quyết định người dùng phải nhìn màn hình loading bao lâu.
Chúng tôi đo trực tiếp từ stream. Nhà cung cấp không tạo văn bản trong mười giây sẽ trượt probe latency. Ngưỡng được đặt rộng có chủ ý và một vòng chậm chưa đủ để loại host; áp lực queue tạm thời vẫn có thể xảy ra.
2. Lọc và từ chối im lặng
Chúng tôi gửi một đoạn tiếp nối roleplay cố định, đại diện cho traffic Reverie hỗ trợ. Probe kiểm tra finish reason, các mẫu từ chối có độ tin cậy cao và output trống.
Chúng tôi cũng chạy probe trên những host được biết là có lọc nội dung như positive control. Nếu một control bất ngờ vượt qua, chúng tôi không tuyên bố mọi nhà cung cấp khác đều khỏe; chúng tôi đánh dấu chính probe đã yếu đi. Một bài kiểm tra không còn phát hiện được lỗi đã biết không phải bằng chứng về sức khỏe.
3. Structured output
Chúng tôi yêu cầu một object nhỏ với schema cố định và xác thực kết quả. Lỗi transport và output sai định dạng được xử lý khác nhau: kết nối hỏng cho thấy không thể tiếp cận nhà cung cấp, còn generation hoàn tất nhưng không đáp ứng schema là bằng chứng về suy giảm khả năng.
“Endpoint tuyên bố hỗ trợ parameter” và “endpoint tuân thủ đáng tin cậy” không phải cùng một lời hứa.
4. Tính toàn vẹn ngôn ngữ
Reverie hỗ trợ 17 ngôn ngữ giao diện, vì vậy smoke test chỉ bằng tiếng Anh sẽ bỏ sót một số vấn đề người dùng thực sự gặp phải.
Canary luân phiên qua các ngôn ngữ được hỗ trợ bằng prompt roleplay tổng hợp. Một bộ phát hiện ngôn ngữ cục bộ và deterministic tìm kiếm sự chuyển đổi rõ ràng của toàn câu trả lời sang ngôn ngữ khác, việc trộn ngôn ngữ kéo dài và lỗi encoding hiển nhiên. Nó không dùng cuộc trò chuyện thật và không yêu cầu mô hình khác đưa ra đánh giá chủ quan.
Output mơ hồ hoặc quá ngắn được xem là chưa thể kết luận, không phải thất bại. Khi phát hiện bất thường ngôn ngữ, canary lập tức chạy thêm hai lần xác nhận và yêu cầu kết quả đa số. Cùng ngôn ngữ được lặp lại ở vòng sau để nhà cung cấp không thoát khỏi quy tắc vòng liên tiếp chỉ vì lịch luân phiên đã chuyển đi.
Chúng tôi thiết kế hệ thống để nghi ngờ chính kết luận của mình
Tự động loại capacity inference rất hữu ích, nhưng false positive có thể tạo ra outage lớn hơn lỗi ban đầu. Vì vậy, canary có nhiều lớp phanh:
- Lỗi transport không được tính là lỗi chất lượng. Timeout, rate limit và response 5xx đóng băng điểm thay vì kéo dài chuỗi dẫn đến suspension.
- Một vòng xấu chưa đủ. Nhà cung cấp phải thất bại trong hai vòng liên tiếp, mỗi vòng chạy cách nhau nửa giờ.
- Quan sát và thực thi được tách riêng. Chúng tôi có thể chạy hệ thống ở observe mode, ghi lại host nào sẽ bị suspension, thông báo cho quản trị viên và đo false positive trước khi bật hành động tự động.
- Capacity có giới hạn tối thiểu. Canary không suspension nhà cung cấp nếu việc đó khiến còn dưới hai production host. Thay vào đó, hệ thống cảnh báo quản trị viên.
- Khôi phục cũng được kiểm tra. Nhà cung cấp bị suspension vẫn tiếp tục nhận probe. Hai vòng sạch liên tiếp sẽ đưa host trở lại sớm.
- Lỗi lặp lại tăng dần thời gian. Suspension kéo dài một ngày cho lần đầu, ba ngày cho lần tiếp theo và bảy ngày sau đó. Sau mười bốn ngày không có suspension mới, lịch sử mờ dần và thang bắt đầu lại.
Mục tiêu không phải trừng phạt nhà cung cấp. Mục tiêu là đưa traffic người dùng ra khỏi tuyến có lỗi tái hiện được, đồng thời giữ một con đường rõ ràng để quay lại khi vấn đề được sửa.
Ba lớp bảo vệ
Quyết định routing cuối cùng kết hợp ba loại loại trừ:
- Loại trừ tích hợp đã được review cho các lỗi hoặc policy mismatch mà chúng tôi đã đo và không muốn vô tình đưa trở lại.
- Loại trừ sự cố ở runtime mà quản trị viên có thể thêm ngay mà không cần chờ deployment.
- Canary suspension có thời hạn cho các nhà cung cấp vượt qua ngưỡng lỗi tự động.
Các danh sách này được hợp nhất vào tùy chọn provider.ignore của OpenRouter khi Reverie tạo request. Người dùng không phải thử lại cho đến khi ngẫu nhiên gặp một nhà cung cấp tốt hơn; tuyến không khỏe bị loại khỏi danh sách ứng viên.
Mọi quyết định tự động đều được ghi lại, quản trị viên được thông báo khi có thay đổi trạng thái quan trọng và suspension có thể được gỡ thủ công khi cần.
Hệ thống này đảm bảo điều gì — và không đảm bảo điều gì
Canary được giữ phạm vi hẹp có chủ ý. Code có thể đánh giá latency, tính hợp lệ của schema, việc lọc có độ tin cậy cao, tính toàn vẹn của ngôn ngữ và encoding. Nó không giả vờ chấm điểm liệu một nhân vật có đủ hài hước, đủ tinh tế về cảm xúc hay trung thành tuyệt đối với một tính cách phức tạp hay không.
Những câu hỏi rộng hơn vẫn cần đánh giá bằng prompt đại diện, review của con người, production telemetry và quan trọng nhất là báo cáo từ người dùng.
Hệ thống cũng không có nghĩa mọi câu trả lời lạ đều chứng minh mô hình suy giảm. Mô hình tạo sinh mang tính xác suất. Một cuộc trò chuyện dài có thể tích lũy ngữ cảnh mâu thuẫn và định nghĩa nhân vật có thể chứa các chỉ dẫn cạnh tranh. Đôi khi một câu trả lời lạ chỉ đơn giản là một câu trả lời lạ.
Điều thay đổi là “cùng một mô hình” không còn kết thúc cuộc điều tra của chúng tôi. Giờ đây, chúng tôi có thể cô lập tuyến phục vụ, tái hiện lỗi khách quan và giữ traffic tiếp theo tránh xa nó.
Độ tin cậy nghĩa là bảo toàn trải nghiệm
Routing đa nhà cung cấp vẫn rất có giá trị. Nó mang lại cho Reverie capacity và khả năng chống chịu để duy trì cuộc trò chuyện khi một endpoint riêng lẻ gặp sự cố.
Nhưng khả năng chống chịu không chỉ là nhận được HTTP response. Một câu trả lời bắt đầu quá muộn, mất cấu trúc bắt buộc, từ chối nội dung được hỗ trợ hoặc bất ngờ đổi ngôn ngữ không trở thành kết quả khỏe mạnh chỉ vì hóa đơn ghi request thành công.
Đối với sản phẩm nhân vật AI, độ tin cậy mang ý nghĩa con người hơn: dù máy nào đang nói thay, nhân vật vẫn phải luôn tạo cảm giác là chính nhân vật đó.
Đó là tiêu chuẩn mà các biện pháp bảo vệ routing mới của chúng tôi được xây dựng để gìn giữ.
Nếu bạn nhận thấy chất lượng hoặc ngôn ngữ của câu trả lời thay đổi đột ngột, hãy gửi báo cáo kèm tên mô hình và thời gian gần đúng. Thông tin đó giúp chúng tôi nối trải nghiệm bạn thấy với chính xác tuyến đã phục vụ nó.