Kiekvienas, kas bent kartą naudojosi ChatGPT, Claude ar bet kuriuo kitu kalbos modeliu, greičiausiai yra matęs tą keistą momentą — modelis su absoliučiu pasitikėjimu pateikia informaciją, kuri tiesiog neegzistuoja. Sugalvoja knygos pavadinimą, kurio autorius niekada nerašė. Nurodo teismo bylos numerį, kurio nėra jokioje duomenų bazėje. Paaiškina API funkciją, kuri skamba logiškai, bet realybėje tokios funkcijos toje bibliotekoje niekada nebuvo. Šis reiškinys pramone vadina halucinacijomis, ir kuo giliau į jį panagrinėji, tuo aiškiau matai — tai ne klaida sistemoje, o jos prigimtinė savybė.
Kas iš tikrųjų vyksta, kai modelis „meluoja”
Pirmiausia verta atsikratyti antropomorfinio mąstymo. Modelis nemeluoja ta prasme, kokia meluoja žmogus — jis neturi intencijos apgauti, nežino, kad klysta, ir neturi jokio vidinio „aš žinau tiesą, bet sąmoningai ją iškraipau” mechanizmo. Tai, ką jis daro, yra kur kas paprasčiau ir kartu keisčiau: jis generuoja seką žodžių, kurie statistiškai labiausiai tikėtini pagal treniravimo duomenis ir kontekstą, kuriame vyksta pokalbis.
Didelis kalbos modelis iš esmės yra tikimybių skaičiuoklė. Kai jis „rašo” atsakymą, kiekvienas sekantis žodis (tiksliau, tokenas) parenkamas pagal tai, kas labiausiai tinka po prieš tai buvusių žodžių. Jei modelis treniruotas ant milijardų tekstų apie mokslinius straipsnius, jis puikiai išmoko, kaip atrodo mokslinio straipsnio citata — pavadinimas, autoriai, metai, žurnalas. Bet jis neturi vidinio mechanizmo, kuris patikrintų, ar konkreti citata tikrai egzistuoja duomenų bazėje. Jis tiesiog atkuria formą, kuri statistiškai atrodo teisinga.
Statistika vietoj supratimo
Čia slypi esminė problema. Žmogus, kai nežino atsakymo, dažniausiai tai jaučia — kyla neapibrėžtumo pojūtis, abejonė. Modelis tokio vidinio signalo neturi ta pačia forma. Jam generuoti tikslų faktą ir generuoti įtikinamai skambantį prasimanymą yra techniškai identiškas procesas — abu atvejai yra tiesiog tokenų seka, parinkta pagal tikimybes. Skirtumas tik tas, kad vienu atveju ta seka sutampa su realybe, o kitu — ne.
Tyrėjai, dirbantys su šiomis sistemomis, mėgsta sakyti, kad modelis „nežino, ko nežino”. Tai gana tiksliai apibūdina situaciją. Kai paklausi apie plačiai aprašytą temą — sakykime, Antrąjį pasaulinį karą — modelis turi milijonus panašių sakinių treniravimo duomenyse, todėl atsakymas paprastai bus tikslus, nes teisingos informacijos yra tiesiog daug ir ji nuosekli. Bet kai paklausi apie nišinę temą, retą reguliavimo aktą ar mažai žinomą mokslininką, treniravimo duomenų apie tą konkretų dalyką gali būti minimaliai arba jų gali visai nebūti. Tokiu atveju modelis vis tiek generuos atsakymą, nes jo užduotis yra generuoti — jis neturi „nutylėjimo” mygtuko, nebent specialiai apmokytas tokį elgesį taikyti.
Kelios halucinacijų rūšys, su kuriomis susiduri kasdien
Verta suprasti, kad halucinacijos nėra vienalytis reiškinys. Praktikoje jos pasireiškia keliais gana skirtingais būdais:
- Faktinės halucinacijos — modelis sugalvoja skaičius, datas, vardus. Klasikinis pavyzdys: paprašius nurodyti šaltinius, modelis sukuria akademinių straipsnių pavadinimus su realistiškai atrodančiais autoriais ir metais, bet patys straipsniai niekada neegzistavo.
- Loginės halucinacijos — modelis daro klaidingas išvadas iš teisingų prielaidų arba pameta loginę giją ilgame samprotavime, ypač matematikoje ar sudėtinguose skaičiavimuose.
- Kontekstinės halucinacijos — kai modeliui pateiki dokumentą ir paprašai jį apibendrinti, bet jis „prideda” detalių, kurių originaliame dokumente nebuvo, nes tos detalės atrodo logiškai tinkamos pagal bendrą kontekstą.
- Kodo halucinacijos — programuotojams gerai pažįstamas atvejis, kai modelis sugalvoja neegzistuojančią bibliotekos funkciją ar parametrą, nes ta funkcija „turėtų” egzistuoti pagal panašių bibliotekų logiką.
Paskutinis punktas ypač įdomus, nes jis parodo, kaip halucinacijos gimsta iš pernelyg gerų apibendrinimo gebėjimų. Modelis matė tūkstančius Python bibliotekų su panašia struktūra, todėl jis „nuspėja” funkciją, kuri logiškai turėtų egzistuoti konkrečioje bibliotekoje, net jei realybėje jos autoriai tokios funkcijos niekada neįgyvendino.
Kodėl treniravimo procesas iš dalies skatina šį elgesį
Yra dar viena, mažiau akivaizdi priežastis, kodėl modeliai linkę „spėlioti” vietoj to, kad pripažintų nežinojimą. Treniravimo ir vertinimo procesai, ypač tie, kurie remiasi žmonių atsiliepimais (RLHF), dažnai netiesiogiai baudžia modelį už atsakymą „nežinau”. Įsivaizduok testą, kuriame už teisingą atsakymą gauni tašką, o už tuščią lauką — nulį. Tokioje sistemoje racionaliausia strategija visada yra bandyti atsakyti, net jei tikimybė teisingai atspėti nedidelė, nes „nežinau” garantuotai duoda nulį, o spėjimas bent jau turi šansą.
Panašus mechanizmas veikia ir su kalbos modeliais. Jei per treniravimą modeliai, kurie drąsiai (bet klaidingai) atsako, gauna geresnius vertinimus nei tie, kurie sako „negaliu būti tikras”, sistema pamažu išmoksta, kad drąsa apsimoka labiau nei atsargumas. Tai nėra sąmoningas sprendimas modelio pusėje — tai tiesiog optimizacijos proceso pasekmė.
Kodėl RAG ir kiti triukai tik iš dalies padeda
Pastaraisiais metais populiariausias būdas kovoti su halucinacijomis — vadinamasis RAG (Retrieval-Augmented Generation), kai modelis prieš atsakydamas gauna prieigą prie realių dokumentų ar duomenų bazės ir savo atsakymą grindžia jais, o ne vien treniravimo metu įsimintais duomenimis. Tai realiai sumažina klaidų kiekį, ypač kai kalbama apie faktus, kurie yra konkrečiuose dokumentuose.
Bet reikia suprasti ribas. RAG sumažina tikimybę, kad modelis sugalvos faktą iš nieko, bet neišsprendžia problemos iki galo. Modelis vis tiek gali neteisingai interpretuoti gautą dokumentą, sumaišyti kelis šaltinius į vieną, arba tiesiog „ištęsti” tekstą detalėmis, kurių dokumente nebuvo, jei to reikalauja atsakymo forma. Be to, jei paieškos sistema grąžina netikslią ar nerelevantišką informaciją, modelis su tuo pačiu pasitikėjimu ją pateiks kaip teisingą — šiukšlės įvestyje, šiukšlės išvestyje niekur nedingo.
Kitas dažnai minimas metodas — grandininis samprotavimas (chain-of-thought), kai modelis „mąsto garsiai” prieš pateikdamas galutinį atsakymą. Tai padeda su loginėmis klaidomis, nes modelis turi daugiau žingsnių patikrinti savo paties logiką, bet nepadeda su faktinėmis halucinacijomis, jei pati bazinė žinių bazė yra ribota ar klaidinga.
Praktika: ką daryti, kai reikia pasitikėti atsakymu
Dirbant su šiais įrankiais kasdien, susiformavo keletas gana paprastų taisyklių, kurios realiai sumažina riziką gauti klaidingą informaciją ir jos nepastebėti:
- Prašyk nurodyti šaltinius ir juos tikrink. Jei modelis mini konkretų straipsnį, teisės aktą ar tyrimą — patikrink, ar jis apskritai egzistuoja. Ypač akademinėje ar teisinėje srityje sugalvotos citatos yra dažna problema.
- Naudok RAG sistemas, kai dirbi su konkrečiais dokumentais. Jei reikia analizuoti sutartį, techninę dokumentaciją ar vidinius įmonės failus, geriau pateikti tuos dokumentus tiesiogiai modeliui, o ne pasikliauti jo „atmintimi” apie panašius atvejus.
- Skaidyk sudėtingas užduotis į mažesnius žingsnius. Kuo ilgesnis ir sudėtingesnis atsakymas reikalaujamas iš karto, tuo didesnė tikimybė, kad kažkur atsiras klaida. Prašydamas žingsnis po žingsnio, gali lengviau pastebėti, kur logika nutrūko.
- Būk įtaresnis su labai konkrečiais skaičiais ir datomis. Bendro pobūdžio teiginiai apie žinomus dalykus paprastai patikimesni nei tiksli statistika, konkretūs procentai ar smulkios techninės detalės, kurių negali greitai patikrinti.
- Perprašyk kitaip suformulavęs klausimą. Jei gauni tą patį faktą pateikus klausimą kitu būdu, tikimybė, kad jis teisingas, didesnė. Jei atsakymai skiriasi arba prieštarauja vienas kitam — tai raudona vėliavėlė.
- Kodo generavime visada tikrink importus ir API. Paleisk kodą lokaliai arba bent patikrink dokumentacijoje, ar minima funkcija tikrai egzistuoja, ypač dirbant su mažiau populiariomis bibliotekomis.
Verta paminėti ir tai, kad naujesni modeliai (ypač tie, kurie specialiai treniruoti su vadinamaisiais „confidence calibration” metodais) pamažu geriau atpažįsta situacijas, kai reikėtų pasakyti „nesu tikras” vietoj drąsaus spėjimo. Bet tai vis dar toli gražu nėra išspręsta problema — net pažangiausi modeliai kartais su tuo pačiu pasitikėjimu klysta ir teisingai atsako.
Ką daryti su mašina, kuri nemoka sakyti „nežinau”
Jei iš viso to reikėtų išsinešti vieną mintį, tai būtų ši: kalbos modelis nėra žinių bazė, jis yra teksto generatorius, kuris labai gerai imituoja žinių turėjimą. Šis skirtumas atrodo subtilus, bet praktikoje jis lemia visą požiūrį į tokius įrankius. Modelis nekaupia faktų taip, kaip enciklopedija — jis kaupia raštingumo šablonus, kalbos struktūras, samprotavimo modelius. Faktinis tikslumas yra šalutinis produktas, ne pagrindinis tikslas.
Tai nereiškia, kad šie įrankiai nenaudingi — priešingai, kai suprasi jų ribas, jie tampa daug vertingesni, nes žinai, kur galima pasitikėti aklai, o kur būtinai reikia patikrinimo sluoksnio. Kūrybinėse užduotyse, idėjų generavime, kalbos redagavime ar bendrų koncepcijų paaiškinime halucinacijos rizika praktiškai neturi reikšmės. Bet teisiniuose dokumentuose, medicininėje informacijoje, tiksliuose skaičiavimuose ar akademinėse citatose kiekvienas atsakymas turi būti traktuojamas kaip hipotezė, kurią reikia patikrinti, o ne kaip galutinė tiesa.
Ateityje tikriausiai matysime vis geresnius mechanizmus, kurie padės modeliams atskirti, kada jie tikrai „žino” (nes informacijos treniravimo duomenyse buvo daug ir ji nuosekli) nuo situacijų, kai jie tiesiog spėlioja pagal panašumą. Bet kol tas mechanizmas netaps patikimas šimtu procentų — o tikriausiai jis niekada netaps, nes pati architektūra to nenumato — atsakomybė už faktų tikrinimą liks žmogaus pusėje. Ir tai, tiesą sakant, nėra blogai. Sveikas skepticizmas prieš bet kokį informacijos šaltinį — ar tai būtų kalbos modelis, ar internetinis forumas, ar net spaudos leidinys — niekada nebuvo pertekliaus dalykas.
