Käännös: Miksi suuret kielimallit eivät todellakaan pysty rakentamaan ohjelmistoja Kirjailija: Conrad Irwin Yksi asia, johon käytän paljon aikaa, on ohjelmistosuunnittelijoiden haastatteleminen. Tämä on ilmeisesti vaikea tehtävä, enkä uskalla sanoa, että minulla olisi mitään temppuja; Mutta se antoi minulle aikaa pohtia, mitä tehokas ohjelmistosuunnittelija tekee. Ohjelmistosuunnittelun ydinsykli Kun katsot todellista asiantuntijaa, huomaat, että hän suorittaa aina seuraavat vaiheet syklissä: * Rakenna henkinen malli tarpeista. * Kirjoita (toivottavasti?!) ) -koodia, jolla vaatimukset pannaan täytäntöön. * Rakenna henkinen malli siitä, miten koodisi todella käyttäytyy. * Etsi ero näiden kahden välillä ja päivitä sitten koodi (tai vaatimus). On monia tapoja saavuttaa nämä vaiheet, mutta tehokkaiden insinöörien hieno puoli on heidän kykynsä rakentaa ja ylläpitää selkeitä henkisiä malleja. Miten suuret kielimallit toimivat? Ollakseni rehellinen, suuret kielimallit ovat melko hyviä koodin kirjoittamisessa. He tekevät myös hyvää työtä koodin päivittämisessä, kun huomautat ongelmasta. He voivat myös tehdä kaikkea sitä, mitä oikea insinööri tekisi: lukea koodia, kirjoittaa ja suorittaa testejä, lisätä lokeja ja (oletettavasti) käyttää virheenkorjausohjelmaa. Mutta he eivät voi ylläpitää selkeää henkistä mallia. Suuret kielimallit joutuvat loputtomaan sekaannukseen: ne olettavat, että heidän kirjoittamansa koodi on todella käyttökelpoinen; Kun testi epäonnistuu, he voivat vain arvailla, onko kyseessä korjauskoodi vai kiinteä testi; Kun he turhautuvat, he yksinkertaisesti leikkaavat kaiken pois ja aloittavat alusta. Tämä on täysin päinvastaista kuin mitä odottaisin insinööriltä. Ohjelmistosuunnittelijat testaavat työskennellessään. Kun testi epäonnistuu, he voivat käyttää henkistä malliaan päättääkseen, korjataanko koodi vai testi, vai kerätäänkö lisätietoja ennen päätöksen tekemistä. Kun he tuntevat olonsa turhautuneeksi, he voivat pyytää apua kommunikoimalla ihmisten kanssa. Vaikka he joskus poistavat kaiken ja aloittavat alusta, se on valinta, joka tehdään ongelman selkeämmän ymmärtämisen jälkeen. Mutta se tapahtuu pian, eikö niin? Muuttuuko tämä, kun malleista tulee tehokkaampia? Ehkä?? Mutta mielestäni tämä vaatii perustavanlaatuista muutosta tapaan, jolla malleja rakennetaan ja optimoidaan. Ohjelmistosuunnittelu vaatii malleja, jotka ovat muutakin kuin pelkkää koodin tuottamista. Kun henkilö kohtaa ongelman, hän pystyy väliaikaisesti jättämään koko kontekstin syrjään ja keskittymään käsillä olevan ongelman ratkaisemiseen ja palaamaan sitten käsillä olevaan suureen ongelmaan. He voivat myös vaihtaa kokonaiskuvan ja mikroyksityiskohtien välillä, jättää yksityiskohdat väliaikaisesti huomiotta keskittyäkseen kokonaisuuteen ja kaivautua osiin tarvittaessa. Meistä ei tule tuottavampia vain tunkemalla enemmän sanoja "konteksti-ikkunaamme", se vain tekee meidät hulluiksi. Vaikka pystymme käsittelemään suurta määrää kontekstia, tiedämme, että näillä generatiivisilla malleilla on tällä hetkellä useita vakavia ongelmia, jotka vaikuttavat suoraan niiden kykyyn ylläpitää selkeitä henkisiä malleja: * Kontekstuaalinen poisjättäminen: Mallit eivät ole hyviä havaitsemaan huomiotta jäänyttä kontekstuaalista tietoa. * Viimeaikaisuusharha: Ne ovat alttiina vakavalle viimeaikaisuusharhalle, kun he työskentelevät kontekstiikkunoiden kanssa. * Hallusinaatiot: He usein "fantasioivat" yksityiskohdista, joita ei pitäisi olla olemassa. Nämä ongelmat eivät ehkä ole ylitsepääsemättömiä, ja tutkijat pyrkivät lisäämään muistia malleihin, jotta ne voivat harjoittaa samanlaisia ajattelutaitoja kuin me. Mutta valitettavasti toistaiseksi he (ylitettyään tietyn monimutkaisuustason) eivät voi todella ymmärtää, mitä todella tapahtui. He eivät voi rakentaa ohjelmistoja, koska he eivät pysty ylläpitämään kahta samanlaista "henkistä mallia" samanaikaisesti, selvittämään eroja ja päättämään, päivittävätkö koodia vai päivittävätkö ne vaatimuksia. Joten mitä nyt? On selvää, että suuret kielimallit ovat hyödyllisiä ohjelmistosuunnittelijoille. Ne luovat koodia nopeasti ja ovat erinomaisia vaatimusten ja dokumentaation integroinnissa. Joihinkin tehtäviin tämä riittää: vaatimukset ovat riittävän selkeät, ongelmat ovat riittävän yksinkertaisia, jotta ne voidaan tehdä yhdessä yössä. Tästä huolimatta missään monimutkaisessa tehtävässä he eivät pysty ylläpitämään tarpeeksi tarkasti kontekstia iteroidakseen vihdoin toteuttamiskelpoisen ratkaisun. Ohjelmistosuunnittelijana olet edelleen vastuussa siitä, että vaatimukset ovat selkeitä ja että koodi todella toimittaa sen, mitä se väittää tekevänsä. Me Zedillä uskomme tulevaisuuteen, jossa ihmiset ja tekoälyagentit voivat rakentaa ohjelmistoja yhdessä. Uskomme kuitenkin vakaasti (ainakin toistaiseksi), että olet kuljettaja ratin takana ja että suuret kielimallit ovat vain yksi työkalu lisää käden ulottuvilla.