Įrašyti susitikimai – nepakankamai išnaudojamas žinių šaltinis. Juose sunku ieškoti, jų peržiūra užima daug laiko, o patys įrašai išsibarstę po komandų diskus, todėl vertingos įžvalgos dažnai lieka nepastebėtos.
Per vienos dienos hakatoną trijų žmonių komanda sukūrė „Callombia“. Tai vidinė platforma, kuri automatiškai transkribuoja ir žymomis papildo įrašytus pokalbius, rengia jų santraukas, iškerpa fragmentus ir perkelia juos į visuose pasauliniuose biuruose pasiekiamą „YouTube“ primenančią saugyklą su paieška.
Visas su Codex sukurtas sprendimas pasitelkia semantinę paiešką, paremtą OpenAI įterpiniais ir kosinuso panašumu, kad rastų aktualius momentus net nenaudojant tikslių raktažodžių. Jį papildo RAG pokalbių robotas ir pranešimų sistema.
Tai, kas anksčiau būtų užtrukę kelias savaites, buvo sukurta per septynias valandas. Tai parodė, kaip DI pritaikytas kūrimas su tokiais programavimo agentais kaip Codex gali gerokai sutrumpinti produkto kūrimo ciklą ir padėti vidiniuose hakatonuose sukurti tikrą verslo vertę.
Jei esate panašūs į mane, tikriausiai retai turite laiko (ar kantrybės) iš naujo klausytis įrašytų susitikimų. Dažnai taip yra todėl, kad tenka naršyti netvarkingus komandų diskus, praleidinėti nekokybiškus nereikšmingus pokalbius ir mėginti iš tikrųjų klausytis tuo pat metu siunčiant el. laiškus bei žinutes.
Bet galbūt taip neturi būti? Gal galėtume sukurti ką nors, kas visiškai pakeistų įrašytų susitikimų naudojimą? Būtent tokia mintis paskatino mūsų naujausią hakatono projektą.
Vos per vieną dieną 50 mūsų inžinerijos, įgyvendinimo ir operacijų komandų narių sprendė įvairiose verslo srityse iškeltas problemas: kaip plėsti įdarbinimo operacijas, supaprastinti darbų apimties dokumentų kūrimą, įvertinti projektų būklę, realiuoju laiku kurti prototipus ir rasti įžvalgų įrašytuose susitikimuose.
Šiame Codex paremtame hakatone sukūrėme „Callombia“. „Callombia“ – mūsų įmonės „YouTube“, kiekvieną pokalbį paverčianti nuolat atnaujinamu ištekliumi su paieška. Kiekvienas pokalbis automatiškai transkribuojamas, pažymimas žymomis ir apibendrinamas, tada suskaidomas į teminius fragmentus ir įtraukiamas į saugyklą, suskirstytą pagal kanalus (klientus) bei temas (DI specializacijos sritis). Todėl bet kuris komandos narys Londone, Edinburge, Singapūre ar Australijoje gali iš karto pasiekti jam svarbius pokalbių momentus.
Pažįstama, mūsų prekės ženklą atitinkanti naudotojo sąsaja leidžia intuityviai atrasti turinį, o semantinė paieška (ir, žinoma, RAG DI pokalbių robotas) padeda žmonėms rasti būtent tai, ko jie ieško. Pranešimų sistema taip pat leidžia kolegoms užsiprenumeruoti tam tikras temas ir gauti pranešimus, kai paskelbiami jiems aktualūs nauji fragmentai.
Tačiau įdomiausia „Callombia“ dalis – ne pats produktas ir net ne 2 tūkst. svarų prizas už pergalę hakatone (pasigyrėme), o tai, kad du inžinieriai ir įgyvendinimo vadovas visa tai sukūrė vos per septynias valandas. Prieš metus tai nebūtų buvę įmanoma. Programavimo agentų pažanga labai paspartino visą produkto kūrimo procesą, o šis hakatonas tapo puikia bandymų erdve kintančioms jų galimybių riboms pažinti. Taigi, kaip naudojome Codex?
Užuot tiesiog surašę daugybę reikalavimų, pirmiausia užklausoje pateikėme bendrą požiūrį į sprendžiamą problemą ir „Callombia“ viziją. Sąmoningai vengėme konkretumo, kad modelis galėtų atlikti savo darbą ir mąstyti kūrybiškai:
Po dešimties minučių diskusijos įjungėme planavimo režimą, kad patikslintume reikalavimus ir pasirengtume techninei kūrimo daliai. Planavimo režimas primena atsakinėjimą į klausimus to įkyraus draugo, kuris (laimei) jau apgalvojo visus įmanomus scenarijus. Sutarus dėl tokių dalykų kaip vaizdo įrašų skaičius, semantinė ar raktažodžių paieška ir būsima architektūra, Codex sukūrė „Markdown“ failą, tapusį tolesnio projekto pagrindu.
Parengus planą, reikėjo sukurti pagrindinius komponentus, kad „Callombia“ iš tiesų veiktų. Tam reikėjo sukurti procesą, kuris įrašytus pokalbius paverstų ištekliais su paieška:
Importuoti vaizdo įrašus ir transkripcijas,
Suskirstyti juos į prasmingus momentus,
Papildyti juos santraukomis ir žymomis,
Pateikti juos per API, kuriomis galėtų naudotis kliento dalis.
Edas daugiausia rūpinosi, kad neapdoroti įrašai ir transkripcijų duomenys būtų paversti tinkamu naudoti formatu, o Nico kūrė paieškos sluoksnį, kuris leistų šiuos momentus atrasti. Naudodamiesi Codex, abu jie daug greičiau, nei būtume galėję rankiniu būdu, sukūrė duomenų modelius, išgavimo scenarijus ir vidinės sistemos infrastruktūrą. Taip gavome kur kas daugiau nei prie vaizdo įrašo pridėtą transkripciją. Gavome konkrečius momentus: dalį apie „Tesco“, strategijos naujienas, diskusiją apie įdarbinimą ar tas konkrečias 90 pokalbio sekundžių, kurias kas nors iš tiesų nori peržiūrėti.
Būtent paieškos sluoksnyje viskas tapo ypač įdomu. Norėjome, kad įvedęs, pavyzdžiui, “financial performance,” “Tesco roadmap,” arba “conversation evals”, žmogus iš karto rastų aktualiausius fragmentus, net jei šie tikslūs žodžiai pokalbyje niekada nebuvo ištarti. Tam sukūrėme dalis su laiko žymomis, santraukomis, transkripcijos tekstu ir metaduomenimis. Turėdami aiškią architektūrą ir daug padedami Codex, sujungėme temą, santrauką bei transkripciją į vieną įvestį ir kiekvienos dalies įterpiniams generuoti panaudojome OpenAI modelį text-embedding-3-small. Šiuos įterpinius išsaugojome duomenų bazėje ir, pasitelkę kosinuso panašumą, lyginome naudotojo užklausą su kiekviena dalimi. Taip vietoje paprastos raktažodžių paieškos gavome semantinės paieškos sluoksnį.
Šis sprendimas buvo itin tikslus ir per hakatono demonstraciją suteikė produktui magiškumo įspūdį. Kartu žinojome, kad vaizdo įrašų skaičiui toliau augant šis metodas ilgainiui taptų sunkiai plečiamas, nes kiekvieną užklausą lyginti su kiekviena dalimi galiausiai būtų per brangu. Natūralus kitas žingsnis būtų diegti efektyvesnes paieškos strategijas, pavyzdžiui, „Hierarchical Navigable Small World“, kad sumažėtų palyginimų skaičius, o duomenų rinkiniui augant delsa išliktų maža. Kai ši funkcija pradėjo veikti, „Callombia“ tapo panašesnė ne į medijos biblioteką, o į žinių sistemą.
Kaip ir kiekviename gerame hakatone, šią dalį taip pat reikėjo tobulinti: pradinės dalių ribos buvo per daug apytikslės, kai kurias laiko žymas reikėjo patikslinti, kai kurios žymos buvo per plačios, o transkripcijos ir įrašų failai ne visada sklandžiai sutapdavo. Tačiau būtent čia ir atsiskleidė vertė. Codex leido greitai tobulinti sistemą, užuot strigus ties konfigūravimu ir perdarymu. Galiausiai turėjome vidinę sistemos dalį, galinčią teikti fragmentus, ištraukas ir tikrai naudingą semantinę paiešką. Tuomet „Callombia“ jau pradėjo priminti tikrą produktą, o ne vien hakatono demonstraciją.
Kol Edas ir Nico kūrė duomenų importavimo bei intelekto sluoksnius, aš kūriau kliento dalį. Naudodamas mūsų viso technologijų rinkinio šabloną, greitai sukūriau pirmąją svetainės versiją neparašęs nė vienos kodo eilutės. Paprašęs vietoje atverti svetainę mano naršyklėje, pateikdavau paprastą punktų sąrašą su pastabomis ir taip nuosekliai tobulinau dizainą, kol gavau norimą rezultatą.
Po maždaug valandos tokio bendravimo jau turėjau rezultatą, kuriuo buvau gana patenkintas, nors neturėjau jokios naudotojo sąsajų ar dizaino patirties. Nors galutinis produktas tikrai nėra tobulas, tai gana vykusi pirmoji versija, padedanti žmonėms suprasti produktą.
Kad dienos pabaigoje tikrai turėtume rezultatą, darbus pasidalijome tarpusavyje. Žinoma, po kelių valandų iš dalies savarankiško darbo visi turėjome savo vietines šakas su daugybe konfliktų.
Užuot skyrę laiko, kurio neturėjome, ir kruopščiai sprendę konfliktus, nusprendėme tiesiog leisti Codex savarankiškai darbuotis saugyklose ir juos ištaisyti. Nors šiuo metu nerekomenduotume taip kurti įmonėms skirtos programinės įrangos, buvo neįtikėtina stebėti šio metodo veiksmingumą mažos rizikos aplinkoje – jis sutaupė mums daugybę valandų.
Paskutinė hakatono užduotis buvo įrašyti „Callombia“ demonstraciją vertintojams. Iš pradžių instinktyviai norėjome įrašymui atsidaryti „Loom“, tačiau pagalvojome, kad tai galėtų būti rimtas Codex išbandymas ir užduotis, šiek tiek peržengianti dabartines jo galimybes. Taigi… parašėme užklausą, pateikėme nuorodą į „Callombia“ svetainę, pridėjome mano balso įrašą iš OpenAI kūrėjų platformos ir paprašėme visa kita padaryti savarankiškai.
Pirmasis bandymas buvo labai įspūdingas: Codex parašė demonstracijos scenarijų, įrašė ekraną, pridėjo mano balsą ir iš esmės įvykdė užduotį. Vienintelis dalykas, kuriuo iš karto nebuvome patenkinti, buvo balso įrašo sinchronizavimas su demonstracija, todėl paprašėme: “MANDATORY: align the voiceover exactly with what is being shown in the demo. There was misalignment (e.g. on the chat page). Triple check alignment of voiceover and the screen-recorded demo at the end. Match it up through whichever means possible.”
Atsakydamas į šį prašymą, Codex suskaidė balso ir ekrano įrašus į trumpesnes dalis ir beveik nepriekaištingai atliko užduotį kaip tik iki 17.30 val., kai jau laukė šventinis alus ir pica.
Žinome, kad „Callombia“ sprendžia daugumai įmonių aktualią problemą. Sparčiai augančioje įmonėje sunku dalyvauti kiekviename pokalbyje, tačiau juose pasidalytos vertingos įžvalgos yra neįkainojamos. Dabar tereikia parengti sistemą naudoti realioje aplinkoje.
Tačiau čia slypi ir svarbesnė pamoka apie DI integravimą į veiklą bei naudą, kurią suteikia inžinerijos ir produktų kūrimo kompetencijų sutelkimas bendroms problemoms spręsti. Ištrūkę iš įprasto darbo ritmo, bendradarbiaudami tarp komandų ir veikdami šiek tiek konkurencingoje aplinkoje, galiausiai sukūrėme ne vieną sprendimą, kurį šiek tiek patobulinus būtų galima naudoti realioje aplinkoje. Reguliariai tai kartodami galime užtikrinti, kad mūsų vidiniai procesai būtų tokie pat sklandūs kaip klientams kuriami sprendimai.