Automatyzacja przez demonstrację
Czyli "pokaż" AI efekt końcowy
Twój gotowy dokument może być “wzorcem” dla AI
Jestem wielkim fanem generowania przez AI instrukcji dla samego siebie. “Inżynierię promptów” zostawmy badaczom i ludziom, którzy wyciskają z modeli językowych absolutne maksimum i mają czas/zasoby, żeby co kolejną wersję modelu poprawiać swoje instrukcje. W większości przypadków biznesowych, szybciej (bez nauki “promptowania”) i taniej (bez wydatków na utrzymanie wycyzelowanych instrukcji) jest użyć modelu językowego do wygenerowania instrukcji.
Można to zrobić na kilka sposobów, które omawiałem przy okazji wpisu o metakompetencji zadawania pytań. Dziś opiszę szczególny przypadek: kiedy macie wzorcowy dokument do zademonstrowania oczekiwanego wyniku.
Weźmy na przykład firmę rekrutacyjną, w której powtarza się zadanie: wziąć specyfikację stanowiska pracy od klienta (często szczątkową) i zamienić ją na profesjonalnie wyglądającą ofertę pracy do zamieszczenia w sieci. W firmie nie ma żadnego oficjalnego schematu - są powtarzające się elementy, ale “mięsko” oferty rekruter tworzy sam. Czy modele językowe mogą tu coś pomóc? Oczywiście. Czy warto samemu rozkładać strukturę oferty na czynniki pierwsze, żeby napisać dobrą instrukcję? Moim zdaniem szkoda czasu.
Weźmy na warsztat ofertę programisty sterowników z 7N (pozdrawiam i polecam, fajna firma, jeśli potrzebujecie zatrudnić osoby z IT) - skrócony zrzut ekranu poniżej (jest tam kilka więcej sekcji).
Do modelu językowego wrzuciłem ofertę pracy i instrukcję
“Zrób z tego template - wzorzec. Przeanalizuj, które elementy są stałe, które trzeba wypełnić. Zwróć wzorzec z instrukcją dla każdego punktu, który będzie zmienny pomiędzy ofertami pracy.”
Pewnie można by było to zrobić lepiej, ale lenistwo źródłem wynalazków. Model językowy (GPT-4o w tym przypadku) “domyślił się” o co chodzi od razu i wygenerował całkiem porządną instrukcję dla samego siebie (wklejam fragment):
Instrukcja: Część "O nas" może być stałym elementem szablonu, jeśli opisuje ogólną działalność firmy. W razie potrzeby można dostosować informacje dotyczące długości działalności, unikalnych wartości firmy lub misji.
Obowiązki:
Tworzenie oprogramowania dostosowującego się do potrzeb klienta w obszarze [OBSZAR DZIAŁALNOŚCI, np. zabudowy autobusów]
Utrzymanie [OKREŚLENIE OBSZARU, np. wewnętrznej bazy danych części oprogramowania]
Implementacja, uruchamianie i testowanie aplikacji [TECHNOLOGIA, np. PLC]
Analiza i rozwiązywanie problemów jakościowych w obszarze oprogramowania w określonym czasie
Instrukcja: W tej części należy dostosować szczegóły dotyczące konkretnej roli. Zmiennymi mogą być:
Specyficzny obszar działalności, w którym będzie działać pracownik (np. motoryzacja, automatyka przemysłowa)
Technologia lub system, z którym pracownik będzie miał do czynienia (np. PLC, HMI)
Szczegółowe zadania, jeśli rola wymaga innych umiejętności technicznych
Wymagania:
Doświadczenie w [SPECYFICZNEJ TECHNOLOGII LUB ZADANIU, np. programowaniu oprogramowania wbudowanego]
Dobra znajomość [TECHNOLOGIA, np. programowania PLC (FBD)]
Doświadczenie w [OKREŚLONA TECHNOLOGIA/MODUŁ, np. programowaniu na mikrokontrolery] będzie dodatkowym atutem
Podstawowa wiedza z zakresu [OBSZAR, np. projektowania elektroniki i elektrotechniki]
Umiejętność czytania [TYP DOKUMENTACJI, np. schematów elektrycznych]
Zdolność do diagnozowania usterek w [OBSZAR, np. systemach elektrycznych]
Znajomość [SPECYFICZNY PROTOKÓŁ, np. protokołu CAN] będzie dodatkowym atutem
Znajomość [PRZEPISY LUB NORMY, np. międzynarodowych przepisów dotyczących branży motoryzacyjnej, w tym cyberbezpieczeństwa]
Instrukcja: Tutaj należy dostosować wymagania dotyczące technologii, doświadczenia i specyficznych kwalifikacji potrzebnych do danej roli.
Zmiennymi mogą być:
Technologia (np. PLC, CAN)
Obszary wiedzy (np. elektryka, elektrotechnika)
Dodatkowe atuty (np. znajomość konkretnych norm branżowych)
Zwróćcie uwagę na to, jak bardzo elastyczny jest to wzorzec. Można wrzucić w to ofertę pracy programisty Java, analityka biznesowego czy architekta systemów i model językowy wymyśli pasujące kryteria. Im lepsza specyfikacja tym lepsze efekty, ale testowaliśmy takie podejście na ostatnich warsztatach z rekruterami wrzucając w analogiczną instrukcję dosłownie dwa zdania od ich klienta i efekt był zadowalający.
Oczywiście, że efekt końcowy należy zweryfikować, czy model czegoś nie przekręcił (na przykład stawek), ale pierwszy szkic, który od razu przypomina końcowy efekt da się zrobić jakieś 15 minut szybciej niż ręcznie. Kluczem sukcesu jest posiadanie efektu końcowego (najlepiej w ustrukturyzowanej postaci, z sekcjami, listami, i innymi tego typu elementami) w formie tekstowego dokumentu, np. Word (z PDFami to loteria).
Można to podejście pociągnąć dalej i kazać modelom językom automatycznie optymalizować swoje instrukcje pod konkretne zadania, jeśli ma się odpowiednio dużo przypadków testowych. Są już do tego narzędzia programistyczne i dają… zaskakujące rezultaty.
Pół roku temu pokazała się praca naukowców z firmy VMware, w której pokazano m.in., że modele językowe od firmy Meta (rodzina modeli LLama) radzą sobie lepiej z zadaniami matematycznymi, kiedy będą udawać komputer pokładowy z filmu Star Trek - ale żaden z naukowców nie wymyślił tej analogii, modele językowe wpadły na to same.
Ciekaw jestem, kto z “inżynierów promptowania” wpadłby na to, że
“You are a professor of mathematics. Answer the following math question. Take a deep breath and think carefully.”
będzie działać gorzej niż:
“Command, we need you to plot a course through this turbulence and locate the source of the anomaly. Use all available data and your expertise to guide us through this challenging situation.”
Pokaż modelowi językowemu jak ma wyglądać ostateczny wynik i niech wygeneruje do tego instrukcję. I jak zobaczysz analogię do filmu, to nie usuwaj - może to klucz do sukcesu :).
Ciekawe niusy
Casetext to firma AI z produktem asystenta prawnego, którą ostatnio kupił gigant Thomson Reuters za drobne $650 milionów dolarów. W ostatnim wywiadzie przekonywali, że ich podejście gwarantuje zero błędów i halucynacji. Na ich nieszczęście wywiad zauważyło środowisko AI na Twitterze, rozniosło argumentację prezesa Casetext, Jake’a Hellera, w drobny pył i zmusiło go do tłumaczeń:
A Jake Heller _nie jest bardzo aktywny_ na Twitterze/X (pojawia się co kilka miesięcy).
Bardzo mi się spodobał komentarz Hamela Husaina:
Jak się chce uzyskać 100% powtarzalności, to się używa deterministycznych narzędzi, a nie probabilistycznych. Nie dajcie się nabrać, jak ktoś Wam oferuje narzędzie AI, które ma zero halucynacji. Bo albo spekulatywna sztuczna inteligencja nie odgrywa tam znaczącej roli, albo liczba przekłamań nie wynosi zero.