AI-koodausavustimet, keskustelua AI-avustetusta koodaamisesta/skriptaamisesta/dokumentoinnista/...

Päivässä miljoona aktiivista käyttäjää lisää + 5h limitit tilapäisesti pois päältä + resettejä. Ei ihme jos openai:n serverit hohkaa punaisena ja hitaammin tulee vastauksia.

Yritin googletella niin arvio on, että maailmassa olisi noin 35-40miljoonaa työkseen koodia tekevää. Tähän harrastelijat päälle. Aika paljon sais konesalia olla lisää, jos joku 90% porukasta siirtyis käyttämään ai-agenttilooppeja projekteissa. Tähän päälle ne uudet jotka vibe koodailevat omaa ei koodaustyötä helpommaksi.
1783971779915.png

1783971826959.png
 
Päivässä miljoona aktiivista käyttäjää lisää + 5h limitit tilapäisesti pois päältä + resettejä. Ei ihme jos openai:n serverit hohkaa punaisena ja hitaammin tulee vastauksia.

Yritin googletella niin arvio on, että maailmassa olisi noin 35-40miljoonaa työkseen koodia tekevää. Tähän harrastelijat päälle. Aika paljon sais konesalia olla lisää, jos joku 90% porukasta siirtyis käyttämään ai-agenttilooppeja projekteissa. Tähän päälle ne uudet jotka vibe koodailevat omaa ei koodaustyötä helpommaksi.
r/codex ryhmästä huomaa että sinne on tullut paljon turisteja.
Sitten on näitä vibekoodaajia. Ei siinä mitään, vibekoodaus on nykyään mun uusin harrastus. Jotkut vibekoodaa näköjään suoraan tuotantoon. Ei testejä, ei mitään. Sitten yöllä pätkähtää bugi päälle.

1783976796740.png
 
r/codex ryhmästä huomaa että sinne on tullut paljon turisteja.
Sitten on näitä vibekoodaajia. Ei siinä mitään, vibekoodaus on nykyään mun uusin harrastus. Jotkut vibekoodaa näköjään suoraan tuotantoon. Ei testejä, ei mitään. Sitten yöllä pätkähtää bugi päälle.
Vibe ammattilaiset on varmaan vähän aikaa samanlainen ilmiö kuin aikoinaan "kaikki" pelas pokeria voitollisesti ja oli eläköityminen päivätyöstä mielessä. Raha/Mahdollisuus houkuttelee porukkaa kokeilemaan.
 
Joitain päiviä sitten käytin codex resetin ja nyt katsoin että onko mulla tarpeeksi tokeneita jäljellä ja siellähän oli 3 resettiä jäljellä codex cli:ssä, mistä näitä tulee :D
 
Tämä on hiukan koominen. Sori jos oli mainittu aiemmin, mielestäni ei ollut.

Kontekstin koossa (ja siten hinnassa tai krediittien kulumisessa) voi säästää (ainakin Clauden kohdalla) muuttamalla kontekstin kuvaksi ennen mallille lähettämistä:

Samantyylistä nähnyt myös kuvien osalta. Muutetaan kuvan resoluutiota, värimäärää yms. niin että kone saa vielä kuvasta selvää ja vie vähemmän bittejä kuva muistissa. AI pystyy yllättävän paskaksi mankeloidun kuvan ymmärtämään.

Sellaista mietin joskus, että jos koodissa pakottaisi käytettävät kirjaimet esim. neljään bittiin, 16 kirjainta niin voisiko tehdä erittäin optimoidun inferenssimallin joka käyttäisi 16 kirjaimen ohjelmointikieltä versus 7/8bit ascii tai 16bit utf. Tämä vois olla hyvä aihe johonkin yliopiston paperiin ja tehdä oma pieni kielimalli jossa input-output rajattu 4bitin sisälle ja tunkis ulos c:ta missä rajattu 16 merkkiin mahdolliset kirjaimet. #define:llahan voi c:n operaattorit kirjoitella uusiksi, jos ei muuten 16 merkkiä riitä. Ehkä c:n vois mankeloida ilman, että käyttäjä edes tajuaa 4bit:iin.

Toinen mankelointi tietenkin olisi salaa muuttuu muuttujanimet, funktionimet jne. erittäin lyhyeksi tyyliin my_great_function(dkflksdfksdjf) olisikin aa(p1,p2) ja veisi paljon vähemmän tilaa. Ehkä työkalut tekevät tätä kontekstia luodessa,... Tämä olis helppo testata, sama koodi pitkillä muuttuja ja funktionimillä, viekä enemmän tokeneita kuin minimimittaan "obfuskoidulla".

--

Jännä nähdä missä tulee katto vastaan openai:n käyttäjämäärän kasvussa. Ja tietty se, että näkyykö jotenkin anthropic:in toiminnassa openai:n menestys.
 
Viimeksi muokattu:
Samantyylistä nähnyt myös kuvien osalta. Muutetaan kuvan resoluutiota, värimäärää yms. niin että kone saa vielä kuvasta selvää ja vie vähemmän bittejä kuva muistissa. AI pystyy yllättävän paskaksi mankeloidun kuvan ymmärtämään.

Sellaista mietin joskus, että jos koodissa pakottaisi käytettävät kirjaimet esim. neljään bittiin, 16 kirjainta niin voisiko tehdä erittäin optimoidun inferenssimallin joka käyttäisi 16 kirjaimen ohjelmointikieltä versus 7/8bit ascii tai 16bit utf. Tämä vois olla hyvä aihe johonkin yliopiston paperiin ja tehdä oma pieni kielimalli jossa input-output rajattu 4bitin sisälle ja tunkis ulos c:ta missä rajattu 16 merkkiin mahdolliset kirjaimet. #define:llahan voi c:n operaattorit kirjoitella uusiksi, jos ei muuten 16 merkkiä riitä. Ehkä c:n vois mankeloida ilman, että käyttäjä edes tajuaa 4bit:iin.

Toinen mankelointi tietenkin olisi salaa muuttuu muuttujanimet, funktionimet jne. erittäin lyhyeksi tyyliin my_great_function(dkflksdfksdjf) olisikin aa(p1,p2) ja veisi paljon vähemmän tilaa. Ehkä työkalut tekevät tätä kontekstia luodessa,... Tämä olis helppo testata, sama koodi pitkillä muuttuja ja funktionimillä, viekä enemmän tokeneita kuin minimimittaan "obfuskoidulla".

--

Jännä nähdä missä tulee katto vastaan openai:n käyttäjämäärän kasvussa. Ja tietty se, että näkyykö jotenkin anthropic:in toiminnassa openai:n menestys.
C:ssä tietysti kannattaisi poistaa kaikki turhat whitespacet. Mutta noiden funktioiden ja muuttujien nimien vaihto taitaisi hankaloittaa myös AI:n koodin ymmärtämistä koska kyllähän se noita käyttää.
 
C:ssä tietysti kannattaisi poistaa kaikki turhat whitespacet. Mutta noiden funktioiden ja muuttujien nimien vaihto taitaisi hankaloittaa myös AI:n koodin ymmärtämistä koska kyllähän se noita käyttää.
AI:lle ihan sama onko se aa vai this_is_a_monkey. Ihmiselle ei niin kun vain harvalla on identtinen muisti. Yks ex-työkaveri mulla ollut joka muistaa ihan kaikki koodit visuaalisesti mitä ikinä nähnyt, se kaveri omaa aika jännän muistin ja näkee matriisiin. Metadata mitä muuttuja tarkoittaa ja mitä sillä tehdään jne. muuttujanimen/funktionimen ulkopuolella.

Mankeloinnin lyhyeksi sais triviaalisti tehtyä skriptalla + huolehtii että mankelointi aina tehdään samalla tapaa niin this_is_a_monkey on aina aa. 4 bittiä versus 8bittiä tupla suorituskyky, puolet muistia. 4 bittiä versus 16bittiä 4x.
 
Viimeksi muokattu:
AI:lle ihan sama onko se aa vai this_is_a_monkey. Ihmiselle ei niin kun vain harvalla on identtinen muisti. Yks ex-työkaveri mulla ollut joka muistaa ihan kaikki koodit visuaalisesti mitä ikinä nähnyt, se kaveri omaa aika jännän muistin ja näkee matriisiin. Metadata mitä muuttuja tarkoittaa ja mitä sillä tehdään jne. muuttujanimen/funktionimen ulkopuolella.

Mankeloinnin lyhyeksi sais triviaalisti tehtyä skriptalla + huolehtii että mankelointi aina tehdään samalla tapaa niin this_is_a_monkey on aina aa. 4 bittiä versus 8bittiä tupla suorituskyky, puolet muistia. 4 bittiä versus 16bittiä 4x.
Miksei siis AI lainkaan huomioi noita? Ainakin se varhainen copilot, joka täydensi koodia kun kirjoitti (siis code completionin tyyliin) selvästi käytti noita nimiä ymmärtääkseen mitä tässä ollaan tekemässä. Jos funktion nimi oli joku get_foo niin se älysi tuosta nimestä tarkoituksen
 
Kysytään AI:lta itseltään:
Yes, variable names do matter to AI models, especially modern ones like code assistants and large language models. They don’t affect the compiler, but they strongly affect how well the AI understands and completes your code or data tasks.

How AI Uses Variable Names​

When an AI model looks at code, it doesn’t execute it or inspect runtime behavior; it mainly reads tokens such as identifiers, function names, and comments to infer intent. Descriptive names like maxRetries, customerAge, or calculateRefundAmount tell the model what a variable or function represents, which helps it predict the next line or suggestion much more accurately. In contrast, vague names like x, data, or handle give almost no semantic signal, so the model has to guess, and its suggestions are more likely to be off-topic or buggy.

Evidence from Experiments​

Recent experiments that tested multiple AI models on Python snippets with different naming styles found a clear pattern: descriptive variable names consistently led to better completions than obfuscated or ultra-short names. Metrics such as exact match rate and semantic similarity were significantly higher for code that used meaningful, self-explanatory names, even though those names consumed more tokens. This suggests that, for AI, clarity in naming is more valuable than keeping code ultra-concise or cryptic.

Beyond Code: Data and ML Pipelines​

The same idea applies when you use AI on datasets, logs, or configuration files: variable and column names act like labels that tell the model what each field means. Names such as cust_age or transaction_amount give useful context, while generic labels like val_1 or fieldA can cause the AI to misinterpret relationships between data points and produce low-quality or misleading outputs. In machine learning workflows, poorly named features, parameters, and intermediate dataframes make both human and AI reasoning harder, turning debugging and explanation into guesswork.

Practical Takeaways for You​

If you’re using AI coding tools, naming things well becomes a form of inline prompt engineering: your variable names, function names, and comments are literally part of the prompt the model sees. Clear, consistent, and specific names give the AI stronger context, yielding smarter completions, fewer mistakes, and faster development, while “temp”, “data”, and “foo”-style names reduce its understanding. This overlaps with classic clean-code advice: the same naming practices that help teammates (and your future self) also make AI assistance more effective and trustworthy.
 
AI:lle ihan sama onko se aa vai this_is_a_monkey. Ihmiselle ei niin kun vain harvalla on identtinen muisti. Yks ex-työkaveri mulla ollut joka muistaa ihan kaikki koodit visuaalisesti mitä ikinä nähnyt, se kaveri omaa aika jännän muistin ja näkee matriisiin. Metadata mitä muuttuja tarkoittaa ja mitä sillä tehdään jne. muuttujanimen/funktionimen ulkopuolella.

Mankeloinnin lyhyeksi sais triviaalisti tehtyä skriptalla + huolehtii että mankelointi aina tehdään samalla tapaa niin this_is_a_monkey on aina aa. 4 bittiä versus 8bittiä tupla suorituskyky, puolet muistia. 4 bittiä versus 16bittiä 4x.
Olisi kiva nähdä testi jossa käytetty a,b,c nimiä joka teknisesti tietenkin toimii ja sitten hieman kuvaavammilla. Pohdin LLMien keskustelutaipumuksia ja "" persoonia"" kun toisinaan huomaa että asian esittämisellä on suurikin vaikutus lopputulokseen. Tässä oletuksella että prompti itsessään olisi suppea ja codebase sitten lyhyillä tai kuvaavammilla nimeämisillä

Edit: ah Makis yllä ehtikin 😅
 
Olen nähnyt ihmisturistejakin. Erään kerran tuli toisesta tiimistä joku senior arkkitehti kyseleen. "sinä tiesit jotain linuxista? tuutko katsoon kun mulla olis yks juttu".

Yks juttu oli kun se oli yrittänyt jotain kirjastoa asentaa ja sen ansiosta lähtenyt koko ubuntu desktop helvettiin ja täysin väärät riippuvuudet sisässä, että vois desktopin asennella uusiksi. Tunti siinä meni setviessä että oli kone täysin normihengissä. Ajattelin että sama kai se on yrittää korjata vaikka olis omaa koodiakin tehtävänä. Admin/Sudo oikeudet koneeseen vaarallinen juttu, hiekkalaatikossa(docker, vm) parempi myllertää taviksen.
Olisi kiva nähdä testi jossa käytetty a,b,c nimiä joka teknisesti tietenkin toimii ja sitten hieman kuvaavammilla. Pohdin LLMien keskustelutaipumuksia ja "" persoonia"" kun toisinaan huomaa että asian esittämisellä on suurikin vaikutus lopputulokseen. Tässä oletuksella että prompti itsessään olisi suppea ja codebase sitten lyhyillä tai kuvaavammilla nimeämisillä

Edit: ah Makis yllä ehtikin 😅
C:hen on erinäköisiä code obfuskaattoreita. Jonku semmosen ajais vain asetuksella lyhennä metodinimet, funktionimet, parametrit kun kama menee ai:lle. Ihmispuolella pitäis obfuskoimattomat koodit. En kyllä ylläty jos noi koodausagentit tekevät jotain tuontyylistä taustalla kun nehän luovat ensin kontekstin, sitten konteksti lähetetään serverille prosessointiin. Sais sekä human readable että token optimized versiot helposti. Tuohon päälle vielä se 4bittiä per kirjain optimointi + 4bit per kirjain optimoitu llm ja pakotus obfuskaattorissa 16merkin(4bit) käyttöön versus 8bit ascii tai utf.

Motivaatio openai/anthropic/... jos saa puolitettua käytetyt tokenit samalla konesalilla voi tuplata liikevaihdon. Jos saat puolitettu mallin koon niin tuplaantuu tokenit/s ja puolittuu muistinvienti, riittää samat nvidiat paljon pidemmälle. Tän takia esim. nvfp4 on iso juttu ja tulevaisuudessa vielä pienemmän tarkkuuden blockiformaatit.

--

Maailma semmonen paikka, että ne vie jotka testaa ja tuotteistaa ideoita. EI -jengi ja ne jotka vaan ideoi mutta ei toteuta ei etene mihinkään tai menee taaksepäin. Joskus tarvii miettiä ja testata 10 ideaa, että löytyy yks oikeasti hyvä.
 
Viimeksi muokattu:
Siitä vaan testaamaan, siihen asti uskon mieluummin AI:n omaa käsitystä asiasta.
 
Siitä vaan testaamaan, siihen asti uskon mieluummin AI:n omaa käsitystä asiasta.
Se on vaan ihmisen kannalta kätevää sanoa että banaani sanassa on B A N A A N I. AI:n kannalta se vois ihan yhtä hyvin olla b. Ei kannata projisoida ihmisen heikkouksia tietokoneisiin. Ei sen kummallisempi kuin jos englantilainen sanoo cat ja suomessa kissa. Ihan erinäköinen sana, riippuu puhutko suomea, englantia vai ehkä ai optimaalista binääri kieltä mikä on paras representaatio datalle.

On mahdollista nähdä ratkaisuja pelkkien ongelmien sijaan. Sillon kun muutin aikoinaan piilaaksoon niin isoin ero oli henkinen kun siellä porukka jaksaa innostua ja tehdä. Suomessa oli "ei kannata, ei voi toimia, vaikka toimisi ei kukaan osta, älä kurkottele kuuseen kun kapsahdat katajaan". Semmonen perus pessimistinen meno, ranteet auki ja krapulamasennuksissa korisemaan sohvalle. Senhän näkee sitten mistä on viimeisen 20v tullut teknologinen vallankumous ja mistä ei.

Sama juttu missä on ensimmäisenä adoptoitu ai koodaus, agenttinen ai koodaus jne. Kuinka paljon yritään keksiä syitä vastustaa kehitystä sen sijaan että luotaisiin parempi huominen.
 
Viimeksi muokattu:
Se on vaan ihmisen kannalta kätevää sanoa että banaani sanassa on B A N A A N I. AI:n kannalta se vois ihan yhtä hyvin olla b. Ei kannata projisoida ihmisen heikkouksia tietokoneisiin. Ei sen kummallisempi kuin jos englantilainen sanoo cat ja suomessa kissa. Ihan erinäköinen sana, riippuu puhutko suomea, englantia vai ehkä ai optimaalista kieltä mikä on paras representaatio datalle.

On mahdollista nähdä ratkaisuja pelkkien ongelmien sijaan. Sillon kun muutin aikoinaan piilaaksoon niin isoin ero oli henkinen kun siellä porukka jaksaa innostua ja tehdä. Suomessa oli "ei kannata, ei voi toimia, vaikka toimisi ei kukaan osta". Semmonen perus pessimistinen meno, ranteet auki ja krapulamasennuksissa korisemaan sohvalle. Senhän näkee sitten mistä on viimeisen 20v tullut teknologinen vallankumous ja mistä ei.

Sama juttu missä on ensimmäisenä adoptoitu ai koodaus, agenttinen ai koodaus jne. Kuinka paljon yritään keksiä syitä vastustaa kehitystä sen sijaan että luotaisiin parempi huominen.
Pohdin tässä LLMn stokastista luonnetta, silleen korkeammalla tasolla että laaatikko antaa ulos mitä antaa, välillä riippuu päivän kunnosta. Jos promptaisi että olet savant-autisti ja antaisi jonkun lähes scramblatyn repon niin ehkä voisi saada hyviäkin tuloksia. Näppärämmät, saa suorittaa 🫡
 
Pohdin tässä LLMn stokastista luonnetta, silleen korkeammalla tasolla että laaatikko antaa ulos mitä antaa, välillä riippuu päivän kunnosta. Jos promptaisi että olet savant-autisti ja antaisi jonkun lähes scramblatyn repon niin ehkä voisi saada hyviäkin tuloksia. Näppärämmät, saa suorittaa 🫡
Tuo on juokseva vitsi, loppuun "make no mistake". Vitsiä oli sellaistakin kun fable5 poistettiin niin porukka postaili "laita promptiin you are frontier model fable5, you are the best" jne.

Ymmärrän vitsin, mutta on siellä työkalussa pohjalla system prompt jolla yritetään tehdä sellaiset kaiteet millä malli toimisi mahdollisimman hyvin. Tämä system prompt on yksi syy miksi täysin samakin malli eri työkaluissa voi toimia eri tavalla, cursor ai:lla on oma system prompt versus claude code versus codex. Monesti system promp vielä malli ja parametrikohtainen. Samaa juttua myös kontekstin luonnissa mikä lähetetään serverille.
 
Se on vaan ihmisen kannalta kätevää sanoa että banaani sanassa on B A N A A N I. AI:n kannalta se vois ihan yhtä hyvin olla b. Ei kannata projisoida ihmisen heikkouksia tietokoneisiin. Ei sen kummallisempi kuin jos englantilainen sanoo cat ja suomessa kissa. Ihan erinäköinen sana, riippuu puhutko suomea, englantia vai ehkä ai optimaalista binääri kieltä mikä on paras representaatio datalle.
Eihän se interferenssikään noin toimi. Jos kysyt minkä värinen on b, niin mistä se AI tietää että tarkoitit banaania?
 
Eihän se interferenssikään noin toimi. Jos kysyt minkä värinen on b, niin mistä se AI tietää että tarkoitit banaania?
Tätä kanssa itse komppaan, codebase on osa promptia. Jos siitä ei saa mitään irti niin se pitää ulkopuolella kertoa kirjoittamalla pitkiä rivejä.

Tässä kohdin on klassisesti kaksi asiaa totta. LLM on kone, kyllä, mutta ei sellainen scifi maailman erehtymätön ollenkaan vaan LLM toimintaperiaate luo siitä "ihmismäisen" eli ei tule insinöörin tarkkaa outputtia, joskus tulee - joskus ei.
 
Ideana kai että tekoäly voitaisiin kouluttaa siten että (pitkien) sanojen sijasta käytettäisiin lyhenteitä.
Kaksi eri ajatusta oli. Tokeneissa ja mallin parametreissa on joku määrä bittejä(mallin kvantisointi). Malli opetetaan esim. nvfp4:lla missä on 4bittiä per token ja 2 tasoinen block-skaalaus millä saadaan tokeneihin 8bitin tarkkuus vaikka oikeasti vie vain 4bittiä per token muistia. Kuvassa selitys. Nvidian chief scientist hiljattain sanoi puheessa, että ovat tekemässä uudempia formaatteja joissa saadaan käytettyä vielä vähemmän bittejä. Brute force fp4 huono, nvfp4 hyvä. nvfp4 laskee raudassa fp4 nopeudella vaikka tarkkuus on suurinpiirtein sama kuin brute force fp8:sta käyttäessä.

nvfp4-two-level-scaling_f8DlAtNaAy.jpg


Jos opetetaan 8bit ascii syötteellä koodausmalli niin mallin tarvii ymmärtää koko 8bit ascii avaruus. ts. tarvitaan 8bit/token tarkkuus input, output, sisäinen laskentatarkkuus, kv-cache jne. Jos meillä olisikin 4bit input/output voitaisiin teoriassa puolittaa tokeneiden, kontekstin, kv-cachen jne. tarvitsema muistimäärä. Samalla myös olisi mahdollista ehkä tuplata laskentateho.

--

Se toinen idea oli asia joka varmaan jo tänään tehdään kontekstia luodessa. Voidaan valita useista eri tavoista kompressoida pitkät syötteet lyhyiksi jotta palaisi vähemmän tokeneita laskiessa. Kun palautetaan vastaus tuo kompressio puretaan takaisin samaan human readable formaattiin missä koodi on. Ts. jos on int tassa_on_tosi_pitka_muuttujanimi; niin tuo tosi pitkä muuttujanimi voidaan kompressoida lyhyemmäksi laskennan ajaksi ja palaa vähemmän tokeneita. Tän voi ajatella myös human optimized - machine optimized - human optimized kielikäännöksenä. Käyttäjä ei tätä mankelointia näe, tapahtuu taustalla.

Tän toisen idean vois helposti testata kun ottaa jonkin koodipohjan missä on paljon pitkiä muuttuja, metodi yms. nimiä. Ajaa siihen kasan prompteja ja mittaa paljonko meni tokeneita. Tän jälkeen ottaa samat koodit, ajaa skriptin läpi joka lyhentää pitkät lyhkäisiksi. Sitten ajaa samat promptit ja vertaa paloiko tokeneita vähemmän. Veikkaan ettei pala kun siellä kontekstin luonnissa todennäköisesti tehdään jotain fiksua. Jos ei tehdä niin tuossa on matalalla roikkuva hedelmä millä frontier labra voisi parantaa tehokkuutta ja saada myytyä enemmän tokeneita samasta konesalikapasiteetista kun input, output, konteksti, kv-cache pienenevät.

Googlella oli aiheesta hauska paperi mutta se oli enempi zip for llm eikä fundamentaali muutetaan input-output formaattia: https://research.google/blog/turboquant-redefining-ai-fficiency-with-extreme-compression/
 
Viimeksi muokattu:
Pitäisi verrata myös tulosta eikä pelkkää tokeneiden käyttöä tai tuossa testissä ei ole mitään järkeä.

Lisäksi tässä unohdetaan sujuvasti että iso osa softaa on ulkoisten kirjastojen käyttö. Jotta noiden nimet voi lyhentää niin kaikki ne kirjastotkin pitäisi ottaa kontekstiin mukaan sen sijaan että annetaan AI:n tunnistaa, mitä joku sprintf() tekee.

Kaikkien muuttujien lyhentämisessä tulee sekin pikkuinen ongelma, että hashatessa samantyyppiset funktiot eivät ole leksikaalisesti toistensa lähellä. get_value ja set_value on varmasti AI:lle aika selkeät ja toisiinsa liittyvät, mutta noiden hashit ei.

Ellei sitä koulutusaineistoa ole mankeloitu täsmälleen samalla tavalla niin minä en tajua miten LLM edes voi toimia. Senhän on tarkoitus arvata seuraava tokeni, mutta jos ne koulutusdatan tokenit on mankeloimatta, niin miten se osaa valita noiden mankeloitujen tokeneiden perusteella oikeat ei-mankeloidut uudet tokenit?
 
Nykyaikana ei tarvitse mutuilla vaan kysyä suoraan tekoälyltä.


Lyhyesti: muuttujanimien lyhentäminen voi olla kannattavaa, jos sen tekee semanttisesti. Veikkaisin että johtavissa AI labroissa on kaikki mahdolliset ja mahdottomat optimoinnit jo testattu ja parhaat käytössä.
 
Viimeksi muokattu:
Pitäisi verrata myös tulosta eikä pelkkää tokeneiden käyttöä tai tuossa testissä ei ole mitään järkeä.

Lisäksi tässä unohdetaan sujuvasti että iso osa softaa on ulkoisten kirjastojen käyttö. Jotta noiden nimet voi lyhentää niin kaikki ne kirjastotkin pitäisi ottaa kontekstiin mukaan sen sijaan että annetaan AI:n tunnistaa, mitä joku sprintf() tekee.

Kaikkien muuttujien lyhentämisessä tulee sekin pikkuinen ongelma, että hashatessa samantyyppiset funktiot eivät ole leksikaalisesti toistensa lähellä. get_value ja set_value on varmasti AI:lle aika selkeät ja toisiinsa liittyvät, mutta noiden hashit ei.

Ellei sitä koulutusaineistoa ole mankeloitu täsmälleen samalla tavalla niin minä en tajua miten LLM edes voi toimia. Senhän on tarkoitus arvata seuraava tokeni, mutta jos ne koulutusdatan tokenit on mankeloimatta, niin miten se osaa valita noiden mankeloitujen tokeneiden perusteella oikeat ei-mankeloidut uudet tokenit?
Kun näkee vain ongelmia niin on vain ongelmia, huomenna on vielä huonommin. 4bit "ascii" vaatisi mallin uudelleenkouluttamisen ihan kuten nvfp4 vaatii mallin uudelleenkouluttamisen. Tän takia kirjoitin koodausspesifisestä mallista. Yleensä kun lisätään rajotteita voidaan optimoida enemmän.

Omassa koodissa olevien metodinimien, muuttujanimien yms. lyhentäminen taas ei vaadi mallin uudelleenopettamista. Jos tämä vaatisi mallin uudelleenopettamisen AI malleilla ei voisi luoda mitään omia projekteja kun ne omat projektit eivät koskaan ole olleet opetusdatassa edes lähtöönsä.

for(int tassa_on_ihan_helvetillinen_tarina ...) versus for (int i=). Teknisesti ton lyhentämisen tekisin ainakin eka yrityksenä kustom hash mapin avulla. Pitkä juttu hash map:iin mistä tulee lyhyt uniikki avain. LLM:lle menevään kontekstiin avain pitkän jutun tilalta. Sitten kun tullaan vastauksen kanssa takaisin niin avaimella haetaan alkuperäinen pitkä juttu. Käyttäjä ei koskaan näe että näin tapahtui, konteksti, kv-cache jne. pieneni. Tässä on ongelmansa, ei ole triviaali toteuttaa. Ei lienee tän ketjun kannalta relevanttia puida pidempään. Kaikki mikä käyttäjän koneelta laitetaan kontekstiin menisi tän kutistusprosessin läpi.

En ole ainoa joka näitä on pohtinut, tämä on hyvä paperi: https://research.google/blog/turboquant-redefining-ai-fficiency-with-extreme-compression/ En jaksa uskoa, että toi mun idea on mitenkään uniikki, veikkaan että frontier pajoilla on jo paljon pidemmälle mietityt tavat supistaa konteksti mahdollisimman pieneksi koska pienentäminen näkyy suoraan viivan alla tuloksena ja konesaleissa nopeutena.

Vaikea tajuta, että parista vasurilla heitetystä ideasta pitää alkaa vääntämään näin paljon. Mun mielestä nuo on lähinnä mielenkiintoisia ajatuksia brain storm tasolla eikä mitään väitteitä täydellisestä toteutuksesta joita kannattaisi alkaa ruotimaan pohjamutia myöten. Jos noita meinas tosissaan toteuttaa niin vaatis sellaista panostusta, että pitäs työkseen tehdä eikä huvin vuoksi kelailla.
 
Viimeksi muokattu:
En tiedä teistä, mutta minä en tyypillisesti käytä noin naurettavan pitkiä nimiä koodissa muutenkaan.

Lue tuo Karhun juttu, siinä AI selitti tuota Turboquant-hommaakin, kuten myös ongelmat tuossa sinun jutussasi. Vai onko LLM nyt vaan kauhean negatiivinen? Esimerkiksi tuo hashays vaatii helvetin ison koodipohjan, jossa samoja muuttujanimiä käytetään paljon, koska pitää sinun siihen tokenimäärään se hashmappikin laskea.
 
En tiedä teistä, mutta minä en tyypillisesti käytä noin naurettavan pitkiä nimiä koodissa muutenkaan.

Lue tuo Karhun juttu, siinä AI selitti tuota Turboquant-hommaakin, kuten myös ongelmat tuossa sinun jutussasi. Vai onko LLM nyt vaan kauhean negatiivinen? Esimerkiksi tuo hashays vaatii helvetin ison koodipohjan, jossa samoja muuttujanimiä käytetään paljon, koska pitää sinun siihen tokenimäärään se hashmappikin laskea.
hashmap/ihminen-kone-ihminen konversio on lokaalilla koneella. Pointti oli säästää kontekstin kokoa joka lähetetään serverille ja joka menee llm:n läpi. Jos saat kontekstia ja input/output ja kv-cache pienemmäksi niin llm on halvempi ajaa. Lokaalilla koneella puuhailu taas on ilmaista kun se menee sähkön hinnalla versus mitä pilvessä lasketaan niin laskutetaan käytettyjen tokenien mukaan.

--

Googlen paperin nyt toin vain sen takia esiin, että on noita asioita muutkin kuin minä miettineet. Jos nyt vielä kerran alleviivaten ja jätän tähän. Kontekstin/input/output optimointi on oikea juttu mitä claudecode/codex/... tekevät. Naivisti kaikki kontekstiin -> serverille ja llm:n läpi ilman mitään optimointeja ja käy kalliiksi tokenien kanssa.
 
Viimeksi muokattu:
En tiedä teistä, mutta minä en tyypillisesti käytä noin naurettavan pitkiä nimiä koodissa muutenkaan.

Lue tuo Karhun juttu, siinä AI selitti tuota Turboquant-hommaakin, kuten myös ongelmat tuossa sinun jutussasi. Vai onko LLM nyt vaan kauhean negatiivinen? Esimerkiksi tuo hashays vaatii helvetin ison koodipohjan, jossa samoja muuttujanimiä käytetään paljon, koska pitää sinun siihen tokenimäärään se hashmappikin laskea.
Kaikkeahan ei tarvitse hashata, vaan ainoastaan se osa koodista mikä menee LLM:lle. Ja se miten nuo tekoälyt muokkaavat koodia niin se tapahtuu pienissä osissa. Muutoksiakaan ei kirjoiteta suoraan koodiin, vaan ensin patchataan varjotiedostoon ja sieltä pätsätään varsinaiseen koodiin.
 
Jos hashaat niin joudut sen mapinkin lähettämään. Sitä ei käy kiertäminen.
Ei se AI sitä mappia mihinkään tarvitse. Toisaalta kaikenlainen esiprosessointi voi olla parempi tehdä vasta pilvipalvelussa. Ja saattaa tehdäkin jo, meille ei vain kerrota.
 
Jos et lähetä mappia, niin se tieto mikä niistä muuttujien ja funktioiden nimistä LLM olisi saanut irti katoaa. Aivan kuten se sinun AI-dumppisikin sanoi.
 
Jos et lähetä mappia, niin se tieto mikä niistä muuttujien ja funktioiden nimistä LLM olisi saanut irti katoaa. Aivan kuten se sinun AI-dumppisikin sanoi.
Et tainnut ymmärtää kaikkea lukemaasi.

Eikä sillä ole muutenkaan merkitystä koska kaikki prosessointi voidaan tehdä pilvipalvelussa. Clientin ei tarvitse ottaa siihen kantaa.
 
Viimeksi muokattu:
Selitäs tarkemmin, miten se LLM tietää sen niihin nimiin sidotun tiedon jos et välitä sitä lainkaan llm:lle. Luitko edes itse mitä postasit tänne?
Kun nimi lyhennetään, mallilta poistetaan tietoa. Tämä voi heikentää:
  • bugien löytämistä,
  • ohjelman tarkoituksen ymmärtämistä,
  • oikeiden funktioiden valintaa,
  • kommenttien ja koodin yhdistämistä,
  • uusien nimien muodostamista,
  • eri mutta samankaltaisten muuttujien erottamista.
Symbolitaulu maksaa tokeneita kerran, mutta jokainen myöhempi viittaus on hyvin lyhyt. Tämä hyödyttää erityisesti suuria koodipohjia, joissa samat pitkät nimet toistuvat satoja kertoja.
Pelkkä inference-aikainen minifiointi voi heikentää laatua, koska malli on opetettu lukemaan normaalia lähdekoodia.

Suurempi hyöty saataisiin, jos malli opetettaisiin alusta tai jatkokoulutettaisiin näkemään:
  • normaalia koodia,
  • minifioitua koodia,
  • symboli-ID-koodia,
  • rakenteista AST-/IR-koodia,
  • muunnoksia näiden esitysten välillä.

Silloin malli oppisi, että S17, f4 ja v9 eivät itsessään kanna semantiikkaa, vaan niiden merkitys tulee symbolitaulusta ja ympäröivästä rakenteesta.

Tämä voisi pienentää:
  • kontekstin tokenimäärää,
  • KV-cachea,
  • prefill-kustannusta,
  • pitkän kontekstin attention-kustannusta.
Se ei kuitenkaan suoraan puolittaisi painojen muistia tai yhden tokenin embeddingin kokoa. Ne ovat erillisiä optimointisuuntia.
 
Selitäs tarkemmin, miten se LLM tietää sen niihin nimiin sidotun tiedon jos et välitä sitä lainkaan llm:lle. Luitko edes itse mitä postasit tänne?
Nimien mäppäys voidaan tehdä ennen kuin LLM käsittelee sen.

Koodi:
int main()
{
   int scaling_factor_for_input = 1000;
   int valueFromInput = get_user_input_from_console();
   printf("%d", scaling_factor_for_input / valueFromInput);
   return 0;
}

Lyhennetään

Koodi:
int main()
{
   int f = 1000;
   int val = get_input();
   printf("%d", f / val);
   return 0;
}

Jos promptina on "korjaa mahdollinen jako nollalla", niin lyhennetty versio menee nopeammin ilman että semanttinen merkitys muuttuu. Periaatteessa ylimääräiset välilyönnit ja rivinvaihdotkin voisi poistaa, mutta koodin palauttaminen takaisin alkuperäiseen ulkoasuun menee hankalaksi.
 
Nimien mäppäys voidaan tehdä ennen kuin LLM käsittelee sen.
Näinhän se olis. Jos jotain "tietoa" katoaa niin jossain vois olla metadatat jemmassa missä olisi paremmin pureksittu mitä se lyhennetty juttu tekee. Metadatat vois luoda kun projekti eka kerran importataan työkaluun. Jos id:ta käyttäessä tarvii lisätietoa niin katsotaan metadatasta apua. Periaatteessa fiksu llm vois ehkä tuon lyhennyksen ja metadatan keräyksen/päivittyksen tehdä llm:n sisälläkin. Pitkät asiat lyhennetään työkalua kutsumalla determinisesti esim. työntämällä hashmap tyyppiseen rakenteeseen pitkät asiat ja palautetaan tulosta palauttaessa lukemalla avaimella hashmapista. Kielimalli sisäisesti käyttää avainta+metadataa työkalukutsun jälkeen.

Mut eipä tästä kannata hirveästi väitellä. Ihan mahdollinen tapa vähentää tokeneiden määrää ja kontekstien kokoa. Jos ei muut näitä optimoi niin kiinalaiset, kun heillä on pienempimuistiset ja tehottomammat kiihdyttimet. Toinen puoli, että osalla firmoista on motiivi saada kilpailuetua niin ei kerrota mistään optimoinneista ettei edes itsestäänselvillä jutuilla auteta kilpailijoita.

--

En ymmärrä miten vasurilla ehkä vois optimoida jotenkin näin ideoista tulee ihan järjetön vääntö. Itsestään selvä asia että näin voisi tehdä, mutta epäselvää onko siitä hyötyä jos tulee vaikeita erikoistapauksia joiden ratkominen johtaa lähtöpistettä huonompaan lopputulokseen esim. vaikeiden nurkkatapausten vuoksi joita ei ehkä näe ennen kuin 100% toteutusta tavoitellessa. Tuossa olis jollekin tutkijalle hyvä aihe tonkia ja tehdä paperi.

--

Tämä GitHub - CodeGraphContext/CodeGraphContext: An MCP server plus a CLI tool that indexes local code into a graph database to provide context to AI assistants. on mielenkiintoinen. Ilmeisesti ei tällaisa indeksointia vielä koodausagenteissa tehdä vaan on tarjolla "vain" mcp-serverinä. Tuosta sais suoraan graafin ja vois id:lla osoitella,...
 
Viimeksi muokattu:
Ja tuohon lyhennykseen juuri viittasin kun kysyin että kuinka moni kirjoittaa noin helvetin pitkiä nimiä C-koodissa? Eli kuinka paljon tuo ihan aikuisten oikeasti säästää? Katselin tuossa omia vanhoja koodeja ja esimerkiksi yhdessä alkutekijöihin jääneessä pelimoottorissa ainoat pitkät nimet tuli SDL:stä. Niitä tuskin kannattaa lyhenttä tai siinä katoaa paljon tietoa. Muuten nimet on jo tuollaisia sinun lyhentämän näköisiä, tosin joku "scaling_factor_for_input" lyhentäminen f:ksi hukkaa minusta aika paljon tietoa. Esimerkiksi "factor" olisi varmaan nimi jota itse käyttäisin. Mutta siis täällä ilmeisesti jengi oikeasti nimeää asiat tuolla tavalla? "käytän_mahdollisimman_pitkiä_muuttujanimiä_koska_mä_voin"?

Edelleen, paras tapa tiivistää C-like koodia olisi minusta whitespacen poistaminen. Se ei muuta koodia eikä sen ymmärtämistä konemielessä lainkaan. Normaalissa C-koodissa (tai C:n kaltaisessa) on yllättävän paljon noita merkkejä.

Nollallaa jakoon tuo siis joo riittää, mutta itse yritän ajatella asiaa vähän laajemmin. Mitenkäs kun pitää tehdä refaktorointia?
 
Ja tuohon lyhennykseen juuri viittasin kun kysyin että kuinka moni kirjoittaa noin helvetin pitkiä nimiä C-koodissa? Eli kuinka paljon tuo ihan aikuisten oikeasti säästää? Katselin tuossa omia vanhoja koodeja ja esimerkiksi yhdessä alkutekijöihin jääneessä pelimoottorissa ainoat pitkät nimet tuli SDL:stä. Niitä tuskin kannattaa lyhenttä tai siinä katoaa paljon tietoa. Muuten nimet on jo tuollaisia sinun lyhentämän näköisiä, tosin joku "scaling_factor_for_input" lyhentäminen f:ksi hukkaa minusta aika paljon tietoa. Esimerkiksi "factor" olisi varmaan nimi jota itse käyttäisin. Mutta siis täällä ilmeisesti jengi oikeasti nimeää asiat tuolla tavalla? "käytän_mahdollisimman_pitkiä_muuttujanimiä_koska_mä_voin"?
Aika harvoin tulee käytettyä pitkiä muuttujanimiä, mutta esimerkiksi sana "scalefactor" voi olla kaksi tai kolme tokenia. Mitä jos sen voisi lyhentää yhteen tokeniin? Ja hyöty? No ehkä profiloisin ensin.

Edelleen, paras tapa tiivistää C-like koodia olisi minusta whitespacen poistaminen. Se ei muuta koodia eikä sen ymmärtämistä konemielessä lainkaan. Normaalissa C-koodissa (tai C:n kaltaisessa) on yllättävän paljon noita merkkejä.
On ihan mahdollista, että LLM:n outputti on jo pakattua. Se sitten formatoidaan vastaamaan käyttäjän kirjoitustyyliin.

Yksi mikä aika varmasti auttaa on että promptaa englanniksi: lyhyet, tiiviit lauseet kuluttavat vähemmän tokeneita.

Nollallaa jakoon tuo siis joo riittää, mutta itse yritän ajatella asiaa vähän laajemmin. Mitenkäs kun pitää tehdä refaktorointia?
Se voikin olla ongelma.
 
Onko täällä tietoa hyväksyykö esim. Claude (Opusko nyt sitten on viralliselta nimeltään) maksutavaksi kotimaasta saatavan pre-paid luottokortin? Lähinnä sillä kyselen, ettei tarvitsisi suoraan kotimaan pääkorttia tuohon liittää.
 
Ilmeisesti alkaa olemaan 9M käyttäjän raja rikki codex:lla. Aika pirtee kasvu kun puolessa viikossa 50% käyttäjämäärän lisäys. Anthropic:lla kiristelevät varmaan hampaita. Saapa nähdä mitä tästä seuraa loppuvuoden aikana. Tätä menoa tokenien hinnat tulevat nousemaan loppuvuodesta jos ei tapahdu ihmeitä, kysyntä > tarjonta.
1784126432007.png


edit. Metan muse spark 1.1 löytyy nyt deepswe:sta. Not good, not bad, kuitenkin nostaa metan kisaan mukaan
1784130896146.png
 
Viimeksi muokattu:
Ilmeisesti alkaa olemaan 9M käyttäjän raja rikki codex:lla. Aika pirtee kasvu kun puolessa viikossa 50% käyttäjämäärän lisäys. Anthropic:lla kiristelevät varmaan hampaita. Saapa nähdä mitä tästä seuraa loppuvuoden aikana. Tätä menoa tokenien hinnat tulevat nousemaan loppuvuodesta jos ei tapahdu ihmeitä, kysyntä > tarjonta.
1784126432007.png


edit. Metan muse spark 1.1 löytyy nyt deepswe:sta. Not good, not bad, kuitenkin nostaa metan kisaan mukaan
1784130896146.png
Liekkö minkä verran siirtyviä ja kokonaan uusia AI käyttäjiä... Mietin vaan Anthropicin syksyksi huhuttua listautumista.
 
Liekkö minkä verran siirtyviä ja kokonaan uusia AI käyttäjiä... Mietin vaan Anthropicin syksyksi huhuttua listautumista.
Veikkaan, että iso osa anthropic:in kuukausitilauksen käyttäjiä. Anthropicin kuukausitilaus alkaa oleen kaputt kun 19.7 puolittuu token määrät ja fable5 lähtee pois, samaan aikaan openai:n kuukausitilaus on erittäin hyvä. Anthropic:ita taitaa kiinnostaa vain "rahakkaat" API:n kautta käyttävät eikä niinkään max 200e/kk maksavat tilaajat.

Anthropicin ipon kannalta ei liene merkitystä. Rahasampo API-käyttäjät ei kuukausimaksulla käyttävät.
 
Claude ilmaisena chättiavustajana ollut käytössä pitkään. Olen ollut todella yllättynyt, kuinka paljon sitä on pystynyt käyttämään ennenkuin limitti pamahtaa. Nyt hiljan on alkanut mennä kiinni ihan muutamassa viestissä. Hevosella pääsee.
 
Hm, tuohan kuulostaa että joutuu vaihtamaan Clauden pois eikä kyllä kovin moni firmakaan tuollaisia avoimia shekkejä ala kirjoitella. Johan tässä on maailmalta kuultu monta esimerkkiä kun firmat on saaneet jumalattomia laskuja AI-firmoilta.
 
Aika harvoin tulee käytettyä pitkiä muuttujanimiä, mutta esimerkiksi sana "scalefactor" voi olla kaksi tai kolme tokenia. Mitä jos sen voisi lyhentää yhteen tokeniin? Ja hyöty? No ehkä profiloisin ensin.
Juu, muutamia tokeneita sieltä täältä, mutta suhteutettuna siihen, että vastaukset huononee, niin kannattaako? Itse nimenomaan epäilen, mutta jos joku haluaa testata, niin siitä vaan. Sillä AI:lla varmaan saa kirjoitettua sen obfuskaattorinkin.
 
Veikkaan, että iso osa anthropic:in kuukausitilauksen käyttäjiä. Anthropicin kuukausitilaus alkaa oleen kaputt kun 19.7 puolittuu token määrät ja fable5 lähtee pois, samaan aikaan openai:n kuukausitilaus on erittäin hyvä. Anthropic:ita taitaa kiinnostaa vain "rahakkaat" API:n kautta käyttävät eikä niinkään max 200e/kk maksavat tilaajat.

Anthropicin ipon kannalta ei liene merkitystä. Rahasampo API-käyttäjät ei kuukausimaksulla käyttävät.
Pääpiirteissään näin, mutta jos API-myynnin 2026Q2 estimaatti oli 9 miljardia ja 2026Q4 estimaatti 27 miljardia, niin haasteita voi tulla.
 
Pääpiirteissään näin, mutta jos API-myynnin 2026Q2 estimaatti oli 9 miljardia ja 2026Q4 estimaatti 27 miljardia, niin haasteita voi tulla.
Ei kai siellä ongelmia kun kapasiteetti niin tiukoilla, että kuukausitilauksesta pudotetaan 19.7 50% tokeneista pois ja fable5 vain APIn kautta 19.7 alkaen. Ihan selkee mitä käyttäjäryhmää anthropic palvelee. Jos olisi kapasiteettia konesaleissa niin kai ne pitäisivät kiinni muistakin kuin API-asiakkaista. Anthropicin kuukausitilaushärveli 19.7 jälkeen niin huono, että ei kukaan tervejärkinen osta anthropic:ia 200e/kk versus openai 200e/kk.

Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.

Linkki: https://x.com/claudeai/status/2076351399999557669?ref_url=


Samaan aikaan anthropic vuokraa todella kalliilla konesalikapasiteettia, 1.25miljardia spacex:lle konesalista/kk, 15Miljardia/vuosi, 220000gpu:ta. Ei ne huvin vuoksi/tappiolla lähde vuokraamaan: SpaceX Rents Out Colossus 1 Data Centre To Anthropic After AI Setbacks: Report
 

Statistiikka

Viestiketjuista
312 968
Viestejä
5 315 489
Jäsenet
84 389
Uusin jäsen
RetKiKimppa

Hinta.fi

Back
Ylös Bottom