Beskytte Prompts fra LLM Data Leaks

Mening En interessant IBM NeurIPS 2024 innsending fra slutten av 2024 gjenoppstod på Arxiv forrige uke. Den foreslår et system som kan intervenere automatisk for å beskytte brukerne fra å sende personlige eller sensitive opplysninger i en melding når de har en samtale med en stor språkmodell (LLM) som ChatGPT.

Mock-up-eksempler brukt i en brukerstudie for å bestemme måtene mennesker ville ønske å samhandle med en prompt-intervensjonstjeneste. Kilde: https://arxiv.org/pdf/2502.18509

De ovennevnte mock-up-eksemplene ble brukt av IBM-forskerne i en studie for å teste potensiell brukerfriktjon mot denne type “forstyrrelse”.

Selv om det ikke er gitt mange detaljer om GUI-implementeringen, kan vi anta at en slik funksjonalitet enten kan inkorporeres i en nettleserutvidelse som kommuniserer med en lokal “brannmur” LLM-rammeverk, eller at en applikasjon kan bli skapt som kan koble direkte til (for eksempel) OpenAI API, og effektivt gjenskape OpenAIs eget nedlastbare program for ChatGPT, men med ekstra sikkerhetstiltak.

Det sies at ChatGPT selv automatisk sensurerer svar på forespørsler som den oppfatter å inneholde kritisk informasjon, som bankdetaljer:

ChatGPT nekter å engasjere seg i forespørsler som inneholder oppfattede kritiske sikkerhetsinformasjon, som bankdetaljer (detaljene i forespørselen ovenfor er fiktive og ikke-funksjonelle). Kilde: https://chatgpt.com/

Likevel er ChatGPT mye mer tolerant når det gjelder ulike typer personlige opplysninger – selv om å spre disse opplysningene på noen måte kanskje ikke er i brukerens beste interesse (i dette tilfelle kanskje av ulike årsaker relatert til arbeid og åpenbaring):

Eksempelet ovenfor er fiktivt, men ChatGPT tøver ikke å engasjere seg i en samtale med brukeren om et sensitivt emne som kan utgjøre en potensiell reputasjons- eller inntektsrisiko (eksempelet ovenfor er fullstendig fiktiv).

I dette tilfelle kunne det ha vært bedre å skrive: ‘Hva er betydningen av en leukemidiagnose på en persons evne til å skrive og på deres mobilitet?’

IBM-prosjektet identifiserer og tolker slik forespørsler på nytt fra en “personlig” til en “generisk” holdning.

Skjema for IBM-systemet, som bruker lokale LLM-er eller NLP-baserte heuristiske metoder for å identifisere sensitive materialer i potensielle forespørsler.

Dette antar at materiale samlet inn av nettbaserte LLM-er, i denne tidlige fasen av offentlighetens entusiastiske tilpasning av AI-samtale, aldri vil føre til senere modeller eller til senere annonseringsrammeverk som kan utnytte brukerbaserte søkeforespørsler for å gi potensielle målrettede annonser.

Selv om ingen slik ordning eller system er kjent å eksistere nå, var slike funksjoner heller ikke tilgjengelige ved begynnelsen av internett-tilpasning på begynnelsen av 1990-tallet; siden da har deling av informasjon over domener for å gi personlig annonsering ført til forskjellige skandaler, samt paranoia.

Derfor antyder historien at det ville være bedre å sanere LLM-forespørsler nå, før slik data samles inn i store mengder, og før våre LLM-baserte innsendelser havner i permanente sykliske databaser og/eller modeller, eller andre informasjonsbaserte strukturer og skjemaer.

Husk Meg?

En faktor som taler mot bruk av “generiske” eller sanerte LLM-forespørsler er at, ærlig talt, muligheten til å tilpasse en kostbar API-basert LLM som ChatGPT er ganske overbevisende, i alle fall i den nåværende tilstanden – men dette kan innebære langvarig eksponering av private opplysninger.

Jeg ber ofte ChatGPT om å hjelpe meg å formulere Windows PowerShell-skript og BAT-filer for å automatisere prosesser, samt om andre tekniske spørsmål. Til dette formålet finner jeg det nyttig at systemet permanent husker detaljer om hårdwaren jeg har tilgjengelig; mine eksisterende tekniske ferdigheter (eller mangelen på dem); og forskjellige andre miljøfaktorer og tilpassede regler:

ChatGPT lar en bruker utvikle en ‘hukommelse’ som vil bli brukt når systemet vurderer svar på fremtidige forespørsler.

Uunngåelig holder dette informasjon om meg lagret på eksterne servere, under vilkår og betingelser som kan endre seg over tid, uten noen garanti for at OpenAI (selv om det kunne være en annen stor LLM-leverandør) vil respektere vilkårene de har satt opp.

Generelt sett er imidlertid evnen til å bygge en hukommelse i ChatGPT mest nyttig på grunn av den begrensede oppmerksomhetsvinduet til LLM-er generelt; uten langvarige (tilpassede) innføring av hukommelse, føler brukeren frustrerende at de samhandler med en enhet som lider av anterograd amnesi.

Det er vanskelig å si om nyere modeller vil bli tilstrekkelig performant til å gi nyttige svar uten å måtte huske hukommelse, eller å skape tilpassede GPT-er som lagres online.

Midlertidig Amnesi

Selv om en kan gjøre ChatGPT-samtaler “midlertidige”, er det nyttig å ha Chat-historien som en referanse som kan destilleres, når tid tillater, til en mer sammenhengende lokal rekord, kanskje på en notatplattform; men likevel kan vi ikke vite eksakt hva som skjer med disse “kastede” samtaler (selv om OpenAI hevder at de ikke vil bli brukt til trening, sier de ikke at de blir ødelagt), basert på ChatGPT-infrastrukturen. Alt vi vet er at samtaler ikke lenger vises i vår historie når “Midlertidige samtaler” er aktivert i ChatGPT.

Forskjellige nylige kontroverser indikerer at API-baserte leverandører som OpenAI ikke nødvendigvis bør overlates ansvaret for å beskytte brukerens personvern, inkludert oppdagelsen av emergent memorisering, som betyr at større LLM-er er mer sannsynlig å memorisere noen treningseksempler fullstendig, og øker risikoen for åpenbaring av brukerspesifikke data – blant andre offentlige hendelser som har overbevist en rekke store selskaper, slike som Samsung, til å forbyde LLM-er for intern bruk.

Tenk Annet

Denne spenningen mellom den ekstreme nytten og den åpenbare potensielle risikoen til LLM-er vil trenge noen oppfinnsomme løsninger – og IBM-forslaget ser ut til å være et interessant grunnleggende mal i denne retningen.

Tre IBM-baserte reformuleringer som balanserer nytte mot personvern. I den laveste (rosa) båndet ser vi en forespørsel som er utenfor systemets evne til å sanere på en meningsfull måte.

IBM-tilnærmingen fanger opp utgående pakker til en LLM på nettverksnivå og skriver dem om hvis nødvendig før den opprinnelige kan bli sendt. De mer omfattende GUI-integreringene sett tidligere i artikkelen er bare illustrative av hvor slik en tilnærming kunne gå, hvis den ble utviklet.

Selvfølgelig, uten tilstrekkelig myndighet kan brukeren ikke forstå at de mottar et svar på en noe endret reformulering av deres opprinnelige innsendelse. Dette manglet gjennomsiktighet er ekvivalent med et operativsystems brannmur som blokkerer tilgang til en nettside eller tjeneste uten å informere brukeren, som da kan søke etter andre årsaker til problemet.

Forespørsler som Sikkerhetsrisiko

Perspektivet om “forespørselsintervensjon” ligner godt på Windows OS-sikkerhet, som har utviklet seg fra en lappeteppe av (valgfrie) kommersielle produkter på 1990-tallet til et ikke-valgfritt og strengt påtvinget sett med nettverksforsvarstverktøy som følger med en Windows-installasjon, og som krever en del innsats for å slå av eller redusere.

Hvis forespørsels-sanering utvikler seg som nettverksbrannmurer har gjort over de siste 30 årene, kan IBM-papirets forslag tjene som en mal for fremtiden: å deployere en fullstendig lokal LLM på brukerens maskin for å filtere utgående forespørsler rettet mot kjente LLM-API-er. Dette systemet ville naturligvis trenge å integrere GUI-rammeverk og varslinger, og gi brukerne kontroll – med mindre administrative politikker overstyrer det, som ofte skjer i bedriftsmiljø.

Forskerne utførte en analyse av en åpen kildeversjon av ShareGPT-datasetten for å forstå hvor ofte kontekstuell personvern blir krenket i virkelige scenarier.

Llama-3.1-405B-Instruct ble brukt som en “dommer”-modell for å oppdage krenkelser av kontekstuell integritet. Fra en stor mengde samtaler ble en undergruppe av enkelt-samtaler analysert basert på lengde. Dommermodellen vurderer deretter konteksten, sensitive opplysninger og nødvendigheten for oppgavefullføring, noe som ledet til identifisering av samtaler som inneholdt potensielle krenkelser av kontekstuell integritet.

En mindre undergruppe av disse samtaler, som viste definitive krenkelser av kontekstuell personvern, ble analysert videre.

Rammeverket i seg selv ble implementert ved hjelp av modeller som er mindre enn typiske chat-agenter som ChatGPT, for å muliggjøre lokal deployering via Ollama.

Skjema for forespørselsintervensjonssystemet.

De tre LLM-ene som ble evaluert var Mixtral-8x7B-Instruct-v0.1; Llama-3.1-8B-Instruct; og DeepSeek-R1-Distill-Llama-8B.

Brukerforespørsler blir prosessert av rammeverket i tre trinn: kontekstidentifikasjon; sensitiv informasjonsklassifisering; og reformulering.

To tilnærminger ble implementert for sensitiv informasjonsklassifisering: dynamsk og strukturert klassifisering: dynamisk klassifisering bestemmer de vesentlige detaljene basert på deres bruk i en bestemt samtale; strukturert klassifisering tillater spesifikasjon av en forhåndsdefinert liste over sensitive attributter som alltid anses som ikke-essensielle. Modellen reformulerer forespørselen hvis den oppdager ikke-essensielle sensitive detaljer ved å enten fjerne eller omskrive dem for å minimere personvernrisiko samtidig som den opprettholder bruksområdet.

Hjemmeregler

Selv om strukturert klassifisering som konsept ikke er godt illustrert i IBM-papiret, er det mest likt “Private Data Definitions”-metoden i Private Prompts-initiativet, som gir en nedlastbar selvstendig program som kan omskrive forespørsler – selv om den ikke har evnen til å intervenere direkte på nettverksnivå, som IBM-tilnærmingen gjør (i stedet må brukeren kopiere og lime inn de modifiserte forespørslerne).

Private Prompts-eksekverbar fil lar en liste over alternativ erstattere for bruker-innputt-tekst.

I bildet ovenfor kan vi se at Private Prompts-brukeren kan programmere automatiske erstattere for instanser av sensitive opplysninger. I begge tilfeller, for Private Prompts og IBM-metoden, synes det usannsynlig at en bruker med tilstrekkelig nærvær og personlig innsikt til å kuratere en slik liste faktisk ville trenge dette produktet  – selv om det kunne bygges opp over tid som hendelser skjer.

I en administratorrolle kunne strukturert klassifisering fungere som en påtvunget brannmur eller sensur-nett for ansatte; og i et hjemmenettverk kunne det, med noen vanskelige justeringer, bli et hjemmenettverksfilter for alle nettverksbrukere; men ultimate er denne metoden kanskje unødvendig, siden en bruker som kunne sette dette opp korrekt også kunne sensurere seg selv effektivt fra begynnelsen av.

ChatGPTs Mening

Ettersom ChatGPT nylig lanserte sin dypt forskningstool for betalende brukere, brukte jeg denne fasiliteten til å be ChatGPT om å gjennomgå relatert litteratur og gi meg en “synisk” vurdering av IBM-papiret. Jeg mottok det mest defensive og foraktelige svaret systemet noen gang har gitt når det ble bedt om å evaluere eller tolke en ny publikasjon:

ChatGPT-4o har en lav mening om IBM-prosjektet.

‘Hvis brukerne ikke stoler på OpenAI, Google eller Anthropic til å håndtere deres data ansvarlig,’ hevder ChatGPT. ‘hvorfor skulle de stole på en tredjeparts programvarelag som sitter mellom dem og AI-en? Mellomleddet blir en ny feilpunkt—potensielt logger, mishandler eller til og med lekker data før det noen gang når LLM-en. Det løser ingenting hvis det bare skaper en ny enhet som kan utnytte brukerdata.’

Dette motargumentet synes selvbetjent og uaktuell, gitt den rike historien av åpne kildekodsprosjekter som faktisk har gavn til sluttbrukerne gjennom de samlede, langvarige innsatsene til samfunnsutviklere og bidragsytere; og gitt den voksende potensialet for mobile enheter til å kjøre – og til og med trene – lettvinte LLM-er. Sikkert i dette tilfelle er bruksområdet ikke særlig krevende.

Deretter går ChatGPT glipp av poenget med å ha en lettvekt LLM som gir tilsyn over innsendelser til en kommersiell LLM som ikke kan kjøres på en lokal maskin (fordi LLM-en er for stor, og å tillate lokal tilgang er for risikabelt for selskapet som lager den):

‘Effektivt personvern-filtering krever å forstå innsendelsen før man bestemmer hva som skal fjernes. Hvis en mellomledd er smart nok til å gjenkjenne sensitive data (navn, adresser, finansielle detaljer), så er det allerede i ferd med å prosessere og analysere denne dataen—det betyr at det må lagre eller undersøke det samme som det skal slette.

‘Dette introduserer en paradoks: a) En dum filter (grunnleggende regex-erstatter) vil være ineffektiv og gå glipp av subtile personvernrisiko. b) En smart filter (LLM-drevet omskriver) må prosessere hele innsendelsen, noe som gjør det like farlig som den opprinnelige LLM-en.

‘Hvis du stoler på mellomleddet nok til å lese og omskrive dine innsendelser, hvorfor ikke bare stole på LLM-en selv?’

Svaret på det siste spørsmålet her er at den lokale LLM-en er ment å være fullstendig på brukerens side, og uunngåelig åpen kilde, med minimal eller ingen behov for nettverksaksess. En tilsvarende kommersiell versjon, uansett hvor godt ment den var fra begynnelsen av, ville til slutt være sårbar for korporative skifter og endringer i vilkårene for tjenesten, hvor en passende åpen kilde-lisens ville forhindre denne type ‘uunngåelige korrupsjon’.

ChatGPT hevdet videre at IBM-forslaget “ødelegger brukerens intensjon”, siden det kunne tolke en forespørsel om til en alternativ som påvirker dens nytte. Likevel er dette et mye bredere problem i forespørsels-sanering, og ikke spesifikt for dette konkrete bruksområdet.

I slutten (ignorert hans forslag om å bruke lokale LLM-er “i stedet”, som er akkurat hva IBM-papiret faktisk foreslår), mente ChatGPT at IBM-metoden representerer en hindring for tilpasning på grunn av “brukerfriktions”-problemet med å implementere advarsel- og redigeringsmetoder i en samtale.

Her kan ChatGPT ha rett; men hvis betydelig press kommer til å ligge på grunn av ytterligere offentlige hendelser, eller hvis profitter i én geografisk sone blir truet av økende regulering (og selskapet nekter å bare forlate den berørte regionen fullstendig), antyder historien til forbrukerteknologi at sikkerhetstiltak til slutt vil ikke lenger være valgfrie likevel.

Konklusjon

Vi kan ikke realistisk forvente at OpenAI noen gang vil implementere sikkerhetstiltak av den type som foreslås i IBM-papiret, og i den sentrale konseptet bak det; i alle fall ikke effektivt.

Og sikkert ikke globalt; like som Apple blokkerer visse iPhone-funksjoner i Europa, og LinkedIn har forskjellige regler for å utnytte brukernes data i forskjellige land, er det rimelig å anta at ethvert AI-selskap vil standardisere til de mest profitable vilkårene og betingelsene som er tolerable i hver enkelt nasjon hvor det opererer – i hvert tilfelle, på bekostning av brukerens rett til personvern, hvis nødvendig.

Først publisert torsdag, 27. februar 2025

Oppdatert torsdag, 27. februar 2025 15:47:11 på grunn av feilaktig Apple-relatert lenke – MA