Ściśle według scenariusza (Programy konwersacyjne cz. 2)

Na początek drobne ogłoszenie: jeżeli udaje wam się czytać ten tekst, to wiecie, że podczepiłem blog i Przenicę (https://szymonrutkowski.pl/przenica) pod domenę szymonrutkowski.pl. Pozwala mi to prywatnie zaoszczędzić parę groszy. Obecnie pracuję nad nowym projektem (zupełnie oderwanym od Przenicy), co zajmuje mi większość czasu na… rozwój & badania, jeżeli to tak ująć. Poza tym być może, w związku z pracą dla CLARIN-u, zabiorę się w końcu za kontynuację serii o morfonologii, która bardzo się wiąże z tym, co aktualnie robię zawodowo.

No dobrze, a co z programami konwersacyjnymi? Planuję na ten temat jeszcze dwa wpisy. Obecny będzie dotyczyć aplikacji, które idą w kierunku przewidywania wszystkich sytuacji przez programistę. W następnym zajmiemy się sposobami, które pozwalają do pewnego stopnia “nadążać za rozmówcą” – niezależnie od tematów, jakie on wybierze. Przy tej okazji poruszę kwestię pięknych konwersacji, jakie można mieć z komputerem, który naczyta się klasycznej literatury (w naszym wypadku Lalki Prusa).

Fakt jest taki, że w obecnych zastosowaniach przemysłowych technika “scenariuszowa” – chociaż mniej ekscytująca – w zupełności wystarcza, a zapewne nawet sprawdza się lepiej. Jak wiadomo, często rozwiązania prostsze technicznie są ekonomicznie lepsze.

Trzeba wiedzieć, że temat chatbotów jest aktualnie głośny w branży. Przewiduje się, że niedługo będziemy robić zakupy czy wykonywać operacje na koncie bankowym “rozmawiając” z odpowiednim programem. Jest to jeden z pierwszych trendów w światowej IT, które przychodzą z Chin – gdzie większość przedsiębiorstw ma tak zwane oficjalne konta na tamtejszym serwisie WeChat. Owe konta służą właśnie do automatycznych konwersacji.

Aplikacje mające reprezentować biznes powinny być przewidywalne, jeżeli chodzi o wykonywanie swoich zadań i nierobienie głupot. Wiele mówiący jest tutaj przypadek Tay: tworu Microsoftu, który świat zobaczył 23 marca tego roku. W ramach przypomnienia: Tay miała być chatbotem-nastolatką na Twitterze, ale okazała się nabierać ekstremalnych poglądów i trzeba ją było odciąć od Internetu po 16 godzinach. Dokładny schemat jej działania nie jest znany, ale na pewno była zasadniczo systemem “otwartym”, niescenariuszowym. Jedną z zalet stosowania zamkniętych schematów jest z pewnością łatwość upewnienia się, że nasz program nie zacznie się wdawać w w wywody o dobrych intencjach Hitlera.

Jednak ten blamaż nie odwiódł obecnego szefa Microsoftu, Satya Nadelli, od ogłoszenia programów konwersacyjnych elementem nowej strategii korporacji. W czerwcu Apple zakomunikowało, że w nowym iOS-ie będzie możliwa głęboka integracja wszelkich aplikacji z Siri – słynnym “chatbotem” pozwalającym na głosowe sterowanie smartfonem. Wielką platformą dla programów konwersacyjnych na pewno stanie się Facebook Messenger (gdzie modelową aplikacją jest Poncho, kot-pogodynka).

Wracając na chwilę do historii: polski system MARYSIA, rozwijany głównie w latach 70. ubiegłego wieku na Uniwersytecie Warszawskim, mógłby być dobrym przykładem programu scenariuszowego. MARYSIA była planowana jako trochę coś więcej niż odpowiednik ELIZY: miała służyć jako warstwa interfejsu do dowolnego programu. Mógł to być na przykład program wykonujący obliczenia matematyczne, które wymagałyby czasem zapytania człowieka o wskazówki (żadnych Instagramów w tej epoce). Zespół UW zmagał się nie tylko ze skomplikowaną polską fleksją, ale też ze słabością przestarzałego sprzętu (duńska maszyna GIER z końca lat 50.) – przez co polskiej ELIZY nigdy nie udało się ukończyć[1.].

Tak zwane “scenariusze” i “scenopisy” MARYSI miały regulować konwersację z użytkownikiem – trwającą tak długo, aż uda się uzyskać od niego informacje potrzebne dla głównego systemu roboczego. Jest to typowa sytuacja, pojawiająca się także w komercyjnych systemach rezerwujących samoloty czy pokoje hotelowe.

Wyobraźmy sobie teraz, że budujemy program mający w rozmowie z użytkownikiem ustalić sposób obróbki fotografii. Potrzebuje on szeregu czysto liczbowych informacji, takich jak kontrast K, liczba kolorów L i tak dalej. Mamy przy tym jakąś metodę, która interpretuje wypowiedzi człowieka. Aplikacja mogłaby, w wielkim uproszczeniu, przekładać słowa takie jak “bardzo”, “trochę”, “dużo” na liczby (co nie może się ograniczać do wychwytywania obecności pojedynczych słów – rozważ przypadki “bardzo dużo” czy “trochę mniej niż”). Otóż maszyna może w jakiś sposób oceniać, czy wypowiedź człowieka jest dla niej w miarę zrozumiała i jeżeli nie jest, zadawać to samo pytanie jeszcze raz. Schemat mógłby wyglądać tak:

Schemat prostego chatbota

Program powinien postępować w ten sposób, dopóki nie zbierze zbioru odpowiednich informacji, który przekaże do aplikacji rzeczywiście dokonującej obróbki zdjęcia. Mamy więc coś w rodzaju prostego scenariusza.

Problem w tym, że rozmowa z takim programem okaże się frustrująca, jeżeli użytkownik nie umie wypowiadać w sposób wystarczająco zrozumiały dla parsera (czyli, w tym wypadku, podsystemu przekładającego wypowiedzi człowieka na wartości parametrów). Za czwartym razem, gdy beznamiętny głos “Fotoelizy” zapyta o kontrast, przeciętny człowiek w najlepszym razie zrezygnuje, a w najgorszym fizycznie wyładuje swój gniew na komputerze.

Okazuje się, że rozmowy nie wystarczy ujmować jako prostej wymiany wypowiedzi na ustalony temat. Nawet pomijając język mimiki i gestów, przy okazji przekazujemy sobie wiele innych informacji. Wielokrotnie prosząc o powtórzenie wypowiedzi, maszyna nieświadomie mówi użytkownikowi coś jeszcze – coś, co mu się bardzo nie podoba.

Pod pewnymi względami typowa, codzienna rozmowa nie różni się od komunikacji radiowej, na której Shannon wypracował teorię informacji, czy przesyłania paczek danych przez protokół TCP/IP. Podczas komunikacji rozmówcy wypowiadają się na temat kanału, którym przekazują sobie informacje na główny temat. Kanał lubi w praktyce się zatykać; dlatego dobrze jest na wszelki wypadek potwierdzać dotarcie wiadomości. W lingwistyce mówi się o funkcji fatycznej wypowiedzeń podtrzymujących rozmowę. Służą temu “półsłówka” – wszelkie tak mhm – ale też przeformułowywanie i powtarzanie po rozmówcy. By rzec prawdę, potwierdzenia odbioru są głęboko zanurzone w wypowiedziach, które pozornie nie mają temu służyć. – Spotkajmy się o czwartej. – Gdzie się widzimy? (= Usłyszałem i zrozumiałem, że proponujesz spotkanie. Gdzie?).

Pojawiają się tutaj zjawiska, które można nazwać socjologicznymi czy psychologicznymi: mówiąc prosto, ludzie rzeczywiście się denerwują, jeżeli ktoś ich nie rozumie, albo sami są nierozumiani – zwłaszcza jeżeli chodzi o “proste” rzeczy. Ktoś, kto nie potrafi się wysłowić, albo pojąć swojego rozmówcy, musi być, oczywiście, głupi. (Nawet przesadne potwierdzanie, że rozumiemy rozmówcę, może być obraźliwe!). Przy budowie programu komputerowego ryzykuje się, że wyda się on głupi użytkownikowi, albo – co chyba gorsze z punktu widzenia projektanta – zachowanie maszyny sprawi, że głupi poczuje się człowiek.

Chyba bardziej złożoną kwestią, choć równie “przezroczystą” dla użytkowników języka, jest przekazywanie inicjatywy w mówieniu. Istnieją tutaj określone reguły – jak to zwykle z regułami, najlepiej je widać, gdy są łamane. Na przykład małe dzieci mają skłonność do przerywania wszystkim i głośnego wypowiadania, co im przyjdzie do głowy – zanim zrozumieją, że ich kolej nadejdzie i można delikatnie sugerować, że chce się coś powiedzieć. Myślę, że każdy zna także pewną liczbę dorosłych, którzy wyrzucają z siebie wielosłowie i agresywnie przejmują kontrolę nad konwersacją.

Jednak zazwyczaj codzienna rozmowa między ludźmi jest wzorem porządku i organizacji. W każdym momencie mówi jedna osoba (poza krótkimi chwilami, gdy może się ważyć, kto się pierwszy wypowie), a między wypowiedziami różnych osób w zasadzie nie ma przerw. Pomimo takich objawów zdyscyplinowania kolejność i długość utrzymywania inicjatywy przez każdego uczestnika nie jest z góry określona: ustala się na bieżąco, zwykle w chwili, gdy ktoś kończy mówić. Na przykład gdy rozmawia kilka osób, jedna z nich może wybrać kolejną, zadając jej pytanie. Jeżeli kogoś zainteresował ten temat, proponuję A Simplest Systematics for the Organization of Turn-Taking for Conversation (Sacks et al., 1974).

Oczywiście, zasady inicjatywy bardziej ujawniają się w rozmowie głosowej. Ale także jeżeli używamy tekstowego komunikatora, oczekujemy, że obie osoby będą miały okazję się wypowiedzieć. Raczej nie chcielibyśmy, żeby pojedyncze wypowiedzi programu konwersacyjnego były dziesięciostronnicowe, nawet jeżeli mogłyby być bardzo mądre i choćby wygenerowanie takiej ilości tekstu nie było problemem dla maszyny. Myślę, że do ciekawych zjawisk doprowadza funkcja, którą chyba pamiętam jeszcze z Gadu-Gadu, a obecna jest w czacie Facebooka – to znaczy wskaźnik, że druga osoba właśnie pisze. Często skłania to rozmówcę do rezygnacji z pisania w tej chwili, żeby dać się wypowiedzieć drugiej osobie. A nierzadko kończy się to tak, że oboje przestają pisać. Trudno powiedzieć, czy widać tu niedoskonałość projektu aplikacji, czy brak ustabilizowanych reguł konwersacji tekstowej.

Uf, dużo tej teorii! Trochę dlatego, że z definicji techniczna realizacja czysto scenariuszowego “robota” nie przedstawia jakichś specyficznych problemów. To znaczy, parsowanie języka naturalnego czy rozpoznawanie mowy (żeby zrozumieć użytkownika) oraz synteza głosu (żeby dać głos maszynie) to są bardzo poważne, złożone dziedziny, ale mają one wiele zastosowań innych niż programy konwersacyjne. Problem generowania tekstu po prostu omijamy – ustalamy szereg pytań, na które program ma gotową odpowiedź. Na wypadek, gdyby użytkownik wykroczył poza schemat, wrzucamy trochę zróżnicowanych wypowiedzi oznaczających “przepraszam, nie rozumiem, porozmawiajmy o czymś innym”. Jak można się domyślić, ludzie uwielbiają słyszeć coś takiego od rozmówcy.

Ale ponownie, prostota techniki ułatwia jej masowe zastosowanie. W ten sposób będą działać chatboty, które niedługo zaleją rynek smartfonów, jeśli przewidywania gigantów branży są słuszne i świat pójdzie za przykładem Państwa Środka. Jeżeli macie ochotę już dziś wypróbować program pracujący głównie na predefiniowanych wypowiedziach, proponuję A.L.I.C.E. lub Monikę z ZUS-u.

Tendencja, która jest widoczna w nowoczesnych chatbotach internetowych, to nieco paradoksalnie odchodzenie od konwersacji mających imitować kontakt z człowiekiem. Znacznie prostsze jest zmuszenie użytkownika do wyboru gotowych opcji. (Chociaż może lepiej ująć to jako przedstawienie tych opcji, zamiast zmuszania, żeby człowiek je zgadywał). Każdy, kto zagrał w jakąś grę CRPG albo przygodową, zna z doświadczenia “drzewka dialogowe”. Rozmowa z postaciami niezależnymi, sterowanymi przez komputer, wygląda zwykle tak:

  1. Użytkownik wybiera jakąś wypowiedź, którą ma wygłosić jego postać.
  2. Na co postać komputerowa odpowiada według skryptu: jej odpowiedź na każdą opcję dialogową jest wprogramowana w kod gry co do przecinka.
  3. Użytkownik dostaje listę opcji dialogowych do wyboru w nowej sytuacji (może to być inna lista niż poprzednio).
  4. Użytkownik znowu wybiera jakąś wypowiedź itd.

W istocie, jeżeli wypowiedzi komputera i tak są oskryptowane, nie ma sensu, żeby gracz miał się domyślać, że musi powiedzieć Gdzie Pan był dziś wieczorem?, podczas gdy Gdzie Pan był dziś wczesną nocą? wywoła ciszę albo błąd programu. Z tym, że oczywiście taka “konwersacja” niezbyt przypomina rozmowę z człowiekiem. W następnym wpisie zajmiemy się próbami zbudowania programu konwersacyjnego zajmującego się bardziej naturalnie.

[1.] Więcej można przeczytać w ogólnodostępnym artykule Założenia polskiego systemu konwersacyjnego MARYSIA (z 1973 roku). Dziękuję P. Profesorowi Januszowi Bieniowi za udzielenie informacji na ten temat.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *