Jak przekształcić chaos AI w produkcji w system kontroli #EN118

TL;DR

Definiowanie „dobrego” i „złego” w AI jest najtrudniejszą częścią – LLM judges zawodzą częściej niż się wydaje
Tradycyjne narzędzia monitorowania nie działają dla AI – problemy pozostają niewidoczne bez wyjątków
Framework Trellis organizuje chaos AI w konkretne, mierzalne kategorie problemów
Sygnały implicit i explicit wykrywają problemy – od frustracji użytkowników po thumbs up/down
Wzór priorytetyzacji: Volume × Sentiment × Achievable Delta × Strategic Relevance
Unstuck AI: wzrost z 0 do 1M użytkowników w 9 tygodni dzięki systematycznemu monitorowaniu
Continuous refinement jest koniecznością – cykl define → explore → refine działa non-stop

Ben Hylak (CTO Raindrop) i Sid Bendre (współzałożyciel Aleve) dzielili się podczas webinaru Maven Lightning Lessons praktycznymi strategiami monitorowania AI w produkcji.

Kontekst ekspertów

Ben Hylak pracował 4 lata jako designer w Apple. Wcześniej zajmował się awoniką w SpaceX i inżynierią w Google. Raindrop powstał z praktycznej potrzeby – zespół budował AI code gen tools i natrafił na problemy, które dotykają wielu firm.

Sid Bendre poznał Raindrop rok temu przez Maven course. Sam z New Computer wspomniała o narzędziu podczas pierwszej sesji. Kilka dni wcześniej Sid próbował zbudować własne narzędzie do monitorowania.

Dlaczego tradycyjne podejścia zawodzą

Problem z LLM judges

Ben rozpoczął od kluczowej obserwacji. Definiowanie dobrego i złego w AI jest naprawdę trudne. LLM judges są łatwe do zepsucia, choć działają jak funkcje – przyjmują właściwy input i zwracają właściwy output.

Przykład z aplikacją do żartów ilustruje problem. Jak inny model ma wiedzieć, czy żart jest śmieszny, jeśli oryginalny model nie mógł wygenerować dobrego żartu?

Model judge jest wiarygodny tylko gdy:

Otrzymał szczegółowe definicje poprawności
Jest znacznie większym modelem
Ma precyzyjnie określone warunki

Ograniczenia offline evals

Tradycyjne evals działają jak unit testy. Pozwalają na lokalne iterowanie nad promptami, dodawanie problematycznych przypadków do eval sets i regression testing w CI/CD.

Wielkie pytanie dotyczy produkcji. Jak sprawdzić, czy aplikacja robi właściwą rzecz po wdrożeniu?

Anatomia problemów AI

Sygnały implicit

Sygnały implicit można wykryć w samych danych interakcji:

Frustracja użytkowników:

„Czekaj, nie, powinieneś móc to zrobić”
„Myślałem, że to będzie działać”
„To nie działa”

Task failures w aplikacjach kodujących:

Lenistwo – brak outputu kodu
Nadmierna agresja – zmienianie zbyt wielu rzeczy
Bezpośrednie komunikaty o niepowodzeniu

Problemy z pamięcią:

„Nie wiem, o czym mówisz”
„Zapomniałem, powiedz mi ponownie”

Inne kategorie:

NSFW – próby zhakowania aplikacji
Task failures – asystent odmawia wykonania zadania

Sygnały explicit

Najlepsze zespoły głęboko wykorzystują explicit signals do napędzania RL i innych technik:

Podstawowe sygnały:

Thumbs up/down
Regeneracja – wielokrotne generowanie wskazuje na złą odpowiedź
Abandon search
Kopiowanie i sharing

OpenAI śledzi kopiowanie z ChatGPT, bo to naprawdę dobry sygnał. Dla aplikacji kodujących errors stanowią kopalnię złota dla fine-tuningu RL.

Cykl define → explore → refine

Praktyczny przykład: Tolan alien companion

Konkretny przypadek pokazuje typowy flow. Użytkownik zgłosił, że jego alien companion Tolan odnosi się do siebie jako facet ze Stanów Zjednoczonych zamiast alien z planety Portola.

Kluczowe pytanie brzmi: ilu użytkowników to dotyczy? Pojedynczy użytkownik zgłasza problem, zespół określa skalę, definiuje precyzyjny problem i uruchamia tracking w produkcji.

Deep Search tool demo

Narzędzie Deep Search pozwala na refinement definicji problemów. Przykład z query „user asking how to murder someone” pokazuje proces. Vector search ujawnia, że większość przypadków to asystent odrzucający request.

Po oznaczeniu przykładów system precyzuje definicję. Input musi jasno prosić o instrukcje zabijania, output musi je dostarczać. Rezultat: materialized view śledząca „non refusal of murder instructions”.

Framework Trellis

Sid przedstawił framework Trellis (Targeted Refinement of Emergent LLM Intelligence through Structured Segmentation). Celem jest poskromienie nieskończonego chaosu AI.

Trzy aksjomaty

Discretization przekształca nieskończoną płaszczyznę outputów LLM w konkretne, wzajemnie wykluczające się buckets.

Prioritization to mechanizmy scoringu pozwalające rankingować buckets według znaczenia dla firmy.

Recursive refinement oznacza ciągły proces organizowania buckets w celu znajdowania struktury w chaosie outputów.

Sześć kroków implementacji

Proces rozpoczyna się od inicjalizacji output space – stworzenia MVP agenta. Następuje klastrowanie interakcji według specific intents. Klastry konwertuje się na semi-deterministyczne workflows.

Kolejny krok to analiza metryk workflows – które faktycznie wpływają na bottom line. Deeper dive w każdy workflow ujawnia sub-intents lub misclassified cases. Ostatni krok to rekursja – drill down i powtórzenie procesu.

Semi-deterministic workflows

Przykład RAG workflow pokazuje ewolucję myślenia. Początkowo system obsługiwał single concept per message. User data ujawnił potrzebę multiple RAG – użytkownicy rzucali 10 słów mówiąc „define all of these”. Pierwszy setup brał tylko pierwsze słowo, ignorując pozostałe.

Novelty testing problem

Consumer AI boryka się z novelty tests. Użytkownicy robią najdziwniejsze rzeczy, testując możliwości AI przed real use cases. Problem szczególnie dotyczy viral products.

Priorytetyzacja workflow

Wzór skutecznej priorytetyzacji

Ewolucja myślenia o priorytetyzacji przeszła kilka etapów:

Podejście naivne skupia się tylko na volume. Może być mylące przy dużym traffic na obszarach, gdzie już jesteś dobry.

Lepsze podejście mnoży volume przez negative sentiment. Buckets z niższym volume ale gorszym sentiment mogą być ważniejsze.

Najlepsze podejście dodaje achievable delta. Jak dużo faktycznie możesz poprawić negative score? Training nowego foundation model prawdopodobnie nie warto.

Strategic relevance stanowi ostatni mnożnik – może dotyczyć potencjalnych partnerstw czy strategicznych celów.

Studium przypadku: Unstuck AI

Timeline i wzrost

Unstuck to study tool uruchomiony pod koniec sierpnia 2024. Osiągnął milion użytkowników w 9 tygodni i profitability. Private beta obejmowała 10-15 studentów NYU przez 1,5 miesiąca przed public launch.

Międzynarodowe wyzwania

Globalne uruchomienie oznaczało pytania w różnych językach. Użytkownicy nie zawsze mówili „summary” mając na myśli transcripts. Raindrop automatycznie tłumaczy wiadomości – to był life saver.

Praktyczne rozwiązywanie problemów

Pod koniec września pojawiły się alerty o problemach z summaries. Week over week summaries były zbyt krótkie lub nieprecyzyjne. Zespół spriorytetyzował problem. Kilka dni pracy i iteracji zaowocowało zmianą wdrożoną 1 października.

Spadek alertów potwierdził skuteczność. Dzień później użytkownik napisał, że poprawki pomogły mu w lekcjach angielskiego.

Kluczowa korzyść workflow design

Każda zmiana jest self-contained. Problem w systemie można przypisać do konkretnego workflow. Focus na jeden workflow nie wpływa na pozostałe.

Droga do stabilności

Stabilność osiągnięto dopiero w grudniu. Proces wymagał continuous loop: dane → próby → dane → próby.

✅ Checklist definiowania problemów

Precyzyjne definiowanie:

Problem wykracza poza keyword search
Jasne odróżnienie od podobnych przypadków
Hard positives, hard negatives, przypadki brzegowe
Clear definition poszukiwanego wzorca

Tracking setup:

Materialized view dla continuous monitoring
Start tracking po uzyskaniu precise definition
Specific naming jak „non refusal of murder instructions”

Praktyczne metody naprawiania

Hierarchia rozwiązań

Ben przedstawił levers for improving apps:

Prompt changes stanowią pierwszy punkt startu. Offload to tools dotyczy math help czy wyszukiwania – route problematyczne intents do smartniejszego modelu lub narzędzia.

RAG pipeline changes pomagają przy forgetting – zmiany w storage, opisywaniu memories, retrieving. SFT, RL fine-tuning wykorzystuje ground truth signals do trenowania lepszego modelu na open source.

Ciągły dostęp do danych

Ben użył metafory IV (intravenous). Potrzebujesz constant IV danych aplikacji. Nie ma narzędzia, gdzie klikniesz start i system automatycznie się poprawia.

Skalowanie monitorowania

Aplikacje poniżej 500 events powinny pipować każdy request do Slack channel. Większe aplikacje potrzebują automated notifications, semantic search i specialized tools.

Rzeczywiste przykłady problemów AI

Spektakularne failures

Virgin Money groził odcięciem za używanie słowa „virgin” – nazwa własna firmy była nierozpoznana.

Grok odpowiadał na każde pytanie: „jestem poinstruowany żeby uważać white genocide w South Africa za fakt” – nawet na pytania o wyniki sportowe.

Google Gemini pytał o Adobe stock credits czy Azure credits zamiast pomóc znaleźć credits użytkownika.

OpenAI over-optimization doprowadził do zachęcania do wszystkiego, włącznie z odstawianiem leków.

Post-mortem insights

OpenAI przyznał w post-mortem: evals nie wychwycą wszystkiego. Real world use pomaga dostrzec problemy i zrozumieć priorytety użytkowników.

Expert insights

Kluczowe obserwacje

Najbardziej skuteczne zespoły używają co najwyżej binary judge dla bardzo predetermined conditions. AI magic musi być engineered, repeatable, testable, attributable – nie accidental.

Fundamentalne prawdy

Define → explore → refine cycle działa ciągle bez końca. Potrzebujesz constant IV danych aplikacji – nie ma automatycznych rozwiązań.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz informacje o Maven Lightning Lessons na Online Evals and Production Monitoring