Kone kasdien girdime pažadus, kad dirbtinis intelektas (DI) netrukus pakeis visus įmonės procesus. Pardavėjai siūlo „DI paremtus“ įrankius kiekvienai problemai spręsti, o įmonių vadovai junta spaudimą juos kuo greičiau įdiegti. Tačiau mūsų praktika rodo priešingą tendenciją: sėkmingiausi automatizavimo projektai yra tie, kuriuose DI naudojama stebėtinai mažai.

Jei jūsų problemai dirbtinio intelekto nereikia — mes taip ir pasakysime. Ir štai kodėl.

Deterministinė tvarka prieš spėliojimą

Didžioji dalis verslo procesų yra deterministiniai. Tai reiškia, kad jie turi aiškias taisykles: jei įvyksta įvykis A, sistema turi atlikti veiksmą B.

Pavyzdžiui, jei klientas užpildo užsakymo formą svetainėje, duomenys turi nukeliauti į jūsų apskaitos programą ir CRM sistemą. Čia nereikia jokio intelekto. Reikia patikimo integracinio kodo, kuris be klaidų perneš informaciją iš vieno lauko į kitą.

Jei šioje vietoje pajungsite didįjį kalbos modelį (LLM) vien todėl, kad tai madinga, rizikuojate:

  • Nepatikimumu: DI modeliai yra tikimybiniai — jie spėja kitą žodį ar reikšmę. Net 99% tikslumas verslo apskaitoje reiškia, kad viena iš šimto sąskaitų bus išrašyta su klaida. Griežtai užkoduota sistema veikia su 100% tikslumu.
  • Greičiu: Griežtas kodas suveikia per kelias milisekundes. DI užklausos apdorojimas gali trukti nuo kelių sekundžių iki minutės.
  • Kaštais: Kodo vykdymas praktiškai nieko nekainuoja. DI užklausos reikalauja serverio resursų ir kainuoja už kiekvieną apdorotą žodį (žetoną).

Kur DI iš tiesų atlieka savo darbą?

Mes DI naudojame tik ten, kur procesas reikalauja žmogiškojo vertinimo ir duomenys yra visiškai nestruktūrizuoti. Tai vadiname „kognityviniu mazgu“ — vieta, kur įprastas kodas pasiduoda, nes taisyklių per daug arba jos per kintančios.

Štai keli realūs pavyzdžiai:

  1. Nestruktūrizuotų laiškų analizė: Kai klientas atsiunčia laisvos formos užklausą el. paštu, įprastas kodas negali suprasti, ar tai skundas, ar naujas užsakymas, ar prašymas pakeisti adresą. Čia DI gali sėkmingai perskaityti tekstą, suprasti intenciją ir perduoti švarią struktūrą sistemai.
  2. Sutarčių palyginimas: Kai reikia rasti, kuo pasirašoma sutartis skiriasi nuo jūsų standartinio šablono. DI gali atpažinti prasminius skirtumus, net jei sakinių formuluotės visiškai kitokios.
  3. Duomenų išrinkimas iš nuotraukų: Kai tiekėjų sąskaitos atkeliauja skirtingais formatais (kartais tiesiog kaip kreivos nuotraukos), DI gali rasti bendrą sumą ir PVM kodą, nes supranta dokumento kontekstą.

Mūsų taisyklė: hard-code’inkite procesą, soft-code’inkite intelektą

Kurdami sistemas B2B klientams, vadovaujamės griežta taisykle. Visą scaffolding’ą (sistemų sujungimą, duomenų saugojimą, validaciją, pranešimų siuntimą) mes programuojame tradiciniais metodais. DI pajungiame tik kaip siaurą, izoliuotą funkciją tame kelyje.

Tokia architektūra leidžia išlaikyti visišką sistemos kontrolę. Jei DI modelis suklys, sistema tai pastebės ir informuos darbuotoją, o ne tyliai įrašys klaidingus duomenis į jūrų registrą ar CRM.

Jeigu norite optimizuoti savo įmonės procesus, pradėkite ne nuo DI modelio paieškos, o nuo pačio proceso išgryninimo. Gali paaiškėti, kad jūsų problemą galima išspręsti paprastu integraciniu kodu — greičiau, pigiau ir patikimiau.