Ierakstītas sapulces ir nepietiekami izmantots zināšanu avots. Tajās ir grūti meklēt, to atkārtota pārskatīšana prasa daudz laika, un tās ir izkaisītas pa komandu diskiem, tāpēc vērtīgas atziņas bieži paliek nepamanītas.
Vienas dienas hakatonā trīs cilvēku komanda izveidoja Callombia. Tā ir iekšēja platforma, kas automātiski transkribē un marķē ierakstītos zvanus, veido to kopsavilkumus un tematiskus fragmentus, pārvēršot tos par meklējamu YouTube stila repozitoriju, kas pieejams birojiem visā pasaulē.
Risinājums ir pilnībā izveidots ar Codex un izmanto OpenAI iegultojumos un kosinusa līdzībā balstītu semantisko meklēšanu, lai atrastu atbilstošos brīžus pat tad, ja nav izmantoti precīzi atslēgvārdi. To papildina RAG tērzēšanas bots un paziņojumu sistēma.
Tas, kam agrāk būtu vajadzīgas vairākas nedēļas, tika paveikts septiņās stundās. Tas parāda, kā mākslīgajā intelektā balstīta izstrāde ar tādiem programmēšanas aģentiem kā Codex var ievērojami saīsināt produkta izstrādes ciklu un palīdzēt iekšējos hakatonos radīt patiesu vērtību uzņēmumam.
Ja esat tāds pats kā es, jums reti pietiek laika (vai uzmanības), lai vēlreiz noklausītos ierakstītas sapulces. Bieži vien tas nozīmē rakņāties nesakārtotos komandu diskos, pārtīt mazvērtīgas ikdienas sarunas un mēģināt patiesi klausīties, vienlaikus steidzīgi atbildot uz e-pasta vēstulēm un ziņām.
Bet varbūt tam nav jābūt tik sarežģīti? Varbūt mēs varētu radīt kaut ko tādu, kas pilnībā mainītu darbu ar ierakstītām sapulcēm? Šī doma bija mūsu nesenā hakatona projekta pamatā.
Vienā dienā 50 mūsu izstrādes, projektu īstenošanas un operāciju komandu darbinieki risināja dažādas uzņēmumā apzinātas problēmas — no personāla atlases operāciju mērogošanas un SoW izveides vienkāršošanas līdz projektu stāvokļa izpratnei, prototipu ģenerēšanai reāllaikā un ierakstītās sapulcēs ietverto atziņu atrašanai.
Šajā uz Codex balstītajā hakatonā mēs izveidojām Callombia. Callombia ir mūsu uzņēmuma YouTube, kas ikvienu zvanu pārvērš par pastāvīgi papildināmu un meklējamu resursu. Katrs zvans tiek automātiski transkribēts un marķēts, tam tiek izveidots kopsavilkums, pēc tam tas tiek sadalīts tematiskos fragmentos un pievienots repozitorijam, kas sakārtots pēc kanāliem (klientiem) un tēmām (MI specializācijas jomām). Tādējādi ikviens komandas dalībnieks Londonā, Edinburgā, Singapūrā vai Austrālijā var uzreiz piekļūt sev svarīgajiem zvanu fragmentiem.
Pazīstama, zīmolam atbilstoša lietotāja saskarne ļauj saturu atrast intuitīvi, savukārt semantiskā meklēšana (un, protams, RAG MI tērzēšanas bots) palīdz atrast tieši meklēto. Paziņojumu sistēma ļauj kolēģiem arī abonēt noteiktas tēmas un saņemt paziņojumus par jauniem, viņiem aktuāliem fragmentiem.
Taču iespaidīgākais Callombia aspekts nav pats produkts vai hakatonā laimētā 2000 £ balva (nedaudz palielīsimies), bet gan tas, ka divi inženieri un projektu vadītājs to visu spēja izveidot tikai septiņās stundās. Pirms gada tas nebūtu bijis iespējams. Programmēšanas aģentu uzlabojumi ir būtiski paātrinājuši visu produkta izstrādes procesu, un šis hakatons bija lieliska izmēģinājumu vide, kurā izpētīt šo tehnoloģiju nevienmērīgās iespēju robežas. Kā mēs izmantojām Codex?
Tā vietā, lai vienkārši uzrakstītu virkni prasību, mēs vispirms uzvednē izklāstījām savu kopīgo skatījumu uz problēmu jomu un Callombia ieceri. Apzināti izvairoties no pārmērīgas konkretizēšanas, mēs ļāvām modelim paveikt darbu un domāt radoši:
Pēc desmit minūšu ilgas domu apmaiņas ieslēdzām plānošanas režīmu, lai precizētu prasības un sagatavotu izstrādes tehnisko daļu. Plānošanas režīms līdzinās atbildēšanai uz jautājumiem, ko uzdod kaitinošais draugs, kurš (par laimi) ir pārdomājis ikvienu iespējamo scenāriju. Kad bijām vienojušies par video skaitu, semantisko vai atslēgvārdu meklēšanu un izmantojamo arhitektūru, Codex izveidoja Markdown failu, kas kļuva par projekta turpmāko pamatu.
Kad plāns bija gatavs, nākamais solis bija izveidot pamatkomponentus, kas nodrošinātu Callombia darbību. Tas nozīmēja izveidot procesu, kas ierakstītos zvanus pārvērstu meklējamos resursos:
video un transkripciju ievade;
to sadalīšana jēgpilnos fragmentos;
to papildināšana ar kopsavilkumiem un tagiem;
to nodrošināšana, izmantojot API, kurus varētu lietot priekšgalsistēma.
Eds galvenokārt pārveidoja neapstrādātos ierakstus un transkripciju datus izmantojamā formātā, savukārt Niko pievērsās informācijas izguves slānim, kas ļautu atrast vajadzīgos fragmentus. Ar Codex palīdzību abi spēja daudz ātrāk, nekā tas būtu iespējams manuāli, sagatavot datu modeļus, izgūšanas skriptus un aizmugursistēmas infrastruktūru. Rezultāts bija daudz vairāk nekā tikai video pievienota transkripcija. Mēs ieguvām konkrētus fragmentus: sadaļu par Tesco, stratēģijas jaunāko informāciju, diskusiju par darbinieku pieņemšanu vai tās konkrētās 90 zvana sekundes, kuras kāds patiešām vēlas noskatīties.
Īpaši interesants izrādījās informācijas izguves slānis. Mēs vēlējāmies, lai lietotājs varētu ievadīt, piemēram, „financial performance“, „Tesco roadmap“ vai „conversation evals“ un nonākt pie visatbilstošākajiem fragmentiem pat tad, ja šādi vārdi sarunā nemaz nebija izskanējuši. Lai to panāktu, izveidojām fragmentus ar laika kodiem, kopsavilkumiem, transkripcijas tekstu un metadatiem. Vadoties pēc skaidras arhitektūras un plaši izmantojot Codex palīdzību, mēs apvienojām tēmu, kopsavilkumu un transkripciju vienā ievadē un ar OpenAI text-embedding-3-small modeli ģenerējām iegultojumus katram fragmentam. Šos iegultojumus glabājām datubāzē un izmantojām kosinusa līdzību, lai salīdzinātu lietotāja vaicājumu ar katru fragmentu. Tādējādi vienkāršas atslēgvārdu meklēšanas vietā ieguvām semantiskās izguves slāni.
Tas nodrošināja ļoti augstu precizitāti un hakatona demonstrācijā piešķīra produktam „maģisku“ iespaidu. Vienlaikus sapratām, ka, video skaitam turpinot augt, šī pieeja nebūs mērogojama bezgalīgi, jo katra vaicājuma salīdzināšana ar katru fragmentu galu galā kļūtu pārāk dārga. Loģisks nākamais solis būtu ieviest efektīvākas izguves stratēģijas, piemēram, Hierarchical Navigable Small World, lai samazinātu salīdzinājumu skaitu un, datu kopumam augot, saglabātu mazu latentumu. Kad šī funkcija sāka darboties, Callombia arvien mazāk atgādināja multivides bibliotēku un arvien vairāk — zināšanu sistēmu.
Kā jau ikvienā labā hakatonā, arī šī daļa bija vairākkārt jāuzlabo: sākotnējās fragmentu robežas bija pārāk aptuvenas, daži laika kodi bija jāprecizē, daži tagi bija pārāk plaši, un transkripciju un ierakstu faili ne vienmēr precīzi sakrita. Taču tieši šeit atklājās risinājuma vērtība. Codex ļāva ātri pilnveidot sistēmu, nevis iestrēgt sākotnējā iestatīšanā un atkārtotā pārstrādē. Noslēgumā mums bija aizmugursistēma, kas spēja nodrošināt klipus, fragmentus un patiesi noderīgu semantisko meklēšanu. Šajā brīdī Callombia sāka šķist īsts produkts, nevis tikai hakatona demonstrācija.
Kamēr Eds un Niko veidoja datu ievades un domāšanas slāni, es izstrādāju priekšgalsistēmu. Izmantojot mūsu pilna steka veidni, varēju ātri sagatavot vietnes pirmo versiju, neuzrakstot nevienu koda rindu. Kad biju lūdzis vietni atvērt lokāli savā pārlūkprogrammā, es sniedzu vienkāršas atsauksmes aizzīmju saraksta formā un pakāpeniski pilnveidoju dizainu līdz vēlamajam rezultātam.
Pēc aptuveni stundu ilgas domu apmaiņas biju ieguvis rezultātu, ar kuru biju visnotaļ apmierināts, turklāt man nebija nekādas pieredzes lietotāja saskarņu vai dizaina jomā. Lai gan galaprodukts noteikti nav nevainojams, tā ir gana laba pirmā versija, kas palīdz cilvēkiem izprast produktu.
Lai dienas beigās mums noteikti būtu gatavs rezultāts, darbu sadalījām savā starpā. Protams, pēc dažām daļēji patstāvīga darba stundām katram bija savs lokālais zars ar veselu virkni konfliktu.
Tā vietā, lai veltītu laiku, kura mums nebija, rūpīgai konfliktu izskatīšanai un novēršanai, mēs vienkārši ļāvām Codex brīvi darboties repozitorijos un pašam tos novērst. Pašlaik mēs to neieteiktu uzņēmuma līmeņa programmatūras izstrādē, taču vidē ar nelielu risku risinājuma efektivitāte bija pārsteidzoša un ietaupīja mums daudzas stundas.
Hakatona pēdējais posms bija Callombia demonstrācijas ierakstīšana žūrijai. Instinktīvi gribējām atvērt Loom un ierakstīt demonstrāciju, taču nolēmām, ka šis varētu būt īsts Codex pārbaudījums un uzdevums, kas nedaudz pārsniedz tā pašreizējās iespējas. Tāpēc… mēs uzrakstījām uzvedni, norādījām saiti uz Callombia vietni, OpenAI izstrādātāju platformā pievienojām savas balss ierakstu un lūdzām paveikt pārējo.
Pirmais mēģinājums bija ļoti iespaidīgs — Codex bija uzrakstījis demonstrācijas scenāriju, ierakstījis ekrānu, pievienojis manu aizkadra balsi un gandrīz pilnībā izpildījis uzdevumu. Vienīgais, ar ko uzreiz nebijām apmierināti, bija aizkadra balss sinhronizācija ar demonstrācijas ierakstu, tāpēc lūdzām: “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.”
Atbildot uz šo pieprasījumu, Codex sadalīja aizkadra balsi un ierakstu mazākās daļās un gandrīz nevainojami paveica uzdevumu tieši laikā — līdz plkst. 17.30, kad varējām svinēt ar alu un picu.
Mēs zinām, ka Callombia atrisina problēmu, ar kuru saskaras lielākā daļa uzņēmumu. Strauji augošā uzņēmumā ir grūti piedalīties katrā zvanā, taču tajos izskanējušās vērtīgās atziņas ir nenovērtējamas. Tagad mums tikai jāievieš risinājums ražošanas vidē.
Taču te slēpjas arī plašāka mācība par MI pamatotu darba pieeju un ieguvumiem, ko sniedz inženiertehnisko un produktu izstrādes zināšanu veltīšana kopīgu problēmu risināšanai. Izkāpjot no ierastā darba ritma, sadarbojoties starp komandām un darot to visu daļēji konkurējošā vidē, mēs nonācām pie vairākiem risinājumiem, kurus pēc nelieliem uzlabojumiem varētu ieviest ražošanas vidē. Regulāri rīkojoties šādi, varam panākt, lai mūsu iekšējie procesi būtu tikpat noslīpēti kā klientiem veidotie risinājumi.