Syntetiske treningsdata kan forsterke feil ved finjustering

Syntetiske eksempler kan utvide treningsgrunnlaget når gode, reelle eksempler er få. Men hvis en feil i referansen blir til mange treningspar, får feilen større vekt. Microsofts veiledning for Foundry anbefaler å kontrollere et lite utvalg før oppskalering, vurdere en blanding med reelle data og måle ytelsen på virkelige oppgaver.

En kontrollert arbeidsflyt begynner med en tydelig oppgave og gjennomgått referansemateriale. Deretter lager du en liten pilot, inspiserer eksemplene, blander godkjente syntetiske data med reelle eksempler og evaluerer den finjusterte modellen på oppgaver som ble holdt utenfor både generering og trening.

Avgrens oppgaven og rens referansen

Bestem først hvilken atferd finjusteringen skal forbedre. Det kan være korte, korrekte svar om et avgrenset fagområde eller valg av riktig verktøy i en bestemt situasjon. Beskriv hva et godt svar må inneholde, når modellen bør be om mer informasjon, og når den skal la være å gjette. Slike kriterier gjør det mulig å skille nyttig variasjon fra svar som bare høres overbevisende ut.

Bruk oppdaterte fagtekster, rutiner eller verktøybeskrivelser som referanse. Fjern motstridende instrukser, foreldede opplysninger og irrelevant standardtekst før genereringen starter. Hvis grunnlaget gir feil svar på et spørsmål, kan generatoren gjenta svaret i flere varianter. Da ser datasettet større ut uten at det inneholder mer pålitelig kunnskap.

Hold samtidig av et eget utvalg reelle oppgaver til sluttevaluering. Ta med vanlige forespørsler, sjeldne tilfeller og spørsmål der nødvendig informasjon mangler. Disse oppgavene må ikke brukes som referanse for generatoren eller som treningsdata: Da ville den avsluttende prøven måle noe modellen allerede har fått se.

Lag en liten pilot og inspiser svarene

Generer først et begrenset utvalg som dekker ulike oppgavetyper. Les spørsmål og svar som foreslåtte fasitsvar, ikke som ferdige treningsdata. Kontroller at hvert svar følger referansen, faktisk besvarer spørsmålet og har et format som passer bruken. Et velformulert svar skal forkastes hvis det legger til opplysninger som ikke finnes i grunnlaget.

Se etter nær identiske spørsmål, gjentatte påstander og tilfeller der modellen svarer skråsikkert på noe referansen ikke avklarer. Et menneske som kjenner oppgaven, bør undersøke både de tilsynelatende gode eksemplene og de åpenbart svake. Ellers kan en enkel kontroll fange opp formatfeil, men overse en faglig feil som går igjen i mange svar.

Noter hvorfor eksempler blir forkastet, og rett årsaken før neste runde. Mange faktiske feil kan peke mot en svak referanse; mange like eksempler kan peke mot for snever variasjon i genereringen. Øk først volumet når pilotens feil kan oppdages og håndteres på en måte som også fungerer for resten av datasettet.

Bland med reelle data uten å skjule unntak

Godkjente syntetiske eksempler kan fylle hull i dekningen, særlig for oppgavetyper det finnes få observerte eksempler på. Behold samtidig reelle eksempler fra den faktiske bruken. De viser hvordan folk formulerer ufullstendige spørsmål, hvilke behov som oppstår utenfor de planlagte kategoriene, og hvilke unntak generatoren lett kan overse.

Merk eksemplene med opprinnelse og oppgavetype før de blandes. Da blir det synlig om mange syntetiske varianter overdøver et mindre, men viktig reelt mønster. Sammenlign gjerne en modell finjustert på de godkjente reelle dataene med en variant som også får syntetiske eksempler. Forskjellen på en separat prøve sier mer om nytten enn antall nye rader i treningsfilen.

Et forsøk med rekursiv modelltrening viste at sjeldnere deler av den opprinnelige datavariasjonen kunne forsvinne når generert innhold ble brukt videre gjennom modellgenerasjoner. Forsøket beskriver gjentatt trening, mens en enkelt finjustering er en annen situasjon. Den relevante kontrollen her er å bevare uavhengige, reelle eksempler og se om modellen fortsatt håndterer viktige unntak.

Evaluer på oppgaver generatoren aldri så

Etter finjustering bør den nye modellen sammenlignes med utgangspunktet på det avsatte utvalget av reelle oppgaver. Vurder faglig riktighet, riktig format, håndtering av manglende informasjon og resultatet på sjeldne tilfeller. En penere formulering er ingen forbedring dersom modellen samtidig gjør flere faktiske feil.

Se på resultatene per oppgavetype og brukergruppe, ikke bare ett samlet mål. Bedring på mange enkle spørsmål kan skjule tilbakegang der svarene krever særskilt kunnskap eller forsiktighet. Gjentatte feil i samme retning er et varselsignal om skjevheter i referansen, pilotutvalget eller blandingen. Undersøk de konkrete svarene før du bestemmer hva som må endres.

Hvis modellen gjør det bedre på treningsdataene, men dårligere på den separate prøven, kan den være overtilpasset. Prøv færre eller mer varierte syntetiske eksempler, en annen blanding eller mindre omfattende finjustering, og mål på nytt. Et automatisk delt generert datasett er heller ikke nok som sluttest hvis begge delene bygger på samme referanse og overser de samme reelle oppgavene.

Skill syntetisk tekst fra differensielt private data

At tekst er generert, gir i seg selv ingen matematisk personverngaranti. En generator som får personopplysninger i referansen, kan produsere gjenkjennelige detaljer i utdataene. Fjern opplysninger som ikke trengs før generering, og undersøk både piloten og det ferdige datasettet for navn, særpregede utdrag og andre identifiserbare opplysninger. Den samme kontrollen trengs for reelle eksempler som beholdes i treningen.

Differensielt personvern krever en egen metode som begrenser hvor mye én persons data kan påvirke resultatet. Google Researchs forsøk med privat inferens ga brukbare BERT-klassifikatorer trent på syntetiske Yelp-data, men nøyaktigheten lå under den beste private finjusteringsmetoden i denne sammenligningen. Metoden samlet modellens svar på flere sensitive eksempler med differensielt personvern under genereringen; vanlig generering fra en referansefil har ikke automatisk den egenskapen.

Før et større datasett produseres, bør referansen være kontrollert, pilotens feil rettet og blandingen med reelle eksempler begrunnet. Den separate evalueringen må vise at tillegget hjelper på oppgavene modellen faktisk skal løse. Hvis personvern er et krav, må en eventuell garanti knyttes til den konkrete metoden som ble brukt under genereringen.

Les også: