Ģeneratīvais mākslīgais intelekts var dažu sekunžu laikā apkopot dokumentu, sagatavot klientam atbildes melnrakstu vai palīdzēt darbiniekam atrast vajadzīgo procedūru. Tas pats rīks var pārliecinoši nosaukt neesošu līguma punktu, sajaukt cenu nosacījumus vai izdomāt avotu. Valoda izklausās profesionāla, tādēļ kļūdu ne vienmēr pamana uzreiz.
Īsā atbilde ir šāda: valodas modelis nav uzņēmuma faktu datubāze. Tas ģenerē ticamu teksta turpinājumu, balstoties modelī apgūtajās sakarībās un konkrētajā brīdī pieejamajā kontekstā. Ja informācijas trūkst, jautājums ir neskaidrs vai sistēma nav iemācīta apstāties, modelis var aizpildīt robu ar ticamu, bet nepareizu versiju.
Halucināciju risku nevar pilnībā novērst ar vienu “perfektu” uzvedni. To samazina sistēma: skaidri lietošanas gadījumi, apstiprināti datu avoti, noteikumi par nenoteiktību, pārbaudāmas atsauces, cilvēka kontrole svarīgos lēmumos, regulāri testi un kļūdu uzskaite. Uzņēmumam jāvada ne tikai modelis, bet visa darba plūsma ap to.
Kas ir MI halucinācija
MI halucinācija ir pārliecinoši pasniegta, taču kļūdaina, izdomāta vai dotajam kontekstam neatbilstoša atbilde. NIST savā ģeneratīvā MI riska profilā lieto terminu “confabulation” un norāda, ka šāds saturs var būt ne tikai faktiski nepareizs, bet arī pretrunā lietotāja ievadei vai iepriekš teiktajam.
Uzņēmuma vidē tas var izskatīties ļoti ikdienišķi:
klientu atbalsta asistents izdomā atlaidi, kas nav cenu politikā;
iekšējais zināšanu palīgs atsaucas uz novecojušu procedūru;
pārdošanas rīks sajauc divu produktu funkcijas;
dokumentu kopsavilkums izlaiž būtisku izņēmumu;
analīzē tiek minēta neesoša datu kolonna vai nepareizi interpretēts rādītājs;
atbildei pievienota ticami noformēta, bet neeksistējoša atsauce.
Ne katra nepareiza atbilde ir tikai paša modeļa “izdomājums”. Kļūdas avots var būt novecojis dokuments, nekorekta integrācija, nepareizi atlasīts fragments, lietotāja neskaidrs jautājums vai automatizācija, kas atbildi nosūta bez pārbaudes. Tāpēc diagnostikā jāvērtē visa sistēma.
Kāpēc valodas modelis var kļūdīties
Modelis prognozē valodu, nevis pārbauda patiesību
Lielais valodas modelis mācās paredzēt, kāds vārds vai teksta elements visdrīzāk seko iepriekšējam kontekstam. Šis mehānisms ļauj radīt plūstošu, gramatiski pareizu tekstu, bet plūdums nav faktu garantija. Retu faktu, specifisku nosaukumu, precīzu datumu vai uzņēmuma iekšējās informācijas gadījumā ticamākais formulējums var nebūt pareizā atbilde.
Arī spēcīgs modelis nevar droši zināt informāciju, kas tam nav pieejama. Ja tiek prasīta šodienas noliktavas atlikuma situācija, bet sistēma nav savienota ar noliktavas datiem, pareizā rīcība būtu atzīt ierobežojumu. Ja darba plūsma mudina vienmēr dot konkrētu atbildi, rodas minējums.
Uzņēmuma konteksts nav dots vai ir pārāk plašs
Frāze “sagatavo piedāvājumu mūsu klientam” modelim nepasaka, kuru cenu lapu izmantot, kādi ir apmaksas nosacījumi, kas drīkst saņemt atlaidi un kura dokumenta versija ir spēkā. Darbinieks šo kontekstu var zināt no pieredzes; MI to nezina, ja vien informācija nav pievienota jautājumam vai droši iegūta no apstiprinātas sistēmas.
Pretēja problēma rodas, ja modelim vienlaikus iedod pārāk daudz materiāla. Starp desmitiem dokumentu var būt dublikāti, pretrunas un senas versijas. Liels konteksts pats par sevi negarantē, ka atbilde balstīsies pareizajā fragmentā.
Avoti ir novecojuši, pretrunīgi vai slikti strukturēti
Ja uzņēmuma zināšanu bāzē ir trīs failu versijas ar nosaukumiem “gala”, “gala-jauns” un “gala-īstais”, MI nevar uzticami noteikt, kura no tām ir oficiāla. Tas pats attiecas uz dokumentiem bez īpašnieka, apstiprināšanas datuma vai spēkā esamības termiņa.
Šeit halucināciju risks patiesībā atklāj informācijas pārvaldības problēmu. Modelis var ātri izgaismot nekārtību, bet nevar tās vietā pieņemt organizācijas lēmumu par to, kurš avots ir patiesais.
Informācijas atlase var atrast nepareizo fragmentu
Uzņēmumu MI risinājumos bieži izmanto meklēšanu papildinātu ģenerēšanu jeb RAG. Sistēma vispirms atrod jautājumam atbilstošus dokumentu fragmentus un pēc tam lūdz modelim sagatavot atbildi, balstoties tajos.
RAG samazina vajadzību paļauties uz modeļa vispārējām zināšanām, tomēr tas nav automātisks kvalitātes zīmogs. Meklēšana var neatpazīt nozares terminus, atnest fragmentu bez vajadzīgā izņēmuma vai dot priekšroku vecākam dokumentam. Ja atlasītais pamats ir nepareizs, arī skaisti noformēta atbilde būs nepareiza.
Uzdevums vienā solī prasa pārāk daudz
Pieprasījums vienlaikus izlasīt līgumu, noteikt juridisko risku, aprēķināt finansiālo ietekmi un uzrakstīt gala lēmumu apvieno vairākas atšķirīgas darbības. Kļūdas kļūst grūtāk pamanāmas, jo nav redzams, kurā posmā tās radušās.
Drošāka pieeja ir sadalīt darbu: iegūt faktus, norādīt avotus, identificēt nenoteiktību, veikt aprēķinu ar atsevišķu rīku un tikai tad sagatavot skaidrojumu. Šāda arhitektūra ir pārbaudāma.
Lietotāji uzticas pārliecinošam tonim
Valodas modelis var kļūdīties bez vilcināšanās pazīmēm. Cilvēks nereti sajauc labi uzrakstītu atbildi ar pārbaudītu atbildi, īpaši ja tā apstiprina viņa sākotnējo pieņēmumu. NIST šo problēmu saista arī ar pārmērīgu paļaušanos uz automatizāciju.
Tādēļ risinājumā nepietiek ar tehnisku precizitāti. Interfeisam un darba kārtībai jāparāda avoti, informācijas datums, ierobežojumi un brīži, kad nepieciešams eksperta apstiprinājums.
Kāpēc ar labāku uzvedni vien nepietiek
Laba uzvedne palīdz: tā var noteikt lomu, uzdevumu, atbildes formātu, atļautos avotus un rīcību nepietiekamas informācijas gadījumā. Tomēr uzvedne nevar atjaunot novecojušu cenu lapu, salabot bojātu integrāciju vai garantēt, ka dokumentu meklētājs atradis pareizo fragmentu.
Ja MI tiek iesaistīts procesu automatizācijā, jāprojektē visa ķēde:
kur rodas jautājums;
no kurienes tiek iegūti fakti;
ko modelis drīkst secināt;
kā atbilde tiek pārbaudīta;
kas notiek, ja informācijas nepietiek;
vai atbildi tikai parāda darbiniekam vai automātiski nosūta klientam.
Jo lielāka kļūdas ietekme, jo mazāk procesa drīkst balstīt tikai uz brīvi ģenerētu tekstu.
Praktiska sistēma halucināciju riska samazināšanai
Sāciet ar lietošanas gadījuma riska līmeni
Nav vajadzīga vienāda kontrole bloga ideju ģenerēšanai un klienta līguma interpretācijai. Katram lietošanas gadījumam novērtējiet kļūdas sekas.
Zema riska uzdevumi ir idejas, valodas uzlabojumi un melnraksti, kurus cilvēks pārskata. Vidēja riska uzdevumi var ietvert iekšējo dokumentu meklēšanu vai atbilžu sagatavošanu darbiniekam. Augsts risks rodas, ja atbilde ietekmē naudu, tiesības, veselību, drošību, personāla lēmumus vai tiek automātiski nosūtīta ārējam saņēmējam.
Šis iedalījums nosaka, cik stingri avoti, testi un apstiprinājumi nepieciešami. Dažus augsta riska uzdevumus nav lietderīgi nodot ģeneratīvam MI bez kvalificēta speciālista iesaistes.
Izveidojiet vienu apstiprinātu zināšanu pamatu
Pirms pievienot MI, sakārtojiet dokumentus. Katram būtiskam avotam vajadzīgs īpašnieks, versija, apstiprināšanas datums un statuss. Novecojušās versijas jāarhivē tā, lai meklēšana tās nepasniegtu kā aktuālas.
Zināšanu bāzei nav jābūt milzīgai. Neliels, rūpīgi atlasīts dokumentu kopums bieži ir noderīgāks par visu uzņēmuma failu automātisku indeksēšanu. Atļaujiet sistēmai meklēt tikai tajos avotos, kuri ir piemēroti konkrētajam uzdevumam un lietotāja tiesībām.
Pieprasiet atbildi tikai no dotajiem avotiem
Atbildes noteikumos skaidri pasakiet, ka modelis drīkst izmantot tikai atrastos vai pievienotos avotus. Ja tajos atbildes nav, sistēmai jāpasaka, ka informācija nav atrasta, jāuzdod precizējošs jautājums vai jānodod uzdevums cilvēkam.
Noderīgs atbildes līgums var prasīt:
īsu secinājumu;
izmantotos faktus un atsauces uz avota fragmentiem;
neatrisinātos jautājumus;
pārliecības vai riska marķējumu;
aizliegumu izdomāt trūkstošus datus;
norādi, kam atbilde jāapstiprina.
Ar frāzi “esi precīzs” nepietiek. Sistēmai jāzina, ko darīt, ja precīza atbilde nav iespējama.
Ļaujiet modelim atteikties un prasīt precizējumu
MI sistēma, kurai vienmēr jāatbild, neizbēgami tiek mudināta minēt. OpenAI pētījuma skaidrojums par halucinācijām uzsver, ka vērtēšana tikai pēc pareizo atbilžu skaita var atalgot minēšanu, nevis godīgu nenoteiktības atzīšanu.
Uzņēmuma kvalitātes rādītājos kļūdainai pārliecinošai atbildei jābūt dārgākai par korektu atteikšanos. Frāze “avotos nav pietiekamas informācijas” var būt ļoti kvalitatīvs rezultāts, ja alternatīva ir izdomāts fakts.
Atdaliet ģenerēšanu no aprēķiniem un darbībām
Valodas modelim var uzticēt skaidrojumu, bet precīzu cenu, nodokļa summu, termiņu vai atlikumu labāk iegūt no determinēta avota: datubāzes, kalkulatora, ERP vai citas biznesa sistēmas. Modelis var izsaukt šo rīku un izskaidrot rezultātu, taču nedrīkst aizstāt pašu aprēķinu ar teksta prognozi.
Tāpat automātiskai darbībai jābūt ar validāciju. Pirms nosūtīt e-pastu, mainīt klienta statusu vai izveidot rēķinu, sistēmai jāpārbauda obligātie lauki, atļaujas un biznesa noteikumi.
Pievienojiet cilvēka pārbaudi īstajā vietā
“Cilvēks procesā” nenozīmē, ka darbiniekam formāli jānospiež poga zem katras atbildes. Pārbaudei jābūt jēgpilnai. Pārbaudītājam jāredz avots, modeļa secinājums, iespējamā nenoteiktība un tas, kas tieši tiks darīts pēc apstiprināšanas.
Obligāts apstiprinājums ir pamatots, ja rezultāts rada finansiālas vai juridiskas saistības, skar sensitīvus datus, ietekmē cilvēka tiesības vai nonāk publiskā telpā. Zemāka riska melnrakstiem var pietikt ar izlases kontroli.
Testējiet ar sava uzņēmuma reāliem jautājumiem
Publisks modeļa kvalitātes vērtējums nepasaka, vai sistēma pareizi atbildēs uz jūsu cenu, piegādes un procedūru jautājumiem. Izveidojiet pārbaudes kopu ar tipiskiem, sarežģītiem un apzināti maldinošiem jautājumiem.
Kopā vajadzīgi arī gadījumi, kuros pareizā atbilde ir “informācijas nepietiek”. Pārbaudiet faktu pareizību, avota atbilstību, atteikšanās kvalitāti, sensitīvu datu aizsardzību un to, vai darbība tika nodota cilvēkam. Testi jāatkārto pēc modeļa, uzvednes, dokumentu vai integrāciju maiņas.
Reģistrējiet kļūdas un mācieties no tām
Ja lietotājs pamana nepareizu atbildi, ar manuālu izlabošanu vien nepietiek. Jāsaglabā jautājums, izmantotā avota versija, atrastie fragmenti, modeļa versija, atbilde un veiktā darbība, ciktāl to atļauj datu aizsardzības prasības.
Kļūdas pēc tam var iedalīt kategorijās: trūka avota, meklēšana izvēlējās nepareizu dokumentu, uzvedne bija neskaidra, modelis neievēroja noteikumus, nedarbojās integrācija vai lietotājs izmantoja sistēmu neparedzētam mērķim. Šāda uzskaite parāda, kurš labojums dos reālu efektu.
Nosakiet sistēmas īpašnieku un izmaiņu kārtību
MI pilotprojekts var darboties labi sākumā un pakāpeniski zaudēt kvalitāti, ja mainās dokumenti, modelis vai uzņēmuma process. Tāpēc jābūt vienai atbildīgai lomai, kas uzrauga avotus, testu rezultātus, piekļuves tiesības un incidentus. Tas nenozīmē, ka visu dara viens cilvēks; viņš koordinē satura īpašniekus, IT un konkrētās jomas ekspertus.
Arī katrai izmaiņai vajadzīga pārbaudāma kārtība. Ja tiek nomainīts modelis, papildināta uzvedne, pievienoti dokumenti vai mainīta integrācija, pirms plašas palaišanas atkārto kritiskos testus. Pretējā gadījumā tehniski neliels uzlabojums var negaidīti pasliktināt atbildes citā scenārijā.
Ko mērīt pēc MI ieviešanas
Vienīgais rādītājs nedrīkst būt ātrāka atbilde. Ātri radīta kļūda var izmaksāt vairāk nekā lēnāks, pārbaudīts process.
Praktiskā uzraudzībā vērtējiet:
faktiski pareizo atbilžu īpatsvaru noteiktā testu kopā;
neatbalstītu apgalvojumu un nepareizu atsauču skaitu;
korektu atteikšanos, kad avotos nav atbildes;
gadījumus, kad nepieciešama cilvēka iejaukšanās;
kļūdu sadalījumu pa cēloņiem un lietošanas gadījumiem;
laiku no kļūdas pamanīšanas līdz labojumam;
dokumentu aktualitāti un īpašnieku atbildību.
Rādītāji jāskata atsevišķi katram lietošanas gadījumam. Vidējais precizitātes skaitlis var slēpt faktu, ka sistēma labi raksta kopsavilkumus, bet slikti atbild uz jautājumiem par izņēmumiem.
Minimālais ieviešanas plāns uzņēmumam
Pirmajā posmā izvēlieties vienu šauru uzdevumu, kuram ir skaidri avoti un kontrolējama kļūdas ietekme. Nosakiet, ko MI drīkst darīt un ko nedrīkst.
Otrajā posmā sakārtojiet avotus un izveidojiet 30–50 reprezentatīvus testa jautājumus, tostarp jautājumus bez atbildes. Definējiet pieņemšanas kritērijus un eskalācijas noteikumus.
Trešajā posmā palaidiet risinājumu ierobežotai lietotāju grupai. Atbildes sākumā izmantojiet kā melnrakstus, nevis automātiskus gala lēmumus. Reģistrējiet labojumus un meklējiet atkārtojošos kļūdu cēloņus.
Ceturtajā posmā automatizāciju paplašiniet tikai tad, kad testi un reālā lietošana parāda stabilu rezultātu. Saglabājiet iespēju sistēmu apturēt, atgriezties pie drošas darba plūsmas un pārskatīt notikušo.
Secinājums
MI nepareiza atbilde nav tikai modeļa kvalitātes jautājums. Tā ir modeļa, datu, meklēšanas, uzvednes, integrāciju, lietotāja un uzņēmuma kontroles kopējais rezultāts. Tāpēc risinājums nav viens universāls prompts.
Droša ieviešana sākas ar šauru lietošanas gadījumu un skaidru atbildību. Modelim dod apstiprinātus avotus, māca atzīt nenoteiktību, precīzus aprēķinus atstāj pārbaudāmiem rīkiem, bet nozīmīgus lēmumus — kompetentam cilvēkam. Kļūdas tiek testētas, reģistrētas un izmantotas sistēmas uzlabošanai.
Uzņēmumam nav jāgaida MI, kas nekad nekļūdās. Tam jāizveido process, kurā kļūda tiek retāk radīta, ātrāk pamanīta un nevar nekontrolēti pārvērsties klientam nosūtītā solījumā, finanšu zaudējumā vai nepareizā vadības lēmumā.
