Kohdeyleisö: Kehittäjät, jotka käyttävät tekoälypohjaisia ohjelmointityökaluja (kuten Cursor, Windsurf, trae jne.), sekä tekniset johtajat, joilla on puutteellinen käsitys tekoälyn kustannuksista.

Ydinajatukset: Tokenit eivät ole vain yksinkertaisia laskutusyksiköitä, vaan myös "huomioresursseja" ja "laskentatehon valuuttaa". Agent-mallien väärinkäyttö ja kontekstin hallinnan laiminlyönti tarkoittavat itse asiassa taktisen ahkeruuden (annetaan tekoälyn puuhastella umpimähkään) käyttämistä strategisen laiskuuden (ei itse ajatella) peittämiseen.

"Tekoälykulusi" voivat olla korkeammat kuin palkkasi

Muutama päivä sitten tarkistin token-laskuni. Olin hieman yllättynyt nähdessäni sen numeron: 10 miljoonaa tokenia. Huomaa, että tämä ei ole kuukauden kulutus, vaan yhden päivän.

Luulin, että tämä oli minulta jo aika paljon. Myöhemmin julkaisin lyhyen videon tokenien laskemisesta.

Tuloksena kommenttiosio osoitti minulle, mitä "taivas taivaan yläpuolella" tarkoittaa.

Alla oleva kuva on käyttäjän "老K的日常" (Lao K:n arki) näyttökuva, jossa näkyy kahden sadan miljoonan tokenin kulutus yhden päivän aikana:

Aluksi ajattelin, että kyseessä saattaa olla yksittäistapaus, mutta kun monet käyttäjät kommentoivat kuluttavansa 100 miljoonaa tokenia päivässä, ymmärsin, että tämä on hyvin yleinen ilmiö.

Mitä 100 miljoonaa tokenia tarkoittaa? Jos lasketaan "joidenkin yleisten kaupallisten mallien" yleisellä laskutustasolla (syöttö/tulostus laskutetaan erikseen, karkeasti arvioituna 10 dollaria / miljoona tokenia), niin tämä polttaa 1000 dollaria päivässä. 7000 RMB palaa päivässä. Monen nuoremman ohjelmoijan kuukausipalkka ei ehkä riitä tekoälyn "ajatustyöhön" edes yhden päivän aikana.

(Huomautus: Eri mallien/toimittajien hinnat vaihtelevat suuresti, ja syötteen ja tulosteen yksikköhinnat ovat myös usein erilaiset. Tässä ei ole tarkoitus laskea tarkasti desimaalin tarkkuudella, vaan luoda ensin "suuruusluokan tunne".)

Jos haluat laskea itse, yleensä on vain tämä yksi kaava (jätä huomiotta välimuisti/alennukset jne.): Kustannus ≈ (Syöttötokenit / 1 000 000) × Yksikköhinta_in + (Tulostustokenit / 1 000 000) × Yksikköhinta_out

Tämä on hyvin intuitiivista. Ajattelemme aina, että tekoäly on halpaa, ja OpenAI jopa alentaa hintoja. Mutta miksi tokenien kulutus kasvaa todellisessa suunnittelussa eksponentiaalisesti?

Tänään puretaan syvällisesti tämän "token-mustan aukon" takana oleva logiikka ja miten voimme lopettaa tappiot.

I. Miksi tokenit "räjähtävät eksponentiaalisesti"?

Monilla veljillä ei ole aavistustakaan tokenien määrästä. He ajattelevat: "No, eihän se ole kuin muutama koodinpätkä? Kuinka paljon niitä voi olla?"

1. Lasketaan selkeästi

Luodaan ensin suunnittelun kannalta riittävä kvantitatiivinen käsitys. Sanotaan se suoraan: Token ei ole sanojen määrä, eikä se ole merkkien määrä. Se on mallin tekstin pilkkomisen jälkeen syntynyt "koodinpätkä". Eri malleilla on erilaiset tokenizerit, joten voidaan antaa vain väli, ei "kaikkialle sopivaa" vakiota.

Ajattele näitä lukuja "arviointiviivaimena" (tarkoituksena on arvioida suuruusluokkaa, arvioida kustannuksia ja tehdä tappioiden rajoituspäätöksiä):

• 1 kiinalainen merkki: Yleensä 1–2 tokenia (yleiset merkit lähempänä 1, harvinaiset merkit/yhdistelmät helpommin 2–3)

• 1 englanninkielinen sana: Yleensä noin 1,2–1,5 tokenia (karkea arviointi 1,3 on myös ok)

• 1 koodirivi ≈ 10–50 tokenia (sisältää sisennysten, kommenttien ja tyyppimääritysten)

• Yksinkertainen liiketoimintalogiikka ≈ 12–20 tokenia

• Tyyppiannotaatioilla, rajapinnoilla, JSDocilla, 4 välilyönnin sisennys ≈ 20–35 tokenia

• Paljon importteja / koristeita / kommentteja ≈ 30–50+ tokenia

• 1 lähdetiedosto (400–600 riviä, moderni TS/Java-projekti) ≈ 4 000–24 000 tokenia on hyvin yleistä (mediaani ≈ 12 000–18 000)

• 1 keskikokoinen projekti (100–200 lähdetiedostoa, vain src/, ei node_modules/ / luotua koodia)

• Ydinlähdekoodin "lukeminen läpi" on usein miljoonan tokenin luokkaa

• Jos lisätään testit, konfiguraatiot, skriptit, riippuvuusmääritykset ja lokit, niin kymmenet miljoonat tokenit eivät ole harvinaisia

Nykypäivän frontend-projektit ovat TypeScriptiä, joka on täynnä monimutkaisia rajapintamäärityksiä; tai Javaa, jossa on helposti kymmeniä rivejä importteja. Nämä "mallikoodit" ovat itse asiassa token-tappajia. Keskikokoisessa projektissa, jossa on 100 tiedostoa, pelkästään tekoälyn "koodin läpi lukeminen" voi helposti kuluttaa miljoona tokenia.

2. Tokenien "lumipalloefekti"

Tokenien kulutuksen pelottavin asia ei ole yksittäinen keskustelu, vaan kontekstin kumuloituminen monissa keskusteluissa.

LLM:n mekanismi on tilaton. Jotta tekoäly muistaisi, mitä sanoit edellisessä lauseessa, järjestelmä pakkaa yleensä yhteen "järjestelmäkehotteen + aiemmat keskustelut + viittaamasi tiedostot/koodinpätkät + työkalukutsujen tulosteet (kuten hakutulokset, virhelokit)". Luulet kysyneesi vain yhden kysymyksen, mutta maksat itse asiassa toistuvasti "koko kontekstipaketista".

• 1. kierros: Lähetetään 10 000 tokenia, tekoäly vastaa 1 000 tokenilla.

• 2. kierros: Lähetetään (10 000 + 1 000 + uusi kysymys), tekoäly vastaa...

• 10. kierros: Kontekstisi on saattanut paisua 200 000 tokeniin.

Tässä vaiheessa, vaikka kysyisit vain "auta minua muuttamaan muuttujan nimeä", kulutat 200 000 tokenin verran. Siksi sinusta tuntuu, että et ole tehnyt mitään, mutta laskusi nousee pilviin.

Vielä pahempaa on, että Agent-tila "lukee tiedostoja aktiivisesti". Jos sanot "auta minua optimoimaan käyttäjämoduuli", se saattaa ensin skannata asiaankuuluvat hakemistot, sitten jäljittää riippuvuudet, sitten jäljittää konfiguraation, sitten jäljittää testit... Se ei laiskottele, vaan "täyttää velvollisuutensa oletusstrategian mukaisesti", ja oletusstrategia on usein: lue enemmän, kokeile enemmän, iteroi enemmän.

II. Kaksi "laiskottelua" tuhoavat suunnitteluosaamisesi

Kun olemme käyneet läpi kommenttiosion "sata miljoonaa" -tyyppien kanssa, huomaan, että tokenien räjähdysmäisen kasvun juuret eivät ole vain tekoälyn kulutusmekanismissa, vaan myös ihmisten laiskuudessa.

Alla on kaksi tyypillistä "ajatuksen laiskuutta".

Laiskuus yksi: Vastuunpakoilija

Onko sinulla myös tämä asenne:

• "Tämä vanha projekti on liian sotkuinen, en jaksa katsoa logiikkaa, heitetään se suoraan tekoälylle."

• "Cursorissa on Agent-tila, hienoa, annetaan sen korjata bugit itse."

Joten heität koko src-kansion Agentille ja annat epämääräisen ohjeen: "Auta minua optimoimaan käyttäjämoduuli." Agentti alkaa työskennellä:

• Se lukee 50 tiedostoa (kuluttaa 500 000 tokenia).

• Se huomaa, että se viittaa utils-tiedostoon, ja menee lukemaan apuluokat (kuluttaa 200 000 tokenia).

• Se yrittää muokata, tulee virhe, lukee virhelokit (kuluttaa 100 000 tokenia).

• Se yrittää korjata, tulee taas virhe...

Se yrittää ja erehtyy hullun lailla, kuluttaa tokeneita hullun lailla. Ja sinä? Selaat puhelintasi ja tunnet, että tehokkuutesi on todella korkea. Totuus on: vaihdat rahaa "valetehokkuuteen" ja tuotat kasan koodia, jota et voi ylläpitää myöhemmin.

Ammatillisemmin sanottuna tässä on kaksi kerrosta tappioita:

• Kustannustaso: Syöttötokenit kasvavat, iteraatioiden määrä kasvaa, kustannukset kasvavat lineaarisesti

• Suunnittelutaso: Menetät kontekstin ja päätösvallan, ja lopulta jäljellä on vain "toimiva" hallitsematon järjestelmä

Laiskuus kaksi: Sekalainen seurakunta

Kun kohtaat bugin, miten heität sen tekoälylle? Kopioitko suoraan koko virhekonsolin Ctrl+A:lla vai annoitko tekoälyn etsiä sen itse @Codebase:lla?

Tätä kutsutaan "sekalaiseksi seurakunnaksi". Et jaksa paikantaa ongelman ydintä, et jaksa suodattaa avainkoodinpätkiä. Heität 99 % tehottomasta tiedosta (kohina) ja 1 % tehokkaasta tiedosta (signaali) tekoälylle.

Tekoäly on kuin vahvistin.

• Jos annat sille selkeän logiikan (signaali), se vahvistaa viisauttasi, tokeneita käytetään vähän ja vaikutus on hyvä.

• Jos annat sille sekavuutta ja epämääräisyyttä, se vahvistaa sekavuuttasi, tokenit nousevat pilviin ja tuottavat roskaa.

III. Ratkaisu: Miten käyttää tekoälyä tehokkaasti ja vähentää tokenien kulutusta

Jos haluat suojella lompakkoasi, on tärkeämpää suojella suunnittelun hallintaa. Meidän on muutettava yhteistyömalliamme tekoälyn kanssa.

1. Pienimmän kontekstin periaate

Tämä on tekoälyohjelmoinnin ensimmäinen periaate. Anna tekoälylle aina vain pienin koodijoukko, joka vastaa nykyistä ongelmaa.

Hyödynnä näitä operaattoreita Cursorissa:

• @File: Viittaa vain asiaankuuluviin tiedostoihin, ei koko kansioon.

• Ctrl+L Valitse koodi: Lähetä Chatille vain kohdistimen valitsemat 50 koodiriviä, ei koko tiedostoa.

• @Docs: Viittaa kolmannen osapuolen kirjastojen osalta dokumentaatioon sen sijaan, että antaisit sen arvailla.

Tämä on usein käyttämäni, jäsennelty ja uudelleenkäytettävä SOP (jos teet näin, tokenit vähenevät silminnähden):

Tämä tarkoittaa: Kun teet yhteistyötä tekoälyn kanssa, kiinnitä huomiota tehokkuuteen ja tarkkuuteen. Toimi seuraavasti:

• Määritä ensin tavoite: Kerro tekoälylle ytimekkäästi nykyinen ongelma ja toivottu tulos, älä anna sen arvailla itse.

• Yksinkertaista ongelman toistaminen: Jos voit toistaa ongelman yksinkertaisimmalla tavalla, älä käytä monimutkaista tapaa, liitä mahdollisimman vähän ja olennaista koodia, älä kasaa paljon asiaankuulumatonta sisältöä.

• Anna mahdollisimman vähän tarvittavaa tietoa: Anna vain 1–3 asiaankuuluvaa tiedostoa, avainfunktioita ja virhepinon ensimmäiset rivit, älä koko tietoa.

• Pyydä palauttamaan muutospisteet: Pyydä tekoälyä kertomaan vain, missä muutokset tehdään ja miksi, älä anna sen kirjoittaa koko koodia uudelleen.

• Lopuksi tarkista itse: Tee mahdollisimman lyhyt vahvistus varmistaaksesi, että muutokset eivät vaikuta muihin paikkoihin.

Yksinkertaisesti sanottuna, käytä mahdollisimman vähän ja olennaista tietoa tekoälyn tekemiseen ja säilytä lopullinen hallinta ja harkinta.

2. Myös tärkein: Ajattele ensin, sitten kehotus, suunnittele ensin, sitten toimi

Ennen kuin painat Enter-näppäintä, pakota itsesi pysähtymään 10 sekunniksi ja kysy itseltäsi kolme kysymystä:

• Mitä ongelmaa olen ratkaisemassa? (Määritä rajat)

• Mihin ydinmoduuleihin tämä ongelma liittyy? (Suodata konteksti)

• Jos kirjoittaisin itse, miten kirjoittaisin? (Anna ideoita)

Sinä olet 1, tekoäly on sen perässä oleva 0. Jos 1 ei ole vakaa, niin vaikka 0:ia olisi kuinka monta, se on vain merkityksetöntä kulutusta.

Muutama sydämellinen sana

"Sata miljoonaa tokenia päivässä" -tarina ei ehkä tapahdu kaikille. Mutta tokenien tuhlaaminen on kokemus, jonka lähes jokainen tekoälyohjelmointia käyttävä ohjelmoija kokee.

Vaikka tekoäly on tehnyt ohjelmoinnista helpompaa, on edelleen olemassa kynnys. Todella osaavat ihmiset ovat kuin tiikereitä, joilla on siivet.

Aiemmin huonosti kirjoittamasi koodi vain "ällötti" kollegoita. Nyt laiskuutesi muuttuu suoraan laskun numeroiksi ja rankaisee itseäsi nousevilla kustannuksilla.Joten älä ole "kädet taskussa" -tyyppi. Ole syvällisesti ajatteleva, tarkasti ilmaiseva ja suunnitelmallisesti toimiva AI-arkkitehti. Tämä on myös suurin korvaamattomuutemme tällä aikakaudella.