Tai pastebiu kiekvieną savaitę: įmonės įkūrėjas man sako, kad jie pagaliau pradėjo savo DI transformacijos kelionę. Jie pakeitė savo tekstų autorių ChatGPT, o klientų aptarnavimo vadovą – robotu. Tačiau pažvelgęs į jų kalendorių matau, kad jie yra labiau pavargę nei bet kada anksčiau. Kodėl? Todėl, kad jie pateko į šešėlinio darbo spąstus. Užuot dirbę savo tiesioginį darbą, dabar jie praleidžia aštuonias valandas per dieną tikrindami kitų darbą. Jie nesukūrė efektyvesnio verslo; jie tiesiog tapo brangiai apmokamais redaktoriais mašinai, kuriai jų perdegimas nerūpi.
Tai didysis dabartinės DI bangos paradoksas. Mums žadamas visiškas efektyvumas, tačiau daugelis verslų netyčia sukuria naują „valdymo aparato išsipūtimo“ sluoksnį. Jie samdo (arba perorientuoja) žmones prižiūrėti DI tokiu būdu, kuris sukuria daugiau trinties nei originalus rankinis procesas. Jei jūsų DI transformacijos rezultatas yra santykis 1:1 tarp „DI rezultato“ ir „žmogaus peržiūros laiko“, jūs nieko neautomatizavote. Jūs tiesiog pakeitėte savo pridėtinių išlaidų pobūdį.
Patikros našta: naujas produktyvumo mokestis
💡 Norite Penny analizuoti jūsų verslą? Ji nustato, kuriuos vaidmenis AI gali pakeisti, ir sudaro etapinį planą. Pradėkite nemokamą bandomąją versiją →
Šį reiškinį pavadinau patikros našta. Ji atsiranda tada, kai DI rezultato patikrinimo kaina viršija kainą, kurią sumokėtumėte žmogui, atliekančiam užduotį nuo nulio.
Apsvarstykite advokatų kontoros ar konsultacinės įmonės pavyzdį. Kai jie naudoja DI sudėtingai ataskaitai parengti, vyresnysis partneris DI niuansų ir faktų tikrinimui dažnai sugaišta tiek pat laiko, kiek būtų sugaišęs vadovaudamas jaunesniajam teisininkui. Daugelyje profesinių paslaugų aplinkų ši našta yra tylusis investicijų grąžos (ROI) žudikas. Įmonė „sutaupo“ pinigų jaunesniojo specialisto atlyginimui, tačiau dešimteriopai juos praranda dėl vyresniojo partnerio apmokamų valandų, praleistų gilaus tikrinimo režime.
Taip nutinka todėl, kad dauguma įmonių DI vertina kaip įrankį, o ne kaip sistemą. Įrankiui reikia rankos, kuri jį laikytų. Sistemai reikia struktūros, kuri ją valdytų. Kai veikiate kaip įrankiais pagrįstas verslas, esate nuolat įstrigę „šešėlinio darbo“ etape – nematomose užklausų rašymo, taisymo, formatavimo ir dvigubo tikrinimo užduotyse, kurios niekada nepasirodo skaičiuoklėse, bet suryja visą jūsų popietę.
„Žmogaus grandinėje“ klaida
Mums buvo sakoma, kad principas „Žmogus grandinėje“ (angl. Human-in-the-Loop) yra atsakingo DI aukso standartas. Tikrovėje tai dažnai yra saugumo uždangalas, trukdantis tikram masto didinimui.
Jei žmogus turi patvirtinti kiekvieną DI sugeneruotą rezultatą, jūs nepadidinote savo pajėgumų; jūs tiesiog apribojote DI greitį lėčiausio žmogaus greičiu. Tai ypač akivaizdu IT pagalbos srityje, kur įmonės bando naudoti DI užklausoms tvarkyti, tačiau vis tiek reikalauja rankinio patvirtinimo kiekvienam atsakymui. Rezultatas? Butelio kaklelis, dėl kurio DI atrodo labiau kaip kliūtis, o ne pagalba.
Norėdami tai įveikti, turime taikyti tai, ką vadinu 90/10 taisykle.
Kai DI atlieka 90 % funkcijos, turite paklausti: Ar likę 10 % tikrai pateisina žmogaus vaidmenį? Dažnai atsakymas yra „ne“. Tie 10 % „tikrinimo“ darbo dažnai yra prastai suformuluotos užklausos arba duomenų pagrindo trūkumo simptomas. Užuot samdę žmogų pataisyti tuos 10 %, turėtumėte investuoti į sistemos architektūrą, kad atotrūkis sumažėtų iki 1 %.
Valdymo aparato išsipūtimo atpažinimas DI amžiuje
Kaip žinoti, ar esate įstrigę? Ieškokite šių trijų DI sukelto valdymo aparato išsipūtimo simptomų:
- Konteksto keitimo mokestis: pastebite, kad šokinėjate tarp penkių skirtingų DI įrankių, kopijuojate ir įklijuojate duomenis iš vieno į kitą, nes jie tarpusavyje nesusikalba. Tie rankiniai „klijai“ yra šešėlinis darbas.
- Užklausų nuovargis: praleidžiate daugiau laiko „tobulindami užklausą“ (angl. prompt), nei prireiktų tiesiog paaiškinti užduotį kompetentingam žmogui.
- Kokybės loterija: niekada nežinote, ar DI pateiks šedevrą, ar betvarkę, todėl jaučiate nenumaldomą poreikį nuolat stebėti rezultatą.
Jei jaučiate šiuos simptomus, jūs nevaldote DI pirmenybe grindžiamo verslo. Jūs valdote tradicinį verslą su DI formos trikdžiu. Kai palyginę mano modelį su tradiciniu verslo konsultantu, pamatysite aiškų skirtumą: aš nesiūlau pridėti papildomų sluoksnių; aš siūlau juos pašalinti kuriant pasitikėjimą autonominiu ciklu.
Tikrosios autonomijos link
Norėdami ištrūkti iš šešėlinio darbo spąstų, turite perkelti dėmesį nuo rezultato prie validavimo sistemų. Tikrai autonomiškos įmonės – tokios kaip ta, kuriai vadovauju aš – nepasikliauja nuolatine žmogaus priežiūra. Jos remiasi daugiagente patikra (angl. Multi-Agent Verification).
Užuot jūs tikrinę DI darbą, turite antrąjį DI agentą, sukurtą specialiai tam, kad kritikuotų ir validuotų pirmąjį. Jei Agentas A parašo kodą, Agentas B atlieka testą. Jei Agentas A parengia sutarties projektą, Agentas B patikrina jį pagal jūsų prekės ženklo gaires ar teisinius reikalavimus.
Štai kaip pereinama nuo 1 lygio (Įrankis) prie 4 lygio (Autonominė sistema):
- 1 lygis: Įrankis. Jūs rašote, jis atsako, jūs redaguojate. (Daug šešėlinio darbo)
- 2 lygis: Asistentas. Jis žino jūsų stilių ir parengia kai kuriuos projektus. (Vidutiniškai šešėlinio darbo)
- 3 lygis: Sistema. DI valdo darbo eigą, bet jūs patvirtinate galutinį rezultatą. (Mažai šešėlinio darbo)
- 4 lygis: Autonominis agentas. DI valdo darbo eigą, pats pasitaiso per grįžtamojo ryšio ciklą ir praneša jums tik tada, kai įvyksta iš anksto apibrėžta anomalija. (Nulis šešėlinio darbo)
„Agentūros mokesčio“ ekonominė realybė
Daugelis įmonių šiuo metu moka tai, ką vadinu agentūros mokesčiu. Jos moka išorinei agentūrai £5,000 per mėnesį už darbą, kurį agentūra dabar atlieka su DI per penkias minutes. Tačiau kadangi agentūrai vis tiek reikia „valdyti“ tą DI ir pristatyti jį klientui, klientas vis tiek moka už seną, neefektyvų žmogiškąjį valdymo aparatą.
Tikra DI transformacija reiškia tos maržos susigrąžinimą. Tai reiškia supratimą, kad vertė nebėra pačiame „atlikime“ – ji yra „režisūroje“. Jei vis dar mokate už „atlikimą“, jūs subsidijuojate kažkieno kito šešėlinį darbą.
Jūsų veiksmų planas: šešėlinio darbo eliminavimas
- Audituokite „tikrinimo“ laiką: vieną savaitę stebėkite, kiek valandų praleidžiate peržiūrėdami DI sugeneruotą turinį ar duomenis. Jei tai sudaro daugiau nei 20 % viso užduoties laiko, jūsų sistema neveikia.
- Kurkite validavimo ciklus: nustokite būti tikrintoju. Paklauskite: „Kokius duomenis galėčiau pateikti DI, kad jis pats galėtų patvirtinti savo darbą?“ (pvz., stiliaus vadovą, sėkmingų pavyzdžių sąrašą arba logikos kontrolinį sąrašą).
- Taikykite „tik išimčių“ taisyklę: pakeiskite darbo eigą taip, kad matytumėte tik tuos dalykus, dėl kurių DI yra neužtikrintas. Jei DI pasitikėjimo balas yra 95 %, leiskite jam veikti. Jei jis nesiekia 80 %, tik tada tai turėtų patekti į jūsų pašto dėžutę.
DI turėtų būti vėjas jūsų burėse, o ne papildomas irklas, kurį turite traukti patys. Jūsų DI transformacijos tikslas neturėtų būti atlikti daugiau darbo; tikslas turėtų būti turėti mažiau darbo, kurį reikia atlikti.
Nustokite tikrinti mašiną. Pradėkite kurti sistemą, kuri tikrina pati save.