Tilpasse koding følgesvenner for organisasjoner | Amazon Web Services

Generative AI-modeller for koding av ledsagere er for det meste trent på offentlig tilgjengelig kildekode og naturlig språktekst. Mens den store størrelsen på opplæringskorpuset gjør det mulig for modellene å generere kode for ofte brukt funksjonalitet, er disse modellene uvitende om kode i private arkiver og tilhørende kodestiler som håndheves når de utvikler med dem. Følgelig kan de genererte forslagene kreve omskriving før de er passende for inkorporering i et internt depot.

Vi kan løse dette gapet og minimere ytterligere manuell redigering ved å bygge inn kodekunnskap fra private arkiver på toppen av en språkmodell som er trent på offentlig kode. Dette er grunnen til at vi utviklet en tilpasningsmulighet for Amazon Code Whisperer. I dette innlegget viser vi deg to mulige måter å tilpasse kodingsledsager ved å bruke utvidet gjenfinning og finjustering.

Målet vårt med CodeWhisperer-tilpasningsevne er å gjøre det mulig for organisasjoner å skreddersy CodeWhisperer-modellen ved å bruke deres private depoter og biblioteker for å generere organisasjonsspesifikke kodeanbefalinger som sparer tid, følger organisasjonsstil og konvensjoner, og unngår feil eller sikkerhetssårbarheter. Dette er til fordel for programvareutvikling for bedrifter og hjelper til med å overvinne følgende utfordringer:

1. Sparsom dokumentasjon eller informasjon for interne biblioteker og APIer som tvinger utviklere til å bruke tid på å undersøke tidligere skrevet kode for å replikere bruk.
2. Mangel på bevissthet og konsistens i implementering av bedriftsspesifikk kodingspraksis, stiler og mønstre.
3. Utilsiktet bruk av utdatert kode og APIer av utviklere.

Ved å bruke interne kodelagre for ytterligere opplæring som allerede har gjennomgått kodegjennomganger, kan språkmodellen dukke opp bruken av interne APIer og kodeblokker som overvinner den foregående listen over problemer. Fordi referansekoden allerede er gjennomgått og oppfyller kundens høye krav, er sannsynligheten for å introdusere feil eller sikkerhetssårbarheter også minimert. Og ved å nøye velge kildefilene som brukes for tilpasning, kan organisasjoner redusere bruken av utdatert kode.

Designutfordringer

Å tilpasse kodeforslag basert på en organisasjons private depoter har mange interessante designutfordringer. Utplassering av store språkmodeller (LLM) til overflatekodeforslag har faste kostnader for tilgjengelighet og variable kostnader på grunn av slutninger basert på antall genererte tokens. Derfor kan det være uoverkommelig dyrt å ha separate tilpasninger for hver kunde og hoste dem individuelt, og dermed pådra seg ekstra faste kostnader. På den annen side, å ha flere tilpasninger samtidig på samme system, krever multi-tenant-infrastruktur for å isolere proprietær kode for hver kunde. Videre bør tilpasningsevnen dukke opp knotter for å muliggjøre valg av passende opplæringsdelsett fra det interne depotet ved å bruke forskjellige beregninger (for eksempel filer med en historie med færre feil eller kode som nylig er lagt inn i depotet). Ved å velge koden basert på disse beregningene, kan tilpasningen trenes opp ved hjelp av kode av høyere kvalitet som kan forbedre kvaliteten på kodeforslag. Til slutt, selv med kontinuerlig utviklende kodelagre, bør kostnadene forbundet med tilpasning være minimale for å hjelpe bedrifter med å realisere kostnadsbesparelser fra økt utviklerproduktivitet.

En grunnleggende tilnærming til å bygge tilpasning kan være å forhåndstrene modellen på et enkelt opplæringskorpus som består av det eksisterende (offentlige) foropplæringsdatasettet sammen med (privat) bedriftskoden. Selv om denne tilnærmingen fungerer i praksis, krever den (overflødig) individuell foropplæring ved bruk av det offentlige datasettet for hver virksomhet. Det krever også redundante distribusjonskostnader forbundet med å være vert for en tilpasset modell for hver kunde som kun betjener klientforespørsler som kommer fra den kunden. Ved å koble fra opplæringen av offentlig og privat kode og distribuere tilpasningen på et system med flere leietakere, kan disse overflødige kostnadene unngås.

Hvordan tilpasse

På et høyt nivå er det to typer mulige tilpasningsteknikker: gjenfinningsforsterket generasjon (RAG) og finjustering (FT).

• Gjenvinningsutvidet generasjon: RAG finner samsvarende kodebiter i et depot som ligner på et gitt kodefragment (for eksempel kode som kommer umiddelbart foran markøren i IDE-en) og forsterker ledeteksten som brukes til å spørre LLM med disse samsvarende kodebitene. Dette beriker spørsmålet om å hjelpe modellen til å generere mer relevant kode. Det er noen få teknikker utforsket i litteraturen langs disse linjene. Se Gjenvinningsutvidet generasjon for kunnskapsintensive NLP-oppgaver, EKTE, kNN-LM og RETRO.

• Finjustering: FT tar en forhåndsopplært LLM og trener den videre på en spesifikk, mindre kodebase (sammenlignet med forhåndsopplæringsdatasettet) for å tilpasse den til det aktuelle depotet. Finjustering justerer LLMs vekter basert på denne treningen, noe som gjør den mer skreddersydd til organisasjonens unike behov.

Både RAG og finjustering er kraftige verktøy for å forbedre ytelsen til LLM-basert tilpasning. RAG kan raskt tilpasse seg private biblioteker eller APIer med lavere opplæringskompleksitet og kostnad. Søking og utvidelse av hentede kodebiter til ledeteksten øker imidlertid ventetiden ved kjøring. I stedet krever finjustering ikke noen utvidelse av konteksten fordi modellen allerede er opplært på private biblioteker og APIer. Det fører imidlertid til høyere opplæringskostnader og kompleksitet i å betjene modellen, når flere tilpassede modeller må støttes på tvers av flere bedriftskunder. Som vi diskuterer senere, kan disse bekymringene avhjelpes ved å optimalisere tilnærmingen ytterligere.

Gjenvinning utvidet generasjon

Det er noen få trinn involvert i RAG:

Indeksering

Gitt et privat depot som input fra administratoren, opprettes en indeks ved å dele kildekodefilene i biter. Enkelt sagt, chunking gjør kodebitene til fordøyelige deler som sannsynligvis vil være mest informative for modellen og som er enkle å hente gitt konteksten. Størrelsen på en del og hvordan den trekkes ut fra en fil er designvalg som påvirker det endelige resultatet. For eksempel kan biter deles basert på kodelinjer eller basert på syntaktiske blokker, og så videre.

Administrator arbeidsflyt

Innholdssøk

Søk i et sett med indekserte kodebiter basert på noen få linjer med kode over markøren og hent relevante kodebiter. Denne gjenfinningen kan skje ved hjelp av forskjellige algoritmer. Disse valgene kan omfatte:

• Sekk med ord (BM25) - En bag-of-words gjenfinningsfunksjon som rangerer et sett med kodebiter basert på søketermfrekvenser og kodebitlengder.

BM25-basert henting

Følgende figur illustrerer hvordan BM25 fungerer. For å bruke BM25 bygges det først en invertert indeks. Dette er en datastruktur som tilordner ulike termer til kodebitene som disse termene forekommer i. På søketidspunktet slår vi opp kodebiter basert på termene som er tilstede i spørringen og skårer dem basert på frekvensen.

Semantisk gjenfinning

BM25 fokuserer på leksikalsk matching. Derfor vil det å erstatte "legg til" med "slett" kanskje ikke endre BM25-poengsummen basert på vilkårene i spørringen, men den hentede funksjonaliteten kan være motsatt av det som kreves. Derimot fokuserer semantisk henting på funksjonaliteten til kodebiten selv om variabel- og API-navn kan være forskjellige. Vanligvis kan en kombinasjon av BM25 og semantiske henting fungere godt sammen for å levere bedre resultater.

Økt slutning

Når utviklere skriver kode, brukes deres eksisterende program til å formulere en spørring som sendes til gjenfinningsindeksen. Etter å ha hentet flere kodebiter ved hjelp av en av teknikkene diskutert ovenfor, legger vi dem foran den opprinnelige ledeteksten. Det er mange designvalg her, inkludert antall utdrag som skal hentes, den relative plasseringen av utdragene i ledeteksten og størrelsen på utdraget. Det endelige designvalget er først og fremst drevet av empirisk observasjon ved å utforske ulike tilnærminger med den underliggende språkmodellen og spiller en nøkkelrolle i å bestemme nøyaktigheten til tilnærmingen. Innholdet fra de returnerte bitene og den originale koden kombineres og sendes til modellen for å få tilpassede kodeforslag.

Arbeidsflyt for utvikler

Finjustering:

Finjustering en språkmodell er gjort for overføre læring der vektene til en forhåndstrent modell trenes på nye data. Målet er å beholde riktig kunnskap fra en modell som allerede er trent på et stort korpus og avgrense, erstatte eller legge til ny kunnskap fra det nye korpuset - i vårt tilfelle en ny kodebase. Bare trening på en ny kodebase fører til katastrofal glemme. For eksempel kan språkmodellen "glem" kunnskapen om sikkerhet eller API-ene som er sparsomt brukt i bedriftens kodebase til dags dato. Det finnes en rekke teknikker som oppleve reprise, GEMog PP-TF som er ansatt for å møte denne utfordringen.

Finjustering

Det er to måter å finjustere på. En tilnærming er å bruke tilleggsdataene uten å forsterke spørsmålet om å finjustere modellen. En annen tilnærming er å forsterke forespørselen under finjustering ved å hente relevante kodeforslag. Dette bidrar til å forbedre modellens evne til å gi bedre forslag i nærvær av hentede kodebiter. Modellen blir deretter evaluert på et holdt ut sett med eksempler etter at den er trent. Deretter distribueres den tilpassede modellen og brukes til å generere kodeforslagene.

Til tross for fordelene ved å bruke dedikerte LLM-er for å generere kode på private repositories, kan kostnadene være uoverkommelige for små og mellomstore organisasjoner. Dette er fordi dedikerte dataressurser er nødvendige selv om de kan være underutnyttet gitt størrelsen på teamene. En måte å oppnå kostnadseffektivitet på er å betjene flere modeller på samme datamaskin (f.eks. SageMaker flerleieforhold). Språkmodeller krever imidlertid en eller flere dedikerte GPUer på tvers av flere soner for å håndtere ventetid og gjennomstrømningsbegrensninger. Derfor er multi-tenancy av full modellvert på hver GPU umulig.

Vi kan overvinne dette problemet ved å betjene flere kunder på samme datamaskin ved å bruke small adaptere til LLM. Parametereffektive finjusteringsteknikker (PEFT) som umiddelbar tuning, prefiks tuning, og lavrangstilpasning (LoRA) brukes til å senke treningskostnadene uten tap av nøyaktighet. Spesielt LoRA har sett stor suksess med å oppnå lignende (eller bedre) nøyaktighet enn finjustering av fullmodell. Den grunnleggende ideen er å designe en lav rangert matrise som deretter legges til matrisene med den opprinnelige matrisevekten til mållag av modellen. Vanligvis blir disse adapterne deretter slått sammen med de originale modellvektene for servering. Dette fører til samme størrelse og arkitektur som det opprinnelige nevrale nettverket. Ved å holde adapterene adskilt, kan vi betjene den samme grunnmodellen med mange modelladaptere. Dette bringer stordriftsfordelene tilbake til våre små og mellomstore kunder.

Low-Rank Adaptation (LoRA)

Måle effektiviteten av tilpasning

Vi trenger evalueringsmål for å vurdere effektiviteten til den tilpassede løsningen. Evalueringsberegninger frakoblet fungerer som beskyttelsesrekkverk mot frakttilpasninger som er lavere enn standardmodellen. Ved å bygge datasett fra et holdt ut datasett fra det angitte depotet, kan tilpasningstilnærmingen brukes på dette datasettet for å måle effektiviteten. Sammenligning av eksisterende kildekode med det tilpassede kodeforslaget kvantifiserer nytten av tilpasningen. Vanlige mål som brukes for denne kvantifiseringen inkluderer beregninger som rediger likhet, eksakt samsvar og KodeBLEU.

Det er også mulig å måle nytten ved å kvantifisere hvor ofte interne API-er påkalles av tilpasningen og sammenligne den med påkallelsene i den eksisterende kilden. Selvfølgelig er det viktig å få begge aspektene riktig for en vellykket gjennomføring. For vår tilpasningstilnærming har vi designet en skreddersydd beregning kjent som Customization Quality Index (CQI), et enkelt brukervennlig mål som varierer mellom 1 og 10. CQI-beregningen viser nytten av forslagene fra den tilpassede modellen sammenlignet med kode forslag med en generisk offentlig modell.

Oppsummering

Vi bygde Amazon CodeWhisperer-tilpasningsevne basert på en blanding av de ledende tekniske teknikkene som er omtalt i dette blogginnlegget og evaluerte det med brukerstudier om utviklerproduktivitet, utført av Persistent Systems. I disse to studiene, på oppdrag fra AWS, ble utviklere bedt om å lage en medisinsk programvareapplikasjon i Java som krevde bruk av deres interne biblioteker. I den første studien tok utviklere uten tilgang til CodeWhisperer (i gjennomsnitt) ~8.2 timer på å fullføre oppgaven, mens de som brukte CodeWhisperer (uten tilpasning) fullførte oppgaven 62 prosent raskere på (i gjennomsnitt) ~3.1 timer.

I den andre studien med et annet sett med utviklerkohorter, fullførte utviklere som brukte CodeWhisperer som hadde blitt tilpasset ved hjelp av deres private kodebase oppgaven på 2.5 timer i gjennomsnitt, 28 prosent raskere enn de som brukte CodeWhisperer uten tilpasning og fullførte oppgaven på ~3.5 timer i gjennomsnitt. Vi er overbevist om at verktøy som CodeWhisperer som er tilpasset kodebasen din har en nøkkelrolle å spille for ytterligere å øke utviklerproduktiviteten, og anbefaler å prøve det. For mer informasjon og for å komme i gang, besøk Amazon CodeWhisperer-side.

---

Om forfatterne

Qing Sun er en Senior Applied Scientist i AWS AI Labs og jobber med AWS CodeWhisperer, en generativ AI-drevet kodingsassistent. Hennes forskningsinteresser ligger i Natural Language Processing, AI4Code og generativ AI. Tidligere hadde hun jobbet med flere NLP-baserte tjenester som Comprehend Medical, et medisinsk diagnosesystem hos Amazon Health AI og Machine Translation-system hos Meta AI. Hun mottok sin doktorgrad fra Virginia Tech i 2017.

Arash Farahani er en Applied Scientist med Amazon CodeWhisperer. Hans nåværende interesser er generativ AI, søk og personalisering. Arash er lidenskapelig opptatt av å bygge løsninger som løser smertepunkter for utviklere. Han har jobbet med flere funksjoner innen CodeWhisperer, og introdusert NLP-løsninger i ulike interne arbeidsstrømmer som berører alle Amazon-utviklere. Han mottok sin doktorgrad fra University of Illinois i Urbana-Champaign i 2017.

Xiaofei Ma er en Applied Science Manager i AWS AI Labs. Han begynte i Amazon i 2016 som en Applied Scientist i SCOT-organisasjonen og senere AWS AI Labs i 2018 og jobbet på Amazon Kendra. Xiaofei har fungert som vitenskapssjef for flere tjenester, inkludert Kendra, Contact Lens, og sist CodeWhisperer og CodeGuru Security. Hans forskningsinteresser ligger innen området AI4Code og Natural Language Processing. Han mottok sin doktorgrad fra University of Maryland, College Park i 2010.

Murali Krishna Ramanathan er en hovedanvendt vitenskapsmann i AWS AI Labs og leder AWS CodeWhisperer, en generativ AI-drevet kodefølge. Han brenner for å bygge programvareverktøy og arbeidsflyter som bidrar til å forbedre utviklernes produktivitet. Tidligere bygde han Piranha, et automatisert refactoring-verktøy for å slette kode på grunn av foreldede funksjonsflagg og ledet kodekvalitetsinitiativer hos Uber engineering. Han er mottaker av Googles fakultetspris (2015), ACM SIGSOFT Distinguished paper award (ISSTA 2016) og Maurice Halstead-prisen (Purdue 2006). Han fikk sin doktorgrad i informatikk fra Purdue University i 2008.

Ramesh Nallapati er Senior Principal Applied Scientist i AWS AI Labs og leder CodeWhisperer, en generativ AI-drevet kodingskompanjong, og Titan Large Language Models ved AWS. Hans interesser er hovedsakelig innen områdene Natural Language Processing og Generative AI. Tidligere har Ramesh gitt vitenskapelig lederskap i å levere mange NLP-baserte AWS-produkter som Kendra, Quicksight Q og Contact Lens. Han hadde forskerstillinger ved Stanford, CMU og IBM Research, og fikk sin Ph.D. i informatikk fra University of Massachusetts Amherst i 2006.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/customizing-coding-companions-for-organizations/