O czym jest ten film
- Jev nie prowadzi rozmowy ani nie pisze odpowiedzi. Ocenia dostarczone dane według wcześniej określonych kryteriów i zwraca liczby, kategorie lub wyniki na skali.
- Dzięki temu może wspierać zwykły kod w decyzjach dotyczących treści, takich jak wiadomości klientów czy opisy błędów.
- Autor omawia trzy rodzaje pytań: rozstrzygnięcie „tak lub nie”, wybór spośród kategorii oraz ocenę na uporządkowanej skali.
- Jev ma uzupełniać Claude’a: przejmować liczne, powtarzalne oceny i przekazywać mu sprawy wymagające rozmowy, pisania lub głębszego namysłu.
- Pokazany przykład dotyczy 50 e-maili do działu obsługi. System rozdziela je między pracownika, zespół techniczny, rejestr pomysłów i Claude’a.
- Claude Code pomaga przygotować pytania, strukturę danych i reguły kierowania zgłoszeń, korzystając z umiejętności udostępnionej przez Typesafe.
- Dobre pytania wynikają z działań, które system ma później wykonać. Każda ocena powinna mieć określony cel.
- Progi wymaganej pewności należy dostosować do skutków pomyłki. Sprawy finansowe i niejednoznaczne trafiają w przykładzie do człowieka.
- Autor zaleca zadawanie kilku niezależnych pytań w jednym żądaniu oraz rozbijanie ogólnych ocen na konkretne kryteria.
- Wyniki demonstracji wskazują na szybkie przetwarzanie, ale część podanych w filmie przeliczeń kosztów jest niespójna.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od decyzji, którą trzeba podjąć
Na czym polega: Jev ma dostarczyć danych potrzebnych do konkretnego działania: skierowania sprawy, ustalenia priorytetu albo zatrzymania procesu.
Jak stosować: Wypisz możliwe działania w swoim procesie, a dopiero potem ułóż pytanie potrzebne do każdego z nich.
Na co uważać: Pytanie, którego wynik niczego nie zmienia, zwiększa złożoność systemu bez wyraźnej korzyści.
2.Dobierz rodzaj pytania do dalszego kroku
Na czym polega: „Tak lub nie” nadaje się do podjęcia lub zaniechania działania, wybór kategorii do skierowania sprawy, a ocena na skali do ustalenia kolejności.
Jak stosować: Dla wiadomości klienta osobno sprawdź, czy prosi o zwrot pieniędzy, do którego zespołu należy sprawa i jak pilna jest odpowiedź.
Na co uważać: Nie używaj jednej ogólnej oceny do kilku różnych decyzji. Trudniej wtedy ustalić, skąd wziął się wynik.
3.Zdefiniuj kryteria możliwie konkretnie
Na czym polega: Model ocenia dane według opisów przygotowanych przez użytkownika. Granice między kategoriami mają więc znaczenie.
Jak stosować: Zamiast pytać, czy błąd jest „poważny”, opisz poziomy: usterka wyglądu, problem z obejściem, brak możliwości korzystania z produktu.
Na co uważać: Ogólne określenia mogą być różnie rozumiane. Wybór spośród kategorii powinien też przewidywać odpowiedź „żadna z powyższych”.
4.Oddziel ocenę od działania
Na czym polega: Jev zwraca wynik, ale sam nie wysyła e-maila ani nie przekazuje zgłoszenia pracownikowi. Robi to kod według ustalonych reguł.
Jak stosować: Zapisz jawne warunki: kiedy wynik uruchamia działanie, kiedy wymaga potwierdzenia, a kiedy sprawa trafia do człowieka.
Na co uważać: Wynik liczbowy nie jest gwarancją poprawnej oceny. Błąd w regule kierowania spraw może być równie dotkliwy jak błąd modelu.
5.Ustal osobny próg dla każdej czynności
Na czym polega: Ta sama niepewność może być dopuszczalna przy przewijaniu strony, lecz zbyt duża przy zatwierdzaniu przelewu.
Jak stosować: Określ koszt pomyłki dla każdego działania i na tej podstawie ustaw próg lub wymóg potwierdzenia.
Na co uważać: Jeden próg dla całego procesu ignoruje różnicę między drobną niedogodnością a decyzją o skutkach finansowych.
6.Kieruj trudne sprawy do właściwej osoby lub narzędzia
Na czym polega: Proste zapytanie może obsłużyć skrypt, odpowiedź wymagającą sformułowania przygotuje Claude, a sporną lub nietypową sprawę oceni człowiek.
Jak stosować: Dla każdego rodzaju zgłoszenia wskaż wykonawcę i przewidź ścieżkę dla przypadków, których Jev nie potrafi jednoznacznie sklasyfikować.
Na co uważać: Automatyczne skierowanie nie rozwiązuje problemu, jeśli wybrany wykonawca nie ma danych lub uprawnień potrzebnych do działania.
7.Zadawaj niezależne pytania razem
Na czym polega: W jednym żądaniu można sprawdzić temat wiadomości, prośbę o zwrot, wagę usterki i ton wypowiedzi.
Jak stosować: Zbierz pytania, których odpowiedzi będą potrzebne przy różnych możliwych wynikach, i prześlij je wraz z tym samym zestawem danych.
Na co uważać: Późniejszy kod musi pominąć wyniki nieistotne dla danej sprawy. Ocena wagi usterki nie powinna wpływać na obsługę wiadomości wyłącznie o fakturze.
8.Przekazuj zwięzłe, uporządkowane dane
Na czym polega: W przykładzie każdy e-mail staje się osobnym obiektem z nazwanymi polami: tematem, treścią, planem klienta i datą otrzymania.
Jak stosować: Dołącz informacje, które człowiek sprawdziłby przed podjęciem decyzji, i nazwij pola tak, aby było jasne, czego dotyczą.
Na co uważać: Długi, nieistotny kontekst może utrudniać ocenę i zwiększać koszt. Autor przypomina też o limicie 64 tys. tokenów na żądanie.
9.Sprawdzaj odpowiedzi przygotowane przez Claude’a
Na czym polega: Jev może ocenić szkic odpowiedzi: czy odnosi się do pytania klienta i czy nie obiecuje zwrotu lub rabatu.
Jak stosować: Po przygotowaniu szkicu wyślij do kontroli oryginalną wiadomość i proponowaną odpowiedź; zachowaj tylko teksty spełniające ustalone warunki.
Na co uważać: Taka kontrola sprawdza określone kryteria. Nie daje pewności, że cała odpowiedź jest merytorycznie poprawna.
10.Sprawdzaj rachunki przed planowaniem kosztów
Na czym polega: W demonstracji przetworzenie 50 wiadomości kosztowało według autora 0,026 dolara, lecz dalsze przeliczenia w filmie nie zgadzają się z tą kwotą.
Jak stosować: Oszacuj koszt na podstawie liczby własnych zgłoszeń, wielkości danych i rzeczywistych pomiarów z próbnego uruchomienia.
Na co uważać: Przy stawce 0,026 dolara za 50 wiadomości dolar wystarczyłby na około 1900, a nie 19 tys. wiadomości. Codzienna analiza 50 wiadomości kosztowałaby około 9,49 dolara rocznie, bez uwzględnienia pozostałych części procesu.
Redakcyjne tłumaczenie
Model, który odpowiada liczbami
O jednym z najgłośniej omawianych ostatnio modeli AI trudno myśleć tak, jak o Claude’ie czy ChatGPT. Jev nie napisze nawet zdania. Nie można z nim porozmawiać ani poprosić go, by wyjaśnił swoją odpowiedź. Mimo to już w pierwszym tygodniu po udostępnieniu pokazano kilka interesujących zastosowań: przeglądarkę wypełniającą formularz Google Flights w około siedem sekund, analizę trzech milionów sesji na stronach internetowych w 40 sekund za mniej więcej dwa dolary oraz sterowanie Chrome głosem, które potrafi rozpocząć działanie, zanim użytkownik skończy mówić.
Przejrzałem dokumentację Jev. Chcę pokazać, czym ten model jest, kiedy może przydać się osobom korzystającym z Claude’a i jak połączyć oba narzędzia za pomocą Claude Code. Najważniejsze będzie jednak zrozumienie, o co pytać Jev i co później zrobić z jego odpowiedzią.
Zwykły program jest pełen prostych warunków. Możemy zapisać regułę: jeśli wartość zamówienia przekracza 10 tys. dolarów, skieruj je do kontroli. Komputer bez trudu porówna kwoty, daty czy wartości pól formularza. Znacznie gorzej radzi sobie z warunkiem „jeśli e-mail brzmi na napisany przez rozgniewanego klienta” albo „jeśli zamówienie wygląda podejrzanie”. Tych ocen nie da się odczytać wprost z jednej liczby.
Jev ma wypełnić tę lukę. Dostaje treść oraz dokładnie określone pytanie, a w odpowiedzi zwraca wynik, który program może wykorzystać. Pytamy na przykład, czy zamówienie wygląda podejrzanie, i określamy, co ma o tym świadczyć. Jev ocenia prawdopodobieństwo, a przygotowany przez nas kod sprawdza, czy wynik przekracza ustalony próg. Dopiero kod oznacza zamówienie do kontroli. Możemy też sprawdzić kilka przesłanek naraz i działać tylko wtedy, gdy wszystkie spełnią nasze warunki.
Typesafe, firma stojąca za Jev, nazywa go modelem ocen. Gdy zadamy Claude’owi pytanie o podejrzaną wiadomość, otrzymamy odpowiedź napisaną językiem naturalnym. Model może uzasadnić swoje stanowisko albo zaproponować dalszą korespondencję z klientem. Jev działa inaczej: wcześniej dostaje zestaw pytań, na przykład o rozbieżność między adresem płatnika a adresem dostawy, oraz dane konkretnego zamówienia. Następnie zwraca liczby odpowiadające zdefiniowanym możliwościom. Nie pisze komentarza.
W dokumentacji pojawia się porównanie do „systemu pierwszego” z książki „Pułapki myślenia”: szybkiej, niemal odruchowej oceny. Modele prowadzące rozmowę i rozumujące autor zestawia z bardziej namyślnym „systemem drugim”. To użyteczna analogia do podziału zadań, choć nie oznacza, że Jev rozumuje tak jak człowiek.
Dlaczego sam wynik liczbowy bywa zaletą
Według liczb przywołanych w filmie Jev może być od 40 do 1000 razy tańszy i od 20 do 400 razy szybszy od tradycyjnych modeli językowych w zadaniach, do których go przeznaczono. Autor podaje cenę około czterech centów za milion tokenów wejściowych oraz znikomy koszt odpowiedzi. Ma to znaczenie przy tysiącach podobnych ocen, kiedy każda rozbudowana odpowiedź modelu językowego kosztowałaby czas i pieniądze.
Jev zwraca wynik wyłącznie w ramach możliwości, które mu podamy. Jeśli zdefiniujemy trzy kategorie, nie dopisze czwartej. Nie znaczy to, że nie może się pomylić — może wybrać niewłaściwą kategorię. Zaletą jest przewidywalny format odpowiedzi, który łatwo przetworzyć w kodzie. Autor wskazuje również na większą powtarzalność: przy ponawianiu tej samej oceny wyniki Jev zmieniały się mniej niż wyniki porównywanych modeli konwersacyjnych.
Typesafe deklaruje, że wartości podawane przez model są skalibrowane. W praktyce chodzi o to, by wynik 0,8 odpowiadał trafnej ocenie w przybliżeniu w ośmiu przypadkach na dziesięć z podobnym wynikiem. Można to porównać z prognozą pogody: „80 proc. szans” ma sens wtedy, gdy takie zapowiedzi sprawdzają się mniej więcej osiem razy na dziesięć. Dzięki temu program może zdecydować, czy działać, skierować sprawę gdzie indziej, czy poprosić człowieka o ocenę.
Jev nie ma zastępować Claude’a. Ma przejąć pewien rodzaj pracy, który dziś często zlecamy modelom językowym: szybkie, liczne i powtarzalne oceny potrzebne wewnątrz oprogramowania. Rozmowa, pisanie, specjalistyczna wiedza oraz zadania wymagające rozbudowanego namysłu nadal należą do Claude’a lub podobnego modelu. Jev dostarcza sygnałów, na podstawie których reszta systemu wybiera dalszy krok.
Trzy rodzaje pytań
Pierwszy rodzaj to pytanie rozstrzygające „tak lub nie”, określane w materiale jako „null”. Wyobraźmy sobie pytanie: „Czy klient brzmi na rozgniewanego?”. Jeśli Jev zwróci 0,9, wynik przemawia za odpowiedzią „tak”. Możemy ustalić, że powyżej 0,8 wiadomość trafia do kierownika, a poniżej 0,2 nie wymaga takiej interwencji. Wynik około 0,5 oznacza, że na tej podstawie trudno rozstrzygnąć sprawę. Sam Jev niczego nie przekazuje dalej — robi to skrypt sprawdzający wynik.
Drugi rodzaj to wybór spośród zdefiniowanych kategorii. Pytamy, który zespół powinien zająć się wiadomością: rozliczenia, wsparcie techniczne czy sprzedaż. Odpowiedź może przypisać tym możliwościom odpowiednio 85, 10 i 5 proc. Program wybierze wtedy dział rozliczeń. Przy pytaniu z kilkoma kategoriami Jev zwraca także wskaźnik pewności wyboru. Rozkład 85–10–5 wskazuje wyraźnego faworyta; przy rozkładzie 40–35–25 przewaga pierwszej kategorii jest dużo mniej przekonująca. Kod powinien sprawdzić również tę drugą wartość, zanim skieruje sprawę.
Tak działa jeden z pokazanych przykładów sterowania przeglądarką. System ocenia, jaką czynność wykonać — kliknąć, wpisać tekst czy przewinąć stronę — oraz którego elementu strony to dotyczy. Każdy przycisk i pole otrzymuje identyfikator. Jeśli ocena jest dostatecznie jednoznaczna, program wykonuje czynność. W przeciwnym razie zatrzymuje się i pyta użytkownika.
Trzeci rodzaj to ocena na uporządkowanej skali. Jej poziomy opisujemy słowami, na przykład „spokojny”, „poirytowany” i „wściekły”. Pytanie brzmi: „Jak bardzo rozgniewany jest klient?”. Wynik może wypaść między poziomami. Wartość 2,4 na takiej skali wskazuje, że wypowiedź jest bliższa „poirytowanej”, lecz przesuwa się w stronę „wściekłej”. Pozwala to ułożyć wiadomości od najbardziej pilnych. W ten sam sposób można oceniać wagę błędu, pilność zgłoszenia czy dopasowanie potencjalnego klienta do oferty. Tu również pojawia się wskaźnik pewności.
Różnicę najłatwiej zapamiętać, patrząc na dalszą czynność. Jeśli program ma zdecydować, czy coś zrobić, pytamy „tak lub nie”. Jeśli ma wybrać miejsce docelowe, wybieramy kategorię. Jeśli ma ułożyć sprawy w kolejności, korzystamy ze skali. Wszystkie trzy rodzaje pytań można zawrzeć w jednym żądaniu. Jedna wiadomość klienta może więc jednocześnie dostać ocenę tonu, kategorię działu i miejsce w kolejce.
Podobnie wyglądał pokaz analizy sesji na stronach internetowych. Osobne pytania rozpoznawały zdarzenia, takie jak wielokrotne klikanie z frustracji, kliknięcie niedziałającego elementu czy błąd na stronie. Dodatkowa ocena określała, jak nieudana była cała sesja. Człowiek mógł potem obejrzeć tylko najwyżej ocenione przypadki, zamiast przeglądać miliony nagrań po kolei.
Gdzie umieścić Jev w pracy z Claude’em
Widzę dwa główne sposoby połączenia tych narzędzi. Pierwszy polega na sprawdzaniu materiałów przed użyciem Claude’a lub po otrzymaniu jego odpowiedzi. Typesafe pokazuje przykład kontroli wiadomości wysyłanych do modelu pod kątem prób obejścia zabezpieczeń i szkodliwych próśb. Odpowiedź Claude’a może przejść podobną kontrolę, zanim zobaczy ją użytkownik.
Inny przykład dotyczy cytowań. Model językowy przygotował dokument z ośmioma odwołaniami do źródeł. Jev porównał je z materiałami: cztery uznał za poprawne, przy jednym wykrył nieistniejący cytat, przy kolejnym znaczenie przeciwne do treści źródła, a dwa przekazał człowiekowi z powodu niepewności. To sposób na sprawdzenie określonych elementów odpowiedzi, takich jak zgodność cytatu ze wskazanym fragmentem.
Drugi sposób to zastąpienie Claude’a przy masowej klasyfikacji. Jeśli trzeba posortować pięć tysięcy wierszy, oznaczyć zgłoszenia w skrzynce albo ocenić setki potencjalnych klientów, Jev może wykonać etap oceny. Claude dostanie tylko przypadki niejednoznaczne oraz te, w których trzeba napisać odpowiedź. W filmie pojawia się przykład oceny 700 kontaktów sprzedażowych w 40 sekund za około dziewięć centów.
Przygotowanie Claude Code
Typesafe udostępnia umiejętność dla narzędzi takich jak Claude Code. Można ją znaleźć w panelu Typesafe lub w dokumentacji pod adresem docs.typesafe.ai/agent-skill. Autor instaluje ją poleceniami podanymi w dokumentacji, uruchamia nową sesję Claude Code i sprawdza na liście wtyczek, czy instalacja się powiodła. Następnie tworzy klucz API i zapisuje go w pliku konfiguracyjnym środowiska.
W poleceniu dla Claude’a wyraźnie wskazuje, by użył umiejętności Typesafe. Pierwsza próba jest prosta: do Jev trafia wiadomość „Obciążono nas dwa razy. Proszę pilnie to naprawić” oraz pytanie, czy klient zgłasza problem z rozliczeniem. Claude, korzystając z instrukcji umiejętności, przygotowuje opis danych i kryteria odpowiedzi. Do odpowiedzi „tak” zalicza problemy z obciążeniami, płatnościami, fakturami, zwrotami i rozliczaniem subskrypcji. Jev zwraca 0,99.
Autor podaje, że samo żądanie do Jev trwało około 0,3 sekundy. Obejmowało 324 tokeny wejściowe i 24 wyjściowe. Umiejętność Typesafe nie wykonuje pracy za model: jest zestawem wskazówek, jak dobrać rodzaj pytania, opisać kryteria, połączyć pytania w żądaniu i umieścić progi w kodzie. Claude przygotowuje skrypt, skrypt kontaktuje się z Jev, a potem wyniki wracają do dalszego przetwarzania.
Autor wspomina też o użyciu tej umiejętności w aplikacji Claude na komputerze przez dodanie jej pliku w ustawieniach. Zastrzega jednak, że sam tej drogi nie przetestował. Bez Claude Code można korzystać z modelu przez inne narzędzie udostępniające dostęp do niego, lecz wtedy pytania, opisy kategorii i strukturę danych trzeba przygotować samodzielnie.
Przykład: 50 wiadomości po nocy
Załóżmy, że rano czeka na nas 50 e-maili od klientów. W pliku CSV są identyfikatory, daty otrzymania, informacje o planie i historii klienta, dane ostatniej faktury, tematy oraz treści wiadomości. Są tam prośby o zwrot, problemy z logowaniem, zgłoszenia błędów, propozycje nowych funkcji i pytania dotyczące zgodności z RODO.
Zanim ułożę pytania dla Jev, określam możliwe działania. Claude może przygotować szkic odpowiedzi. Sprawa może trafić do zespołu technicznego, do rejestru propozycji nowych funkcji albo do pracownika obsługi. Chcę też, aby w każdej grupie najpilniejsze wiadomości znalazły się na początku.
Tak opisuję zadanie Claude Code. Proszę o użycie umiejętności Typesafe, analizę 50 wiadomości z pliku CSV i rozdzielenie ich na cztery grupy. Dla każdego e-maila chcę znać główny temat: rozliczenia, problem techniczny, propozycja funkcji, konto albo „żadna z powyższych”. Ta ostatnia możliwość jest istotna. Bez niej model musiałby dopasować nawet obcą sprawę do jednej z podanych kategorii.
Dodaję kolejne pytania: czy klient domaga się zwrotu pieniędzy, czy coś w produkcie nie działa, jak mocno brzmi jego niezadowolenie oraz czy odpowiedź jest rutynowa, wymaga oceny, czy jest na tyle nietypowa, że powinien zająć się nią człowiek. Określam też zasady działania. Sprawy dotyczące pieniędzy mają trafić do pracownika, podobnie jak przypadki nietypowe i takie, których kategorii Jev nie rozpoznaje dostatecznie pewnie. Problem uniemożliwiający korzystanie z produktu trafia do zespołu technicznego. Propozycje funkcji zostają zapisane. W pozostałych przypadkach Claude przygotowuje szkic według osobnego poradnika odpowiedzi.
Każdą grupę ustawiam według wyniku, w którym większą wagę ma niezadowolenie klienta, a mniejszą dotkliwość problemu. Przed zapisaniem szkicu proszę o jeszcze jedną kontrolę: czy odpowiedź rzeczywiście dotyczy pytania klienta i czy nie obiecuje zwrotu pieniędzy lub rabatu. Zachowane mają zostać tylko szkice, które przejdą oba sprawdzenia.
Ważny jest ostatni warunek polecenia: Claude ma najpierw pokazać plan, a dopiero później uruchomić przetwarzanie. Plan ma zawierać dane przekazywane do modelu, pytania wraz z kryteriami oraz reguły kierowania spraw z progami dla poszczególnych działań. Dzięki temu mogę sprawdzić zasady przed analizą całego pliku.
Jak wygląda plan
Claude proponuje osobny, uporządkowany zestaw danych dla każdej wiadomości. Zamiast jednego długiego ciągu tekstu Jev otrzymuje nazwane pola, między innymi identyfikator, datę, plan klienta, temat i treść e-maila. Informacja o planie oraz stażu klienta może mieć znaczenie: zgłoszenie wieloletniego klienta z najwyższego planu to inna sytuacja niż wiadomość od osoby, która dopiero rozpoczęła okres próbny.
Do danych nie trafia wszystko, co udałoby się znaleźć. Pominięta zostaje na przykład niepotrzebna historia wcześniejszej korespondencji. Jev ma limit 64 tys. tokenów na żądanie, ale autor podkreśla, że dobrze przygotowane pytania powinny korzystać ze znacznie krótszych, konkretnych danych. Osobny zestaw powstaje dla drugiej kontroli: zawiera oryginalną wiadomość i szkic odpowiedzi Claude’a.
Każdy e-mail dostaje pięć pytań w jednym żądaniu. Pierwsze dotyczy głównego tematu. Opis kategorii „rozliczenia” obejmuje obciążenia, faktury, płatności i koszty subskrypcji, lecz wyklucza problemy z logowaniem lub dostępem do konta. Kolejne pytanie sprawdza prośbę o zwrot: samo anulowanie subskrypcji, bez żądania zwrotu już zapłaconych pieniędzy, nie spełnia tego warunku.
Ocena problemu technicznego ma kilka opisanych poziomów: od braku usterki, przez defekt wyglądu i problem, który da się obejść, po niemożność korzystania z produktu. Takie doprecyzowanie jest ważniejsze niż samo słowo „uciążliwy”. Dla Jev otrzymuje ono konkretny sens: funkcja działa gorzej lub zawodzi czasami, ale klient ma sposób obejścia problemu. Osobne pytanie dotyczy tonu wiadomości, a kolejne tego, ile oceny wymaga przygotowanie odpowiedzi.
Wszystkie pytania trafiają do modelu razem, nawet jeśli część nie będzie miała zastosowania. E-mail o fakturze też otrzyma ocenę wagi usterki, lecz dalszy kod ją zignoruje, jeśli sprawa w ogóle nie dotyczy działania produktu. Gdy wiadomość opisuje błąd, potrzebna ocena jest już gotowa i nie trzeba wysyłać drugiego żądania.
Plan zawiera również reguły kierowania spraw. Wyniki Jev przechodzą przez zwykłe warunki zapisane w skrypcie. Jeśli pewność przypisania kategorii jest zbyt mała, wiadomość trafia do człowieka. Pozostałe wyniki, zależnie od progów, kierują ją do zespołu technicznego, rejestru pomysłów albo kolejki szkiców dla Claude’a. Na tym etapie nie ma kolejnej swobodnej decyzji modelu językowego: reguły da się odczytać i sprawdzić w kodzie.
Wynik próby i ważna poprawka w rachunkach
Autor uruchomił taki proces dla 50 wiadomości, używając ośmiu równoległych zadań. Całość trwała 4,2 sekundy. Według jego porównania przetwarzanie tych samych wiadomości jedna po drugiej zajęłoby około 31 sekund. Koszt oceny wyniósł 0,026 dolara za wszystkie 50 e-maili.
Wyniki zapisano w czytelnym zestawieniu. Priorytet składał się w 70 proc. z oceny niezadowolenia klienta i w 30 proc. z dotkliwości problemu. Dziewiętnaście wiadomości trafiło do człowieka. Część przekazano zespołowi technicznemu, część zapisano jako propozycje funkcji, a dla kolejnych 19 Claude miał przygotować odpowiedzi. Pracownik może zacząć dzień od uporządkowanej listy spraw, które rzeczywiście wymagają jego uwagi.
(Informacja dodatkowa: W filmie pojawiają się niespójne przeliczenia kosztu. Jeśli 50 ocen kosztuje 0,026 dolara, za jednego dolara można ocenić około 1900 takich wiadomości, a nie 19 tys. Codzienne przetwarzanie 50 wiadomości przez rok kosztowałoby przy tej samej stawce około 9,49 dolara, nie jednego dolara. Nie obejmuje to innych kosztów, na przykład przygotowania odpowiedzi przez Claude’a.)
Pięć kroków do własnego zestawu pytań
Napisanie skryptu z pomocą Claude’a jest stosunkowo łatwe. Trudniejsze okazuje się ustalenie, o co model powinien pytać. Przygotowałem więc własną listę pięciu kroków, złożoną na podstawie dokumentacji i przykładów zastosowań.
Najpierw wypisuję działania, które system ma móc wykonać. W przykładzie są to: szkic odpowiedzi od Claude’a, zgłoszenie do zespołu technicznego, zapis propozycji funkcji i przekazanie sprawy pracownikowi. Następnie dla każdego działania zapisuję zdanie określające warunek. „Wyślij do człowieka, gdy klient prosi o zwrot pieniędzy” od razu podpowiada pytanie dla Jev. Pokazuje też, że chodzi o rozstrzygnięcie „tak lub nie”. Jeśli warunek wybiera dział, potrzebna będzie kategoria; jeśli ustala kolejność pracy, potrzebna będzie skala.
W trzecim kroku zapisuję, jakie informacje sprawdziłby człowiek przed podjęciem tej decyzji. To właśnie dane, które należy przekazać modelowi. Czwarty krok polega na szukaniu wyjątków: co jeszcze mogłoby być prawdą i zmienić dalszą drogę zgłoszenia? Stąd wziął się pomysł osobnej oceny wagi usterki. Na koniec określam koszt błędnej decyzji. Od niego zależy próg wymaganej pewności oraz to, kiedy sprawa powinna trafić do człowieka.
Cztery zasady projektowania takiego procesu
Pierwsza zasada brzmi: zadawaj potrzebne, niezależne pytania od razu. W przykładzie wszystkie pięć trafia do Jev w jednym żądaniu. Nie czekamy na rozpoznanie kategorii, aby dopiero później zapytać o wagę błędu. Odpowiedzi, które nie dotyczą danej wiadomości, pomijamy w dalszym przetwarzaniu. Jeśli dotyczą — są już dostępne.
Druga zasada to osobny próg dla każdej czynności. Typesafe pokazuje przykład bankowości sterowanej głosem. Odczytanie salda może wymagać niższego progu rozpoznania polecenia niż zatwierdzenie przelewu. Gdy wynik przy ważniejszej operacji nie jest wystarczająco pewny, system powinien poprosić o potwierdzenie. Podobnie w demonstracji przeglądarki przewinięcie strony może nastąpić od razu, natomiast zamknięcie karty wymaga ostrożniejszej reguły.
Trzecia zasada polega na rozbiciu ogólnej oceny na części. Pytanie „Czy to dobry kandydat do pracy? Podaj wynik od 1 do 10” daje liczbę, ale niewiele mówi o powodach. Lepiej osobno ocenić znajomość Pythona, projektowanie systemów, kierowanie zespołem i tempo uczenia się. Później kod może połączyć te wyniki z wagami odpowiednimi dla stanowiska. Przy rekrutacji starszego programisty większe znaczenie mogą mieć umiejętności techniczne i projektowe; przy stanowisku menedżerskim — kierowanie ludźmi.
Czwarta zasada to skierowanie każdego rodzaju sprawy do narzędzia lub osoby najlepiej przygotowanej do jej obsługi. Pytanie „Gdzie jest moje zamówienie?” może uruchomić odczyt z bazy danych. Pytanie o funkcję produktu trafi do Claude’a mającego dostęp do dokumentacji. Złożona skarga trafi do pracownika. Jev szybko rozpoznaje rodzaj sprawy, lecz nie musi sam wykonywać końcowego zadania.
Pokaz inteligentnego domu łączy te zasady. Polecenie wyłączenia świateł wymaga rozpoznania rodzaju prośby, pomieszczeń, urządzeń i działania. Jeśli użytkownik połączy w jednym zdaniu dwa polecenia, sprawa może trafić do modelu językowego, który rozdzieli je na osobne zadania. Jeśli zapyta o coś niezwiązanego ze sterowaniem domem, odpowiedzią również zajmie się model językowy.
Właśnie w takim układzie widzę największy pożytek z Jev. Szybko ocenia dużą liczbę jasno określonych przypadków, a Claude przejmuje rozmowę, pisanie i sprawy, w których potrzeba więcej namysłu. O jakości całego procesu decydują jednak pytania, opis kategorii i reguły działania zapisane przez człowieka.