Grįžti į sąrašą

SKAITMENINIŲ PASLAUGŲ PLATFORMOS DIRBTINIO INTELEKTO POSISTEMĖS KŪRIMO IR DIEGIMO PASLAUGOS

Išanalizuota

Viešoji įstaiga CPO LT

Rinkos konsultacijaCPV: 72000000 - IT paslaugos: konsultavimas, programinės įrangos kūrimas, internetas ir aptarnavimo paslaugos
ID: 64871642026-02-10 14:24
Atidaryti CVP IS

Aprašymas

Perkamos Skaitmeninių paslaugų platformos dirbtinio intelekto posistemės (SPP DIP) kūrimo, diegimo ir palaikymo paslaugos, įskaitant išorinių naudotojų bei administravimo pokalbių robotų diegimą. Taip pat įsigyjami standartinių bendrosios paskirties DI modelių resursai. Pirkimo tikslas – sukurti DI sistemą, kuri efektyvintų institucijų specialistų ir paslaugų gavėjų darbą, automatizuojant konsultavimą ir plėtrą.

Kvalifikaciniai reikalavimai

  • 1Pasiūlymų vertinimo etape Tiekėjas privalės atlikti turimo SPP DIP ar atskirų kertinių elementų prototipo demonstraciją.
  • 2Paslaugas teikiantis subjektas neturi vykdyti veiklos karinę agresiją prieš Ukrainą vykdančiose šalyse.
  • 3Paslaugas teikiantis subjektas neturi būti įmonių grupės, kurios bet kuris narys vykdo veiklą karinę agresiją prieš Ukrainą vykdančiose šalyse, nariu.
  • 4Paslaugas teikiantis subjektas neturi dalyvauti tokios įmonių grupės veikloje per savo vadovą, kito valdymo ar priežiūros organo narius ar kitą asmenį (kitus asmenis), turintį (turinčius) teisę atstovauti tiekėjui ar jį kontroliuoti, jo vardu priimti sprendimą, sudaryti sandorį, asmenį (asmenis), turintį (turinčius) teisę surašyti ir pasirašyti tiekėjo finansinės apskaitos dokumentus.
  • 5Paslaugas teikiantis subjektas negali remtis pajėgumais ir (ar) sudaryti subtiekimo sutarties su subtiekėju netenkinančiu šių sąlygų.
  • 6Standartiniai DI modeliai turi būti teikiami viešosios debesijos paslaugų pavidalu tik iš Europos Sąjungos ir NATO šalių debesijos centrų.
  • 7Paslaugos neturi kelti grėsmės Nacionaliniam saugumui vadovaujantis LR viešųjų pirkimų įstatymo 37 str. 8 d. ir 9 d. nuostatoms.

Techniniai reikalavimai

SPP bendrųjų žinių bazė

  • 1Ž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.
  • 2Žinių bazė turi būti atnaujinama ir papildoma SPP DIP administratoriaus, pateikiant naujus dokumentus ar keičiant esamų dokumentų versijas, integruojant naujus žinių šaltinius rankiniu būdu.
  • 3Pokalbių 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.

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.
  • 2SPP DIP realizacija turi atitikti galiojančius ES ir LR teisės aktus, įskaitant ES DI aktą, BDAR, NIS2, ES autorių teisių 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 gaires.
  • 3SPP DIP naudotojo sąsajoje turi būti informuojama, kad pokalbiuose pateikiamas DI sugeneruotas turinys.
  • 4SPP DIP integracija ir sąveika su DI modeliais turi būti realizuotos per unifikuotą „DI modelių vartų modulį“.
  • 5Prieiga prie „DI modelių vartų“ API GW privalo būti valdoma per virtualius API raktus, su galimybe valdyti naudojimo limitus, biudžetus ir prieigos teises.
  • 6Turi turėti atsarginių modelių mechanizmą (fallbacks), kai užklausa automatiškai išsiunčiama į iš anksto sukonfigūruotą atsarginį DI modelį, įvykus klaidai ar nepasiekus pagrindinio modelio.
  • 7Turi būti realizuotas automatinis užklausų pakartojimo mechanizmas (retries) su konfigūruojamais nustatymais (pvz., bandymų skaičius, delsos laikas).
  • 8Architektūra privalo palaikyti užklausų apkrovos balansavimą (load balancing) tarp kelių identiškų modelių egzempliorių.
  • 9Turi būti integruotas atidėtinas talpinimas (caching), leidžiantis saugoti ir pakartotinai naudoti atsakymus į identiškas užklausas, su konfigūruojamu talpyklos galiojimo laiku.
  • 10SPP DIP sąveika su „DI modelių vartais“ turi būti realizuota REST API standartu.
  • 11Tiekė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.
  • 12SPP DIP turi turėti galimybes realizuoti duomenų mainus su išorinėmis sistemomis REST API standartu.
  • 13SPP DIP turi būti tinkama diegti tiek VSSA valstybinio duomenų centro, tiek VSSA valdomoje Microsoft Azure debesijos infrastruktūroje.
  • 14SPP DIP nustatymai turi būti saugomi duomenų bazėje, užtikrinant nustatymų pastovumą ir galimybę diegti kelis posistemės serverius su apkrovos balansavimu.
  • 15SPP 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.
  • 16SPP DIP turi būti realizuota užtikrinant atsparumą OWASP Top 10: 2021 kibernetinio saugumo rizikoms.
  • 17SPP DIP naudotojų autentifikavimo mechanizmas turi palaikyti integraciją su VSSA naudojama debesijos tapatybės ir prieigos valdymo platforma Microsoft Entra ID.
  • 18SPP DIP naudotojų prieigos prie pokalbių robotų autorizavimas turi būti paremtas naudotojų grupėmis ir/ar rolėmis.
  • 19SPP DIP turi automatiškai perduoti pokalbių robotui ir jo DI modeliui, kokiai naudotojų grupei priklauso naudotojas tam, kad adaptuoti pokalbio kontekstą.
  • 20Naudotojo asmens duomenys tiesiogiai neturi būti naudojami DI modelių apmokymui, konteksto nustatymui.
  • 21SPP 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).
  • 22SPP DIP administratorius turi turėti galimybę suteikti arba apriboti teises: DI modelių/Pokalbių robotų prieiga, Žinių bazių prieiga, teisė įkelti failus, teisė redaguoti ir trinti savo siųstas žinutes, teisė iš naujo perkurti DI modelio atsakymą arba tęsti jo generavimą, teisė vertinti modelio atsakymus, teisė keisti pokalbio nurodymus (Prompt) DI modeliui, teisė viename pokalbyje naudoti kelis skirtingus modelius, teisė naudoti paieškos internete funkciją, teisė naudoti paveikslėlių generavimo funkciją.
  • 23SPP DIP administratorius turi turėti galimybę sujungti naudotojus į logines roles ir/arba grupes, kurioms galima centralizuotai priskirti roles.
  • 24SPP DIP administratorius turi turėti galimybę kurti, blokuoti, šalinti pavienius naudotojus, priskirti juos į grupes, suteikti jiems roles tiek individualiai, tiek per grupę.
  • 25SPP DIP administratorius turi turėti galimybę įkelti naujų naudotojų sąrašą iš CSV ar lygiaverčio formato failo.
  • 26SPP DIP turi turėti naudotojų aktyvumo ir veiksmų stebėsenos priemones ir ataskaitas, apimančias naudotojų prisijungimus, DI modelių ir pokalbių robotų panaudojimą.
  • 27Turi būti galimybė naudotojų stebėsenos žurnalus ir metrikas eksportuoti į VSSA naudojamą Graylog SIEM sistemą JSON arba kitu palaikomu formatu.
  • 28Turi būti galimybė sekti ir registruoti kiekvienos užklausos į DI modelį kaštus, remdamasi modelio tiekėjo kainodara.
  • 29Turi būti galimybė nustatyti DI resursų – žetonų (tokens) limitus DI modeliams arba naudotojams.
  • 30SPP DIP neturi riboti galimybių kurti papildomus pokalbių robotus ir jiems atitinkančias naudotojų roles.
  • 31SPP DIP vidinės žinių bazių architektūra turi palaikyti statinius DOCX, XLSX, PDF ir TXT formatų dokumentus, integracijas su Microsoft SQL Server, PostgreSQL, Oracle, MySQL duomenų bazėmis, integracijas su Microsoft Office 365 SharePoint dokumentų saugyklomis, integracijas su sąsajomis, realizuotomis MCP standartu.
  • 32SPP 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ą.
  • 33SPP DIP programinės įrangos architektūra turi užtikrinti 99% per mėnesį prieinamumą (uptime).
  • 34SPP DIP turi būti keičiamo dydžio (scalable), kad galėtų efektyviai aptarnauti didelį ir nuolat augantį naudotojų skaičių.
  • 35Pasibaigus 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.

SPP DIP prototipo demonstracija

  • 1Tiekėjas teikdamas pasiūlymą privalo turėti veikiantį SPP DIP ar atskirų kertinių elementų prototipą (-us).
  • 2Demonstravimas turi būti vykdomas tiekėjo aplinkoje nuotoliniu būdu.
  • 3Demonstracijos apimtis: Prototipo programinio kodo ir aplinkos valdymas (įrodant tiesioginę prieigą prie kodo ir aplinkos valdymo); Naudotojų ir rolų valdymo funkcionalumas (sukurti pirkimo komisijos nurodytą naudotoją ir suteikti prieigą); Bazinis pokalbio roboto funkcionalumas (parodyti pokalbio su pasirinktu DI modeliu funkcionalumą lietuvių ir anglų kalbomis, išlaikant kontekstą); Specializuoto pokalbių roboto kūrimo funkcionalumas (sukurti pokalbių robotą ir jo žinių bazę 2 PDF ir DOCX dokumentų pagrindu, nustatyti apribojimą naudoti tik žinių bazės turinį); Integracija su išorinėmis informacinėmis sistemomis (pademonstruoti užklausas į išorinę sistemą per REST API); Duomenų suverenitetas ir skaidrumas (pademonstruoti tiesioginę techninę prieigą prie žinių bazės turinio); Neprisirišimas prie konkrečių DI modelių (pademonstruoti, kaip pridedami nauji DI modeliai ir keičiami esamų parametrų); Naudotojų veiklos stebėsena (parodyti konkretaus naudotojo DI modelių naudojimo duomenis).

SPP paslaugų gavėjų pokalbių robotas

  • 1Pokalbių robotas turi būti prieinamas šioms naudotojų rolėms: SPP produktų vadovas (tiesiogiai SPP DIP terpėje) ir Skaitmeninių paslaugų katalogas (išoriniame SPK portale ir mobiliose programėlėse).
  • 2Tiekėjas turi sukurti integracines priemones ir parengti integracijos pavyzdžius pokalbių roboto naudotojo sąsajos įskiepio realizavimui SPK portale ir SPK mobiliose programėlėse.
  • 3Pokalbių robotas turi gebėti asistuoti atsakydamas į klausimus dėl SPK naudojimo, apie katalogo paslaugas, aprašus ir duomenis, reikalingus užsakymui, kokios paslaugų būsenos ir teikimo eiga, patardamas, kokios paslaugos tinkamos aprašyto gyvenimo scenarijaus atveju, informuodamas, kokius reikalavimus turi atitikti paslaugos gavėjas, atsakydamas į klausimus apie institucijas ir teisės aktus.

VSSA aktualių teisės aktų žinių bazė

  • 1Žinių bazės turinį sudaro iki 100 dokumentų: LR aktualūs teisės aktai, susiję su VSSA veikla; 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.
  • 2Žinių bazė turi būti atnaujinama ir papildoma SPP DIP administratoriaus, pateikiant naujus dokumentus ar keičiant esamų dokumentų versijas, integruojant naujus žinių šaltinius rankiniu būdu.
  • 3Mažiausiai 2 suderintiems su VSSA teisės aktams, kurie įtraukti į žinių bazę ir kurie viešai prieinami LR teisės aktų registre ir ES teisės aktų registre EUR-Lex, turi būti realizuotas ir pademonstruotas automatinio pakeitimų sekimo ir žinių bazės atnaujinimo funkcionalumas.
  • 4Žinių bazė turi semantiškai indeksuoti dokumentus DI modelių pagrindu.

Paslaugų teikimo ir palaikymo reikalavimai

  • 1Ne vėliau nei po 10 darbo dienų po Sutarties pasirašymo turi būti sudarytas Projekto reglamentas, reguliariai atnaujinamas, apimantis projektinę organizaciją, įrankius, įgyvendinimo būdą, diegimo aplinkas, pakeitimų ir rizikų valdymą, DI rizikos ir atitikties ES DI aktui vertinimą.
  • 2VSSA atsakinga pateikti reikalingą dokumentaciją, duomenų šaltinius, metaduomenų rinkinius ir prieigos teises per 5 d. d. nuo paklausimo.
  • 3Tiekė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ą.
  • 4Tiekėjas atsakingas parengti žinių bazių naujinimo instrukcijas, įskaitant teikiamų duomenų formatus ir priemones.
  • 5Paslaugų darbai turi būti vykdomi iteracinių-inkrementiniu būdu (Agile).
  • 6Tiekėjas turi užtikrinti darbų eilės, užduočių būsenų ir progreso matomumą Užsakovui ir kartu derinti vykdymo prioritetus.
  • 7SPP DIP turi būti sukurta ir įdiegta VSSA valdomoje infrastruktūroje ne vėliau nei per 1 mėnesį nuo Sutarties pasirašymo.
  • 8SPP DIP palaikymo paslaugos turi būti teikiamos 11 mėnesių laikotarpyje nuo SPP DIP sukūrimo ir diegimo priėmimo.
  • 9Standartinių bendrosios paskirties DI modelių resursai turi būti teikiami 11 mėnesių laikotarpyje nuo SPP DIP sukūrimo ir diegimo priėmimo arba iki visiško nurodytos resursų apimties sunaudojimo.
  • 10Techninėje specifikacijoje aprašyti pokalbių robotai ir jų žinių bazės turi būti sukurti ir įdiegti ne vėliau nei 2026 m. gegužės 20 d.
  • 11Palaikymo paklausimų kategorijos: Klaida, DI incidentas, IT incidentas, Konsultacija, Pakeitimas.
  • 12Reakcijos ir sprendimo laikai Klaidoms, DI incidentams, IT incidentams: Kritinis – reakcija per 4 d.v., sprendimas per 2 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..
  • 13Palaikymo paslaugos preliminariai apims 480 Tiekėjo specialistų darbo valandų Pakeitimams, Konsultacijoms ir IT incidentams, kilusiems ne dėl Tiekėjo kaltės.

DI pokalbių robotų funkcionalumo 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.
  • 4Privalo palaikyti asinchroninius pokalbius, leidžiančius naudotojui dirbti su keliais pokalbiais vienu metu, neprarandant konteksto.
  • 5Pokalbiai privalo būti saugomi istorijoje, naudotojai neturi turėti galimybės trinti pokalbius.
  • 6Privalo palaikyti tekstinius pokalbių „kanalus“ arba „kambarius“, kuriuose skirtingi naudotojai ir skirtingi DI modeliai ir agentai gali bendrauti viename pokalbyje realiu laiku.
  • 7Pokalbių robotų naudotojo sąsaja turi leisti naudotojui pasirinkti DI modelį iš įdiegtų ir/ar integruotų su SPP DIP.
  • 8Turi būti galimybė naudoti kelis skirtingus kalbos modelius vieno pokalbio metu.
  • 9Turi teikti faktiškai teisingus ir kontekstą atitinkančius atsakymus į klausimus, naudodamas prieigą prie nustatytų žinių bazių, roboto naudotojo pateiktus dokumentus ir išorinius informacijos šaltinius.
  • 10Pokalbiams turi būti sugeneruojamas ir priskiriamas trumpas, aiškus pavadinimas naudojant DI modelius.
  • 11Pokalbių roboto atsakymai turi būti pagrįsti žinių bazės dokumentais ir šaltiniais, pateikiant nuorodas į konkrečius teisės aktų straipsnius ar dokumento vietas.
  • 12Pokalbių robotas turi asistuoti rengiant, analizuojant, lyginant dokumentus, susijusius su žinių bazėmis (per natūralios kalbos dialogą, išlaikant kontekstą, atliekant patariamąjį vaidmenį).
  • 13Pokalbių robotai turi informuoti naudotoją apie DI ribotumus ir atsakymų informacijos šaltinius.
  • 14Naudotojas turi turėti galimybę pažymėti blogą atsakymą, pateikti atsakymo vertinimą ir pagrindimą, o grįžtamasis ryšis turi būti registruojamas ir prieinamas SPP DIP administratoriui.
  • 15Analizuojant 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ą.
  • 16Turi būti galima žymėti pokalbius etiketėmis (tags) ir vėliau pagal jas filtruoti bei vykdyti paiešką.
  • 17Turi būti galimybė vykdyti paiešką praeities pokalbių pavadinimuose, turinyje ir pagal suteiktas etiketes.
  • 18Turi būti galimybė archyvuoti nebeaktualius pokalbius.
  • 19Turi būti galimybė eksportuoti ir/ar kopijuoti pokalbius atvirų formato dokumentų pavidalu, pvz., TXT, DOCX, PDF.
  • 20Turi gebėti priimti, analizuoti ir apibendrinti vartotojo pateiktų dokumentų (pvz., PDF, DOCX, XLSX, TXT) turinį.
  • 21Privalo turėti RAG funkcionalumą, leidžiantį įkelti PDF, DOCX, XLSX, TXT dokumentus ir juo praturtinti pokalbių roboto žinių bazę ir pokalbio kontekstą.
  • 22Turi būti integruota paieškos internete galimybė, kuri paieškos rezultatus perduoda RAG procesui.
  • 23Turi būti integruota galimybė naudoti konkretaus interneto puslapio turinį (nurodant URL nuorodą), kuris perduodamas RAG procesui.
  • 24RAG vektorinio indeksavimo realizacija turi būti paremta VSSA turimu DI modeliu, įdiegtu VSSA infrastruktūroje.
  • 25Roboto funkcionalumas turi leisti generuoti naujus dokumentus (pvz., el. laiškus, ataskaitų juodraščius) ir pateikti juos vartotojui, remiantis pokalbio kontekstu ir vartotojo nurodymais.
  • 26Robotas privalo turėti formatavimo palaikymą praturtintam (pvz., Markdown standartu) turiniui generuoti ir atvaizduoti pokalbių lange.
  • 27Turi palaikyti vaizdų ir paveikslėlių įkėlimą ir apdorojimą pokalbių lange, jei naudojami multi-modaliniai DI modeliai.
  • 2895% pokalbių robotų atsakymų pateikimas turi prasidėti ne ilgiau nei per 3 sekundes nuo vartotojo užklausos gavimo.
  • 29Visi naudotojo duomenys ir pokalbiai turi būti perduodami šifruotu ryšiu (TLS/SSL) ir saugomi pagal taikomus duomenų apsaugos standartus, įskaitant BDAR.
  • 30Pokalbių roboto architektūra ir realizacija turi leisti naudotis juo tiek SPP DIP naudotojo sąsajos terpėje, tiek realizuojant įskiepius į kitų Web portalų naudotojo sąsają.
  • 31Pokalbių robotas turi užtikrinti pritaikomą naudotojo sąsajos dizainą (responsive design).

Standartinių bendrosios paskirties DI modelių resursai

  • 1Tiekėjas turi pasiūlyti standartinių bendrosios paskirties DI modelių resursus (žetonus), kurie turi būti naudojami 11 mėnesių 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 skirtingų ekosistemų (tiekėjų) DI modelių per saugius įmonių lygio prieigos taškus (API).
  • 4Tiekėjas privalo užtikrinti prieigą prie šių (arba lygiaverčių savo parametrais bei našumu) ir naujesnių jų versijų: OpenAI šeima (GPT-5 (Omni) ir GPT-5-mini klasės modeliai), Anthropic šeima (Claude Sonnet 4 ir Claude Haiku 4.5 klasės modeliai), Google šeima (Gemini 2.5 Pro ir Gemini 2.5 Flash klasės modeliai).
  • 5Standartinių bendrosios paskirties DI modelių atitiktis ES DI aktui turi būti užtikrinta jų tiekėjų atsakomybe. Neatitikties atveju, SPP DIP Tiekėjas privalo užtikrinti pakeitimą kitais lygiaverčiais modeliais, nekeičiant kainos.
  • 6Standartinių DI modelių resursai turi apimti šiuos žetonų limitus: Aukšto našumo (Reasoning/Flagship) modelių klasė – ne mažiau kaip 3 000 000 000 žetonų; Greitaveikos/Ekonominė (High-efficiency) modelių klasė – ne mažiau kaip 10 800 000 000 žetonų.
  • 7DI resursų suvartojimo limitai (pvz., savaitei, mėnesiui) turi būti valdomi SPP DIP priemonėmis.
  • 8DI resursams turi būti taikomas suminis įvesties (Input/Context) ir išvesties (Output/Generation) žetonų skaičiavimas, kur išvesties žetonai sudarytų ne daugiau kaip 20% bendro limito.
  • 9Naudotojui išnaudojus „Aukšto našumo“ klasės limitą, turi būti užtikrinta galimybė tęsti darbą naudojant „Greitaveikos“ klasės modelius.
  • 10Neturi 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.
  • 11Neturi 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.
  • 12Neturi būti ribojama galimybė įsigyti papildomus išvardintų ir/ar alternatyvių standartinių DI modelių tiekėjų resursus.

SPP paslaugas teikiančios institucijos pokalbių robotas

  • 1Pokalbių robotas turi būti prieinamas šioms naudotojų rolėms: SPP produktų vadovas (tiesiogiai SPP DIP terpėje) ir SPP Institucijų Web portalas (išoriniame SPP Institucijos Web portale).
  • 2Tiekėjas turi sukurti integracines priemones ir parengti integracijos pavyzdžius pokalbių roboto naudotojo sąsajos įskiepio realizavimui SPP Institucijos Web portale.
  • 3Pokalbių robotas turi gebėti asistuoti atsakydamas į klausimus dėl „SPP Institucijų Web portalo“ panaudojimo, apie katalogo paslaugas, aprašus ir duomenis, kokie tų paslaugų modeliai, padėdamas rasti kitų institucijų teikiamas el. paslaugas, konsultuodamas apie tokių paslaugų aprašų ir modelių turinio panaudojimo galimybes, atsakydamas į klausimus dėl galimybės adaptuoti kitos institucijos el. paslaugų aprašus ir modelius, atsakydamas į klausimus apie paslaugų teikimą ir skaitmenizavimą reglamentuojančius teisės aktus.

SPP išorinių naudotojų pokalbių robotų bendrieji 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ų 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.
  • 3Pokalbių robotai turi kontroliuoti, kad pokalbis liktų SPP naudojimo ir valstybės elektroninių paslaugų kontekste, užkardant nukrypimus į kitas temas (necenzūrinė leksika, smurtas, seksualinis, religinis, politinis turinys, išskyrus susijusį su paslauga ar teisės aktais).
  • 4Pokalbių robotai neturi priimti ir apdoroti naudotojo persiunčiamų failų.
  • 5Pokalbių robotai neturi generuoti failų, įskaitant paveiksliukus, vaizdinę ir garsinę informaciją.
  • 6Pokalbių 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).
  • 7Tiekė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ą.

Dokumentai6

  • 2 pr. Technine_specifikacija.docx
  • 3 pr. Sutarties_specialiosios_sąlygos.docx
  • 4 pr. Pasiūlymo_forma.docx
  • 1146_6487164.pdf
  • 1_Kvietimas_rinkos konsultacijai.docx
  • 1 pr. Rinkos konsultacijos klausimynas.docx
tendis.lt · Sukurta recodin.lt