AI zrobiło analizę. Jak odebrać wynik przed publikacją raportu

Jeden agent pisze analizę, drugi ją sprawdza, a trzeci tłumaczy, dlaczego obaj mogą się mylić. W moim skeczu to nadal brainstorming. Żart dotyka jednak konkretnego problemu: łatwo dołożyć kolejną odpowiedź AI, trudniej powiedzieć, kto i na jakiej podstawie przyjął wynik.

Chcę rozwinąć właśnie moment odbioru. Raport może wyglądać przekonująco i zawierać kod, którego odbiorca nie rozumie. Zanim przekażę go dalej, potrzebuję sprawdzić sens liczb oraz granice wniosku. Sama liczba agentów pracujących nad zadaniem nie daje mi jeszcze odpowiedzi na te pytania.

Ustal, co właściwie odbierasz

W skeczu szef wpisuje zakres pracy całego działu i dodaje żądanie szybkiego, bezbłędnego wykonania. Takie polecenie utrudnia mi ocenę rezultatu. Jeśli nie ustaliliśmy pytania, trudno powiedzieć, czy odpowiedź rzeczywiście rozwiązuje problem. Mogę jedynie stwierdzić, że dostaliśmy dużo materiału.

Przed odbiorem wracam więc do celu. Jaką decyzję ma wspierać analiza? Jaki okres obejmuje? Co oznacza przychód, klient albo zamówienie? Które dane wolno wykorzystać? Jeśli tych ustaleń brakuje, proszę o ich doprecyzowanie. Bez tego kolejne poprawki mogą dotyczyć wyłącznie wyglądu raportu.

Oddzielam też plik roboczy od rekomendacji gotowej do przekazania. W pierwszym mogą być hipotezy i otwarte pytania. Przy drugim chcę umieć wskazać, co zostało rozstrzygnięte, a co nadal ogranicza decyzję. Słowo „gotowe” potrzebuje konkretnego znaczenia.

Oprzyj kontrolę na czymś poza odpowiedzią modelu

Mogę poprosić innego agenta o krytykę. Chcę jednak, żeby wskazał konkretne założenie, dokument lub rekord wymagający sprawdzenia. Ogólna odpowiedź, że wszystko wygląda dobrze, niewiele wnosi. Ponowne opisanie tej samej logiki innymi słowami również nie rozstrzyga, czy założenie było poprawne.

NIST w profilu generatywnej AI opisuje ryzyko przekonująco podanych błędnych treści oraz nadmiernego zaufania do automatyzacji. Z tego powodu w swoim sposobie odbioru szukam punktu odniesienia: uzgodnionej definicji, materiału źródłowego lub małej próbki, którą rozumiem.

Nie muszę znać na pamięć każdej biblioteki wykorzystanej przez AI. Muszę natomiast rozpoznać granicę własnej oceny. Jeśli nie rozumiem ważnego kroku, zawężam go, czytam dokumentację albo proszę właściwą osobę o sprawdzenie. Moja pewność siebie nie zastępuje brakującej wiedzy technicznej.

Zobacz, jak JOIN może pomnożyć przychód

W Shortsie pojawia się żart o wzroście, który pasuje do oczekiwań zarządu albo wynika ze złego połączenia tabel. Rozpiszmy mały, wymyślony przykład. Jeden klient ma dwa zamówienia: na 100 i 50 jednostek. W osobnej tabeli są trzy kontakty z tym klientem. Łączymy tabele wyłącznie po identyfikatorze klienta.

Każde zamówienie pasuje wtedy do trzech kontaktów. Otrzymujemy sześć wierszy, a kwoty 100 i 50 występują po trzy razy. Ich suma w wyniku wynosi 450, choć w zamówieniach było 150. To konsekwencja reguły opisanej w dokumentacji PostgreSQL 18: dla wiersza pierwszej tabeli powstaje wiersz wyniku przy każdym dopasowaniu w drugiej.

Przy odbiorze zapytałbym zatem, co reprezentuje wiersz przed połączeniem i po nim. Porównałbym liczbę zamówień i sumę ich kwot w obu miejscach. Sam wzrost liczby wierszy może być oczekiwany, ale wtedy trzeba pilnować znaczenia sumowanej kwoty. Więcej wariantów pokazuję w tekście o rodzajach JOIN-ów.

Nie naprawiałbym tego automatycznie usuwaniem powtórzeń. Kontakty mogą być poprawnymi, osobnymi zdarzeniami. Najpierw trzeba ustalić, czy w ogóle potrzebujemy ich w zestawieniu przychodu, a jeśli tak, w jaki sposób. Usunięcie powielonych wierszy bez rozumienia celu może stworzyć kolejny błąd.

Oddziel oczekiwany wynik od dowodu

W żarcie model zdąży przyznać rację, zanim rozmówca skończy zmieniać zdanie. Przy analizie chcę uniknąć podobnego układu. Jeśli z góry proszę o uzasadnienie, że kampania się udała, ograniczam przestrzeń na znalezienie czegoś niewygodnego. Wolę zapytać, co dane pozwalają powiedzieć o kampanii i czego nie rozstrzygają.

Sama poprawność sumy przychodu nie dowodzi jeszcze, że kampania spowodowała zmianę. Potrzebuję osobno rozważyć to pytanie. Poprosiłbym o wskazanie innych możliwych wyjaśnień i informacji, których brakuje, żeby je odróżnić. To propozycja sposobu pracy, a nie obietnica, że każdy dostępny zbiór pozwoli rozstrzygnąć przyczynę.

Ograniczenie powinno zostać przy wniosku, który przekazuję dalej. Jeśli istnieje tylko w długiej rozmowie z modelem, odbiorca raportu może nigdy go nie zobaczyć. Chcę, żeby osoba podejmująca decyzję wiedziała, gdzie kończy się to, co sprawdziłem.

W przykładowym zadaniu poprosiłbym również o oddzielenie obserwacji od interpretacji. „Przychód w tym okresie jest wyższy” i „warto zwiększyć wydatki na kampanię” wymagają innych uzasadnień. Przy drugim zdaniu zapytałbym jeszcze o koszty i cel decyzji. Nie chcę, żeby rekomendacja przeszła odbiór tylko dlatego, że stoi tuż obok poprawnie obliczonej liczby i korzysta z jej wiarygodności.

Przećwicz odbiór na jednym małym zadaniu

Proponuję zacząć od analizy, którą potrafisz prześledzić samodzielnie. Przed zleceniem zapisz pytanie i definicje. Po otrzymaniu wyniku wybierz jeden kluczowy krok oraz jedną liczbę do niezależnego sprawdzenia. Następnie spróbuj opowiedzieć komuś, skąd ta liczba się wzięła i jaki wniosek rzeczywiście wspiera.

Jeżeli utkniesz, zapisz dokładnie brakującą wiedzę i wróć do tego fragmentu. To lepszy punkt startu do nauki niż ogólne przekonanie, że trzeba poznać całe AI. Szerszą organizację zadań i kontekstu opisuję w artykule o AI i kompetencjach analityka. Tutaj kryterium końca jest proste: rozumiem rezultat na tyle, by uczciwie określić, co mogę przekazać dalej.