Zadania edukacyjne z AI: dlaczego formularz pomaga bardziej niż pusty czat

Zamiast kolejnego promptu

Zadania-edu to moje narzędzie do przygotowywania materiałów edukacyjnych dla klas 1–3. Łączy gotową bazę zadań z możliwością generowania nowych przy pomocy AI i przygotowania pliku PDF. Nie chcę na tej podstawie przypisywać mu potwierdzonej skuteczności dydaktycznej. To narzędzie do tworzenia materiału, który nadal wymaga sprawdzenia.

Najciekawsze w tym projekcie nie jest dla mnie samo generowanie. Model potrafi zaproponować zadania, ale luźne polecenie zostawia mu bardzo dużo decyzji. Musi domyślić się poziomu, zakresu, długości i formy. Może odpowiedzieć poprawnie językowo, a mimo to przygotować coś nieodpowiedniego dla konkretnej sytuacji.

Dlatego użytkownik zaczyna od wyborów. Podaje parametry, które mają znaczenie dla wyniku. Nie musi znać nazwy techniki promptowania ani pamiętać, jak szczegółowo opisać prośbę. Formularz przypomina mu o rzeczach, które system powinien wiedzieć przed pracą.

Nie znaczy to, że formularz zawsze jest lepszy od rozmowy. Na początku, gdy sam jeszcze nie wiem, czego potrzebuję, czat daje przestrzeń do doprecyzowania pomysłu. Kiedy jednak zadanie ma już rozpoznawalny przebieg, stałe pola mogą bardzo ułatwić kolejne użycie.

Wybory użytkownika są częścią kontekstu

W zadaniach edukacyjnych słowo „łatwe” niewiele wyjaśnia. Dla jednej osoby oznacza prosty rachunek, dla innej krótkie polecenie, a dla jeszcze innej materiał, który dziecko już ćwiczyło. Model nie wie, które z tych znaczeń mam na myśli, jeżeli go w tym nie poprowadzę.

Podobnie jest z klasą i semestrem. Są przydatnymi wskazówkami, ale nie opisują wszystkiego. Konkretny temat i poziom trudności nadal mają znaczenie. Właśnie dlatego parametry powinny się uzupełniać, zamiast udawać, że jedno pole wystarczy do rozpoznania całej potrzeby.

Projekt pozwala wybrać między innymi przedmiot i kategorię, klasę, semestr, poziom trudności oraz liczbę zadań. Każdy wybór ogranicza część zgadywania. Użytkownik dostaje też możliwość zauważenia pomyłki jeszcze przed generowaniem, na przykład niewłaściwego zakresu materiału.

To dobry wzorzec także poza edukacją. Jeżeli przygotowuję status, mogę jawnie wybrać odbiorcę i okres. Jeżeli porównuję oferty, mogę podać kryteria. Nie dlatego, że model nie rozumie zdań, lecz dlatego, że stała struktura pomaga mi przekazywać właściwe informacje za każdym razem.

Gotowa baza też może być częścią rozwiązania

Nie wszystko musi powstawać od nowa. W zadania-edu jest miejsce zarówno na gotowe zadania, jak i na generowanie z pomocą AI. To istotne, bo łatwo nadać modelowi rolę domyślnego wykonawcy każdej czynności tylko dlatego, że znajduje się w projekcie.

Jeżeli istnieje materiał odpowiadający potrzebie, ponowne generowanie nie musi niczego poprawić. Może za to dodać nowy wynik do sprawdzenia. Gotowa baza daje inny rodzaj punktu startu. Generowanie ma sens wtedy, gdy potrzebny jest wariant, którego brakuje, albo inny zestaw parametrów.

Oczywiście sama obecność zadania w bazie nie jest certyfikatem jakości. Materiał też trzeba sprawdzić i umieć poprawić. Chodzi o świadomy wybór źródła, a nie o założenie, że zapisane treści są zawsze dobre, a wygenerowane zawsze ryzykowne.

Dla mnie to szersza lekcja o budowaniu narzędzi. AI może być jednym z elementów procesu. Obok niego mogą działać reguły, zapisane materiały i decyzje człowieka. Użyteczność całości nie zależy od tego, jaki procent pracy wykonuje model.

Generowanie i ocena to różne czynności

Naciśnięcie przycisku nie zamyka zadania. Wynik trzeba przeczytać. W przypadku materiałów edukacyjnych liczy się poprawność odpowiedzi, zrozumiałość polecenia i dopasowanie do zakresu. Każda z tych rzeczy może wymagać innego rodzaju kontroli.

Przykładowo, zadanie matematyczne może mieć poprawny wynik, ale niejasne polecenie. Może też być napisane prostym językiem i jednocześnie wymagać umiejętności spoza wybranego zakresu. To przykłady możliwych problemów, nie opis konkretnej pomyłki znalezionej w tej aplikacji.

Właśnie dlatego nie traktowałbym dobrze brzmiącego polecenia jako dowodu poprawności. Trzeba sprawdzić, czego zadanie rzeczywiście wymaga od dziecka. Jeśli wynik ma być użyty w nauce, ocena dorosłego powinna uwzględniać także konkretną sytuację ucznia.

Podobny podział stosuję przy materiałach zawodowych. Styl odpowiedzi, poprawność faktów i użyteczność dla odbiorcy to osobne rzeczy. Można poprawić język, nie naprawiając błędnego założenia. Najpierw trzeba wiedzieć, jaki problem w ogóle sprawdzamy.

PDF jest częścią zadania

Projekt obejmuje przygotowanie materiału do PDF. To może wyglądać jak drobny dodatek, dopóki nie spojrzy się na końcowe użycie. Jeśli ktoś chce pracować na wydrukowanej kartce, odpowiedź pozostawiona w oknie czatu nie jest jeszcze gotowym materiałem.

Trzeba pomyśleć o czytelności poleceń, układzie zadań i miejscu potrzebnym na rozwiązanie. Dokument powinien dać się otworzyć i wydrukować. Nawet poprawna treść traci część wartości, jeśli wymaga później ręcznego przenoszenia i poprawiania formatowania.

Nie przedstawiam samego eksportu jako gwarancji idealnego wydruku. Plik też wymaga obejrzenia. Szczególnie wtedy, gdy treść ma zmienną długość i może inaczej rozłożyć się na stronach. Wygenerowanie pliku i sprawdzenie jego wyglądu to dwa oddzielne kroki.

To samo dotyczy raportu dla przełożonego czy dokumentu dla klienta. Warto ustalić docelową formę przed rozpoczęciem pracy z AI. Odbiorca nie będzie oceniał tylko tego, czy model odpowiedział. Będzie próbował użyć wyniku w swoim zadaniu.

Nie każda pomyłka wymaga nowego modelu

Gdy wynik jest słaby, naturalnie pojawia się pokusa zmiany narzędzia. Czasem to właściwy kierunek, ale wcześniej sprawdziłbym kilka prostszych rzeczy. Czy parametry były jasne? Czy nie były ze sobą sprzeczne? Czy opisaliśmy, jak ma wyglądać poprawna odpowiedź?

Jeżeli problemem jest brak kontekstu, kolejny model również będzie musiał zgadywać. Może zrobić to inaczej, ale niekoniecznie lepiej. Dopiero po rozpoznaniu przyczyny da się ocenić, czy potrzebna jest zmiana instrukcji, formularza, danych czy samego modelu.

W narzędziu z interfejsem warto patrzeć także na wybory użytkownika. Pole może być formalnie poprawne, ale niezrozumiałe. Dwie opcje mogą brzmieć zbyt podobnie. Osoba korzystająca z aplikacji może więc podać inne parametry, niż zamierzała, nawet jeśli kod działa zgodnie z założeniami.

Dla mnie budowanie z AI polega również na wychwytywaniu takich sytuacji. Nie jestem programistą, ale mogę przejść zadanie i zobaczyć, gdzie sposób użycia przestaje być jasny. Tego nie zastąpi informacja, że aplikacja uruchomiła się bez błędu.

Co powinno się stać, gdy coś nie działa

Każde narzędzie potrzebuje zachowania na wypadek problemu. Generowanie może się nie udać, materiał może być niekompletny, a eksport może wymagać ponowienia. Użytkownik powinien rozumieć, co się wydarzyło i czy ma już wynik, którego może użyć.

W szczególności nie chciałbym, żeby komunikat sukcesu pojawiał się tylko dlatego, że zakończyło się oczekiwanie. Potrzebne jest potwierdzenie właściwego rezultatu. Jeżeli go nie ma, lepiej jasno powiedzieć o niepowodzeniu i zachować wybory użytkownika do kolejnej próby.

To opis kryterium, według którego oceniam użyteczność aplikacji. Nie deklaracja, że każdy możliwy błąd w zadania-edu został już przetestowany. Taką deklarację trzeba byłoby poprzeć konkretnym zakresem sprawdzeń i wynikami.

Ta ostrożność jest przydatna w każdym workflow AI. „Nie znaleziono”, „brak danych” i „nie udało się wykonać” znaczą co innego. Jeśli system miesza te stany, człowiek może podjąć decyzję na podstawie błędnego przekonania, że analiza została zakończona.

Formularz pomaga zachować samodzielność

Dobre narzędzie powinno prowadzić przez zadanie bez konieczności pamiętania wszystkiego, co wie jego autor. Dlatego wybory na wejściu, zrozumiałe komunikaty i możliwość obejrzenia wyniku mają tak duże znaczenie. Użytkownik potrzebuje orientacji w procesie.

Nie chodzi o odebranie swobody. Stałe pola mogą obsługiwać to, co powtarzalne, a dodatkowa instrukcja pozostawić miejsce na konkretną potrzebę. Ważne, żeby człowiek wiedział, które decyzje już podjął i co może jeszcze zmienić.

Przy własnym workflow można osiągnąć podobny efekt bez budowania aplikacji. Pomaga krótka karta wejściowa: odbiorca, materiał, cel, ograniczenia i oczekiwany wynik. Jeśli wracasz do niej przy kolejnym zadaniu, już ograniczasz przypadkowość pustego okna czatu.

Potem potrzebna jest karta sprawdzenia. Nie ogólne „oceń jakość”, tylko kilka pytań związanych z zastosowaniem. Czy liczby się zgadzają? Czy niczego nie dopisano? Czy wynik nadaje się do formy, w której będzie użyty? W zależności od pracy te pytania będą inne.

Co zabieram z tego projektu do pracy z AI

Zadania-edu przypomina mi, że wygoda użytkownika zaczyna się przed odpowiedzią modelu. Jeśli dobrze przygotuję wejście, łatwiej uzyskać wynik, który da się ocenić. Jeśli ustalę końcową formę, łatwiej rozpoznać, kiedy zadanie jest rzeczywiście skończone.

Najpierw wybrałbym więc jedną powtarzalną potrzebę. Następnie zapisałbym informacje, które trzeba dostarczyć, oraz rzeczy, które trzeba sprawdzić. Dopiero potem szukałbym najwygodniejszego sposobu obsługi: instrukcji, szablonu, formularza czy aplikacji.

Własny system nie musi być duży. Powinien być na tyle zrozumiały, żebyś umiał wrócić do niego po przerwie i przeprowadzić podobne zadanie. Jeśli potrafisz wyjaśnić, co dostaje AI, co robi i co sprawdzasz Ty, masz już konkretną podstawę do dalszej pracy.

Taką podstawę budujemy w AI po Twojemu na jednym realnym zadaniu zawodowym. Narzędzia, które tworzę na własne potrzeby, są dla mnie źródłem doświadczeń. Nie oznacza to, że każdy uczestnik programu potrzebuje własnej aplikacji. Potrzebuje sposobu pracy, który rozumie i potrafi samodzielnie powtórzyć.