AI-keskustelumallit voivat aiheuttaa kustannuksia päättömällä sanoilla

Monet suositut AI-keskustelumallit kuluttavat huomattavia määriä maksettuja symboleja turhien sanojen vuoksi. Vaikuttuneet mallit tietävät itse, mitä he tekevät, mutta eivät voi estää itseään.

Suuret päättelymallit (kuten ChatGPT-5 ja Google Gemini) laskuttavat enemmän päättelystä – ongelman ratkaisemisesta askel askeleelta, mikä vaatii huomattavasti enemmän laskentakapasiteettia kuin pelkästään seuraavan sanan nopea ennustaminen. Simuloitu päättelyprosessi kestää kauemmin ja maksaa enemmän suorittaa; tämän seurauksena käyttäjät joutuvat maksamaan tästä “lisäajasta”.

Kuitenkin, jos olet käyttänyt äskettäin viimeisintä LLM-mallia, huomasi ehkä, että token-aloituksesi on usein kulutettu turhien sanojen ja roskaan sijaan ongelman ratkaisemiseen. Tämä voi ilmetä liiallisen imartelun muodossa, pitkien ja/tai tarpeettomien vastausten muodossa – tai jopa “päätömiin” sanoihin, kuin AI olisi jäänyt kiinni ja yrittää puhua itsensä ulos epämukavasta tilanteesta.

Luonnollisesti, meidän olisi mieluummin, että LLM-mme myöntävät tappionsa, seuraavat vaihtoehtoisia polkuja tai pyytävät selvennystä. Mutta jopa saada AI tällaisen myöntymään, ettei se tiedä vastausta, on huomattava haaste itsessään.

Sillä aikaa, käyttäjät alempien tai ilmaisten tasoilla voivat löytää itsensä polttaneen tokeninsa nopeasti, riippumatta siitä, kuinka kohdennetut tai taloudelliset heidän kysymyksensä ja vuorovaikutuksensa olivat, koska AI itse rakastaa puhua; ja tässä tapauksessa, puhuminen ei ole halpaa.

Sana-salaatti

Sanoittamattoman “päätömiin” sanojen suhteen, uusi akateeminen yhteistyö tarjoaa selityksen ja ratkaisun ehdottamalla, että LLM-mallit, joilla on päättelykyky, ovat taipuvaisia polttamaan tokenisi, kun ne joutuvat “sana-salaatti”- silmukkaan – hämmennystilan, jossa päättelyprosessi menee eksyksiin toistuvasti – omalla kustannuksella*.

Tutkijat, jotka ovat kirjoittaneet uuden tutkimuksen, ovat havainneet, että merkittävä osa LLM-mallin prosessoiduista symboleista koostuu toistuvuuksista ja tarpeettomuuksista – ja että malli itsessään tietää, että se on vaikeuksissa, vaikka se ei voi lopettaa kalliita silmukkaa.

Tutkimus toteaa:

‘Osoitamme, että merkittävä osa näistä symboleista on tarpeettomia itseensä toistuvia – mitä me kutsumme “sana-salaatiksi” – jotka kuluttavat dekoodausbudjettia ilman arvon lisäämistä. Mielenkiintoista on, että havaitsemme, että LRM-mallit ovat itsetietoisia, kun ne joutuvat näihin silmukoihin: piilotilat, jotka seuraavat jokaisen päättelylohkon, osoittavat kuvioita, jotka sallivat meidän havaita sana-salaatti-käyttäytymistä lennossa yksinkertaisen lineaarisen luokittelijan avulla.

‘Kun sana-salaatti on havaittu, yksinkertainen leikkaus, johon on liitetty suora uudelleenluontipyyntö, antaa merkittäviä säästöjä vähäisen laadun menetyksen kera.’

Uuden tutkimuksen tarjoama ratkaisu on intervention, joka voi lopettaa LRM-mallin kiertämisen prosessin lennossa, ilman koulutusdatan sisällyttämistä tai vahinkoa, joka voi aiheutua hienosäätöä käyttämällä. Runko, joka on nimeltään Sana-Salaatti-Leikkaaja, on julkaistu GitHubissa.

Vaikka alkuperäinen työ keskittyy DeepSeek-versioihin, kuten Qwen- ja Llama-sarjoihin, tutkimus toteaa, että ei-toivottu käyttäytyminen on todennäköisesti sovellettavissa laajemmin samanlaisiin päättelymalliin (mukaan lukien suositut API-vain tarjoajat, kuten ChatGPT ja Google Gemini).

Kuten tutkimus toteaa, aiemmat tarjoukset, kuten Demystifying Long Chain-of-Thought Reasoning in LLMs ja Small Models Struggle to Learn from Strong Reasoners käyttävät pieniä määriä julkaistuja Chain-of-Thought (CoT) -päättelymalleja osoittamaan laajemman ongelman tämän malliluokan keskuudessa^†:

‘[LRM-mallit] tuhlautuvat valtavan määrän dekoodausbudjettia yksinkertaisesti toistamalla itseään

‘Me kutsumme tällaista käyttäytymistä Sana-Salaatiksi, termi, jota usein käytetään pilkatakseen julkisia puhujia antamasta pitkiä, täynnä jargonia vastauksia, jotka lopulta ovat sisällöltään tyhjiä tai epäselviä.’

Osuus output-symboleista, jotka on tunnistettu semanttisesti tarpeettomiksi GPQA-Diamond-vastauksissa. Sana-Salaatti-Leikkaaja vähentää tämän ylityön yli 55 prosentista alle 6 prosenttiin kaikissa testatuissa DeepSeek-R1-Distill-malleissa, kirjoittajat toteavat. Lähde

Kirjoittajat toteavat, että yritykset lyhentää päättelyprosesseja säilyttäen vastauslaatu on muodostunut vahvaksi alavirraksi tutkimuskirjallisuudessa, nimittäin pitkästä lyhyeen (L2S); ja huomauttavat, että vaikka heidän projektin tavoitteet ovat samanlaiset kuin joitakin aiempia aloitteita, heidän omansa on ensimmäinen, joka tarjoaa ad hoc -ratkaisun, joka ei vaadi interventiota koulutusprosessissa, mallin muokkausta tai muita mahdollisia vaikutuksia LLM-mallin perusrakenteeseen; ja uskovat, että heidän lähestymistapansa tulisi yleistyä soveltuvissa järjestelmissä^†:

‘Ottaen huomioon sen pieni ylityö, vahvat säästöt ja sana-salaatti-symboleiden puute semanttisesta arvosta, uskomme, että [Sana-Salaatti-Leikkaaja] – tai vastaava komponentti – on välttämätön kaikille LRM-sovelluksille, joissa on käyttäjäkokemus mielessä ‘

Tutkimus on nimeltään Word Salad Chopper: Reasoning Models Waste A Ton Of Decoding Budget On Useless Repetitions, Self-Knowingly, ja se on tehty kuuden tutkijan yhteistyönä Minnesotan yliopistosta, Ricen yliopistosta, Stevensin teknologiainstituutista ja Lambda, Inc:stä.

Aikaisemmat huomioonotot

Jotta voidaan seurata LRM-mallien taipumusta toistaa itseään, tutkijat jakavat mallin outputin palasiin, missä on kaksi rivinvaihtoa, ja tarkistavat, kuinka samanlaisia kunkin palasen on aikaisempiin verrattuna:

Arvioitu osuus päättelylohkoja, jotka on merkitty sana-salaatiksi kahdessa dekoodauslämpötilassa (τ = 0,0, 0,6). Luokittelija merkitsee lohkon “sana-salaatiksi”, kun se muistuttaa liian läheisesti aikaisempaa osaa mallin outputista, osoittaen toistoa sen sijaan, että edetäisiin eteenpäin. Tulokset osoittavat, että tämä käyttäytyminen on laajasti levinnyt eri tietojoukoissa ja mallikokoissa.

Jos palanen on liian samanlainen, se merkittyy sana-salaatiksi (vaikuttavasti tarpeettomaksi toistoksi).

Tutkijat toteavat, että kun malli menee “sana-salaatti”-tilaan, se on hyvin epätodennäköistä, että se pääsee siitä ilman ulkoista apua, vaan se jää kalliiseen silmukkaan, kunnes käyttäjän dekoodausbudjetti on kulutettu^††:

‘Tarpeettoman sanan, että tämä esittää katastrofaalisen ongelman käyttäjille, koska ihanteellisesti paljon lyhyempi ajattelijakausi on nyt maksimoitu tarpeettomin toistoin. Joten käyttäjä maksaa nyt maksimihinnan (todennäköisesti) väärästä vastauksesta, samalla kun hän kestää pisin loppuun asti viive.’

Sana-salaatti-lohkojen osuus ennen ja jälkeen leikkauspistettä (ts. hetkeä, jolloin toistuva output alkaa hallita). Useimmat toistot tapahtuvat tämän pisteen jälkeen, osoittaen, että kun malli menee sana-salaatti-silmukkaan, se harvoin palautuu ilman interventiota.

Tutkijat kertovat yllättyneensä, kun he huomasivat, että päättelykykyiset LRM-mallit osoittavat merkkejä siitä, että ne tietävät sana-salaatti-tilastaan. Kuitenkin juuri tämä tietoisuus ja se, miten se sisältyy mallin todennäköiseen päättelytilaan, mahdollistaa interventiojärjestelmän:

‘Keveyden ansiosta tämä lineaarinen luokittelija avaa oven lennossa havaitsemiseen, jossa voimme tehokkaasti interventiolla eri toimilla mallien, jotka ovat jääneet sana-salaatti-silmukoihin.’

Menetelmä

Jotta voidaan havaita sana-salaatin läsnäolo dekoodauksen aikana, tutkijat kouluttivat yksinkertaisen lineaarisen luokittelijan, joka toimii kunkin kaksoisrivivaihdon piilotilassa.

Mikä tahansa palanen, joka tapahtui mallin jäätyä toistosilmukkaan, kohdeltiin sana-salaattina, ja tämä leikkauspiste (jota kutsutaan leikkauspisteeksi) käytettiin koulutusdatan merkitsemiseen. Tuhat päättelyjälkeä generoitiin S1-benchmarkilla, ja kunkin jälki jaettiin rivivaihtojen mukaisiin palasiin.

Käsitteellinen schema Sana-Salaatti-Leikkaajalle. Generoinnin aikana kunkin kaksoisrivivaihdon piilotila analysoidaan toistuvien segmenttien havaitsemiseksi. Kun kaksi sana-salaatti-palasta on merkitty peräkkäin, generointi pysäytetään. Kiinteä uudelleenluontipyyntö liitetään, jotta malli voi jatkaa ja vastata ilman dekoodausbudjetin ylittämistä.

Jos palanen oli hyvin samanlainen kuin aikaisempi, se merkittiin sana-salaatiksi. Kun ensimmäinen pysyvä toisto havaittiin, kaikki myöhemmät palaset merkittiin myös sana-salaatiksi, jotta nämä silmukat voitiin havaita.

Luokittelija toteutettiin yhtenä täysin kytketyssä kerroksessa ja koulutettiin viimeisen transformaattorin piilotilojen avulla. Erillinen luokittelija koulutettiin kullekin mallille, ja tätä dataa käytettiin, eikä hienosäätöä tehty arvioinnin aikana.

Data ja testit

Koulutus ja dekoodaus käyttivät neljää NVIDIA A100 (80G VRAM) -näytönohjainta Adam -optimoinnin alla, oppiakoron ollessa 1×10^-2, 50 epokan ajan.

Arviointidatana käytettiin ‘Grade School Math’ 8000, eli GSM8K; MATH-500; GPQA-DIAMOND; ja AIME25 (2025).

Testatuissa malleissa olivat DeepSeek-R1-Distill-Qwen-1.5B; DeepSeek-R1-Distill-Qwen-7B; ja DeepSeek-R1-Distill-Llama-8B, kaikki MIT-lisenssillä.

Käytetyt mittarit olivat Tarkkuus ja AUROC.

Sana-salaatti-luokittelijan tarkkuus ja AUROC Qwen-7B:llä neljällä benchmarkilla ja kahdella dekoodauslämpötilalla. Korkeat pisteet vahvistavat, että toiston alkamista voidaan luotettavasti havaita kaksoisrivivaihdon piilotilasta.

Tuloksista, jotka on esitetty tässä, tutkijat toteavat:

‘[Taulukko yllä] osoittaa, että lineaarinen luokittelija on erittäin tarkka sana-salaatti-palasten havaitsemisessa; [taulukko alla] osoittaa, että uudelleenluontipyyntö auttaa palauttamaan tehtävän tarkkuuden, joka menetettiin brutaali-leikkauksesta.’

Qwen-7B:n tarkkuus kussakin benchmarkissa τ = 0,6:ssa, vertailemassa suorituskykyä ennen sana-salaattia (Alkuperäinen), leikkaamisen jälkeen (Leikattu) ja uudelleenluonnin jälkeen (Uudelleenluotu). Uudelleenluonnin hyödyt ovat kohtuullisia, mutta johdonmukaisia, palauttaen enimmäkseen suorituskyvyn ennen silmukan alkamista useimmissa tapauksissa.

Tässä taulukossa voidaan nähdä, että Sana-Salaatti-Leikkaaja paransi tai säilytti tarkkuuden samalla, kun se vähensi merkittävästi mallin outputin pituutta, jopa 57 prosentilla:

Kun Sana-Salaatti-Leikkaaja käytetään ahneassa dekoodauksessa (τ = 0), se vähentää mallin outputin pituutta, joskus yli puolella, samalla kun se säilyttää tarkkuuden samana tai hieman parempana, suorituskyky, joka säilyy johdonmukaisena eri malleissa ja tehtävissä (AIME25 on jätetty pois tästä asetuksesta johtuen epävakaista suorituskyvystä).

Suurimmat hyödyt näkyivät pitemmissä vastauksissa, erityisesti GPQA-Diamondissa, jossa lähes puoli tekstistä poistettiin ilman suorituskyvyn heikentymistä. Alla voidaan nähdä samanlaiset tulokset, kun satunnaisuutta lisätään generointiin:

Korkeammassa lämpötilassa (τ = 0,6) Sana-Salaatti-Leikkaaja jatkaa lyhentämällä outputteja 10-30 prosentilla, tarkkuuden säilyessä vakaana tai hieman paranevana kaikissa malleissa ja benchmarkissa (AIME25-tulokset on keskitetty vähentämään vaihtelua).

Tässä tarkkuus säilyi vakaana, ja lyhyemmät outputit saavutettiin. Kaiken kaikkiaan järjestelmä jatkoi toimintaa, vaikka mallin vastaukset tulivat toistuvammiksi; ja tutkijat toteavat, että koska luokittelija tarkistaa vain yhden tokenin per lause, se suoritetaan erittäin nopeasti, jopa live-generoinnin aikana.

Tutkimus huomauttaa, että tulevaisuuden tutkimuksessa tämänkaltaisten strategioiden hyödyntäminen voisi hyötyä antamalla mallille pieni uudelleenluontibudjetti intervention jälkeen; jatkuva Sana-Salaatti-Leikkaajan kaltaisen järjestelmän soveltaminen uudelleenluontien aikana; ja pakottamalla “loppu-ajattelu”-token malliin, jotta se vaatii parasta mahdollista vastausta.

Lopuksi, tutkijat kommentoivat päättelymallien arvioinnin nykytilasta kriittisellä sävyllä^†:

‘On meille rehellinen usko, että monet tehokkaat päättelymenetelmät näyttävät tehokkailta osittain, koska nykyiset päättelyarvioinnin benchmarkit tarvitsevat paljon parantamista.

‘Kun kehitämme kattavampia arviointiohjelmia sarjoja – mitä varmasti teemme tulevaisuudessa – odotamme, että monet tehokkaat päättelymenetelmät epäonnistuvat tai käyttäytyvät eri tavoin kuin niiden perus-LRM-vastineet.’

Johtopäätös

Johtavien järjestelmien mittakaavassa, kuten ChatGPT:ssä, jopa pienet muutokset käyttäjän resurssien kulutuksessa voivat aiheuttaa merkittäviä infrastruktuurin, logistiikan ja kustannusvaikutuksia. Tämä tekee tehokkuuden jaettavaksi prioriteetiksi sekä tarjoajille että laajemmalle tutkimusyhteisölle.

Jos toteutettu, tutkimuksessa esitetty uusi ja kevyt järjestelmä (joka on koulutettava kullekin uudelle mallirakenteelle) voisi estää turhan tokenien polttamisen – mikä antaa asiakkaalle vaikutelman, että tarjoaja “vuotaa” heidän aloitustaan tuhlauksella. Totuudessa tarjoaja hyötyy enemmän antamalla hyödyllistä outputtia sen sijaan, että se toistaa itseään, mikä maksaa samaa laskentaresursseja.

* Vaikka emme selitä tätä tässä, tämä laajenee myös paikallisesti isännöityihin malleihin, jotka voivat olla sekä yritys- että harrastajien, ja joissa sana-salaatin sähkön- ja tuottavuuden menetykset voivat olla huomionarvoisia tekijöitä.

^† Yleensä kaikki korostukset ovat kirjoittajien, eivätkä minun. Missä sovellettavissa, heidän sisäiset viittauksensa on muutettu hyperlinkkeiksi minun toimestani.

^†† Tässä on tunnustettava, että kehykset ja API:t voivat määrittää “alibudjetin” kyselyille, joten yksittäinen kysely ei välttämättä pysty polttamaan koko päivän token-aloitusta – mutta tämä ei ole yleinen käytäntö eikä yleisesti keskusteltu aihe API-vain tarjoajien keskuudessa.

^††† En yleensä ole valmis omaksumaan kirjoittajien käyttämää ‘LRM’:n lyhennettä, koska se ei ole tällä hetkellä vakiintunut lyhenne, joten käytän muuta terminologiaa tässä artikkelissa tarpeen mukaan.

Julkaistu torstaina, 6. marraskuuta 2025