Automatyzacje AI: kiedy warto, kiedy drogi teatr.

Kiedy warto dołożyć AI do pipeline'u

Trzy sygnały, po których rozpoznaję że AI-warstwa prawdopodobnie się opłaca:

• Input jest nieustrukturyzowany: maile klientów, PDF-y faktur, screenshoty z aplikacji, notatki ze spotkań. Wszystko, co ma format "ludzki", a na wyjściu potrzebujemy klasyfikacji albo ekstrakcji pól do bazy. Tu LLM wygrywa z regex'ami i tradycyjnym NLP, bo tolerancja na wariancje wejściową jest znacznie wyższa.
• Decyzja wymaga kontekstu zewnętrznego: "czy ten lead pasuje do naszego ICP", "czy ten ticket jest priorytetowy dla tego klienta", "czy ta faktura wymaga szczególnej akceptacji". Kiedy jasno-reguły kończą się po 15 minutach rozmowy, a człowiek doświadczony odpowiada trafnie w 10 sekund, jest miejsce dla LLM z RAG nad historią.
• Generowanie pierwszej wersji czegoś: draft odpowiedzi na maila, podsumowanie spotkania z nagrania, opis produktu z pliku technicznego. LLM jako "pierwsza wersja do przeglądu przez człowieka" daje często 60-85 procent gotowej pracy, reszta to szybka edycja.

W każdym z tych scenariuszy AI jest środkiem do celu, nie celem. Jeśli klient przychodzi z zapytaniem "chcę wdrożyć AI", pierwsze pytanie na warsztacie to: jaki proces ma być szybszy albo mniej błędny, i dlaczego klasyczne narzędzia tego nie rozwiązały.

Kiedy AI jest drogim teatrem

Kilka sytuacji, w których LLM pogarsza proces zamiast go usprawniać:

• Decyzje deterministyczne z jasnymi regułami: "jeśli kwota faktury powyżej 10 000 PLN, wyślij do akceptacji". Bieżące LLM potrafią wpadać w pułapkę interpretacji nieoczywistych przypadków (negatywne kwoty, waluty, korekty), a deterministyczny if-else w Pythonie daje 100 procent powtarzalności i jest tańszy w runtime.
• Procesy o zerowej tolerancji błędu: wyliczanie VAT-u, obliczanie premii, przypisywanie pacjentów do lekarza. Nawet 0.5 procent halucynacji LLM w rocznym wolumenie kilkudziesięciu tysięcy operacji daje kilkaset błędów rocznie. Jeśli proces jest regulowany prawnie, to nie do zaakceptowania.
• Workflow, gdzie opłaca się inwestować w sam proces zamiast automatyzować chaos: jeśli proces ma 15 różnych wariantów "bo tak klient chce", LLM nie rozwiąże tego problemu, tylko go przykryje. Przed AI warto spróbować zredukować wariancję procesu, potem ewentualnie dołożyć AI.

Wzorce, które działają w produkcji

Po dziesiątkach wdrożeń z różnym zakresem AI, trzy wzorce wracają najczęściej:

Klasyfikacja ze score'em konfidencji

LLM zwraca kategorię plus prawdopodobieństwo (np. "faktura_zakupowa: 0.92"). Jeśli konfidencja wyższa niż próg (typowo 0.85), automatyczne procesowanie. Jeśli niższa, ticket idzie do człowieka. Typowy split: 70-85 procent spraw leci automatycznie, reszta ręcznie. Mierzone: false positive rate (ile decyzji "pewnych" było błędnych) i false negative rate (ile spraw trafiło niepotrzebnie do człowieka).

Ekstrakcja strukturalna do schema

LLM dostaje schema JSON albo Pydantic model i tekst wejściowy, zwraca wypełniony schema. Kluczowe: validacja po ekstrakcji (Pydantic to lubi), retry z poprawką kiedy schema nie waliduje, fallback do OCR albo ręcznej introdukcji gdy retry nie pomaga. Sprawdzam też dryfy: model z miesiąca 6 radzi sobie z nową formą faktury lub nie.

RAG jako "pamięć semantyczna" agenta

Agent odpowiada na pytanie, najpierw zaglądając do bazy dokumentów klienta (embeddings w pgvector), wybiera 3-7 najbardziej relevantnych fragmentów, dokleja do promptu i generuje odpowiedź z cytatami. To daje odpowiedzialność (który dokument był źródłem) i kontrolę nad halucynacjami (nawet jeśli LLM zmyśli, cytat nie pasuje do źródła, co łatwo odróżnić).

Jak dobieram model do zadania

Nie ma jednego "najlepszego" modelu językowego, jest kombinacja "wystarczająco dobry na dane zadanie, za cenę która pasuje do ROI". Moje kryteria wyboru:

• Okno kontekstu: jeśli input to umowa handlowa 40 stron PDF, nie użyję modelu z oknem 8k tokenów. Długie okna mają dziś Gemini i duże modele Vertex AI (1M+ tokens), średnie ma większość mainstream LLM (128k-200k).
• Tryb JSON / structured output: jeśli potrzebuję wyjścia zgodnego ze schema, wybieram model z natywnym trybem JSON. Większość mainstream modeli to dziś wspiera, ale jakość compliance różni się znacznie między dostawcami.
• Latency przy synchronicznym workflow: jeśli workflow odpowiada klientowi na czacie live, latency per call powyżej 5 sekund jest nie do zaakceptowania. Dla takich scenariuszy wybieram mniejsze, szybkie modele (Haiku, mini), a dla tła zostaje większy model.
• Koszt na tysiąc executions: przy wysokich wolumenach różnica 2-10x między tanim a drogim modelem może zmienić projekt z opłacalnego na nieopłacalny. Kalkuluję zawsze full cost: input tokens plus output tokens plus ewentualny cache hit.
• Lokalizacja danych: dla workflow z PII wybieram model hostowany w EU (Vertex AI europe-west4 albo europe-west3). Dla non-sensitive OK są regiony US.

Budżetowanie AI w projekcie

Koszty AI dekomponują się na trzy główne warstwy:

• Tokens per execution: input plus output. Dla klasyfikacji maila typowo 500-1500 tokens input, 50-100 tokens output. Dla RAG z 5 dokumentami po 500 tokens plus 300 tokens pytania i 200 tokens odpowiedzi: 3000 tokens input, 200 tokens output per call.
• Volume miesięczny: liczba execution × tokens per execution × cena per milion tokens. Dla klasyfikacji maili (1000 dziennie × 30 dni × 1000 tokens × cena input) wychodzi zwykle 30-150 PLN miesięcznie, zależnie od modelu.
• Embeddings dla RAG: oddzielny budżet, zwykle tanio (embedding na milion tokens kosztuje ułamek kosztu generowania). Raz na dokument plus re-embedding przy zmianach.

Przy kalkulacji ROI dodaję jeszcze koszt infra (jeśli hostujesz RAG u siebie, Postgres z pgvector kosztuje), koszt monitoringu jakości (audit log wszystkich decyzji plus sample review co tydzień) oraz koszt re-kalibracji (raz na 3-6 miesięcy sprawdzam czy model ciągle radzi sobie z aktualnymi wejściami).

Guardrails, czyli jak nie strzelić sobie w stopę

Cztery warstwy ochronne, które dokładam do każdego produkcyjnego wdrożenia AI:

• Human-in-the-loop domyślnie, automat jako upgrade: pierwsze tygodnie produkcji LLM generuje draft, człowiek zatwierdza. Kiedy statystyki (accuracy, approval rate, edit rate) ustabilizują się powyżej progu, włączam auto-approval dla konfidencji > X, a człowiek dostaje tylko edge case'y.
• Audit log każdej decyzji: input, prompt, wyjście, konfidencja, model użyty, czas. Logi trzymam minimum 12 miesięcy. Dla procesów regulowanych 5-10 lat. Bez audit log nie wiesz co robić, gdy klient skarży się na błędną decyzję.
• Eskalacja automatyczna: konfidencja poniżej progu, sprzeczny kontekst, brak wystarczających dokumentów w RAG. Każdy taki sygnał kieruje ticket do człowieka zamiast halucynować odpowiedź.
• Test set z edge case'ami: zbieram problemy, które pojawiły się w produkcji (błędne klasyfikacje, halucynacje, dziwne odpowiedzi) w dedicated test set. Przy każdej zmianie promptu albo modelu odpalam test i sprawdzam, czy jakość nie spada.

Najczęstsze pytania

Co warto przeczytać obok