Zespół Mendral opracował architekturę AI, która pozwoliła im obniżyć koszty przy jednoczesnym przejściu na bardziej zaawansowany model Claude Opus 4.6. Kluczem do sukcesu okazała się hierarchia agentów, gdzie tańsze modele wykonują większość pracy filtracyjnej. Szczegóły tej strategii opisano w artykule na blogu Mendral.
Firma zauważyła, że 80% awarii systemów CI to duplikaty już znanych problemów. Zamiast angażować drogi model do każdej analizy, wprowadzili system trzystopniowy, gdzie model Haiku najpierw weryfikuje, czy problem już występował.
Kluczowe wnioski
- Hierarchia kosztów: 80% awarii nigdy nie dociera do drogiego modelu Opus, co obniża koszty o połowę przy lepszej jakości analiz.
- Filtr duplikatów: Z 4000 przeanalizowanych awarii CI tylko 818 to nowe problemy — pozostałe 3187 to znane już błędy.
- Podział ról: Opus planuje i deleguje, podczas gdy tańsze modele Haiku wykonują konkretne zadania — bez prawa do tworzenia kolejnych pod-agentów.
- Kontekst na żądanie: Agenty nie otrzymują pełnych logów na start, lecz mają dostęp do SQL i pobierają tylko potrzebne dane z ClickHouse.
- Koszty proporcjonalne: Haiku obsługuje 65% tokenów wejściowych, ale stanowi tylko 36% wydatków na LLM.
System filtrowania duplikatów
Największe oszczędności pochodzą z inteligentnego filtrowania. Model Haiku w roli „triagera” otrzymuje bardzo specyficzne zadanie: sprawdzić, czy dany problem już występował. Ma dostęp do dwóch narzędzi wyszukiwania — dokładnego dopasowania dla znanych błędów oraz wyszukiwania semantycznego przez pgvector.
Wyszukiwanie semantyczne okazuje się szczególnie przydatne, gdy ten sam błąd manifestuje się różnymi komunikatami. Na przykład „operator does not exist bigint character varying” i „migration type mismatch on installation_id” to różne stringi, ale ta sama przyczyna źródłowa.
Koszt analizy przez Haiku jest 25 razy niższy niż pełne śledztwo Opusa. System preferuje fałszywie pozytywne wyniki (kosztują tylko pieniądze) nad fałszywie negatywne (możemy przeoczyć prawdziwy problem).
Architektura kontekstu na żądanie
Zamiast wypychania gigabajów logów do promptu, agenty otrzymują interfejs SQL do ClickHouse i pobierają tylko potrzebne dane. To nie tylko kwestia kosztów tokenów — gdy dajemy agentowi konkretny zestaw linii logów, już podejmujemy decyzję o tym, co jest istotne, zanim poznamy faktyczny problem.
System składa się z tabeli z surowymi danymi (github_logs) oraz zmaterializowanych widoków z pre-agregowanymi danymi: wskaźniki awarii według workflow, czasy zadań, liczniki wyników. Większość śledztw zaczyna się od zmaterializowanych widoków, by zawęzić przyczynę, a potem schodzi do surowych logów.
Przykład działania w praktyce
Niedawno trzy zadania CI Storybook zawiodły na tym samym commicie, wszystkie crashując na etapie pnpm install. Opus rozpoczął od zlecenia pod-agentowi pobrania komunikatów błędów z tego kroku. ClickHouse nie miał jeszcze logów, więc pod-agent użył GitHub CLI.
Wynik: gyp ERR! not found: make. Problem z kompilacją re2@1.23.0 — brakuje make na runnerze. Opus przeszukał istniejące insights (bez dopasowania), potem zapytał ClickHouse o trend awarii z 14 dni: 23 lutego 0,2%, 24 lutego 1,1%, 25 lutego 8,0% — wyraźny punkt przegięcia.
Drugi pod-agent zbadał zmiany między 24–25 lutego przez git log na plikach workflow i package.json. Okazało się, że podczas niezwiązanej migracji usunięto zależności buildowe. Trzeci pod-agent zweryfikował aktualny stan workflow. Opus nigdy sam nie czytał logów, historii git ani kodu.
Ponad jedna trzecia śledztw wymaga wielorundowego podejścia, a nowe problemy potrzebują około dwukrotnie głębszej analizy niż znane już błędy. System zachowuje czystość kontekstu orchestratora dzięki strukturalnym podsumowaniom zamiast surowych danych.
