Como é que um servidor de IA doméstico mantém o contexto de cada utilizador separado?

Um servidor de IA doméstico pode manter o contexto de cada utilizador separado enquanto partilha o mesmo modelo, mas a separação não vem do próprio modelo. Vem da ligação de cada chat, registo de memória, documento recuperado, entrada de cache e chamada de ferramenta a um utilizador autenticado antes que essa informação chegue ao prompt.

Se duas pessoas podem iniciar sessão separadamente, mas a pergunta de um utilizador recupera as notas de outra pessoa, a falha está geralmente na aplicação em torno do modelo. O teste útil é se a identidade sobrevive a todo o caminho do pedido. Este artigo segue esse caminho e mostra onde o isolamento deve ser aplicado, onde normalmente falha e quando um limite mais forte é justificado.

O Modelo Pode Ser Partilhado, mas o Contexto Pessoal Não Pode

Os pesos do modelo são o motor comum de raciocínio. Não precisam de uma cópia separada para cada membro da família ou colega quando o modelo está a servir pedidos de inferência comuns. O que deve permanecer separado é a informação reunida em torno desses pesos para um pedido específico.

Essa informação inclui o chat atual, histórico de conversas guardado, preferências do utilizador, passagens de ficheiros recuperadas, resultados de pesquisa vetorial, saídas de ferramentas, caches temporários e credenciais. Juntas, estas camadas formam o contexto pessoal. Um utilizador diferente deve receber um pacote de contexto diferente mesmo quando ambos os pedidos passam pelo mesmo processo do modelo.

Esta distinção mantém a arquitetura prática. Um servidor doméstico pode evitar carregar várias cópias idênticas do modelo enquanto ainda isola os dados que tornam cada assistente pessoal. O limite de isolamento pertence à identidade, armazenamento, recuperação, sessões e acesso a ferramentas — não a um prompt que apenas diz ao modelo para respeitar a privacidade.

A Identidade Deve Acompanhar o Pedido Até ao Fim

Ecrãs de login separados são apenas o primeiro passo. A autenticação estabelece quem está a fazer o pedido; a autorização decide a que chats, ficheiros, memórias e ações essa identidade pode aceder. O isolamento eficaz requer autorização após a autenticação em cada limite de dados, não apenas quando o utilizador abre a interface.

O servidor deve derivar um ID de utilizador estável a partir da sessão verificada ou do token de acesso. Não deve confiar num ID de utilizador enviado num campo de formulário, parâmetro de URL ou mensagem de chat. Caso contrário, alterar um valor controlado pelo cliente pode ser suficiente para solicitar os registos de outra pessoa.

Essa identidade derivada do servidor torna-se então parte de cada pesquisa. Consultas de conversação, pesquisas vetoriais, caminhos de ficheiros, chaves de cache e credenciais de ferramentas precisam todos do mesmo âmbito de utilizador confiável. Se um serviço a jusante a perder, o sistema regressa silenciosamente a um contexto partilhado, mesmo que a interface continue a mostrar contas separadas.

A Memória Duradoura Precisa de uma Fronteira ao Nível do Armazenamento

A memória a longo prazo geralmente reside numa base de dados relacional, armazenamento de documentos ou ficheiros no disco. Cada registo precisa de um identificador de proprietário ou inquilino, e cada leitura, atualização e eliminação deve ser restrita a essa identidade. Filtrar apenas depois de uma consulta ampla já ter retornado dados é demasiado tarde.

As políticas da base de dados podem fornecer um segundo ponto de aplicação abaixo do código da aplicação. Quando a base de dados avalia o utilizador atual antes de devolver registos, uma falha de filtro numa rota da aplicação tem menos hipótese de se tornar numa divulgação entre utilizadores.

A memória baseada em ficheiros precisa da mesma disciplina. Dê a cada utilizador um diretório dedicado, mantenha as regras de propriedade e controlo de acesso intactas, e faça a aplicação resolver os caminhos a partir da identidade autenticada. Um nome de pasta fornecido pelo navegador não é uma fronteira de autorização, e uma conta de serviço partilhada com acesso irrestrito ao sistema de ficheiros pode contornar diretórios cuidadosamente organizados.

A Recuperação Deve Ser Delimitada Antes de o Prompt Ser Construído

O RAG cria um dos pontos de isolamento mais importantes porque as passagens recuperadas são inseridas diretamente no contexto de trabalho do modelo. Uma vez que o documento de outro utilizador chega ao prompt, pedir ao modelo para não o revelar não é uma correção fiável. A camada de recuperação deve excluí-lo primeiro.

Uma camada RAG consciente de permissões pode filtrar resultados de pesquisa pelos direitos de acesso ao documento antes de qualquer passagem entrar no prompt. A decisão de autorização deve usar a sessão verificada em vez de uma identidade fornecida na pergunta.

Uma base de dados vetorial pode separar registos com um namespace ou coleção por utilizador, ou com filtros obrigatórios de metadados dentro de um índice partilhado. Namespaces ou coleções para isolamento facilitam a delimitação de escritas, pesquisas e eliminações, enquanto o filtro de metadados pode suportar partilha controlada quando uma família ou equipa tem documentos comuns.

A aplicação deve escolher o namespace a partir da sessão verificada em vez de aceitá-lo do prompt. A mesma regra aplica-se quando a pesquisa semântica é feita sobre documentos privados: o filtro de identidade pertence ao caminho da consulta antes da classificação por similaridade, não numa etapa de limpeza após o retorno dos resultados.

Documentos partilhados também precisam de um modelo explícito. Um registo pode pertencer a um utilizador, a um grupo familiar ou a um espaço de trabalho, mas esse âmbito deve ser guardado como dados de permissão e avaliado de forma consistente. Copiar um documento para vários índices pessoais pode ser mais simples para um sistema pequeno; permissões baseadas em grupo tornam-se mais fáceis de manter à medida que os utilizadores e pastas partilhadas crescem.

Sessões e Caches Podem Reunir Dados por Acidente

Uma base de dados pode estar perfeitamente filtrada enquanto um cache ainda vaza contexto. Se o histórico de chat for guardado em cache apenas sob `conversation_id`, dois utilizadores com uma colisão ou identificador previsível podem aceder à mesma entrada. Chaves mais seguras incluem tanto o ID de utilizador confiável como o ID da conversa.

O mesmo limite aplica-se a caches de prompt, caches de fragmentos recuperados, diretórios temporários de upload e objetos de sessão em memória. Chaves de cache conscientes do inquilino reduzem a exposição entre utilizadores ao transportar o ID de utilizador confiável tanto nas leituras como nas escritas do cache.

O logout deve remover ou invalidar o estado correto. Limpar um cookie do navegador enquanto mantém a sessão do lado do servidor, ficheiros temporários ou prompt em cache disponíveis pode expor o contexto do utilizador anterior num computador partilhado. A expiração, eliminação e remoção da conta devem propagar-se por todas as lojas que guardam dados pessoais.

As Chamadas de Ferramentas Precisam do Mesmo Limite de Utilizador

Um assistente pode ler calendários, pesquisar emails, abrir pastas NAS ou ativar automações. Essas ferramentas podem revelar mais do que a base de dados do chat, por isso cada chamada deve usar as permissões do utilizador que faz o pedido em vez de uma única credencial de administrador detida pelo serviço de IA.

Para ficheiros locais, a ferramenta deve herdar ou impor o acesso ao sistema de ficheiros do utilizador. Para aplicações ligadas, utilize tokens com escopo de utilizador quando a integração os suportar. Um token global pode ser conveniente durante os testes, mas transforma o assistente numa forma de contornar as permissões que os utilizadores esperam do serviço original.

A saída da ferramenta também se torna contexto. Armazene-a sob o mesmo utilizador e escopo de sessão do pedido, evite colocar segredos no histórico de chat comum e redija campos sensíveis dos registos. Uma camada de recuperação segura não compensa uma ferramenta que devolve diretamente dados de outro utilizador.

Qual Padrão de Isolamento se Ajusta a um Servidor de IA Doméstico?

A fronteira certa depende da sensibilidade, do número de utilizadores e de quanto administração o proprietário do servidor pode manter. A tabela compara designs comuns pelo que é partilhado e onde os erros são mais prováveis.

Para a maioria das casas, regras ao nível da linha, recuperação vetorial com escopo de utilizador, caminhos de ficheiros isolados e permissões de ferramentas específicas do utilizador fornecem um meio-termo prático. Contentores ou máquinas separadas tornam-se valiosos quando os utilizadores não confiam uns nos outros, as ferramentas executam código arbitrário ou as consequências de um erro são incomumente elevadas.

Por que as Contas Separadas Ainda Vazam Contexto

A primeira falha é aplicar permissões apenas na interface. Ocultar as conversas de outro utilizador numa barra lateral não serve de nada se a API as devolver quando for fornecido um ID diferente. Cada endpoint do servidor deve repetir a decisão de autorização.

A segunda falha é filtrar o histórico de chat, mas não a recuperação. O assistente mostra a conversa correta, mas pesquisa num índice vetorial partilhado sem um filtro de utilizador. A resposta contém então detalhes privados que nunca apareceram no tópico visível.

A terceira falha é a partilha de dados operacionais. Registos de depuração, rastreamentos, caches de prompt, carregamentos temporários e análises podem conter o mesmo contexto sensível que a resposta final. O contexto em tempo de execução pode expor informações sensíveis mesmo quando o modelo base nunca foi treinado com ele.

A última falha é confiar no modelo como uma camada de controlo de acesso. Um prompt do sistema pode descrever expectativas de privacidade, mas não pode desfazer de forma fiável o contexto que nunca deveria ter sido recuperado. Os controlos de segurança devem decidir o que chega ao modelo; o modelo não deve decidir o que o utilizador foi autorizado a recuperar.

Como Testar se o Isolamento de Utilizadores Funciona Realmente

Crie duas contas ordinárias com dados de teste deliberadamente diferentes. Dê ao Utilizador A um documento contendo uma frase única e inofensiva e ao Utilizador B uma frase diferente. Nenhuma das frases deve ocorrer em mais nenhum lugar no corpus de teste.

A partir do Utilizador B, tente perguntas diretas, pesquisas semânticas vagas, IDs de conversa adivinhados, links partilhados, ficheiros renomeados e pedidos que peçam ao assistente para ignorar as suas regras. O objetivo não é apenas testar a interface normal; é verificar que cada rota não retorna dados fora do âmbito do Utilizador B.

Repita o teste após logout, reinício do serviço, aquecimento da cache, reindexação de documentos, restauração de backup e eliminação de conta. Estas transições frequentemente usam caminhos de código diferentes do chat normal e podem reintroduzir contexto obsoleto que o caminho principal da consulta trata corretamente.

Revise os registos do servidor com as mesmas duas identidades. Cada recuperação, leitura de ficheiro, escrita de memória e chamada de ferramenta deve transportar o âmbito de utilizador esperado sem registar desnecessariamente conteúdos privados do prompt. Um administrador deve ser capaz de explicar por que cada item de contexto entrou no prompt final.

Um Design Prático de Isolamento para Uso Doméstico

Comece por manter a execução do modelo e os dados localmente, depois use um serviço de identidade e um ID de utilizador confiável que o servidor derive da sessão. Passe essa identidade pelo serviço de chat, armazenamento de memória, pesquisa vetorial, gateway de ficheiros e camada de ferramentas. Rejeite pedidos quando a identidade ou o âmbito de permissão estiverem em falta, em vez de recorrer a um padrão partilhado.

Mantenha o modelo partilhado a menos que uma ameaça específica exija ambientes de execução separados. A pilha envolvente de armazenamento, recuperação, inferência, interface e permissões é o que transforma ficheiros locais num assistente privado baseado em dados locais. Duplicar pesos do modelo não corrige uma consulta a base de dados sem âmbito.

Use um identificador de utilizador ou espaço de trabalho em registos duráveis, aplique o acesso a linhas abaixo da aplicação sempre que possível, e coloque dados vetoriais em namespaces com âmbito de utilizador ou partições filtradas obrigatórias. Dê aos ficheiros temporários e caches o mesmo âmbito, depois defina regras de expiração e eliminação para cada camada.

Separe intencionalmente o conhecimento pessoal e partilhado. Um manual do agregado familiar pode pertencer a um espaço de trabalho comum, enquanto os registos fiscais permanecem privados. Numa servidor de IA multi-função, a adesão a grupos deve determinar qual espaço de trabalho partilhado se junta ao contexto pessoal do utilizador para esse pedido.

Escolha uma fronteira mais forte quando a ameaça mudar. Se os utilizadores puderem executar código, instalar plugins, montar pastas arbitrárias ou ligar ferramentas poderosas, apenas filtros de aplicação podem não ser suficientes. Contentores separados, máquinas virtuais, credenciais e armazenamento podem limitar o que um serviço comprometido consegue alcançar.

Perguntas Frequentes

Cada utilizador precisa de uma cópia separada do modelo de IA?

Não. Vários utilizadores podem partilhar um modelo de inferência porque o contexto pessoal pode ser montado separadamente para cada pedido. Processos de modelo separados podem ainda ser úteis para utilizadores não confiáveis, adaptadores personalizados, limites rigorosos de recursos ou cargas de trabalho que exijam uma fronteira operacional mais forte.

Um histórico de conversas separado é suficiente para proteger o contexto pessoal?

Não. O histórico de conversas é apenas uma fonte de contexto. Documentos recuperados, índices vetoriais, ficheiros carregados, caches, credenciais de ferramentas, registos e dados temporários devem seguir a mesma fronteira de identidade. Uma camada sem âmbito pode expor informação mesmo quando a lista visível de conversas está correta.

Os membros da família podem partilhar intencionalmente algum contexto?

Sim. Coloque documentos e memórias partilhados num âmbito explícito de agregado familiar ou espaço de trabalho, depois conceda a adesão aos utilizadores que dela necessitam. Mantenha os registos pessoais sob propriedade individual. O construtor de prompts pode combinar o âmbito privado do utilizador atual com os âmbitos partilhados autorizados sem abrir nenhum deles a todos.

A regra prática é simples: partilhar o modelo, não o caminho do contexto. A identidade deve restringir os dados antes de serem lidos, recuperados, armazenados em cache ou passados para uma ferramenta. Se cada camada puder responder qual utilizador autorizou um item, um servidor de IA doméstico pode permanecer pessoal mesmo quando o seu processamento é partilhado.