QuestLab Plataforma Inteligente de Questões
Banco público de questões

Questões para Concursos

Pesquise questões reais por disciplina, assunto, tópico, banca, órgão, cargo, ano e modalidade.

Questões por banca

29 bancas disponíveis. Clique para visualizar todas.

Encontre as questões que procura
Limpar filtros
478 questões encontradas

A otimização de hiperparâmetros é crucial na construção de modelos de Machine Learning, pois pode afetar significativamente o desempenho do modelo. Diversas técnicas de busca são usadas para encontrar a melhor combinação de hiperparâmetros, e entender quais são eficazes para esse propósito é essencial para aprimorar a precisão do modelo. A técnica apropriada na otimização de hiperparâmetros para um modelo de aprendizado supervisionado, considerando tanto a eficiência quanto a eficácia é a

A Busca Aleatória.
B Busca em Grade.
C Busca em Gradiente.
D Otimização Bayesiana.
E Representação com Bag de n-gramas.

Em uma rede neural artificial feedforward usada para a classificação de documentos no TRF-1, um dos neurônios de uma camada intermediária possui o seguinte vetor de pesos na entrada: W = [2, −1, ln (5/8) ,1/2 ]. Para uma determinada instância a ser classificada, o vetor de entradas para esse neurônio é I = [ln (2/3), ln (1/2),1, ln (9/25)], sem a presença de bias. Sabendo que o neurônio possui como função de ativação a função sigmoide, o valor de saída do neurônio será:

A 3/83;
B 3/80;
C 1/4;
D 3/10;
E 1/3.

Uma camada convolucional de uma rede neural convolucional recebe como entrada uma imagem de 50 x 50 pixels. Essa imagem passa por um filtro convolucional de tamanho 5 x 5. Sabendo que a convolução usa um stride de 3 e um padding de 0, o tamanho da imagem na saída dessa convolução será:

A 15 x 15;
B 16 x 16;
C 17 x 17;
D 45 x 45;
E 46 x 46.

Bernardo, analista de dados do TRF-1, realiza o pré-processamento de um dataset que será utilizado para treinar o chatbot do Tribunal. Em uma das etapas do pré-processamento, ele utiliza uma ferramenta que deflexiona as palavras, retirando suas inflexões. Nessa etapa, Bernardo realizou uma:

A anotação;
B codificação;
C estemização;
D extração;
E lematização.

Os analistas do Time de Desenvolvimento de Software (TDS) estão utilizando User Story (História de Usuário) do Extreme Programming (XP) para todos os novos projetos, em substituição aos Casos de Uso em UML. Na escrita das User Stories, os analistas devem:

A considerar que histórias podem ser construídas em mais de uma iteração;
B ordenar a escrita das histórias, visto que há uma dependência entre elas;
C detalhar os critérios de testes a serem executados com base na história;
D considerar que uma história pode ser um ou mais cenários em um caso de uso;
E focar nos objetivos do usuário e em como a interação com o sistema satisfaz esses objetivos.

O Time de Soluções Inovadoras (TISI) de uma organização está utilizando práticas do Kanban no processo de desenvolvimento de soluções de software. Com o uso do Kanban, o TISI visa a:

A manter um workflow padrão para o processo de inovação;
B gerenciar e melhorar o desempenho dos indivíduos do time;
C estabelecer uma metodologia de desenvolvimento de soluções de software de modo iterativo;
D aplicar um processo para definição de incrementos para desenvolvimento de soluções de software;
E utilizar uma abordagem de mudança evolutiva, baseada em feedbacks, para o processo de desenvolvimento de soluções de software.

Para realizar o clone de um único branch de um repositório git, a analista Ana utilizou o comando ‘git clone --depth 1 --branch q07 https://trf1.br/ana/repo07.git’. Após concluir o trabalho necessário no branch q07, Ana precisou recuperar o histórico completo de commits e realizar o checkout para o branch master, sem efetuar um novo clone. Para realizar as operações necessárias, a analista:

A executou imediatamente o comando git checkout master, sem alterações;
B alterou o escopo do fetch na configuração do git e logo após efetuou o checkout;
C executou imediatamente o comando git checkout master, com o argumento unshallow;
D executou o comando fetch com o argumento all e só então executou o comando git checkout master;
E efetuou o unshallow do clone e alterou o escopo do fetch na configuração do git, para só então efetuar novo fetch e checkout.

O analista Ângelo está comparando os sistemas de versionamento Git e Subversion (SVN). Ele está especialmente interessado no tipo de arquitetura dos versionadores e na capacidade nativa de travar a modificação de determinados arquivos (file locking). Ao fim da comparação, Ângelo deve concluir que:

A tanto o Git quanto o SVN possuem arquitetura distribuída, mas só o Git suporta file locking;
B tanto o Git quanto o SVN possuem arquitetura distribuída, mas só o SVN suporta file locking;
C tanto o Git quanto o SVN possuem arquitetura centralizada, mas só o SVN suporta file locking;
D o Git não suporta file locking e possui arquitetura distribuída, enquanto o SVN suporta file locking e possui arquitetura centralizada;
E o SVN não suporta file locking e possui arquitetura distribuída, enquanto o Git suporta file locking e possui arquitetura centralizada.

Considere o seguinte arquivo .gitlab-ci.yml, que define um pipeline no GitLab CI/CD: workflow: rules: - if: $CI_PIPELINE_SOURCE == "web" - if: $CI_PIPELINE_SOURCE == "push" stages: - primeiro primeiro: stage: primeiro script: - echo "Executando..." O pipeline do GitLab CI/CD descrito acima:

A não será executado, pois um job não pode ter o mesmo nome de um stage;
B não será executado, pois a palavra-chave workflow é inválida;
C será executado apenas no clique do botão Run Pipeline na interface do GitLab e nos eventos de push de branches ou de tags;
D será executado apenas nos acionamentos via API do GitLab, e nos eventos de push de branches, mas não nos de tags;
E será executado apenas nos acionamentos via WebHooks registrados no GitLab, e nos eventos de push de branches, mas não nos de tags.

A definição de uma pipeline de CI/CD requer a utilização de uma série de comandos, de acordo com o fluxo de execução necessário, para automatizar a entrega do software. Em um ambiente com múltiplos desenvolvedores, trabalhando com um repositório comum, a primeira ação da pipeline será a:

A compilação do código-fonte;
B implantação de contêiner com o artefato em execução;
C obtenção do código-fonte a partir do repositório;
D geração dos artefatos;
E execução de testes unitários.