Jeśli backlog rośnie szybciej, niż ktokolwiek jest w stanie go przeczytać, znasz ten ból: nowe bugi i tickety lądują w jednym worku, ktoś ręcznie je czyta, nadaje priorytet, przypisuje do zespołu i sprawdza, czy to nie duplikat sprzed tygodnia. AI-triage zgłoszeń to sposób, żeby ten pierwszy, najbardziej żmudny etap oddać modelowi językowemu, a ludziom zostawić decyzje, które faktycznie wymagają człowieka. U klientów to jeden z najszybciej zwracających się scenariuszy AI, bo dotyka pracy wykonywanej codziennie.
Na czym polega problem: ręczna segregacja zgłoszeń
Zanim ktokolwiek zacznie naprawiać buga, ktoś musi go zrozumieć i skierować w dobre miejsce. Ten etap, triage, pochłania zaskakująco dużo czasu i ma trzy typowe wady:
- jest niespójny, dwie osoby ocenią ten sam problem inaczej, a priorytety zależą od nastroju i dnia tygodnia;
- jest wolny, zgłoszenie potrafi leżeć w kolejce godzinami, zanim ktoś w ogóle je otworzy;
- generuje szum, duplikaty i zgłoszenia „nie tam” rozpraszają zespół i zaniżają zaufanie do backlogu.
Ta praca nie wymaga seniorskiej wiedzy, wymaga cierpliwości i konsekwencji, a akurat z tym modele radzą sobie bardzo dobrze.
Jak AI-triage zgłoszeń klasyfikuje i priorytetyzuje
Triage oparty o LLM robi kilka rzeczy naraz, na podstawie samej treści zgłoszenia (opisu, kroków, logów, załączonych zrzutów):
- Klasyfikacja: czy to bug, feature request, pytanie do supportu, czy błąd konfiguracji po stronie użytkownika; jakiego modułu dotyczy.
- Priorytetyzacja: model ocenia dotkliwość na podstawie sygnałów w treści: „nie mogę się zalogować” waży więcej niż „literówka w stopce”. Warto dać mu jawne kryteria (wpływ na użytkownika, obejście, zasięg).
- Przypisanie: skierowanie do właściwego zespołu lub osoby po obszarze, którego dotyczy zgłoszenie.
- Wykrywanie duplikatów: tu najlepiej działa wyszukiwanie semantyczne (embeddingi): nowe zgłoszenie jest porównywane z istniejącymi po znaczeniu, nie po dokładnych słowach, więc „aplikacja się wywala przy zapisie” i „crash on save” trafią do siebie.
- Uzupełnianie braków: jeśli brakuje kroków reprodukcji czy wersji, model może od razu poprosić zgłaszającego o doprecyzowanie.
Ten sam mechanizm sprawdza się przy zgłoszeniach generowanych automatycznie z pipeline’u CI/CD: model potrafi wstępnie odróżnić realną regresję od niestabilnego (flaky) testu Selenium czy Playwright, zanim ktokolwiek otworzy raport. To ta sama rodzina zastosowań, o której piszę szerzej w tekście o LLM w testowaniu oprogramowania, z tą różnicą, że tutaj model pracuje na wejściu do procesu, a nie na samych testach.
Przykładowy przepływ triage’u krok po kroku
Tak może wyglądać przepływ zbudowany na tym, co firma już ma (np. Jira, GitHub Issues, system ticketów), spięty automatyzacją:
| Krok | Co się dzieje |
|---|---|
| 1. Wejście | Nowe zgłoszenie trafia do systemu (formularz, e-mail, webhook, alert z CI/CD). |
| 2. Normalizacja | Wyciągnięcie tytułu, opisu, logów, wersji; oczyszczenie danych. |
| 3. Duplikaty | Porównanie semantyczne z otwartymi zgłoszeniami, jeśli trafienie, link do istniejącego. |
| 4. Analiza LLM | Klasyfikacja, priorytet, sugerowany zespół, brakujące informacje, jako uporządkowany JSON. |
| 5. Zapis | Ustawienie etykiet, priorytetu i przypisania w systemie; komentarz z uzasadnieniem. |
| 6. Człowiek | Przy niskiej pewności lub wysokim priorytecie, ludzki przegląd przed dalszym ruchem. |
Warstwę wykonawczą (kroki 1, 2, 5) najwygodniej postawić w narzędziu do automatyzacji procesów w n8n, a LLM podpiąć jako jeden z węzłów przepływu. Dzięki temu całość jest edytowalna bez pisania aplikacji od zera.
Korzyści i ryzyka: gdzie kończy się AI, a zaczyna człowiek
Co realnie zyskujesz
- Czas: pierwsza segregacja dzieje się w sekundach od zgłoszenia, całą dobę, bez kolejki.
- Spójność: te same kryteria stosowane za każdym razem, niezależnie od tego, kto akurat dyżuruje.
- Czystszy backlog: mniej duplikatów i mniej „bugów”, które w rzeczywistości są pytaniami.
Ryzyka i human-in-the-loop
Nie oddawaj modelowi decyzji, których nie chciałbyś podjąć bez sprawdzenia. Zasady, które stosuję w praktyce:
- model proponuje, człowiek zatwierdza tam, gdzie stawka jest wysoka, krytyczne priorytety zawsze przechodzą przez ludzki przegląd;
- model zwraca poziom pewności; poniżej progu zgłoszenie idzie do kolejki „do sprawdzenia”, a nie automatycznie dalej;
- każda decyzja ma zapisane uzasadnienie, żeby dało się ją zweryfikować i poprawić prompt;
- uważaj na dane wrażliwe w zgłoszeniach, ustal, co i dokąd jest wysyłane, zanim ruszysz na produkcję.
Od czego zacząć wdrożenie
Nie zaczynaj od pełnej automatyzacji. Zacznij od małego, mierzalnego wycinka:
- Weź 50–100 historycznych zgłoszeń i ich ręczne rozstrzygnięcia to Twój zbiór odniesienia.
- Uruchom triage w trybie „cień”: model tylko sugeruje, nic nie zmienia. Porównaj jego decyzje z ludzkimi.
- Dopracuj kryteria priorytetów i etykiet, najwięcej zyskuje się na jasnych definicjach, nie na większym modelu.
- Włącz automatyczne działania stopniowo: najpierw etykiety i duplikaty, później priorytet i przypisanie.
- Zostaw furtkę dla człowieka i mierz efekt: czas do pierwszej reakcji i odsetek poprawnie skierowanych zgłoszeń.
To podejście „małymi krokami, na produkcji” opisuję szczegółowo we wpisie o wdrożeniu AI w firmie, od pomysłu do produkcji. Chodzi o to, żeby po pierwszym tygodniu mieć działający, mierzalny fragment, a nie kolejne demo bez wpływu na pracę zespołu.
Jak w tym pomagam
Nazywam się Paweł Szewczyk, od 20 lat pracuję w IT, od siedmiu jako inżynier jakości. Jako QA Sensei łączę testowanie, automatyzację procesów i wdrożenia AI szyte na miarę. Triage zgłoszeń to naturalne skrzyżowanie tych trzech światów: rozumiem, jak wygląda dobry bug report, jak spiąć go z Jirą czy systemem ticketów i jak podpiąć model tak, żeby był pomocny, a nie ryzykowny. Pomagam zaprojektować przepływ, dobrać kryteria priorytetów i wdrożyć rozwiązanie z rozsądnym human-in-the-loop, zdalnie w całej Polsce lub u klienta w okolicach Wrocławia. Zobacz, w czym jeszcze pomagam i jak wygląda moja współpraca krok po kroku.