Udhëzime sigurie

Modelet gjeneruese të inteligjencës artificiale janë mjete të fuqishme, por ato nuk janë pa kufizimet e tyre. Shkathtësia dhe zbatueshmëria e tyre ndonjëherë mund të çojë në rezultate të papritura, të tilla si rezultate që janë të pasakta, të njëanshme ose fyese. Vlerësimi manual pas përpunimit dhe rigoroz është thelbësor për të kufizuar rrezikun e dëmtimit nga rezultate të tilla.

Modelet e ofruara nga Gemini API mund të përdoren për një shumëllojshmëri të gjerë të aplikacioneve gjeneruese të AI dhe përpunimit të gjuhës natyrore (NLP). Përdorimi i këtyre funksioneve ofrohet vetëm nëpërmjet Gemini API ose aplikacionit të uebit të Google AI Studio. Përdorimi juaj i Gemini API është gjithashtu subjekt i Politikës së Përdorimit të Ndaluar të UA gjeneruese dhe kushteve të shërbimit të Gemini API .

Një pjesë e asaj që i bën modelet e mëdha gjuhësore (LLM) kaq të dobishme është se ato janë mjete krijuese që mund të trajtojnë shumë detyra të ndryshme gjuhësore. Fatkeqësisht, kjo do të thotë gjithashtu se modelet e mëdha të gjuhës mund të gjenerojnë rezultate që nuk e prisni, duke përfshirë tekstin fyes, të pandjeshëm ose faktikisht të pasaktë. Për më tepër, shkathtësia e jashtëzakonshme e këtyre modeleve është gjithashtu ajo që e bën të vështirë të parashikohet saktësisht se çfarë lloj prodhimi të padëshiruar mund të prodhojnë. Ndërsa Gemini API është projektuar duke pasur parasysh parimet e AI të Google , barra i takon zhvilluesve që t'i zbatojnë këto modele me përgjegjësi. Për të ndihmuar zhvilluesit në krijimin e aplikacioneve të sigurta dhe të përgjegjshme, Gemini API ka disa filtrim të integruar të përmbajtjes, si dhe cilësime të rregullueshme sigurie në 4 dimensione të dëmtimit. Referojuni udhëzuesit të cilësimeve të sigurisë për të mësuar më shumë.

Ky dokument ka për qëllim t'ju prezantojë me disa rreziqe sigurie që mund të lindin kur përdorni LLM-të dhe të rekomandojë rekomandimet e reja të dizajnit dhe zhvillimit të sigurisë. (Vini re se ligjet dhe rregulloret mund të vendosin gjithashtu kufizime, por konsiderata të tilla janë përtej qëllimit të këtij udhëzuesi.)

Hapat e mëposhtëm rekomandohen kur ndërtoni aplikacione me LLM:

• Kuptimi i rreziqeve të sigurisë së aplikimit tuaj
• Marrja në konsideratë e rregullimeve për të zbutur rreziqet e sigurisë
• Kryerja e testeve të sigurisë të përshtatshme për rastin tuaj të përdorimit
• Kërkimi i reagimeve nga përdoruesit dhe monitorimi i përdorimit

Fazat e rregullimit dhe testimit duhet të jenë të përsëritura derisa të arrini performancën e përshtatshme për aplikacionin tuaj.

Kuptoni rreziqet e sigurisë së aplikacionit tuaj

Në këtë kontekst, siguria përkufizohet si aftësia e një LLM për të shmangur dëmtimin e përdoruesve të saj, për shembull, duke gjeneruar gjuhë toksike ose përmbajtje që promovon stereotipe. Modelet e disponueshme përmes Gemini API janë projektuar duke pasur parasysh parimet e AI të Google dhe përdorimi i tij i nënshtrohet Politikës Gjenerative të Përdorimit të Ndaluar të UA-së . API ofron filtra të integruar të sigurisë për të ndihmuar në adresimin e disa problemeve të zakonshme të modelit të gjuhës, si gjuha toksike dhe gjuha e urrejtjes, si dhe përpjekjet për përfshirje dhe shmangie të stereotipeve. Megjithatë, çdo aplikacion mund të paraqesë një grup të ndryshëm rreziqesh për përdoruesit e tij. Pra, si pronar i aplikacionit, ju jeni përgjegjës për njohjen e përdoruesve tuaj dhe dëmet e mundshme që mund të shkaktojë aplikacioni juaj, dhe për të siguruar që aplikacioni juaj përdor LLM-të në mënyrë të sigurt dhe me përgjegjësi.

Si pjesë e këtij vlerësimi, duhet të merrni parasysh mundësinë që dëmi mund të ndodhë dhe të përcaktoni seriozitetin dhe hapat e tij zbutës. Për shembull, një aplikacion që gjeneron ese të bazuara në ngjarje faktike do të duhet të jetë më i kujdesshëm në shmangien e dezinformatave, në krahasim me një aplikacion që gjeneron histori fiktive për argëtim. Një mënyrë e mirë për të filluar eksplorimin e rreziqeve të mundshme të sigurisë është të hulumtoni përdoruesit tuaj fundorë dhe të tjerët që mund të preken nga rezultatet e aplikacionit tuaj. Kjo mund të marrë shumë forma, duke përfshirë kërkimin e studimeve të gjendjes së artit në domenin e aplikacionit tuaj, vëzhgimin se si njerëzit përdorin aplikacione të ngjashme, ose kryerjen e një studimi, sondazhi të përdoruesit ose kryerjen e intervistave joformale me përdoruesit e mundshëm.

Merrni parasysh rregullimet për të zbutur rreziqet e sigurisë

Tani që i keni kuptuar rreziqet, mund të vendosni se si t'i zbusni ato. Përcaktimi i rreziqeve për t'u dhënë përparësi dhe sa shumë duhet të bëni për t'i parandaluar ato është një vendim kritik, i ngjashëm me kontrollimin e defekteve në një projekt softuerësh. Pasi të keni përcaktuar përparësitë, mund të filloni të mendoni për llojet e zbutjes që do të ishin më të përshtatshmet. Shpesh ndryshimet e thjeshta mund të bëjnë një ndryshim dhe të zvogëlojnë rreziqet.

Për shembull, kur hartoni një aplikacion merrni parasysh:

• Rregullimi i prodhimit të modelit për të pasqyruar më mirë atë që është e pranueshme në kontekstin e aplikimit tuaj. Akordimi mund ta bëjë produktin e modelit më të parashikueshëm dhe të qëndrueshëm dhe për këtë arsye mund të ndihmojë në zbutjen e rreziqeve të caktuara.
• Sigurimi i një metode hyrëse që mundëson rezultate më të sigurta. Inputi i saktë që i jepni një LLM mund të bëjë një ndryshim në cilësinë e prodhimit. Eksperimentimi me kërkesat e hyrjes për të gjetur atë që funksionon më mirë në rastin tuaj të përdorimit ia vlen shumë, pasi më pas mund të siguroni një UX që e lehtëson atë. Për shembull, mund t'i kufizoni përdoruesit të zgjedhin vetëm nga një listë rënëse e kërkesave të hyrjes, ose të ofroni sugjerime kërcyese me fraza përshkruese që keni gjetur se funksionojnë të sigurta në kontekstin e aplikacionit tuaj.

• Bllokimi i hyrjeve të pasigurta dhe filtrimi i daljes përpara se t'i shfaqet përdoruesit. Në situata të thjeshta, listat e bllokimit mund të përdoren për të identifikuar dhe bllokuar fjalë ose fraza të pasigurta në kërkesat ose përgjigjet, ose të kërkojnë që rishikuesit njerëzorë të ndryshojnë ose bllokojnë manualisht një përmbajtje të tillë.

• Përdorimi i klasifikuesve të trajnuar për të etiketuar secilën kërkesë me dëme të mundshme ose sinjale kundërshtare. Më pas mund të përdoren strategji të ndryshme se si të trajtohet kërkesa bazuar në llojin e dëmit të zbuluar. Për shembull, nëse hyrja është haptazi kundërshtare ose abuzive në natyrë, ajo mund të bllokohet dhe në vend të kësaj të nxjerrë një përgjigje të parashkruar.

  Këshillë e avancuar

  • Nëse sinjalet përcaktojnë se dalja është e dëmshme, aplikacioni mund të përdorë opsionet e mëposhtme:
    • Jepni një mesazh gabimi ose një dalje të paracaktuar.
    • Provoni sërish promptin, në rast se gjenerohet një dalje e sigurt alternative, pasi ndonjëherë e njëjta kërkesë do të nxjerrë rezultate të ndryshme.

• Vendosja e masave mbrojtëse kundër keqpërdorimit të qëllimshëm, si p.sh. caktimi i çdo përdoruesi një ID unike dhe vendosja e një kufiri në vëllimin e pyetjeve të përdoruesit që mund të dërgohen në një periudhë të caktuar. Një mbrojtje tjetër është të përpiqeni të mbroni kundër injektimit të mundshëm të menjëhershëm. Injeksioni i menjëhershëm, njëlloj si injeksioni SQL, është një mënyrë për përdoruesit me qëllim të keq që të dizajnojnë një kërkesë hyrëse që manipulon daljen e modelit, për shembull, duke dërguar një kërkesë hyrëse që udhëzon modelin të injorojë çdo shembull të mëparshëm. Shihni Politikën Gjenerative të Përdorimit të Ndaluar të UA për detaje rreth keqpërdorimit të qëllimshëm.

• Përshtatja e funksionalitetit me diçka që është në thelb rrezik më i ulët. Detyrat që janë më të ngushta në fushëveprim (p.sh. nxjerrja e fjalëve kyçe nga pjesët e tekstit) ose që kanë një mbikëqyrje më të madhe njerëzore (p.sh., gjenerimi i përmbajtjes në formë të shkurtër që do të shqyrtohet nga një person), shpesh paraqesin një rrezik më të ulët. Pra, për shembull, në vend që të krijoni një aplikacion për të shkruar një përgjigje me email nga e para, në vend të kësaj mund ta kufizoni atë në zgjerimin në një skicë ose sugjerimin e frazave alternative.

Kryeni testimin e sigurisë të përshtatshme për rastin tuaj të përdorimit

Testimi është një pjesë kyçe e ndërtimit të aplikacioneve të fuqishme dhe të sigurta, por shtrirja, qëllimi dhe strategjitë për testim do të ndryshojnë. Për shembull, një gjenerator haiku thjesht për argëtim ka të ngjarë të përbëjë rreziqe më pak të rënda sesa, të themi, një aplikacion i krijuar për t'u përdorur nga firmat ligjore për të përmbledhur dokumentet ligjore dhe për të ndihmuar në hartimin e kontratave. Por gjeneratori i haiku mund të përdoret nga një shumëllojshmëri më e gjerë përdoruesish që do të thotë se potenciali për përpjekje kundërshtare apo edhe inpute të dëmshme të paqëllimshme mund të jetë më i madh. Konteksti i zbatimit gjithashtu ka rëndësi. Për shembull, një aplikacion me rezultate që shqyrtohen nga ekspertë njerëzorë përpara se të ndërmerret ndonjë veprim mund të konsiderohet më pak i mundshëm për të prodhuar rezultate të dëmshme sesa aplikacioni i njëjtë pa një mbikëqyrje të tillë.

Nuk është e pazakontë të kaloni disa përsëritje për të bërë ndryshime dhe testime përpara se të ndiheni të sigurt se jeni gati për të nisur, edhe për aplikacionet me rrezik relativisht të ulët. Dy lloje testimi janë veçanërisht të dobishme për aplikacionet e AI:

• Krahasimi i sigurisë përfshin hartimin e matjeve të sigurisë që pasqyrojnë mënyrat se si aplikacioni juaj mund të jetë i pasigurt në kontekstin se si ka gjasa të përdoret, më pas testimin se sa mirë performon aplikacioni juaj në metrikë duke përdorur grupet e të dhënave të vlerësimit. Është praktikë e mirë të mendosh për nivelet minimale të pranueshme të matjeve të sigurisë përpara testimit, në mënyrë që 1) të mund të vlerësosh rezultatet e testit kundrejt këtyre pritjeve dhe 2) të mund të mbledhësh të dhënat e vlerësimit bazuar në testet që vlerësojnë metrikat që ju interesojnë më shumë.

  Këshilla të avancuara

  • Kujdes nga mbështetja e tepërt në qasjet "jashtë raftit", pasi ka të ngjarë që do t'ju duhet të ndërtoni grupet tuaja të të dhënave të testimit duke përdorur vlerësuesit njerëzorë për t'iu përshtatur plotësisht kontekstit të aplikacionit tuaj.
  • Nëse keni më shumë se një metrikë, do t'ju duhet të vendosni se si do të tregtoni nëse një ndryshim çon në përmirësime për një metrikë në dëm të një tjetri. Ashtu si me inxhinieri të tjera të performancës, ju mund të dëshironi të përqendroheni në performancën e rastit më të keq në grupin tuaj të vlerësimit dhe jo në performancën mesatare.

• Testimi kundërshtar përfshin përpjekjen proaktive për të thyer aplikacionin tuaj. Qëllimi është të identifikoni pikat e dobëta në mënyrë që të mund të ndërmerrni hapa për t'i korrigjuar ato sipas nevojës. Testimi kundërshtar mund të marrë kohë/përpjekje të konsiderueshme nga vlerësuesit me ekspertizë në aplikacionin tuaj - por sa më shumë të bëni, aq më të mëdha janë shanset për të dalluar problemet, veçanërisht ato që ndodhin rrallë ose vetëm pas ekzekutimeve të përsëritura të aplikacionit.

  • Testimi kontradiktor është një metodë për vlerësimin sistematik të një modeli ML me qëllimin për të mësuar se si sillet kur ofrohet me inpute keqdashëse ose të dëmshme pa dashje:
    • Një hyrje mund të jetë me qëllim të keq kur hyrja është krijuar qartë për të prodhuar një rezultat të pasigurt ose të dëmshëm - për shembull, duke i kërkuar një modeli të gjenerimit të tekstit të gjenerojë një fyerje të urryer për një fe të caktuar.
    • Një input është pa dashje i dëmshëm kur vetë inputi mund të jetë i padëmshëm, por prodhon rezultate të dëmshme -- për shembull, duke i kërkuar një modeli të gjenerimit të tekstit për të përshkruar një person të një etnie të caktuar dhe duke marrë një rezultat racist.
  • Ajo që e dallon një test kundërshtar nga një vlerësim standard është përbërja e të dhënave të përdorura për testim. Për testet kundërshtare, zgjidhni të dhënat e testit që ka më shumë gjasa të nxjerrin rezultate problematike nga modeli. Kjo do të thotë të hetosh sjelljen e modelit për të gjitha llojet e dëmtimeve që janë të mundshme, duke përfshirë shembuj të rrallë ose të pazakontë dhe rastet anësore që janë të rëndësishme për politikat e sigurisë. Ai gjithashtu duhet të përfshijë diversitetin në dimensionet e ndryshme të një fjalie si struktura, kuptimi dhe gjatësia. Ju mund t'i referoheni praktikave të inteligjencës artificiale të përgjegjshme të Google me drejtësi për më shumë detaje se çfarë duhet marrë parasysh kur ndërtoni një grup të dhënash testimi.

    Këshilla të avancuara

    • Përdorni testimin e automatizuar në vend të metodës tradicionale të regjistrimit të njerëzve në 'skuadrat e kuqe' për të provuar të prishni aplikacionin tuaj. Në testimin e automatizuar, 'skuadra e kuqe' është një model tjetër gjuhësor që gjen tekst hyrës që nxjerr rezultate të dëmshme nga modeli që testohet.

Monitoroni për problemet

Pavarësisht se sa shumë provoni dhe zbutni, nuk mund të garantoni kurrë përsosmërinë, kështu që planifikoni paraprakisht se si do t'i dalloni dhe do të merreni me problemet që lindin. Qasjet e zakonshme përfshijnë vendosjen e një kanali të monitoruar për përdoruesit që të ndajnë komente (p.sh. vlerësimi me gishtat lart/poshtë) dhe kryerja e një studimi të përdoruesit për të kërkuar në mënyrë proaktive reagime nga një përzierje e ndryshme përdoruesish – veçanërisht të vlefshme nëse modelet e përdorimit janë të ndryshme nga pritshmëritë.

Hapat e ardhshëm

• Referojuni udhëzuesit të cilësimeve të sigurisë për të mësuar rreth cilësimeve të rregullueshme të sigurisë të disponueshme përmes Gemini API.
• Shihni hyrjen e kërkesave për të filluar me shkrimin e kërkesave tuaja të para.