Agentinės LLM sistemos versle: architektūra, kaštai ir kur jos lūžta

Kodėl žodis „agentas“ reiškia architektūrą, ne funkciją?

Pokalbių robotą galima pastatyti per dieną: modelis, langas, sistema paruošta. Agentinė sistema yra kitas inžinerijos lygmuo, ir skirtumą lemia trys sluoksniai, kurių robotas neturi:

• Įrankių sluoksnis. Agentas turi ką nors daryti — skaityti duomenų bazę, kurti įrašą CRM, siųsti dokumentą. Kiekvienas įrankis yra sutartis: ką agentas gali, ko negali ir ką privalo patikrinti prieš veikdamas. Čia gyvena ir saugumas: agento teisės yra įrankių teisės, ne modelio geri norai.
• Būsenos valdymas. Realios užduotys netelpa į vieną užklausą. Agentas turi žinoti, ką jau padarė, kas liko ir ką daryti nutrūkus ryšiui pusiaukelėje — kitaip antras paleidimas sukurs dvigubus įrašus.
• Patikros taškai. Kur agentas sustoja ir laukia žmogaus? Atsakymas „niekur“ yra projektavimo klaida. Gerose sistemose negrįžtami veiksmai — mokėjimas, siuntimas klientui, trynimas — visada eina per žmogų.

Kur agentinės sistemos lūžta praktikoje?

Iš mūsų diegimų patirties — keturios vietos, kuriose lūžta dažniausiai. Nė viena nėra „modelis per kvailas“:

• Pasitikėjimas išvestimi be patikros. Modelis kartais pateikia įtikinamą, bet neteisingą rezultatą. Sistemos be atskiro patikros žingsnio — ar skaičius sutampa su šaltiniu, ar įrašas tikrai sukurtas — anksčiau ar vėliau paskleidžia klaidą į procesus. Mūsų praktikoje patikros sluoksnis yra ne priedas, o pusė architektūros.
• Per platus pirmas žingsnis. „Automatizuokime klientų aptarnavimą“ žlunga; „rūšiuokime gaunamus laiškus į penkias kategorijas su žmogaus patvirtinimu“ veikia ir po mėnesio plečiasi pats. Agentai auga iš siaurų, išmatuojamų pergalių.
• Kaštų inžinerijos nebuvimas. LLM kaina valdoma trimis svertais: talpykla pasikartojančiam kontekstui, modelio dydžio parinkimas pagal užduoties sudėtingumą ir griežtos išvesties struktūros. Sistema be šių svertų už tą patį darbą moka daug kartų daugiau — ir tai paaiškėja tik gavus sąskaitą.
• Integracijos be standarto. Kiekvienam įrankiui rašoma atskira jungtis prie konkretaus tiekėjo API reiškia, kad tiekėjo keitimas — perrašymas. Standartizuotas įrankių sluoksnis (MCP) šią riziką pašalina: įrankiai aprašomi kartą, modeliai keičiami laisvai.

API ar lokalus modelis — kaip spręsti?

Šis klausimas praktikoje sprendžiamas pagal tris kriterijus. Kokybė: stipriausi modeliai lokaliai neprieinami, ir jei užduotis sudėtinga, skirtumas matosi rezultate. Duomenys: jei jie teisiškai ar sutartimis negali palikti Jūsų infrastruktūros, lokalus sluoksnis tampa ne pasirinkimu, o reikalavimu. Ekonomika: lokalus modelis apsimoka tik esant dideliam, nuspėjamam srautui — techninės įrangos ir priežiūros kaštai fiksuoti, todėl mažam srautui API visada pigesnis.

Dažniausias brandus atsakymas yra hibridas: jautrūs duomenys apdorojami lokaliai mažesniu modeliu, o sudėtingi sprendimai — nuasmeninti — keliauja į stiprų API modelį. Taip suderinami reikalavimai, kurie iš pirmo žvilgsnio nesuderinami.

Kaip atrodo sąžiningas diegimo kelias?

Per kelias savaites, ne per pusmetį — bet siaurai. Pasirenkamas vienas procesas su aiškiu teisingumo kriterijumi ir matuojamu laiko kaštu: dokumentų apdorojimas, užklausų rūšiavimas, ataskaitų ruošimas. Pastatoma pilna grandinė — įrankiai, patikros, žmogaus taškai — ir mėnesį matuojama: kiek laiko sutaupyta, kiek klaidų praleista, kiek kainavo.

Po mėnesio turite ne nuomonę apie AI, o savo skaičius. Iš jų sprendimas dėl plėtros ateina savaime — arba paaiškėja, kad Jūsų atvejui agentinė sistema per anksti, ir tai irgi vertingas atsakymas, kainavęs savaites, ne metus.