[LV] LATA 2026 Konference
Date:
This post is in Latvian, because the conference and the accompanying slides were also in Latvian.
Nesen bija kārtējā LATA konference, nu jau 2026. gada versija: Digitālā burbuļošana. Procesi, datu centri, mākslīgais intelekts.
Slaidus viņi vēl nenopublicēja, bet šo to norises laikā piefiksēju. Iedomājos, ka uztaisīšu sava veida kopsavilkumu par to, kas šķita vissaistošākais. Nebūs te tik daudz info par konkrētajiem runātājiem vai LATA gada balvu, vairāk par pašu saturu.
Savukārt, ja interesē pilnais video ieraksts, to var apskatīties šeit: YouTube: "Digitālā burbuļošana. Procesi. Datu centri. Mākslīgais intelekts."
Jēgpilna IKT pārvaldība: no birokrātiskas kontroles līdz attīstības ceļakartēm
Prezentēja: Gatis Ozols, VARAM, Valsts sekretāra vietnieks digitālās transformācijas jautājumos
No sākuma bija prezentācija par IKT pārvaldību valstī. Vārdu sakot, VARAM (Viedās Administrācijas un Reģionālās Attīstības Ministrija) mēģina izstrādāt plānu, kā valstī pārvaldīt sistēmu izveidi un uzturēšanu, viņi to nosauca par "IKT būvvaldi", ar domu to pārvaldi arī taisīt vairākos slāņos:
Ja interesē, tad atradu prezentāciju kur par to var vairāk paskatīties: IKT būvvalde un digitālās pārvaldes arhitektūra
Papildus tam, arī pašā mājaslapā ir vairāk info: Digitālās pārvaldes arhitektūra
Protams, ikdienā gan jau tā ir birokrātija, bet censties sakārtot to kā valstī sistēmas tiek izstrādātas, vismaz ideja ir atzīstama!
Paši arī par to varēja palielīties:
Papildus tam, viss izskatās ka ir ne tikai "top-down" pieejā, bet arī cenšas drusku dabūt info no nozares:
No vienas puses, lietas centralizēt ir riskanti, jo var rasties situācijas kur domēnam piedāvā/rekomendē/uzspiež nepiemērotus risinājumus kas no tehniskās puses vienkārši nedarbotos labi (OS, DB, API). Bet no otras puses, reizēm lietas izdodas tīri smuki. Var paskatīties uz to, kā Lielbritānijā izveidoja priekš valdības saitiem konsistentu dizaina sistēmu, lai nebūtu problēmas ar accessibility un lietotājiem būtu vieglāk strādāt (UI elementi, izskats un darbība laika gaitā pazīstami): Design your service using GOV.UK styles, components and patterns
Get ahead. Stay ahead.
Prezentēja: Aigars Mačiņš, Emergn, Risinājumu arhitektūras prakses vadītājs
Pēc tam bija viena praktiskāka prezentācija, kas runāja par to, cik daudz ir mainījies tas kā uzņēmumi strādā, populārākiem kļūstot AI rīkiem. Detaļas bija visai daudz, bet lielās līnijās viss vērsts uz to, ka uzņēmumi un vispār izstrādātāji kas izmanto AI, var lietas apgūt un iterēt daudz ātrāk:
Laika gaitā tas visticamāk novedīs pie tā, ka tie uzņēmumi kam nav Claude/Codex/Gemini subscription vienkārši atpaliks, nespēs taisīt prototipus, nespēs ātri taisīt jaunus projektus (īpaši startup). Projektu pārvaldes un ieguldījumu sakarā arī uzsvars uz to, ka vairāk jāeksperimentē un jādarbojas iteratīvi, nevis jāizplāno kaut kādi ļoti lielie projekti daudziem gadiem uz priekšu:
Nevajag arī pārsarežģīt, jāskatās kāds risinājums ir spējīgs ģenerēt vērtību, būtībā Minimum Viable Product pieeja. Varbūt pat ne tikai tas, bet arī lielām sistēmām jāskatās kura funkcionalitāte reāli ir vajadzīga, kuru izmanto, cik lielus uzturēšanas riskus nevajadzīgā rada. Būtībā no tehniskās puses to pašu gribētos teikt par arhitektūru un DevOps lietām reizēm:
Vispār interesanti, viņi uztaisīja (būtībā vibe coded) produktu projektu pārvaldībai, palaida tirgū un jau par to pelna naudu: Praxis by Emergn
Par koda un kopējā risinājuma kvalitāti un to biznesa ideju neteikšu pats neko ne labu, ne sliktu, bet pajautājiet sev:
Cik bieži mēs uzņēmumā palaižam paši savus SaaS projektus publiskai lietošanai?
Tas pats Emergn arī ir uzņēmums kurš izskatās ka nodarbojas ar konsultēšanu. Ja viņi var, kas to liedz darīt jums? Ja kādreiz ir kāda laba ideja, kāpēc kavēties? Var kaut ko uzsist gaisā un ļaut tirgum pateikt, labs produkts (un visiem $$$) vai nē (un tad meklēt citus). Tāpēc arī runā par ātriem izstrādes cikliem, nevis liela mēroga ilgajiem projektiem.
Mazāk kaut ko, kas praksē izskatās pēc "waterfall" un vairāk "īsto agile", tostarp arī produktu domāšanu vajag:
Tur var teikt ka AI tehnoloģijas tam visam nebūt nav centrālas, bet vienkārši rīks kas ar to var palīdzēt veiksmīgāk strādāt. Personīgā pieredze arī rāda, ka ar Claude Code varu strādāt pie vairākiem projektiem produktīvi, vairāk gan kā pats, gan kā citi kolēģi. Ja iegulda laiku (un naudu) lai to visu labi atstrādātu, tad lietas lido uz priekšu.
Problēma, par ko tur tik daudz nepastāstīja: nevar būvēt sistēmas slikti un gaidīt ka AI ļaus 10x pavairot produktivitāti.
Sistēmām ir jābūt testējamām. Ja tur ir pliki biznesa loģikas testi kam tomēr vajag celt gaisā veselas lietotnes kontekstu (piem. Spring Boot) jo biznesa loģikas kods ir cieši sasaistīts ar tehnisko risinājumu VAI arī ja ir jātaisa mocki pus lietotnei un nav iespējams testā uzrakstīt dažus objektus ko iebarot savam kodam un testēt to, tad bottleneck ir pats projekts. Vēl sliktāk, ja testi nav vispār un projekts tikai "izskatās" ka strādā un cilvēkiem ir bailes kaut ko mainīt, ja nu salūzt.
Izstrādātājiem ir jāspēj iterēt brīvi, salauzt lokālās izstrādes vides (tādas vajag, ne tikai kaut kādu dalīto DB), eksperimentēt un kustēties uz priekšu. Ja projekts neļauj smuki palaist paralēli 3-10 aģentus dažādiem uzdevumiem, tad bottleneck ir reāli pats projekts. Līdzīgi, ja tur DB shēma ir kosmoss un nav nekādas izstrādātāju dokumentācijas, coding conventions un stila lietas utt. ir viss "jāpatur galvā" un par to tikai kāds kolēģis ar garu baltu bārdu ieminēsies code review laikā, tad bottleneck ir viss izstrādes process.
Vajag dokumentāciju turēt tuvāk kodam, jā, arī visu dīvaino/īpatnējo/sarežģīto/svarīgo kodā dokumentēt ar komentāriem (100% self explanatory code ir būtībā mīts), ieguldīt laiku rīkos - gan publiski pieejamos, visādos formatteros, linteros, code style check rīkos, koda statiskās analīzes rīkos, bet arī automatizēt lietas pašiem ar saviem rīkiem, visu kas ir specifisks projektam. Codegen kur var, savukārt kur nevar tad vismaz kādu harness kas 80% no "Vai šis kods ir ok?" varēs pilnīgi automatizēti pateikt, kas nozīmē ka visi tie paralēlie aģenti uzreiz arī dabūs pa saviem virtuālajiem pirkstiem un būs spiesti kodu rakstīt "labāk", tāpat kā kolēģi.
Tie, kas šo sapratīs un izmantos, lidos. Tie kuriem vides ir kaut kādi manuāli pārvaldīti serveris un Oracle DB ar loģiku ko pat Oracle XE nevar pacelt lokāli, nekādiem README.md vai citiem setup skriptiem un nekādu automatizāciju, tāpat lēnām muļļāsies uz priekšu. Būtībā nekā jauna - slikts kods iešauj kājā kā pašiem, tā AI.
Atvērtība un brīva konkurence valsts pārvaldē. Vai atvērtajai VPS sekos pārējie?
Prezentēja: Edžus Žeiris, Dativa, direktors
Tālāk bija prezentācija par open source, vārdu sakot, uzmanība jāpievērš MK 367: Informācijas sistēmu vispārējās tehniskās prasības
Tur interesantās daļas no likuma ir:
2.2.1. informācijas sistēmas prasības un projektējumu attiecībā uz datiem, par kuru pārvaldību informācijas sistēmas pārzinis ir atbildīgs un kas ir saistoši un noderīgi sabiedrībai un ir klasificēti kā vispārpieejama informācija, veido atbilstoši principam "atvērts pēc noklusējuma", paredzot, ka datus atvērto datu formātā kopā ar metadatiem vai tikai datu kopu metadatus publicē Latvijas atvērto datu portālā https://data.gov.lv (turpmāk – atvērto datu portāls) vai valsts vienotajā ģeotelpiskās informācijas portālā https://geolatvija.lv;
un
2.4.5. izstrādājot jaunas informācijas sistēmas, izmanto atvērtā koda platformas un risinājumus, kuri atbilst mūsdienīgas – modulāras, sadarbspējīgas un informācijas un komunikācijas tehnoloģiju infrastruktūru efektīvi izmantojošas – informācijas un komunikācijas tehnoloģiju arhitektūras prasībām saskaņā ar Vides aizsardzības un reģionālās attīstības ministrijas tīmekļvietnē publicētajām specializētās lietojumprogrammatūras tehnoloģiskās arhitektūras vadlīnijām un kuriem ir demonstrētu pielietojumu vēsture un pastāvīga attīstības kopiena:
Protams, tur vēlāk ir ierastās atrunas kas nozīmē ka šiem punktiem nesekos tik daudz kā vajadzētu, bet saprātīgā pasaulē tas rezultētu:
- atvērto datu portālā būtu arvien vairāk informācija par Latviju pieejama laika gaitā, datu zinātniekiem būtu ko darīt un pētīt
- ja taisām klienta-servera risinājumu, tad pēc default gan jau tas būtu FreeBSD, NetBSD, OpenBSD vai kāda no Linux distribūcijām: nekāds Windows Server ar dārgajām licencēm, būtībā pat kāpēc lai mēs par RHEL maksātu (par nodokļu maksātāju naudu); pat ne tāpēc ka viņi slikti būtu, vienkārši mums nav tik liels mērogs lai to vajadzētu
- ja taisām sistēmu kurā vajag DB, tad pēc default gan jau tā būtu PostgreSQL vai MariaDB (vai nosacīti MySQL) vai SQLite, vai jebkas cits ko var BRĪVI uzcelt kur vajag, cik instancēs, testēšanai, izstrādei un prod, ne dārgās Oracle, vai SQL Server, vai IBM DB2 vai citu risinājumu licences (arī par nodokļu maksātāju naudu)
- tāpat ar teju jebkuru specializēto programmatūru, piemēram Valkey priekš key-value store, RabbitMQ vai NATS priekš ziņojumu rindām, Garage vai SeaweedFS priekš kā S3 saderīga, Apache2 vai Nginx vai Caddy kad vajag tīkla serveri utt.
- vārdu sakot, tiešām brīvība izstrādē, nevis sasietas rokas un lielā naudas tērēšana; tikpat labi par "support" var maksāt pašiem, lai nauda ir LV
- atvērtā pirmkoda programmatūra arī ir ļoti daudz laba, vajag tik viņu spēt izmantot UN dot savu darbu atpakaļ visa projekta uzlabošanai
Tātad, minēja vienoto pašvaldību sistēmu, redz kur vairāk info (ZZ Dats gan pārsauca par Dativa tagad): “ZZ Dats” atver vienoto pašvaldību informācijas sistēmu – turpmāk pieejama zem EUPL atvērtā koda licences
Lielās līnijās domāšana pareizā virzienā, patiesībā lielu daļu valsts un privātā sektora projektu vajadzētu pie reizes padomāt arī izplatīt tālāk, vai ko nevar uztaisīt tā, ka var pārdot, piemēram tiem pašiem Igauņiem vai Lietuviešiem, vai citām EU valstīm:
Līdzīgi arī ar izstrādes valodām, runtime, satvariem un bibliotēkām, būtībā visu; reāli neredzu iemeslu kāpēc nevarētu aiziet soli tālāk un pateikt ka visi tagad kodu liks uz kāda git.gov.lv (uzcelt lielu GitLab vai Gitea vai Forgejo instanci gaisā) savām sistēmām un katrs Latvijas iedzīvotājs kas par to sistēmu ar saviem nodokļiem maksā varēs pieslēgties un izstrādātājiem submitot pull request, kad atkal sistēmās ir bugi un lietas nestrādā. Līdzīgi ar drošības caurumiem, labāk tos pamanīt drošības speciālistiem un taisīt responsible disclosure, nevis Krievijas hakeriem.
Prezentāciju klausoties, gan palika nedaudz dīvaini:
Ievērojāt problēmu? Preses relīze ir, stāsta ka open source... a kur ir kods? Kur ir jūsu Git repo, vai GitHub links? Te laikam konkrētā iniciatīva sabrūk jo meklēju GitHub un atradu tikai šos:
Tajā rakstā augstāk komentāros cilvēki arī zobojas:
Publiskā licence nenozīmē, ka viss ir izlikts publiski. Publiski ZZdats ir izlikts tikai LX – Vue.js freimworks. To gan jebkurš var gan lietot, gan piedāvāt savus papildinājumus. Es tās sistēmas esmu redzējis – tas, ka no ārpuses tas viss saucas Vienotā pašvaldības sistēma, nenozīmē, ka tur apakšā ir viena megasistēma. Vienots ir tikai logins, kamēr apakšā ir ašpadsmit dažādas sistēmas no 30 gadus vecām EXĒm līdz jaunām un svaigām web un mobilajām aplikācijām.
Izklausās pēc atrunām.
FSF pasaka skaidri:
A program is free software if the program's users have the four essential freedoms:
The freedom to run the program as you wish, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help others (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Tātad, tu nevari teikt "atvērtais pirmkods", ja tas kods tiem kas sistēmu izmanto vai saņem tās pakalpojumus nav pieejams.
Pat viņu izvēlētā EUPL licence to pasaka skaidri:
The Licensor may provide the Work either in its Source Code form, or as Executable Code. If the Work is provided as Executable Code, the Licensor provides in addition a machine-readable copy of the Source Code of the Work along with each copy of the Work that the Licensor distributes or indicates, in a notice following the copyright notice attached to the Work, a repository where the Source Code is easily and freely accessible for as long as the Licensor continues to distribute or communicate the Work.
un tālāk:
Provision of Source Code: When distributing or communicating copies of the Work, the Licensee will provide a machine-readable copy of the Source Code or indicate a repository where this Source will be easily and freely available for as long as the Licensee continues to distribute or communicate the Work.
Ko tur nozīmē tā saziņa? Vienkārši, līdzīgi AGPL:
— ‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person.
Tātad, visi kurus skar tā pašvaldību sistēma ir pelnījuši piekļuvi pirmkodam. Man šķiet tie puiši paziņoja ka tagad ir atvērtais pirmkods, bet ja nav piekļuve tam kodam, tad ir liela iespēja ka šobrīd paši pārkāpj licences noteikumus un tiem neseko, vienalga kā to centīsies pasniegt. Nevar paņemt un tā pārdefinēt labi zināmus terminus, lai tie nozīmētu kaut ko pavisam citu, tikai tāpēc, ka pašiem tā ir ērtāk.
Datu centri: Kritiskā infrastruktūra, kuras nozīmi un ietekmi uz nākotni mēs nenovērtējam
Prezentēja: Pēteris Elksnis, Lailio, izpilddirektors
Bija arī prezentācija par datu centriem, vārdu sakot, tur ir prātam neaptverami ieguldījumi:
Pašsaprotami ka tekošajā AI ērā ir daudz enerģijas patēriņš tieši GPU, kā arī dzesēšanai:
Izskatās, ka tas tikai aug plašumā. Izskatās ka ja tas "burbulis" kādreiz plīsīs, tad varētu globālo ekonomiku paraut līdzi aptuveni kā 2008. gadā:
Tam vajag ļoti daudz elektrības, savukārt vairumā valstu tam vienkārši nav pietiekami liels tīkls, lai to visu paceltu:
Bija ļoti interesants salīdzinājums ar naftu, šobrīd datu centri (drīzāk gan GPU compute, nekā dati) ir ar lielākiem ieguldījumiem:
Latvijā, savukārt, ir mazāka mēroga projekti, dēļ ierobežojumiem:
Tajā pat laikā minēja arī riskus saistībā ar centralizāciju:
Viens no komentētājiem teica ka izklausās "šizofrēniski" jo iepriekš runāja par vienotu pieeju izstrādei un pārizmantošanu bet šajā prezentācijā atkal par to ka vajag vairākus piegādātājus utt. - moderators to jautājumu gan nepacēla, jo visticamāk nebija īsti pieklājīgi uzrakstīts.
Es gan pacelšu - ja ir SSO tikai ar vienu piekļuvi (piem. Latvija.lv) tad tas ir masīvs single point of failure. Ja tur piekabina klāt eParakstu, Smart-ID, internetbankas un varbūt vēl kaut ko, tad uzreiz ir labāk. Tā arī ir galvenā doma tam, ka vairāki provideri ir labāk. Papildus tam, pat ja ir viena platforma, viņu var taisīt ar High Availability pieeju (HA), lai pat ja nobrūk vesels datu centrs, lai risinājums vismaz ar ierobežotu kapacitāti turpinātu strādāt.
Kāpēc Latvijā sistēmas joprojām brūk? Lielās līnijās:
A) nemāk uztaisīt HA sistēmas, nav kompetences, savukārt tie kam ir nestrādā valsts sektorā, bet pie tiem kas daudz maksā
B) nav budžets ko ieguldīt, lai to uztaisītu kārtīgi, vai arī ir izdomāti fake deadline un nav laiks
C) šķērdē skaitļošanas resursus ar sliktām arhitektūrām un sliktām realizācijām, vecām pieejām utt.
Esmu pats redzējis sistēmas kas nobrūk pie 400 RPS, lai gan paskatoties ko citi spēj dabūt gatavu, tas nav labākais ko moderni dzelži spēj.
Tas ir tas pats, kāpēc daudzi raksta kodu ar N+1 problēmām (vieglāk acīmredzot, vai arī nav rīki kas to noķer), kāpēc nemāk izmantot vai vienkārši netaisa slodzes testus ar tādiem rīkiem kā K6 (vai neuzraksta savējos, jo jāatzīst ka K6 support WebSocket ir slikts), kā arī sataisa sistēmu arhitektūras kas vienkārši nav mērogojamas. Līdzīgi, industrijā rakstām nevis normālu desktop programmatūru arī, bet shippojam Electron lietotnes kas ir vesels pārlūks lai atrādītu UI, un pat OS šķērdē resursus pa labi un pa kreisi.
No vienas puses, jāatceras: Wirth's law
No otras puses, ok, nesaku ka katra sistēma ir jāraksta Rust vai baigi jātestē visas no viņām. Reizēm pietiek kaut ko sasviest kopā Ruby vai Python, vai pat neuzrakstīt optimālu kodu Spring Boot vai ASP.NET lietotnē un galvenais lai strādā - bet ir atšķirība, vai sistēmai būs varbūt 100 lietotāji, vai arī 1'000'000. Tam ievērojami jāietekmē gan arhitektūru, gan arī izstrādes un testēšanas procesu. Vienkāršām sistēmām, savukārt domāt par tādu scaling reāli ir laika tērēšana. Tik uzmanāmies, ka sistēma no vienas kategorijas nepārvēršas par otru, tad ir auzas.
MI kā automatizācijas instruments kiberdrošības nodrošināšanā
Prezentēja: Juris Pūce, PEAKDEFENCE, partneris
Bija arī prezentācija par pašu LLM pielietojumu, par modeļiem, kas lielās līnijās atbilst paša pieredzei:
Apskatīja arī pieeju par kuru domāju pats, piemēram, kāds lokālais Qwen modelis apstrādā uzdevumu, bet ar EuroLLM pārtulkot Latviski pareizi (te pat JSON nevajadzētu, būtībā var no viena modeļa uz otru datus stumdīt, tikai harness vajadzētu):
Un protams, arī runāts par datu kvalitāti un formātu, lai nebūtu variants "garbage in, garbage out":
Ko tas nozīmē katram kurš grib lokāli laist LLM un kāda ir mana pieredze?
Sakarīgākais jautājums:
Vai Tev ir aptuveni 100'000 EUR ko ieguldīt dzelžos?
Ja atbilde ir jā, tad varēsi pacelt vidēja lieluma modeļus (>200B) ar labu precizitāti un kontekstu, un gan jau tikt sveikā cauri dažādiem uzdevumiem ar normālu ātrumu. Ja atbilde ir nē, tad nāksies izvēlēties arvien vairāk kompromisu: mazākus modeļus (kas ir derīgi tikai specializētiem uzdevumiem, un ne pārāk sarežģītiem), kvantizētās versijas, mazāki konteksta izmēri, sliktāka veiktspēja. Tas nenozīmē ka ar tiem nevarēs izdarīt neko, pat ar Qwen klases 35B MoE modeļiem uz parastas aparatūras var dabūt aptuveni 40-60 tokenus/sekundē un veikt plānveidīgus uzdevumus... bet tie nekad nebūs tik labi kā mākoņmodeļi.
Var skatīties uz visādām kastēm ar "unified memory", bet viņas būs lēnas. Var skatīties uz mazākas jaudas GPU, piemēram Nvidia L4 lai nebankrotētu, kamēr MoE apmierina. Var arī skatīties uz augšu un sapņot par investīcijām lai dabūtu vēl vairāk naudu un tādus dzelžus ar kuriem varētu palaist GLM 5.1 modeli: unsloth/GLM-5.1-GGUF kam pat 4 bitu kvantizētajā versijā vajadzētu aptuveni 465 GB atmiņas + vēl KV cache pa virsu + vēl compute un bandwidth saziņai (tostarp NVLink vai tml., ar PCIe būtu bottleneck).
Un tad uzreiz ir otrs jautājums:
Bet vai vajag?
Man šķiet daudziem uzņēmumiem pieeja AI, un pieeja ar ko ir grūti strīdēties, būs:
"Our AI solution is just a cloud version of GPT-5.X in a trench coat."
Un ziniet kur ir patiesība? Tiem, kas izvēlēsies to pieeju būs labāki iznākumi, jo lokālie modeļi bez ievērojamām investīcijām nekad nekonkurēs ar tiem mākoņmodeļiem.
Tie kas izmanto Codex, vai Claude Code, vai Gemini CLI / Antigravity vai jebko citu iegūs daudz vairāk spējas, nekā tie kuri izmantos sliktus modeļus sarežģītiem uzdevumiem. Tie kas kontrolē tos datu centrus un platformas, lielā mērā kontrolē spējas tiem, kas AI arī izmanto - un agrāk vai vēlāk, tas gan nozīmēs to, ka viņi uzskrūvēs cenas un samazinās usage limits dažādiem subscription... un tas joprojām būs lētāk kā censties visu laist lokāli.
Pēkšņi tā naftas analoģija nav nevietā, īpaši ja apdomājam ģeopolitiku: mums vispār no AI lielajiem uzņēmumiem Eiropā ir kas... Mistral? Labi ka viņi ir, bet kaut kā vajadzētu vairāk, īpaši pēdējā laikā apzinoties, ka ASV nebūt vienmēr nav draugi, kas gribētu mums visu to labāko.
Could public cloud be considered as AI accelerator?
Prezentēja: Bogdans Jarbuss, Accenture, prakses vadītājs
Tajā pat laikā, AI pielietojums EU pieaug:
Un ierobežojumi ir tie ko minēju, papildus kam klāt nāk visādi līgumi un to ierobežojumi, neesošas kompetences, slikta datu pārvaldība un "legacy" sistēmas, kā arī nav iniciatīvas vai līdzekļi eksperimentācijai:
Tādā ziņā Latvija tomēr atpaliek no citām EU valstīm, bet par laimi tomēr ir uzņēmumi kuriem ir iniciatīvas, kas cenšas saprast kā un kur tehnoloģijas var pielietot, un kādas:
Paneļdiskusijas
Tam visam sekoja arī paneļdiskusijas, šeit viņas apkopošu vienuviet, un padalīšos ar savām domām.
Par to, kādā līmenī valstī ir dzelži, dzirdēju aptuveni:
"LVRTC ir 10 statnes ar Nvidia kartēm, līdz gada beigām būs 20."
Un dažus teikumus vēlāk:
"Darba vidē to bieži vien vispār nenodrošina, pat ne lokālos rīkus."
Vārdu sakot, LVRTC to GLM 5.1 gan jau dabūtu gaisā, bet tāds prieks ir reti kuram uzņēmumam IKT sfērā, kā arī daudzi vispār nenodrošina pat minimumu - kas noved pie tā, ka kopē privātos DeepSeek un līdzīgu AI kontos. Liek datus ko nevajadzētu iekšā mākoņrīkos, ko nevar izkontrolēt (AI platformas arī ir daudz) un ko visticamāk nevarēs izkontrolēt.
Lokālos modeļus mēģina laist un lietot daudzi, bet pat lieliem uzņēmumiem neiet pārāk labi - visiem vairāk patīk mākoņmodeļi, pat ar to pašu programmatūru. Uzņēmumiem ar to ciešas integrācijas, reizēm būvē risinājumus kur runā ar publiskajiem modeļiem bet laiž pieprasījumus caur savu infrastruktūru no sākuma, lai varētu vismaz noauditēt. Sava veida hibrīdais modelis.
Protams, piemēram, maksāt par Anthropic modeļiem per-token (AWS Bedrock, vai viņu API pa taisno, vai OpenRouter utt.) vienmēr būs dārgāk kā paņemt viņu subscription: praksē atšķirība varētu būt 10-20x. Ja tu vari par 100 USD paņemt uz mēnesi subscription, tad tos limitus sasniedzot ar pieeju kur maksā par tokeniem, tie drīzāk būtu 1000 EUR, jo uzņēmumi subscription servisus paši subsidizē.
Tajā pat laikā, laba ideja bija Pēterim Jurčenko (Piekļūstamības eksperts, Balsu talkas aktīvists): ieteikums katram paņemt un pamēģināt Claude Code (vai Cowork), Codex, vai līdzīgos risinājumus.
Viņiem uzņēmumā bija pieeja, kur reizi nedēļā pārrunāja, kādas lietas ar AI var novienkāršot un uzlabot, kādas problēmas atrisināt. Kad to sāka darīt, tad tam aizgāja varbūt 7 minūtes, bet kā stāstīja, tagad jau tās ir 40 minūtes - jo ar modernajiem rīkiem un modeļiem, tiem ir ievērojamas spējas.
Ļoti kodolīgi (aptuveni ko teica):
"Nav tā ka uzņēmumi un iestādes ar lieliem projektiem nevarētu atļauties Claude Code subscription."
Tur arī uzradās skeptiķis, Egils Rupenheits (ESET kiberdrošības speciālists):
"Nav tā ka visu tie rīki izdarīs, viņi nav bez robežām."
Te gan gribētu pielikt savas domas: nevienam no tiem rīkiem nevajag kosmosu. Vajag lai tie rīki var spēt realizēt uzdevumus:
- pietiekami labi
- pietiekami ātri
- pietiekami lēti
Man šķiet ka nevaram ignorēt to ka tuvākajos 10 gados daudzi zaudēs savu darbu, jo kapitālistiskā sistēmā daudzi uzņēmumi izvēlēsies viņus aizstāt ar AI, pat ja kvalitāte nebūs ideāla, tad šiem uzņēmumiem tā būs pietiekami laba. Citi atkal nevarēs konkurēt ar tīro darba apjomu, kuru var paveikt ar AI, ja paši to neizmantos - no vienas puses tas palielinās konkurētspēju un produktivitāti visiem, kam tā tehnoloģija ir pieejama, no otras puses, iespējams devaluēs darbu. Īpaši saistoši cilvēkiem kas raksta saturu, tulko, transkribē video/audio, kā arī dažāda veida māksliniekiem un jā - arī programmētājiem.
Tas ir aptuveni tāpat, kā kāpēc maksāt 150'000 EUR gadā par ASV izstrādātāju, ja var par tādu naudu paņemt veselu offshore veselu komandu. Tur vēl ir kultūras un komunikācijas jautājumi - bet AI gadījumā, modeļi kļūst labāki, viņš nekad neguļ, viņš nenogurst, viņš labi seko instrukcijām. Programmētājiem tas var būt sava veida spēju vairotājs, bet tajā pat laikā no izglītības iestādēm nāks ārā cilvēki kuri pa īstam to saturu nav iemācījušies, bet arvien vairāk ir prasījuši AI. Tāpat, jāskatās uzmanīgi kas būs ar jaunajiem izstrādātājiem - no vienas puses, kompānijas varbūt mazāk tādiem pievērsīs uzmanību jo produktivitāte visiem pārējiem pieaugs, bet no otras puses arī jaunie izstrādātāji varētu "sist uz augšu" vienu soli, jo AI var palīdzēt nepieļaut dažādas kļūdas (kamēr modelis ir pietiekami labs un nesaka visu laiku "Yes, you are absolutely right!" par muļķībām) un darīt vairāk, kā viņu pašu prasmes ļautu.
Vārdu sakot, ir risks drusku nosliekties distopijas virzienā, bet runājot par pašu produktivitāti, kad rīku un modeļu kombinācija mums iedod "good enough" kvalitāti, tad skats uz konkrēto industriju mainās. Man šķiet programmētājiem tieši tādas izmaiņas bija 2025. gada beigas un kad iznāca Opus 4.5 modelis, ko kombinācijā ar atbilstošu rīku nodrošinājumu un kontroles metodēm var pataisīt par efektīvu kolēģi - kamēr es rakstu šo te postu, man viņš fonā jau 3 projektos uztaisīja refaktoringu, pēc mana plāna, kā arī palaida visus sakonfigurētos koda kontroles rīkus, salaboja kļūdas, palaida 3 paralēlas review sub-aģentu iterācijas, cikliski salaboja visas atrastās problēmas, līdz viss ir pieņemamā stāvoklī.
Par pašu paneļdiskusiju runājot, atkal labi ka drusku izteica abu veidu argumentus, gan par, gan pret - jo lai gan konfliktējoši viedokļi, nevajag no tā baidīties, un taisnība bija abiem. Arī tas pats Egils Rupenheits atgādināja, ka lokālo modeļu kvalitāte varētu arī noteiktiem uzdevumiem nebūt "good enough". Tātad, pie tā vēl jāstrādā, jāgaida kamēr modeļi kļūs labāki (piem. var salīdzināt Qwen 2.5 un Qwen 3.5 un vispār cik liels progress notiek gadu mijā), kā arī jāstrādā pie inženierijas - kā jau teicu, pat ja ir spējīgi modeļi, lai nebūtu vibe coded sviests, tāpat vajag testus un veidu kā kodam piespiest izskatīties un strādāt tā, kā mēs to gribam.
Kā pašiem izmēģināt AI tehnoloģijas
Papildus tam, ja nu kāds grib palaist kādu modeli lokāli arī, te būs īsās instrukcijas no manas puses. Tas gan nebūs production use case, bet vairāk pašu interesei.
No sākuma vajadzēs programmatūru lai modeļus laistu, piemēram Ollama.
Kad tas ir uzinstalēts, tad var paskatīties kādi modeļi interesē: Models
Lokālām ierīcēm tie varētu būt MoE (mixture of experts, aktivizē tikai daļu neironu) modeļi un pēc izmēra nelieli: piemēram Qwen 3.6, Gemma 4, Qwen 3.5 (ir mazākas versijas kā 3.6), GLM 4.7 Flash, Devstral Small 2.
Kad modelis ir izvēlēts, tad atliek sekot Quickstart instrukcijām.
Ar mazajiem modeļiem caur API gan vairums programmatūras izstrādes rīku strādās visai slikti, man labākā pieredze bija tieši ar Cline, RooCode un KiloCode (būtībā vairāki fork sākotnējam projektam ar savām fīčām), praksē labāk nekā OpenCode, jo vairāk pabiksta modeli pareizajā virzienā. Iesaku paņemt un uz Visual Studio Code viņus uzstādīt, paskatīties vai caur Ollama API strādā ok.
Papildus tam, ja nu gribas ko automatizēt, var paņemt arī LiteLLM bibliotēku priekš Python, strādās labi.
Galvenais ko saprast: svarīgi ir nevis paši modeļi, bet gan tas ka OpenAI saderīgo API (kad pārejat no Ollama API uz to, agrāk vai vēlāk; pats Ollama atbalsta abus) varēs saslēgt arī mākoņmodeļiem pēc vajadzības. Vārdu sakot, modelis ir kaut kas ko pēc vajadzības var mainīt, piemeklēt kas ir konkrētam uzdevumam piemērots un pašiem pa makam.
Ja nu gribas laist ko glaunāku par Ollama, te būs daži atslēgas vārdi: LM Studio, llama.cpp, vLLM.
Un ja vajag vairāk GGUF formāta vai jebkāda cita formāta modeļus, redz kur saits: HuggingFace - Models compatible with the GGUF library
Konkrētāk, ļoti labas kvantizētās versijas ir Unsloth.
Savukārt, ja gribat vienkārši paskatīties kā strādā State of the Art (SOTA) modeļi, tad redz kur, var paņemt ~20 USD (ar šo gan varētu būt par īsu) vai 100 USD subscription: Claude Pricing
Ir arī lētākas opcijas, piemēram GLM 5.1 varat sameklēt, bet arī daļa no šī pēc gada vai diviem varētu būt out of date.
Kopsavilkums
Kopumā konferenci labi paklausīties, redzēt ka Latvijā arī kaut kas notiek, vienīgais ka tā nākotne tāda neskaidra paliek.
Visi ignorēja grūtos jautājumus, tādi optimistiski paši, par to problēmu ka AI tehnoloģijas mēs paši bieži nekontrolējam (un kad kontrolējam, nekonkurējam) neviens īsti nerunāja.
Bet no otras puses, tas pasākums arī ir sava veida marketing padarīšana, nevar gaidīt ka tur būtu īstā vieta vai laiks izcilāt sarežģītos jautājumus.
Other posts: Previous »