Beskytter meldinger fra LLM-datalekkasjer

Mening En interessant IBM NeurIPS 2024 innsending fra slutten av 2024 dukket opp igjen på Arxiv forrige uke. Den foreslår et system som automatisk kan gripe inn for å beskytte brukere fra å sende inn personlig eller sensitiv informasjon i en melding når de har en samtale med en Large Language Model (LLM) som f.eks. ChatGPT.

Mock-up-eksempler brukt i en brukerundersøkelse for å finne ut hvordan folk foretrekker å samhandle med en hurtigintervensjonstjeneste. Kilde: https://arxiv.org/pdf/2502.18509

Modellene vist ovenfor ble brukt av IBM-forskerne i en studie for å teste potensiell brukerfriksjon mot denne typen «forstyrrelser».

Selv om det gis lite detaljer om GUI-implementeringen, kan vi anta at slik funksjonalitet enten kan inkorporeres i en nettleserplugin kommunisere med et lokalt «brannmur»-LLM-rammeverk; eller at det kunne opprettes et program som kan koble seg direkte til (for eksempel OpenAI API, og dermed effektivt gjenskape OpenAIs eget nedlastbare frittstående program for ChatGPT, men med ekstra sikkerhetstiltak.

Når det er sagt, selvsensurerer ChatGPT selv automatisk svar på spørsmål som den oppfatter å inneholde kritisk informasjon, for eksempel bankdetaljer:

ChatGPT nekter å engasjere seg med spørsmål som inneholder antatt kritisk sikkerhetsinformasjon, for eksempel bankdetaljer (detaljene i ledeteksten ovenfor er fiktive og ikke-funksjonelle). Kilde: https://chatgpt.com/

ChatGPT er imidlertid mye mer tolerant når det gjelder ulike typer personlig informasjon – selv om det å formidle slik informasjon på noen måte kanskje ikke er i brukerens beste interesse (i dette tilfellet kanskje av ulike årsaker knyttet til arbeid og utlevering):

Eksemplet ovenfor er fiktivt, men ChatGPT nøler ikke med å delta i en samtale om brukeren om et sensitivt emne som utgjør en potensiell omdømme- eller inntektsrisiko (eksemplet ovenfor er fullstendig fiktivt).

I tilfellet ovenfor kan det ha vært bedre å skrive: «Hvilken betydning har en leukemidiagnose for en persons skriveevne og mobilitet?»

IBM-prosjektet identifiserer og tolker slike forespørsler på nytt fra en «personlig» til en «generisk» holdning.

Skjema for IBM-systemet, som bruker lokale LLM-er eller NLP-baserte heuristikk for å identifisere sensitivt materiale i potensielle forespørsler.

Dette forutsetter at materiale samlet inn av nettbaserte LLM-er, i denne spede fasen av publikums entusiastiske adopsjon av AI-chat, aldri vil bli brukt i verken påfølgende modeller eller senere annonseringsrammeverk som kan utnytte brukerbaserte søk for å gi potensielle resultater. målrettet annonsering.

Selv om det ikke er kjent at noe slikt system eller arrangement eksisterer nå, var heller ikke slik funksjonalitet tilgjengelig ved begynnelsen av internett-adopsjon på begynnelsen av 1990-tallet; siden da, deling av informasjon på tvers av domener å mate personlig tilpasset annonsering har ført til ulike skandaler, i tillegg til paranoia.

Derfor tyder historien på at det ville være bedre å rense LLM-spørsmålene nå, før slike data samles inn i volum, og før våre LLM-baserte innsendinger 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 rengjorte LLM-ledetekster er at muligheten til å tilpasse en dyr API-basert LLM som ChatGPT er ganske overbevisende, i hvert fall med dagens teknologiske utvikling – men dette kan innebære langsiktig eksponering av privat informasjon.

Jeg ber ofte ChatGPT om å hjelpe meg med å formulere Windows PowerShell-skript og BAT-filer for å automatisere prosesser, så vel som andre tekniske spørsmål. For dette formål synes jeg det er nyttig at systemet permanent husker detaljer om maskinvaren jeg har tilgjengelig; mine eksisterende tekniske ferdigheter (eller mangel på slike); og forskjellige andre miljøfaktorer og tilpassede regler:

ChatGPT lar en bruker utvikle en «cache» av minner som vil bli brukt når systemet vurderer svar på fremtidige forespørsler.

Dette holder uunngåelig informasjon om meg lagret på eksterne servere, underlagt vilkår og betingelser som kan utvikle seg over tid, uten noen garanti for at OpenAI (selv om det kan være en hvilken som helst annen større LLM-leverandør) vil respekter vilkårene de har satt opp.

Generelt er imidlertid kapasiteten til å bygge en cache med minner i ChatGPT mest nyttig på grunn av begrenset oppmerksomhetsvindu av LLM-er generelt; uten langsiktig (personlig) innebygging, føler brukeren, frustrerende nok, at de snakker med en enhet som lider av Anterograd amnesi.

Det er vanskelig å si om nyere modeller etter hvert vil bli tilstrekkelig ytelsesdyktige til å gi nyttige svar uten behov for å cache minner, eller å lage tilpassede GPT-er som er lagret på nett.

Midlertidig hukommelsestap

Selv om man kan gjøre ChatGPT-samtaler «midlertidige», er det nyttig å ha chathistorikken som en referanse som kan destilleres, når tiden tillater det, til en mer sammenhengende lokal oversikt, kanskje på en notatplattform; men uansett kan vi ikke vite nøyaktig hva som skjer med disse «forkastede» chattene (selv om OpenAI stater de vil ikke bli brukt til opplæring, det står ikke at de er ødelagt), basert på ChatGPT-infrastrukturen. Alt vi vet er at chatter ikke lenger vises i historikken vår når «Midlertidige chatter» er slått på i ChatGPT.

Diverse nylige kontroverser tyder på at API-baserte leverandører som OpenAI ikke nødvendigvis bør ha ansvaret for å beskytte brukerens personvern, inkludert oppdagelsen av emergent memorering, noe som betyr at større LLM-er er mer sannsynlig å huske noen treningseksempler i sin helhet, og øker risikoen for utlevering av brukerspesifikke data – blant andre offentlige hendelser som har overbevist en mengde store selskaper, som Samsung, Til forby LLM-er for intern bedriftsbruk.

Tenk annerledes

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

Tre IBM-baserte omformuleringer som balanserer nytteverdi mot databeskyttelse. I det laveste (rosa) båndet ser vi en ledetekst som er utenfor systemets evne til å rense på en meningsfull måte.

IBM-tilnærmingen fanger opp utgående pakker til en LLM på nettverksnivå, og omskriver dem etter behov før originalen kan sendes inn. De ganske mer forseggjorte GUI-integrasjonene som ble sett i begynnelsen av artikkelen er bare illustrerende for hvor en slik tilnærming kan gå, hvis den er utviklet.

Uten tilstrekkelig medvirken kan det selvsagt hende at brukeren ikke forstår at de får svar på en litt endret omformulering av den opprinnelige innsendingen. Denne mangelen på åpenhet tilsvarer at et operativsystems brannmur blokkerer tilgang til et nettsted eller en tjeneste uten å informere brukeren, som da feilaktig kan søke etter andre årsaker til problemet.

Forespørsler som sikkerhetsforpliktelser

Utsiktene til «rask inngripen» analogiserer godt med Windows OS-sikkerhet, som har utviklet seg fra et lappeteppe av (valgfritt installerte) kommersielle produkter på 1990-tallet til en ikke-valgfri og strengt håndhevet pakke med nettverksforsvarsverktøy som følger med som standard med en Windows-installasjon, og som krever litt innsats for å slå av eller deintensivere.

Hvis rask sanering utvikler seg slik nettverksbrannmurer har gjort de siste 30 årene, kan IBM-avisens forslag tjene som en blåkopi for fremtiden: å distribuere en fullstendig lokal LLM på brukerens maskin for å filtrere utgående meldinger rettet mot kjente LLM APIer. Dette systemet vil naturligvis trenge å integrere GUI-rammer og varsler, og gi brukere kontroll – med mindre administrative retningslinjer overstyrer det, som ofte skjer i forretningsmiljøer.

Forskerne gjennomførte en analyse av en åpen kildekode-versjon av Del GPT datasett for å forstå hvor ofte kontekstuelt personvern krenkes i virkelige scenarier.

Lama-3.1-405B-instruks ble brukt som en «dommermodell» for å oppdage brudd på kontekstuell integritet. Fra et stort sett med samtaler ble et delsett av samtaler med én runde analysert basert på lengde. Dommermodellen vurderte deretter konteksten, sensitiv informasjon og nødvendigheten av oppgavefullføring, noe som førte til identifisering av samtaler som inneholdt potensielle kontekstuelle integritetsbrudd.

En mindre undergruppe av disse samtalene, som viste definitive kontekstuelle brudd på personvernet, ble analysert videre.

Selve rammeverket ble implementert ved hjelp av modeller som er mindre enn typiske chat-agenter som ChatGPT, for å muliggjøre lokal distribusjon via Ollama.

Skjema for hurtigintervensjonssystemet.

De tre LLM-ene som ble evaluert var Mixtral-8x7B-Instruct-v0.1; Lama-3.1-8B-instruks, Og DeepSeek-R1-Destill-Llama-8B.

Brukerforespørsler behandles av rammeverket i tre trinn: kontekstidentifikasjon; klassifisering av sensitiv informasjon, Og omformulering.

To tilnærminger ble implementert for klassifisering av sensitiv informasjon: dynamisk og strukturert klassifisering: dynamisk klassifisering bestemmer de essensielle detaljene basert på deres bruk i en spesifikk samtale; strukturert klassifisering gir mulighet for spesifikasjon av en forhåndsdefinert liste over sensitive attributter som alltid anses som ikke-essensielle. Modellen omformulerer forespørselen hvis den oppdager ikke-essensielle sensitive detaljer ved enten å fjerne eller omformulere dem for å minimere personvernrisikoen samtidig som brukervennligheten opprettholdes.

Hjemmeregler

Selv om strukturert klassifisering som konsept ikke er godt illustrert i IBM-artikkelen, er det mest beslektet med metoden «Private Data Definitions» i Private forespørsler initiativ, som gir et nedlastbart frittstående program som kan omskrive forespørsler – om enn uten mulighet til å gripe direkte inn på nettverksnivå, slik IBM-tilnærmingen gjør (i stedet må brukeren kopiere og lime inn de modifiserte ledetekstene).

Den kjørbare Private Prompts tillater en liste over alternative erstatninger for brukerinndatatekst.

I bildet ovenfor kan vi se at brukeren av private forespørsler er i stand til å programmere automatiserte erstatninger for tilfeller av sensitiv informasjon. I begge tilfeller, for Private forespørsler og IBM-metoden, virker det usannsynlig at en bruker med nok tilstedeværelse og personlig innsikt til å lage en slik liste faktisk trenger dette produktet – selv om det kan bygges opp over tid etter hvert som hendelser oppstår.

I en administratorrolle kan strukturert klassifisering fungere som en pålagt brannmur eller sensurnett for ansatte; og i et hjemmenettverk kan det, med noen vanskelige justeringer, bli et hjemmenettverksfilter for alle nettverksbrukere; men til syvende og sist er denne metoden uten tvil overflødig, siden en bruker som kunne konfigurere dette riktig, også kan selvsensurere effektivt i utgangspunktet.

ChatGPTs mening

Siden ChatGPT nylig lanserte sin dyptgående forskningsverktøy For betalende brukere brukte jeg denne funksjonen til å be ChatGPT om å gjennomgå relatert litteratur og gi meg et «kynisk» syn på IBMs artikkel. Jeg fikk den mest defensive og nedsettende responsen systemet noensinne har gitt da jeg ble bedt om å evaluere eller analysere en ny publikasjon:

ChatGPT-4o har en lav oppfatning av IBM-prosjektet.

«Hvis brukere ikke stoler på at OpenAI, Google eller Anthropic håndterer dataene deres på en ansvarlig måte» ChatGPT-poster. «Hvorfor skulle de stole på et tredjeparts programvarelag som sitter mellom dem og AI-en? Mellomleddet i seg selv blir et nytt feilpunkt – potensielt logging, feilhåndtering eller til og med lekkasje av data før de i det hele tatt når LLM. Det løser ingenting hvis det bare oppretter en annen enhet for å utnytte brukerdata.»

Denne innvendingen virker selvbetjent og ikke-anvendbar, gitt den historie med åpen kildekode-prosjekter som virkelig kommer sluttbrukere til gode gjennom den samordnede langsiktige innsatsen til fellesskapsutviklere og bidragsytere; og gitt det voksende potensialet til mobile enheter for å kjøre – og til og med trene – lette LLM-er. Gjerne i dette tilfellet er ikke brukssaken spesielt krevende.

Deretter savner ChatGPT selvsikkert poenget med å ha en lett LLM som gir tilsyn med input til en kommersiell LLM som umulig kunne kjøres på en lokal maskin (fordi LLM er for stor, og å tillate lokal tilgang er for risikabelt for selskapet som lager det):

'Effektiv personvernfiltrering krever at du forstår inndataene før du bestemmer deg for hva som skal fjernes. Hvis en mellommann er smart nok til å gjenkjenne sensitive data (navn, adresser, økonomiske detaljer), så behandler og analyserer den allerede disse dataene – noe som betyr at den må lagre eller undersøke akkurat det den skal slette.

"Dette introduserer et paradoks: a) Et dumt filter (grunnleggende regex-substitusjon) vil være ineffektivt og gå glipp av subtile personvernrisikoer. b) Et smart filter (LLM-drevet rewriter) må behandle hele inndata, noe som gjør det like farlig som den originale LLM.

«Hvis du stoler nok på mellommannen til å lese og omskrive inndataene dine, hvorfor ikke bare stole på selve LLM-en?»

Svaret på det siste spørsmålet her er at den lokale LLM er ment å være helt på brukerens side, og uunngåelig åpen kildekode, med minimalt eller null behov for nettverkstilgang. En tilsvarende kommersiell versjon, uansett hvor velment det var i utgangspunktet, ville til slutt være sårbar for bedriftsendringer og endringer i tjenestevilkårene, mens en passende åpen kildekode-lisens ville forhindre denne typen «uunngåelig korrupsjon».

ChatGPT argumenterte videre for at IBMs forslag «bryter brukerens intensjon», siden det kunne omtolke en ledetekst til et alternativ som påvirker nytten. Dette er imidlertid en mye bredere problem ved rask sanering, og ikke spesifikt for denne spesielle brukssaken.

Avslutningsvis (og ignorerte forslaget om å bruke lokale LLM-er «i stedet», som er akkurat det IBM-artikkelen faktisk foreslår), mente ChatGPT at IBM-metoden representerer en barriere for adopsjon på grunn av «brukerfriksjonen» ved å implementere varslings- og redigeringsmetoder i en chat.

Her kan ChatGPT ha rett; men hvis betydelig press kommer på grunn av ytterligere offentlige hendelser, eller hvis fortjeneste i en geografisk sone trues av økende regulering (og selskapet nekter å bare forlate den berørte regionen helt), antyder historien til forbrukerteknologi at sikkerhetstiltak vil til slutt ikke lenger være valgfritt uansett.

Konklusjon

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

Og absolutt ikke globalt; akkurat som Apple blokker visse iPhone-funksjoner i Europa, og LinkedIn har forskjellige regler For å utnytte brukernes data i forskjellige land, er det rimelig å antyde at ethvert AI-selskap vil bruke de mest lønnsomme vilkårene som er akseptable for en bestemt nasjon der det opererer – i hvert tilfelle på bekostning av brukerens rett til datapersonvern, etter behov.

Først publisert torsdag 27. februar 2025

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