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: 65864152026-02-19 16:02
Atidaryti CVP ISAprašymas
Perkamos Skaitmeninių paslaugų platformos Dirbtinio intelekto posistemės (SPP DIP) kūrimo, diegimo ir palaikymo paslaugos. Šis pirkimas apima SPP DIP, išorinių naudotojų pokalbių robotų, SPP administravimo ir plėtros pokalbių roboto kūrimą bei diegimą, taip pat standartinių bendrosios paskirties DI modelių resursų tiekimą. Pirkimo tikslas yra efektyvinti valstybės e-paslaugų teikimą ir konsultavimą, panaudojant dirbtinį intelektą.
Kvalifikaciniai reikalavimai
Kvalifikacinių reikalavimų nerasta
Techniniai reikalavimai
DI resursų valdymas
- 1Standartiniai bendrosios paskirties DI modelių resursai turi apimti prieigą prie ne mažiau kaip 3 skirtingų ekosistemų (tiekėjų) DI modelių per saugius įmonių lygio prieigos taškus.
- 2Privaloma užtikrinti prieigą prie šių (arba lygiaverčių) ir naujesnių jų versijų: OpenAI šeima (GPT-5 (Omni) ir GPT-5-mini), Anthropic šeima (Claude Sonnet 4 ir Claude Haiku 4.5), Google šeima (Gemini 2.5 Pro ir Gemini 2.5 Flash).
- 3Aukšto našumo modelių klasė (pvz., GPT-5, Claude Sonnet, Gemini Pro ar lygiaverčiai) turi turėti ne mažiau kaip 3 000 000 000 žetonų.
- 4Greitaveikos/Ekonominė modelių klasė (pvz., GPT-5-mini, Claude Haiku, Gemini Flash ar lygiaverčiai) turi turėti ne mažiau kaip 10 800 000 000 žetonų.
- 5DI resursų suvartojimo limitai (pvz., savaitei, mėnesiui) turi būti valdomi SPP DIP priemonėmis.
- 6DI resursams turi būti taikomas suminis įvesties ir išvesties žetonų skaičiavimas.
- 7Išvesties žetonai turi sudaryti ne daugiau kaip 20% bendro limito.
- 8Naudotojui išnaudojus 'Aukšto našumo' klasės limitą, turi būti užtikrinta galimybė tęsti darbą naudojant 'Greitaveikos' klasės modelius.
- 9Neturi būti ribojama galimybė įsigyti papildomus išvardintų ir/ar alternatyvių standartinių DI modelių tiekėjų resursus.
- 10Turi būti galimybė sekti ir registruoti kiekvienos užklausos į DI modelį kaštus, remiantis modelio tiekėjo kainodara.
- 11Turi būti galimybė nustatyti DI resursų (žetonų) limitus DI modeliams arba naudotojams.
Žinių bazių valdymas
- 1SPP DIP vidinės žinių bazių architektūra turi palaikyti statinius DOCX, XLSX, PDF ir TXT formatų dokumentus.
- 2Žinių bazių architektūra turi palaikyti integracijas su Microsoft SQL Server, PostgreSQL, Oracle, MySQL duomenų bazėmis.
- 3Žinių bazių architektūra turi palaikyti integracijas su Microsoft Office 365 SharePoint dokumentų saugyklomis.
- 4Ž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ų) apima Lietuvos Respublikos teisės aktus (IT, viešieji pirkimai, duomenų apsauga), ES reglamentus/direktyvas, VSSA organizacinę struktūrą, metodikas, projektų dokumentus.
- 6Žinių bazė turi būti atnaujinama ir papildoma SPP DIP administratoriaus, integruojant naujus žinių šaltinius rankiniu būdu.
- 7Mažiausiai 2 suderintiems su VSSA teisės aktams, viešai prieinamiems LR ir ES registruose, turi būti realizuotas ir pademonstruotas automatinio pakeitimų sekimo ir žinių bazės atnaujinimo funkcionalumas.
- 8Žinių bazė turi semantiškai indeksuoti dokumentus DI modelių pagrindu, kad paieška ir atsakymai būtų kontekstiniai.
- 9SPP bendrųjų žinių bazės turinys apima SPK ir kitų SPP posistemių naudotojų instrukcijas (iki 10 dokumentų).
- 10SPP bendrųjų žinių bazės turinys apima paslaugų aprašų duomenis iš Skaitmeninių paslaugų katalogo (SPK) duomenų bazės.
- 11SPP bendrųjų žinių bazės turinys apima paslaugų modelių ir metaduomenų duomenis JSON formatu iš SPP CORE duomenų bazės (apibrėžiant paslaugos paskirtį, būseną, teikiančią instituciją, duomenų modelį, vykdymo proceso žingsnius, integracijas, programinius įskiepius).
- 12Pokalbių robotas turi būti integruotas su SPP posistemių duomenų bazėmis ir/arba API sluoksniu, siekiant gauti dinaminę, realaus laiko informaciją apie paslaugų aprašus (SPK PostgreSQL) ir paslaugų modelių/metaduomenų aprašus (SPP CORE PostgreSQL).
Integracijos ir sąsajos
- 1SPP DIP turi turėti galimybes realizuoti duomenų mainus su išorinėmis sistemomis REST API standartu.
- 2SPP 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.
- 3Pokalbių robotų realizacija turi numatyti galimybę, kad pokalbių robotai būtų prieinami ne tik SPP DIP terpėje, bet ir išoriniuose Web portaluose ir/arba mobiliose programėlėse per specialius įskiepius ir integracines sąsajas (API).
- 4Tiekėjas turi įgalinti išorinių portalų ir programėlių vystytojus įgyvendinti integraciją, pateikiant detalią SPP DIP integracinės sąsajos specifikaciją ir tos sąsajos panaudojimo išeities kodo pavyzdžius – pokalbių langelio prototipą.
- 5Tiekėjas turi pademonstruoti, kad prototipas gali inicijuoti užklausas į išorinę informacinę sistemą per integracinę programinę sąsają (REST API ar kitokiu standartiniu protokolu), gauti, suprasti ir pateikti pokalbio roboto naudotojo sąsajoje išorinės sistemos grąžintą atsakymą.
Bendrosios sistemos savybės
- 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 DI modeliais.
- 2Sistemą galima integruoti su standartiniais bendrosios paskirties DI modeliais, teikiamais debesijos paslaugų pagrindu.
- 3Sistemą galima integruoti su specializuotais DI modeliais ir tekstynais, įdiegtais SPP DIP terpėje arba VSSA infrastruktūroje.
- 4Sistemą galima integruoti su specializuotomis žinių ir duomenų bazėmis, tiek įdiegtomis SPP DIP terpėje, tiek su išorinėmis.
- 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 programinės įrangos architektūra turi užtikrinti 99% per mėnesį prieinamumą.
- 8SPP DIP turi būti keičiamo dydžio (scalable), kad galėtų efektyviai aptarnauti didelį ir nuolat augantį naudotojų skaičių.
- 9Pasibaigus Sutarties galiojimui visi Sutarties metu sukurti artefaktai (programinis 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.
Pokalbių roboto funkcionalumas
- 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 kalgoms.
- 3Privalo išlaikyti pokalbio kontekstą per kelias užklausas ir palaikyti asinchroninius pokalbius.
- 4Pokalbiai privalo būti saugomi istorijoje, o naudotojai neturi turėti galimybės trinti pokalbių.
- 5Privalo palaikyti tekstinius pokalbių 'kanalus' arba 'kambarius', kuriuose skirtingi naudotojai ir DI modeliai gali bendrauti realiu laiku, išlaikant bendrą kontekstą.
- 6Pokalbių robotų naudotojo sąsaja turi leisti naudotojui pasirinkti DI modelį iš įdiegtų/integruotų.
- 7Turi būti galimybė naudoti kelis skirtingus kalbos modelius vieno pokalbio metu, persijungiant ir naudojant juos lygiagrečiai.
- 8Turi teikti faktiškai teisingus ir kontekstą atitinkančius atsakymus į klausimus, naudodamas žinių bazes, pateiktus dokumentus ir išorinius informacijos šaltinius.
- 9Pokalbiams turi būti sugeneruojamas ir priskiriamas trumpas, aiškus pavadinimas naudojant DI modelius.
- 10Pokalbių roboto atsakymai turi būti pagrįsti žinių bazės dokumentais ir šaltiniais, pateikiant nuorodas į konkrečius teisės aktų straipsnius ar dokumento vietas.
- 11Atsakymuose turi būti aiškiai nurodyta, jei informacija nėra rasta arba naudojamas viešasis bendrinis šaltinis.
- 12Pokalbių robotas turi asistuoti rengiant, analizuojant, lyginant dokumentus, susijusius su žinių bazėmis.
- 13Pokalbių robotai turi informuoti naudotoją apie DI ribotumus ir atsakymų informacijos šaltinius.
- 14Naudotojas turi turėti galimybę pažymėti neteisingą ar klaidinančią informaciją, pateikti atsakymo vertinimą ir pagrindimą.
- 15Naudotojo grįžtamasis ryšys į blogą atsakymą turi būti registruojamas ir prieinamas SPP DIP administratoriui tobulinimui.
- 16Naudotojas turi turėti galimybę betarpiškai užregistruoti DI incidentą per SPP DIP pokalbių roboto sąsają, nustačius ES DI akto pažeidimą.
- 17Turi būti galima žymėti pokalbius etiketėmis, filtruoti ir vykdyti paiešką pagal jas.
- 18Turi būti galimybė vykdyti paiešką praeities pokalbių pavadinimuose, turinyje ir pagal suteiktas etiketes.
- 19Turi būti galimybė archyvuoti nebeaktualius pokalbius.
- 20Turi būti galimybė eksportuoti ir/ar kopijuoti pokalbius atvirų formato dokumentų pavidalu (TXT, DOCX, PDF).
- 21Turi gebėti priimti, analizuoti ir apibendrinti vartotojo pateiktų dokumentų (PDF, DOCX, XLSX, TXT) turinį.
- 22Privalo turėti RAG funkcionalumą, leidžiantį įkelti dokumentus ir juo praturtinti pokalbių roboto žinių bazę ir pokalbio kontekstą, naudojant PDF, DOCX, XLSX, TXT formatus.
- 23Turi būti integruota paieškos internete galimybė, kuri paieškos rezultatus perduoda RAG procesui.
- 24Turi būti integruota galimybė naudoti konkretaus (nurodant URL nuorodą) interneto puslapio turinį, perduodant jį RAG procesui.
- 25RAG vektorinio indeksavimo realizacija turi būti paremta VSSA turimu DI modeliu, įdiegtu VSSA infrastruktūroje.
- 26Roboto funkcionalumas turi leisti generuoti naujus dokumentus (el. laiškus, ataskaitų juodraščius) ir pateikti juos vartotojui, remiantis pokalbio kontekstu ir vartotojo nurodymais.
- 27Robotas privalo turėti formatavimo palaikymą praturtintam (Markdown standartu) turiniui generuoti ir atvaizduoti pokalbių lange.
- 28Turi palaikyti vaizdų ir paveikslėlių įkėlimą ir apdorojimą pokalbių lange, jei naudojami multi-modaliniai DI modeliai.
- 2995% pokalbių robotų atsakymų pateikimas turi prasidėti ne ilgiau nei per 3 sekundes nuo vartotojo užklausos gavimo.
- 30SPP 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.
- 31Pokalbių 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.
- 32Pokalbių robotai turi kontroliuoti, kad pokalbis liktų SPP naudojimo ir valstybės elektroninių paslaugų kontekste, užkardant nukrypimus kita tema (įskaitant necenzūrinę leksiką, smurtą, seksualinį, religinį, politinį turinį, nesusijusį su paslauga/teisės aktais).
- 33Pokalbių robotai neturi priimti ir apdoroti naudotojo persiunčiamų failų.
- 34Pokalbių robotai neturi generuoti failų, įskaitant paveiksliukus, vaizdinę ir garsinę informaciją.
- 35Pokalbių robotas turi užtikrinti pritaikomą naudotojo sąsajos dizainą (responsive design).
Atitiktis teisės aktams ir saugumas
- 1SPP DIP realizacija turi atitikti Europos Parlamento ir Tarybos reglamentą (ES) 2024/1689 (ES DI aktas / AI Act) ir Lietuvos Respublikos dirbtinio intelekto akto įgyvendinimo priemones.
- 2SPP DIP realizacija turi atitikti Europos Parlamento ir Tarybos reglamentą (ES) 2016/679 (Bendrąjį duomenų apsaugos reglamentą – BDAR / GDPR).
- 3SPP DIP realizacija turi atitikti Direktyvą (ES) 2022/2555 (NIS2) ir jos įgyvendinamuosius Lietuvos Respublikos teisės aktus.
- 4SPP DIP realizacija turi atitikti taikytinus ES autorių teisių teisės aktus ir Lietuvos Respublikos autorių teisių ir gretutinių teisių įstatymą.
- 5SPP DIP realizacija turi atitikti Lietuvos Respublikos valstybės informacinių išteklių valdymo įstatymą ir jį įgyvendinančius teisės aktus.
- 6SPP DIP realizacija turi atitikti Lietuvos Respublikos kibernetinio saugumo įstatymą ir iš jo išplaukiančius kibernetinio saugumo reikalavimus, įskaitant valstybės informacinių sistemų saugos nuostatus.
- 7Paslaugos turi būti teikiamos vadovaujantis Lietuvos Respublikos gaminių ir paslaugų prieinamumo reikalavimų įstatymu.
- 8SPP DIP naudotojo sąsajoje turi būti informuojama, kad pokalbiuose pateikiamas DI sugeneruotas turinys.
- 9SPP DIP turi būti realizuota užtikrinant atsparumą OWASP Top 10: 2021 kibernetinio saugumo rizikoms.
- 10Naudotojo asmens duomenys tiesiogiai neturi būti naudojami DI modelių apmokymui, konteksto nustatymui.
- 11Visi 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).
- 12Standartiniai 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.
DI modelių integravimas ir valdymas
- 1SPP DIP integracija ir sąveika su DI modeliais turi būti realizuotos per unifikuotą „DI modelių vartų modulį“.
- 2„DI modelių vartų“ API prieiga privalo būti valdoma per virtualius API raktus su naudojimo limitais, biudžetais ir prieigos teisėmis.
- 3Turi būti atsarginių DI modelių mechanizmas (fallbacks) klaidų ar nepasiekiamumo atveju.
- 4Turi būti realizuotas automatinis užklausų pakartojimo mechanizmas (retries) su konfigūruojamais nustatymais.
- 5Architektūra privalo palaikyti užklausų apkrovos balansavimą tarp kelių identiškų modelių egzempliorių.
- 6Turi būti integruotas atidėtinas talpinimas (caching) su konfigūruojamu talpyklos galiojimo laiku (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 privalo turėti integruotą DI pokalbių robotų kūrimo aplinką, leidžiančią kurti, modifikuoti ir vykdyti pasirinktinius pokalbių robotus.
- 10DI pokalbių robotų kūrimas ar modifikavimas turi būti grindžiamas nustatytais DI modeliais ir žinių bazėmis.
- 11Turi būti galimybė DI pokalbių robotams priskirti papildomas žinias, įrankius ar funkcijas.
- 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.
- 13Tiekėjas turi pademonstruoti, kaip SPP DIP prototipe pridedami nauji DI modeliai ir keičiami esamų modelių parametrai.
Vartotojų valdymas ir prieigos kontrolė
- 1SPP DIP naudotojų autentifikavimo mechanizmas turi palaikyti integraciją su VSSA naudojama debesijos tapatybės ir prieigos valdymo platforma Microsoft Entra ID.
- 2SPP DIP naudotojų prieigos prie pokalbių robotų autorizavimas turi būti paremtas naudotojų grupėmis ir/ar rolėmis.
- 3SPP DIP turi automatiškai perduoti pokalbių robotui ir jo DI modeliui naudotojų grupės informaciją pokalbio konteksto adaptavimui.
- 4SPP DIP administratorius privalo turėti galimybę kurti detalias vartotojų roles, grupes ir valdyti jų prieigos teises prie įvairių posistemės funkcijų (RBAC).
- 5Administratorius turi turėti galimybę suteikti arba apriboti teises į DI modelių/pokalbių robotų prieigą, žinių bazių prieigą, failų įkėlimą, žinučių redagavimą/trynimą, DI atsakymų perkūrimą/tęsimą/vertinimą, pokalbio nurodymų keitimą, kelių modelių naudojimą viename pokalbyje, paieškos internete ir paveikslėlių generavimo funkcijas.
- 6SPP DIP administratorius turi turėti galimybę sujungti naudotojus į logines roles ir/arba grupes, kurioms galima centralizuotai priskirti roles.
- 7SPP DIP administratorius turi turėti galimybę kurti, blokuoti, šalinti pavienius naudotojus, priskirti juos į grupes, suteikti jiems roles tiek individualiai, tiek per grupę.
- 8SPP DIP administratorius turi turėti galimybę įkelti naujų naudotojų sąrašą iš CSV ar lygiaverčio formato failo.
- 9SPP DIP turi turėti naudotojų aktyvumo ir veiksmų stebėsenos priemones ir ataskaitas (naudotojų prisijungimai, DI modelių/pokalbių robotų panaudojimas, stebėjimo laikotarpis).
- 10Turi būti galimybė naudotojų stebėsenos žurnalus ir metrikas eksportuoti į VSSA naudojama žurnalų konsolidavimo sistemą Graylog SIEM naudojant JSON formatą arba kitu palaikomu formatu.
- 11Neturi būti ribojama galimybė kurti papildomus pokalbių robotus ir jiems atitinkančias naudotojų roles.
- 12Tiekėjas turi pademonstruoti tiesioginę techninę prieigą prie žinių bazės turinio, parodant, kad Perkančioji organizacija gali matyti, eksportuoti ar ištrinti duomenis tiek naudotojo sąsajos priemonėmis, tiek duomenų bazės/failų saugyklos lygyje.
- 13Perkančioji organizacija turi matyti, eksportuoti ar ištrinti duomenis, užtikrinant, kad žinių bazių duomenys nėra saugomi uždaru Tiekėjo specializuotu formatu.
- 14Tiekėjas turi pademonstruoti, kaip sistemoje yra peržiūrimi konkretaus naudotojo DI modelių naudojimo duomenys (naudoti modeliai, užklausų skaičius, suvartotų žetonų skaičius, užklausų atlikimo laikas).
SPP paslaugų gavėjų pokalbių roboto funkcionalumas
- 1Pokalbių robotas turi būti prieinamas SPP produktų vadovui ir Skaitmeninių paslaugų katalogui (išoriniame SPK portale ir mobiliose programėlėse).
- 2Tiekė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, naudojant bendrines SPK modulių sistemines naudotojų paskyras.
- 3Pokalbių robotas turi asistuoti atsakydamas į klausimus dėl SPK naudojimo; apie katalogo paslaugas, aprašus ir duomenis, reikalingus užsakymui, paslaugų būsenas ir teikimo eigą.
- 4Pokalbių robotas turi patarti, kokios paslaugos tinkamos aprašyto gyvenimo scenarijaus atveju; informuoti, kokius reikalavimus turi atitikti paslaugos gavėjas, kad užsakyti vieną ar kitą paslaugą.
- 5Pokalbių robotas turi atsakyti į klausimus apie institucijas, kurioms perduodami paslaugų užsakymai ir kiti naudotojo duomenis; atsakyti į klausimus apie paslaugų teikimą reglamentuojančius teisės aktus.
SPP paslaugas teikiančios institucijos pokalbių roboto funkcionalumas
- 1Pokalbių robotas turi būti prieinamas SPP produktų vadovui ir SPP Institucijų Web portalui (išoriniame SPP Institucijos Web portale).
- 2Tiekėjas turi sukurti integracines priemones ir parengt integracijos pavyzdžius pokalbių roboto naudotojo sąsajos įskiepio realizavimui SPP Institucijos Web portale, naudojant bendrinę sisteminę naudotojo paskyrą.
- 3Pokalbių robotas turi asistuoti atsakydamas į klausimus dėl „SPP Institucijų Web portalo“ panaudojimo; apie katalogo paslaugas, aprašus ir duomenis, reikalingus užsakymui, paslaugų modelius.
- 4Pokalbių robotas turi padėti rasti kitų institucijų teikiamas el. paslaugas, konsultuoti apie aprašų/modelių panaudojimą/adaptavimą; atsakyti į klausimus dėl galimybės adaptuoti kitos institucijos el. paslaugų aprašus ir modelius naudotojo institucijai.
- 5Pokalbių robotas turi atsakyti į klausimus apie paslaugų teikimą reglamentuojančius teisės aktus; atsakyti į klausimus apie teisės aktus, reglamentuojančius institucijos paslaugų skaitmenizavimą ir teikimą per SPP.
Dokumentai17
tendis.lt · Sukurta recodin.lt