Evale przed startem mówią ci, że agent działa na twoim zbiorze testowym. Produkcja mówi ci, czy działa na rzeczywistości — a tylko ciągłe monitorowanie zamyka tę lukę. Deep-dive o obserwowaniu agentów na wolności: co logować, co mierzyć, jak łapać cichą degradację i jak awarie produkcyjne wracają do twoich evali.
Gdy Rails 8 wyszło, byłem entuzjastyczny wobec stosu „Solid” bez-Redisa i tezy frameworka jednej osoby. Teraz uruchamiałem go na produkcji przez sześć miesięcy. Oto uczciwa retrospektywa: gdzie dostarczył, gdzie były szorstkie krawędzie i czy uproszczenie wytrzymało pod prawdziwym obciążeniem.
Nieraz stawałem po stronie pgvectora jako sensownego wyboru domyślnego do wyszukiwania wektorowego. Po jakimś czasie utrzymywania go na produkcji zebrałem to, o czym wprowadzające poradniki milczą: wybór indeksu i jego kompromisy, dostrajanie relacji recall–szybkość, utrzymywanie embeddingów w zgodzie ze źródłem i pułapki operacyjne, które ujawniają się dopiero przy skali.
Postawienie agenta na produkcji jest trudniejsze niż pojedyncze wywołanie LLM, bo agent to pętla z pomnożoną powierzchnią awarii — i musisz zarazem ograniczyć go w czasie wykonania i mierzyć go w czasie. Deep-dive o dwóch dyscyplinach, które czynią agentów produkcyjnych godnymi zaufania: barierach ograniczających, co agent może zrobić, i evalach testujących całą trajektorię, nie pojedyncze wyjście.
Prototyp był magią. Potem wysłaliśmy go do prawdziwych użytkowników i wszystko, co demo ukryło, stało się wymagalne naraz — koszt, opóźnienie, nadużycie, padające API i unikalny problem wspierania funkcji, której wyjścia nie możesz w pełni przewidzieć. Opowieść z frontu o przepaści między demem LLM a produktem LLM.