Jak serwer AI w domu utrzymuje oddzielny kontekst dla każdego użytkownika?

Domowy serwer AI może utrzymać kontekst każdego użytkownika oddzielnie, dzieląc ten sam model, ale separacja nie pochodzi z samego modelu. Pochodzi z powiązania każdego czatu, rekordu pamięci, pobranego dokumentu, wpisu w pamięci podręcznej i wywołania narzędzia z uwierzytelnionym użytkownikiem, zanim te informacje trafią do promptu.

Jeśli dwie osoby mogą się zalogować osobno, a pytanie jednego użytkownika pobiera notatki innej osoby, błąd zwykle leży w aplikacji wokół modelu. Przydatnym testem jest, czy tożsamość przetrwa całą ścieżkę żądania. Ten artykuł podąża tą ścieżką i pokazuje, gdzie należy wymusić izolację, gdzie najczęściej dochodzi do jej naruszenia i kiedy uzasadniona jest silniejsza granica.

Model może być współdzielony, ale kontekst osobisty nie może

Wagi modelu są wspólnym silnikiem rozumowania. Nie potrzebują osobnej kopii dla każdego członka rodziny czy współpracownika, gdy model obsługuje zwykłe żądania inferencji. To, co musi pozostać oddzielne, to informacje zgromadzone wokół tych wag dla konkretnego żądania.

Te informacje obejmują bieżący czat, zapisane historie rozmów, preferencje użytkownika, pobrane fragmenty plików, wyniki wyszukiwania wektorowego, wyniki narzędzi, tymczasowe pamięci podręczne i poświadczenia. Razem te warstwy tworzą kontekst osobisty. Inny użytkownik powinien otrzymać inny pakiet kontekstowy, nawet gdy oba żądania przechodzą przez ten sam proces modelu.

To rozróżnienie utrzymuje architekturę praktyczną. Serwer domowy może uniknąć ładowania kilku identycznych kopii modelu, jednocześnie izolując dane, które czynią każdego asystenta osobistym. Granica izolacji należy do tożsamości, przechowywania, wyszukiwania, sesji i dostępu do narzędzi — nie do promptu, który jedynie nakazuje modelowi szanować prywatność.

Tożsamość musi podążać za żądaniem przez cały czas

Oddzielne ekrany logowania to tylko pierwszy krok. Uwierzytelnianie ustala, kto wykonuje żądanie; autoryzacja decyduje, do których czatów, plików, wspomnień i działań ta tożsamość ma dostęp. Skuteczna izolacja wymaga autoryzacji po uwierzytelnieniu na każdej granicy danych, nie tylko wtedy, gdy użytkownik otwiera interfejs.

Serwer powinien wyprowadzać stabilny identyfikator użytkownika z zweryfikowanej sesji lub tokena dostępu. Nie powinien ufać identyfikatorowi użytkownika przesłanemu w polu formularza, parametrze URL lub wiadomości czatu. W przeciwnym razie zmiana jednej wartości kontrolowanej przez klienta może wystarczyć do uzyskania dostępu do danych innej osoby.

Tożsamość pochodząca z serwera staje się wtedy częścią każdego wyszukiwania. Zapytania konwersacyjne, wyszukiwania wektorowe, ścieżki plików, klucze pamięci podręcznej i poświadczenia narzędzi muszą mieć ten sam zaufany zakres użytkownika. Jeśli jedna z usług pośrednich ją utraci, system cicho wraca do wspólnego kontekstu, mimo że interfejs nadal pokazuje oddzielne konta.

Trwała pamięć wymaga granicy na poziomie przechowywania

Pamięć długoterminowa zwykle znajduje się w relacyjnej bazie danych, magazynie dokumentów lub plikach na dysku. Każdy rekord musi mieć właściciela lub identyfikator najemcy, a każde odczytanie, aktualizacja i usunięcie musi być ograniczone do tej tożsamości. Filtrowanie dopiero po szerokim zapytaniu, które już zwróciło dane, jest za późne.

Polityki bazy danych mogą stanowić drugi punkt egzekwowania pod kodem aplikacji. Gdy baza danych ocenia bieżącego użytkownika przed zwróceniem rekordów, pominięty filtr w jednej ścieżce aplikacji ma mniejsze szanse na spowodowanie ujawnienia danych między użytkownikami.

Pamięć oparta na plikach wymaga tej samej dyscypliny. Przydziel każdemu użytkownikowi dedykowany katalog, zachowaj zasady własności i kontroli dostępu, a aplikacja powinna rozwiązywać ścieżki na podstawie uwierzytelnionej tożsamości. Nazwa folderu podana przez przeglądarkę nie stanowi granicy autoryzacji, a współdzielone konto serwisowe z nieograniczonym dostępem do systemu plików może ominąć starannie zorganizowane katalogi.

Pobieranie musi być ograniczone przed zbudowaniem promptu

RAG tworzy jeden z najważniejszych punktów izolacji, ponieważ pobrane fragmenty są wstawiane bezpośrednio do kontekstu roboczego modelu. Gdy dokument innego użytkownika trafi do promptu, proszenie modelu, by go nie ujawniał, nie jest niezawodnym rozwiązaniem. Warstwa pobierania musi go najpierw wykluczyć.

Warstwa RAG świadoma uprawnień może filtrować wyniki wyszukiwania według praw dostępu do dokumentów zanim jakikolwiek fragment zostanie wprowadzony do promptu. Decyzja o autoryzacji musi opierać się na zweryfikowanej sesji, a nie na tożsamości podanej w pytaniu.

Baza danych wektorów może oddzielać rekordy, przypisując jedną przestrzeń nazw lub kolekcję na użytkownika, lub stosując obowiązkowe filtry metadanych w ramach wspólnego indeksu. Przestrzenie nazw lub kolekcje dla izolacji ułatwiają określanie zakresu zapisu, wyszukiwania i usuwania, podczas gdy filtrowanie metadanych może wspierać kontrolowane udostępnianie, gdy gospodarstwo domowe lub zespół mają wspólne dokumenty.

Aplikacja powinna wybierać przestrzeń nazw z weryfikowanej sesji, a nie akceptować jej z prompta. Ta sama zasada dotyczy wyszukiwania semantycznego w prywatnych dokumentach: filtrowanie tożsamości należy umieścić w ścieżce zapytania przed rankingiem podobieństwa, a nie w kroku czyszczenia po zwróceniu wyników.

Współdzielone dokumenty również potrzebują wyraźnego modelu. Rekord może należeć do jednego użytkownika, grupy domowej lub przestrzeni roboczej, ale ten zakres powinien być przechowywany jako dane uprawnień i oceniany konsekwentnie. Kopiowanie dokumentu do kilku osobistych indeksów może być prostsze w małym systemie; uprawnienia oparte na grupach stają się łatwiejsze do utrzymania wraz ze wzrostem liczby użytkowników i współdzielonych folderów.

Sesje i pamięci podręczne mogą przypadkowo łączyć dane

Baza danych może być idealnie filtrowana, podczas gdy pamięć podręczna nadal wycieka kontekst. Jeśli historia czatu jest buforowana tylko pod `conversation_id`, dwóch użytkowników z kolizją lub przewidywalnym identyfikatorem może uzyskać dostęp do tego samego wpisu. Bezpieczniejsze klucze zawierają zarówno zaufany identyfikator użytkownika, jak i identyfikator rozmowy.

Ten sam zakres dotyczy pamięci podręcznych promptów, pamięci podręcznych pobranych fragmentów, tymczasowych katalogów przesyłania i obiektów sesji w pamięci. Klucze pamięci podręcznej świadome najemcy zmniejszają narażenie na wyciek między użytkownikami, przenosząc zaufany identyfikator użytkownika zarówno podczas odczytów, jak i zapisów pamięci podręcznej.

Wylogowanie musi usunąć lub unieważnić odpowiedni stan. Usunięcie ciasteczka przeglądarki przy pozostawieniu sesji po stronie serwera, plików tymczasowych lub pamięci podręcznej prompta może ujawnić kontekst poprzedniego użytkownika na współdzielonym komputerze. Wygasanie, usuwanie i usuwanie konta powinno propagować się przez wszystkie magazyny przechowujące dane osobowe.

Wywołania narzędzi muszą mieć ten sam zakres użytkownika

Asystent może odczytywać kalendarze, przeszukiwać e-maile, otwierać foldery NAS lub wywoływać automatyzacje. Te narzędzia mogą ujawniać więcej niż baza danych czatu, dlatego każde wywołanie musi korzystać z uprawnień użytkownika żądającego, a nie z pojedynczych poświadczeń administratora posiadanych przez usługę AI.

Dla lokalnych plików narzędzie powinno dziedziczyć lub wymuszać dostęp do systemu plików użytkownika. W przypadku połączonych aplikacji należy używać tokenów z zakresem użytkownika, jeśli integracja je obsługuje. Token globalny może być wygodny podczas testów, ale zamienia asystenta w obejście uprawnień, których użytkownicy oczekują od oryginalnej usługi.

Wyniki narzędzi również stają się kontekstem. Przechowuj je w tym samym zakresie użytkownika i sesji co żądanie, unikaj umieszczania sekretów w zwykłej historii czatu i redaguj wrażliwe pola w logach. Bezpieczna warstwa wyszukiwania nie rekompensuje narzędzia, które bezpośrednio zwraca dane innego użytkownika.

Który wzorzec izolacji pasuje do domowego serwera AI?

Właściwa granica zależy od wrażliwości, liczby użytkowników i tego, ile administracji może utrzymać właściciel serwera. Tabela porównuje popularne projekty pod kątem tego, co jest współdzielone i gdzie najczęściej pojawiają się błędy.

Dla większości domów reguły na poziomie wiersza, wyszukiwanie wektorowe z zakresem użytkownika, izolowane ścieżki plików i uprawnienia narzędzi specyficzne dla użytkownika stanowią praktyczny kompromis. Kontenery lub oddzielne maszyny stają się wartościowe, gdy użytkownicy nie ufają sobie nawzajem, narzędzia wykonują dowolny kod lub konsekwencje błędu są wyjątkowo poważne.

Dlaczego oddzielne konta nadal wyciekają kontekst

Pierwszym błędem jest stosowanie uprawnień tylko w interfejsie. Ukrywanie rozmów innego użytkownika w pasku bocznym nic nie daje, jeśli API zwróci je po podaniu innego ID. Każdy punkt końcowy serwera musi powtarzać decyzję o autoryzacji.

Drugim błędem jest filtrowanie historii czatu, ale nie wyszukiwania. Asystent wyświetla poprawną rozmowę, ale przeszukuje wspólny indeks wektorowy bez filtra użytkownika. Odpowiedź zawiera wtedy prywatne dane, które nigdy nie pojawiły się w widocznym wątku.

Trzecią porażką są współdzielone dane operacyjne. Logi debugowania, ślady, pamięci podręczne promptów, tymczasowe przesyłania i analizy mogą zawierać ten sam wrażliwy kontekst co ostateczna odpowiedź. Kontekst działania może ujawniać wrażliwe informacje nawet jeśli model bazowy nigdy na nich nie był trenowany.

Ostatnią porażką jest zaufanie modelowi jako warstwie kontroli dostępu. Prompt systemowy może opisać oczekiwania dotyczące prywatności, ale nie może niezawodnie cofnąć kontekstu, który nigdy nie powinien był zostać pobrany. Kontrole bezpieczeństwa muszą decydować, co trafia do modelu; model nie powinien decydować, co użytkownik miał prawo pobrać.

Jak przetestować, czy izolacja użytkowników naprawdę działa

Utwórz dwa zwykłe konta z celowo różnymi danymi testowymi. Daj Użytkownikowi A dokument zawierający unikalną, nieszkodliwą frazę, a Użytkownikowi B inną frazę. Żadna z fraz nie powinna występować nigdzie indziej w korpusie testowym.

Z konta Użytkownika B spróbuj bezpośrednich pytań, niejasnych wyszukiwań semantycznych, zgadywanych identyfikatorów rozmów, udostępnionych linków, zmienionych nazw plików oraz żądań, które proszą asystenta o zignorowanie jego zasad. Celem jest nie tylko przetestowanie normalnego interfejsu; chodzi o weryfikację, że każda ścieżka nie zwraca danych spoza zakresu Użytkownika B.

Powtórz test po wylogowaniu, restarcie usługi, rozgrzaniu pamięci podręcznej, ponownym indeksowaniu dokumentów, przywróceniu kopii zapasowej i usunięciu konta. Te przejścia często używają innych ścieżek kodu niż zwykły czat i mogą ponownie wprowadzać przestarzały kontekst, który główna ścieżka zapytań obsługuje poprawnie.

Przeglądaj logi serwera z tymi samymi dwoma tożsamościami. Każde pobranie, odczyt pliku, zapis w pamięci i wywołanie narzędzia powinno zawierać oczekiwany zakres użytkownika bez niepotrzebnego zapisywania prywatnych treści promptów. Administrator powinien być w stanie wyjaśnić, dlaczego każdy element kontekstu trafił do ostatecznego promptu.

Praktyczny projekt izolacji do użytku domowego

Zacznij od utrzymywania wykonywania modelu i danych lokalnie, następnie użyj jednej usługi tożsamości i jednego zaufanego identyfikatora użytkownika, który serwer wyprowadza z sesji. Przekazuj tę tożsamość przez usługę czatu, magazyn pamięci, wyszukiwanie wektorowe, bramę plików i warstwę narzędzi. Odrzucaj żądania, gdy brakuje tożsamości lub zakresu uprawnień, zamiast wracać do wspólnego domyślnego ustawienia.

Utrzymuj model współdzielony, chyba że konkretne zagrożenie wymaga oddzielnych środowisk uruchomieniowych. Otaczający stos magazynowania, pobierania, inferencji, interfejsu i uprawnień to to, co zamienia lokalne pliki w prywatnego asystenta opierającego się na lokalnych danych. Duplikowanie wag modelu nie naprawia zapytania do bazy danych bez zakresu.

Używaj identyfikatora użytkownika lub przestrzeni roboczej na trwałych rekordach, egzekwuj dostęp do wierszy poniżej aplikacji, jeśli to możliwe, i umieszczaj dane wektorowe w przestrzeniach nazw z zakresem użytkownika lub obowiązkowo filtrowanych partycjach. Nadaj plikom tymczasowym i buforom ten sam zakres, a następnie ustaw zasady wygasania i usuwania dla każdej warstwy.

Oddzielaj celowo wiedzę osobistą i współdzieloną. Podręcznik gospodarstwa domowego może należeć do wspólnej przestrzeni roboczej, podczas gdy dokumenty podatkowe pozostają prywatne. W serwerze AI z wieloma rolami członkostwo w grupie powinno decydować, która współdzielona przestrzeń robocza dołącza do osobistego kontekstu użytkownika dla danego zapytania.

Wybierz silniejszą granicę, gdy zmienia się zagrożenie. Jeśli użytkownicy mogą uruchamiać kod, instalować wtyczki, montować dowolne foldery lub łączyć potężne narzędzia, same filtry aplikacji mogą nie wystarczyć. Oddzielne kontenery, maszyny wirtualne, poświadczenia i magazyny mogą ograniczyć, do czego ma dostęp skompromitowana usługa.

FAQ

Czy każdy użytkownik potrzebuje osobnej kopii modelu AI?

Nie. Wielu użytkowników może korzystać z jednego modelu inferencyjnego, ponieważ osobisty kontekst może być składany oddzielnie dla każdego zapytania. Oddzielne procesy modelu mogą być nadal przydatne dla nieufnych użytkowników, niestandardowych adapterów, ścisłych limitów zasobów lub zadań wymagających silniejszej granicy operacyjnej.

Czy oddzielna historia czatu wystarczy, by chronić osobisty kontekst?

Nie. Historia czatu to tylko jedno źródło kontekstu. Pobierane dokumenty, indeksy wektorowe, przesłane pliki, bufory, poświadczenia narzędzi, logi i dane tymczasowe muszą podlegać tym samym granicom tożsamości. Jedna warstwa bez zakresu może ujawnić informacje, nawet gdy widoczna lista rozmów jest poprawna.

Czy członkowie rodziny mogą celowo udostępniać jakiś kontekst?

Tak. Umieść udostępnione dokumenty i wspomnienia w wyraźnym zakresie gospodarstwa domowego lub przestrzeni roboczej, a następnie przyznaj członkostwo użytkownikom, którzy tego potrzebują. Zachowaj osobiste dane pod indywidualną własnością. Kreator promptów może łączyć prywatny zakres bieżącego użytkownika z autoryzowanymi zakresami współdzielonymi, nie udostępniając ich wszystkim.

Praktyczna zasada jest prosta: udostępniaj model, nie ścieżkę kontekstu. Tożsamość musi ograniczać dane zanim zostaną odczytane, pobrane, zbuforowane lub przekazane do narzędzia. Jeśli każda warstwa potrafi odpowiedzieć, który użytkownik autoryzował element, domowy serwer AI może pozostać osobisty, nawet gdy jego moc obliczeniowa jest współdzielona.