Większość rozmów o AI kończy się na możliwościach: co potrafi model? Bardziej użyteczne pytanie dla każdego, kto prowadzi biznes, dotyczy dostępności: czy będzie robił to nadal o trzeciej nad ranem, w święto, pod obciążeniem, gdy jego dane wejściowe --- i stojący za nimi model --- po cichu się zmieniły?
Niezawodność to cecha systemu, nie modelu
Model jest jednym z wielu komponentów, a większość zagrożeń dla systemu nie leży w samym modelu. Dostawca wycofuje wersję albo z dnia na dzień zmienia jej zachowanie; rate limit dławi przepustowość w szczycie; nagły skok ruchu zamienia koszt tokenów w rachunek, którego nikt nie zatwierdził; indeks retrievalu ulega driftowi i odpowiedzi po cichu się pogarszają. Niezawodne działanie systemu wymaga timeoutów i retries, graceful degradation, gdy zależność jest wolna, rozsądnych fallbacków, gdy odpowiedź nie przejdzie walidacji, oraz twardych limitów, które nie pozwolą, by zły dzień stał się awarią lub niekontrolowanym rachunkiem. Nic z tego nie jest badaniem nad modelami, ale wszystko to jest inżynierią systemu AI --- i to właśnie czyni model użytecznym w produkcji.
Observability dla systemów, którym wolno się mylić
Tradycyjny monitoring zakłada wyraźną granicę między działaniem a awarią. Systemy AI działają w tej luce: każdy health check na zielono, opóźnienie normalne, współczynnik błędów zerowy --- a odpowiedzi po cichu gorsze niż tydzień temu. Model może być technicznie zdrowy i funkcjonalnie zepsuty jednocześnie. To wymaga innego rodzaju observability --- jakość wyników, groundedness, retrieval hit rate, koszt na żądanie i drift, a nie tylko uptime i współczynniki błędów --- tak, by powolne pogarszanie ujawniało się jako alert, a nie skarga klienta.
Pager jest częścią projektu
System projektuje się z myślą o jego najgorszym dniu: runbooki dla awarii, które da się przewidzieć, alerty, które powiadomią człowieka, zanim zauważą to klienci, możliwość wycofania modelu (rollback) lub przypięcia wersji tak łatwo jak deployment oraz jasna odpowiedzialność za to, kto reaguje na alert. Rozstrzyganie tego wszystkiego po starcie to sposób, w jaki obiecujący system staje się takim, którego nikt nie chce utrzymywać.
Eksploatacja systemu nie jest dodatkiem do inżynierii; jest inżynierią. Oto co znaczy tworzyć oprogramowanie, które przetrwa kontakt z rzeczywistością.