DI haliucinacijos: kas tai ir kaip jų išvengti?

Kas yra DI haliucinacijos?

Pavyzdžiui, paprašę DI pateikti 20 augančias pajamas gaunančių Vilniaus įmonių Juridinių asmenų registro kodus, galime gauti iš pažiūros logišką ir išsamų sąrašą. Tačiau visi jame nurodyti kodai gali būti išgalvoti.

Būtent šis tariamas logiškumas ir yra būdingas haliucinacijoms: atsakymai atrodo įtikinami, o DI nerodo nė menkiausios abejonės. Todėl kalbos modelių sąsajose ir primenama tikrinti pateikiamus skaičius bei faktus.

Kodėl kyla DI haliucinacijos?

Taigi haliucinacijos dažniausiai kyla trimis atvejais:

• trūksta duomenų (pagrindinė priežastis – modelis ima spėlioti);
• užklausa netiksli (modelis pats užpildo spragas);
• užduotis pernelyg sudėtinga (modelis mėgina viską atlikti iš karto).

Problema susijusi ne vien su kalbos modeliais, bet ir su jų prieiga prie duomenų. Todėl haliucinacijos nėra visiškai atsitiktinis ar nekontroliuojamas reiškinys – jas lemia aplinkybės, kurias galima keisti.

Kaip sumažinti DI haliucinacijų riziką?

DI haliucinacijų galima išvengti suteikus modeliui tiesioginę prieigą prie struktūruotų duomenų. Tokioje aplinkoje kalbos modeliai geriausiai interpretuoja informaciją, priima sprendimus ir daro išvadas.

Tam skirtus tris toliau aptariamus būdus galima rinktis pagal techninius poreikius ir galimybes.

Duomenų failo paruošimas

Paruošti duomenys – paprasčiausias būdas praktiškai spręsti haliucinacijų problemą. Taip DI paliekama gerokai mažiau erdvės „kurti savo istorijas“.

Pradedantieji dažnai tikisi, kad kalbos modelis vienu metu bus paieškos sistema, ETL duomenų apdorojimo įrankis ir duomenų rinkimo iš svetainių sistema. Tačiau jei užduočiai reikia surinkti, išvalyti ir standartizuoti daug duomenų, galima viršyti modelio konteksto lango ribas, o haliucinacijų rizika smarkiai išauga.

Todėl duomenų rinkimo procesą verta suskaidyti į kelias mažesnes užklausas ir nuolat tikrinti, ar DI pateikia teisingą informaciją. Tai gali skambėti nuobodžiai ir užimti laiko, tačiau taip sukuriamas tvirtas pagrindas, leidžiantis kalbos modeliams atskleisti tikrąjį potencialą – dirbti su turimais duomenimis.

API naudojimas

Prisijungimas per API – pažangesnis šios problemos sprendimas: jis suteikia greitesnę, lengviau plečiamą prieigą prie duomenų, kurie gali būti nuolat atnaujinami. Jei paruoštas duomenų failas primena paduotą kibirą vandens, API – atsuktą čiaupą.

Paieška, kuria naudojasi ChatGPT, Claude ar Gemini, nedaug skiriasi nuo žmogaus atliekamos paieškos. Kalbos modeliai peržiūri turinį išoriniuose šaltiniuose, pavyzdžiui, Reddit ar Wikipedia, ir pateikia atsakymą.

Tačiau taip ieškant nėra garantijos, kad rastas turinys teisingas ir aktualus. Skirtinguose šaltiniuose gali būti taikomi nevienodi standartai, nurodomos skirtingos datos, pasitaikyti žmogiškų klaidų ar subjektyvių nuomonių. API padeda įveikti šį trūkumą, suteikdama programinę prieigą prie nuoseklaus, sutvarkytų duomenų šaltinio.

Pavyzdžiui, Monitly API suteikia prieigą prie viso pasaulio statistikos tiesiogiai jungdamasi prie tokių institucijų kaip Valstybės duomenų agentūra, Eurostat, World Bank, WHO ir IMF šaltinių. Dėl to DI nereikia ieškoti informacijos įvairiose svetainėse: jis pateikia tiesioginę užklausą API ir gauna naujausią prieinamą rezultatą, kurį lengviau analizuoti bei interpretuoti.

Prisijungimas per MCP

Prijungus DI per MCP (Model Context Protocol), kalbos modeliai gauna tiesioginę prieigą prie failų, skaičiuoklių, programinio kodo ar programų. Tai gerokai sumažina haliucinacijų riziką, nes modeliui pateikiami duomenys, su kuriais jis gali dirbti.

Pavyzdžiui, įmonių duomenų platforma Compabase siūlo MCP sąsają, leidžiančią DI greitai patikrinti vietos įmonių duomenis. Dabar, paprašę pateikti 20 augančias pajamas gaunančių Vilniaus įmonių Juridinių asmenų registro kodus, galime gauti ne išgalvotą informaciją, o nuoseklų, patikrintą sąrašą. Skirtumas nėra tas, kad modelis staiga tapo „protingesnis“. Anksčiau jis tiesiog neturėjo prieigos prie šių duomenų, o dabar gali pateikti paprastą SQL užklausą duomenų bazei ir gauti rezultatą.

Kitaip tariant:

Be MCP:

• dalis įmonių gali neegzistuoti;
• finansiniai duomenys gali būti atsitiktiniai;
• juridinių asmenų kodai gali būti išgalvoti.

Su MCP:

• modelis pateikia užklausą duomenų bazei;
• gauna konkrečius įrašus;
• užklausos rezultatas yra apibrėžtas.

Žinoma, vien tai haliucinacijų visiškai nepanaikina, jei ir toliau reikalaujame pernelyg sudėtingai apdoroti ir jungti duomenis. Tačiau sukūrus aplinką, kurioje duomenys jau struktūruoti, atnaujinami realiuoju laiku, o interpretavimo laisvė ribota, DI mažiau spėlioja ir daugiau analizuoja tai, kas iš tiesų egzistuoja.