Konkursa nolikumā izvirzītā prasība par ChatGPT apmācību un datu uzglabāšanu platformu. [8] Par mākslīgā intelekta Chat GPT apmācību un apmācības materiālu uzglabāšanu
Konkursa priekšmeta 1. daļas prasības ir noteiktas Konkursa nolikuma 7. pielikumā, kura 2.2. punktā cita starpā noteikts, ka mākslīgā intelekta Chat GPT apmācībai un apmācības materiālu uzglabāšanai ir jānotiek kontaktu centra platformā.
Iesniedzējs uzskata, ka šī prasība faktiski pieprasa iebūvētu LLM integrāciju ar failu analīzes un datu glabāšanas iespējām, kas pieejama tikai atsevišķās, ļoti specifiskās platformās. Lielākā daļa modernu AI risinājumu paredz šādu funkcionalitāti nodrošināt, izmantojot API.
Iesniegumu izskatīšanas komisija konkrētās prasības pamatotības izvērtēšanai pieaicināja Latvijas informācijas un komunikācijas tehnoloģijas asociācijas ieteiktu ekspertu Oskaru Vilīti. Vadoties no eksperta atzinuma, Iesniedzējs šo prasību interpretē kā nepieciešamību pēc platformā iebūvētiem LLM), un to integrāciju ar failu analīzes un datu glabāšanas iespējām, pretēji iespējai to integrēt, izmantojot API (piemēram, OpenAI). No Konkursa nolikumā ietvertās prasības tas tomēr tiešā veidā neizriet. Kā norāda eksperts savā atzinumā, tad prasības formulējums nav precīzs, jo atsaucas uz “Chat GPT apmācību”, lai gan Chat GPT ir konkrēts produkts (konkrēts LLM - lielo valodas modeļu sērija, ko izstrādājusi OpenAI), un tas netiek mācīts no jauna. Tomēr, ar šādu terminu var saprast: a) modeļa pielāgošanu (fine-tuning), b) savas ChatGPT pielāgotas versijas izveidi, c) vai zināšanu bāzes izveidi un integrāciju, nodrošinot kontekstu LLM (piemēram, izmantojot RAG principus). Bez papildus informācijas no prasības izriet, ka platformai jānodrošina kādu no šiem risinājumiem, turklāt LLM konteksta nodrošināšanai nepieciešamajai informācijai jāglabājas platformā. Pati par sevi šāda prasība pilnībā atbilst industrijas praksei, glabājot kontekstuālos materiālus lokālās vektoru datubāzēs un izmantojot tās LLM pieprasījuma konteksta formēšanai. No šīs prasības formulējuma neizriet ierobežojums LLM API lietošanā. Eksperta ieskatā Pasūtītāja sniegtais skaidrojums gan satur pretrunas. No vienas puses (Konkursa nolikuma tehniskās specifikācijas) 2.2. punkta prasība tiek pretstatīta trešās puses LLM servisu API integrācijai, no otras – kā piemēri tiek minētas platformas, kas izmanto trešās puses LLM API (piemēram, Five9 Intelligent CX Platform, XCALLY Motion AI, Genesys Cloud CX). Kopumā tomēr rodas iespaids, ka Pasūtītājs meklē platformu, kas nodrošina integrētu lokalizētu zināšanu pārvaldību un izmantošanu MI asistentos (kas ir normāla, industrijai atbilstoša prasība), iespējams, līdz galam neizprotot tehniskās detaļas.
Kā norāda eksperts, nozarē tiek lietoti gan lokāli izvietoti lielie valodu modeļi, gan mākoņrisinājumi, kam piekļuve tiek nodrošināta caur API. Izvēle, kuru pieeju lietot, balstās uz konkrētiem kritērijiem, piemēram: a) datu konfidencialitāte (mākoņrisinājumos dati nonāk trešo pušu serveros), b) interneta pieejamība (lokālie modeļi uz jaudīgām iekārtām var nodrošināt veiktspēju pat bez stabila interneta savienojuma), c) sistēmas mērogojamības vajadzības (lokālie modeļi ierobežoti ar pieejamo infrastruktūru), d) domēnam pielāgoti dati (lokālos modeļus iespējams trenēt ar saviem datiem). Atbilstoši definētiem kritērijiem ir pilnībā pieļaujamas un pamatojamas prasības pēc lokāli izvietota LLM. Katram risinājumam ir gan priekšrocības, gan trūkumi (skat. iepriekš minētos kritērijus), piemēram, konfidenciālas informācijas nenonākšanu uz trešās puses serveriem var nodrošināt tikai lokāli izvietots LLM.
Tāpat saistībā ar iesniegumu izskatīšanas komisijas uzdotajiem jautājumiem ekspertam, vai API risinājums var radīt sadrumstalotības, drošības, neprognozējamu izmaksu un datu pieejamības riskus, eksperts norāda, ka a) sadrumstalotības risks nebūtu attiecināms uz API risinājumu – tā ir industrijā pieņemta prakse sistēmas komponenšu komunikāciju nodrošināt, lietojot API, un tas attiecas gan uz sistēmas iekšējo komponenšu saziņu, gan ārējām saskarnēm, b) drošības risks var tikt attiecināms uz LLM mākoņrisinājumu konfidenciālas informācijas kontekstā, jo informācija tiek sūtīta uz trešās puses serveriem. Risks var tikt mazināts, lietojot reģionāli ierobežotus LLM API, kā, piemēram, Azure vai AWS, c)Neprognozējamu izmaksu risks nebūtu attiecināms uz LLM mākoņrisinājumu. Izmaksas ir prognozējamas gan mākoņrisinājuma, gan lokāli izvietota modeļa gadījumā. Tas jau ir platformas cenu politikas jautājums, kā konkrētās izmaksas tiek atainotas pret platformas lietotāju, d)Datu pieejamības risks, ja ar to tiek saprasta spēja nodrošināt piekļuvi Pasūtītāja zināšanu bāzei, nav attiecināms uz LLM mākoņrisinājumu, jo arī tajā iespējams realizēt zināšanu izmantošanu konteksta bagātināšanai.
Izvērtējot iepriekš norādīto, iesniegumu izskatīšanas komisija secina, ka konkrētā tehniskās specifikācijas prasība par LLM integrāciju kontaktu centra platformā nav viennozīmīgi saprotama, proti, atšķiras Iesniedzēja un Pasūtītāja izpratne par konkrētās tehniskās prasības izpildi, jo prasība konkrētajā redakcijā neliedz izmantot API LLM integrācijai. Turklāt šī izpratne par LLM integrāciju ir diametrāli pretēja. Vienlaikus arī konstatējams, ka Pasūtītāja norādītais pamatojums, ar kuru tas pamato konkrēto tehniskās specifikācijas prasību, ir pretrunīgs, kas attiecīgi norāda, ka Pasūtītājam konkrētās lietas izskatīšanas procesā nav objektīva pamatojuma šādas apstrīdētās prasības izvirzīšanai kontaktu centra risinājumam. Senāts 2013. gada 18. decembra rīcības sēdes lēmuma lietā Nr.SKA1033/2013, vērtējot nolikuma prasību atbilstību Publisko iepirkumu likumam, ir norādījis, ka ir izslēdzami tikai nepamatoti, nevis jebkuri ierobežojumi konkurencei. Līdz ar to, tā kā nav konstatējams objektīvs pamatojums apstrīdētajai tehniskās specifikācijas prasībai, kā arī šīs prasības neskaidro dabu, iesniegumu izskatīšanas komisijas ieskatā šī prasība ir atceļama un attiecīgi Iesniedzēja iesniegums šajā daļā ir atzīstams par pamatotu.