Lietuvos rinkoje pastaruoju metu atsirado dešimtys agentūrų, siūlančių „individualius dirbtinio intelekto sprendimus“. Dažniausiai jų pasiūlymai skamba panašiai: pokalbių robotai svetainėms, automatinis dokumentų apdorojimas, išmanieji asistentai. Tačiau po šiais skambiais pavadinimais dažnai slepiasi itin paprasta technologija — vadinamieji „ChatGPT wrapperiai“ (apvalkalai).

Verslui tai yra rizika. Apvalkalas, sukurtas per kelias valandas, gali gražiai atrodyti per prezentaciją, tačiau greitai sulūžta susidūręs su realiais kasdienio darbo duomenimis.

Štai kaip atskirti paviršutinišką apvalkalą nuo profesionaliai suprojektuotos sistemos.

Kas yra „ChatGPT wrapperis“?

Paprastai tariant, tai yra tiesioginis kanalas į „OpenAI“ ar kitą DI modelį, paslėptas po jūsų įmonės logotipu. Toks įrankis paima vartotojo įvestą tekstą, nusiunčia jį į standartinę DI sąsają (API) ir parodo gautą atsakymą ekrane.

Kūrėjas tokiu atveju neatlieka jokio inžinerinio darbo. Jis nesuvaldo modelio elgsenos, neužtikrina duomenų saugumo ir neturi galimybės garantuoti rezultato stabilumo.

Tikros DI sistemos požymiai

Mūsų požiūriu, patikimas verslo įrankis privalo turėti kelis architektūrinius sluoksnius, kurie apsaugo įmonę nuo DI nenuspėjamumo.

Štai keturi esminiai elementai, kuriuos mes įdiegiame kiekviename projekte:

1. Griežtas įvesties ir išvesties validavimas

DI modeliams negalima leisti tiesiogiai rašyti į jūsų duomenų bazę ar siųsti el. laiškų klientams. Prieš perduodant duomenis toliau, sistema privalo atlikti automatinius čekius. Pavyzdžiui, jei DI išrašė sąskaitą iš el. laiško, mūsų programinė įranga patikrina, ar PVM kodas yra realus, ar suma sutampa su kainoraščiu ir ar visi privalomi laukai užpildyti. Tik praėjus šią programinę validaciją, duomenys keliauja į CRM ar apskaitą.

2. Rezultato struktūrizavimas (Structured Outputs)

Mėgėjiški sprendimai paprastai prašo DI grąžinti atsakymą laisvu tekstu, kurį vėliau sunku apdoroti. Mes naudojame griežtas schemas (pavyzdžiui, JSON schemas), kurios priverčia DI modelį grąžinti duomenis tiksliai nurodytu formatu. Tai reiškia, kad klientas, užsakymo suma ir prekių sąrašas visada bus atskirti į atskirus laukus, kuriuos supranta įmonės sistemos.

3. Atsarginių scenarijų valdymas (Fail-safe)

Ką daryti, jei „OpenAI“ serveriai laikinai neveikia? O jei modelis grąžino nesąmoningą atsakymą? Apvalkalas tiesiog parodys klaidą vartotojui. Tikras sprendimas turi paruoštus kelius:

  • Retries: automatiškai bando užklausą siųsti dar kartą.
  • Fallbacks: jei pagrindinis modelis neveikia, sistema perjungia užklausą į kito tiekėjo modelį (pvz., iš OpenAI į Anthropic Gemini).
  • Žmogaus peržiūra: jei DI nepasitiki savo atsakymu (gautas žemas patikimumo balas), užklausa nukreipiama darbuotojo peržiūrai, o ne siunčiama klientui.

4. Duomenų privatumas ir kontrolė

Naudojant paprastus įrankius, jūsų įmonės duomenys gali būti panaudoti DI modelių apmokymui. Mes užtikriname, kad visi duomenų srautai vyktų per saugius įmonių API kanalus (Enterprise API), kuriuose galioja griežtos privatumo taisyklės, o informacija niekada nenaudojama modelių treniravimui.

Kaip patikrinti kūrėją?

Jeigu renkatės rangovą DI projektui, užduokite jam tris paprastus klausimus:

  1. „Kaip jūsų sistema užtikrina, kad DI nepradės meluoti ar kurti faktų (haliucinuoti)?“
  2. „Kas nutiks, jei DI modelio API kurį laiką bus nepasiekiama?“
  3. „Ar galite garantuoti, kad DI grąžinti duomenys visada bus tinkamo formato įrašymui į mūsų CRM?“

Jei atsakymai apsiriboja pažadais apie „gerai parašytą instrukciją (promptą)“, prieš jus yra paprastas apvalkalas. Tikroji vertė sukuriama ne rašant tekstines užklausas DI modeliui, o statant patikimą programinę architektūrą aplink jį.