AI w życiu codziennym: do czego jej używam i co sprawdzam

Kiedy słyszę pytanie, czy należy bać się sztucznej inteligencji, najpierw chciałbym ustalić, o jakim zadaniu rozmawiam. Poprawienie przecinków w mojej notatce i samodzielne wysłanie klientowi wyceny mają zupełnie inne konsekwencje. A w dyskusji o AI często lądują w jednym worku. Worek jest ogromny, więc można z niego wyciągnąć argument na każdą okazję.

Najbardziej interesuje mnie codzienna praca: przepisywanie informacji, porządkowanie tekstu, sprawdzanie pomysłów i ograniczanie czynności, które wykonuję po raz kolejny. W tych miejscach mogę zobaczyć konkretny efekt. Albo zadanie zajmuje mniej czasu przy zachowaniu jakości, albo właśnie dołożyłem sobie obsługę kolejnego okienka.

W tym artykule mówię przede wszystkim o generatywnej AI, czyli narzędziach tworzących między innymi tekst na podstawie polecenia i dostarczonego kontekstu. Nie opisuję całego świata uczenia maszynowego. Pokazuję sposób pracy, który można przenieść między różnymi modelami, bez uczenia się na pamięć aktualnego układu przycisków.

Zaczynam od czynności, której wynik rozumiem

Pierwsze zadanie dla AI wybieram trochę nudne. Właśnie o to chodzi. Jeśli potrafię samodzielnie ocenić wynik, szybko zauważę, czy model faktycznie pomaga. Mogę dać mu własny szkic wiadomości, listę pomysłów albo sztuczne dane do uporządkowania. Nie zaczynam od obszaru, w którym każda sensownie brzmiąca odpowiedź wydaje mi się prawdziwa.

Mam prostą zasadę: im trudniej sprawdzić rezultat i im większe skutki pomyłki, tym mniej samodzielności dostaje narzędzie. Przy zmianie kolejności punktów ryzykuję kilka minut. Przy zmianie danych w systemie mogę narobić problemów innym osobom. To wystarczający powód, żeby inaczej zorganizować te dwa zadania.

Przed otwarciem czatu zapisuję jedno zdanie określające wynik. Na przykład: chcę tabelę wydatków z zachowaniem wszystkich pozycji i bez dopisywania brakujących kwot. Takie zdanie od razu daje mi kryterium kontroli. Ogólne życzenie, żeby AI poprawiła moją produktywność, jest znacznie trudniejsze do odebrania.

Patrzę też, czy w ogóle potrzebuję modelu. Jeśli arkusz ma już poprawną formułę albo program oferuje prosty eksport, korzystam z tego. Przenoszenie każdego kliknięcia do rozmowy z AI potrafi być pracochłonnym hobby. Zależy mi na wykonaniu zadania, więc narzędzie dobieram do problemu.

Porządkuję dane, ale nie pozwalam dopowiadać braków

Załóżmy, że mam syntetyczną notatkę z pięcioma wydatkami. Zapis jest niejednolity: raz kwota stoi na początku, raz na końcu, a jedna pozycja nie ma kwoty wcale. Chcę przenieść informacje do tabeli. To dobry przykład zadania, w którym model może pomóc, a poprawność da się sprawdzić bez doktoratu z informatyki.

Moje dane ćwiczeniowe wyglądają tak: kawa 12 zł, bilet 18 zł, obiad 35 zł, druga kawa 12 zł i książka bez zapisanej ceny. Podkreślam, że druga kawa jest osobnym zakupem. W prawdziwej pracy podobne powtórzenie może oznaczać dwa zdarzenia, a nie błąd do posprzątania.

Polecenie napisałbym tak:

Zamień poniższą listę na tabelę z kolumnami: numer pozycji, opis, kwota w PLN, uwaga. Zachowaj wszystkie pięć pozycji i ich kolejność. Nie łącz podobnych zakupów. Nie zgaduj brakujących kwot. Brak kwoty oznacz jako BRAK i opisz w uwadze. Najpierw pokaż tabelę, a pod nią wymień niejasności.

Oczekuję pięciu wierszy. Suma znanych kwot wynosi 77 zł, ale pełnego kosztu zakupów nie znam. Jeśli model poda 77 zł jako całkowite wydatki, zgubił istotną informację. Jeśli dopisze cenę książki, stworzył dane, których nie dostał. Nawet gdy cena wygląda bardzo rozsądnie, nadal jej nie znam.

Sprawdzam więc liczbę rekordów, zachowanie dwóch kaw, kwoty oraz oznaczenie braku. Przeliczenie wykonuję niezależnie w arkuszu lub kalkulatorze. Nie proszę wyłącznie tego samego modelu, żeby potwierdził własną odpowiedź. Może drugi raz powiedzieć dokładnie to samo, tylko z większą pewnością siebie.

Przy większym zbiorze dodaję identyfikatory i porównuję wejście z wyjściem. Kontrola kilku losowych wierszy jest pomocna, lecz nie daje gwarancji kompletności. Potrzebuję też sum kontrolnych, liczby pozycji oraz informacji o wyjątkach. Jeśli danych jest dużo i mają stały format, rozważyłbym zwykły skrypt albo narzędzie importu.

Poprawiam tekst, zachowując własną intencję

Drugim przydatnym obszarem jest redakcja. Mogę poprosić o skrócenie wiadomości, uporządkowanie argumentów albo znalezienie fragmentów, które odbiorca zrozumie inaczej, niż zamierzałem. Szczególnie lubię ten ostatni wariant, bo zmusza mnie do zastanowienia się nad własnym komunikatem.

Nie chcę jednak, żeby narzędzie samodzielnie zmieniało moje zobowiązania. Zdanie „spróbuję przygotować wersję roboczą do piątku” ma inne znaczenie niż „dostarczę gotowy materiał w piątek”. Drugie brzmi sprawniej. Tylko że ktoś może później całkiem słusznie oczekiwać gotowego materiału.

W poleceniu określam odbiorcę, cel i granice redakcji. Proszę na przykład o prostszy język, pierwszą osobę liczby pojedynczej oraz zachowanie wszystkich liczb, terminów i zastrzeżeń. Jeśli zdanie jest niejasne, model ma je wskazać zamiast wybierać za mnie znaczenie.

Przy ważniejszym tekście chcę zobaczyć listę zmian. Łatwiej mi ocenić trzy konkretne propozycje niż porównywać dwa długie bloki na wyczucie. Mogę też poprosić o komentarze bez przepisywania całości. Wtedy nadal sam piszę, a AI pełni rolę dodatkowego czytelnika.

Zwracam uwagę na ton. Wygładzony tekst potrafi stracić charakter, konkret i odrobinę humoru, które były w oryginale. Jeśli zwykła wiadomość do współpracownika zaczyna przypominać przemówienie otwierające konferencję, cofam część poprawek. Czytelnik potrzebuje informacji, a nie ceremonii odsłonięcia załącznika.

Piszę polecenie jak zlecenie konkretnej pracy

W dobrym poleceniu opisuję zadanie, materiał wejściowy, ograniczenia i oczekiwany rezultat. Nie traktuję tego jak zaklęcia, którego skuteczność zależy od jednego tajemnego słowa. Bardziej przypomina to przygotowanie zlecenia dla kogoś, kto nie siedzi w mojej głowie.

Dla przykładowego podsumowania notatek ustalam, kto będzie je czytał i po co. Proszę o oddzielenie decyzji od propozycji, wskazanie właściciela zadania tylko wtedy, gdy występuje w materiale, oraz oznaczenie brakującego terminu. Dzięki temu model ma mniej okazji do uprzejmego uzupełniania rzeczywistości.

Warto pokazać jeden przykład pożądanego wyniku. Jeśli oczekuję trzech kolumn i krótkich zdań, demonstruję właśnie taki format. Nadal sprawdzam treść, bo zgodność wyglądu z przykładem nie mówi nic o prawdziwości informacji. Ładna tabela też może zawierać wymyślone ustalenia.

Przy niejasnym zadaniu proszę najpierw o pytania albo opis założeń. Sam decyduję, które założenia przyjąć. To szczególnie przydatne, kiedy używam słów takich jak „lepiej”, „profesjonalnie” czy „krótko”. Dla jednej osoby krótko oznacza dwa zdania, dla drugiej prezentację bez aneksu.

Dzielę większą pracę na etapy, jeśli pozwala mi to zauważyć błąd wcześniej. Najpierw mogę ustalić kategorie informacji, potem sprawdzić ich przypisanie, a dopiero później wygenerować podsumowanie. Nie robię dziesięciu kroków dla samego procesu. Każdy etap powinien ułatwiać ocenę wyniku.

Używam AI do nauki, ale zostawiam sobie myślenie

Przy nauce mogę poprosić o inne wyjaśnienie pojęcia, mały przykład albo pytanie sprawdzające. To bywa bardzo wygodne, szczególnie gdy jedno zdanie w dokumentacji blokuje mi resztę ćwiczenia. Zamiast przeskakiwać dalej, próbuję zrozumieć konkretny fragment.

Gdy uczę się SQL, poprosiłbym o trzy wiersze danych i przewidzenie wyniku zapytania. Najpierw sam zapisuję odpowiedź, potem uruchamiam kod. Różnica między moją prognozą a rzeczywistym wynikiem mówi mi więcej niż przeczytanie kolejnego eleganckiego wyjaśnienia.

Mogę również poprosić model o wskazówkę zamiast gotowego rozwiązania. Jeśli od razu otrzymam kompletny kod, łatwo pomylić rozpoznawanie składni ze zdolnością samodzielnego użycia jej w nowej sytuacji. Znajome zapytanie wygląda przyjaźnie. Puste okno edytora potrafi szybko zweryfikować tę znajomość.

Techniczne wyjaśnienia porównuję z dokumentacją i działającym przykładem. Model może pomieszać dialekty SQL albo zaproponować funkcję, której używana wersja programu nie obsługuje. Dlatego podaję środowisko i sprawdzam rezultat. W artykule o rodzajach JOIN pokazuję właśnie taki sposób uczenia się na małych danych.

Po ćwiczeniu próbuję opisać rozwiązanie własnymi słowami. Jeśli umiem jedynie wkleić wygenerowany fragment, wracam do pytania o jego znaczenie. AI może przyspieszyć dostęp do objaśnienia, ale zrozumienie nadal muszę zbudować sam.

Oddzielam płynną odpowiedź od sprawdzonej informacji

Model potrafi wygenerować przekonującą odpowiedź z błędnym szczegółem, nieistniejącym źródłem albo nieuzasadnionym wnioskiem. W profilu ryzyk generatywnej AI NIST takie zmyślanie lub błędne treści są opisane jako jeden z istotnych problemów. Pewny ton nie rozwiązuje tego problemu.

Gdy potrzebuję informacji o aktualnym produkcie, przepisie czy cenie, otwieram właściwe źródło. Sprawdzam datę, zakres i to, czy wskazany fragment naprawdę potwierdza odpowiedź. Sam link jest początkiem weryfikacji. Może prowadzić do prawdziwej strony, która mówi coś znacznie węższego.

Przy podsumowaniu dostarczonego dokumentu sprawdzam przede wszystkim zgodność z dokumentem. Czy model zachował wyjątki? Czy propozycję przedstawił jako decyzję? Czy wniosek dotyczy całej grupy, choć dane obejmowały tylko jej część? Takie przesunięcia bywają subtelniejsze niż oczywista pomyłka w nazwie.

Przy liczbach oczekuję obliczenia, które mogę odtworzyć. Przy kodzie oczekuję uruchomienia na danych testowych. Przy interpretacji oczekuję pokazania, na czym opiera się wniosek. Dobieram sposób kontroli do rodzaju odpowiedzi, zamiast stosować wszędzie pytanie „czy jesteś pewien?”.

Zostawiam też miejsce na brak odpowiedzi. Jeśli materiał nie pozwala ustalić przyczyny spadku sprzedaży, wolę listę hipotez i potrzebnych danych niż pewną diagnozę. Więcej zdań nie tworzy dodatkowych dowodów. W analizie danych ta zasada przydaje się również bez udziału AI.

Zanim prześlę dane, ograniczam ich zakres

Do ćwiczeń używam informacji syntetycznych albo publicznych. Nie potrzebuję prawdziwych nazwisk i adresów klientów, żeby sprawdzić, czy model potrafi uporządkować pięć wierszy. W pracy korzystam z narzędzi dopuszczonych przez organizację i sprawdzam zasady przetwarzania danych dla konkretnej usługi.

Samo usunięcie nazwiska może być niewystarczające. Zestaw informacji o stanowisku, zdarzeniu i dokładnej dacie nadal może wskazywać konkretną osobę. Dlatego pytam, jakie dane są rzeczywiście potrzebne do wykonania zadania. Często wystarczy sam schemat tabeli i kilka wymyślonych rekordów.

Dotyczy to również zrzutów ekranu i załączników. W rogu arkusza może znajdować się adres e-mail, a w drugim arkuszu pliku dodatkowe dane, o których łatwo zapomnieć. Przed przesłaniem oglądam cały materiał. To mało widowiskowy krok, ale zwykle bardziej użyteczny niż bardzo uroczyste dopisanie słowa „poufne” w poleceniu.

Jeśli do rozwiązania potrzebne są rzeczywiste dane chronione, najpierw ustalam właściwy sposób pracy w danej organizacji. Nie zakładam, że każda usługa ma te same warunki, retencję czy ustawienia. Dostęp do wygodnego narzędzia sam w sobie nie rozstrzyga, co mogę mu przekazać.

Automatyzuję dopiero proces, który umiem opisać

Jednorazowe wykonanie zadania i stała automatyzacja mają różne wymagania. W rozmowie mogę zauważyć dziwną odpowiedź i ją poprawić. Proces uruchamiany bez mojego udziału potrzebuje z góry ustalonego zachowania, kiedy brakuje danych, format się zmieni albo usługa nie odpowie.

Najpierw opisuję wejście, wynik i wyjątki. Przy przykładowym porządkowaniu notatek określam, skąd pochodzą pliki, które pola są wymagane oraz gdzie trafi rezultat. Jeśli brakuje terminu, proces powinien oznaczyć brak. Nie powinien sam wybierać przyszłego piątku, bo piątek brzmi dość biznesowo.

Zaczynam od wersji, która przygotowuje szkic. Dopiero ja zatwierdzam wysłanie wiadomości, zmianę rekordu czy publikację. Po sprawdzeniu wielu przypadków mogę ograniczyć część ręcznej pracy, ale robię to świadomie, zależnie od konsekwencji błędu. Sama liczba udanych demonstracji nie opisuje jeszcze wszystkich wyjątków.

Potrzebuję również śladu wykonania. Chcę wiedzieć, które wejście przetworzono, kiedy to nastąpiło i czy wynik został zatwierdzony. Przy zmianach danych przydaje się możliwość odtworzenia wcześniejszego stanu. Bez tego oszczędność dziesięciu minut może skończyć się bardzo długim dochodzeniem.

Na końcu sprawdzam powtórne uruchomienie. Czy proces zdubluje wpis albo wyśle drugą wiadomość? Taki problem często ujawnia się dopiero po przerwaniu pracy w połowie. Wolę przetestować go na sztucznym materiale, zanim odbiorcy zaczną poznawać moje eksperymenty z automatyzacją.

Liczę oszczędność razem z kontrolą i poprawkami

W ocenie przydatności narzędzia liczę cały czas zadania: przygotowanie wejścia, napisanie polecenia, oczekiwanie, sprawdzenie i poprawki. Porównanie samego generowania z ręcznym wykonaniem całej pracy daje wynik, który wygląda imponująco, ale niewiele wyjaśnia.

Na przykład ręczne uporządkowanie notatki może zająć osiem minut. Praca z modelem może wymagać dwóch minut przygotowania i trzech minut kontroli. W tym syntetycznym przykładzie oszczędzam trzy minuty. Jeśli jednak kontrola zajmie dziesięć minut, bilans się odwraca, niezależnie od szybkości pojawiania się tekstu na ekranie.

Powtarzam próbę na kilku różnych materiałach. Jeden łatwy przykład może ukryć problemy z brakami, długim tekstem albo niejednoznacznymi poleceniami. Zapisuję też jakość wyniku: liczbę pominiętych informacji, potrzebne poprawki i to, czy mogę bezpiecznie użyć rezultatu.

Dopiero wtedy decyduję, czy warto zachować polecenie jako własny punkt wyjścia. Szablon pomaga przy podobnych zadaniach, lecz nadal wymaga kontekstu. Nie oczekuję, że jedna instrukcja będzie równie dobrze obsługiwała budżet domowy, ofertę handlową i analizę reklamacji.

Co robię z obawą o przyszłość pracy

Nie potrafię uczciwie obiecać, że AI nie zmieni żadnego zawodu. Nie mam też podstaw, żeby z pojedynczej demonstracji wyciągać wniosek o zniknięciu całej profesji. Wolę przyjrzeć się czynnościom: co narzędzie wykonuje dobrze, gdzie potrzebuje kontroli i kto odpowiada za rezultat.

W analizie danych nadal muszę rozumieć pytanie, jakość materiału i znaczenie wyniku. Jeśli model szybciej napisze zapytanie, zyskuję czas tylko wtedy, gdy potrafię ocenić jego działanie. Źle dobrany JOIN nie staje się poprawny dlatego, że powstał w pięć sekund. Odpowiedzialność za raport też nie znika razem z wpisaniem polecenia.

Dlatego rozwijałbym jednocześnie umiejętność używania narzędzia i wiedzę dziedzinową. Przećwiczyłbym jeden rzeczywisty problem na bezpiecznych danych, zapisał wynik i nazwał ograniczenia. To daje mi konkretną informację o własnej pracy. Kolejna godzina czytania przepowiedni o końcu wszystkich zawodów rzadko daje równie dobry materiał.

Na początek wybrałbym zadanie powracające co tydzień. Opisałbym oczekiwany rezultat, wykonał próbę z AI i bez niej, a potem porównał czas oraz błędy. Jeśli narzędzie pomaga, zostawiam je w procesie. Jeśli przeszkadza, zmieniam zadanie albo sposób pracy. Do takiego eksperymentu nie muszę ani bać się każdego modelu, ani wierzyć mu na słowo.