Die sagteware-ontwikkelingsbedryf is 'n domein wat dikwels staatmaak op beide konsultasie en intuïsie, gekenmerk deur ingewikkelde besluitnemingstrategieë. Verder vereis die ontwikkeling, instandhouding en bedryf van sagteware 'n gedissiplineerde en metodiese benadering. Dit is algemeen dat sagteware-ontwikkelaars besluite op intuïsie eerder as konsultasie baseer, afhangende van die kompleksiteit van die probleem. In 'n poging om die doeltreffendheid van sagteware-ingenieurswese te verbeter, insluitend die doeltreffendheid van sagteware en verminderde ontwikkelingskoste, ondersoek wetenskaplikes die gebruik van diep-leer-gebaseerde raamwerke om verskeie take binne die sagteware-ontwikkelingsproses aan te pak. Met onlangse ontwikkelings en vooruitgang in die diepleer- en KI-sektore, soek ontwikkelaars maniere om sagteware-ontwikkelingsprosesse en -praktyke te transformeer. Hulle doen dit deur gebruik te maak van gesofistikeerde ontwerpe wat in verskillende stadiums van die sagteware-ontwikkelingsproses geïmplementeer is.

Vandag gaan ons ChatDev bespreek, 'n groot taalmodel (LLM)-gebaseerde, innoverende benadering wat daarop gemik is om die veld van sagteware-ontwikkeling te revolusioneer. Hierdie paradigma poog om die behoefte aan gespesialiseerde modelle tydens elke fase van die ontwikkelingsproses uit te skakel. Die ChatDev-raamwerk maak gebruik van die vermoëns van LLM-raamwerke, deur natuurlike taalkommunikasie te gebruik om sleutelsagteware-ontwikkelingsprosesse te verenig en te stroomlyn.

In hierdie artikel sal ons ChatDev verken, 'n virtuele-aangedrewe maatskappy wat spesialiseer in sagteware-ontwikkeling. ChatDev neem die watervalmodel aan en verdeel die sagteware-ontwikkelingsproses noukeurig in vier primêre stadiums.

1. Ontwerp. 
2. Kodering. 
3. Toets. 
4. Dokumentasie. 

Elkeen van hierdie stadiums ontplooi 'n span virtuele agente soos kodeprogrammeerders of toetsers wat met mekaar saamwerk deur dialoë te gebruik wat 'n naatlose werkvloei tot gevolg het. Die kletsketting werk as 'n fasiliteerder, en breek elke stadium van die ontwikkelingsproses af in atoomsubtake, wat dus dubbele rolle moontlik maak, wat voorsiening maak vir voorstelle en validering van oplossings deur konteksbewuste kommunikasie te gebruik wat ontwikkelaars in staat stel om die gespesifiseerde subtake effektief op te los. 

ChatDev se instrumentele analise toon dat nie net die ChatDev-raamwerk uiters doeltreffend is om die sagteware-ontwikkelingsproses te voltooi nie, maar dit is uiters kostedoeltreffend, asook dat dit die hele sagteware-ontwikkelingsproses in net minder as 'n dollar voltooi. Verder identifiseer die raamwerk nie net potensiële kwesbaarhede nie, maar verlig dit ook, stel potensiële hallusinasies reg, alles terwyl hoë doeltreffendheid en kostedoeltreffendheid gehandhaaf word. 

ChatDev: 'n Inleiding tot LLM-aangedrewe sagteware-ontwikkeling

Tradisioneel is die sagteware-ontwikkelingsbedryf een wat gebou is op die fondamente van 'n gedissiplineerde en metodiese benadering, nie net vir die ontwikkeling van die toepassings nie, maar ook vir die instandhouding en bedryf daarvan. Tradisioneel gesproke is 'n tipiese sagteware-ontwikkelingsproses 'n hoogs ingewikkelde, komplekse en tydrowende noukeurige proses met lang ontwikkelingsiklusse, aangesien daar verskeie rolle by die ontwikkelingsproses betrokke is, insluitend koördinasie binne die organisasie, toekenning van take, skryf van kode, toetsing, en laastens, dokumentasie. 

In die laaste paar jaar, met die hulp van LLM of groot taalmodelle, het die KI-gemeenskap beduidende mylpale bereik in die velde van rekenaarvisie en natuurlike taalverwerking, en na opleiding oor "volgende woordvoorspelling"-paradigmas, het Groot Taalmodelle hul vermoë om doeltreffende prestasie op 'n wye verskeidenheid stroomaf-take te lewer goed gedemonstreer soos masjienvertaling, vraagbeantwoording en kodegenerering. 

Alhoewel groot taalmodelle kode vir die hele sagteware kan skryf, het dit 'n groot nadeel: kode hallusinasies, wat baie soortgelyk is aan die hallusinasies waarmee natuurlike taalverwerkingsraamwerke te kampe het. Kode hallusinasies kan kwessies soos onontdekte foute, ontbrekende afhanklikhede en onvolledige funksie-implementerings insluit. Daar is twee hoofoorsake van kode hallusinasies. 

• Gebrek aan taakspesifikasie: Wanneer die sagtewarekode in een enkele stap gegenereer word, verwar die LLM's nie die spesifieke van die taak nie as take in die sagteware-ontwikkelingsproses soos die ontleding van gebruikersvereistes, of die keuse van die voorkeurprogrammeertaal verskaf dikwels geleide denke, iets wat ontbreek in die hoë -vlaktake wat deur hierdie LLM'e hanteer word. 
• Gebrek aan kruisondervraging : Beduidende risiko's kom wanneer 'n kruisondervraging nie uitgevoer word nie, veral tydens die besluitnemingsprosesse. 

ChatDev poog om hierdie kwessies op te los, en LLM's te fasiliteer met die vermoë om moderne en effektiewe sagtewaretoepassings te skep deur 'n virtuele-aangedrewe maatskappy vir sagteware-ontwikkeling te skep wat die watervalmodel vestig, en die sagteware-ontwikkelingsproses noukeurig in vier primêre verdeel. stadiums,

1. Ontwerp. 
2. Kodering. 
3. Toets. 
4. Dokumentasie. 

Elkeen van hierdie stadiums ontplooi 'n span virtuele agente soos kodeprogrammeerders of toetsers wat met mekaar saamwerk deur dialoë te gebruik wat 'n naatlose werkvloei tot gevolg het. Boonop maak ChatDev gebruik van 'n kletsketting wat as 'n fasiliteerder werk, en breek elke stadium van die ontwikkelingsproses af in atoomsubtake, wat dus dubbele rolle moontlik maak, wat voorsiening maak vir voorstelle en validering van oplossings deur konteksbewuste kommunikasie te gebruik wat ontwikkelaars in staat stel om effektief los die gespesifiseerde subtake op. Die kletsketting bestaan ​​uit verskeie nodusse waar elke individuele nodus 'n spesifieke subtaak verteenwoordig, en hierdie twee rolle is betrokke by multi-draai konteksbewuste besprekings om nie net die oplossings voor te stel nie, maar ook te valideer. 

In hierdie benadering ontleed die ChatDev-raamwerk eers 'n kliënt se vereistes, genereer kreatiewe idees, ontwerp en implementeer prototipe-stelsels, identifiseer en spreek potensiële probleme aan, skep aantreklike grafika, verduidelik die ontfoutingsinligting en genereer die gebruikershandleidings. Laastens lewer die ChatDev-raamwerk die sagteware aan die gebruiker saam met die bronkode, gebruikershandleidings en spesifikasies vir afhanklikheidsomgewing. 

ChatDev: argitektuur en werk

Noudat ons 'n kort inleiding tot ChatDev het, kom ons kyk na die argitektuur en werking van die ChatDev-raamwerk wat begin met die Chat-ketting. 

Kletsketting

Soos ons in die vorige afdeling genoem het, gebruik die ChatDev-raamwerk 'n watervalmetode vir sagteware-ontwikkeling wat die sagteware-ontwikkelingsproses in vier fases verdeel, insluitend ontwerp, kodering, toetsing en dokumentasie. Elkeen van hierdie fases het 'n unieke rol in die ontwikkelingsproses, en daar is 'n behoefte aan effektiewe kommunikasie tussen hulle, en daar is potensiële uitdagings wat in die gesig gestaar word wanneer individue geïdentifiseer word om mee om te gaan, en die volgorde van interaksies te bepaal. 

Om hierdie probleem aan te spreek, gebruik die ChatDev-raamwerk Chat Chain, 'n algemene argitektuur wat elke fase in 'n subatomiese klets afbreek, met elkeen van hierdie fases wat fokus op taakgeoriënteerde rolspel wat dubbele rolle behels. Die verlangde uitset vir die klets vorm 'n noodsaaklike komponent vir die teikenprogrammatuur, en dit word bereik as gevolg van samewerking en uitruil van instruksies tussen die agente wat aan die ontwikkelingsproses deelneem. Die kletskettingparadigma vir intermediêre taakoplossing word in die prent hieronder geïllustreer. 

Vir elke individuele geselsie begin 'n instrukteur eers die instruksies, en lei dan die dialoog na die voltooiing van die taak, en intussen volg die assistente die instruksies wat deur die instrukteur gelê is, bied ideale oplossings en tree in gesprek oor die haalbaarheid van die oplossing. Die instrukteur en die agent tree dan in multi-draai dialoë totdat hulle by 'n konsensus kom, en hulle beskou die taak as suksesvol uitgevoer. Die kettingketting bied aan gebruikers 'n deursigtige siening van die ontwikkelingsproses, werp lig op die pad om besluite te neem, en bied geleenthede om die foute te ontfout wanneer hulle opduik, wat die eindgebruikers in staat stel om die foute te analiseer en te diagnoseer, intermediêre uitsette te inspekteer, en gryp in die proses indien nodig geag. Deur 'n kletsketting in te sluit, is die ChatDev-raamwerk in staat om op elke spesifieke subtaak op 'n granulêre skaal te fokus wat nie net effektiewe samewerking tussen die agente fasiliteer nie, maar dit lei ook tot die vinnige bereiking van die vereiste uitsette. 

Die ontwerp van

In die ontwerpfase vereis die ChatDev-raamwerk 'n aanvanklike idee as 'n inset van die menslike kliënt, en daar is drie voorafbepaalde rolle in hierdie stadium. 

1. HUB of Hoof Uitvoerende Beampte. 
2. CPO of hoofprodukbeampte. 
3. CTO of Hoof Tegniese Beampte. 

Die kletsketting kom dan ter sprake en verdeel die ontwerpfase in opeenvolgende subatomiese kletstake wat die programmeertaal (CTO en HUB) en die modaliteit van die teikensagteware (CPO en HUB) insluit. Die ontwerpfase behels drie sleutelmeganismes: Roltoewysing of Rolspesialisasie, Geheuestroom en Selfrefleksie. 

Roltoewysing

Elke agent in die Chat Dev-raamwerk word 'n rol toegeken deur spesiale boodskappe of spesiale aanwysings tydens die rolspelproses te gebruik. Anders as ander gesprekstaalmodelle, beperk die ChatDev-raamwerk homself slegs tot die inisieer van die rolspel-scenario's tussen die agente. Hierdie aanwysings word gebruik om rolle aan die agente toe te ken voor die dialoë. 

Aanvanklik neem die instrukteur die verantwoordelikhede van die HUB, en is betrokke by interaktiewe beplanning, terwyl die verantwoordelikhede van die CPO hanteer word deur die agent wat take uitvoer en die vereiste antwoorde verskaf. Die raamwerk gebruik "begin aansporing” vir rolspesialisasie wat die agente in staat stel om hul rolle effektief te vervul. Die assistent- en instrukteuropdragte bestaan ​​uit belangrike besonderhede rakende die aangewese rolle en take, beëindigingskriteria, kommunikasieprotokolle en verskeie beperkings wat daarop gemik is om ongewenste gedrag soos oneindige lusse, oninsiggewende reaksies en instruksieoortolligheid te voorkom. 

Geheuestroom

Die geheuestroom is 'n meganisme wat deur die ChatDev-raamwerk gebruik word wat 'n omvattende gespreksrekord van die vorige dialoog's van 'n agent byhou, en bystaan ​​in die besluitnemingsproses wat volg op 'n uitingbewuste wyse. Die ChatDev-raamwerk gebruik aansporings om die vereiste kommunikasieprotokolle te vestig. Byvoorbeeld, wanneer die betrokke partye 'n konsensus bereik, 'n eindboodskap wat voldoen aan 'n spesifieke formateringsvereiste soos ( : Werkskermtoepassing"). Om voldoening aan die aangewese formaat te verseker, moniteer die raamwerk deurlopend, en laat die huidige dialoog uiteindelik tot 'n gevolgtrekking kom. 

Selfrefleksie

Ontwikkelaars van die ChatDev-raamwerk het situasies waargeneem waar beide die betrokke partye 'n wedersydse konsensus bereik het, maar die voorafbepaalde kommunikasieprotokolle is nie geaktiveer nie. Om hierdie kwessies aan te pak, is die ChatDev-raamwerk stel 'n selfrefleksiemeganisme bekend wat help met die herwinning en onttrekking van herinneringe. Om die selfrefleksiemeganisme te implementeer, begin die ChatDev-raamwerk 'n nuwe en vars klets deur "pseudo-self" as 'n nuwe vraesteller aan te roep. Die "pseudo-self" ontleed die vorige dialoë en historiese rekords, en lig die huidige assistent in, waarna dit 'n opsomming van afdoende en aksiewaardige inligting versoek soos gedemonstreer in die figuur hieronder. 

Met die hulp van die selfhelpmeganisme word die ChatDev-assistent aangemoedig om die besluite wat hy voorgestel het, te besin en te ontleed. 

Kodering

Daar is drie voorafbepaalde rolle in die koderingsfase, naamlik die CTO, die programmeerder en die kunsontwerper. Soos gewoonlik verdeel die kletskettingmeganisme die koderingsfase in individuele subatomiese take soos die generering van kodes (programmeerder en CTO), of om 'n GUI te ontwerp of grafiese gebruikerskoppelvlak (programmeerder en ontwerper). Die CTO gee dan die programmeerder opdrag om die markdown-formaat te gebruik om 'n sagtewarestelsel te implementeer waarna die kunsontwerper 'n gebruikersvriendelike en interaktiewe GUI voorstel wat van grafiese ikone gebruik maak om met gebruikers te kommunikeer eerder as om op tradisionele teksgebaseerde opdragte te vertrou. 

Kodebestuur

Die ChatDev-raamwerk gebruik objekgeoriënteerde programmeertale soos Python, Java en C++ om komplekse sagtewarestelsels te hanteer omdat die modulariteit van hierdie programmeertale die gebruik van selfstandige voorwerpe moontlik maak wat nie net help met probleemoplossing nie, maar ook met samewerkende ontwikkeling , en help ook om oortolliges te verwyder deur die voorwerpe te hergebruik deur die konsep van oorerwing. 

Gedagte-instruksies

Tradisionele metodes van vraagbeantwoording lei dikwels tot irrelevante inligting, of onakkuraathede, veral wanneer kode gegenereer word, aangesien die verskaffing van naïewe instruksies tot LLM-hallusinasies kan lei, en dit kan 'n uitdagende kwessie word. Om hierdie kwessie aan te pak, stel die ChatDev-raamwerk die "gedagte-instruksies"-meganisme bekend wat inspirasie put uit ketting-van-gedagte-vrae. Die "gedagte-instruksies"-meganisme spreek uitdruklik individuele probleemoplossingsgedagtes wat in die instruksies ingesluit is, aan, soortgelyk aan om take op 'n opeenvolgende en georganiseerde manier op te los. 

toets

Die skryf van 'n foutvrye kode in die eerste poging is uitdagend nie net vir LLM's, maar ook vir menslike programmeerders, en eerder as om die verkeerde kode heeltemal weg te gooi, ontleed programmeerders hul kode om die foute te identifiseer en reg te stel. Die toetsfase in die ChatDev-raamwerk word in drie rolle verdeel: programmeerder, toetser en beoordelaar. Die toetsproses word verder verdeel in twee opeenvolgende subatomiese take: Ewekniebeoordeling of statiese ontfouting (Resensent en Programmeerder), en Stelseltoetsing of dinamiese ontfouting (Programmeerder en toetser). Statiese ontfouting of ewekniebeoordeling ontleed die bronkode om foute te identifiseer, terwyl dinamiese ontfouting of stelseltoetsing die uitvoering van die sagteware verifieer deur verskeie toetse wat deur die programmeerder met 'n tolk uitgevoer word. Dinamiese ontfouting fokus hoofsaaklik op swartbokstoetsing om die toepassings te evalueer. 

dokumentasie

Nadat die ChatDev-raamwerk gedoen is met ontwerp-, koderings- en toetsfases, neem dit vier agente in diens, naamlik die HUB, CTO, CPO en Programmeerder om die dokumentasie vir die sagtewareprojek te genereer. Die ChatDev-raamwerk gebruik LLM's om 'n paar skoot-aanwysings te gebruik met in-konteksvoorbeelde om die dokumente te genereer. Die CTO gee die programmeerder opdrag om die instruksies vir die konfigurasie van omgewingsafhanklikhede te verskaf, en 'n dokument soos "afhanklikheidsvereistes.txt" te skep. Terselfdertyd word die vereistes en stelselontwerp deur die HUB aan die CPO gekommunikeer om die gebruikershandleiding vir die produk te genereer. 

Results

Sagteware Statistiek

Om die werkverrigting van die ChatDev-raamwerk te ontleed, die span ontwikkelaars het 'n statistiese ontleding gedoen oor die sagtewaretoepassings wat deur die raamwerk gegenereer word op grond van 'n paar sleutelmaatstawwe, insluitend verbruikte tekens, totale dialoogbeurte, beeldbates, sagtewarelêers, weergawe-opdaterings en 'n paar meer, en die resultate is gedemonstreer in die tabel hieronder. 

Duur Analise

Om ChatDev se produksietyd vir sagteware vir verskillende versoekopdragte te ondersoek, het die ontwikkelaars ook 'n tydsduuranalise uitgevoer, en die verskil in die ontwikkelingstyd vir verskillende aanwysings weerspieël die verskillende duidelikheid en kompleksiteit van die take wat opgedra is, en die resultate word in die figuur hieronder gedemonstreer. . 

Gevallestudie

Die volgende figuur demonstreer ChatDev wat 'n vyf in 'n ry of 'n Gomoku-speletjie ontwikkel. 

Die figuur heel links demonstreer die basiese sagteware wat deur die raamwerk geskep is sonder om enige GUI te gebruik. Soos dit duidelik gesien kan word, bied die toepassing sonder enige GUI beperkte interaktiwiteit, en gebruikers kan hierdie speletjie slegs deur die opdragterminal speel. Die volgende figuur demonstreer 'n meer visueel aantreklike speletjie wat geskep is met die gebruik van GUI, bied 'n beter gebruikerservaring en 'n verbeterde interaktiwiteit vir 'n boeiende spelomgewing wat baie meer deur die gebruikers geniet kan word. Die ontwerperagent skep dan bykomende grafika om die bruikbaarheid en estetika van die spel verder te verbeter sonder om enige funksionaliteit te beïnvloed. As die menslike gebruikers egter nie tevrede is met die beeld wat deur die ontwerper gegenereer word nie, kan hulle die beelde vervang nadat die ChatDev-raamwerk die sagteware voltooi het. Die buigsaamheid wat deur ChatDev-raamwerk aangebied word om die beelde met die hand te vervang, stel gebruikers in staat om die toepassings volgens hul voorkeure aan te pas vir 'n verbeterde interaktiwiteit en gebruikerservaring sonder om die funksionaliteit van die sagteware op enige manier te beïnvloed. 

Harde Gedagtes

In hierdie artikel het ons gepraat oor ChatDev, 'n LLM of Groottaalmodel gebaseerde innoverende paradigma wat daarop gemik is om die sagteware-ontwikkelingsveld te revolusioneer deur die vereiste vir gespesialiseerde modelle tydens elke fase van die ontwikkelingsproses uit te skakel. Die ChatDev-raamwerk het ten doel om die vermoëns van die LLM-raamwerke te benut deur natuurlike taalkommunikasie te gebruik om sleutelsagteware-ontwikkelingsprosesse te verenig en vaartbelyn te maak. Die ChatDev-raamwerk gebruik die kletskettingmeganisme om die sagteware-ontwikkelingsproses in opeenvolgende subatomiese take op te breek, en sodoende korrelfokus moontlik te maak en gewenste uitsette vir elke subatomiese taak te bevorder.