Jeden z najczęstszych argumentów przeciwko automatyzacji przez AI brzmi tak: nie można ufać modelowi, bo kłamie że wykonał instrukcję, realnie nic nie robiąc. Albo: ignoruje plik z instrukcjami i wesoło halucynuje.
Oba argumenty są słuszne. I żaden z nich nie jest argumentem przeciwko automatyzacji — są argumentem przeciwko naiwnej automatyzacji, gdzie LLM ma wolną rękę bez żadnej warstwy weryfikacji.
Konkretne klasy błędów — co naprawdę się dzieje
Model twierdzi że wykonał operację — ale nie wykonał
To nie jest złośliwość. To jest mechanika modelu językowego: LLM generuje tekst który jest najbardziej prawdopodobną odpowiedzią na prompt w danym kontekście. Jeśli prompt brzmi „stwórz kampanię X”, model wygeneruje tekst potwierdzający że kampania powstała — bo to statystycznie właściwa odpowiedź na takie zlecenie.
Problem pojawia się gdy między „powiem że zrobiłem” a „sprawdzę czy zrobiłem” nie ma żadnego mechanizmu. W czystej integracji LLM + API taki mechanizm domyślnie nie istnieje.
Model ignoruje plik z instrukcjami
Każdy kto pracuje z LLM w produkcji zna ten problem: model dostaje system prompt ze szczegółowymi instrukcjami, a potem — przy wystarczająco długim kontekście lub specyficznie sformułowanym zapytaniu — zachowuje się jakby instrukcji nie było.
To nie jest bug do naprawienia. To właściwość architektury transformerów. Uwaga modelu rozkłada się nierównomiernie po całym oknie kontekstu. Instrukcja napisana 50 000 tokenów wcześniej ma mniejszy wpływ niż ta napisana trzy linie wyżej.
Model halucynuje parametry
„Użyj domyślnego UTM” — model wpisuje utm_source=facebook zamiast utm_source=meta. „Skopiuj targeting z adsetu X” — model wymyśla targeting bo nie sprawdził faktycznego. Drobne halucynacje, których nie widać w odpowiedzi modelu, ale które kumulują się w realnych błędach na koncie reklamowym.
Dlaczego to nie jest argument przeciwko automatyzacji
Żaden z tych problemów nie jest specyficzny dla AI. To wersje błędów które popełniają też ludzie:
- Junior w agencji potwierdza że kampania jest ustawiona — i nie sprawdza statusu
- Copywriter ignoruje brief i pisze po swojemu
- Mediaplanner przepisuje targeting z pamięci zamiast z systemu
Rozwiązaniem w tradycyjnych procesach jest review i weryfikacja — nie eliminacja człowieka z procesu. To samo dotyczy LLM.
Jak to rozwiązaliśmy w OWLI
Zewnętrzna weryfikacja zamiast zaufania do modelu
Po każdej operacji tworzącej lub modyfikującej reklamę, OWLI automatycznie pobiera obiekt z Meta Graph API i weryfikuje jego stan faktyczny. Nie pyta modelu „czy reklama powstała?” — sprawdza w źródle prawdy.
Weryfikacja obejmuje: czy formaty grafik są poprawne, czy pixel jest w tracking_specs, czy UTM jest w url_tags, czy Advantage+ jest wyłączone, czy placement routing działa. Jeśli cokolwiek się nie zgadza — system raportuje konkretny issue.
Model nie może „udawać” że reklama powstała. Wynik pochodzi z API, nie z generowanego tekstu.
Krytyczna logika w kodzie, nie w prompcie
Status domyślny PAUSED, limit budżetowy, blokada usuwania kampanii, wyłączenie Advantage+ — to wszystko jest w kodzie TypeScript, nie w instrukcjach dla modelu. Prompt można przegadać źle sformułowanym zapytaniem. Kod nie.
Guardrail blokujący DELETE na kampaniach jest hardcoded w warstwie HTTP — działa niezależnie od tego co model postanowi, nawet jeśli całkowicie zignoruje system prompt.
Auto-discovery eliminuje halucynacje parametrów
Zamiast kazać modelowi „pamiętać” lub „zgadywać” UTM, pixel ID, lead form ID, page ID — system automatycznie wyciąga te wartości z istniejących reklam w adsecie przed każdą operacją. Model nie ma możliwości wpisania złego UTM, bo UTM pochodzi z API, nie z generowanego tekstu.
Człowiek w pętli przed każdą mutacją
Każda operacja zmieniająca stan konta wymaga jawnego potwierdzenia operatora. System pokazuje dokładnie co zamierza zrobić — klient, konto, parametry, budżet w złotówkach — zanim cokolwiek wyśle do API.
To jest ostatnia bariera przed błędem planistycznym modelu: sytuacją gdy model dobrze wykonał instrukcję, ale instrukcja była błędna. Żaden mechanizm kodu tego nie złapie. Człowiek złapie.
Jeden punkt wejścia dla wszystkich mutacji
Wszystkie operacje tworzące lub modyfikujące reklamy przechodzą przez jedną funkcję w kodzie. Model nie ma możliwości wywołania API z pominięciem tej funkcji — nawet jeśli zignoruje instrukcje z pliku. Funkcja gwarantuje kompletność: poprawny status, pixel, wyłączenie Advantage+, logowanie operacji.
Co nadal może pójść nie tak — uczciwa odpowiedź
Powyższe mechanizmy eliminują klasę błędów związanych z wykonaniem. Nie eliminują błędów związanych z rozumieniem intencji.
Jeśli operator napisze „stwórz kampanię sprzedażową” a model zinterpretuje to jako leadgenową — żaden guardrail tego nie zatrzyma. Dlatego istnieje podsumowanie przed akcją: operator widzi dokładnie co model zamierza zrobić i potwierdza lub koryguje.
Jeśli model zignoruje konwencję nazewniczą z instrukcji — system to wykona. Dlatego pełna nazwa jest zawsze widoczna w podglądzie przed potwierdzeniem.
Reguła jest prosta: im wyżej w hierarchii decyzyjnej, tym więcej odpowiedzialności po stronie człowieka. Szczegóły wykonania (format pliku, pixel ID, status reklamy) delegujemy do kodu. Intencję i strategię weryfikuje operator.
Wniosek
LLM kłamie, ignoruje instrukcje i halucynuje parametry. To fakty. Pytanie nie brzmi „czy model popełnia błędy” — popełnia. Pytanie brzmi: czy architektura systemu pozwala tym błędom dotrzeć do produkcji?
W OWLI odpowiedź brzmi: większość klas błędów nie dociera. Zewnętrzna weryfikacja łapie błędy wykonania. Guardrails blokują błędy destrukcyjne. Auto-discovery eliminuje halucynacje parametrów. Człowiek w pętli łapie błędy planistyczne.
Jest różnica między systemem który ufa modelowi na słowo, a systemem który traktuje model jak sprytnego junior pracownika — z autonomią w ramach zatwierdzonych granic i obowiązkowym przeglądem przed każdą istotną zmianą.
