Forbedre ytelsen til generative språkmodeller med selvkonsistens på Amazon Bedrock | Amazon Web Services

Forbedre ytelsen til generative språkmodeller med selvkonsistens på Amazon Bedrock | Amazon Web Services

Generative språkmodeller har vist seg bemerkelsesverdig dyktige til å løse logiske og analytiske oppgaver for naturlig språkbehandling (NLP). Videre bruk av rask prosjektering kan spesielt forbedre ytelsen deres. For eksempel, tankekjede (CoT) er kjent for å forbedre en modells kapasitet for komplekse flertrinnsproblemer. For å i tillegg øke nøyaktigheten på oppgaver som involverer resonnement, en selvkonsistens Det har blitt foreslått en tilskyndende tilnærming, som erstatter grådig med stokastisk dekoding under språkgenerering.

Amazonas grunnfjell er en fullstendig administrert tjeneste som tilbyr et utvalg av høyytende fundamentmodeller fra ledende AI-selskaper og Amazon via et enkelt API, sammen med et bredt sett med muligheter for å bygge generativ AI applikasjoner med sikkerhet, personvern og ansvarlig AI. Med batch-slutning API, kan du bruke Amazon Bedrock til å kjøre inferens med grunnlagsmodeller i grupper og få svar mer effektivt. Dette innlegget viser hvordan du implementerer selvkonsistensspørring via batch-inferens på Amazon Bedrock for å forbedre modellytelsen på aritmetiske og flervalgsresonneringsoppgaver.

Oversikt over løsning

Språkmodellers selvkonsistens er avhengig av generering av flere svar som samles til et endelig svar. I motsetning til enkeltgenerasjonstilnærminger som CoT, skaper selvkonsistensprøve-og-marginaliseringsprosedyren en rekke modellfullføringer som fører til en mer konsistent løsning. Generering av forskjellige svar for en gitt forespørsel er mulig på grunn av bruken av en stokastisk, snarere enn grådig, dekodingsstrategi.

Den følgende figuren viser hvordan selvkonsistens skiller seg fra grådig CoT ved at den genererer et mangfoldig sett med resonnementbaner og samler dem for å produsere det endelige svaret.

Forskjeller mellom selvkonsistens og CoT-forespørsel.

Avkodingsstrategier for tekstgenerering

Tekst generert av dekoder-bare språkmodeller utfolder seg ord for ord, med det påfølgende symbolet forutsagt på grunnlag av den foregående konteksten. For en gitt ledetekst beregner modellen en sannsynlighetsfordeling som indikerer sannsynligheten for at hvert token vises neste i sekvensen. Dekoding innebærer å oversette disse sannsynlighetsfordelingene til faktisk tekst. Tekstgenerering formidles av et sett med slutningsparametere som ofte er hyperparametre for selve dekodingsmetoden. Et eksempel er temperatur, som modulerer sannsynlighetsfordelingen til neste token og påvirker tilfeldigheten til modellens utdata.

Grådig avkoding er en deterministisk dekodingsstrategi som ved hvert trinn velger token med høyest sannsynlighet. Selv om tilnærmingen er enkel og effektiv, risikerer den å falle inn i repeterende mønstre, fordi den ser bort fra det bredere sannsynlighetsrommet. Å sette temperaturparameteren til 0 ved inferenstidspunkt tilsvarer i hovedsak å implementere grådig dekoding.

sampling introduserer stokastisitet i dekodingsprosessen ved å tilfeldig velge hvert påfølgende token basert på den forutsagte sannsynlighetsfordelingen. Denne tilfeldigheten resulterer i større utgangsvariabilitet. Stokastisk dekoding viser seg å være flinkere til å fange mangfoldet av potensielle utdata og gir ofte mer fantasifulle svar. Høyere temperaturverdier introduserer flere svingninger og øker kreativiteten til modellens respons.

Oppfordringsteknikker: CoT og selvkonsistens

Resonneringsevnen til språkmodeller kan forsterkes via prompt engineering. Spesielt har CoT vist seg å fremkalle resonnement i komplekse NLP-oppgaver. En måte å implementere en nullskudd CoT er via umiddelbar utvidelse med instruksjonen om å "tenke trinn for trinn." En annen er å eksponere modellen for eksempler på mellomliggende resonnementtrinn få skudds tilskyndelse mote. Begge scenariene bruker vanligvis grådig dekoding. CoT fører til betydelige ytelsesgevinster sammenlignet med enkel instruksjon som ber om aritmetiske, sunn fornuft og symbolske resonnementoppgaver.

Selvkonsistens ber om er basert på antakelsen om at det å introdusere mangfold i resonneringsprosessen kan være fordelaktig for å hjelpe modeller til å konvergere til riktig svar. Teknikken bruker stokastisk dekoding for å oppnå dette målet i tre trinn:

  1. Spør språkmodellen med CoT-eksemplarer for å fremkalle resonnement.
  2. Erstatt grådig dekoding med en samplingsstrategi for å generere et mangfoldig sett med resonnementbaner.
  3. Aggreger resultatene for å finne det mest konsistente svaret i svarsettet.

Selvkonsistens er vist å overgå CoT-anmodninger på populære aritmetiske og sunne resonnementer. En begrensning ved tilnærmingen er dens større beregningskostnad.

Dette innlegget viser hvordan selvkonsistens-spørring forbedrer ytelsen til generative språkmodeller på to NLP-resonneringsoppgaver: aritmetisk problemløsning og flervalgsdomenespesifikk spørsmålssvar. Vi demonstrerer tilnærmingen ved å bruke batch-inferens på Amazon Bedrock:

  • Vi får tilgang til Amazon Bedrock Python SDK i JupyterLab på en Amazon SageMaker notatbokforekomst.
  • For aritmetiske resonnementer spør vi Sammenhengende kommando på GSM8K-datasettet med matematiske problemer på grunnskolen.
  • For flervalgsbegrunnelse spør vi AI21 Labs Jurassic-2 Mid på et lite utvalg spørsmål fra AWS Certified Solutions Architect – Associate-eksamen.

Forutsetninger

Denne gjennomgangen forutsetter følgende forutsetninger:

Administrer modelltilgang på Amazon Bedrock

Den estimerte kostnaden for å kjøre koden vist i dette innlegget er $100, forutsatt at du kjører selvkonsistensspørring én gang med 30 resonneringsbaner ved å bruke én verdi for den temperaturbaserte prøvetakingen.

Datasett for å undersøke aritmetiske resonneringsevner

GSM8K er et datasett med menneskesammensatte matematiske problemer på grunnskolen med et høyt språklig mangfold. Hver oppgave tar 2–8 trinn å løse og krever å utføre en sekvens av elementære beregninger med grunnleggende aritmetiske operasjoner. Disse dataene blir ofte brukt til å benchmarke multi-trinns aritmetiske resonneringsevner til generative språkmodeller. De GSM8K togsett omfatter 7,473 poster. Følgende er et eksempel:

{"question": "Natalia sold clips to 48 of her friends in April, and then she sold half as many clips in May. How many clips did Natalia sell altogether in April and May?", "answer": "Natalia sold 48/2 = <<48/2=24>>24 clips in May.nNatalia sold 48+24 = <<48+24=72>>72 clips altogether in April and May.n#### 72"}

Sett opp for å kjøre batch-inferens med Amazon Bedrock

Batch-inferens lar deg kjøre flere inferensanrop til Amazon Bedrock asynkront og forbedre ytelsen til modellslutning på store datasett. Tjenesten er i forhåndsvisning når dette skrives og kun tilgjengelig via API. Referere til Kjør batch-slutning for å få tilgang til batch-inferens-APIer via egendefinerte SDK-er.

Etter at du har lastet ned og pakket ut Python SDK i en SageMaker notatbokforekomst kan du installere den ved å kjøre følgende kode i en Jupyter notatbokcelle:

# Install preview SDK packages
!pip install -q $(ls ./bedrock-python-sdk-reinvent/botocore-*.whl | head -1)
!pip install -q $(ls ./bedrock-python-sdk-reinvent/boto3-*.whl | head -1)

Formater og last opp inndata til Amazon S3

Inndata for batch-inferens må forberedes i JSONL-format med recordId og modelInput nøkler. Sistnevnte skal matche kroppsfeltet til modellen som skal påberopes på Amazon Bedrock. Spesielt noen støttede slutningsparametere for Cohere Command er temperature for tilfeldighet, max_tokens for utgangslengde, og num_generations å generere flere svar, som alle sendes sammen med prompt as modelInput:

data = [
    {
        "recordId": "1",
        "modelInput": {
            "prompt": prompt,
            "temperature": temperature,
            "max_tokens": max_tokens,
            "num_generations": n,
        },
    },
    ...,
]

Se Inferensparametere for fundamentmodeller for mer informasjon, inkludert andre modellleverandører.

Eksperimentene våre på aritmetisk resonnement utføres i få-skudd-innstillingen uten å tilpasse eller finjustere Cohere Command. Vi bruker det samme settet med åtte få-skudd-eksempler fra tankekjeden (Tabell 20) og selvkonsistens (Tabell 17) papirer. Forespørsler opprettes ved å sette sammen eksemplene med hvert spørsmål fra GSM8K-togsettet.

Vi setter max_tokens til 512 og num_generations til 5, det maksimale tillatt av Cohere Command. For grådig avkoding setter vi temperature til 0 og for selvkonsistens, kjører vi tre eksperimenter ved temperaturer 0.5, 0.7 og 1. Hver innstilling gir forskjellige inngangsdata i henhold til de respektive temperaturverdiene. Data formateres som JSONL og lagres i Amazon S3.

# Set up S3 client
session = boto3.Session()
s3 = session.client("s3")

# Create S3 bucket with unique name to store input/output data
suffix = str(uuid.uuid4())[:8]
bucket = f"bedrock-self-consistency-{suffix}"
s3.create_bucket(
    Bucket=bucket, CreateBucketConfiguration={"LocationConstraint": session.region_name}
)

# Process data and output to new lines as JSONL
input_key = f"gsm8k/T{temperature}/input.jsonl"
s3_data = ""
for row in data:
    s3_data += json.dumps(row) + "n"
s3.put_object(Body=s3_data, Bucket=bucket, Key=input_key)

Opprett og kjør batch-inferensjobber i Amazon Bedrock

Batch-inferensjobboppretting krever en Amazon Bedrock-klient. Vi spesifiserer S3-inn- og utgangsbanene og gir hver påkallingsjobb et unikt navn:

# Create Bedrock client							    
bedrock = boto3.client("bedrock")

# Input and output config						     
input_config = {"s3InputDataConfig": {"s3Uri": f"s3://{bucket}/{input_key}"}}
output_config = {"s3OutputDataConfig": {"s3Uri": f"s3://{bucket}/{output_key}"}}

# Create a unique job name
suffix = str(uuid.uuid4())[:8] 
job_name = f"command-batch-T{temperature}-{suffix}"

Jobber er opprettet ved å overføre IAM-rollen, modell-ID, jobbnavn og input/output-konfigurasjon som parametere til Amazon Bedrock API:

response = bedrock.create_model_invocation_job(
    roleArn=f"arn:aws:iam::{account_id}:role/BedrockBatchInferenceRole",
    modelId="cohere.command-text-v14",
    jobName=job_name,
    inputDataConfig=input_config,
    outputDataConfig=output_config,
)
job_arn = response["jobArn"]

Listing, overvåkingog stoppe batch-inferensjobber støttes av deres respektive API-kall. Ved opprettelse vises jobber først som Submitted, deretter som InProgress, og til slutt som Stopped, Failedeller Completed.

# Get job details
job_details = bedrock.get_model_invocation_job(jobIdentifier=job_arn)

Hvis jobbene er fullført, kan det genererte innholdet hentes fra Amazon S3 ved å bruke dets unike utdataplassering.

# Get the output file key
s3_prefix = f"s3://{bucket}/"
output_path = job_details["outputDataConfig"]["s3OutputDataConfig"]["s3Uri"].replace(
    s3_prefix, ""
)
output_folder = job_details["jobArn"].split("/")[1]
output_file = (
    f'{job_details["inputDataConfig"]["s3InputDataConfig"]["s3Uri"].split("/")[-1]}.out'
)
result_key = f"{output_path}{output_folder}/{output_file}"

# Get output data
obj = s3.get_object(Bucket=bucket, Key=result_key)
content = obj["Body"].read().decode("utf-8").strip().split("n")

# Show answer to the first question
print(json.loads(content[0])["modelOutput"]["generations"][0]["text"])

[Out]: 'Natalia sold 48 * 1/2 = 24 clips less in May. This means she sold 48 + 24 = 72 clips in April and May. The answer is 72.'

Selvkonsistens forbedrer modellens nøyaktighet på aritmetiske oppgaver

Cohere Command-anmodning om selvkonsistens overgår en grådig CoT-grunnlinje når det gjelder nøyaktighet på GSM8K-datasettet. For selvkonsistens prøver vi 30 uavhengige resonneringsbaner ved tre forskjellige temperaturer, med topP og topK satt til deres standardverdier. Endelige løsninger aggregeres ved å velge den mest konsistente forekomsten via flertallsavstemning. Ved uavgjort, velger vi tilfeldig ett av flertallets svar. Vi beregner verdier for nøyaktighet og standardavvik i gjennomsnitt over 100 kjøringer.

Følgende figur viser nøyaktigheten på GSM8K-datasettet fra Cohere Command spurt med grådig CoT (blå) og selvkonsistens ved temperaturverdier 0.5 (gul), 0.7 (grønn) og 1.0 (oransje) som en funksjon av antall samplede resonnementveier.

Nøyaktighet av Cohere Command ved bruk av selvkonsistens vs CoT-forespørsel.

Den foregående figuren viser at selvkonsistens øker aritmetisk nøyaktighet i forhold til grådig CoT når antallet samplede baner er så lavt som tre. Ytelsen øker konsekvent med videre resonnementbaner, og bekrefter viktigheten av å introdusere mangfold i tankegenerasjonen. Cohere Command løser GSM8K-spørsmålssettet med 51.7 % nøyaktighet når det blir bedt om med CoT vs. 68 % med 30 selvkonsistente resonneringsbaner ved T=1.0. Alle de tre undersøkte temperaturverdiene gir lignende resultater, med lavere temperaturer som er relativt mer effektive ved færre samplede baner.

Praktiske betraktninger om effektivitet og kostnad

Selvkonsistens er begrenset av den økte responstiden og kostnadene som påløper når du genererer flere utdata per forespørsel. Som en praktisk illustrasjon, batch-slutning for grådig generering med Cohere Command på 7,473 GSM8K-poster ble fullført på mindre enn 20 minutter. Jobben tok 5.5 millioner tokens som input og genererte 630,000 XNUMX output tokens. For tiden Amazon Bedrock slutningspriser, var de totale kostnadene rundt $9.50.

For selvkonsistens med Cohere Command bruker vi inferensparameter num_generations for å opprette flere fullføringer per forespørsel. Når dette skrives, tillater Amazon Bedrock maksimalt fem generasjoner og tre samtidige Submitted batch inferens jobber. Jobbene fortsetter til InProgress status sekvensielt, derfor krever sampling av mer enn fem baner flere påkallinger.

Følgende figur viser kjøretidene for Cohere Command på GSM8K-datasettet. Total kjøretid vises på x-aksen og kjøretid per samplet resonneringsbane på y-aksen. Grådig generasjon går på kortest tid, men pådrar seg en høyere tidskostnad per samplet bane.

Kjøretider for Cohere Command

Grådig generasjon fullfører på mindre enn 20 minutter for hele GSM8K-settet og prøver en unik resonneringsvei. Selvkonsistens med fem prøver krever omtrent 50 % lengre tid å fullføre og koster rundt $14.50, men produserer fem baner (over 500%) på den tiden. Total kjøretid og kostnad øker trinnvis for hver fem ekstra samplede baner. En kostnad-nytte-analyse antyder at 1–2 batch-slutningsjobber med 5–10 samplede baner er den anbefalte innstillingen for praktisk implementering av selvkonsistens. Dette oppnår forbedret modellytelse samtidig som kostnadene og ventetiden holdes i sjakk.

Selvkonsistens forbedrer modellens ytelse utover aritmetiske resonnementer

Et avgjørende spørsmål for å bevise egnetheten til selvkonsistens-tilskyndelse er om metoden lykkes på tvers av ytterligere NLP-oppgaver og språkmodeller. Som en utvidelse til en Amazon-relatert brukssak, utfører vi en liten analyse på eksempelspørsmål fra AWS Solutions Architect Associate-sertifisering. Dette er en flervalgseksamen om AWS-teknologi og -tjenester som krever domenekunnskap og evnen til å resonnere og bestemme mellom flere alternativer.

Vi utarbeider et datasett fra SAA-C01 og SAA-C03 eksempler på eksamensspørsmål. Fra de 20 tilgjengelige spørsmålene bruker vi de første 4 som få-skuddseksempler og ber modellen om å svare på de resterende 16. Denne gangen kjører vi slutninger med AI21 Labs Jurassic-2 Mid-modellen og genererer maksimalt 10 resonnementbaner på temperatur 0.7. Resultatene viser at selvkonsistens forbedrer ytelsen: selv om grådig CoT gir 11 riktige svar, lykkes selvkonsistens på 2 til.

Følgende tabell viser nøyaktighetsresultatene for 5 og 10 samplede baner i gjennomsnitt over 100 kjøringer.

. Grådig avkoding T = 0.7
# samplede baner: 5 68.6 74.1 ± 0.7
# samplede baner: 10 68.6 78.9 ± 0.3

I følgende tabell presenterer vi to eksamensspørsmål som er feil besvart av grådig CoT mens selvkonsistens lykkes, og fremhever i hvert tilfelle de riktige (grønne) eller feilaktige (røde) resonnementsporene som førte til at modellen ga riktige eller feilaktige svar. Selv om ikke hver samplet bane generert av selvkonsistens er korrekt, konvergerer flertallet på det sanne svaret etter hvert som antallet samplede baner øker. Vi observerer at 5–10 baner vanligvis er nok til å forbedre de grådige resultatene, med avtagende avkastning når det gjelder effektivitet forbi disse verdiene.

Spørsmål

En nettapplikasjon lar kunder laste opp bestillinger til en S3-bøtte. De resulterende Amazon S3-hendelsene utløser en Lambda-funksjon som setter inn en melding i en SQS-kø. En enkelt EC2-instans leser meldinger fra køen, behandler dem og lagrer dem i en DynamoDB-tabell partisjonert med unik ordre-ID. Neste måned forventes trafikken å øke med en faktor 10, og en løsningsarkitekt vurderer arkitekturen for mulige skaleringsproblemer.

Hvilken komponent trenger mest sannsynlig re-arkitektur for å kunne skaleres for å imøtekomme den nye trafikken?

A. Lambdafunksjon
B. SQS-kø
C. EC2-forekomst
D. DynamoDB-tabell

En applikasjon som kjører på AWS bruker en Amazon Aurora Multi-AZ DB-klyngedistribusjon for sin database. Ved evaluering av ytelsesmålinger oppdaget en løsningsarkitekt at databaselesingene forårsaker høy I/O og legger til latens til skriveforespørslene mot databasen.

Hva bør løsningsarkitekten gjøre for å skille leseforespørslene fra skriveforespørslene?

A. Aktiver gjennomlest caching på Aurora-databasen.
B. Oppdater applikasjonen for å lese fra Multi-AZ standby-forekomsten.
C. Lag en Aurora-replika og modifiser applikasjonen for å bruke de riktige endepunktene.
D. Opprett en andre Aurora-database og koble den til den primære databasen som en lesereplika.

Korrekt svar C – En enkelt EC2-instans vil ikke skaleres og er et enkelt feilpunkt i arkitekturen. En mye bedre løsning ville være å ha EC2-forekomster i en Auto Scaling-gruppe på tvers av 2 tilgjengelighetssoner som leser meldinger fra køen. De andre svarene er alle administrerte tjenester som kan konfigureres til å skalere eller skaleres automatisk. C – Aurora-replikaer gir en måte å avlaste lesetrafikk. Aurora Replicas deler den samme underliggende lagringen som hoveddatabasen, så forsinkelsestiden er generelt veldig lav. Aurora Replicas har sine egne endepunkter, så applikasjonen må konfigureres for å dirigere lesetrafikk til de nye endepunktene.
Grådig avkoding Det er kanskje ikke mulig å skalere EC2-forekomsten direkte, da det kanskje ikke er mulig å endre størrelse på forekomsten. Skalering av lambdafunksjonen er kanskje ikke tilstrekkelig, da Lambda-funksjoner har en 6 GB minneallokeringsgrense. Skalering av SQS-køen er kanskje ikke tilstrekkelig, ettersom SQS har en grense på 10,000 XNUMX meldinger. DynamoDB-tabeller kan skaleres ved å klargjøre flere kapasitetsenheter. Riktig svar er D. Endring av programmet for å lese fra Multi-AZ standby-forekomsten (alternativ B) er den beste tilnærmingen. Standby-forekomsten replikeres asynkront fra primærforekomsten, så leseoperasjoner vil ikke forstyrre skriveoperasjoner. Aktiverer gjennomlest caching (alternativ A) eller opprettelse av en Aurora-replika (alternativ C) vil ikke løse I/O-stridsproblemet. Å opprette en andre Aurora-database og koble den som en lesereplika (alternativ D) vil heller ikke løse I/O-stridsproblemet. Riktig svar er B.
Prøvebane #1 Det er kanskje ikke mulig å skalere EC2-forekomsten til 10 ganger dens nåværende størrelse, verken fra et kostnads- eller ytelsesperspektiv. Det vil kreve en større instans, som kan være dyrt. En mer kostnadseffektiv tilnærming kan være å bruke en sverm av mindre forekomster (f.eks. Auto Scaling Group) for å dele belastningen. I dette tilfellet vil EC2-forekomsten sannsynligvis måtte re-arkitekteres. Riktig svar er C. Å endre applikasjonen for å bruke de riktige endepunktene er ikke en praktisk løsning, da det vil kreve endringer i applikasjonskoden. Det riktige svaret er C: Lag en Aurora-replika og modifiser applikasjonen for å bruke de riktige endepunktene.
Prøvebane #2 Å skalere en enkelt EC2-instans er vanskeligere og mer problematisk enn å skalere de andre tjenestekomponentene. Amazon SQS, Lambda og DynamoDB kan alle skaleres automatisk for å takle den økte belastningen. Riktig svar er C.

(C) Lag en Aurora-replika og modifiser applikasjonen for å bruke de riktige endepunktene.

Ved å konfigurere en Aurora Replica kan du skille lesetrafikk fra skrivetrafikk. Aurora-replikaene bruker forskjellige endepunkts-URLer, slik at du kan dirigere lesetrafikk til replikaen i stedet for primærdatabasen. Replikaen kan behandle leseforespørsler parallelt med skriveforespørsler til primærdatabasen, reduserer I/U og latens.

Rydd opp

Å kjøre batch-slutninger i Amazon Bedrock er underlagt gebyrer i henhold til Amazons grunnfjellspriser. Når du har fullført gjennomgangen, sletter du SageMaker-notebook-forekomsten og fjerner alle data fra S3-bøttene dine for å unngå fremtidige kostnader.

betraktninger

Selv om den demonstrerte løsningen viser forbedret ytelse for språkmodeller når du blir bedt om med selvkonsistens, er det viktig å merke seg at gjennomgangen ikke er produksjonsklar. Før du distribuerer til produksjon, bør du tilpasse dette proof of concept til din egen implementering, med tanke på følgende krav:

  • Tilgangsbegrensning til APIer og databaser for å forhindre uautorisert bruk.
  • Overholdelse av beste praksis for AWS-sikkerhet angående IAM-rolletilgang og sikkerhetsgrupper.
  • Validering og sanering av brukerinndata for å forhindre umiddelbare injeksjonsangrep.
  • Overvåking og logging av utløste prosesser for å muliggjøre testing og revisjon.

konklusjonen

Dette innlegget viser at selvkonsistens øker ytelsen til generative språkmodeller i komplekse NLP-oppgaver som krever aritmetiske og flervalgslogiske ferdigheter. Selvkonsistens bruker temperaturbasert stokastisk dekoding for å generere ulike resonneringsbaner. Dette øker modellens evne til å lokke fram ulike og nyttige tanker for å komme frem til riktige svar.

Med Amazon Bedrock batch-inferens, blir språkmodellen Cohere Command bedt om å generere selvkonsistente svar på et sett med aritmetiske problemer. Nøyaktigheten forbedres fra 51.7 % med grådig dekoding til 68 % med selvkonsistens-sampling 30 resonneringsbaner ved T=1.0. Sampling av fem baner øker allerede nøyaktigheten med 7.5 prosentpoeng. Tilnærmingen kan overføres til andre språkmodeller og resonneringsoppgaver, som demonstrert av resultatene fra AI21 Labs Jurassic-2 Mid-modellen på en AWS-sertifiseringseksamen. I et lite spørsmålssett øker selvkonsistens med fem samplede baner nøyaktigheten med 5 prosentpoeng i forhold til grådig CoT.

Vi oppfordrer deg til å implementere selvkonsistens-forespørsel for forbedret ytelse i dine egne applikasjoner med generative språkmodeller. Lære mer om Sammenhengende kommando og AI21 Labs Jurassic modeller tilgjengelig på Amazon Bedrock. For mer informasjon om batch-inferens, se Kjør batch-slutning.

Takk til

Forfatteren takker tekniske anmeldere Amin Tajgardoon og Patrick McSweeney for nyttige tilbakemeldinger.


om forfatteren

Forbedre ytelsen til generative språkmodeller med selvkonsistensspørring på Amazon Bedrock | Amazon Web Services PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Lucía Santamaría er en Sr. Applied Scientist ved Amazons ML University, hvor hun har fokusert på å heve nivået av ML-kompetanse i hele selskapet gjennom praktisk utdanning. Lucía har en doktorgrad i astrofysikk og brenner for å demokratisere tilgang til teknisk kunnskap og verktøy.

Tidstempel:

Mer fra AWS maskinlæring