LendingTree multiagentė sistema: hipotekos klientui vieno chatboto nebeužtenka

multiagentė sistema šiandien nėra teorinis žaislas. Tai jau darbas, pinigai, duomenys ir kartais labai žemiškas klausimas: kas prisiims atsakomybę, kai DI pradės veikti už žmogų?

Multiagentė sistema LendingTree pavyzdyje parodo, kodėl vieno chatboto sudėtingam klientų procesui dažnai neužtenka. AWS rugpjūčio 5 d. aprašė hipotekos asistentą, kuriame atskiri agentai planuoja, vykdo ir saugo procesą.

Turiu prisipažinti, tokias naujienas skaitau ne kaip blizgančią vitriną. Skaitau kaip žmogus, kuris iš karto galvoja apie komandą pirmadienio rytą. Kas iš to bus naudinga? Kur bus painiava? Ir kur po mėnesio kas nors pasakys: „mes galvojom, kad čia automatiškai susitvarkys“.

KAS NUTIKO

LendingTree ir AWS akcentuoja atskyrimą tarp planavimo ir vykdymo, struktūrinį saugumą ir pakartotinai naudojamas galimybes, kad multiagentė architektūra galėtų plėstis per organizaciją.

Hipoteka nėra klausimas „koks oras rytoj“. Ten yra pajamos, rizika, dokumentai, pasiūlymai, teisė, klientų nerimas ir labai daug mažų sprendimų.

Čia svarbi detalė: kalbame ne apie dar vieną gražų demonstracinį video. Kalbame apie produktus, politiką, infrastruktūrą arba tyrimus, kurie keičia, kaip žmonės dirba su DI realiose organizacijose.

KODĖL TAI SVARBU

Kai procesas sudėtingas, vienas agentas greitai tampa per didelis. Jis turi ir klausti, ir skaičiuoti, ir tikrinti, ir saugoti ribas. Tada sunku suprasti, kur klaida.

DI jau išlipo iš „parašyk tekstą“ dėžutės. Jis naršo, jungiasi prie įrankių, analizuoja duomenis, planuoja veiksmus, kartais tvarko dokumentus ar padeda priimti sprendimą. Trumpai: jis artėja prie darbo proceso, ne tik prie pokalbio lango.

Ir čia smegenys mėgsta paslysti. Norisi sakyti: „ai, čia dar užsienyje“. Bet tas pats modelis ar funkcija rytoj atsiras kliento kompiuteryje, darbuotojo naršyklėje arba partnerio pasiūlyme.

KĄ TAI REIŠKIA VERSLUI

Verslui multiagentis požiūris naudingas ten, kur procesas turi skirtingas atsakomybes: klientų aptarnavimą, dokumentus, riziką, pasiūlymus, atitiktį.

• atskirti planavimo ir vykdymo agentus
• saugumą padaryti privaloma proceso dalimi
• kurti bendras pakartotinai naudojamas funkcijas
• testuoti ne pokalbį, o visą kelią iki rezultato

Paimkite vieną sudėtingą klientų procesą ir pažymėkite, kurios dalys yra pokalbis, kurios – duomenų tikrinimas, kurios – sprendimo taisyklės.

Man patinka paprastas testas: ar po šios naujienos tavo komanda turi vieną aiškesnį sprendimą? Jei ne, vadinasi dar tik skaitome. Skaityti galima. Tik nereikia apsimesti, kad tai jau strategija.

KUR GALI SKAUDĖTI

Rizika – per anksti statyti agentų orkestrą. Jei procesas neaiškus žmogui, keli agentai jo stebuklingai neišgelbės.

Dažniausia klaida labai ūkiška. Žmonės įsijungia įrankį, pabando, nustemba, pasidžiaugia ir tada palieka viską savieigai. Po kelių savaičių paaiškėja, kad vieni darbuotojai kelia jautrius failus, kiti matuoja naudą iš jausmo, o treti net nežino, kas leidžiama.

Ne tragedija. Bet tvarkos reikia.

KĄ PASIDARYTI ŠIĄ SAVAITĘ

Šią savaitę suskaidykite vieną klientų kelionę į atsakomybes. Tik tada spręskite, ar reikia vieno agento, ar kelių.

Šaltinis: AWS Machine Learning Blog.

DUK

Kas yra multiagentė sistema?

Tai kelių agentų sprendimas, kuriame skirtingi agentai turi skirtingas atsakomybes.

Kodėl LendingTree pasirinko tokį kelią?

Hipotekos procesas turi daug skirtingų užduočių, todėl planavimą, vykdymą ir saugumą verta atskirti.

Ar mažai įmonei reikia multiagentės sistemos?

Tik tada, kai procesas pakankamai sudėtingas. Paprastoms užduotims dažnai užtenka vieno gerai apriboto agento.

Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.