Lokalny model AI: co działa po odłączeniu internetu?

Na pokazie lokalny asystent podsumowuje dokument, choć komputer nie ma dostępu do internetu. Po tygodniu pracownik otwiera świeżo zainstalowaną aplikację w sali bez zasięgu i widzi prośbę o pobranie składnika. Model jest lokalny. Składnik najwyraźniej jeszcze o tym nie wie.

Obie sytuacje mogą być zgodne z opisem produktu. W pierwszej wszystkie potrzebne pliki już znajdowały się na urządzeniu. W drugiej zabrakło elementu niezbędnego do uruchomienia zadania. Osobne pytanie brzmi, czy przy działającym internecie ten sam asystent korzysta wyłącznie z komputera, czy także z podłączonych usług.

Przyjmijmy fikcyjny zespół Forma, który przygotowuje streszczenia instrukcji urządzeń. Dokument trafia z firmowego folderu do aplikacji, model układa odpowiedź, a pracownik zapisuje wynik w systemie zgłoszeń. Kierownik chciałby powiedzieć klientowi: „Ten proces działa lokalnie”. Zanim użyje takiego zdania, musi ustalić, które czynności obejmuje ta deklaracja. Dostęp do instrukcji, samo generowanie odpowiedzi i zapis do zewnętrznego systemu mogą mieć trzy różne granice.

Najpierw ustal, co ma zostać na komputerze

Słowo „lokalny” potrzebuje rzeczownika. Lokalny model, lokalna aplikacja i lokalny obieg dokumentu opisują różne sprawy. Model może wykonywać obliczenia na laptopie, podczas gdy aplikacja pobiera dokument z chmury. Cały zestaw może pracować na jednym urządzeniu, ale wynik trafia potem do współdzielonego folderu. Samo miejsce obliczeń nie opisuje dalszej drogi danych.

W Formie warto rozpisać jeden konkretny przypadek: instrukcja o numerze F-18, pytanie o przygotowanie urządzenia do transportu, odpowiedź ze wskazaniem fragmentów i ręczny zapis notatki. Przy każdej czynności zapisz, co czyta plik, skąd pochodzi treść i gdzie powstaje kopia. Taką mapę porządkuje rejestr przepływu danych AI. Na tym etapie nie wystarczy nazwa modelu wpisana w oknie rozmowy.

Przy każdym miejscu przechowywania ustal też sposób usunięcia materiału po próbie. Zamknięcie rozmowy może pozostawić plik wynikowy, eksport albo kopię roboczą. W naszym przykładzie pracownik ma wiedzieć, gdzie znajduje się szkic notatki i czy po przekazaniu sprawy nadal jest potrzebny na laptopie. Ocena lokalności nie kończy się w chwili wygenerowania ostatniego zdania.

Oddziel również to, co firma deklaruje wobec klienta, od tego, czego potrzebuje do pracy. Jeżeli warunkiem jest brak wysyłania instrukcji do zewnętrznej usługi, sprawdzasz drogę jej treści. Jeżeli celem jest praca w terenie bez łączności, sprawdzasz dostępność całego zadania. Rozwiązanie może spełniać jeden z tych warunków, a drugiego nie. Pracownik w hali nie skorzysta z tej subtelności, kiedy ekran przestanie odpowiadać.

W dokumentacji pracy offline LM Studio producent rozdziela podstawowe funkcje, takie jak rozmowa z pobranym modelem i lokalne przetwarzanie dokumentów, od czynności wymagających sieci: wyszukiwania i pobierania modeli oraz pobierania środowisk uruchomieniowych i aktualizacji. Ten opis dotyczy wymienionych funkcji, a nie dowolnego zestawu dodatków.

W protokole odbioru przypisz te funkcje do własnej konfiguracji. Zapisz wersję aplikacji, wybrany model, używany sposób odczytu dokumentów i listę podłączonych narzędzi. Zrzut samego pola z nazwą modelu nie pokaże pozostałych elementów. Gdy zmieni się któryś z nich, wynik dawnej próby nie opisuje już automatycznie nowego zestawu.

Przy zakupie nie sprowadzaj pytania do „czy macie tryb lokalny?”. Poproś o rozpisanie czynności wykonywanych na urządzeniu i poza nim dla waszego zadania. To konkretne uzupełnienie oceny dostawcy AI przed zakupem: pozwala porównać rozwiązania na tym samym procesie, zamiast zestawiać dwa podobnie brzmiące hasła.

Trzy próby zamiast jednego odłączenia kabla

Pierwsza próba dotyczy przygotowanego stanowiska. Osoba odpowiedzialna za konfigurację potwierdza, że potrzebne składniki są pobrane, a dokument testowy znajduje się na urządzeniu. Dopiero potem, w uzgodnionych warunkach, ogranicza się dostęp do internetu i wykonuje całe zadanie. Użyj sztucznej instrukcji ze szczegółem, którego model nie powinien znać z wiedzy ogólnej, na przykład wymyślonym oznaczeniem opakowania transportowego.

Sprawdź nie tylko pojawienie się odpowiedzi. Czy aplikacja rzeczywiście odczytała wskazaną instrukcję? Czy przywołała właściwy fragment? Czy udało się zapisać wynik w miejscu przewidzianym dla pracy bez sieci? Odpowiedź z pamięci rozmowy albo swobodnie ułożony opis transportu nie potwierdza odczytu pliku. Dobrze brzmiący akapit może zasłonić brakujący etap.

W drugim dokumencie umieść to samo pytanie, ale inną poprawną odpowiedź. Potem porównaj oba wyniki z przygotowanym kluczem. Jeśli asystent powtarza pierwsze oznaczenie, sprawdź, czy dostał drugi plik, a nie tylko kolejne pytanie w tej samej rozmowie. Taka para pomaga odróżnić rzeczywisty odczyt od pozornego działania na treści zachowanej wcześniej.

Druga próba zaczyna się od ponownego uruchomienia aplikacji w tych samych warunkach. Dzięki temu oddzielasz działającą już rozmowę od możliwości rozpoczęcia nowej pracy. Zapisz, czy dostępny jest model, dokument i funkcja przygotowania odpowiedzi. Jeżeli pierwszy przebieg korzystał z otwartej wcześniej sesji, wynik po jej zamknięciu może być inny. Nie dopisuj wtedy do raportu jednego ogólnego „offline działa”.

Do próby dołącz także obsługiwany plik o innej wielkości i materiał w formacie, którego zespół nie zamierza przyjmować. Pierwszy sprawdza rzeczywisty zakres pracy, drugi sposób zakończenia nieobsługiwanego zadania. Komunikat aplikacji powinien wskazać przyczynę przerwania; brak odczytu nietypowego załącznika nie jest tym samym co niedostępność modelu. Zapisz te wyniki oddzielnie.

Trzecia próba dotyczy przygotowania lub odtworzenia stanowiska. Ma inny cel: sprawdza, jakie składniki i uprawnienia trzeba zapewnić przed wyjazdem albo po wymianie komputera. Pobranie modelu może wymagać sieci, nawet jeśli późniejsze przetwarzanie jej nie potrzebuje. Ustal osobę odpowiedzialną za przygotowanie oraz sposób potwierdzenia gotowości. To zadanie organizacyjne powinno znaleźć się przed podróżą w kalendarzu, a nie dopiero na dworcu.

W każdym przebiegu zapisuj rzeczywisty zakres ograniczenia łączności. Brak internetu nie musi oznaczać braku firmowej sieci lokalnej. Wyłączenie jednego połączenia nie dowodzi też, że aplikacja nie mogła użyć innego. Osoba prowadząca próbę powinna opisać warunki i dostępne obserwacje, zamiast wyciągać wniosek o pełnej izolacji z samego komunikatu w pasku systemowym.

Połączenie może wrócić, zanim skończy się zadanie

Następny przypadek zaczyna się bez sieci, a kończy po jej przywróceniu. W Formie pracownik przygotował notatkę lokalnie i zaznaczył zamiar zapisania jej w systemie zgłoszeń. Czy zapis czeka na wykonanie? Czy zostanie uruchomiony sam, czy dopiero po ponownym potwierdzeniu? Czy pracownik widzi różnicę między lokalnym szkicem a notatką udostępnioną zespołowi?

To nie jest drobiazg interfejsu. Ustal, co dzieje się z odłożoną operacją oraz z kopią dokumentu po odzyskaniu połączenia. Jeśli aplikacja nie ma kolejki takich operacji, opisz ręczny sposób dokończenia pracy. Jeśli ją ma, sprawdź rezultat na danych testowych. Nie zakładaj synchronizacji tylko dlatego, że obok pliku pojawiła się ikona chmury.

W próbie z przywracaniem połączenia zmień jeszcze treść lokalnego szkicu przed jego przekazaniem. Potwierdzenie powinno dotyczyć tej wersji, którą pracownik widzi w chwili decyzji. W raporcie zachowaj oznaczenie wejściowej instrukcji i przekazanego wyniku. Dzięki temu później da się rozstrzygnąć, czy błąd powstał podczas analizy, ręcznej korekty czy odroczonego zapisu.

FAQ Ollama opisuje możliwość wyłączenia funkcji chmurowych, co usuwa dostęp do modeli chmurowych i wyszukiwania w sieci w tym produkcie. Dokumentacja wymaga ponownego uruchomienia po zmianie konfiguracji. Taki mechanizm trzeba odnieść do konkretnej instalacji; nie określa on działania innych aplikacji ani zewnętrznych narzędzi.

Własny odbiór powinien więc uwzględnić stan przed zmianą ustawienia, po jego zastosowaniu i po ponownym uruchomieniu. Samo zapisanie konfiguracji nie potwierdza, że pracujący proces już ją stosuje. Zachowaj też rozróżnienie między brakiem dostępnej funkcji a niedziałającym zadaniem: wyłączone wyszukiwanie może być zamierzonym ograniczeniem, a nie awarią.

Przed próbą z niedostępnym systemem zgłoszeń ustal także, jak pracownik rozpozna zaległe sprawy. Przy kilku instrukcjach łatwo pomylić notatkę ukończoną z przekazaną. Lista powinna wiązać wynik z numerem dokumentu i sprawy, a nie tylko z czasem utworzenia pliku. W przeciwnym razie porządkowanie po powrocie do biura może potrwać dłużej niż samo przygotowanie streszczeń.

Dodatkowe narzędzie zmienia odpowiedź na pytanie o lokalność

Przyjmijmy, że Forma dodaje wyszukiwanie aktualnego wykazu części. Model pozostaje ten sam, ale od tej chwili jedno z pytań wymaga połączenia z innym systemem. To rozsądne rozszerzenie, jeśli zostało świadomie uzgodnione. Nie powinno po cichu odziedziczyć dawnego opisu „całość działa bez internetu”.

Zapisz, kto wykonuje wyszukiwanie: sama aplikacja, oddzielna usługa czy podłączony serwer narzędzi. Następnie sprawdź, jakie dane dostaje. Do znalezienia oznaczenia części może wystarczyć jej numer; przesłanie całej instrukcji wymaga osobnej oceny potrzeby. Zmiana narzędzi MCP pokazuje, dlaczego katalog dostępnych funkcji i ich znaczenie należą do konfiguracji procesu, nawet gdy użytkownik nadal widzi jedno okno rozmowy.

Samo lokalne uruchomienie nie wyznacza również granicy odczytu plików. Model potrzebuje materiału dostarczonego przez aplikację lub narzędzie, a te mogą mieć dostęp do szerszego katalogu niż wybrana instrukcja. Zakres plików i sieci sprawdza się osobno w piaskownicy agenta AI, czyli środowisku z określonymi ograniczeniami działania. Jedna etykieta produktu nie zastępuje obu ocen.

Brak połączenia podczas próby mówi, że zadanie w opisanych warunkach nie wymagało tego połączenia. Sam w sobie nie dowodzi, jak aplikacja zachowa się przy dostępnej sieci ani że wszystkie jej możliwe operacje zostały sprawdzone. Jeśli firma potrzebuje mocniejszej deklaracji dotyczącej ruchu danych, musi określić dodatkowy zakres obserwacji i zabezpieczeń z osobą odpowiedzialną za środowisko.

Przy aktualizacji powtórz próby, które dotyczą zmienionego składnika. Nowa wersja modelu może wymagać ponownego pobrania, zmiana aplikacji może dołożyć funkcję, a nowe narzędzie wprowadzić zależność od sieci. Wskaż zmieniony składnik i próby, które go obejmują. Przy pozostałych wynikach odnotuj, dlaczego nadal opisują używany układ.

Na koniec przeprowadź krótką próbę z osobą, która będzie pracowała w terenie. Daj jej przygotowane stanowisko, sztuczny dokument i jasne zadanie. Poproś o wskazanie, co zostało ukończone, co czeka na połączenie oraz jak wróci do zaległych zapisów. Plan ciągłości pracy powinien uwzględniać tę drogę równie konkretnie jak awarię zewnętrznej usługi.

Wynikiem odbioru może być krótkie zdanie określające zakres sprawdzonego działania: przygotowane stanowisko odczytuje wskazane lokalne instrukcje i zapisuje szkice bez internetu, natomiast przekazanie do systemu zgłoszeń wymaga połączenia oraz potwierdzenia pracownika. Tak opisany proces da się przekazać kolejnej osobie i sprawdzić ponownie. W ofercie Aeneia Audit punktem odniesienia jest właśnie sposób używania narzędzi w pracy; nazwa modelu to dopiero jeden z jego elementów.