Egy helyi nyelvi modell gyorsan kipróbálható. A közös MI-asszisztenshez szabályozott hozzáférés, tiszta adatútvonalak és az üzemeltetést vállaló felelős is szükséges. Az Ollama és az Open WebUI együttműködhet: az egyik a modelleket futtatja, a másik a napi munkához biztosít felületet.
Vállalatnál a tervezés konkrét feladattal kezdődik: szövegvázlat jóváhagyott pontokból, belső jegyzetek rendezése vagy műszaki kérdések támogatása. A hardverválasztás előtt kell meghatározni a megengedett bemeneteket, az eredmények ellenőrzését és a megfelelő válaszidőt.
Két komponens eltérő feladatokkal
Ollama futási környezetet és API-t biztosít a nyelvi modellekhez. Open WebUI kezelhető webes felületet ad hozzá. A helyben telepített felület azonban nem mondja meg, hol számol minden csatlakoztatott modell. Felhőmodellek, webes keresés és további eszközök más adatútvonalakat használhatnak.
Ebben az üzemeltetési koncepcióban a munkatársak engedélyezett útvonalon érik el a felületet. Az Open WebUI belső kapcsolaton csatlakozik az Ollamához. A modell API-ja az azt ténylegesen igénylő szolgáltatásokra korlátozott. Külön konténerek vagy szerverek kapcsolatait kifejezetten meg kell tervezni: localhost mindig az adott komponens saját hálózati környezetét jelöli.
Egy munkaállomástól a közös szolgáltatásig
A különbség főként az első sikeres beszélgetés utáni működésben van. Az összevetés egy kisvállalkozás lehetséges fejlesztési szintjét mutatja; tervezési segédlet, nem dokumentált ügyfélprojekt.
| Terület | Egyéni teszt | Közös használat |
|---|---|---|
| Hozzáférés | Egy személy a saját gépén tesztel. | Saját fiókok, meghatározott szerepek és szabályozott hozzáférés-visszavonás. |
| Adatok | Nem érzékeny mintaadatok. | Engedélyezett adattípusok, megőrzés és igazolható forrásjogok. |
| Elérhetőség | A számítógép a teszt alatt be van kapcsolva. | Egyeztetett használati idő és dokumentált helyreállás. |
| Kapacitás | Egy kérés használható választ ad. | Párhuzamos feladatok, várakozások és hosszabb bemenetek mérése. |
| Változások | A modellt és a szoftvert kipróbálják. | Tesztelt verziók, változtatás előtti mentés és megbízható visszaút. |
A hozzáférést és a modell API-ját külön védjük
A gyártó szerint az Ollama helyi API-ja nem igényel saját hitelesítést. A hálózati elérés ezért nem helyettesíti a hozzáférés-szabályozást. Vállalati szolgáltatásnál a modell API-ja csak a szükséges belső kapcsolatok felől legyen elérhető. Minden munkaállomás vagy az internet számára nyitott port nem megfelelő kiindulópont. Ollama: hitelesítés (külső hivatkozás).
A felület bejelentkezését, felhasználó-jóváhagyását és adminisztrációs jogait tudatosan kell beállítani. Meglévő identitásszolgáltatás hasznos integráció lehet; a megfelelő csatlakozás a környezettől függ. A proxy hitelesített identitást csak saját maga által beállított, megbízható információval adhat tovább. Open WebUI: hozzáférés és jogosultságok (külső hivatkozás).
A HTTPS a böngésző és a belépési pont közötti kapcsolatot védi. Több rendszer esetén a backendhez vezető további útvonalat is a védelmi igény szerint kell titkosítani és korlátozni. A tanúsítványokat, átirányításokat és a felülethez szükséges kapcsolatokat együtt teszteljük. Open WebUI: HTTPS és fordított proxy (külső hivatkozás).
A „helyi” működést a valós adatútvonal igazolja
Kizárólag helyi modellhívásokhoz az Ollama felhőfunkciók nélküli módot kínál. Ez nem helyettesíti az Open WebUI vagy a hozzáadott eszközök egyéb kapcsolatainak ellenőrzését. A modellletöltésekhez és szoftverfrissítésekhez is tervezett beszerzési útvonal kell. Ollama: helyi használat és felhőfunkciók (külső hivatkozás).
- Modell: Melyik pontos verzió dolgozza fel a kérést, és hol fut?
- Dokumentumok: Hol tárolódnak a feltöltések, kinyert szövegek, keresőindexek és mentések?
- Kiegészítő szolgáltatások: Kereséshez, szövegfelismeréshez, beszédhez vagy beágyazásokhoz más szolgáltatókat is elér a rendszer?
- Eszközök: Melyik kapcsolat olvashat adatot vagy indíthat műveletet, és kinek a jogaival?
A felhő és a hibrid megfelelő kiegészítés lehet. Ilyenkor a szolgáltatókat, adattípusokat és engedélyeket kifejezetten meg kell határozni. Külső szolgáltatásra váltás ne történjen észrevétlenül pusztán azért, mert a helyi modell foglalt.
A vállalati tudáshoz konkrét jogosultság kell
A bejelentkezés először azt tisztázza, ki használja a felületet. Ebből nem következik automatikus jog minden feltöltött dokumentumhoz. A példában egy jóváhagyott útmutató minden pilotfelhasználónak elérhető lehet, miközben a személyzeti iratok teljesen kívül maradnak a piloton.
További források későbbi bekötésekor gyűjteményenként, dokumentumonként és felhasználónként kell ellenőrizni a jogokat. Keresési találatok, idézetek, megosztott beszélgetések és tárolt válaszok is felfedhetnek információt. A csoport- vagy forrásjog-változásoknak a tudásmegoldásban is érvényesülniük kell. További részletek a szakmai oldalakon: Vállalati tudás és RAG és MI-biztonság és jogosultságok.
Mentés és frissítés is része a koncepciónak
A ténylegesen használt adatokat mentjük: adatbázist, feltöltéseket és konfigurációt, valamint a helyreállításhoz szükséges kulcsokat. A modell nevét és pontos verzióját dokumentáljuk, a módosított modelleket és saját kiegészítéseket is. A mentés hozzáférés-védetten, a futó rendszertől elkülönítve tárolódik.
Frissítés előtt helyreállítható mentés, kiadási megjegyzések áttekintése és éles szolgáltatáson kívüli teszt szükséges. Adatbázis-migráció után a régi konténerkép önmagában nem feltétlenül állítja vissza a korábbi állapotot. Open WebUI: frissítés, mentés és visszaút (külső hivatkozás).
Érdemi helyreállítási teszt külön környezetben indul. Ott ellenőrizzük a bejelentkezést, modellkapcsolatot, nem érzékeny tesztfeladatot és az elvárt jogosultságokat. Csak ezután becsülhető meg egy valódi kiesés hossza. A futó virtuális gép vagy létező mentési könyvtár önmagában ezt nem igazolja.
A futó felület még nem jelent működő modellt
A felügyelet különböztesse meg az elérhető felületet, a választott modell rendelkezésre állását és a teljes kérés sikerét. Az Open WebUI dokumentációja is elválasztja ezeket a szinteket. Open WebUI: működésfelügyelet (külső hivatkozás).
Az egyeztetett üzemeltetéshez a tárhelyfoglalást, szabad kapacitást, hibaarányt és várakozásokat is figyeljük. A tesztkérések nem tartalmaznak bizalmas információt. A napló elég legyen a hibakereséshez anélkül, hogy minden beszélgetést általánosan megkettőzne. A szélesebb használat előtt kijelöljük a hibára reagáló és a frissítést jóváhagyó felelőst.
Áttekinthető átvétel az indulás előtt
- Hozzáférés ellenőrzése: Az engedélyezett felhasználó belép; az engedély nélküli felhasználó és tiltott hálózati tartomány kívül marad.
- Adatútvonal ellenőrzése: A modell, felület és minden kiegészítő szolgáltatás kizárólag az egyeztetett kapcsolatokat használja.
- Jogosultság ellenőrzése: Két tesztszerep csak a számára engedélyezett tartalmat kapja. A visszavont hozzáférés korábbi sikeres keresés után is megszűnik.
- Terhelés ellenőrzése: A tipikus feladatok külön és párhuzamosan futnak; az elfogadható várakozást és korlátokat rögzítjük.
- Helyreállás ellenőrzése: A mentés elkülönítve visszaállítható; a felelősség és a visszaút dokumentált.
A szükséges hardver a modelltől, kontextushossztól, párhuzamos használattól és minőségi céltól függ. Az architektúrából ezért nem adható meg általános egyidejű felhasználószám. A meglévő cikk Helyi MI tesztelése: pilot érdemi terheléssel ezt a kapacitásvizsgálatot részletezi.
Érdemes körülhatárolt feladattal kezdeni
A DAXS felmérheti a meglévő infrastruktúrát, megtervezheti az adatútvonalakat és hozzáféréseket, és beillesztheti a megoldást az egyeztetett üzemeltetésbe. Jó első lépés a körülhatárolt, ellenőrizhető hasznú eset. Ebből derül ki, hogy helyi szolgáltatás, felhőkapcsolat vagy kombináció illik-e gazdaságilag és szervezetileg.
Helyi LLM-ek és infrastruktúra · MCP és interfészek · MI-tanácsadás és automatizálás igénylése
Források: a példa lehetséges architektúrát és ellenőrzési folyamatot mutat, nem általános telepítési útmutatót. A termékfunkciókat, modelllicenceket és tényleges kompatibilitást a használt verziókra ellenőrizzük.
