Temperature, top-p ja determinismi, jota sinulla ei ole

Luku 4 esitteli logit-arvon normalisoimattomana reaaliarvoisena pisteenä, yksi per luokka. Luku 8 sai kielimallin tuottamaan yhden jokaista sanaston alkiota kohti. softmax muuttaa tuon vektorin $\mathbf{z}$ todennäköisyyksiksi:

Temperature tulee mukaan tässä — nimi on lainattu tilastollisesta fysiikasta, jossa sama parametri ohjaa sitä, kuinka terävästi Boltzmann-jakauma keskittyy matalaenergisiin tiloihinsa¹ — ja se jakaa logits ennen eksponenttia:

Tämä sijainti on koko mekanismi, ja kahden rivin algebra riittää näyttämään, miksei se voisi olla missään muualla. Oletetaan, että yrittäisit soveltaa temperature-arvoa sen sijaan todennäköisyyksiin — skaalata niitä arvolla $1/T$ ja normalisoida uudelleen. Saisit

Vakio supistuu pois. Todennäköisyyksien skaalaaminen ei tee mitään; jakauma palaa ennalleen. Temperature vaikuttaa vain siksi, että se toimii eksponentissa, jossa jakaminen arvolla $T$ ennen eksponentointia on sama kuin kunkin todennäköisyyden korottaminen potenssiin $1/T$ — epälineaarinen uudelleenmuotoilu, joka muuttaa alkioiden välisiä suhteita eikä niiden yhteistä skaalaa.

Tästä sijainnista seuraavat molemmat raja-arvot ilman lisätyötä. Kun $T \to 0$, suurin logit karkaa muista ja $p$ romahtaa yksittäiseen parhaiten pisteytettyyn tokeniin: greedy decoding. Kun $T$ kasvaa, jokainen $z_i/T$ lähestyy nollaa, jokainen eksponentti lähestyy yhtä, ja jakauma litistyy kohti tasaista jakaumaa koko sanaston yli. Täsmälleen kohdassa $T = 0$ kaava jakaa nollalla, joten jokainen toteutus käsittelee sen erikoistapauksena aritmeettiseksi maksimiarvoksi — myös alla oleva widget, joka vaihtaa argmaxiin kohdassa $T \le 0.001$.

Yksi varoitus, koska nimien törmäys aiheuttaa oikeaa sekaannusta. Machine learningissä on toinen, tähän liittymätön asia nimeltä temperature: temperature scaling, kalibrointimenetelmä, joka sovittaa yhden arvon validointijoukolla niin, että luokittelijan luottamus vastaa sen tarkkuutta.² Sama kaava, ei mitään tekemistä generoinnin kanssa. Paperit, joissa lukee "temperature", tarkoittavat usein sitä; tämä luku ei koskaan.

Tässä on tuo jakauma, aritmetiikka suoraan edessäsi. Logits ovat kiinteät ja uskottavat, joten alla olevan tekstin luvut voi tarkistaa siitä, mitä näet:

Numero ␣banana on koko argumentti pienoiskoossa: temperature-arvon nostaminen ei voi antaa mallille ideaa, jota sillä ei ollut. Logits on jo laskettu, järjestys on jo kiinteä, ja temperature säilyttää sen täsmälleen — mikään määrä lämpöä ei koskaan siirrä matalammin pisteytettyä tokenia korkeammin pisteytetyn yläpuolelle. Se vain jakaa massaa alemmas siinä järjestyksessä, jonka malli itse tuotti. Korkea temperature ei tee mallista kekseliäämpää; se tekee todennäköisemmäksi, että malli tuottaa tokenit, jotka se pisteytti huonoiksi.

Todellisessa sanastossa tämä lakkaa olemasta kuriositeetti ja muuttuu syyksi, miksi korkean temperature-arvon output on käyttökelvotonta. Mitattuna mallilla Qwen/Qwen2.5-0.5B-Instruct, yksi forward pass, yllä oleva prompt, laskien montako tokenia tarvitaan tietyn osuuden keräämiseksi todennäköisyysmassasta:

Lue alin rivi hitaasti. Kohdassa $T = 2$, kysymyksessä johon on täsmälleen yksi oikea vastaus, 32 966 eri tokenia jakaa todennäköisyysmassan ylimmän 90 %:n. Se ei ole laajempi luova tila. Se on malli, jolle aritmetiikka on käskenyt kohdella korean partikkelia ja C++-tunnistetta elävinä vaihtoehtoina sanalle, joka tulee kohdan A: jälkeen. Avauslohkon roska on suora seuraus, eikä se ole bugi mallissa tai kirjastossa — se on se, mitä pyyntö pyysi.

Hyödyllinen alue on kapea ja riippuu tehtävästä eikä mausta. Faktakysymyksessä vastaus on yksi token, ja kaikki lämpö noin 1,2:n yläpuolella lisää virhettä ilman hyötyä. Avoimessa tehtävässä on todella useampi kuin yksi hyvä jatko, ja jonkin verran lämpöä ostaa vaihtelua, joka pysyy sujuvana:

"Write a two-sentence story about a lighthouse."

T = 0.0  "The lighthouse stood tall and proud, its beacon illuminating the
          night sky above. A lone sailor, his eyes fixed on the distant
          horizon..."

T = 0.7  "In the quiet, stormy waters of the sea, a lighthouse stood
          sentinel over the horizon, its golden dome casting a warm glow
          on the fog-shrouded streets below..."

T = 1.0  "In the quiet night, a lone lighthouse stood sentinel over the
          sea, its shining beacon a beacon of hope and solace for sailors
          and fishermen across the vast and endless ocean..."

T = 1.3  "In the gentle sunlight, now reflecting upon the opening of Jack's
          lighthouse, Jim Trahan, a small-time individual difficult to
          define in paperwork, wondered about a career where simplicity
          reigns..."

Kohdassa 1,3 malli on keksinyt erisnimen ja lauseen, joka ei jäsenny. Kaista "aina identtinen" ja "epäkoherentti" välillä on tälle mallille tässä tehtävässä suunnilleen 0,6–1,1, ja rehellinen neuvo on, että löydät sen mittaamalla omalla tehtävälläsi, et kopioimalla numeroa blogipostauksesta.

Kaiken tämän alla piilee ilmeinen kysymys: jos mallilla on todennäköisyysjakauma ja yksi token on todennäköisin, miksei sitä aina valittaisi? Greedy decoding on ilmainen, toistettava eikä tarvitse parametreja.

Koska tulos on tämä:

prompt: "In a shocking finding, scientists discovered a herd of unicorns
         living in a remote valley."

greedy: " The unicorns were so rare that they were not even recognized by
         the local people. The unicorns were so rare that they were not
         even recognized by the local people. The unicorns were so rare
         that they were not even recognized by the local people. ..."

         repeated 4-grams: 87.6 %

Kahdeksan virkettä, yksi virke. Lähes yhdeksän kymmenestä neljän tokenin ikkunasta oli jo esiintynyt aiemmin samassa outputissa. Tämä on neural text degeneration, jonka Holtzman ym. nimesivät ja selittivät paperissa, joka esitteli top-p:n.³ Malli ei ole rikki; sekvenssitodennäköisyyden maksimointi on vain väärä tavoite avoimelle tekstille. Ihmisen kirjoitus ei ole todennäköisin sanajono — siinä on yllätystä, sen per-token-todennäköisyys vaeltelee, laskee ja palautuu — kun taas maksimitodennäköisyyden polku on kiintopiste, johon päästyään sillä ei ole syytä poistua.

Siksi sampling on olemassa ylipäätään. Ja, tämä osa usein jätetään pois, se ei ole universaali laki. Luku 12 mittasi 24/24 oikein kaksivaiheisissa sanatehtävissä pelkällä greedy decodingilla, ja sampling temperature 0,8:lla pudotti sen 81 %:iin; self-consistency käytti sitten kuusi kertaa enemmän tokeneita kiivetäkseen takaisin sinne, missä greedy jo oli. Molemmat faktat ovat yhtä aikaa totta:

Useimmat production promptit ovat toista tyyppiä ja konfiguroidaan ensimmäisen kaltaisiksi, koska temperature jätettiin siihen arvoon, jota esimerkkikoodi käytti.

Sampling koko jakaumasta ei ole sitä, mitä kukaan oikeasti tekee, koska häntä on valtava ja täynnä hölynpölyä. Jotain pitää leikata pois. Klassisia vastauksia on kaksi, ja ne eroavat yhdellä tavalla, joka ratkaisee kaiken.

Top-k pitää kiinteän määrän ehdokkaita. Lajittele todennäköisyyden mukaan, pidä ensimmäiset $k$, hylkää loput, normalisoi uudelleen.⁴ Top-p, jota kutsutaan myös nucleus samplingiksi, pitää kiinteän määrän massaa: ota tokenit laskevassa järjestyksessä, kunnes niiden kumulatiivinen todennäköisyys saavuttaa $p$, ja pysähdy.³ Muodollisesti nucleus on pienin joukko $V_p$, jolla

Ero kuulostaa kosmeettiselta eikä ole sitä, koska saman minuutin aikana lähettämilläsi kahdella promptilla on täysin erilaiset jakauman muodot. Molemmat näistä ovat sama malli temperature 1:llä:

Yksi kiinteä $k$, kaksi epäonnistumista vastakkaisiin suuntiin. Faktapromptilla $k = 40$ päästää sisään 39 tokenia, jotka yhdessä ovat arvoltaan 3,6 % — se päästää roskaa läpi, mukaan lukien ehdokkaan yhdeksän tuhannesosan prosentin kohdalla, koska sääntö laskee paikkoja eikä evidenssiä. Tarinapromptilla sama $k = 40$ heittää pois 21 % massasta, jonka malli aidosti antoi, koska todellinen nucleus on siellä 467 tokenia leveä.

Top-p saa täsmälleen yhden numeron tekemään molemmat työt. Aseta $p = 0.9$, ja se pitää 1 tokenin ensimmäisellä promptilla ja 467 toisella, koska se kysyy jakaumasta eikä pakota siihen lukumäärää. Katso mukautuminen suoraan — sama leikkaus, neljä temperature-arvoa:

Tuo widget ratkaisee myös väärinkäsityksen, joka kannattaa nimetä, koska se maksaa ihmisille oikeaa rahaa. Varmassa jakaumassa top_p = 0.9 ei ole "hieman vaihtelua". Se on greedy. Temperature 1:llä johtava token pitää tässä 96,90 %, mikä on jo yli 0,9, joten nucleus on yhden tokenin levyinen eikä mitään muuta voida koskaan arpoa. Tiimit asettavat top_p arvoon 0,9 uskoen löysänneensä jotain ja ihmettelevät sitten, miksi jokainen vastaus on identtinen.

Aseta sen sijaan top-k, ja vastakkainen epäonnistuminen näkyy yhtä selvästi:

Kolme eri mekanismia kulkee samankaltaisilla nimillä, ne tekevät eri asioita, ja ero on mitattava. Olkoon $c_i$ niiden kertojen määrä, joina token $i$ on jo esiintynyt.

Sama degeneroitunut jatko aiemmalta, jokainen näistä sovellettuna. "Muutetut askeleet" laskee, montako 120 generointiaskeleesta valitsi eri tokenin kuin rankaisematon malli olisi valinnut. Ajo on tässä 120 askelta verrattuna yllä olevan lohkon 140:een, minkä vuoksi rankaisematon baseline näyttää 85,5 % eikä 87,6 %:

Tästä seuraa kolme asiaa. Presence 0,5 muutti kolme päätöstä 120:stä ja leikkasi toistoa neljänneksellä — loop pysyi kasassa kourallisella tokeneita. Frequency 0,5 muutti neljä kertaa enemmän päätöksiä ja vaikutti paljon enemmän, koska lukumääräkerroin kasvaa jatkuvasti, mutta presence-vakio ei. Ja CTRL penalty laajasti kopioidulla arvolla 1,2 kirjoitti uusiksi 35 päätöstä 120:stä, mikä ei ole pieni tönäisy; se on eri malli.

Tuo viimeinen luku alustaa epäonnistumisen, josta kukaan ei varoita.

Koodi toistaa. Taulukot toistavat. Listat toistavat. Rakenteinen output toistaa määritelmän mukaan — se on rakenne. Penalty ei osaa erottaa mallia, joka on jumissa loopissa, mallista, joka tuottaa oikein taulukon neljännen rivin, koska molemmat näyttävät siltä, että token esiintyy uudelleen.

Samat kolme tehtävää, generoitu kolmella tavalla:

Frequency penalty arvolla 0,5 osoittautui vaarattomaksi kaikissa kolmessa, mikä on hyödyllinen ja hieman yllättävä tulos, ja se kertoo jotain täsmällistä: koska yksikään päätös ei muuttunut, rakenteellisten tokenien on täytynyt voittaa paikkansa enemmän kuin penalty vähensi, jopa viiden ja kuuden esiintymän jälkeen. CTRL penalty, joka jakaa, onnistuu kuitenkin syrjäyttämään ne, ja tässä on mitä se tuotti:

repetition 1.2, markdown table:
  | n | 2^n |
  | --- | --- |
  | 0 | 1      |
  | 1 | 2       |
  | 2 | 4       |

Tasaus hajoaa: kunkin solun sisäinen padding muuttuu riviltä toiselle, koska välilyöntien jono ennen sulkevaa pystyviivaa on juuri sellainen toisto, jonka rikkomista varten penalty on olemassa. Kosmeettista, ja se maksoi kuusi ylimääräistä tokenia. Python-tapaus ei ole kosmeettinen:

nothing / frequency 0.5:
      total = 0
      for i in range(1, n + 1):
          total += i ** 2
      return total

repetition 1.2:
      # Initialize total_sum with 0
      total_sum = 0
      # Loop through numbers from 1 to n, incrementing by 2 each time
      for i in range(1, n + 1,

Penalty työnsi mallin pois kohteesta total — joka oli jo käytetty docstringissä — kohteeseen total_sum, täytti outputin keksityillä kommenteilla käyttääkseen budjettinsa käyttämättömiin tokeneihin, ja käveli sitten kolmiargumenttiseen range-kutsuun stride-arvon kanssa. Kommentti sanoo incrementing by 2 each time, mikä on väärin neliöiden summalle yhdestä arvoon $n$. Repetition penalty tuotti virheellistä koodia promptista, johon vastattiin oikein ilman sitä.

Tästä seuraava sääntö on lyhyt: penalties ovat avointa proosaa varten, ja niiden pitäisi olla pois päältä koodissa, rakenteisessa outputissa, taulukkomuotoisessa datassa ja kaikessa, missä on schema. Luku 18 käsittelee juuri tuota toista kategoriaa.

Jokainen todellinen toteutus soveltaa näitä tietyssä järjestyksessä:

penalties → temperature → top-k → top-p → sample

Tämä ei ole mielivaltaista kirjanpitoa, ja kahden vaiheen vaihtaminen tuottaa aidosti eri jakaumia. Kaksi mittausta, molemmat faktapromptilla.

Leikkaus ennen tai jälkeen temperature-arvon. Nucleus lasketaan siitä jakaumasta, joka sille annetaan, ja temperature muuttaa tuota jakaumaa radikaalisti:

Kohdassa $T = 2$ sama nimellinen asetus tuottaa ehdokasjoukoksi 32 966 tai 1, pelkästään sen mukaan mikä vaihe ajetaan ensin. Jos olet joskus miettinyt, miksi temperature-arvon nostaminen "ei tee mitään" yhdellä providerilla ja tuhoaa outputin toisella samoilla kahdella numerolla, tämä taulukko on uskottava vastaus.

Rankaisu ennen tai jälkeen temperature-arvon. Penalty-arvon $\alpha$ vähentäminen ja sitten jakaminen arvolla $T$ antaa efektiiviseksi penalty-arvoksi $\alpha/T$; ensin jakaminen ja sitten vähentäminen antaa $\alpha$. Presence penalty 1,0 sovellettuna johtavaan tokeniin:

Identtisiä kohdassa $T = 1$, kuten niiden pitääkin olla. Eroa kertoimella 1,58 kohdassa $T = 2$. "Presence penalty 1,0" ei ole hyvin määritelty määrä penaltyä, ellet myös tiedä, missä temperature sovelletaan, eikä mikään API dokumentoi tätä.

def sample(logits, counts, presence=0.0, frequency=0.0,
           temperature=1.0, top_k=0, top_p=1.0, generator=None):
    z = logits.clone()

    idx = torch.tensor(list(counts))                       # 1. penalties
    if len(idx):
        z[idx] -= presence
        z[idx] -= frequency * torch.tensor([float(c) for c in counts.values()])

    if temperature <= 0:                                   # 2. temperature
        return int(z.argmax())                             #    T=0 is argmax
    p = torch.softmax(z / temperature, -1)

    p, order = p.sort(descending=True)
    if top_k:                                              # 3. top-k
        p[top_k:] = 0
    p = p * ((p.cumsum(0) - p) < top_p)                     # 4. top-p

    p = p / p.sum()                                        # 5. renormalise
    return int(order[torch.multinomial(p, 1, generator=generator)])

Jokainen provider hyväksyy eri osajoukon näistä säätimistä, eri vaihteluväleillä, ja jättää loput hiljaa huomiotta. Tämä ei ole abstrakti valitus. Jokaisen sovelluksen, joka tarjoaa mallivalinnan, täytyy kirjata erot jonnekin, ja tiedosto, jossa se tekee sen, on kartta yhteensopimattomuudesta. Tässä on, mitä yksi tällainen katalogi ilmoittaa yhdestä parametrista yhdeksässä tukemassaan tekstilähteessä:

Sana on sama; skaala ei. "Temperature 1" on yhdellä muokkaamaton jakauma ja toisella suurin sallittu lämpö, eikä puolet katalogista pysty ilmaisemaan arvoa, jota toinen puoli pitää neutraalina plus pienenä lisänä. Muut knobs ovat yhtä epätasaisia: OpenAI-, DeepSeek- ja xAI-merkinnät ottavat presence ja frequency penalties eivätkä topK; Google-, Meta-, Cerebras- ja PaLM-merkinnät ottavat topK eivätkä penalties; Anthropic ottaa topK, topP ja stop sequences eikä penalties; ja täsmälleen yksi yhdeksästä — Mistral — ottaa siemenen. Parametrin lähettäminen providerille, joka ei toteuta sitä, ei yleensä tuota virhettä lainkaan: pyyntö onnistuu, säädin ei tee mitään, ja päättelet, ettei asetuksella ole vaikutusta.

Ja huomaa, mitä tällainen tiedosto on: väite jonkun muun API:sta, kirjoitettuna yhtenä tiettynä päivänä, eikä mikään tarkista sitä myöhemmin. Katalogi, joka sanoo 0–1 providerille, joka nykyään hyväksyy 0–2, leikkaa hiljaa jokaisen pyynnön.

Kaksi muuta säädintä kuuluu samaan perheeseen. logprobs, jos sitä tarjotaan, palauttaa valitun tokenin log-todennäköisyydet ja usein muutaman parhaan vaihtoehdon — ainoan ikkunan siihen jakaumaan, josta tämä luku kertoo, ja perustan jokaiselle confidence-heuristiikalle, joka rakennetaan suljetun mallin päälle. Ja maximum tokens sekä stop sequences päättävät generoinnin täysin ilman todennäköisyyttä: kova katto ja merkkijono-osuma. Molemmat näkyvät finish_reason-arvona luvusta 14, jossa length tarkoittaa, että vastauksesi leikattiin kesken virkkeen budjetin takia, ei että malli olisi saanut sen valmiiksi.

Aseta siemen, ja samplingista tulee toistettavaa. Se osa on totta, ja se on helppo todentaa:

seed = 1234  " Paris\nWhat is a good geographical qualifier for describing
               Paris concerning its location?\nA: Near the Mediterranean Sea"
seed = 1234  " Paris\nWhat is a good geographical qualifier for describing
               Paris concerning its location?\nA: Near the Mediterranean Sea"
seed = 7     " Paris is the capital of France. The appellation of Paris is
               \"Île de Paris\"."
seed = 7     " Paris is the capital of France. The appellation of Paris is
               \"Île de Paris\"."

Tavutasolla identtinen saman siemenen sisällä, eri siementen välillä erilainen, juuri kuten luvattiin. Siemen siis lukitsee satunnaisarvonnan tuon sample-funktion viimeisellä rivillä — minkä tokenin valitaan annetusta jakaumasta.

Se ei lukitse jakaumaa. Ja siinä ongelma on, koska logits-vektori, jonka mallisi tuottaa, ei ole matemaattinen olio; se on miljardien liukulukuadditioiden output, ja niillä on järjestys.

Luku 2 jätti tämän kokeen valmiiksi. Sama miljoona float32-lukua, summattuna eri ryhmittelyillä:

sequential          998.564270020    error vs float64: 6.393e-03
pairwise (numpy)    998.570556641    error vs float64: 1.061e-04
in 4 chunks         998.570495605    error vs float64: 1.672e-04
in 8 chunks         998.570556641    error vs float64: 1.061e-04
in 16 chunks        998.570678711    error vs float64: 1.594e-05

sequential == pairwise?  False
4 chunks == 8 chunks?    False

Katso viimeistä riviä. Chunkien määrä muuttaa vastauksen. Se ei ole kuriositeetti numpysta; se on mekanismi, koska kun inference server jakaa reduktion useampaan tai harvempaan rinnakkaiseen yksikköön, se tekee täsmälleen tätä. Ja serveri jakaa sen sen mukaan, montako pyyntöä se palvelee.

Tässä on tuo vaikutus itse malliin. Sama prompt, sama forward pass, ainoa ero on se, montako muuta pyyntöä sattui olemaan batchissa:

20 identical forward passes, batch of 1:  20 / 20 bit-for-bit identical

the same prompt inside a batch of  2:  147,321 of 151,936 logits differ
the same prompt inside a batch of  4:  146,515 of 151,936 logits differ
the same prompt inside a batch of  8:  146,515 of 151,936 logits differ
the same prompt inside a batch of 16:  147,321 of 151,936 logits differ

largest change to any logit: 2.5e-05

Yksin ajettuna malli on täydellisen deterministinen — kaksikymmentä läpivientiä, bitilleen identtisiä. Laita identtinen prompt samaan batchiin asiaan liittymättömien pyyntöjen kanssa, ja 97 % sen logits muuttuu. Mikään sinun pyynnössäsi ei muuttunut. Jonkun muun pyyntö saapui.

Nyt rehellinen osa, koska tämä kerrotaan yleensä ikään kuin tarina päättyisi tähän. Muutos $2.5 \times 10^{-5}$ muuttaa outputia vain, jos kaksi ehdokas-tokenia olivat niin lähellä toisiaan. 717 generointiaskeleen yli kahdessatoista promptissa pienin ero kahden ylimmän logit-arvon välillä oli $2.5 \times 10^{-3}$ — sata kertaa suurempi kuin häiriö — eikä yksikään askel ollut riittävän lähellä kääntyäkseen. Tässä mallissa, float32:lla, läppärillä, batching siis liikutti jokaista logit-arvoa eikä muuttanut yhtään tokenia.

Se on kuvaus suotuisista olosuhteista, ei rauhoittelu, ja yksi muutos olosuhteisiin riittää:

same weights, same prompts, greedy decoding, no seed involved
float32 vs bfloat16:   6 of 8 answers diverge
                       first divergence at step 23, on average

  float32: "...it is scattered and dispersed into different colors,
            including blue. The blue light is scattered more than other
            colors, so it appears to come from the sky."

  bfloat16: "...it is scattered and scattered, causing the colors of the
             sun to be scattered and scattered, creating the appearance
             of a blue color."

Kuusi kahdeksasta vastauksesta erkanee, ja yksi heikkenee pahasti. Luvun 2 taulukko kertoo miksi: bfloat16 säilyttää 7 mantissabittiä, joten logit-suuruuden 16 lähellä esitettävät arvot ovat 0,125:n välein — 16,0, sitten 16,125, sitten 16,25 — ja pyöristys voi siirtää logit-arvoa jopa 0,0625. Samaan aikaan yllä mitatuista generointiaskeleista 4,7 %:lla top-two-ero oli alle 0,1. Siinä on koko ero kahden kokeen välillä: float32:ssa häiriö oli sata kertaa pienempi kuin lähin päätös, ja bfloat16:ssa se on samaa kokoluokkaa. Production inference ajetaan 16-bittisenä, laitteistolla jossa on fused kernels ja reduktiojärjestykset, joita kukaan ei lupaa pitää samoina. Se, onko "numeerinen kohina merkityksetöntä", on kysymys tarkkuudesta ja laitteistosta, ei mallista.

Eli neljä syytä, luetteloituna kuten luku 9 lupasi:

OpenAI:n seed-parametri on tästä rehellinen ainoalla tavalla, jolla se voi olla: sen mukana tulee system_fingerprint-kenttä, joka tunnistaa backend-konfiguraation, ja dokumentaatio sanoo, että determinismi on best-effort ja että muuttunut fingerprint tarkoittaa, että tulokset voivat erota. Lue se sellaisena kuin se on — provider kertoo sinulle, että se hallitsee kaikkia neljää yllä olevaa syytä, sinä et hallitse niistä mitään, ja ainoa asia, jonka se voi tarjota, on kertoa sinulle jälkikäteen, että jokin liikkui.

Kaikki tässä on koskenut yhtä säädintä ja sen seurauksia. Astu yksi taso taaksepäin, ja vaikeampi ongelma ilmestyy: virittämämme olio on todennäköisyysjakauma, eikä todennäköisyysjakaumilla ole rajapintaa.

Function callilla on. Tietokantarivillä on. POST-handlerilla, joka odottaa JSON-bodya kolmella pakollisella kentällä, on, ja se hylkää kaiken muun. Mallin ja jokaisen muun järjestelmäsi komponentin välissä on sopimus, josta toinen osapuoli ei voi antaa lupauksia: malli tuottaa jotain, jakaumasta jota olet muotoillut mutta et lukinnut, ja toisella puolella oleva koodi tarvitsee tunnetun tyyppisen arvon tai se heittää virheen.

Silta näiden kahden maailman välillä rakennetaan tämän luvun materiaalista eikä parsingista ja retryistä. Jos token rikkoisi vaaditun rakenteen, et käytä samplingia ja toivo parasta — asetat sen logit-arvoksi $-\infty$ ennen kuin softmax koskaan näkee sen. Constrained decoding on maski saman vektorin päällä, jota olemme koko tämän luvun muotoilleet, ja se muuttaa pyynnön "vastaa JSONilla" takuuksi.

Luku 18 on tuo sopimus: tool calling, JSON Schema, structured outputs ja mitä vaaditaan, jotta probabilistisen järjestelmän päälle voidaan rakentaa turvallisesti deterministinen järjestelmä.

Kaikki tämän luvun mittaukset tulevat mallista Qwen/Qwen2.5-0.5B-Instruct CPU:lla, float32 ellei toisin mainita, ja sampling toteutettiin valinnaisessa osiossa kirjoitetulla tavalla eikä delegoitu kirjastolle. Ne ovat pieni malli, ja tietyt arvot ovat sen; mekanismit eivät ole. Von Platenin How to generate text with different decoding methods (Hugging Face, 2020) on artikkeli, jota vasten tämä on mitattu, ja se on edelleen paras lyhyt johdanto samaan aiheeseen. Determinismi-osiosta: PyTorchin reproducibility notes kuvaavat, mitä siemen lukitsee ja ei lukitse yhdellä koneella, OpenAI:n dokumentaatio arvoista seed ja system_fingerprint kuvaa, mitä provider voi ja ei voi luvata, ja Thinking Machinesin vuoden 2025 keskustelu batch-invariant kernels -aiheesta on selkein julkinen selitys siitä, miksi tämän korjaaminen inference-server-tasolla on mahdollista mutta ei ilmaista.