Kapag Pagkabigo Pa Rin ang Isang Matagumpay na Request
Isipin mong ilang linggo ka nang nakikipag-usap sa iisang karakter. Pamilyar na ang boses niya. Pare-pareho ang wika niya. Matalas at buhay ang pakiramdam ng mga sagot niya.
Pagkatapos, nang walang binago sa karakter o sa model, may parang mali.
Inaabot ng sampung segundo bago magsimula ang susunod na sagot. Biglang nasisira ang isang feature na umaasa sa structured output. Nagsisimulang magpaligoy-ligoy ang karakter, nagsisingit ng mga piraso ng ibang wika, o sumasagot sa istilong parang galing sa mas mahinang model.
Mula sa pananaw ng server, walang pumalya. Nagbalik ang API ng 200 OK. Dumating ang mga token. Nasingil ang request.
Mula sa pananaw ng user, basta na lang pumangit ang model.
Ang agwat na iyan ang dahilan kung bakit gumawa kami ng provider canary at sistema ng routing quarantine para sa Reverie.
Iisang Pangalan ng Model, Maraming Serving Environment
Ang OpenRouter ang pangunahing gateway namin sa mga model. Isa sa mga lakas nito ay puwedeng i-serve ng maraming independiyenteng inference provider ang iisang model. Kung hindi available ang isang provider, puwedeng saluhin ng iba ang request. Mas maraming capacity, mapagkumpitensyang presyo, at mas matibay na resilience ang naibibigay nito kaysa sa pag-asa sa iisang endpoint.
Pero lumilikha rin ito ng nakatagong variable.
Puwedeng manatiling pareho ang pangalan ng model, pero puwedeng magbago ang infrastructure na nagse-serve nito mula sa isang request papunta sa susunod. Puwedeng gumamit ang bawat provider ng ibang inference engine, configuration ng hardware, antas ng quantization, parser, chat template, queue, o karagdagang layer ng patakaran.
Ipinapaliwanag ng dokumentasyon ng OpenRouter tungkol sa provider routing na isinasaalang-alang ng default na routing nito ang kamakailang availability at presyo, at may ibang provider na nakahanda bilang fallback. Mahahalagang signal ang mga iyon—pero puwedeng online at mura ang isang endpoint at gumawa pa rin ng resultang hindi katanggap-tanggap para sa isang partikular na produkto.
Hayagan ding sumulat ang OpenRouter tungkol sa nasusukat na pagkakaiba ng mga provider na nagse-serve ng iisang model. Sa teorya, dapat magkapareho ang kilos ng magkaparehong weights sa magkaparehong precision. Sa production, komplikado ang pagse-serve ng isang malaking model, at lumilitaw ang mga pagkakaiba.
Ano ang Ibig Naming Sabihin sa “Pagbaba ng Kalidad ng Model”
Hindi iisang standardized na diagnosis ang “pagbaba ng kalidad ng model,” at hindi ito awtomatikong nangangahulugang sinadya ng isang provider na palitan ito ng mas maliit na model.
Ginagamit namin ang termino sa praktikal na paraan: bumaba ang kalidad ng isang serving endpoint kapag hindi na nito napapanatili ang kilos, mga kakayahan, o interactive na performance na inaasahan namin mula sa hiniling na model sa ilalim ng mga representatibong prompt—kahit teknikal na matagumpay ang request.
Para sa Reverie, ito ang mga pinakamalinaw na anyo:
- Pagbaba sa latency — matagumpay ang koneksyon, pero humahaba ang time to first token hanggang masira ang pakiramdam ng live na usapan.
- Pagbaba sa kakayahan — ang endpoint na inaasahang sumusuporta sa structured output ay nagbabalik ng sirang text o hindi na tumutugma sa schema.
- Pagbaba sa kilos — nagiging sira, magulo, hindi inaasahang paulit-ulit ang mga sagot, o halatang lumilihis sa ibang wika.
- Hindi pagtutugma ng patakaran — nagdadagdag ang isang upstream host ng sarili nitong layer ng pag-filter, kaya nagiging pagtanggi, walang laman na sagot, o putol na reply ang isang eksenang sinusuportahan ng Reverie.
Maaaring maraming sanhi. Maaaring maapektuhan ng quantization na mas mababa ang precision ang mahihirap na prompt, gaya ng binabanggit ng dokumentasyon ng OpenRouter at ng nailathalang pananaliksik tungkol sa quantization. Pero hindi pangkalahatang paliwanag ang quantization: kasinghalaga rin ang mga bug sa inference engine, mga tool parser, mga pagkakamali sa tokenizer o chat template, mga punong-punong queue, at middleware sa panig ng provider. Napansin ng OpenRouter na, lalo na para sa mga tool call, mas malaking pinagmumulan ng pagkakaiba ang mga implementasyon ng parser kaysa sa precision lang.
Ang mahalagang tanong ay hindi “Aling sanhi ang pinakakahina-hinala pakinggan?” Ito ay “Kaya ba naming ihiwalay ang endpoint at ulitin ang pagkabigo?”
Dalawang Kaso na Nagpakonkreto sa Problema
Hindi ito teoretikal na alalahanin para sa amin.
Sa isang naka-pin na paghahambing, sinira ng isang provider ang simula ng 19 sa 20 reply sa pamamagitan ng pagsisingit ng bantas o ng piraso ng isang walang kaugnayang token. Sa labing-apat na iba pang host na nagse-serve ng parehong model, lumitaw ang isyu nang 0 beses sa 49 reply. Sa roleplay, kung saan madalas na Markdown emphasis marker ang unang character, kayang sirain ng isang ligaw na byte ang formatting ng buong sagot.
Sa isa pang test, gumawa ang isang endpoint ng matinding paghahalo ng Portuguese at Spanish sa 3 sa 3 generation. Nanatili sa Portuguese ang parehong prompt sa opisyal na host ng model at sa iba pang na-test na host na gumagamit ng parehong klase ng precision. Dahil doon, naging mahinang paliwanag ang “sadyang hindi consistent ang model”; sumusunod ang depekto sa serving endpoint.
Mahirap mapansin ang mga pagkabigong ito dahil hindi naman sila laging nagtatapon ng exception. Malusog na API ang nakikita ng tradisyonal na uptime monitoring. Ang nakikita ng user ay isang karakter na biglang hindi na makapagsalita nang maayos.
Ang Sagot Namin: I-test ang Bawat Ruta, Hindi Lang ang Model
Tuwing tatlumpung minuto, inaalam ng canary namin ang mga aktibong provider na nagse-serve ng default na chat model ng Reverie. Pagkatapos, nagpapadala ito ng maliit na set ng mga synthetic na request sa bawat provider, naka-pin sa provider na iyon lang at naka-disable ang mga fallback.
Mahalaga ang pag-pin. Kung papayagang mag-fallback ang isang probe, puwedeng itago ng isang malusog na pangalawang provider ang pagkabigo ng una. Kailangan naming malaman kung aling serving environment mismo ang gumawa ng resulta.
Apat na makitid na kontrata na kayang hatulan ng makina ang tine-test ng sistema.
1. Time to First Token
Para sa isang streaming na usapan, kalahati lang ng karanasan ang throughput. Ang unang token ang nagtatakda kung gaano katagal nakatitig ang user sa isang spinner.
Direkta namin itong sinusukat mula sa stream. Bagsak sa latency probe ang provider na walang nailalabas na text sa loob ng sampung segundo. Sinadyang maluwag ang threshold, at hindi sapat ang isang mabagal na round para tanggalin ang isang host; nangyayari talaga ang panandaliang pressure sa queue.
2. Pag-filter at mga Tahimik na Pagtanggi
Nagpapadala kami ng isang nakapirming roleplay continuation na kumakatawan sa traffic na sinusuportahan ng Reverie. Sinusuri ng probe ang finish reason, mga pattern ng pagtanggi na mataas ang kumpiyansa, at walang lamang output.
Pinapatakbo rin namin ang probe sa mga host na kilalang nagfi-filter bilang mga positive control. Kung hindi inaasahang pumasa ang isang control, hindi namin binabati ang lahat ng iba pang provider—minamarkahan namin ang mismong probe bilang mahina. Hindi ebidensya ng kalusugan ang isang test na hindi na kayang tukuyin ang kilala nitong failure mode.
3. Structured Output
Humihiling kami ng isang maliit na object na may nakapirming schema at vina-validate namin ang resulta. Magkaiba ang pagtrato namin sa transport error at sa sirang output: sinasabi ng putol na koneksyon na hindi maabot ang provider, habang ang matagumpay na generation na hindi tumutugma sa schema ay ebidensya ng pagbaba ng kakayahan.
Mahalaga ang pagkakaibang ito. Hindi magkaparehong pangako ang “sinasabi ng endpoint na sinusuportahan nito ang parameter” at ang “maaasahang sinusunod ito ng endpoint.”
4. Integridad ng Wika
Sinusuportahan ng Reverie ang 17 wika ng interface, kaya makakaligtaan ng isang English-only na smoke test ang ilan sa mga pagkabigong talagang nararanasan ng mga user namin.
Umiikot ang canary sa mga sinusuportahan naming locale gamit ang mga synthetic na roleplay prompt. Naghahanap ang isang lokal at deterministic na language detector ng tiyak na paglipat ng wika sa buong sagot, tuloy-tuloy na code-mixing, at halatang sira sa encoding. Hindi ito nagpapadala ng totoong mga usapan sa probe, at hindi ito humihingi sa ibang model ng subhetibong paghatol.
Hindi tiyak, hindi pagkabigo, ang malabo o napakaikling output. Kapag may natukoy na pagkabigo sa wika, agad na nagpapatakbo ang canary ng dalawang pagtatangkang pagkumpirma at nangangailangan ng mayorya. Inuulit ang parehong locale sa susunod na round para hindi makatakas ang isang provider sa patakaran ng magkakasunod na round dahil lang lumipat na ang rotation.
Dinisenyo Namin Itong Huwag Pagkatiwalaan ang Sarili Nitong mga Konklusyon
Kapaki-pakinabang ang awtomatikong pagtanggal ng inference capacity, pero puwedeng magdulot ang isang false positive ng mas malaking outage kaysa sa depektong dapat sana nitong lutasin. Kaya may ilang preno ang canary:
- Hindi binibilang na pagkabigo sa kalidad ang mga transport error. Pinapahinto ng mga timeout, rate limit, at 5xx na sagot ang score sa halip na isulong ang sunod-sunod na papunta sa suspension.
- Hindi sapat ang isang masamang round. Kailangang bumagsak ang isang provider sa dalawang magkasunod na round na tuwing kalahating oras.
- Magkahiwalay ang pagmamasid at pagpapatupad. Puwede naming patakbuhin ang buong sistema sa observe mode, itala kung aling mga host ang masu-suspend sana, abisuhan ang mga administrator, at sukatin ang mga false positive bago i-enable ang awtomatikong aksyon.
- May pinakamababang antas ang capacity. Hindi magsu-suspend ng provider ang canary kung mag-iiwan ito ng mas kaunti sa dalawang production host. Sa halip, mag-a-alerto ito sa isang administrator.
- Tine-test ang pagbangon. Nananatiling puwedeng i-probe ang mga naka-suspend na provider. Ibinabalik nang maaga ang isang host pagkatapos ng dalawang magkasunod na malinis na round.
- Unti-unting tumitindi ang paulit-ulit na pagkabigo. Isang araw ang suspension para sa unang insidente, tatlong araw para sa sumunod, at pitong araw pagkatapos noon. Pagkalipas ng labing-apat na malinis na araw, nabubura ang kasaysayan ng paglabag at nare-reset ang hagdan.
Hindi layunin ang parusahan ang mga provider. Layunin nitong ilayo ang traffic ng user sa isang rutang paulit-ulit na napapatunayang hindi malusog, habang nag-iiwan ng malinaw na daan pabalik kapag naayos na ang problema.
Tatlong Patong ng Proteksyon
Pinagsasama ng huling desisyon sa routing ang tatlong uri ng exclusion:
- Mga na-review na built-in na exclusion para sa mga depekto o hindi pagtutugma ng patakaran na nasukat na namin at ayaw naming aksidenteng maibalik.
- Mga runtime na exclusion para sa insidente na agad na maidaragdag ng isang administrator, nang hindi naghihintay ng deployment.
- Mga may-takdang-oras na suspension ng canary para sa mga provider na lumampas sa awtomatikong threshold ng pagkabigo.
Pinagsasama ang mga listahang ito sa preference na provider.ignore ng OpenRouter kapag binubuo ng Reverie ang isang request. Hindi na kailangang mag-retry ng user hanggang sa tsamba nitong mapili ang mas mahusay na provider; inaalis na sa pagpipilian ang hindi malusog na ruta.
Itinatala ang bawat awtomatikong desisyon, inaabisuhan ang mga administrator sa mahahalagang pagbabago ng estado, at puwedeng manu-manong alisin ang isang suspension kapag kinakailangan.
Ano ang Ginagarantiya—at Hindi Ginagarantiya—ng Sistemang Ito
Sinadyang makitid ang canary. Kaya nitong hatulan gamit ang code ang latency, ang bisa ng schema, ang pag-filter na mataas ang kumpiyansa, ang integridad ng wika, at ang kalusugan ng encoding. Hindi ito nagkukunwaring kayang sukatin kung sapat ang pagiging nakakatawa ng isang karakter, sapat ang emosyonal na pakiramdam nito, o tapat ito sa isang komplikadong personalidad.
Kailangan pa rin ng mas malalawak na tanong na iyon ng mga evaluation na binuo mula sa mga representatibong prompt, review ng tao, production telemetry, at—higit sa lahat—mga ulat ng user.
Hindi rin ibig sabihin ng sistemang ito na patunay ng pagbaba ng kalidad ng model ang bawat kakaibang sagot. Probabilistic ang mga generative model. Puwedeng mag-ipon ng magkakasalungat na konteksto ang isang mahabang usapan. Puwedeng maglaman ng nagkokompetensyang instruction ang isang character definition. Minsan, ang kakaibang sagot ay kakaibang sagot lang talaga.
Ang nagbago ay hindi na katapusan ng imbestigasyon namin ang “parehong model.” Kaya na naming ihiwalay ang serving route, ulitin ang mga obhetibong pagkabigo, at ilayo rito ang apektadong traffic.
Ang Pagiging Maaasahan ay Pagpapanatili ng Karanasan
Mahalaga pa rin ang multi-provider routing. Binibigyan nito ang Reverie ng capacity at resilience para manatiling available ang mga usapan kapag bumabagsak ang mga indibidwal na endpoint.
Pero hindi lang basta pagtanggap ng HTTP response ang resilience. Ang isang reply na huli nang dumating, nawalan ng kinakailangang istruktura, tumanggi sa sinusuportahang content, o biglang nagpalit ng wika ay hindi malusog na resulta dahil lang sinasabi ng invoice na matagumpay ang request.
Para sa isang produkto ng AI na karakter, mas makatao ang kahulugan ng pagiging maaasahan: dapat pa ring maramdaman na siya pa rin ang karakter, alinmang makina man ang nagsasalita para sa kanya.
Iyan ang pamantayang pinoprotektahan ng mga bago naming routing safeguard.
Kung mapansin mo ang biglang pagbabago sa kalidad o wika ng mga sagot, magpadala sa amin ng ulat na may pangalan ng model at tinatayang oras. Tinutulungan kami ng mga ulat na iyon na iugnay ang karanasang nakita mo sa eksaktong rutang nag-serve nito.