På denne siden
En kildehenvisning peker på en kontrakt, men kontrakten tilhører feil kunde. I dette tenkte tilfellet søker en assistent for kundestøtte i mappene til to kunder etter en fornyelsesdato. Den finner en lignende kontrakt fra den andre kunden, legger den i konteksten og svarer flytende.
Dette er ikke en rapportert hendelse. Kildehenvisningen får svaret til å virke grundig samtidig som det røper feil kundes data. Feilen oppstod før modellen skrev en eneste setning.
En presentasjon om hvor AI-kunnskap bør ligge gir et nyttig arkitekturpoeng: Kunnskap som varierer mellom brukere, trenger et søkelag med tilgangskontroll. Microsofts veiledning om tilgang på dokumentnivå beskriver tillatelsessjekker knyttet til indekserte dokumenter og identitet ved søk. Den generelle regelen er enklere enn ett bestemt søkeprodukt: Bare autorisert materiale bør nå veien frem til svaret.
Sett grensen før svaret
En prompt kan be assistenten være kort, oppgi kilder eller spørre når noe er uklart. Den kan ikke trygt si «husk å ikke bruke den andre kundens dokumenter» samtidig som den gir modellen disse dokumentene. Hvis søket allerede krysset grensen, blir prompten bedt om å rette en tilgangsfeil i etterkant.
Applikasjonen må fastslå hvem som spør. Søket må bære det riktige omfanget videre: kunde, rolle, konto eller dokumenttillatelser, alt etter fagområdet. Dokumentkandidater bør filtreres eller autoriseres før teksten gis til modellen. Hvis svaret kan føre til en skriving, må skriveveien sjekke autorisasjon på nytt mot målposten.
- Avsenderens identitet
autentiser i applikasjonen
- Avgrenset søk kunde · rolle · dokument
filtrer før modellkonteksten
- Svar med kilder
vis til tillatt dokumentasjon
- Autorisasjon av skriving
sjekk målposten på nytt
Dette handler ikke bare om vektorsøk. Nøkkelordsøk, mellomlagrede sammendrag, samtaleminne og verktøyresultater kan også inneholde private opplysninger. Et sammendrag av én kundes dokument er fortsatt privat etter at kildeteksten er forkortet.
Vår guide til å koble sammen bedriftsverktøy spør hvem som eier hver post, og hvilket system som er fasit. For en assistent må vi legge til et spørsmål: Hvem har lov til å vite at denne posten finnes?
Et lite eksempel viser riktig rekkefølge
Anta at en tenkt indeks har fire dokumenter: to offentlige hjelpeartikler, én kontrakt for Kunde A og én for Kunde B. En bruker fra Kunde A spør om betalingsvilkår. Det semantisk nærmeste treffet er tilfeldigvis kontrakten til Kunde B.
Et søk uten avgrensning returnerer den. En senere instruks om å «svare bare for Kunde A» kan ikke garantere trygghet; innholdet har allerede nådd modellens kontekst. Et avgrenset søk fjerner dokumentet til Kunde B før rangering, eller returnerer bare kandidater brukeren har lov til å se. Assistenten kan da svare fra kontrakten til Kunde A eller si at den mangler nødvendig kilde.
Den nøyaktige løsningen avhenger av plattformen. Azure AI Searchs mønster for sikkerhetsfiltrering knytter gruppeidentifikatorer til dokumenter og bruker et filter på hvert søk. Dokumentasjonen advarer også om at det å skjule et tillatelsesfelt i svaret ikke i seg selv er tilgangskontroll. Det som kan håndheves, er filteret og identiteten bak det.
Skillet betyr noe når tillatelser endres. Hvis en ansatt mister tilgang, må ikke en gammel hurtigbuffer eller en utdatert indeks fortsatt levere dokumentet. Teamet trenger en definert vei for oppdatering og tester for tilbakekall, ikke bare tester for første tildeling. Hvis søketjenesten ikke kan følge tilgangsmodellen til kilden, kan det være feil arkitektur å kopiere kilden inn i indeksen.
Tillatelse og relevans er ulike tester
Et autorisert dokument kan være irrelevant eller foreldet. Et korrekt svar kan være uautorisert. Dette er ulike feil, og de bør evalueres hver for seg.
Test først grensen: Kan en bruker eller tjeneste fra én kunde hente, sitere eller utlede privat innhold fra en annen? Ta med direkte spørsmål, omskrivinger og sammendrag. Test så kvaliteten på svar innenfor den tillatte mengden: Velger assistenten gjeldende regler og innrømmer den når bevis mangler? Microsofts veiledning om søkestøttet generering anbefaler uttrykkelig tilgangskontroll ved søk og å behandle hentet innhold som upålitelig.
Det koster noe. Søk med tillatelser trenger metadata, kobling til identitet og håndtering av tilbakekall. Noen søk blir tomme etter filtrering. Det er riktig resultat når den som spør, mangler tilgang til bevisene. Å fylle tomrommet med en selvsikker gjetning ville gjøre tilgangsvernet til et nøyaktighetsproblem.
Denne grensen er også en praktisk test av den bredere regelen om unntak i automatisering: Hva bør skje når det tillatte søket ikke finner noe? Et godt opplegg kan svare «Jeg har ikke tilgang til en kilde som besvarer dette» og vise riktig vei for å be om hjelp. Det bør ikke søke bredere hos andre kunder, gjenbruke et gammelt svar eller utlede private detaljer fra en dokumenttittel. Behandle det tomme resultatet som en normal tilstand som kan testes. Tillatelse er en del av korrekthet, ikke et særtilfelle som skal lappes etter lansering.
En nyttig assistent er ikke en som vet alt i bedriften. Den finner riktige bevis innenfor tilgangen til den som spør og sier fra når grensen gjør spørsmålet ubesvart.
Ofte Stilte Spørsmål
Kan en prompt be assistenten om ikke å røpe private poster?
En prompt kan beskrive ønsket atferd, men kan ikke erstatte autorisasjon. Begrens søket til dokumenter den som spør, har lov til å se, og håndhev tillatelse igjen før handlinger med konsekvenser.
Hvor bør kundetillatelser brukes i et søkesystem?
Knytt den autentiserte brukeren eller tjenesten til søket, og filtrer eller godkjenn dokumentkandidater før innholdet kommer inn i modellens kontekst. Hold metadata om tillatelser oppdatert når tilgangen endres.
Er en kildehenvisning nok til at et svar kan stoles på?
Nei. En kildehenvisning viser hvor svaret kom fra. Den beviser ikke at den som sendte forespørselen, hadde lov til å se kilden, eller at dataene der er oppdaterte og riktige.