DI Agento Kūrimas: Nuo Idėjos Iki Realaus Darbo

Kaip Sukurti DI Agentą, Kuris Greitai Pradeda Veikti Realiame Darbe

Dauguma komandų klausia „kaip sukurti DI agentą" tada, kai dar net nežino, ką tas agentas turėtų daryti. Geresnis pirmas klausimas - koks darbo procesas turi pereiti į agento rankas nuo pradžios iki galo.

Greitai paleisti agentą labiau padeda ne modelio pasirinkimas, o aiškiai apgalvota sistema, testavimas ir tvirtai nubrėžtos ribos. Gražus demo visada nusileidžia nuobodokai, bet patikimai veikiančiai sistemai. Šiame straipsnyje parodysime, kaip apsibrėžti užduotį, suprojektuoti architektūrą, pasirinkti tinkamą kūrimo kelią ir užtikrintai paleisti agentą į realų darbą.

1 dalis. Apgalvokite Užduotį Prieš Pradėdami Rašyti Kodą

Geriausių rezultatų pasiekia tos komandos, kurios pasirenka labai aiškų ir siaurą tikslą. Ne „pagerinti pardavimus". Ne „automatizuoti operacijas". Viena užduotis, vienas procesas ir vienas konkretus rezultatas, kurį galima pamatuoti skaičiais.

Pokalbių robotas tik kalba. Agentas dirba. Pokalbių robotas atsako į atvirus klausimus, o DI agentas priima aiškiai sutvarkytą informaciją, laikosi taisyklių, atlieka veiksmus ir pateikia rezultatą, kurį komanda gali patikrinti. MIT Sloan (opens in new tab) agentus apibrėžia kaip sistemas, galinčias siekti tikslų su tam tikru savarankiškumo lygiu - būtent „tam tikru". Gamybos agentai nėra autonomiški sprendimų priėmėjai. Jie yra aiškiai apibrėžtos paskirties profesionalai.

Geras pirmasis procesas, kurį verta automatizuoti, turi tris savybes: jis brangiai kainuoja laiku ar pinigais, jis pasikartoja vėl ir vėl, ir jo rezultatus lengva pamatuoti. Pavyzdžiui - pasiūlymų rengimas, sąskaitų apdorojimas, klientų užklausų rūšiavimas, dokumentų sekimas, ataskaitų ruošimas. Visus šiuos procesus galima aiškiai palyginti „prieš" ir „po": kiek valandų sugaišdavo komanda, kiek klaidų atsirasdavo, per kiek laiko būdavo atsakoma į užklausą.

Tinkama pirmoji versija yra maža ir aiškiai apibrėžta. Ji priima tvarkingą informaciją - formos laukus, duomenis iš CRM, sąskaitos informaciją. Į DI modelį kreipiasi tik laikydamasi griežtų taisyklių. Naudoja kuo mažiau atminties. Atlieka vieną ar du veiksmus. Pateikia rezultatą, kurį žmogus gali peržiūrėti prieš jam keliaujant toliau. Įsivaizduokite ją kaip naują darbuotoją su aiškiu užduočių sąrašu, o ne kaip laisvai veikiantį asistentą.

Ko dar reikia prieš paleidžiant agentą į realų darbą: prieigos prie API, sistemos, kuri viską fiksuoja žurnale, būdo testuoti, kaip užduodate užklausas modeliui ir vertinti, ką jis grąžina, versijuojamų duomenų struktūrų ir vieno žmogaus iš verslo pusės, kuris aiškiai pasako, ką laikys sėkme. Be šių dalykų jūs tiesiog spėliojate. Su jais galite išbandyti pakeitimus, suprasti, kur kas sugedo, ir greitai tobulinti sistemą.

2 dalis. Penki DI agento architektūros sluoksniai

Geriausia DI agento architektūra retai būna pati protingiausia - dažniau ji būna pati aiškiausia. Įsivaizduokite ją kaip sluoksnius: kiekvienas sluoksnis atlieka vieną darbą, ir kiekvieną galima patikrinti atskirai.

1. Įvesties sluoksnis. Čia užtikrinama kokybė. Šis sluoksnis sutvarko užklausą dar prieš ją perduodant DI modeliui. Aiškiai apibrėžti laukai. Patikrinimo taisyklės. Tik tas kontekstas, kurio iš tikrųjų reikia užduočiai atlikti. Pavyzdžiui, klientų užklausų rūšiavimo agentui užtenka žinoti užklausos tipą, kliento lygį, produkto sritį ir paskutines penkias žinutes. Visos CRM informacijos jam nereikia. Jei trūksta datos, failas per didelis arba laukas užpildytas netaisyklingai - sustabdykite užklausą iškart, dar šiame sluoksnyje. Neleiskite modeliui spėlioti, ką darytumėt jūs.

2. DI sluoksnis. Modelis samprotauja, apibendrina informaciją, ją ištraukia iš teksto, surikiuoja pagal svarbą ir parašo juodraščius. Jis nesprendžia, kokios yra verslo taisyklės, kas turi teisę ką daryti ir kas duoda galutinį patvirtinimą. Galvokite apie modelį kaip apie stiprų analitiką, o ne kaip apie teisininką. Leiskite jam pasiūlyti, kaip suformuluoti klientui grąžinimo laišką. Bet neleiskite jam nuspręsti, kam pinigai iš tikrųjų bus grąžinti.

3. Atminties sluoksnis. Pradėkite nuo mažesnės atminties, nei jums atrodo reikalinga. Daugumai pirmųjų versijų pakanka pokalbio konteksto, jau patvirtintų pavyzdžių ir paieškos pirminiuose dokumentuose. Aiškiai nustatykite, kokia informacija yra laikina, kokia - pastovi, o kokios niekada negalima saugoti. Daug komandų šį sluoksnį perkrauna. Jūsų pirmajai versijai nereikia atminties, kuri prisimena viską. Jai reikia tinkamos informacijos tinkamu laiku.

4. Veiksmų sluoksnis. Štai kur agentas pradeda dirbti realų darbą. Kvietimai į API, įrašų kūrimas, juodraščių rengimas, užduočių paskirstymas, perdavimas žmogui. Čia pat sudedami ir apsauginiai mechanizmai: garantija, kad tas pats veiksmas nebus atliktas du kartus, pakartojimai, kai kažkas nepavyksta iš pirmo karto, teisių patikrinimai ir veiksmų istorijos žurnalai. Agento vertė yra ne pokalbis. Vertė yra procesas, kurį jis įvykdo - ir tas procesas vertas pasitikėjimo tik tada, kai kiekvienas veiksmas yra užregistruotas ir gali būti atšauktas.

5. Išvesties sluoksnis. Padarykite, kad rezultatai būtų aiškios struktūros, lengvai peržiūrimi ir patikrinami. Grąžinkite tvarkingą atsakymą su pasitikėjimo žymėmis, informacijos šaltiniais ir statuso kodais. Vien laisvas tekstas yra sunkiai testuojamas ir dar sunkiau patikimas. Pavyzdžiui: { patvirtinta: ne, priežastis: "trūksta PVM kodo", kitas_žingsnis: "perduoti žmogui" }. Toks formatas lengvai įsijungia į ataskaitų skydelius, eiles ir įspėjimų sistemas. Toks formatas verčia agentą būti sąžiningą: jei jis nėra tikras dėl atsakymo, jis tai atvirai pasako, o ne pateikia gražiai skambantį, bet neteisingą rezultatą.

Pradėkite nuo paprasčiausios veikiančios versijos. Vienas API kelias. Viena užklausa modeliui. Vienas paieškos žingsnis. Vienas veiksmas. Vienas tvarkingas atsakymas. DI agentą galima sukurti ir be jokio karkaso - daugeliui komandų taip ir derėtų pradėti. Pradėkite nuo mažo, įsitikinkite, kad sistema veikia tinkamai, ir tik tada sustiprinkite ją žurnalais, kokybės vertinimais ir žmogaus peržiūra.

3 dalis. Kaip Sukūrėme DI Agentą Mygom Komandoje

Pradėjome ne nuo klientams skirto produkto, o nuo savo pačių komandos. Toks pasirinkimas davė mums greitą grįžtamąjį ryšį ir kuo mažesnę riziką - jei juodraštis pasirodydavo netinkamas, mes tai pastebėdavome dar viduje, prieš jam pasiekiant klientą.

Mūsų DI įrankis, kuris rašo pasiūlymus už mus (opens in new tab) buvo pirmasis tikras agentas, kurį paleidome į realų darbą. Jo architektūra tiksliai atitiko anksčiau aprašytus penkis sluoksnius. Įvestis būdavo tvarkinga ir aiški - projekto dydis, apimties kategorija, kliento lygis. Tada įsijungdavo konteksto surinkimo žingsnis, kuris pats ištraukdavo kainodaros taisykles ir tinkamus pavyzdžius iš ankstesnių pasiūlymų. Tik tada modelis parašydavo juodraštį - pagal turimus duomenis, o ne pagal savo prielaidas. Rezultatą peržiūros sąsajoje pamatydavo žmogus, kartu su pasitikėjimo žymėmis, ir patvirtindavo kiekvieną galutinę versiją. Pasiūlymų rengimas iš 3-4 valandų sutrumpėjo iki 30-60 minučių. Bet šis pagerinimas atsirado ne dėl paties modelio - jis atsirado dėl tvarkingesnės įvesties, stipresnių apsaugų ir peržiūros žingsnio, kuris padėjo išlaikyti aukštą kokybę.

Ta pati logika veikė ir kuriant mūsų DI sąskaitų automatizavimo platformą (opens in new tab). Tikslas buvo aiškus ir siauras: sąskaitų fiksavimas, jų suderinimas ir dublikatų prevencija. Ne visa finansų valdymo sistema. Ne universalus asistentas. Tik vienas konkretus darbas. Rezultatas - 40% greitesnis sąskaitų apdorojimas, 30% mažesnės sąnaudos ir 10 kartų didesnė apimtis. Dabar tą pačią sistemą diegiame finansų komandoms, kurios susiduria su tomis pačiomis problemomis, su kuriomis kažkada gyvenome ir mes patys.

Štai paradoksali pamoka - jūsų geriausias pirmas žingsnis retai būna klientams skirtas pokalbių robotas. Dažniausiai tai vienas labai daug trinties keliantis vidinis procesas, už kurį kažkas aiškiai atsakingas. Pradėkite ten, kur skausmas akivaizdus ir kur grįžtamasis ryšys ateina greitai. Komandos, kurios paleidžia tikrai veikiančius agentus, yra tos, kurios atsispiria pagundai iškart paleisti viską plačiai - dar prieš įsitikindamos, kad sistema veikia bent vienoje vietoje, kurią jos pačios pilnai kontroliuoja.

4 dalis. Trys kūrimo keliai ir jų skirtumai

Kai užduotis apibrėžta, o architektūra aiški, lieka apsispręsti - kaip viską pristatyti. Yra trys realūs keliai, ir blogai pasirinktas kelias jus stabdys nepriklausomai nuo to, kaip gerai apgalvotas jūsų dizainas.

Kelias 1: Nuosavas kūrimas naudojant tiesioginius API. Tinka, kai reikia greičio, kontrolės ir griežtai apibrėžto piloto. Šis kelias gerai veikia, kai procesas yra siauras, klaidos kaina nedidelė, o jūsų komandoje yra inžinierių, kurie gali patys valdyti visą sistemą. Per savaitę galite sujungti formą, modelio iškvietimą ir vieną veiksmą. Kompromisas: viskas tampa jūsų atsakomybe - pakartojimai, užklausos modeliui, vertinimai, žurnalai, srauto ribos ir kiekviena nauja integracija. Tinka pirmai versijai. Bet greitai tampa skausminga, jei nelaikote apimties siauros.

Kelias 2: Kūrimas su paruoštais sprendimais. Tokie įrankiai kaip n8n, LangChain ar panašūs paspartina darbą - jie padeda sujungti įrankius, valdyti būseną ir suprojektuoti procesus. Naudinga, kai komanda nori paruošto sprendimo ir nenori iš naujo kurti bazinių dalykų. Kompromisas: tokie įrankiai dažnai paslepia sudėtingas detales. Abstrakcijos gali nuslėpti, kiek iš tikrųjų kainuoja kiekviena užklausa, kokiu keliu eina procesas ir kur tiksliai įvyksta klaidos. Klaidų ieškojimas tada virsta sunkia, varginančia detektyvine užduotimi. Tai tampa rimta problema, kai jūsų agentas peržengia demo ribas ir pradeda dirbti su realiu srautu.

Kelias 3: Individuali komanda pilnam diegimui. Šis kelias tampa būtinas, kai procesas paliečia pajamas, atitiktį reikalavimams arba apima kelias pagrindines sistemas vienu metu. Jei agentas turi skaityti sutartis, rašyti į ERP sistemą ir paleisti patvirtinimus per skirtingus padalinius, sutrumpinimai greitai virsta brangiomis klaidomis. Tokiu atveju kruopštus pristatymas yra svarbiau už greitą startą. Šis kelias iš pradžių kainuoja daugiau. Bet jis duoda geresnę architektūrą, kokybišką testavimą, saugumo peržiūrą ir aiškią paleidimo discipliną - visus tuos dalykus, kurie nulemia, ar jūsų agentas vis dar gerai veiks po šešių mėnesių.

Kaip pasirinkti tarp trijų kelių. Atsakykite į šiuos klausimus.

Kiek svarbus procesas? Jei agentas nustos veikti, pasekmė bus prarasta užduotis ar prarastas klientas? Kaip greitai turite pradėti? Kiek realiai turite programavimo pajėgumų? Kiek rizikos leidžiate sau gamyboje - kas, jei kažkas visgi neveiks?

Atsakymai į šiuos klausimus parodys tinkamą kelią. DIY tinka tada, kai procesas siauras, o klaidos kaina maža - vienas vidinis įrankis, ribotas bandymas, kažkas, ką galite išjungti niekam nepastebėjus. Paruošti sprendimai prasmingi tada, kai reikia greičio ir jūsų komanda gali ištverti šiek tiek klaidų ieškojimo trinties - tinka vidutinio reikšmingumo procesams, kurie tiesiogiai neliečia pajamų. Individuali komanda yra tinkamas pasirinkimas tada, kai procesas yra kritinis verslui, apima kelias sistemas arba būtų sunkiai atšaukiamas po paleidimo - sutartys, įrašai į ERP sistemą, finansinė kontrolė, viskas, kur klaidingas rezultatas atsiliepia realiais pinigais.

Kaip atrodo darbas gamyboje

Testavimas nėra pasirinktinas, kai agentas pradeda dirbti su realiu procesu. Reikia matuoti, kaip gerai veikia užklausos modeliui, ar atsakymai atitinka reikiamą struktūrą, kiek tiksli yra informacijos paieška, kiek dažnai įrankiai pasitelkiami sėkmingai, kiek užtrunka kiekvienas veiksmas, kiek kainuoja viena užduotis ir kaip dažnai į procesą tenka įsikišti žmogui. Šie signalai pasako, ar sistema gerėja, ar prastėja. Jie taip pat padeda pastebėti tas klaidas, kurios komandoms skauda labiausiai — neaiškiai apibrėžtą apimtį, prastus duomenis, per didelę laisvę agento veiksmams, neatsekamus užklausų pakeitimus, prastą stebėjimą ir saugaus atsitraukimo nebuvimą, kai agentas pradeda abejoti.

Realiai veikianti sistema paleidžiama su versijuojamomis užklausomis, tvarkingais atsakymais, veiksmų istorijos žurnalais, funkcijų jungikliais, srauto ribomis, išlaidų kontrole ir aiškiai numatytu būdu perduoti darbą žmogui. Tai gali skambėti mažiau įspūdingai už gražų modelio demo. Bet būtent tai ir yra skirtumas tarp eksperimento, kurį komanda toleruoja, ir sistemos, kuria verslas iš tikrųjų gali pasitikėti.

Modelis - tik viena sistemos dalis. Tinkamai apibrėžta užduotis, tvarkinga įvestis, kontroliuojami veiksmai, aiškios struktūros išvestys ir patikima peržiūros eiga - tai visa kita.

Jei vis dar klausiate, kaip sukurti DI agentą, pradėkite nuo mažesnio projekto, nei jums iš pradžių atrodo reikalinga. Pasirinkite vieną procesą. Apibrėžkite, kas jums atrodys sėkmė. Paleiskite versiją su geru matomumu ir aiškiomis ribomis. Plėskite tik tada, kai turite realių įrodymų, kad sistema dirba taip, kaip turėtų.

Komandos, kurios šioje srityje laimi, nebus tos, kurios turi įspūdingiausius prototipus. Tai bus tos, kurios paleidžia sistemą su disciplina, sąžiningai matuoja jos veiklą ir kiekvieną savaitę tobulina ją realiame darbe.

Jei norite aiškaus gamybinio plano būsimam agentui, susisiekite su mumis (opens in new tab).