Suosittelun laatu ei ole vain mallikysymys. Tiimi voi parantaa offline-metriikkaa ja silti epäonnistua tuotannossa, jos julkaisua ei voi selittää, mitata tai palauttaa.
Auditoitava julkaisu pitää neljä asiaa yhdessä:
- mitä käyttäjälle näytettiin
- mitkä config-, sääntö-, algoritmi- ja artefaktiversiot tuottivat vastauksen
- mitkä outcome-tapahtumat liittyivät exposureen
- mikä palautuskeino on käytettävissä, jos guardrail pettää
Siksi RecSys käsittelee exposure-lokituksen, arvioinnin, artefaktimanifestit ja operoinnin yhtenä kokonaisuutena.
Pienin hyödyllinen päätösjälki
Hyödyllinen julkaisutietue on tiivis. Siinä pitää näkyä request ID, tenant, surface, palautetut item ID:t, ranking-metadata, config-versio, rules-versio, artefakti- tai manifestiversio ja arviointiraportti, johon päätös perustui.
Ilman tätä tietuetta tiimi joutuu kokoamaan tuotantotilanteita osittaisista lokeista ja irrallisista muistikirjoista.
Palautus kuuluu suunnitelmaan
Palautus pitää määritellä ennen liikenteen siirtämistä. RecSysissä pääkeinot ovat:
- aiemman tenant-konfiguraation palautus
- aiempien sääntöjen palautus
- viimeksi toimineen artefaktimanifestin palautus
- service-version palautus, jos binääri muuttui
Oikea keino riippuu muutoksesta. Ranking-säännön ongelman ei pitäisi vaatia service-rollbackia, jos control plane voi palauttaa aiemmat säännöt turvallisesti.
Mitä tarkistaa ennen julkaisua
Älä julkaise yhden KPI-liikkeen perusteella. Tarkista skeemat, join-eheys, virheet, latenssi, tyhjien suositusten osuus, varoitukset ja palautuspolku. Jos dataan ei voi luottaa, oikea päätös on yleensä odottaa, ei julkaista.