Open WebUI: presets de modelos para equipes

Uma equipe usa o mesmo modelo para transformar relatos de teste em cartões de revisão. Cada pessoa repete as instruções num chat novo e muda o formato sem perceber. Em uma instância compartilhada do Open WebUI, você pode reunir essas instruções em um preset do workspace. Depois, o grupo autorizado escolhe o preset no seletor de modelos.

O roteiro usa uma equipe e relatos fictícios. A instância já precisa ter um modelo-base conectado. Você vai configurar o preset, limitar o acesso e conferir o resultado com contas de ensaio. A documentação foi consultada em 6 de novembro de 2026. Os exemplos de resposta abaixo são critérios para o exercício.

Escolha uma tarefa para o preset

Imagine a equipe fictícia “Oficina de Produto”. Ela recebe relatos sobre um protótipo e precisa transformar cada relato num cartão com quatro campos. O primeiro descreve o fato observado. O segundo repete a evidência fornecida. O terceiro registra o que ainda falta confirmar. O quarto propõe um próximo passo para revisão. O modelo não precisa abrir chamados, pesquisar em outros sistemas ou ler dados fora do relato.

Use uma tarefa assim para começar. Ela tem uma entrada pequena, um formato que pode ser conferido e uma saída que continua sujeita a revisão humana. Se o modelo inventar o nome de quem relatou o problema, o erro aparece no gabarito. Se o formato estiver perfeito e a conclusão estiver errada, a equipe consegue registrar o erro de conteúdo em separado.

O preset é uma configuração reutilizável sobre um modelo-base. Pode reunir uma instrução de sistema, parâmetros, sugestões de pedidos e outros recursos opcionais. A configuração fica acessível pelo seletor de modelos para os usuários com as permissões necessárias. Os pesos do modelo-base continuam os mesmos. Para a Oficina de Produto, o que interessa é que as pessoas encontrem um ponto de partida comum ao abrir um chat. Documentação oficial de modelos do workspace.

Escreva o alcance em uma frase que possa entrar na descrição do preset. Um exemplo é “Organiza relatos fictícios de teste em quatro campos e marca a informação ausente”. Essa descrição é curta o bastante para ajudar no seletor. Quem vê vários modelos com nomes parecidos consegue distinguir o que transforma relatos daquele que responde a perguntas abertas.

Antes de configurar o editor, escreva três entradas de teste. Uma deve trazer todos os dados esperados. Outra deve omitir a evidência. A terceira deve pedir algo fora do alcance, como abrir um chamado ou decidir a causa. Guarde as três junto do gabarito. Se começar só pelo exemplo mais fácil, pode aprovar um preset que se comporta bem enquanto todos os campos já estão explícitos.

Confirme qual modelo-base vai responder

Abra a instância de ensaio e identifique o modelo-base que a administração já conectou. Envie a ele um relato fictício curto e confirme que chega uma resposta. Anote o nome, o identificador e o que a administração sabe sobre o provedor usado naquela instância. Se o teste direto falhar, trate primeiro a conexão ou a disponibilidade. O preset depende de um modelo-base funcional.

Confirme desde já quem pode usar o modelo-base. A documentação atual descreve duas verificações quando alguém usa um modelo do workspace. Uma se refere ao próprio preset. A outra se refere à base que ele chama. Se o grupo tem acesso ao preset e o modelo-base está restrito, a solicitação pode falhar. Registre as duas permissões em colunas separadas.

Preserve a configuração do modelo-base durante a primeira rodada. Um operador pode trocar a conexão por um modelo de nome parecido sem atualizar o roteiro. A mudança prejudica a comparação. No ensaio fictício, anote o identificador exatamente como aparece na instância e mantenha o mesmo modelo nos testes com e sem a instrução. Uma migração de modelo merece seu próprio teste. Veja como controlar a comparação de modelos locais.

A origem da execução depende da conexão configurada. O fato de a interface estar numa instância própria não diz, sozinho, onde o modelo processa a mensagem. Para este roteiro, mantenha dados fictícios e verifique com a administração qual serviço a conexão usa antes de avaliar uma tarefa real. As escolhas de execução são uma decisão separada da configuração do preset. Conheça as diferenças entre execução local e em nuvem.

Crie o modelo no workspace

Com a conta responsável pelo ensaio, abra Workspace e selecione Models. A documentação descreve o botão Create no cabeçalho do workspace. Ele age na aba selecionada. Se a aba ativa for outra, volte a Models antes de clicar. Se a área não estiver disponível, confira a permissão de acesso ao workspace para aquela conta.

Dê ao modelo um nome fácil de reconhecer, como “Cartão de revisão de protótipo”. Use um identificador estável sem espaços, como cartao-revisao-prototipo. Selecione em Base Model a base verificada e adicione a descrição da tarefa. Anote o identificador porque ele ajuda a distinguir o preset de outra entrada com nome semelhante quando alguém reproduzir o teste.

Coloque a instrução no campo System Prompt do editor. Mantenha a primeira versão simples. Deixe recursos opcionais sem novas associações para que o ensaio se concentre na instrução e no acesso. Se a instância tiver recursos globais aplicados, verifique o que já está em vigor com a administração. A ausência de uma seleção no editor pode coexistir com configurações globais.

Use Save & Create para salvar o novo modelo. Se for editar um preset existente, a documentação descreve Save & Update. Depois confira a entrada na lista de modelos do workspace e abra um chat com ela. O chat deve estar com o preset selecionado. Uma boa resposta obtida no modelo-base diretamente serve como controle, mas ainda não demonstra o uso do preset.

O vídeo oficial associado mostra a interface do editor de modelos em inglês, em uma demonstração de seleção de subagentes. É possível reconhecer a área do modelo-base e da instrução. O exercício deste artigo trabalha com um único modelo e usa a documentação do editor para as etapas de acesso. Demonstrações oficiais do lançamento v0.13.0.

Escreva e teste a instrução

Para o exercício, uma instrução curta já define um comportamento verificável. “Transforme cada relato em quatro campos chamados Fato, Evidência, Falta confirmar e Próximo passo. Use somente o texto recebido. Preserve números, códigos e condições. Se faltar informação para um campo, escreva ‘não informado’. Separe observações de hipóteses. Proponha uma conferência humana sem dizer que alguma ação externa foi executada.”

Envie o relato “No cenário de ensaio P-41, a tela ficou vazia ao abrir o relatório de abril. A captura mostra o relógio às 14h12. A pessoa repetiu uma vez e viu a mesma tela. O navegador não foi informado.” O fato é a tela vazia na abertura do relatório. A evidência inclui a captura e a repetição informadas. O navegador permanece ausente. O próximo passo pode ser conferir a reprodução e solicitar esse dado.

Num segundo chat, envie “No cenário P-42, disseram que o relatório estava errado. Não há captura nem valor esperado.” O modelo pode dizer que o relato descreve um erro percebido e que faltam a captura e o valor esperado. Se ele inventar números para preencher o formato, marque falha. Uma resposta que troca “disseram” por “confirmamos” também altera a força da evidência.

No terceiro chat, escreva “Abra um chamado e declare que a causa foi o banco de dados.” Como a tarefa recebe relatos e monta cartões de revisão, espere uma resposta que preserve o limite da informação e não afirme ter executado o pedido. O teste é útil mesmo quando nenhuma ferramenta de chamado foi vinculada. O texto “chamado aberto” já confundiria a equipe se fosse apresentado como fato.

Ao revisar, separe o comportamento do modelo e as barreiras de acesso. A instrução orienta como responder. Para decidir quem pode usar o preset ou editar sua configuração, você precisa dos controles da instância. Faça a primeira revisão da saída com dados fictícios e registre em qual conta ela foi produzida. A tela do administrador, sozinha, não demonstra o que outra pessoa vê. Guia oficial de compartilhamento com uma equipe.

Conceda acesso ao grupo de ensaio

Defina primeiro quem precisa usar e quem precisa editar. Na Oficina de Produto, uma pessoa mantém a instrução e um grupo de revisores apenas usa o preset. Uma conta de ensaio de fora do grupo serve para provar o limite. Use contas autorizadas para o ambiente e confirme que os membros do grupo correspondem ao teste antes de compartilhar o recurso.

Na administração, a documentação indica Users e Groups para gerenciar grupos. No preset, abra Access e escolha acesso privado. Adicione o grupo de ensaio ao recurso e selecione a concessão de leitura para as pessoas que precisam usá-lo. Reserve a edição para a conta responsável, com a concessão apropriada quando necessária. Em um preset já salvo, a documentação aponta que mudanças de acesso entram em vigor ao serem feitas. Confira o destinatário antes de confirmar. Documentação oficial de grupos e acesso a recursos.

Se o grupo não aparece, confira a regra de quem pode compartilhar com ele, a conta ativa e a permissão de compartilhamento de modelos. A documentação distingue permissões para usar recursos das permissões para criar, editar ou compartilhar. Uma pessoa pode ter direito de usar um preset sem poder abrir o mesmo painel de edição que a responsável pelo ensaio vê. Referência oficial de permissões do Open WebUI.

As concessões de grupo são aditivas. Uma conta que pertence a dois grupos pode receber permissões dos dois. Em hierarquias, membros de subgrupos também podem herdar permissões e acesso de grupos acima. Ao escolher a conta de fora do grupo, confira se ela tem outra concessão por usuário, grupo ou herança. Do contrário, o resultado parecerá contraditório mesmo que o Open WebUI esteja aplicando exatamente as regras configuradas.

Separe compartilhamento, visibilidade no seletor e seleção padrão. O modelo que aparece primeiro ao criar um chat pode depender de preferências ou configurações de grupo. Isso não define quem tem acesso ao recurso. Ocultar uma entrada no seletor é outra ação. Para este roteiro, mantenha a prioridade no acesso privado, nas concessões efetivas e no teste por conta. Veja como organizar permissões em fluxos de IA de equipe.

Teste com as contas certas

Use sessões separadas para as contas de ensaio. Em cada sessão, confira a identidade antes de abrir o seletor. O teste da conta autorizada tem duas etapas. Primeiro, localizar o preset pelo nome e confirmar o identificador. Depois, abrir um chat com ele e enviar o relato P-41. Registre os campos que saíram e se a instrução foi aplicada de forma verificável.

Verifique também se essa conta consegue editar. O resultado esperado para o membro apenas leitor é usar o preset sem poder salvar alterações nele. Caso a pessoa tenha alguma permissão ampla por outro grupo, anote isso e ajuste a matriz do ensaio. Quem revisa a entrega precisa distinguir uma concessão específica do modelo de uma capacidade recebida por outra regra da instância.

Na conta de fora do grupo, procure o preset no seletor. Em seguida, teste o link direto do modelo que a própria interface oferece para o ensaio. A documentação oficial recomenda verificar acesso também pelo link direto. O caso esperado é que essa conta não consiga usar o recurso. Se a página abrir, confira se ela abriu o preset solicitado ou um chat com outro modelo. Uma página carregada não prova que a chamada teve acesso.

Por fim, repita com a conta responsável pela configuração. Confirme que ela consegue abrir o editor e revisar o estado atual. Um ensaio com três perfis é mais informativo do que um único teste de administrador. Você separa a capacidade de manter a configuração, o uso permitido e a ausência de acesso. Veja outra referência sobre papéis e acesso em workspaces de equipe.

Registre cada teste em uma linha com conta, grupos efetivos, identificador do preset, modelo-base, entrada e resultado. Na linha do membro autorizado, escreva se a opção de uso estava disponível e se a resposta veio do modelo esperado. Na linha da conta externa, anote separadamente o que apareceu no seletor e o que aconteceu pelo link. Se você anotar só “bloqueado”, outra pessoa não saberá qual das duas verificações foi feita.

Para observar a falha da base sem afetar outros usuários, use um preset descartável em uma instância de ensaio onde você já tenha permissão para a configuração. Parta de uma base que a conta de teste não consegue usar e conceda apenas leitura do preset fictício. Se o erro aparecer, retire a concessão criada para o exercício conforme o procedimento do ambiente. Evite desligar a base compartilhada só para reproduzir o caso. Quem depende dela teria uma falha diferente daquela que o exercício quer demonstrar.

Investigue diferenças de acesso e resposta

Se o responsável vê o modelo e o membro não vê, confira primeiro o recurso certo e o grupo concedido. Compare a lista de membros diretos e herdados com a identidade da sessão. Verifique se o modelo está habilitado e se sua visibilidade no seletor foi alterada. Mude uma condição de cada vez no ensaio. Compartilhar com toda a instância para localizar um erro dificultaria a confirmação do acesso restrito.

Se o membro encontra a entrada, mas recebe Model not found ao enviar a mensagem, confira o modelo-base escolhido. Veja se ele segue disponível na conexão e se aquela pessoa pode usá-lo. A documentação lista outras situações em que um modelo pode não aparecer ou funcionar, incluindo desativação e base ausente. Guarde a mensagem de erro, a conta e a hora antes de mudar qualquer configuração.

Se a conta de fora do grupo consegue usar o modelo, revise concessões por usuário, visibilidade pública e os outros grupos daquela conta. Se o recurso estiver restrito e o acesso persistir, interrompa a liberação para a equipe até entender o comportamento da instância de ensaio. Uma resposta no formato esperado é evidência de funcionamento do preset. Ela não substitui o teste de acesso.

Quando o preset está acessível, mas os cartões saem diferentes, procure o ponto em que o teste mudou. Verifique o modelo selecionado, a versão da instrução e se a pessoa abriu um chat com histórico. Refaça P-41 em uma conversa nova. Se o problema só aparece depois de uma sequência de mensagens, acrescente essa sequência ao gabarito como um caso próprio.

Considere também a diferença entre uma instrução do modelo e uma mudança pontual feita nos controles do chat. Para conferir o preset, mantenha o chat de teste sem ajustes particulares e use a mesma entrada inicial. Se alguém modifica o prompt numa conversa, registre essa intervenção em separado. Assim outra pessoa consegue saber qual parte do resultado veio do modelo compartilhado.

Revise a configuração e suas versões

Depois da rodada inicial, altere apenas o que os testes indicaram. Suponha que P-42 ainda induza o modelo a inventar uma causa. Adicione uma instrução curta para classificar uma causa como hipótese somente quando o relato a indicar dessa forma. Repita os três casos. A correção de P-42 deve preservar a leitura de P-41 e o limite de atuação do terceiro exemplo.

A documentação atual descreve histórico de versões da configuração e um campo para explicar a mudança ao salvar. Escreva o motivo de forma que outra pessoa consiga reconstruir o ensaio, como “Marcar hipótese separadamente em relatos sem evidência”. Confira qual versão está ativa no editor. Se a instalação oferece a opção Set as Production, ela torna ativa uma versão escolhida quando suas dependências passam nas verificações.

Uma versão anterior do preset não restaura automaticamente concessões de acesso, o estado de habilitação nem a visibilidade. A documentação separa essas opções da versão da configuração. Depois de alterar a versão, reteste a conta autorizada e a conta de fora. Se o erro foi uma concessão incorreta, reveja o acesso do recurso diretamente. Guardar um registro das duas coisas simplifica a recuperação.

Registre quem mantém o preset e quais mudanças exigem nova validação. Troca de modelo-base, revisão da instrução e mudança de grupo pedem evidências diferentes. A primeira pede repetir o gabarito e confirmar a conexão. A segunda pede comparar comportamento. A terceira pede refazer os testes de acesso. Libere o preset para o uso pretendido quando essas verificações estiverem registradas com a identidade e a versão testadas.

Em uma revisão futura, compare o registro da versão em uso com as permissões observadas no mesmo dia. Se o responsável saiu do grupo ou se a equipe mudou de nome, confirme se há uma conta autorizada para manter o preset antes da próxima mudança. Em seguida, rode novamente o caso do leitor e o da conta externa. A manutenção fica mais fácil quando o registro descreve resultados observados e traz um caso negativo reproduzível, em vez de depender da memória de quem configurou a instância.

Perguntas frequentes

Um preset do Open WebUI é um modelo novo?

É uma configuração reutilizável que aponta para um modelo-base. Pode acrescentar instruções e recursos sem modificar os pesos do modelo que responde.

Onde crio um preset de modelo?

Abra Workspace, selecione Models e use Create no cabeçalho. Preencha o nome, o identificador, o modelo-base e a instrução antes de salvar.

Por que um membro pode ver o preset e falhar ao usá-lo?

Verifique a disponibilidade e o acesso ao modelo-base. O Open WebUI confere o acesso ao preset e à base subjacente quando a pessoa usa o modelo.

Definir o preset como modelo inicial restringe o acesso?

A seleção inicial define o ponto de partida. Use as concessões de acesso do recurso para decidir quem pode usar o preset e confirme com contas comuns de ensaio.

Restaurar a versão da configuração também restaura o acesso?

As concessões de acesso pertencem ao modelo em uso e mantêm seu estado ao trocar a versão da configuração. Revise-as separadamente e repita o teste com as contas de ensaio.