Paikallista kielimallia on nopea kokeilla. Yhteinen tekoälyavustaja tarvitsee lisäksi hallitun pääsyn, selkeät datavirrat ja ylläpidosta vastaavan henkilön. Ollama ja Open WebUI voivat toimia yhdessä: toinen komponentti suorittaa mallit, toinen tarjoaa käyttöliittymän päivittäiseen työhön.
Yrityksessä suunnittelu alkaa konkreettisesta tehtävästä: tekstiluonnokset hyväksytyistä muistiinpanoista, sisäisten muistiinpanojen jäsentely tai teknisissä kysymyksissä auttaminen. Sallitut syötteet, tulosten tarkistus ja sopivat vasteajat on määriteltävä ennen laitteiston valintaa.
Kaksi komponenttia, eri tehtävät
Ollama tarjoaa suoritusympäristön ja API:n kielimalleille. Open WebUI lisää hallittavan verkkokäyttöliittymän. Paikallisesti asennettu käyttöliittymä ei kuitenkaan kerro, missä jokainen yhdistetty malli käsittelee pyynnöt. Pilvimallit, verkkohaku ja lisätyökalut voivat käyttää muita datavirtoja.
Tässä toimintamallissa työntekijät pääsevät käyttöliittymään hyväksyttyä reittiä. Open WebUI yhdistyy sisäisesti Ollamaan. Mallin API rajataan palveluille, jotka todella tarvitsevat sitä. Erillisten konttien tai palvelinten yhteydet on suunniteltava nimenomaisesti: localhost tarkoittaa kunkin komponentin omaa verkkoympäristöä.
Yhdestä työasemasta yhteiseksi palveluksi
Ero koskee ennen kaikkea sitä, mitä ensimmäisen onnistuneen keskustelun jälkeen tapahtuu. Vertailu kuvaa pienen yrityksen mahdollista kehitysvaihetta; se on suunnitteluapu, ei dokumentoitu asiakasprojekti.
| Osa-alue | Yksittäinen testi | Yhteiskäyttö |
|---|---|---|
| Pääsy | Yksi henkilö testaa omalla tietokoneellaan. | Henkilökohtaiset tunnukset, määritellyt roolit ja hallittu pääsyn poistaminen. |
| Data | Ei-arkaluonteinen esimerkkidata. | Hyväksytyt datatyypit, säilytys ja todennettavat oikeudet lähteisiin. |
| Saatavuus | Tietokone on päällä testin aikana. | Sovitut käyttöajat ja dokumentoitu palautuminen. |
| Kapasiteetti | Yksi pyyntö antaa käyttökelpoisen vastauksen. | Samanaikaiset tehtävät, odotusajat ja pidemmät syötteet mitataan. |
| Muutokset | Mallia ja ohjelmistoa kokeillaan. | Testatut versiot, varmistus ennen muutoksia ja luotettava paluureitti. |
Suojaa käyttöliittymän pääsy ja mallin API erikseen
Valmistajan mukaan Ollaman paikallinen API ei vaadi omaa tunnistautumista. Verkkopääsy ei siksi korvaa pääsynhallintaa. Yrityspalvelussa mallin API:n tulisi olla saavutettavissa vain tarvittavien sisäisten yhteyksien kautta. Kaikille työasemille tai internetiin avoin portti ei ole sopiva lähtökohta. Ollama: tunnistautuminen (ulkoinen linkki).
Käyttöliittymän kirjautuminen, käyttäjähyväksyntä ja ylläpito-oikeudet määritetään harkiten. Nykyinen identiteettipalvelu voi olla hyödyllinen integraatio; sopiva liitäntä riippuu ympäristöstä. Välityspalvelin saa välittää tunnistetun identiteetin vain itse asettamillaan luotetuilla tiedoilla. Open WebUI: pääsy ja käyttöoikeudet (ulkoinen linkki).
HTTPS suojaa selaimen ja pääsypisteen välistä yhteyttä. Usean järjestelmän tapauksessa myös jatkoyhteys taustapalveluun salataan ja rajataan suojaustarpeen mukaan. Varmenteet, uudelleenohjaukset ja käyttöliittymän tarvitsemat yhteydet testataan yhdessä. Open WebUI: HTTPS ja käänteinen välityspalvelin (ulkoinen linkki).
Varmista paikallisuus todellisen datavirran perusteella
Ollama tarjoaa pelkästään paikallisia mallikutsuja varten tilan ilman pilvitoimintojaan. Se ei korvaa Open WebUI:n tai lisätyökalujen muiden yhteyksien tarkistusta. Myös mallien lataukset ja ohjelmistopäivitykset tarvitsevat suunnitellun hankintareitin. Ollama: paikallinen käyttö ja pilvitoiminnot (ulkoinen linkki).
- Malli: Mikä tarkka versio käsittelee pyynnön ja missä se suoritetaan?
- Asiakirjat: Mihin ladatut tiedostot, poimitut tekstit, hakuindeksit ja varmistukset tallennetaan?
- Lisäpalvelut: Käytetäänkö hakuun, tekstintunnistukseen, puheeseen tai upotuksiin muita palveluntarjoajia?
- Työkalut: Mikä yhteys saa lukea dataa tai käynnistää toimintoja ja kenen oikeuksilla?
Pilvi ja hybridiratkaisut voivat olla sopivia lisäosia. Tällöin tarjoajat, datatyypit ja hyväksynnät määritetään selvästi. Ulkoiseen palveluun ei pidä siirtyä huomaamatta vain siksi, että paikallinen malli on varattu.
Yritystieto tarvitsee erilliset käyttöoikeudet
Kirjautuminen kertoo ensin, kuka käyttöliittymää käyttää. Se ei automaattisesti anna oikeutta kaikkiin ladattuihin asiakirjoihin. Esimerkissä hyväksytty ohje voisi olla kaikkien pilotin käyttäjien saatavilla, mutta henkilöstöasiakirjat pysyvät kokonaan pilotin ulkopuolella.
Uusia lähteitä liitettäessä oikeudet tarkistetaan kokoelmittain, asiakirjoittain ja käyttäjittäin. Myös hakutulokset, lainaukset, jaetut keskustelut ja tallennetut vastaukset voivat paljastaa tietoa. Ryhmä- ja lähdeoikeuksien muutosten on tultava voimaan tietoratkaisussa. Lisätietoa sivuilla Yritystieto ja RAG ja Tekoälyn tietoturva ja käyttöoikeudet.
Varmistukset ja päivitykset kuuluvat kokonaisuuteen
Varmista todelliset tietoaineistot: tietokanta, ladatut tiedostot, asetukset sekä palautukseen tarvittavat avaimet. Dokumentoi mallin nimi ja tarkka versio, myös mukautetut mallit ja omat laajennukset. Varmistus säilytetään erillään käynnissä olevasta järjestelmästä suojatuin käyttöoikeuksin.
Ennen päivitystä tarvitaan palautettava varmistus, julkaisutietojen tarkistus ja testi tuotantopalvelun ulkopuolella. Tietokannan siirron jälkeen vanha konttikuva ei yksin välttämättä palauta aikaisempaa tilaa. Open WebUI: päivitykset, varmistus ja paluureitti (ulkoinen linkki).
Hyödyllinen palautustesti alkaa erillisessä ympäristössä. Siellä tarkistetaan kirjautuminen, malliyhteys, ei-arkaluonteinen testitehtävä ja odotetut oikeudet. Vasta tämän jälkeen voidaan arvioida todellisen käyttökatkon kesto. Pelkkä käynnissä oleva virtuaalikone tai varmistushakemisto ei osoita sitä.
Toimiva käyttöliittymä ei vielä osoita toimivaa mallia
Valvonnan tulisi erottaa käyttöliittymän saatavuus, valitun mallin valmius ja kokonaisen pyynnön toimivuus. Open WebUI:n dokumentaatio erottaa myös nämä tasot. Open WebUI: toiminnan valvonta (ulkoinen linkki).
Sovitussa ylläpidossa seurataan myös tallennustilan käyttöä, vapaata kapasiteettia, virhemääriä ja odotusaikoja. Testipyynnöissä ei ole luottamuksellista tietoa. Lokien tulee riittää vianhakuun ilman kaikkien keskustelujen yleistä kopiointia. Häiriöihin vastaava ja päivitykset hyväksyvä taho määritetään ennen laajempaa käyttöä.
Hallittava hyväksyntä ennen aloitusta
- Tarkista pääsy: Hyväksytty käyttäjä pääsee sisään; hyväksymätön käyttäjä ja kielletty verkkoalue jäävät ulkopuolelle.
- Tarkista datavirrat: Malli, käyttöliittymä ja kaikki lisäpalvelut käyttävät vain sovittuja yhteyksiä.
- Tarkista oikeudet: Kaksi testiroolia saa vain niille hyväksytyn sisällön. Poistettu pääsy estetään myös aiemmin onnistuneen haun jälkeen.
- Tarkista kuorma: Tyypilliset tehtävät suoritetaan erikseen ja yhtä aikaa; hyväksyttävät odotusajat ja rajat kirjataan.
- Tarkista palautuminen: Varmistus palautetaan erilliseen ympäristöön; vastuut ja paluureitti on dokumentoitu.
Laitteistotarve riippuu mallista, kontekstin pituudesta, samanaikaisesta käytöstä ja laatutavoitteesta. Arkkitehtuurista ei siksi voi päätellä yleispätevää yhtäaikaisten käyttäjien määrää. Aiempi artikkeli Paikallisen tekoälyn testaus: pilotti edustavalla kuormalla syventää kapasiteetin arviointia.
Aloita rajatusta tehtävästä
DAXS voi arvioida nykyisen infrastruktuurin, suunnitella datavirrat ja pääsyn sekä liittää ratkaisun sovittuun ylläpitoon. Rajattu käyttötapaus, jolla on todennettava hyöty, on hyvä alku. Se osoittaa, sopiiko paikallinen palvelu, pilviliitäntä vai yhdistelmä taloudellisesti ja organisaatiolle.
Paikalliset LLM:t ja infrastruktuuri · MCP ja rajapinnat · Pyydä tekoälyneuvontaa ja automaatiota
Lähteet: esimerkki kuvaa mahdollista arkkitehtuuria ja tarkistusmenettelyä, ei yleispätevää asennusohjetta. Tuotetoiminnot, mallilisenssit ja todellinen yhteensopivuus tarkistetaan käytettäville versioille.
