Introduction Ievads Būsim godīgi: ceļojums izskatās gandrīz vienādi visiem.Sākumā jūs atverat ChatGPT un domājat: Pāris rindas teksta un pēkšņi jums ir kods, mārketinga neskaidrība vai pat receptes ieteikums. “Wow, tas ir maģija!” Tad nāk nākamais posms. maģija lēnām pārvēršas haosā. Prompts kļūst garāks, uzdevumi uzkrājas, jūs sākat sasaistīt zvanus kopā - un kādu dienu jūs saprotat: “Labi, es tērēju vairāk laika, izskaidrojot modelim, kas man ir nepieciešams, nekā faktiski darot uzdevumu.” Trešais posms ir tas, kad lietas beidzot kļūst interesantas.Tas ir tad, kad jūs saprotat, ka haoss ir nepieciešams tam, un jūs sākat domāt kā inženieris.Ne kā kāds, kurš tinker ar rotaļlietu, bet kā arhitekts, kurš būvē sistēmu. Ļaujiet man jautāt jums: Joprojām spēlē apkārt ar ielūgumiem? iestrēdzis bezgalīgajās spageti ķēdēs? vai varbūt stāvot tieši pie kaut kā lielāka? where are you right now on this maturity curve? Šajā rakstā es gribu pavadīt jūs caur vienkāršu brieduma modeli LLM sistēmām - ceļojumu no ātrajiem eksperimentiem līdz pilnvērtīgai arhitektūrai, kur aģenti strādā kopā kā labi eļļota komanda. - pieeja, kas palīdz beidzot atbrīvoties no haosa. bet pirms mēs tur nokļūstam, ņemsim godīgu skatījumu uz to, kā vairums projektu attīstās. AAC (Agent Action Chains) Why We Need a Maturity Model Kāpēc mums ir nepieciešams izaugsmes modelis Pašlaik LLM sistēmām nav standarta izaugsmes ceļa. Katram izstrādātājam vai komandai ir savs ceļš, izmēģinot hacks, izgudrojot savas pieejas. Papīrā tas izklausās kā brīvība un radošums. Paskaties apkārt: daži projekti apstājas "tikai pievienojiet vēl vienu ielūgumu un tas darbosies" posmā. Citi veido garas zvanu ķēdes, kas izskatās jauki diagrammā, bet sabrūk pirmajā reālajā slodzē. Un tad ir bezkoda kartes, kas spirālveida simts bloku murgā, kas savienoti katrā virzienā. Demo dienā tas joprojām izskatās dzīvs. Bet, tiklīdz tas sasniedz ražošanu, nekas nav mērogs, nekas netiek izsekots, un neviens pat nevar pateikt, kur lietas sabruka. Desmitiem komandu un jaunuzņēmumu galu galā tērē mēnešus, ejot pa to pašu izmēģinājuma un kļūdas ceļu, atkārtoti izgudrojot to pašu riteņu atkal un atkal. Tā ir vieta, kur a Tas dod jums vienkāršu karti: kur jūs tagad esat un kas ir jāmaina, lai virzītos uz priekšu. Citi lauki to jau iepriekš ir piedzīvojuši. Agilās brieduma modeļi palīdzēja uzņēmumiem noskaidrot, vai tie patiešām bija agili vai vienkārši pārdēvēja uzdevumus par "sprintiem". DevOps briedums darīja to pašu atbrīvošanas procesiem, parādot, cik automātiski un atkārtoti tie patiešām bija. maturity model LLM sistēmas ir tādā pašā pagrieziena punktā šodien. Hype ir milzīgs, bet briedums ir gandrīz nulle. Level 1 - The Script (Prompting Playground) 1. līmenis - Skripts (Prompting spēļu laukums) Tas ir, kur gandrīz visi sākas. viens uzaicinājums ChatGPT vai viens API zvanu un uzplaukumu, jums ir atbilde. tas darbojas "pašlaik", bet tikai tik ilgi, kamēr jūs varat saglabāt detaļas galvā. Signs. Haotiski vaicājumi, bez atkārtošanās, neparedzami rezultāti.Šodien tas darbojas, rīt modelis dod jums kaut ko pilnīgi citu. Risks. Nekas šeit nevar tikt integrēts reālajā produktā vai biznesa procesā. When it makes sense. Ātri eksperimenti, prototipēšanas idejas vai tie pirmie "wow brīži", kad jūs vienkārši iegūstat sajūtu par to, ko LLM var darīt. Level 2 - The Complex Prompt (Prompt Engineering 2.0) 2. līmenis - sarežģītais prompt (Prompt Engineering 2.0) Šajā posmā cilvēki sāk "izlej burvestības" ar tekstu. viens vaicājums vairs nav pietiekams, tāpēc jūs saņemsiet garus ielūgumus ar lomu norādījumiem, detalizētiem soļiem un pat mini-scenārijiem. Signs. Jūs sākat sajust "formulēšanas burvību": mainīt vienu frāzi un modelis izspiež kaut ko pilnīgi citu.Daži cilvēki pat izveido steidzamas bibliotēkas, bet apakšā tas joprojām ir tikai viens liels monolīts. Risks. Kad sarežģītība pieaug, ielūgums pārvēršas par briesmonis, ko nevar uzturēt. Pievienot jaunu soli bieži nozīmē pārrakstīt visu. Pārbaude ir sāpīga. Šīs pieejas mērogojums? Gandrīz neiespējami. When it makes sense. Sarežģīti ielūgumi joprojām ir noderīgi pareizajā kontekstā: ātri MVP, mārketinga lietošanas gadījumi vai pētniecības projekti. Dažreiz tie sniedz iespaidīgu rezultātu “šeit un tagad”. Level 3 - The Linear Chain 3. līmenis - Lineārā ķēde Nākamais solis pēc "lielā uzaicinājuma" ir savienot vairākus LLM zvanus secībā. tagad sistēma nav viens masveida teksta bloks - tas ir virkne soļu: iegūt datus, apstrādāt to, un pēc tam ģenerēt atbildi, pamatojoties uz to. Signs. Šajā posmā sāk parādīties pirmās darba plūsmas, neatkarīgi no tā, vai tas ir LangChain, n8n vai Make.com. Cilvēki sāk domāt soļos, sadalot lielās problēmas apakšuzdevumos. Tas jau ir daudz labāk nekā viens milzīgs monolīts, bet tas joprojām ir stingri lineārs, bez atdalīšanas vai elastības. “Pirmkārt klasificējiet, pēc tam iegūstiet kontekstu, pēc tam izveidojiet atbildi.” Risks. Lielākā problēma ir stingrība.Šīs ķēdes ir izgriezti akmenī: mainīt vienu soli, un jūs bieži vien galu galā pārrakstīt visu pārējo. Pievienot jaunus scenārijus ir sāpīgi, un kļūdas mēdz pārtraukt visu ķēdi uzreiz.Tas ir kā agrīnās dienās mikroservisiem bez orķestratora-tehniski modulārs, bet joprojām tur kopā ar cauruļvadu lenti. When it makes sense. Šis līmenis darbojas lieliski maziem robotiem vai vienkāršām automatizācijām: e-pasta analīze, kopsavilkumu ģenerēšana, ātras atbildes sagatavošana.Tas ir labs sākumpunkts.Bet jebkurā reālajā produktā tas ātri kļūst par ierobežojumu. Level 4 - Spaghetti (Ad-hoc Systems) 4. līmenis - Spageti (Ad-hoc sistēmas) Tā ir vieta, kur sākas patiesa sāpes.Kad vienkārša lineāra ķēde vairs nedarbojas, izstrādātāji sāk uzkrāties uz “audzēm” un “ja – tā” nosacījumiem.Pagaidu atmiņa parādās – dažreiz tas ir tikai kods, dažreiz pielāgots uzglabāšanas hack, dažreiz mainīgais, kas netīši tiek nodots starp mezgliem.Logika kļūst neskaidra, un sistēma pārstāj būt lineāra. Signs. Darba plūsmas platformās bez koda sāk izskatīties kā zirnekļa tīkls: desmitiem mezglu, sajaukti savienojumi, loki visur. Projekti, kuru pamatā ir kods, nav daudz labāki: loģika ir izkaisīta pa ielūgumiem un palīgfunkcijām, kritiskie apstākļi ir paslēpti pašu ielūgumu tekstā. Risks. Šīs sistēmas ir murgs uzturēt. kad kaut kas sabrūk, noskaidrojot ir gandrīz neiespējami. kļūdas ir paslēptas, labošana nav pastāvīga, un viss ir atkarīgs no vienas personas, kas "zina, kā tas darbojas." Kur When it makes sense. Godīgi? nekad. spageti sistēmas parasti parādās kā eksperimentu blakusprodukts, bet paliekot šeit nogalina izaugsmi.Daudzas komandas sasniedz šo posmu un beidzot saprot: risinājums nav "tikai vēl viens hack" - tas ir reāla arhitektūra. Level 5 - Orchestrator + Roles (System Design Thinking) 5. līmenis - orķestris + lomas (sistēmu dizaina domāšana) Tas ir posms, kurā haoss beidzot pārvēršas sistēmā.Viens bezgalīgs ķēde vai spageti neskaidrība no filiālēm, jūs saņemsiet Katra sistēmas daļa zina savu darbu: structured design with clearly defined roles. - the brain that decides who does what and in what order. Orchestrator - narrow experts, each handling a specific task: classification, response generation, data retrieval. Specialists - makes sure the system isn’t living like a goldfish, giving it access to past context and knowledge. Memory - catches errors and ensures resilience, so one failure doesn’t bring everything down. Guard - monitors execution, collects logs, and provides visibility. Observer - polishes the final output and delivers it to the next stage. Egress Signs. Šajā līmenī jūs redzat formālos līgumus (bieži JSON), kas savieno lomas. Jūs varat testēt komponentus atsevišķi, apmainīties vai paplašināt tos, neizjaucot visu sistēmu. Risks. Jā, tas prasa vairāk pūļu iepriekš.Jums ir jādomā arhitektūrā, jāizstrādā lomas un jāatturas no vēlēšanās vienkārši "metināt citā ielūgumā".Bet šī investīcija atmaksājas ātri, ja jūsu sistēma ir paredzēta reāliem lietotājiem un mērogam. When it makes sense. Ražošanas vides, uzņēmējdarbības procesi un reālie produkti. Viss, kas pārsniedz eksperimentus, galu galā būs jāattīstās šajā posmā. Un tas ir tieši tur, kur AAC formalizē lomas, pievieno disciplīnu un ļauj šo izšķirošo lēcienu no “ātrās hacking” uz patiesu inženieriju. AAC (Agent Action Chains) How to Use This Model Kā izmantot šo modeli Reālā vērtība nobriedušā modeļa ir tas, ka tas darbojas kā spogulis. tas ļauj jums godīgi apskatīt savu projektu, redzēt, kur jūs esat, un izdomāt, kas ir jāmaina, lai virzītos uz priekšu. For self-assessment. Ja jūs veidojat kaut ko vienatnē vai nelielā komandā, modelis būtībā ir ātrs pārbaudes saraksts. Šis snapshot palīdz jums atpazīt rītdienas pudelēs šodien - un sagatavoties tiem iepriekš. “Vai mēs joprojām dzīvojam īstajā zemē? vai mēs esam uzcēluši vienkāršas ķēdes? vai mēs jau nogrimstam spageti?” For teams. Produkta vadītājs, inženieris un analītiķis nav jāzaudē tehniskajās detaļās - viņi var vienkārši nosaukt līmeni. - un visi zina, ko tas nozīmē. mazāk berzes, produktīvākas sarunas. "Mēs esam ķēdes stadijā, bet mums ir nepieciešams pāriet no spageti ASAP" For investors and partners. Modelis arī darbojas kā signāls par komandas briedumu. Startups, kas joprojām strādā ar neapstrādātiem paziņojumiem, var sniegt mirdzošus demos, protams, bet tas ir riskanti. LLM sistēmu evolūcija seko tam pašam lokam kā jebkura tehnoloģija: vispirms nāk maģija, tad haoss un beidzot - inženierzinātne.Mēs sākam ar vienkāršiem skriptiem, nokļūstam sarežģītos ieteikumos, mēģinām ķēdēt lietas kopā, noslīpējam spageti ... un tikai tad saprotam: ir pienācis laiks veidot arhitektūru. Pieaugušo modelis palīdz mums saskarties ar šo realitāti: redzēt, kur mēs esam, un zināt, kur mums jādodas tālāk.Dažiem tas nozīmē atbrīvoties no “monstriem”.Citiem tas nozīmē izvairīties no haotisko ķēžu lamatas.Un dažiem tas ir aicinājums pacelties uz nākamo līmeni, kur beidzot parādās orķestri, lomas un reālas sistēmas dizains. Tā ir vieta, kur iekļūst attēlā - arhitektūra, kas formalizē šo augstāko brieduma līmeni. bet AAC nav maģija. Tas ir rezultāts staigājot pa ceļu. AAC (Agent Action Chains) 👉 Šeit ir AAC sistēmas dizaina modelis, ja vēlaties ienirt dziļāk. Šeit ir AAC sistēmas dizaina modelis, ja vēlaties ienirt dziļāk.
