
Lestev inteligence za programsko opremo in alternativa ekonomiji kodirnih agentov.
Že nekaj časa razmišljam o preprostem vprašanju:
Koliko inteligence je v resnici potrebne za gradnjo programske opreme?
Ne koliko inteligence je na voljo. Ne kako velik je najnovejši model. Koliko je potrebujemo za prav tisto stvar, ki jo želimo zgraditi?
Vzemimo aplikacijo za klepet.
Potrebuje vmesnik, tok sporočil, kanale, članstvo in neko predstavo o tem, kdo je prisoten. To so znani kosi programske opreme. Inženirji so jih zgradili že tisočkrat.
Pa vendar, ko kodirnega agenta prosim, naj zgradi aplikacijo, pogosto dobim oceno, ki je komaj kaj več kot ugibanje.
Model začne delati. Piše kodo, poganja teste, popravlja napake in poskuša znova. Včasih mu uspe. Včasih obtiči. Cena je odvisna od tega, kako dolgo teče zanka in koliko inteligence model potrebuje na poti.
To je nenavaden način kupovanja programske opreme.
Mizar zna oceniti kuhinjo. Tiskarna zna dati ponudbo za pet tisoč letakov. Pri kodirnih agentih pa nas pogosto prosijo, naj začnemo pogovor in upamo, da bo račun na koncu smiseln.
Mislim, da obstaja druga pot.
Predstavljajte si, da bi programsko opremo lahko gradili iz knjižnice obstoječih vedenj.
Vedenje je lahko tok sporočil, prijavni zaslon, iskalno polje ali nadzorna plošča. Nekdo ga je že zgradil, preizkusil in pripravil za ponovno uporabo.
Zdaj si predstavljajte, da zaprosite za aplikacijo za klepet.
Sistem pogleda zahtevo in se vpraša:
Kateri deli že obstajajo?
Katere dele je mogoče sestaviti iz obstoječih kosov?
Kateri deli potrebujejo malo prilagoditve?
Kateri deli so zares novi?
Tu nastopi lestev inteligence.
Predstavljajte si jo kot lestev napora. Na dnu je delo že znano. Na vrhu mora sistem nekaj izumiti.
Nižje ko zahteva pristane na lestvi, manj inteligence potrebuje.
Sliši se samoumevno. Tako delamo povsod drugod.
Tovarna ne zasnuje stola na novo vsakič, ko ga nekdo naroči. Uporabi iste sestavne dele, iste stroje in isti postopek. Delo je cenejše, ker je znanje shranjeno v postopku.
Programska oprema lahko deluje enako.
Manjka le način, kako vedenje programa shraniti in ga znova uporabiti.
Zadnje leto gradim sistem okoli te zamisli.
Enota dela je vedenje: del programa za ponovno uporabo, s svojim stanjem, dogodki in podatki.
Vedenje lahko opisuje, kako se prikaže sporočilo v klepetu, kako se izbere kanal ali kako se uporabnik pridruži pogovoru. Vedenja je mogoče združevati v večja vedenja, večja vedenja pa v aplikacijo.
Pomembna razlika je v tem, da vedenje ni le kos besedila ali izsek kode. Je nekaj, kar sistem zna zgraditi znova.
Ko vedenje enkrat obstaja, ne bi smeli potrebovati zmogljivega modela, da ga znova odkrije vsakič, ko nekdo prosi za isto stvar.
To je temelj lestve inteligence.
To gradim v Almadar Studio, ki je trenutno v različici beta in brezplačen.
Lestev ima štiri ravni.
Točno ta aplikacija ali točno ta načrt za njeno gradnjo že obstaja.
Sistem jo znova zgradi iz shranjenih vedenj.
Klici modela niso potrebni. Delo je deterministično.
To je najcenejši način ustvarjanja programske opreme: sistem že ve, kaj mora storiti.
Zahtevana aplikacija je zelo podobna nečemu v knjižnici.
Morda želite aplikacijo za klepet z drugačnimi oznakami, drugačno barvno shemo ali nekaj dodatnimi polji.
Te razlike lahko zapolni majhen model. Ostalo pride iz obstoječih vedenj.
Dragi del ustvarjanja programske opreme je že opravljen.
Nekateri deli zahteve že obstajajo. Drugi ne.
Sistem znova uporabi znana vedenja in močnejšemu modelu pošlje samo manjkajoče kose.
Če aplikacija za klepet potrebuje znan tok sporočil, a novo vrsto pravil pogovora, ni razloga, da bi tok sporočil izumljali na novo.
Uporabite, kar je znano. Inteligenco porabite tam, kjer je potrebna.
Nič v knjižnici ni dovolj blizu.
Zdaj mora sistem napisati novo vedenje, ga preveriti in po potrebi popraviti.
Tu si močan kodirni model zasluži svoje mesto.
In to je pomembno: vsaka zahteva ne bi smela priti do te ravni.
Danes kodirni agenti pogosto obravnavajo vsako zahtevo, kot da je svež programerski problem. Tudi ko je delo znano, začnejo pisati.
Lestev to obrne na glavo.
Knjižnica Almadar trenutno vsebuje nekaj več kot tisoč vedenj, med njimi atomske komponente in večje komponente, sestavljene iz njih.
Aplikacijo za klepet v realnem času je na primer mogoče sestaviti iz vedenj za:
Tok sporočil.
Kanale.
Članstvo v kanalih.
Prisotne uporabnike.
Pravila pogovora.
Ta uporabljajo skupne komponente, kot so ogrodje aplikacije, seznami za brskanje, plošče s podrobnostmi, iskanje, potrditvena okna in obvestila.
Nobene od teh komponent ni treba napisati posebej za klepet.
Zgrajene so bile enkrat. Uporabiti jih je mogoče znova.
To je razlika med tem, da model prosite, naj napiše aplikacijo, in tem, da sistem prosite, naj jo sestavi.
Prvi pristop se začne s prazno stranjo.
Drugi se začne s knjižnico.
To preizkušam lokalno na svojem računalniku, z različnimi kodirnimi modeli.
Rezultati so zgodnji, a kažejo, zakaj je to pomembno.
Ena nova aplikacija za spletno trgovino je na kodirnem modelu s 30 milijardami parametrov zahtevala 62 klicev modela, približno 1,1 milijona žetonov in 13 minut. Ocenjeni strošek je bil približno osem centov.
Ista zahteva je na splošnem modelu s 27 milijardami parametrov zahtevala 127 klicev, približno 3 milijone žetonov, po 41 minutah pa se je iztekel čas. Aplikacija ni nastala.
Majhna sprememba obstoječe nadzorne plošče je na istem splošnem modelu zahtevala 12 klicev in približno štiri minute. Na manjšem modelu je sprememba zahtevala tri klice in 21 sekund.
To niso produkcijska merila in številke se bodo z izboljševanjem sistema spreminjale. Pokažejo pa nekaj pomembnega.
Cena programske opreme ni le cena modela. Je cena tega, koliko dela mora model znova odkriti.
Ko sistem lahko znova uporabi znana vedenja, se količina potrebne inteligence zmanjša.
In ko se zmanjša količina inteligence, se z njo zmanjša tudi cena.
Ta del se mi zdi najzanimivejši.
Vsako novo vedenje, dodano v knjižnico, lahko poceni gradnjo prihodnjih aplikacij.
Tok sporočil, zgrajen za eno aplikacijo, je lahko uporaben v ducat drugih. Komponenta nadzorne plošče, zgrajena za poslovno aplikacijo, lahko postane del sistema za vodenje šole. Pravilo pogovora je mogoče znova uporabiti v povsem različnih izdelkih.
Knjižnica postane nekakšen skupni spomin programske opreme.
Več ko vsebuje, redkeje mora sistem začeti iz nič.
To ustvari drugačen ekonomski model za kodirne agente.
Namesto da modelu plačujemo, da vedno znova ustvarja isto znanje, znanje shranimo in ga znova uporabimo.
Namesto da vsako aplikacijo obravnavamo kot nov programerski projekt, jo obravnavamo kot sestavo znanih vedenj in majhne količine novega dela.
Lestev inteligence je način, kako to razliko merimo.
Za vsem tem je večje vprašanje.
Kdo naj bi lahko gradil programsko opremo?
Danes je velik del industrije organiziran okoli dostopa do drage inteligence. Najnovejši model je boljši. Strojna oprema je dražja. Naročnina je višja. Aplikacija nastane v dolgem pogovoru, katerega ceno je težko predvideti.
To je morda koristen poslovni model za podjetja, ki inteligenco prodajajo.
Ni pa nujno dober model za ljudi, ki želijo kaj zgraditi.
Raje bi videl, da gre ustvarjanje programske opreme v nasprotno smer.
Več skupnih komponent. Več vedenj za ponovno uporabo. Več lokalnega izvajanja. Bolj predvidljivi stroški. Manj odvisnosti od vrhunskega modela za vsako majhno nalogo.
Majhno podjetje ne bi smelo potrebovati dostopa do najdražjega modela na svetu, da zgradi uporabno interno orodje.
Razvijalec ne bi smel plačati dolgega zaporedja klicev modela, da znova ustvari komponento, ki že obstaja.
In skupnost bi morala imeti možnost graditi na delu drugih, ne da bi morala isto inteligenco kupiti še enkrat.
To zame pomeni, da tehnologija postane vsakdanja dobrina.
Ne to, da je inteligenca manj vredna.
Ampak to, da drage inteligence ni treba trošiti za delo, ki je že opravljeno.
Ne mislim, da bodo kodirni agenti izginili.
Koristni so. Znajo pisati kodo, raziskovati zamisli in reševati probleme, ki bi sicer vzeli veliko časa.
Mislim pa, da smo naredili napako, ko smo kodirnega agenta začeli obravnavati kot celoten proces razvoja programske opreme.
Model, ki sedi pred praznim projektom, ni edini način gradnje programske opreme.
Lahko gradimo sisteme, ki vedo, kaj je že zgrajeno.
Sisteme, ki znajo delo izmeriti, preden začnejo.
Sisteme, ki za znane naloge uporabljajo majhne modele, močne modele pa le takrat, ko je potrebno nekaj zares novega.
Sisteme, ki postajajo cenejši, ko njihove knjižnice rastejo.
To je smer, ki jo raziskujem z Almadarjem.
Cilj ni zgraditi boljšega klepetalnega robota, ki napiše več kode.
Cilj je zgraditi sistem, v katerem je znanje o programski opremi mogoče shraniti, deliti in znova uporabiti.
V katerem se naslednja aplikacija ne začne s prazno stranjo.
V katerem je inteligenca, potrebna za gradnjo nečesa, sorazmerna s tem, kako nova je ta stvar v resnici.
In v katerem se cena gradnje programske opreme približa ceni njenega sestavljanja.
Prihodnost kodirnih agentov morda ni v tem, da bodo modeli inteligentnejši.
Morda je v tem, da bodo inteligence sploh potrebovali manj.