Dokumentų įkėlimas AI pokalbių bote: failų patikra, duomenų apsauga ir perdavimas operatoriui
Failo įkėlimui svetainės pokalbių bote neužtenka vien sąvaržėlės mygtuko. Šis gidas sujungia aiškias ribas, techninę patikrą, suprantamus būsenos pranešimus ir saugų perdavimą.
Įkėlimo piktograma pokalbio lange atrodo paprastai: pasirenki failą, užduodi klausimą, gauni atsakymą. Tačiau techniškai ir turinio prasme čia prasideda atskiras procesas. Dokumente gali būti asmens duomenų, aktyvaus turinio, manipuliuotų failo struktūrų, neįskaitomų skenuotų kopijų ar nurodymų, kurių kalbos modelis neturėtų laikyti patikimais faktais. Todėl dokumentų įkėlimui AI pokalbių bote reikia aiškių ribų prieš perdavimą, kelių patikros etapų po jo ir suprantamos išeities, kai kažkas neveikia.
Šis gidas skirtas svetainių, klientų aptarnavimo ir produktų komandoms. Jame aprašoma ne pavienė kurio nors gamintojo funkcija, o patikima vizija: žmonės prieš įkėlimą žino, kas leidžiama; sistema atskiria priėmimą, saugumo patikrą ir turinio vertinimą; klaidos išlieka suprantamos; o jautrūs atvejai kontroliuojamai perduodami žmogui.
Įkėlimas privalo turėti aiškų tikslą
Pradėkite ne nuo kuo ilgesnio palaikomų formatų sąrašo, o nuo kelių konkrečių užduočių. Ar pokalbių botas turi paaiškinti sąskaitos duomenis, apibendrinti techninius dokumentus, ar papildyti pagalbos užklausą ekrano nuotrauka? Kiekvienai užduočiai turi būti aišku, koks turinys reikalingas, kokį sprendimą sistema gali priimti ir kada būtina žmogaus patikra.
Šis tikslo apibrėžimas neleidžia įkėlimo funkcijai tapti bendra dokumentų saugykla. Tai taip pat padeda kurti sąsają: prekių grąžinimo kvitui reikia kitokių nuorodų ir saugojimo taisyklių nei viešam produkto aprašymui žinių bazėje. Esamas gidas apie mokymą naudojant DUK, dokumentus ir svetainės turinį nagrinėja atitinkamai kuruojamą žinių bazę; čia gi kalbama apie failus, kuriuos lankytojai pateikia vykstančio pokalbio metu.
Padarykite matomus leidžiamus failų tipus, dydžius ir kiekius
Žmonės turėtų matyti taisykles prieš atsidarant failo pasirinkimo langui: leidžiamus Formatus, maksimalų dydį, maksimalų kiekį ir tai, ar priimami slaptažodžiu apsaugoti ar suspausti failai. Naudokite baltąjį sąrašą (positivlįstę), kuris leidžia tik verslui būtinus Formatus. „Visi dokumentai“ nėra naudingas reikalavimas.
HTML atributas accept pagerina pasirinkimą naršyklėje, tačiau nėra saugumo priemonė. MDN aiškiai pabrėžia, kad vartotojai dažnai gali apeiti pasirinkimo apribojimą, todėl patikra turi būti atliekama serveryje. Taigi sąsaja gali siūlyti tinkamus failų plėtinius, o serveris nepriklausomai vertina plėtinį, praneštą MIME tipą, tikrąją parašą ir struktūrą.
Neperimkite failų pavadinimų ir metaduomenų nepatikrinę
Originaliame pavadinime gali būti specialiųjų simbolių, kelio elementų, labai ilgų simbolių eilučių arba jautrios informacijos. Vidinimui saugojimui sistema turėtų priskirti atskirą atsitiktinį identifikatorių, o matomą pavadinimą laikyti tik išvalyta rodymo informacija. Taip pat įterptieji metaduomenys gali turėti vardus, įrenginio informaciją ar vietos duomenis. Ar šie duomenys reikalingi, turi sekti iš tikslo.
OWASP File Upload Cheat Sheet be kitų dalykų rekomenduoja baltąjį plėtinių sąrašą, nepriklausomą tipo patikrą, saugius failų pavadinimus, dydžio ribas, saugojimą už „webroot“ ribų ir apsaugą nuo neautorizuotų įkėlimų. Jokios pavienės patikros neužtenka; prasminga naudoti mažų, suprantamų kontrolės veiksmų grandinę.
Atskirskite priėmimą, saugumo patikrą ir vertinimą
Priimtas failas neturėtų būti iškart prieinamas pokalbių lange. Patikimas procesas turi bent tris būsenas: gauta, tikrinama ir patvirtinta vertinimui. Patikros metu failas yra izoliuotoje zonoje. Tik praėjus patikrą, teksto ištraukimo funkcija gauna prieigą. Reikėtų vengti tiesioginių viešų URL ar nuspėjamų saugojimo kelių.
Kenkėjiško kodo ir struktūros patikra
Priklausomai nuo rizikos, į procesą įtraukiama virusų patikra arba izoliuota aplinka (sandbox), parašo patikra, o atitinkamiems „Office“ ar PDF failams – „Content Disarm and Reconstruction“. Archyvams, įterptiems failams ir itin suspaustam turiniui reikia atskirų ribų, nes jie gali eikvoti resursus arba pulti analizatorius (parserius). Skeneriai ir bibliotekos turi būti atnaujinti ir sukonfigūruoti taip, kad laiko limitas (timeout) ar analizatoriaus klaida nebūtų laikoma patvirtinimu.
Teksto ištraukimas yra atskira kokybės būsena
Saugus failas vis tiek gali būti netinkamas naudoti: pakreiptas skenas, nuotrauka su atspindžiais, ranka rašytas užrašas arba PDF be ištraukiamo teksto sluoksnio. Todėl sistema turėtų atskirai pranešti, ar failas buvo saugiai priimtas ir ar turinys galėjo būti pakankamai perskaitytas. Žema ištraukimo kokybė neturi būti slepiama išgalvotais papildymais.
Formuluokite klaidas tiksliai ir suteikite veiksmų galimybę
„Įkėlimas nepavyko“ nepaaiškina, ką daryti toliau. Geriau naudoti atskiriamus pranešimus: Formatas nepalaikomas, failas per didelis, aptikta apsauga slaptažodžiu, saugumo patikra nepavyko, tekstas neįskaitomas arba apdorojimas laikinai nepasiekiamas. Pranešimas neturi atskleisti vidinių skenerio ar infrastruktūros detalių, tačiau turi pasiūlyti saugų ištaisymo būdą.
WCAG 2.2 reikalauja, kad automatiškai aptiktoms įvesties klaidoms būtų pateiktas tekstinis identifikavimas ir aprašymas. Success Criterion 3.3.1 Error Identification paaiškinime pabrėžiama, kad tiesiog iš naujo parodytos formos neužtenka. Pokalbių botui tai reiškia: nurodyti failo pavadinimą arba įkėlimo vietą, paaiškinti klaidą tekstu ir pasiūlyti konkrečią pakeitimo, pašalinimo ar perdavimo galimybę.
Praneškite apie pažangą prieinamu būdu
Dirbant su didesniais failais atsiranda laukimo laikas. Vien tik vizuali pažangos juosta padeda ne visiems. Būsenos pasikeitimai, tokie kaip „Vyksta įkėlimas“, „Saugumo patikra“, „Skaitomas turinys“ ir „Paruošta“, turėtų būti atpažįstami programiškai, be savavališko klaviatūros fokuso perkėlimo. W3C paaiškinime dėl WCAG 4.1.3 Status Messages pažanga, sėkmė ir klaidos aiškiai įvardijamos kaip svarbi būsenos informacija.
Atšaukimo veiksmas turi išlikti pasiekiamas. Po atšaukimo turėtų matytis, ar perdavimas iš tikrųjų buvo sustabdytas ir jau gauta kopija pašalinta. Mobiliesiems įrenginiams failo pavadinimas, pažanga ir pašalinimo mygtukas turi būti išdėstyti taip, kad neuždengtų nei įvesties, nei svarbios navigacijos.
Paaiškinkite duomenų apsaugą prieš įkėlimą
Pranešimas prieš perduodant duomenis turi atsakyti į klausimus: Kam bus naudojamas failas? Kas gali jį matyti? Kiek laiko jis bus saugomas? Ar jo turinys bus naudojamas modeliui gerinti? Kaip failą galima pašalinti? Bendrosios privatumo politikos išlieka svarbios, tačiau nepakeičia kontekstinio pranešimo tiesiogiai prie įkėlimo.
Bendrojo duomenų apsaugos reglamento 5 straipsnis apima tikslo apribojimą, duomenų kiekio sumažinimą ir saugojimo trukmės apribojimą. Praktiškai tai reiškia: reikalauti tik būtinų dokumentų, vengti nereikalingų puslapių ar metaduomenų, nustatyti pagrįstą ištrynimo terminą ir techniškai patikrinti faktinį ištrynimą. Tai nėra individuali teisinė konsultacija; konkrečios pareigos turi būti įvertintos kiekvienam naudojimo atvejui.
Atskirkite viešus pokalbius ir apsaugotus procesus
Viešas svetainės pokalbių botas nėra automatiškai tinkama vieta sutartims, tapatybės dokumentams, sveikatos duomenims ar banko sąskaitų išrašams. Jautrių procesų atveju pokalbis turėtų persikelti į autorizuotą zoną arba nustatytą saugų kanalą. Straipsnis viešas AI pokalbių botas prieš klientų portalą rodo, kaip atskiriama tapatybė ir prieiga prie duomenų.
Net ir prisijungusio vartotojo zonoje galioja mažiausios teisės principas. Pagalbos darbuotojui gali reikėti peržiūrėti kvitą, bet nebūtinai turėti nuolatinę prieigą prie visų paskyros įkeltų dokumentų. Prieiga, atsisiuntimai ir ištrynimai turėtų būti atsekamai registruojami, be reikalo nekopijuojant dokumento turinio į analitikos įvykius.
Dokumento turinys išlieka nepatikimas
Patvirtintas failas yra techniškai apdorotas, tačiau turinio prasme dar nėra autoritingas šaltinis. Dokumentai gali būti pasenę, prieštaringi arba tyčia manipuliuoti. Juose taip pat gali būti nurodymų, skirtų paskatinti modelį nutekinti duomenis ar apeiti taisykles. Todėl ištrauktą tekstą laikykite nepatikimu turiniu (untrusted content), atskirkite jį nuo sistemos taisyklių ir apribokite įrankius bei prieigą prie duomenų.
Gidas apie Prompt Injection apsaugą svetainės pokalbių botuose paaiškina šią ribą RAG ir įrankiams. Įkėlimams papildomai galioja: atsakymai turėtų remtis atpažįstamomis dokumento vietomis, įvardyti neapibrėžtumą ir, priimant kritinius sprendimus, nepildyti trūkstamos informacijos.
Perdavimas operatoriui su mažu konteksto paketu
Perdavimas žmogui yra būtinas, kai saugumo patikra pakartotinai nepavyksta, teksto ištraukimas išlieka nepatikimas, tapatybė ar teisės yra neaiškios arba kai sprendimas priklauso ne pokalbių boto kompetencijai. Perduodama tik ta informacija, kurios žmogui reikia tęsti darbą: užklausa, įkėlimo būsena, saugi nuoroda į dokumentą, konkreti klaidos žinutė, jau patvirtinti duomenys ir pageidaujamas kitas žingsnis.
Failas neturėtų būti papildomai siunčiamas neapsaugotu el. paštu vien todėl, kad pokalbių botas negalėjo jo perskaityti. Suplanuotas perdavimo operatoriui procesas išsaugo kontekstą, atsakingumą ir lūkesčius, be reikalo nedaugindamas jautraus turinio.
Matuokite įvykiais, o ne dokumentų turiniu
Produkto gerinimui dažnai pakanka struktūrizuotų įvykių: pasirinkimas pradėtas, įkėlimas atšauktas, tipas atmestas, pasiekta dydžio riba, saugumo patikra praeita, ištraukimas nepakankamas, pasirinktas perdavimas ir ištrynimas patvirtintas. Failų pavadinimai, ištrauktas tekstas ir asmens duomenys neturėtų patekti į analitiką ar klaidų žurnalus.
Vertinkite sėkmės ir apsaugos rodiklius kartu. Didelis įkėlimų skaičius yra bevertis, jei daug žmonių nesupranta, kokio failo tikimasi, arba jei jautrūs dokumentai patenka į viešą pokalbį. Todėl svarbūs ir pataisymų rodikliai, atsisakymas po privatumo pranešimo, neįskaitomų failų dalis, laikas iki suprantamo klaidos pranešimo ir sėkmingas tęsinys po perdavimo operatoriui.
Kontrolinis sąrašas prieš paleidimą
- Ar kiekvienam įkėlimo atvejui apibrėžtas aiškus tikslas ir leidžiamas dokumento tipas?
- Ar Formatas, dydis, kiekis, apsauga slaptažodžiu ir saugojimo trukmė matomi prieš pasirinkimą?
- Ar serveris tikrina plėtinį, MIME tipą, parašą, struktūrą ir dydžio ribas nepriklausomai nuo naršyklės?
- Ar karantinas, kenkėjiško kodo patikra, ištraukimas ir patvirtinimas įgyvendinti kaip atskiros būsenos?
- Ar žmonės gauna tikslius, prieinamus pažangos ir klaidų pranešimus?
- Ar jautrūs procesai perkeliami į autorizuotą arba žmogaus prižiūrimą kanalą?
- Ar ištrynimo terminas, prieiga, registravimas ir patvirtintas ištrynimas išbandyti praktiškai?
- Ar pokalbių botas laiko ištrauktą tekstą nepatikimu ir cituoja atsekamas vietas?
- Ar analitikoje yra tik būtini įvykiai, o ne failų pavadinimai ar dokumentų turinys?
- Ar perdavimas operatoriui išbandytas su realiomis klaidomis kompiuteriuose ir mobiliuosiuose įrenginiuose?
Išvada: saugus įkėlimas prasideda dar prieš failą
Geras dokumentų įkėlimas parodo ribas prieš pradedant tekėti duomenims. Po to jis atskiria techninį priėmimą, saugumo patikrą, turinio kokybę ir sprendimo priėmimą. Taip AI pokalbių botas gali naudoti dokumentus kaip naudingą pokalbio kontekstą, aklai nepasitikėdamas kiekvienu gautu baitu ar ištrauktu nurodymu.
Norintys sukurti svetainės pokalbių botą ir integruoti tokius procesus į patikimą bendrą architektūrą, gali peržiūrėti ChatReact funkcijas. Planuokite įkėlimą kaip kontroliuojamą paslaugos procesą – su aiškiu sutikimu, suprantama būsena ir saugiu keliu pas žmogų.
Šaltiniai
Paverskite svetainės lankytojus geresniais pokalbiais
Paleiskite DI pokalbių robotą, naudingą nuo pirmos dienos
Mokykite ChatReact su savo svetaine, dokumentais ir patvirtintais faktais, kad lankytojai gautų greitesnius atsakymus, o jūsų komanda sulauktų mažiau pasikartojančių užklausų.
Susiję straipsniai
Tęsti skaitymą
Kaip apmokyti dirbtinio intelekto pokalbių robotą su DUK, dokumentais ir svetainės turiniu
Ką svetainių komandos turi paruošti prieš paleidimą, kad pokalbių robotas išliktų tikslus, naudingas ir suderintas su patvirtinta verslo informacija.
Viešas DI pokalbių botas ir klientų portalas: kaip saugiai atskirti tapatybę ir prieigą prie duomenų
Viešas svetainės pokalbių botas ir autentifikuotas DI pokalbių botas klientų portale reikalauja skirtingų duomenų, įrankių ir saugumo ribų. Šiame vadove pateikiama praktiška architektūra ir testavimo matrica.
„Prompt Injection“ svetainės pokalbių robotuose: RAG, įrankių ir duomenų apsauga
Kaip svetainių komandos riboja tiesioginę ir netiesioginę „prompt injection“ naudodamos atskiras pasitikėjimo zonas, mažiausių privilegijų principą, išvesties tikrinimą ir tikslinius saugumo testus.