Skaitmeninių paslaugų platformos dirbtinio intelekto posistemės kūrimo ir diegimo paslaugos
Išanalizuota
Viešoji įstaiga CPO LT
139 999 €
Atviras konkursasCPV: 72000000 - IT paslaugos: konsultavimas, programinės įrangos kūrimas, internetas ir aptarnavimo paslaugos
ID: 68870112026-03-12 14:35
Atidaryti CVP ISAprašymas
Perkamos Skaitmeninių paslaugų platformos dirbtinio intelekto posistemės (SPP DIP) kūrimo, diegimo ir palaikymo paslaugos. Ši sistema kurs ir diegs DI pokalbių robotus, integruotus su bendrosios paskirties DI modeliais, siekiant efektyvinti Valstybės skaitmeninių sprendimų agentūros specialistų darbą ir automatizuoti konsultacijas paslaugų gavėjams bei teikiančioms institucijoms. Projektas finansuojamas iš Europos Sąjungos ekonomikos gaivinimo ir atsparumo didinimo plano lėšų.
Kvalifikaciniai reikalavimai
- 1Tiekėjas per paskutinius 5 (penkerius) metus iki pasiūlymo pateikimo termino pabaigos, arba per laiką nuo tiekėjo įregistravimo dienos (jeigu tiekėjas vykdė veiklą mažiau nei 5 (penkerius) metus), turi būti sukūręs arba modernizavęs bent vieną informacinę sistemą ar programinį sprendimą, kuriame buvo įdiegtas dirbtinio intelekto didelių kalbos modelių (angl. Large Language Models, LLM) pagrindu veikiantis funkcionalumas (pvz., pokalbių robotas, virtualus asistentas, tekstų apdorojimas), kurios vertė būtų ne mažesnė kaip 30 000,00 (trisdešimt tūkstančių) Eur be PVM. Sutartis kvalifikacijai pagrįsti yra tinkama tuo atveju, jeigu iki pasiūlymo pateikimo termino pabaigos informacinės sistemos ar programinio sprendinio diegimo darbai yra baigti, kurta ar modernizuota informacinė sistema/programinis sprendimas yra perduota (-s) gamybinei eksploatacijai.
- 2Projekto vadovas per paskutinius 5 (penkerius) metus dalyvavo įgyvendinant ne mažiau kaip 1 (vieną) sutartį, kurios apimtyje vadovavo informacinės sistemos ar programinio sprendimo, kuriame buvo įdiegtas dirbtinio intelekto didelių kalbos modelių (LLM) pagrindu veikiantis funkcionalumas (pvz., pokalbių robotas, virtualus asistentas, tekstų apdorojimas), kūrimo ir/ar vystymo projektui, ir turi tarptautiniu mastu pripažįstamą informacinių technologijų projektų valdymo kvalifikaciją (pvz., „Project Management Professional – PMP“, „CompTIA Project+“, PRINCE2 sertifikatą ar lygiavertį dokumentą).
- 3Informacinių sistemų programuotojas per paskutinius 5 (penkerius) metus dalyvavo įgyvendinant ne mažiau kaip 1 (vieną) sutartį, kurios apimtyje buvo sukurta ar modernizuota informacinė sistema/registras, kurios apimtyje buvo realizuojamos integracijos REST API standarto pagrindu.
- 4Dirbtinio intelekto specialistas per paskutinius 5 (penkerius) metus kaip dirbtinio intelekto specialistas dalyvavo įgyvendinant ne mažiau kaip 1 (vieną) sutartį, kurios rėmuose buvo kuriama ir/ar vystoma informacinė sistema ar programinis sprendimas, kuriame buvo įdiegtas dirbtinio intelekto didelių kalbos modelių (LLM) pagrindu veikiantis funkcionalumas (pvz., pokalbių robotas, virtualus asistentas, tekstų apdorojimas).
- 5Draudžiama pirkime dalyvauti tiekėjams, jų subtiekėjams ar ūkio subjektams, kurių pajėgumais remiamasi, kurie patys ar juos kontroliuojantys asmenys yra registruoti (jeigu tiekėjas, jo subtiekėjas, ūkio subjektas, kurio pajėgumais remiamasi, ar kontroliuojantis asmuo yra fizinis asmuo – nuolat gyvenantis ar turintis pilietybę) Rusijos Federacijos, Baltarusijos Respublikos, Kinijos Liaudies Respublikos (išskyrus Atskirąją Taivano, Penghu, Kinmeno ir Madzu muitų teritoriją), Rusijos Federacijos aneksuoto Krymo, Moldovos Respublikos Vyriausybės nekontroliuojamos Padniestrės teritorijos, Sakartvelo Vyriausybės nekontroliuojamos Abchazijos ir Pietų Osetijos teritorijos valstybėse ar teritorijose.
Techniniai reikalavimai
DI resursų reikalavimai
- 1Tiekėjas turi pasiūlyti standartinių bendrosios paskirties DI modelių resursus, vadinamus žetonais (tokens), kurie turi būti naudojami 11 (vienuolika) mėn. nuo SPP DIP sukūrimo ir diegimo priėmimo-perdavimo akto patvirtinimo.
- 2Standartinių DI modelių resursai turi būti suderinami ir tinkami naudojimui SPP DIP terpėje sukurtų pokalbių robotų bei jų žinių bazių naudojimo ir administravimo funkcionalume.
- 3Standartinių DI modelių resursai turi apimti prieigą prie ne mažiau kaip 3 (trijų) skirtingų ekosistemų (tiekėjų) DI modelių per saugius įmonių lygio (Enterprise) prieigos taškus (API), užtikrinančius duomenų rezidenciją ES.
- 4Tiekėjas privalo užtikrinti prieigą prie OpenAI šeimos (GPT-5 (Omni) ir GPT-5-mini klasės modeliai ar naujesni), Anthropic šeimos (Claude Sonnet 4 ir Claude Haiku 4.5 klasės modeliai ar naujesni) ir Google šeimos (Gemini 2.5 Pro ir Gemini 2.5 Flash klasės modeliai ar naujesni) modelių arba lygiaverčių savo parametrais bei našumu ir naujesnių jų versijų.
- 5Išvardinti standartiniai DI modeliai turi būti teikiami viešosios debesijos paslaugų pavidalu tik iš Europos Sąjungos ir NATO šalių debesijos centrų, bei Paslaugos neturi kelti grėsmės Nacionaliniam saugumui vadovaujantis LR viešųjų pirkimų įstatymo 37 str. 8 d. ir 9 d. nuostatomis.
- 6Standartinių bendrosios paskirties DI modelių atitiktis ES DI aktui turi būti užtikrinta jų tiekėjų atsakomybe. Standartinių bendrosios paskirties DI modelio neatitikimo ES DI aktui ar kitiems teisės aktams nustatymo atveju, SPP DIP Tiekėjas privalo užtikrinti standartinių DI modelių pakeitimą kitais lygiaverčiais to paties arba kito tiekėjo standartiniais DI modeliais, atitinkančiais ES DI aktą ir kitus teisės aktus, nekeičiant kainos ir suderinus pakeitimą su Užsakovu.
- 7Standartinių DI modelių resursai turi apimti šiuos DI modelių žetonų (tokens) limitus: Aukšto našumo modelių klasė (GPT-5, Claude Sonnet, Gemini Pro ar lygiaverčiai) - ne mažiau kaip 3 000 000 000 (trys milijardai) žetonų; Greitaveikos/Ekonominė modelių klasė (GPT-5-mini, Claude Haiku, Gemini Flash ar lygiaverčiai) - ne mažiau kaip 10 800 000 000 (dešimt milijardų aštuoni šimtai milijonų) žetonų.
- 8Aukščiau nurodytų DI resursų suvartojimo limitai (pavyzdžiui, savaitei, mėnesiui ir pan.) turi būti valdomi SPP DIP priemonėmis.
- 9DI resursams turi būti taikomas suminis įvesties (Input/Context) ir išvesties (Output/Generation) žetonų skaičiavimas. Tiekėjas turi teisę taikyti apribojimą, kad Išvesties (Output) žetonai sudarytų ne daugiau kaip 20% bendro limito (standartinis pramonės santykis 4:1).
- 10Naudotojui išnaudojus "Aukšto našumo" klasės limitą, turi būti užtikrinta galimybė tęsti darbą naudojant "Greitaveikos" klasės modelius.
- 11Standartinių DI modelių resursų kaina turi apimti visus standartinių DI modelių panaudojimo kaštus. Visi kaštai ir atsiskaitymai su šių standartinių DI modelių tiekėjais nurodytu laikotarpiu turi būti SPP DIP Tiekėjo atsakomybė.
- 12Neturi būti ribojama galimybė integruoti SPP DIP ir jos terpėje sukurtus pokalbių robotus su kitais DI modeliais, įskaitant nestandartinius, sukurtus ir įdiegtus VSSA valdomoje infrastruktūroje.
- 13Neturi būti ribojama galimybė integruoti SPP DIP ir jos terpėje sukurtus pokalbių robotus su išorinėmis žinių ir/ar duomenų bazėmis, kurios nėra nurodytos šiame dokumente.
- 14Neturi būti ribojama galimybė įsigyti papildomus išvardintų ir/ar alternatyvių standartinių DI modelių tiekėjų resursus.
Žinių bazių reikalavimai
- 1SPP DIP vidinės žinių bazių architektūra turi palaikyti statinius DOCX, XLSX, PDF ir TXT formatų dokumentus.
- 2SPP DIP vidinės žinių bazių architektūra turi palaikyti integracijas su Microsoft SQL Server, PostgreSQL, Oracle, MySQL duomenų bazėmis.
- 3SPP DIP vidinės žinių bazių architektūra turi palaikyti integracijas su Microsoft Office 365 SharePoint dokumentų saugyklomis.
- 4SPP DIP vidinės žinių bazių architektūra turi palaikyti integracijas su sąsajomis, realizuotomis MCP standartu.
- 5VSSA aktualių teisės aktų žinių bazės turinys (iki 100 dokumentų): Lietuvos Respublikos aktualūs teisės aktai, susiję su VSSA veikla (IT, viešieji pirkimai, duomenų apsauga, valstybės IS valdymas ir pan.), ES reglamentai ir direktyvos, aktualios skaitmeninėms paslaugoms, VSSA organizacinė struktūra, pareiginiai nuostatai, vidinės metodikos, gairių dokumentai, procesų aprašai, VSSA projektų planų, ataskaitų, viešųjų pirkimų dokumentų šablonai bei pavyzdiniai dokumentai.
- 6VSSA aktualių teisės aktų žinių bazė turi būti atnaujinama ir papildoma SPP DIP administratoriaus rankiniu būdu.
- 7Mažiausiai 2 suderintiems su VSSA teisės aktams, kurie įtraukti į VSSA aktualių teisės aktų žinių bazę ir kurie viešai prieinami LR teisės aktų registre (https://www.e-tar.lt/) ir ES teisės aktų registre EUR-Lex (https://eur-lex.europa.eu/), turi būti realizuotas ir pademonstruotas automatinio pakeitimų sekimo ir žinių bazės atnaujinimo funkcionalumas.
- 8VSSA aktualių teisės aktų žinių bazė turi semantiškai indeksuoti dokumentus DI modelių pagrindu, kad paieška ir atsakymai būtų kontekstiniai, o ne tik pagal raktinius žodžius.
- 9SPP bendrųjų žinių bazės turinys: SPK ir kitų SPP posistemių naudotojų instrukcijos (iki 10 dokumentų); Paslaugų aprašų duomenys iš Skaitmeninių paslaugų katalogo (SPK) duomenų bazės; Paslaugų modelių ir metaduomenų duomenys JSON formatu iš SPP CORE duomenų bazės, apibrėžiantys: paslaugos paskirtį ir apibrėžimą; paslaugos būseną ir versiją; paslaugą teikiančią instituciją ir atsakingus subjektus; paslaugos duomenų modelį; paslaugos vykdymo proceso žingsnius (workflow); paslaugos naudojamas integracijas; paslaugos naudojamus specializuotus programinius įskiepius.
- 10SPP bendrųjų žinių bazė turi būti atnaujinama ir papildoma SPP DIP administratoriaus rankiniu būdu.
- 11SPP bendrųjų žinių bazės pokalbių robotas turi būti integruotas su SPP posistemių duomenų bazėmis ir / arba integracinių sąsajų (API) sluoksniu, siekiant gauti dinaminę, realaus laiko informaciją apie Paslaugų aprašus iš SPK PostgreSQL duomenų bazės ir Paslaugų modelių ir metaduomenų aprašus iš SPP CORE PostgreSQL duomenų bazės.
DI modelių sąveikos reikalavimai
- 1SPP DIP integracija ir sąveika su DI modeliais turi būti realizuotos per unifikuotą „DI modelių vartų modulį“, užtikrinant vieningą pokalbių robotų sąveiką su įvairiais išoriniais DI modeliais ir galimybę naudoti “DI modelių vartų” integracines programines sąsajas, kaip integracinius vartus (API GW) integracijai su išorinėmis VSSA informacinėmis sistemomis.
- 2Prieiga prie „DI modelių vartų“ API GW privalo būti valdoma per virtualius API raktus (Virtual API Keys). SPP DIP administratorius turi turėti galimybę kurti, valdyti ir atšaukti šiuos raktus, priskirti jiems naudojimo limitus (rate limiting), biudžetus ir prieigos teises prie konkrečių modelių ar modelių grupių.
- 3Privalo turėti atsarginių modelių mechanizmą (fallbacks). Įvykus klaidai ar nepasiekus pagrindinio DI modelio, užklausa turi būti automatiškai išsiunčiama į iš anksto sukonfigūruotą atsarginį DI modelį.
- 4Turi būti realizuotas automatinis užklausų pakartojimo mechanizmas (retries) su konfigūruojamais nustatymais (pvz., bandymų skaičius, delsos laikas), siekiant padidinti sėkmingų užklausų skaičių.
- 5Architektūra privalo palaikyti užklausų apkrovos balansavimą (load balancing) tarp kelių identiškų modelių egzempliorių.
- 6Turi būti integruotas atidėtinas talpinimas (caching), leidžiantis saugoti ir pakartotinai naudoti atsakymus į identiškas užklausas. Turi būti galimybė konfigūruoti talpyklos galiojimo laiką (TTL).
- 7SPP DIP sąveika su „DI modelių vartais“ turi būti realizuota REST API standartu.
- 8Tiekėjas turi parengti ir pateikti „DI modelių vartų“ integracijos su standartiniais DI modeliais specifikaciją ir užtikrinti, kad naudotojų asmens duomenys nenaudojami DI modelių apmokymui.
- 9SPP DIP turi turėti galimybes realizuoti duomenų mainus su išorinėmis sistemomis REST API standartu.
Saugumo ir administravimo reikalavimai
- 1SPP DIP turi būti realizuota užtikrinant atsparumą OWASP Top 10: 2021 kibernetinio saugumo rizikoms.
- 2SPP DIP naudotojų autentifikavimo mechanizmas turi palaikyti integraciją su VSSA naudojama debesijos tapatybės ir prieigos valdymo platformą Microsoft Entra ID.
- 3SPP DIP naudotojų prieigos prie pokalbių robotų autorizavimas turi būti paremtas naudotojų grupėmis ir/ar rolėmis.
- 4SPP DIP turi automatiškai perduoti pokalbių robotui ir jo DI modeliui, kokiai naudotojų grupei priklauso naudotojas tam, kad adaptuoti pokalbio kontekstą pagal naudotojo grupės pavadinimą ir nustatymus, jeigu tai numatyta pokalbių roboto nustatymuose. Naudotojas gali nurodyti kitą analizės ir atsakymo pateikimo kontekstą, pvz., “analizuok, kaip produktų vadovas” arba “kaip pirkimų specialistas” ir pan..
- 5Naudotojo asmens duomenys tiesiogiai neturi būti naudojami DI modelių apmokymui, konteksto nustatymui.
- 6SPP DIP administratorius privalo turėti galimybę kurti detalias vartotojų roles, vartotojų grupes ir valdyti jų prieigos teises prie įvairių posistemės funkcijų (Role-Based Access Control, RBAC), pvz., DI modelių/pokalbių robotų prieiga, žinių bazių prieiga, failų įkėlimo teisė, žinučių redagavimo ir trynimo teisė, modelio atsakymo perkūrimo ar tęsimo teisė, modelio atsakymų vertinimo teisė, pokalbio nurodymų keitimo teisė, kelių modelių naudojimo teisė, paieškos internete ir paveikslėlių generavimo funkcijos naudojimo teisė.
- 7SPP DIP administratorius turi turėti galimybę sujungti naudotojus į logines roles ir/arba grupes (pvz., „Produktų skyrius“, „Skaitmeninių iniciatyvų skyrius“), kurioms galima centralizuotai priskirti roles. Naudotojas gali priklausyti vienai ar kelioms grupėms.
- 8SPP DIP administratorius turi turėti galimybę kurti, blokuoti, šalinti pavienius naudotojus, priskirti juos į grupes, suteikti jiems roles tiek individualiai, tiek per grupę.
- 9SPP DIP administratorius turi turėti galimybę įkelti naujų naudotojų sąrašą iš CSV ar lygiaverčio formato failo.
- 10SPP DIP turi turėti naudotojų aktyvumo ir veiksmų stebėsenos priemones ir ataskaitas tiek visiems naudotojams bendrai, tiek pasirinkus konkretų naudotoją, nurodant stebėjimo laikotarpį (diena, savaitė, mėnuo, 3 mėnesiai) apimant naudotojų prisijungimus, DI modelių panaudojimą, pokalbių robotų panaudojimą.
- 11Turi būti galimybė naudotojų stebėsenos žurnalus ir metrikas į VSSA naudojama žurnalų konsolidavimo sistemą Graylog SIEM naudojant JSON formatą arba kitu Graylog SIEM palaikomu formatu.
- 12Turi būti galimybė sekti ir registruoti kiekvienos užklausos į DI modelį kaštus, remdamasi modelio tiekėjo kainodara.
- 13Turi būti galimybė nustatyti DI resursų – žetonų (tokens) limitus DI modeliams arba naudotojams (pvz., maksimalus kiekis per dieną, savaitę, mėnesį). Viršijus limitą, tolimesnės užklausos privalo būti blokuojamos.
- 14SPP DIP neturi riboti galimybių kurti papildomus pokalbių robotus ir jiems atitinkančias naudotojų roles.
- 15SPP DIP privalo turėti integruotą DI pokalbių robotų kūrimo aplinką (built-in code editor), leidžiančią kurti, modifikuoti ir vykdyti pasirinktinius pokalbių robotus, tiesiogiai per naudotojo sąsają, be poreikio naudoti išorines programavimo aplinkas.
Bendrieji SPP DIP sistemos reikalavimai
- 1SPP DIP turi būti bendrosios paskirties dirbtinio intelekto sistema (GPAI) programinė įranga, leidžianti kurti savo terpėje specializuotus pokalbių robotus, integruotus su bendrosios paskirties dirbtinio intelekto modeliais.
- 2Tiekėjo siūloma SPP DIP realizacija turi atitikti galiojančius Europos Sąjungos ir Lietuvos Respublikos teisės aktus, įskaitant ES DI aktą, BDAR, NIS2, ES autorių teisių teisės aktus, LR viešųjų pirkimų įstatymą, LR asmens duomenų teisinės apsaugos įstatymą, LR valstybės informacinių išteklių valdymo įstatymą, LR kibernetinio saugumo įstatymą ir Ekonomikos ir Inovacijų ministerijos ES Dirbtinio intelekto akto įgyvendinimo gaires.
- 3Paslaugos turi būti teikiamos vadovaujantis Lietuvos Respublikos gaminių ir paslaugų prieinamumo reikalavimų įstatymu.
- 4SPP DIP naudotojo sąsajoje turi būti informuojama, kad pokalbiuose pateikiamas DI sugeneruotas turinys.
- 5SPP DIP turi būti tinkama diegti tiek VSSA valstybinio duomenų centro, tiek VSSA valdomoje Microsoft Azure debesijos infrastruktūroje.
- 6SPP DIP nustatymai turi būti saugomi duomenų bazėje, užtikrinant nustatymų pastovumą ir galimybę diegti kelis posistemės serverius su apkrovos balansavimu.
- 7SPP DIP technologijos, diegimo priemonės ir infrastruktūros reikalavimai neturi riboti SPP DIP galimybių integruotis į SPP posistemių duomenų bazes, įdiegtas VSSA valstybinio duomenų centro infrastruktūroje.
- 8SPP DIP programinės įrangos architektūra turi užtikrinti 99% per mėnesį prieinamumą.
- 9SPP DIP turi būti keičiamo dydžio (scalable), kad galėtų efektyviai aptarnauti didelį ir nuolat augantį naudotojų skaičių.
- 10Pasibaigus Sutarties galiojimui visi Sutarties metu sukurti artefaktai (išeities kodas, bibliotekos, projektavimo dokumentai, architektūros schemos ir pan.), išskyrus standartinius DI modelius ir jų tiekėjų paslaugas, turi būti perleisti VSSA, užtikrinant galimybę naudotis ir modifikuoti technologinius artefaktus tiek savarankiškai, tiek pasitelkiant trečiąsias šalis.
- 11SPP DIP realizacijos technologijos (programavimo kalbos, atviro kodo komponentai, trečiųjų šalių komponentai, duomenų bazės) ir jų licencijavimas neturi apriboti VSSA galimybių naudotis ir modifikuoti SPP DIP tiek savarankiškai, tiek pasitelkiant trečiąsias šalis.
- 12Visos programinės įrangos licencijos turi būti įtrauktos į Tiekėjo pasiūlymo kainą ir neturi reikalauti papildomų licencijų įsigijimo Sutarties galiojimo laikotarpiu arba pasibaigus Sutarties galiojimui.
Pokalbių robotų bendrieji reikalavimai
- 1Turi gebėti apdoroti ir suprasti naudotojo užklausas, pateiktas natūraliąja kalba.
- 2Turi palaikyti pokalbius bent lietuvių ir anglų kalbomis su galimybe sąsają pritaikyti papildomoms kalboms.
- 3Privalo išlaikyti pokalbio kontekstą per kelias užklausas, leidžiant naudotojui tęsti mintį be visiško jos pakartojimo. Privalo palaikyti asinchroninius pokalbius, leidžiančius naudotojui dirbti su keliais pokalbiais vienu metu, neprarandant konteksto.
- 4Pokalbiai privalo būti saugomi istorijoje. Laikini pokalbiai, kurie nėra saugomi istorijoje, neturi būti naudojami. Pokalbių robotų naudotojai neturi turėti galimybės trinti pokalbius, kad neliktų istorijos.
- 5Privalo palaikyti tekstinius pokalbių "kanalus" arba "kambarius", kuriuose skirtingi naudotojai ir skirtingi DI modeliai ir agentai gali bendrauti viename pokalbyje realiu laiku, išlaikant bendrą kontekstą.
- 6Pokalbių robotų naudotojo sąsaja turi leisti naudotojui pasirinkti DI modelį iš įdiegtų ir/ar integruotų su SPP DIP.
- 7Turi būti galimybė naudoti kelis skirtingus kalbos modelius vieno pokalbio metu, persijungiant tarp jų ir naudojant juos lygiagrečiai.
- 8Turi teikti faktiškai teisingus ir kontekstą atitinkančius atsakymus į klausimus, naudodamas prieigą prie nustatytų žinių bazių, roboto naudotojo pateiktus dokumentus, o taip pat prie išorinių informacijos šaltinių, prieinamų per standartinius DI modelius.
- 9Pokalbiams turi būti sugeneruojamas ir priskiriamas trumpas, aiškus pavadinimas naudojant DI modelius pavadinimui sugeneruoti pagal pokalbio turinį.
- 10Kuomet pokalbių roboto nustatymuose yra nurodyta konkreti žinių bazė, pokalbių roboto atsakymai turi būti pagrįsti žinių bazės dokumentais ir šaltiniais, pateikiant nuorodas į konkrečius teisės aktų straipsnius ar dokumento vietas, atsakymuose turi būti aiškiai nurodyta, jei informacija nėra rasta arba naudojamas viešasis bendrinis šaltinis.
- 11Pokalbių robotas turi asistuoti rengiant, analizuojant, lyginant dokumentus, susijusius su žinių bazėmis, natūralios kalbos pagrindu.
- 12Pokalbių robotai turi informuoti naudotoją apie DI ribotumus ir atsakymų informacijos šaltinius.
- 13Tuo atveju, jeigu DI pateikia neteisingą ar klaidinančią informaciją, naudotojas turi turėti galimybę pažymėti blogą atsakymą, pateikto atsakymo vertinimą ir pagrindimą. Naudotojo grįžtamasis ryšis į blogą atsakymą turi būti registruojamas ir prieinamas SPP DIP administratoriui tam, kad būtų galima tobulinti pokalbių roboto ir/ar jo naudojamų DI modelių nustatymus.
- 14Analizuojant DI atsakymus ir nustačius ES DI akto ar kitų teisės aktų pažeidimą, naudotojas turi turėti galimybę betarpiškai užregistruoti DI incidentą SPP DIP pokalbių roboto naudotojo sąsajos priemonėmis.
- 15Turi būti galima žymėti pokalbius etiketėmis (tags) ir vėliau pagal jas filtruoti bei vykdyti paiešką.
- 16Turi būti galimybė vykdyti paiešką praeities pokalbių pavadinimuose, turinyje ir pagal suteiktas etiketes.
- 17Turi būti galimybė archyvuoti nebeaktualius pokalbius.
- 18Turi būti galimybė eksportuoti ir/ar kopijuoti pokalbius atvirų formato dokumentų pavidalu, pvz. TXT, DOCX, PDF.
- 19Turi gebėti priimti, analizuoti ir apibendrinti vartotojo pateiktų dokumentų (pvz., PDF, DOCX, XLSX, TXT) turinį.
- 20Privalo turėti RAG funkcionalumą, leidžiantį įkelti dokumentus ir juo praturtinti pokalbių roboto žinių bazę ir pokalbio kontekstą, naudoti jų turinį pokalbiuose. RAG funkcionalumas privalo palaikyti PDF, DOCX, XLSX, TXT dokumentų formatus.
- 21Turi būti integruota paieškos internete galimybė, kuri paieškos rezultatus perduoda RAG procesui.
- 22Turi būti integruota galimybė naudoti konkretaus (nurodant URL nuorodą) interneto puslapio turinį, kuris perduodamas RAG procesui.
- 23RAG vektorinio indeksavimo realizacija turi būti paremta VSSA turimu DI modeliu, įdiegtu VSSA infrastruktūroje.
- 24Remiantis pokalbio kontekstu ir vartotojo nurodymais, roboto funkcionalumas turi leisti generuoti naujus dokumentus (pvz., el. laiškus, ataskaitų juodraščius) ir pateikti juos vartotojui. Robotas privalo turėti formatavimo palaikymą praturtintam (pvz., "Markdown" standartu) turiniui generuoti ir atvaizduoti pokalbių lange.
- 25Taip pat turi palaikyti vaizdų ir paveikslėlių įkėlimą ir apdorojimą pokalbių lange, jei naudojami multi-modaliniai (t. y. tiek vaizdus, tiek tekstą apdorojantys) DI modeliai.
- 2695% pokalbių robotų atsakymų pateikimas turi prasidėti ne ilgiau nei per 3 sekundes nuo vartotojo užklausos gavimo.
- 27Visi naudotojo duomenys ir pokalbiai turi būti perduodami šifruotu ryšiu (TLS/SSL) ir saugomi pagal taikomus duomenų apsaugos standartus, įskaitant Bendrąjį duomenų apsaugos reglamentą (BDAR).
- 28Pokalbių roboto architektūra ir realizacija turi leisti naudotis pokalbių robotu tiek SPP DIP naudotojo sąsajos terpėje, tiek realizuojant įskiepius į kitų Web portalų naudotojo sąsają, neprarandant pokalbio funkcionalumo.
- 29Pokalbių robotas turi užtikrinti pritaikomą naudotojo sąsajos dizainą (responsive design), leidžiantis patogiai naudotis Platforma tiek stacionariuose ir nešiojamuosiuose kompiuteriuose, tiek mobiliuosiuose įrenginiuose.
Paslaugų teikimo ir palaikymo reikalavimai
- 1Ne vėliau nei po 10 (dešimties) darbo dienų po Sutarties pasirašymo turi būti sudarytas Projekto reglamentas, kuris turi būti reguliariai atnaujinamas Šalių susitarimu Sutarties vykdymo eigoje ir turi apimti: Projektinę organizaciją, Komunikacijos valdymo priemones, Įgyvendinimo užduočių, pakeitimų, palaikymo paklausimų registravimo, valdymo ir kontrolės priemones, Pakeitimų valdymo žurnalą, Diegimo aplinkas ir techninių artefaktų teikimo priemones, Projekto rizikų žurnalą ir jo rėmuose atskirą skiltį DI rizikoms, DI rizikos ir atitikties ES DI aktui ir kitiems teisės aktams reguliaraus vertinimo procedūrą.
- 2Tiekėjas atsakinga pradėti SPP DIP vystymą po Sutarties pasirašymo savo infrastruktūroje, kol nebus suteikta Šalių suderinta Užsakovo diegimo aplinkos infrastruktūra.
- 3Užsakovas atsakingas pateikti diegimo aplinkos infrastruktūrą ir suteikti būtiną prieigą Tiekėjui ne vėliau nei per 1 (vieną) mėnesį nuo Sutarties pasirašymo.
- 4VSSA atsakinga pateikti visą reikalingą dokumentaciją, duomenų šaltinius, metaduomenų rinkinius ir prieigos teises, būtinus pokalbių robotų žinių bazių kūrimui ne ilgiau nei per 5 (penkias) d. d. nuo paklausimo.
- 5Tiekėjas atsakingas transformuoti pateiktą medžiagą į pokalbių robotų žinių bazėms tinkamus formatus, sukurti, importuoti ir sukonfigūruoti žinių bazes, integruoti duomenų šaltinius, užtikrinti jų nuoseklų atnaujinimą ir sinchronizavimą.
- 6Tarpinių ir galutinės versijų, SPP DIP naujinimų, įskaitant žinių bazių naujinimų diegimus Užsakovo valdomoje infrastruktūroje Tiekėjas gali atlikti tik suderinus su Užsakovu.
- 7Tarpinių SPP DIP ir pokalbių robotų versijų testavimas turi būti vykdomas Šalių susitarimu Tiekėjo ir/ar Užsakovo infrastruktūroje.
- 8Bendra paslaugų teikimo Sutarties trukmė – 12 (dvylika) mėnesių.
- 9Standartinių bendrosios paskirties DI modelių resursai turi būti teikiami nuo Sutarties įsigaliojimo visą Sutarties galiojimo laikotarpį arba iki Techninėje specifikacijoje nurodytų DI resursų visiško sunaudojimo. Standartinių bendrosios paskirties DI modelių resursai turi būti pateikti per 5 darbo dienas nuo Sutarties įsigaliojimo dienos, pagal Tiekėjo pateiktą priėmimo-perdavimo aktą ir sąskaitą faktūrą, remiantis Tiekėjo pasiūlyme nurodytų pirkimo objekto elementų kainomis.
- 10SPP DIP Palaikymo paslaugos turi būti teikiamos nuo Sutarties pasirašymo visą Sutarties galiojimo laikotarpį.
- 11Kūrimo ir diegimo paslaugos turi būti suteiktos ir patvirtintos Užsakovo ne vėliau nei 2026 gegužės 20 d., įskaitant SPP DIP sukūrimą ir įdiegimą Užsakovo valdomoje infrastruktūroje, techninėje specifikacijoje aprašytų pokalbių robotų ir jų žinių bazių sukūrimą ir įdiegimą bei SPP DIP administravimo ir žinių bazių naujinimo instrukcijų parengimą.
- 12Palaikymas teikiamas pagal Užsakovo paklausimus, teikiamus elektroniniu būdu, skirstomus į kategorijas: Klaida, DI incidentas, IT incidentas, Konsultacija, Pakeitimas.
- 13Klaidoms, DI incidentams, IT incidentams turi būti suteikiamas prioritetas pagal įtaką posistemei: Kritinis (neprieinama, saugumo pažeidimai, ES DI akto neatitiktys), Aukštas (prieinama, bet neveikia esminis funkcionalumas), Vidutinis (kiti defektai).
- 14Tiekėjas turi užtikrinti reakcijos ir sprendimo laikus pagal Klaidų, DI incidentų ir IT incidentų prioritetus: Kritinis - reakcija per 4 darbo valandas (d.v.), sprendimas per 2 darbo dienas (d.d.); Aukštas - reakcija per 1 d.d., sprendimas per 5 d.d.; Vidutinis - reakcija per 5 d.d., sprendimas per 15 d.d..
- 15Numatoma, kad palaikymo paslaugos preliminariai apims 480 (keturis šimtus aštuoniasdešimt) Tiekėjo specialistų darbo valandų Pakeitimams, Konsultacijoms ir IT incidentams, kilusiems ne dėl Tiekėjo kaltės. Šios paslaugos teikiamos visą sutarties laikotarpį. Gavus šių kategorijų paklausimus, prieš vykdant darbus Tiekėjas turi įvertinti ir pateikti darbo valandų sąmatos bei įvykdymo termino pasiūlymą Užsakovui.
Specifiniai išorinių naudotojų pokalbių robotų reikalavimai
- 1SPP išorinių naudotojų pokalbių robotai neturi naudoti galutinio naudotojo asmens duomenų, paslaugų užsakymų, sprendimų dėl paslaugų teikimo ir kitų operacinių SPP duomenų pokalbio konteksto nustatymui, DI modelių apmokymui ar tų duomenų saugojimui SPP DIP terpėje.
- 2Pokalbių robotų žinių bazės: VSSA aktualių teisės aktų žinių bazė; SPP bendrųjų žinių bazė.
- 3Pokalbių robotai turi grįsti savo atsakymus visu pirma nurodytų žinių bazių turinio pagrindu ir kreiptis į bendrinius žinių šaltinius tik tuo atveju, kai žinių bazėje atsakymo nėra.
- 4Pokalbių robotai turi kontroliuoti, kad pokalbis liktų SPP naudojimo ir valstybės elektroninių paslaugų kontekste. Bet kokie pokalbio nukrypimai kita tema turi būti užkardomi, įskaitant necenzūrinę leksiką, keiksmažodžius, įžeidimus, smurto, seksualinio, religinio ar politinio pobūdžio turinį, išskyrus tiesiogiai susijusį su valstybės paslauga arba teisės aktais.
- 5Pokalbių robotai neturi priimti ir apdoroti naudotojo persiunčiamų failų.
- 6Pokalbių robotai neturi generuoti failų, įskaitant paveiksliukus, vaizdinę ir garsinę informaciją.
- 7Tiekėjas turi sukurti integracines priemones ir parengt integracijos pavyzdžius pokalbių roboto naudotojo sąsajos įskiepio realizavimui SPK portale ir SPK mobiliose programėlėse. Pokalbių robotas turi gebėti asistuoti tokiems scenarijams: atsakyti į klausimus dėl SPK naudojimo; atsakyti į klausimus apie katalogo paslaugas, aprašus ir duomenis, reikalingus užsakymui, kokios paslaugų būsenos ir teikimo eiga; patarti, kokios paslaugos tinkamos aprašyto gyvenimo scenarijaus atveju; informuoti, kokius reikalavimus turi atitikti paslaugos gavėjas, kad užsakytų vieną ar kitą paslaugą; atsakyti į klausimus apie institucijas, kurioms perduodami paslaugų užsakymai ir kiti naudotojo duomenis; atsakyti į klausimus apie paslaugų teikimą reglamentuojančius teisės aktus.
- 8Tiekėjas turi sukurti integracines priemones ir parengt integracijos pavyzdžius pokalbių roboto naudotojo sąsajos įskiepio realizavimui SPP Institucijos Web portale. Pokalbių robotas turi gebėti asistuoti tokiems scenarijams: atsakyti į klausimus dėl „SPP Institucijų Web portalo“ panaudojimo; atsakyti į klausimus apie katalogo paslaugas, aprašus ir duomenis, reikalingus užsakymui, kokie tų paslaugų modeliai; padėti rasti kitų institucijų teikiamas el. paslaugas, labiausiai atitinkančias naudotojo aprašomą situaciją, konsultuoti apie tokių paslaugų aprašų ir modelių turinio panaudojimo ir adaptavimo naujai paslaugai kurti galimybes; atsakyti į klausimus dėl galimybės adaptuoti kitos institucijos el. paslaugų aprašus ir modelius naudotojo institucijai; atsakyti į klausimus apie paslaugų teikimą reglamentuojančius teisės aktus; atsakyti į klausimus apie teisės aktus, reglamentuojančius konkrečios institucijos paslaugų skaitmenizavimą ir teikimą per SPP.
Dokumentai19
tendis.lt · Sukurta recodin.lt