DoX CMS -sisällöt ja paikalliset kielimallit

Ovat suuret kielimallit sitten aikamme suurin vedätys tai uusi teollinen vallankumous, eivät ne ole juurikaan avuksi ilman pääsyä teidän omiin sisältöihinne. Toisaalta harva asia on yhtä vaarallista tietosuojan kannalta kuin salatun tiedon vuotaminen julkisen kielimallin käyttöön. Eikä näiden kielimallien toimittajien lupauksiin koskien tietojen käyttöä valitettavasti voi luottaa lainkaan. Tämä on selvää kaikkien koulutussisältöjä koskevien oikeudenkäyntien vuoksi. Täten esittelen täällä joitakin ajatuksia ja ehdotuksia koskien DoX CMS:ssä kirjoitettujen sisältöjen parhaita hyödynnystapoja osana paikallisia kielimalleja.

Olen käsitellyt generatiivisen tekoälyn käytön mahdollisuuksia aiemmin täällä. Henkilökohtaisesti olen skeptikko koskien näiden järjestelmien kannattavuutta ja pitkän aikavälin skaalautuvuutta. Hyväksyn kuitenkin niille löytyvän myös aitoa lisäarvoa tuovia käyttötapoja osana normaaleja työnkiertoja.

Paikalliset kielimallit

Useimmille tutut kielimallit kuten ChatGPT ja Claude ovat omilla palvelimillaan pyöriviä pilvipalveluita. Tällöin niiden käsiteltäväksi annettu sisältö siis lähetetään kyseisille palvelimille, jolloin on vaikea selvittää, pidetäänkö sitä saatavilla kyseisten mallien jatkokoulutukseen. Vaikka julkisesti saatavilla oleva dokumentaatio on monin tavoin hyödyllistä kaikille osapuolille, kaikkea sisältöä ei ole tarkoitettu kenen tahansa saatavilla olevaksi. Myös julkisesti julkaistavaksi tarkoitetun sisällön jakelu ja versionhallinta halutaan normaalisti pitää omassa hallussa.

Julkiset kielimallit eivät siis usein ole käyttöön soveltuva tuotannon apuväline. Luottamuspula niitä kohtaan on vaikea korjata pelkillä lupauksilla, kun samat toimijat taistelevat poistaakseen kaikki koulutuskäytön rajoitteet.

Ratkaisu tähän ongelmaan ovat paikalliset kielimallit, jotka eivät siirrä käsittelemäänsä sisältöä ulospäin.

Paikallisille kielimalleille löytyy erilaisia toteutuksia, enkä tule käymään läpi kaikkia näitä vaihtoehtoja. Keskityn täällä yleisiin periaatteisiin ja käytän esimerkkien tukena GPT4ALL-käyttöliittymää ja sen tukemia pohjakielimalleja. Tällaisia malleja löytyy esimerkiksi Mistral ja Falcon -perheistä. Ne eivät kuitenkaan ole ainoat vaihtoehdot, vaan sopivia ratkaisuja voi tarvittaessa etsiä Hugging Face -tietokannasta.

Pystytys

Paikallisten mallien käyttöliittymäalustoilla kuten GPT4ALL tai Ollama on omat asennustiedostonsa. Kohtasin itse erillisen ongelman, joka esti asennuksen jälkeisen käyttöönoton. Windows-laitteella tämä ratkesi asentamalla viimeisin versio Microsoftin C++ Redistributable -kirjastosta.

Asennuksen jälkeen ainakin GPT4ALL vaatii sekä käytettävien mallien asentamista että käytettyjen paikallisten kansioiden määrittämistä. Lisäksi ohjelmiston asetuksissa täytyy sallia enemmän tiedostotyyppejä ja malleille on syytä lisätä niiden käyttötarkoituksia vastaavat pohjakehotteet.

Tiedostotyypit

GPT4ALL-ohjelmiston asetuksien paikallistiedostoja koskevan osuuden ensimmäinen kenttä määrittää käytettävissä olevat tiedostotyypit. Näiden tiedostotyyppien päätteet täytyy erottaa toisistaan pilkuilla. Alla ehdottamani käyttötavat vaativat tiedostotyyppien XML, DITA, DITAMAP, CSS, MOD, DTD ja XLSX lisäämistä sallituiksi tiedostotyypeiksi.

Versiointi

Yksi kielimallien ongelmista on niiden kiinnittyminen aiempiin käytänteisiin. Tämä liittyy pääasiassa niiden toiseen koulutusvaiheeseen omien sisältöjenne avulla. Ainakin GPT4ALL sallii tosin valita tilannekohtaisesti upotettavat tiedostojoukot. Tällä tavoin voit erottaa aiemmat versiot omiksisi upotettaviksi kokonaisuuksisteen ja valita ne käyttöön ainoastaan tarvitessasi niiden mukaisia muotoilun suosituksia.

Käytännössä suositukseni tätä varten on eri versioiden erottaminen omiin paikallisiin kansioihinsa. Nämä kansiot voi tallentaa ilman erillistä kirjautumista saatavilla olevalle verkkoasemalle, jotta ne ovat kaikkien niitä tarvitsevien käytettävissä. Ne tulee jokainen tämän jälkeen määrittää omiksi upotettaviksi sisältökokonaisuuksikseen. Näitä kokonaisuuksia voi sitten yhdistellä senhetkisen käyttötarpeen mukaan.

Suosittelen versioimaan myös näille malleille annettavat pohjakehotteet. Tällä tavoin niitä voi kehittää iteroiden ja erottaa tehtäväkohtaisesti ilman pelkoa aiempien versioiden tuhoutumisesta. Nämä kehotteet voi esimerkiksi tallentaa TXT-tiedostoihin käytetyn alustan ulkopuolella. Ne voi sitten kopioida ja liittää sieltä mallin käyttöön.

Pohjakehotteet

Pohjakehotteet ovat jokaiseen mallille lähetettävään pyyntöön lisättäviä ohjeita. Niihin löytyy yleisluontoisia ohjeita esimerkiksi täältä. Esimerkiksi Mistral tarjoaa myös omat kehotteita koskevat ohjeensa. Tämä kattaa myös heidän malleilleen annettavat pohjakehotteet.

DoX CMS:n kautta tuotettujen sisältöjen läpikäyntiin soveltuva pohjakehote vaatii ainakin määritelmät DoX CMS:n eri komponenteille (muuttuja, tagi, elementtiluokka, yms.). Tällä tavoin voit viitata näihin käsitteisiin kysymyksissä mallille, kun haluat sen käyvän läpi raakamateriaalia. Tässä ovat oman tämänhetkisen kehotteeni määritelmät. Niitä voi parantaa ja sovittaa omaan käyttöönne.

# Definitions
- variable: inline content that replaces related parts designated with two pairs of curly parentheses
- tag: identifier and XML attribute (data-doxattribute-) used to filter content in publications (do not mix with XML tags)
- element class: XML attribute (doxelementclass) used to add exceptions to general styles to those elements or their child elements
- topic tree: same function as DITAMAP files, a list of hierarchically organized topics from which you filter out unrelated parts for a publication
- localized image: BLK files that add the correct images for different languages to the <img> elements with Href values that link to them

Lisäksi käytetyn pohjakehotteen on syytä kattaa seuraavat tiedot:

• kielimallin roolitus,
• haluttu käyttötapa,
• käytön rajoitteet,
• ohjeet epävarmuuden ratkaisemistavoiksi,
• vastauksien muotoilun ohjeet ja
• esimerkkejä kehotteista ja vastauksista niihin.

Annettujen määreiden täytyy olla mahdollisimman kvantitatiivisia ja sidottuja mahdollisimman yksiselitteisiin ja helposti käsiteltäviin suureisiin. Esimerkiksi sanamäärän sijaan on parempi käyttää pituuden ehtona merkkimäärää tai polettimäärää (token), koska nämä ovat kielimallin kannalta yksiselitteisempiä laskelmia. Sanojen valitulla kielellä keskimääräisen pituuden perusteella on mahdollista laskea likimääräinen merkkimäärä, joka vastaa haluttua sanamäärää. Samoin ’parempi’ ja vastaavat kuvaukset vaativat ehtoja kuten luettavuuden rajaamisen halutulle tasolle PIAAC-mittarilla.

Rajoitteet

Paikalliset kielimallit ovat rajoittuneempia kuin erikoistuineilla palvelimilla ylläpidetyt palvelut. Saatavilla olevat pohjamallit ovat yleisesti ottaen pelkistetympiä, jotta ne olisivat käytettävissä myös kuluttajatason tietokoneilla. Samoin tietenkin käytettävissä olevat tietokoneet varsinkin yrityskäytössä ovat usein merkittävästi heikompia kuin olisi ihanteellista kielimallien kannalta. Jos käyttäjän vastuualueisiin eivät kuulu 3D-mallintaminen ja videotoimitukset, hänen työkoneessaan on tuskin kovin kehittynyttä näytönohjainta. Kannettavan koneen muistin määrä ei myöskään usein ole ihanteellisella tasolla parhaiden tuloksien saavuttamiseksi.

Tarvittaessa tästä rajoitteesta voi yrittää päästä yli ylläpitämällä erikseen paikallista palvelinta, jolle eri käyttäjät voivat lähettää pyyntönsä. Tällainen vaihtoehto ei ole halpa toteuttaa, mutta useamman käyttäjän ympäristössä se on merkittävästi edullisempi kuin jokaisen käyttäjän päätelaitteiden päivittäminen paikallisten kielimallien käytön tukemiseksi. En kuitenkaan käy täällä tarkemmin läpi paikallisen palvelimen pystyttämisen yksityiskohtia.

Kielimallit ovat myös lähtökohtaisesti osittain arvaamattomia. Niille pohjakehotteessa annetut ohjeet eivät ole ehdottomia. Koska kielimallin tulokset ovat riippuvaisia kaikista toistaiseksi keskustelluista tekijöistä eli valitusta mallista, annetusta pohjakehotteesta ja laitteiston soveltuvuudesta, voi tällainen käytös johtaa kalliiseen selvityskierteeseen. Lisäksi tuloksiin vaikuttaa tietenkin myös niille syötetty sisältö ja käyttäjän kehotteiden muotoilu. Eikä mikään takaa, että tällainen selvitys johtaa parempiin tuloksiin. Kuten sanoin, tällainen kielimalli on lähtökohtaisesti arvaamaton.

Tällöin on tärkeää ensin lähestyä ongelmaa järjestelmällisesti käymällä läpi jokainen mahdollinen syy yksi kerrallaan. Samalla täytyy olla valmis hyväksymään, että mallia ei välttämättä saa pakotettua ruotuun. Tämä ei ole ongelma, jonka pystyy ratkaisemaan pelkästään paremmin muotoilluilla kehotteilla. Yksityiskohtaisemmat kehotteet vaativat enemmän laskentatehoa, mutta pelkkä laskentatehon nostaminen niiden tueksi ei takaa haluttuja tuloksia. Kyseessä on oravanpyörä, josta pois nouseminen voi olla vaikeaa. Tyydyttävien tuloksien saavuttaminen voi olla tai olla olematta mahdotonta. Lisäksi houkutusta jatkaa yrittämistä lisää kaikki tämän eteen jo nähty vaiva. Joskus täytyy tosin vain hyväksyä, että kielimallista ei ole ihmeisiin – tai edes pieneksi avuksi halutuissa tehtävissä.

DoX CMS -sovitukset

En kirjoittaisi tästä aiheesta ilman sanottavaa tavoista, joilla DoX CMS tukee paikallisten kielimallien käyttöä sen avulla kirjoitettujen sisältöjen käsittelemiseen. Kyse ei ole virallisesta kielimallituesta, mutta myös ennestään saatavilla olevat toiminnot auttavat oikein käytettyinä.

Metadata

Tekstieditorin prolog-kenttä antaa lisätä sisältöihin data-elementtejä. Kielimallit hyötyvät tällä tavoin lisätystä metadatasta, joka antaa kontekstiä kunkin otsikkosisällön merkitykselle. Esimerkiksi nämä metadatan muodot voivat auttaa kielimalleja löytämään oikeat sisällöt käyttäjien kehotteiden perusteella:

• Vuosimalli: Ajankohta, milloin kyseiset sisällöt on kirjoitettu.
• Sisällön rooli: Lyhyt kuvaus sisällön tyypistä kuten onko kyseessä ohjeistus.
• Avainsanat: Aihetunnisteita ennalta määritetyltä listalta.
• Kuvaus: Vapaa kuvaus kielimallin ja muiden käyttäjien tueksi.

Vapaita kuvauksia kielimallia varten voi myös upottaa eri elementteihin kommentteina. Samoin eri elementtien ID-arvot voi valita kuvaaviksi, jotta kielimalli kenties käsittelee niitä helpommin.

Sisällön muodot

DoX CMS antaa tuoda ulos muutakin kuin valmiita julkaisuja. Näitä muita sisällön muotoja voi käyttää esimerkiksi kontekstina kielimallin antamalle palautteelle. Lisäksi siltä voi kysyä palautetta myös raakasisältöjen muotoiluun.

Valmiit julkaisut ovat tietenkin kaikkein selvin esimerkki kielimallin käyttöön annettavasta sisällöstä. Niissä on jo tehty erillisten komponenttien yhteenveto, jolloin kielimallilla on pienempi mahdollisuus kohdata osuuksia, joita se ei kykene käsittelemään.

PDF

PDF on edelleen ensisijainen julkaisujen toimitusmuoto ja kielimallit ovat pääasiassa varsin kykeneviä lukemaan niitä. Ne eivät kuitenkaan sovellu kaikkeen, koska esimerkiksi muotoilua koskeva tieto ei tällöin ole luettavissa suoraan CSS-muotoisena.

PDF-syöte kielimallille antaa sen käyttöön varsinaisia toimituksia suoraan vastaavan sisällön (kun toimitukset tehdään tässä muodossa). Tämän tiedostomuodon helppo luettavuus voi myös auttaa kielimalleja toimitettavaksi katselmoitavan tai jo hyväksytyn kyseisiä tuotteita koskevan sisällön käsittelyssä.

DITA

DITA on toimitusmuodoista lähiten raakasisältöä vastaava, mikä voi auttaa kielimalleja yhdistämään suhteen raakasisällön ja toimituksen välillä. Jos sen saa tällä tavoin esimerkiksi yhdistämään conref-merkityt osuudet ja niiden lähdeversioiden sisällöt, olisi kyseessä suuri apu sisältöjen katselmoinnin osalta. Oletusarvoisesti nämä osuudet raakasisällössä tulevat käsitellyiksi ainoastaan tyhjinä, conref-arvollisina elementteinä, mikä jättää kielimallin käsiteltävänä olevaan raakasisältöön aukkoja. Ne eivät vaikuta pääasiassa olevan kykeneviä käsittelemään conref-arvollisia osuuksia kuin ne sisältäisivät lähdeversion sisällön edes, kun lähdeversio on osa samaa käsiteltävää sisältökokonaisuutta.

Tämän julkaisumuodon selvä etu ovat kuitenkin, kuinka niissä on mukana DTD- ja DITAMAP-tiedostot. Suosittelen vähintään lisäämään DoX CMS:n käyttämän DTD-tiedoston paikallisen kielimallin käytettävissä olevaan tiedostojoukkoon. Tällä tavoin on epäluultavampaa, että se suosittelee sallitun formaatin vastaisia muutoksia kuten kuvakehyksen (fig) lisääminen perustaulukon (simpletable) sisään.

DITA-julkaisujen etuihin lukeutuu myös, että niissä julkaistu sisältö pysyy paloiteltuna erillisiin tiedostoihin. Tällä tavoin nämä osuudet voi erotella useiksi tiedostojoukoiksi purkamalla kyseisen julkaisun. Näitä toisistaan irrotettuja osuuksia voi käyttää aihekohtaisiin kyselyihin ilman tarvetta käsitellä koko julkaisun sisältöä. Tämä helpottaa kielimallin käyttöön liittyvää laitteistotarvetta.

HTML

HTML on oman julkaisumuotonsa lisäksi pohja, jonka perusteella DoX CMS kasaa esimerkiksi PDF-julkaisut. Täten sen avulla voi hakea apua esimerkiksi PDF-julkaisujen tyylittelyyn. Näissä julkaisuissa ovat mukana sekä oikeat tunnisteet että käytetyt tyylitiedostot.

Ihanteellisesti kielimalli oppisi tällä tavoin rakenteiden vastaavuudet raakasisällön ja HTML-julkaisujen kesken. En kuitenkaan pidättäisi hengitystäni odottaen tällaista tulosta. Sen sijaan HTML voi osoittautua hyödylliseksi myös pelkästään verkkosisältöjen standardina toimimisen vuoksi. Enemmistö kielimallien koulutuksesta perustuu verkosta kaavittuun sisältöön, minkä pitäisi tehdä HTML:stä niille helposti sulatettavaa.

Raakasisältö

DoX CMS antaa myös ladata tekstieditorin mukaisen raakasisällön muutamalla eri keinolla. Editori-valikossa on erikseen komento, jolla valitut otsikkosisällöt voi ladata yhtenä XML-tiedostona. Lisäksi käännöstiedostojen esikatseluversiot ovat käytännössä vastaavia tältä osin ja niiden avulla voi valikoida mukaan julkaisukohtaiset sisällöt. Näiden sisältöjen perusteella kielimallilta voi pyytää palautetta vielä työn alla oleviin sisältöihin.

Esittelen alla kolmannen keinon tuoda nämä sisällöt kielimallien käyttöön WebDAV-toteutuksemme avulla. Se on monimutkaisempi vaihtoehto. Tällöin nämä sisällöt pysyvät kuitenkin toisistaan erotettuina ja siten jaoteltavina. Tällä tavoin mukaan voi valikoida sisältöjä myös osana työnkiertoa.

Taulukot

Muista, että voit ladata käytännössä kaikki DoX CMS:n listat XLSX-taulukoina. Myös nämä tiedostot voivat tarjota kielimallin käyttöön hyödyllistä kontekstia muun sisällön käsittelemisen tueksi yhdistämällä eri tietoja. Nämä esimerkit antavat suuntaa näiden taulukoiden käyttämisen mahdollisuuksista:

• Editori: Tämä taulukko sisältää esimerkiksi otsikkosisältöjen ID-arvot, otsikot ja kuvaukset.
• Otsikkopuu: Tämä taulukko sisältää otsikkopuukohtaisen suodattamattoman pohjan julkaisuille.
• Elementtiluokat: Tämä taulukko sisältää elementtiluokkien nimet ja selitteet.
• Julkaisu: Tämä taulukko sisältää julkaisun lopullisen otsikkosisältölistan ja samat tiedot kuin Editori-valikko.

Julkaisukohtaisten taulukoiden lataaminen tapahtuu hieman epäintuitiivista kautta. Se vaatii kahden eri julkaisurevision valitsemista ja komennon niiden vertaamiseksi käyttämistä. Tällöin avautuva valikko sisältää painikkeet kunkin julkaisukohtaisen taulukon lataamiseksi.

WebDAV

Sinulle varatut sisällöt DoX CMS:ssä voi avata paikallisesti myös verkkokansiossa. Tämä toiminto oli alkujaan tarkoitettu muiden tekstieditorien kuten oXygen XML ja FrameMaker käyttämiseen. Sitä voi kuitenkin käyttää myös sisältöjen hakemiseen paikallisen kielimallin käyttöön. Tämän vaihtoehdon etuina ovat, että tällöin sisällöt pysyvät erillisissä tiedostoissa ja niiden saatavuutta voi hallinnoida integroituna osana työnkiertoa.

Tarkat ohjeet WebDAV-kansion käyttämiseen löytyvät oppaastamme. En jaa niitä julkisesti tietoturvan nimissä. Käytännössä kyse on kuitenkin DoX CMS:n käyttäjätunnuksen käyttämisestä verkkolevyn lisäämiseen. Tämä verkkolevy näyttää kyseiselle käyttäjälle varatut otsikkosisällöt eri kielillä ja otsikkopuut.

Suosittelen kopioimaan tätä kautta haetut sisällöt paikalliseen kansioon tai ilman kirjautumista saatavilla olevaan verkkokansioon. Kielimalli voi sitten käyttää näitä kopioita, jotka voit myös versioida. Valitettavasti ainakaan GPT4ALL ei esimerkiksi kykene ylläpitämään yhteyttä tällä tavoin kytkettyyn verkkolevyyn vaan sen täytyy käsitellä kaikki nämä tiedostot uudelleen joka kerta, kun tietokone käynnistetään uudelleen.

Työnkierto

Kielimallien käytön kanssa integroitu työnkierto sallii lisätä osaksi työnkiertoa erillisen tilan, jossa sisällöt voi varata (ainoastaan) tekoälykäyttäjälle ja siten tuoda kyseiset sisällöt WebDAV-kansioon talteenottoa varten.

Tällainen työnkierto vaatii erillisen roolin, tähän käyttöön varatun käyttäjätilin ja asianmukaisesti säädetyn työnkierron tilan.

Roolit ovat ainoastaan meidän hallinnoitavissamme. Joutuisit siis pyytämään tätä varten erikseen kyseisenlaisen roolin käyttöönne antamista. Käytännössä kyseessä on tapa merkitä kielimallikäyttäjä ja rajata sille saatavilla olevat käyttöoikeudet pelkkään sisältöjen sille varaamiseen.

Käyttäjätilit menevät tietenkin lisenssimäärästänne. Tämä olisi tosin edullisempi, rajattujen käyttöoikeuksien lisenssi, jonka hinnasta voimme keskustella. Käytännössä kyseisen käyttäjätilin voi kuitenkin kytkeä sähköpostiosoitteeseen, jota ei edes ole olemassa, ja pääkäyttäjänne voi vaihtaa sen salasanan käsin. Näillä tunnuksilla tarvitsee kirjautua vain verkkolevylle, kun eri käyttäjät hakevat tiedostoja sieltä.

Jäljelle jää työnkierron tilan lisääminen. Suositukseni on, että siinä ainoaksi sallituksi rooliksi valitaan kielimallia varten lisätty käyttäjärooli. Tällöin sisältöä ei voi varata muille käyttäjille tätä tilaa käyttäen. Tämän lisäksi uuden työnkierron tilan määrittäminen vaatii sen sijoittamista muiden tilojen väliin sallittujen siirtymien perusteella. Ihanteelliset vaihtoehdot tältä osin riippuvat halutuista käyttötavoista. Toki useampi kielimallien käyttötapa voi olla käytössä samanaikaisesti, jolloin myös näitä tiloja voi lisätä useampia.

Jos haluttu käyttötapa on sisältöjen tarkistaminen kielimallin avustuksella, tulisi tähän tarkoitettu tila sijoittaa oletustilan jälkeen. Suosittelen käyttämään sitä ennen varsinaista katselmointia, koska kielimallin tekemä katselmointi on enintään alustavantasoista. Sillä ei esimerkiksi ole minkäänlaista kykyä kommentoida jo kirjaamattomia tuotteiden piirteitä. Tällöin tämä tila tulisi asettaa oletustilan ja katselmointitilan väliin mahdollisena lisäpolkuna.

Jos haluttu käyttötapa on puolestaan hyväksytyn raakasisällön tuominen kielimallin käyttöön mallina halutuista muotoiluista ja niin edelleen, tulisi tämä vaihe lisätä katselmoinnin ja hyväksymisen väliin. Vaihtoehtoisesti, hyväksymisvaiheessa voi sallia sisällön varaamisen kielimallikäyttäjälle tai hyväksymisvaiheen voi korvata tällä erillisvaiheella.

Yhteenveto

Paikalliset kielimallit ovat keino välttää tekoälypalveluihin liittyvät tietoturvariskit. Niiden asentamiseen voi käyttää alustoja kuten GPT4ALL tai Ollama. Tämän jälkeen näillä alustoilla voi valita käyttöön haluamansa pohjamallin, jota voi säätää paremmin omiin tarkoituksiinne oikein muotoilluilla pohjasyötteillä ja syöttämällä sille sisältöjänne. Valitettavasti näillä kielimalleilla on rajoitteensa, joiden vuoksi niitä ei aina voi pakottaa toimimaan haluamillanne tavoin. Esimerkiksi käytettävissä olevan päätelaitteen laskentateho ja muisti rajoittavat niiden käytettävyyttä.

DoX CMS antaa syöttää sen kautta tuotettuja sisältöjä näille kielimalleille niiden käytön avuksi ja näiden sisältöjen läpikäymiseksi niiden avulla. Tällöin näihin sisältöihin on syytä lisätä metadataa, jonka perusteella kielimallien on helpompaa käsitellä sitä. Eri julkaisumuodoilla on kullakin etunsa kielimalleilla syötettyinä kuten DITA-julkaisujen kautta saatavilla oleva DTD-tiedosto. Lisäksi saat järjestelmästä ulos sekä raakasisältöjä että taulukoita eri listoista.

Kattavampi keino ottaa kielimalli osaksi työnkiertoa vaatii WebDAV-pohjaista toteutusta, jossa kielimallille lisätään erillinen rooli, käyttäjätunnus ja työnkierron tila tai kaksi. Tällä tavoin kyseiselle käyttäjälle voi varata sisältöjä osana niiden työnkiertoa ja ne voi hakea kielimallin käyttöön WebDAV-pohjaisesta verkkokansiosta. Suosittelen kopioimaan nämä sisällöt ilman erillistä kirjautumista saatavilla olevalle verkkolevylle, josta kuka tahansa käyttäjä voi hakea eri versiot ja aihekohtaiset sisällöt käyttötarpeen mukaan.