Udhëzime për sigurinë dhe faktet

Modelet e inteligjencës artificiale gjeneruese janë mjete të fuqishme, por nuk janë pa kufizime. 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ë anshme ose fyese. Përpunimi pasues dhe vlerësimi rigoroz manual janë thelbësorë për të kufizuar rrezikun e dëmit nga rezultate të tilla.

Modelet e ofruara nga Gemini API mund të përdoren për një gamë të gjerë aplikacionesh të IA-së gjeneruese dhe përpunimit të gjuhës natyrore (NLP). Përdorimi i këtyre funksioneve është i disponueshëm vetëm përmes Gemini API ose aplikacionit web Google AI Studio. Përdorimi juaj i Gemini API është gjithashtu subjekt i Politikës së Përdorimit të Ndaluar të IA-së 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ë adresojnë shumë detyra të ndryshme gjuhësore. Fatkeqësisht, kjo do të thotë gjithashtu se modelet e mëdha gjuhësore mund të gjenerojnë rezultate që nuk i prisni, duke përfshirë tekst që është ofendues, i pandjeshëm ose faktikisht i 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ë parashikimin saktësisht se çfarë lloj rezultatesh të padëshirueshme mund të prodhojnë. Ndërsa Gemini API është projektuar duke pasur parasysh parimet e IA-së të Google , përgjegjësia është mbi zhvilluesit 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 filtrime të integruara të përmbajtjes, si dhe cilësime të rregullueshme sigurie në 4 dimensione të dëmit. Referojuni udhëzuesit të cilësimeve të sigurisë për të mësuar më shumë. Ai gjithashtu ofron Grounding me Google Search të aktivizuar për të përmirësuar faktualitetin, megjithëse kjo mund të jetë e çaktivizuar për zhvilluesit, rastet e përdorimit të të cilëve janë më krijuese dhe jo kërkimore të informacionit.

Ky dokument synon t'ju prezantojë me disa rreziqe sigurie që mund të lindin gjatë përdorimit të LLM-ve dhe të rekomandojë rekomandime të reja për projektimin dhe zhvillimin e sigurisë. (Vini re se ligjet dhe rregulloret gjithashtu mund të vendosin kufizime, por konsiderata të tilla janë përtej fushëveprimit të këtij udhëzuesi.)

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

• Kuptimi i rreziqeve të sigurisë së aplikacionit tuaj
• Duke marrë në konsideratë rregullimet 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ë përsëritëse 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 shkaktimin e dëmit ndaj përdoruesve të tij, për shembull, duke gjeneruar gjuhë ose përmbajtje toksike që promovon stereotipe. Modelet e disponueshme përmes Gemini API janë projektuar duke pasur parasysh parimet e IA-së të Google dhe përdorimi juaj i tyre i nënshtrohet Politikës së Përdorimit të Ndaluar të IA-së Gjeneruese . API ofron filtra të integruar sigurie për të ndihmuar në adresimin e disa problemeve të zakonshme të modelit gjuhësor, siç janë gjuha toksike dhe gjuha e urrejtjes, dhe përpjekja për përfshirje dhe shmangie të stereotipeve. Megjithatë, çdo aplikacion mund të paraqesë një sërë rreziqesh të ndryshme 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ëmeve të mundshme që mund të shkaktojë aplikacioni juaj, dhe për t'u siguruar që aplikacioni juaj përdor LLM-të në mënyrë të sigurt dhe të përgjegjshme.

Si pjesë e këtij vlerësimi, duhet të merrni në konsideratë mundësinë e ndodhjes së dëmit dhe të përcaktoni seriozitetin e tij dhe hapat e zbutjes. Për shembull, një aplikacion që gjeneron ese bazuar në ngjarje faktike do të duhet të jetë më i kujdesshëm në shmangien e dezinformatave, krahasuar 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ë hulumtimin e studimeve të gjendjes së artit në domenin e aplikacionit tuaj, vëzhgimin se si njerëzit po përdorin aplikacione të ngjashme ose kryerjen e një studimi, ankete për përdoruesit ose kryerjen e intervistave joformale me përdorues potencialë.

Merrni në konsideratë rregullimet për të zbutur rreziqet e sigurisë dhe faktualitetit

Tani që i kuptoni rreziqet, mund të vendosni se si t’i zbutni ato. Përcaktimi i rreziqeve që duhen përcaktuar si përparësi dhe sa duhet të bëni për t’i parandaluar ato është një vendim kritik, i ngjashëm me klasifikimin e gabimeve në një projekt softueri. Pasi të keni përcaktuar përparësitë, mund të filloni të mendoni për llojet e zbutjeve që do të ishin më të përshtatshme. Shpesh ndryshimet e thjeshta mund të bëjnë diferencën dhe të zvogëlojnë rreziqet.

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

• Rregullimi i rezultatit të modelit për të pasqyruar më mirë atë që është e pranueshme në kontekstin e aplikacionit tuaj. Rregullimi mund ta bëjë rezultatin 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.
• Ofrimi i një metode hyrëse që mundëson rezultate më të sigurta. Informacioni i saktë që i jepni një LLM mund të bëjë një ndryshim në cilësinë e rezultatit. Eksperimentimi me kërkesat e hyrjes për të gjetur se çfarë funksionon më në mënyrë të sigurt në rastin tuaj të përdorimit ia vlen mundit, pasi më pas mund të ofroni një UX që e lehtëson atë. Për shembull, mund t'i kufizoni përdoruesit të zgjedhin vetëm nga një listë zbritëse e kërkesave të hyrjes, ose të ofroni sugjerime që shfaqen me fraza përshkruese të cilat i keni gjetur se funksionojnë në mënyrë të sigurt në kontekstin e aplikacionit tuaj.

• Bllokimi i të dhënave hyrëse të pasigurta dhe filtrimi i të dhënave dalëse përpara se t'i shfaqen 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ërkesa ose përgjigje, ose për të kërkuar që shqyrtuesit njerëzorë ta ndryshojnë ose bllokojnë manualisht përmbajtje të tillë.

• Përdorimi i klasifikuesve të trajnuar për të etiketuar çdo 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 të dhënat hyrëse janë hapur kundërshtare ose abuzive në natyrë, ato mund të bllokohen dhe në vend të tyre të prodhohet një përgjigje e paracaktuar.

  Këshillë e avancuar

  • Nëse sinjalet përcaktojnë që rezultati të jetë i dëmshëm, aplikacioni mund të përdorë opsionet e mëposhtme:
    • Jepni një mesazh gabimi ose një rezultat të paracaktuar.
    • Provo përsëri kërkesën, në rast se gjenerohet një dalje alternative e sigurt, meqenëse ndonjëherë e njëjta kërkesë do të nxjerrë dalje të ndryshme.

• Vendosja e masave mbrojtëse kundër keqpërdorimit të qëllimshëm, siç është caktimi i një ID-je unike për secilin përdorues dhe vendosja e një limiti në vëllimin e pyetjeve të përdoruesit që mund të dorëzohen në një periudhë të caktuar. Një tjetër mbrojtje është përpjekja për t'u mbrojtur nga injektimi i mundshëm i menjëhershëm. Injektimi i menjëhershëm, ashtu si injektimi SQL, është një mënyrë që përdoruesit keqdashës të hartojnë një kërkesë hyrëse që manipulon rezultatin 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 e Përdorimit të Ndaluar të IA-së Gjeneruese për detaje rreth keqpërdorimit të qëllimshëm.

• Përshtatja e funksionalitetit në diçka që është në thelb me rrezik më të ulët. Detyrat që kanë fushëveprim më të ngushtë (p.sh., nxjerrja e fjalëve kyçe nga fragmente teksti) ose që kanë mbikëqyrje më të madhe njerëzore (p.sh., gjenerimi i përmbajtjes së shkurtër që do të rishikohet nga një njeri), shpesh paraqesin një rrezik më të ulët. Kështu, për shembull, në vend që të krijoni një aplikacion për të shkruar një përgjigje me email nga e para, mund ta kufizoni atë në zgjerimin e një skice ose sugjerimin e frazave alternative.

• Rregullimi i cilësimeve të sigurisë së përmbajtjes së dëmshme për të ulur gjasat që të shihni përgjigje që mund të jenë të dëmshme. Gemini API ofron cilësime sigurie që mund t'i rregulloni gjatë fazës së prototipimit për të përcaktuar nëse aplikacioni juaj kërkon konfigurim sigurie më shumë ose më pak kufizues. Ju mund t'i rregulloni këto cilësime në pesë kategori filtri për të kufizuar ose lejuar lloje të caktuara përmbajtjeje. 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.

• Zvogëloni pasaktësitë ose halucinacionet e mundshme faktike duke aktivizuar Grounding with Google Search . Mos harroni, shumë modele të IA-së janë eksperimentale dhe mund të paraqesin informacione faktike të pasakta, të halucinojnë ose të prodhojnë rezultate problematike. Funksioni Grounding with Google Search lidh modelin Gemini me përmbajtje në kohë reale të internetit dhe funksionon me të gjitha gjuhët e disponueshme. Kjo i lejon Gemini të ofrojë përgjigje më të sakta dhe të citojë burime të verifikueshme përtej kufirit të njohurive të modeleve.

Kryeni testime sigurie të përshtatshme për rastin tuaj të përdorimit

Testimi është një pjesë kyçe e ndërtimit të aplikacioneve të forta dhe të sigurta, por shkalla, fushëveprimi dhe strategjitë për testim do të ndryshojnë. Për shembull, një gjenerator haiku vetëm për argëtim ka të ngjarë të paraqesë rreziqe më pak të rënda sesa, të themi, një aplikacion i projektuar për t'u përdorur nga firmat ligjore për të përmbledhur dokumente ligjore dhe për të ndihmuar në hartimin e kontratave. Por gjeneratori haiku mund të përdoret nga një gamë më e gjerë përdoruesish, që do të thotë se potenciali për përpjekje kundërshtare ose edhe për të dhëna 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ë rishikohen nga ekspertë njerëzorë para se të ndërmerret ndonjë veprim mund të konsiderohet me më pak të ngjarë të prodhojë rezultate të dëmshme sesa aplikacioni identik pa një mbikëqyrje të tillë.

Nuk është e pazakontë të kalosh nëpër disa përsëritje të bërjes së ndryshimeve dhe testimeve përpara se të ndihesh i sigurt se je gati për t'u lançuar, madje edhe për aplikacionet që kanë risk relativisht të ulët. Dy lloje testimesh janë veçanërisht të dobishme për aplikacionet e IA-së:

• Krahasimi i sigurisë përfshin hartimin e metrikave të sigurisë që pasqyrojnë mënyrat se si aplikacioni juaj mund të jetë i pasigurt në kontekstin e mënyrës se si ka të ngjarë të përdoret, më pas testimin se sa mirë funksionon aplikacioni juaj në metrika duke përdorur grupe të dhënash vlerësimi. Është praktikë e mirë të mendoni për nivelet minimale të pranueshme të metrikave të sigurisë para testimit, në mënyrë që 1) të mund të vlerësoni rezultatet e testimit kundrejt atyre pritjeve dhe 2) të mund të mbledhni grupin e të dhënave të vlerësimit bazuar në testet që vlerësojnë metrikat që ju interesojnë më shumë.

  Këshilla të avancuara

  • Kini kujdes nga mbështetja e tepërt në qasjet "të gatshme", pasi ka të ngjarë që do t'ju duhet të ndërtoni grupet tuaja të të dhënave të testimit duke përdorur vlerësues 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 ta bëni kompromisin nëse një ndryshim çon në përmirësime për një metrikë në dëm të një tjetre. Ashtu si me inxhinierinë tjetër të performancës, mund të dëshironi të përqendroheni në performancën e rastit më të keq në të gjithë grupin tuaj të vlerësimit në vend të performancës mesatare.

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

  • Testimi kundërshtar është një metodë për vlerësimin sistematik të një modeli ML me qëllim të të mësuarit se si sillet ai kur i ofrohet një informacion i keqdashës ose i paqëllimshëm i dëmshëm:
    • Një të dhënë mund të jetë keqdashëse kur është qartësisht e projektuar për të prodhuar një rezultat të pasigurt ose të dëmshëm - për shembull, t'i kërkohet një modeli të gjenerimit të tekstit të gjenerojë një ankesë të urryer për një fe të caktuar.
    • Një informacion është pa dashje i dëmshëm kur vetë informacioni mund të jetë i padëmshëm, por prodhon rezultate të dëmshme -- për shembull, kur i kërkohet një modeli të gjenerimit të tekstit të përshkruajë një person të një etnie të caktuar dhe marrja e një rezultati 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 testimit që ka më shumë të ngjarë të nxjerrin rezultate problematike nga modeli. Kjo do të thotë të hetohet sjellja e modelit për të gjitha llojet e dëmeve që janë të mundshme, duke përfshirë shembuj të rrallë ose të pazakontë dhe raste 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ç janë struktura, kuptimi dhe gjatësia. Mund t'i referoheni praktikave të Google-it për IA të Përgjegjshme në Drejtësi për më shumë detaje se çfarë duhet të merrni në konsideratë 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ë rekrutimit të njerëzve në 'ekipet e kuqe' për të provuar të prishni aplikacionin tuaj. Në testimin e automatizuar, 'ekipi i kuq' ë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 probleme

Pavarësisht se sa shumë testoni dhe zbutni, nuk mund të garantoni kurrë përsosmëri, prandaj planifikoni paraprakisht se si do t'i dalloni dhe do t'i trajtoni problemet që lindin. Qasjet e zakonshme përfshijnë krijimin e një kanali të monitoruar për përdoruesit që të ndajnë reagime (p.sh., vlerësim pozitiv/poshtë) dhe kryerjen e një studimi mbi përdoruesit për të kërkuar në mënyrë proaktive reagime nga një përzierje e larmishme përdoruesish — veçanërisht e vlefshme nëse modelet e përdorimit janë të ndryshme nga pritjet.

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 në nxitje për të filluar të shkruani nxitjet tuaja të para.