Simulado AWS Certified AI Practitioner (AIP-C01) – Questões Atualizadas

Explicação: A opção B satisfaz melhor os requisitos e, ao mesmo tempo, minimiza o esforço de desenvolvimento, combinando recursos de pesquisa semântica gerenciada com modelos básicos totalmente gerenciados. A orientação do AWS Generative AI descreve a pesquisa semântica como um padrão de recuperação baseado em vetor, onde documentos e consultas do usuário são incorporados em um espaço vetorial compartilhado. A pesquisa por similaridade (como k-vizinhos mais próximos) recupera resultados com base no significado, em vez de palavras-chave exatas. O Amazon OpenSearch Service oferece suporte nativo à indexação vetorial e à pesquisa k-NN em escala. Isso o torna adequado para grandes conjuntos de dados, como 20 milhões de restaurantes e 200 milhões de avaliações, ao mesmo tempo em que atinge latência inferior a um segundo para a maioria das consultas. Como o OpenSearch é um serviço distribuído e gerenciado, ele é dimensionado automaticamente durante períodos de pico de tráfego e fornece desempenho econômico em comparação com a construção e o ajuste de pipelines de pesquisa vetorial personalizados em bancos de dados relacionais. Usar o Amazon Bedrock para gerar embeddings reduz significativamente a complexidade do desenvolvimento. A AWS gerencia os modelos básicos, elimina a necessidade de hospedagem de modelos personalizados e garante consistência usando o mesmo FM para incorporações de documentos e de consultas. Isso se alinha diretamente às arquiteturas de pesquisa semântica recomendadas pela AWS e elimina a necessidade de gerenciamento do ciclo de vida do modelo. As atualizações de hora em hora nos dados do restaurante podem ser tratadas de forma eficiente por meio da reindexação incremental no OpenSearch sem interromper o desempenho da consulta. Essa abordagem separa claramente o armazenamento de dados transacionais das cargas de trabalho de pesquisa, o que é uma prática recomendada em arquiteturas AWS. A opção A não atende ao requisito de pesquisa semântica porque a pesquisa baseada em palavras-chave não pode interpretar de forma confiável a intenção complexa da linguagem natural. A opção C introduz riscos de escalabilidade e desempenho ao executar pesquisas de similaridade vetorial em grande escala no PostgreSQL, o que aumenta a complexidade operacional. A opção D adiciona camadas desnecessárias de ingestão e abstração destinadas à geração aumentada de recuperação, e não à pesquisa semântica de alto rendimento. Portanto, a Opção B oferece o equilíbrio ideal entre desempenho, escalabilidade, atualização de dados e esforço mínimo de desenvolvimento usando os serviços de IA generativa da AWS.

Explicação: A opção A atende melhor aos requisitos combinados de baixa latência, estabilidade e controles de segurança validados usando recursos do Amazon Bedrock desenvolvidos especificamente para operações de produção GenAI. A meta de latência da empresa de menos de 1 segundo e a observação da degradação durante picos indicam fortemente a variabilidade da capacidade e da produtividade. A taxa de transferência provisionada do Amazon Bedrock tem como objetivo oferecer um desempenho mais previsível, reservando capacidade de inferência para um modelo escolhido, reduzindo o risco de limitação e estabilizando os tempos de resposta sob carga. Isto melhora diretamente a consistência operacional entre regiões onde a capacidade sob demanda pode variar. O requisito de “bloquear recomendações inseguras ou alucinadas” é abordado mais diretamente pelo Amazon Bedrock Guardrails. Os Guardrails fornecem aplicação de segurança gerenciada, incluindo controles de informações confidenciais e políticas de conteúdo configuráveis. O uso de regras de negação semântica permite que o aplicativo evite orientações inseguras, como temperaturas perigosas de preparação de cerveja ou outras instruções processuais prejudiciais, reforçando a segurança no limite do modelo em vez de depender da filtragem posterior. O requisito restante é “consistência de saída de 99,5% para entradas idênticas”. Embora os modelos generativos possam ser probabilísticos, os sistemas de produção alcançam consistência prática controlando versões imediatas, entradas e comportamento político. O Amazon Bedrock Prompt Management oferece suporte a práticas controladas de ciclo de vida de prompts, incluindo fluxos de trabalho de versionamento e aprovação, que reduzem desvios não intencionais entre implantações e regiões. Ao garantir que os mesmos modelos e parâmetros de prompt aprovados sejam usados ​​de forma consistente, a empresa pode melhorar significativamente a repetibilidade para as mesmas entradas estruturadas e contexto de recuperação, o que é essencial em cadeias de prompt de vários estágios. As outras opções estão incompletas. B melhora a experimentação e a observabilidade, mas não impõe controles de segurança nem estabiliza a latência. C pode melhorar o desempenho, mas não fornece aplicação de segurança validada no momento da inferência. D pode ajudar na relevância da recuperação, mas não aborda resultados inseguros ou estabilidade de inferência. Portanto, A é a única opção que visa simultaneamente a latência previsível, a governança do comportamento imediato e os fortes controles de segurança no Amazon Bedrock.

Explicação: A opção B é a solução correta porque aborda diretamente os gargalos de taxa de transferência e os requisitos de latência usando recursos nativos de otimização de desempenho do Amazon Bedrock projetados para cargas de trabalho de IA generativas de alto volume e em tempo real. O Amazon Bedrock oferece suporte a perfis de inferência entre regiões, que permitem que os aplicativos roteem de forma transparente solicitações de inferência em várias regiões da AWS. Durante períodos de pico de uso, o tráfego é distribuído automaticamente para regiões com capacidade disponível, reduzindo a limitação, o enfileiramento de solicitações e os riscos de tempo limite. Essa abordagem se alinha às orientações da AWS para a criação de aplicativos GenAI altamente disponíveis e de baixa latência, que devem ser dimensionados de forma elástica entre fronteiras geográficas. O lote de tokens melhora ainda mais a eficiência, combinando diversas solicitações de inferência em uma única invocação de modelo, quando aplicável. A documentação do AWS Generative AI destaca o lote como uma técnica de otimização chave para reduzir a sobrecarga por solicitação, melhorar o rendimento e utilizar melhor a capacidade do modelo. Isto é especialmente eficaz para modelos leves e de baixa latência, como o Claude 3 Haiku, que são projetados para respostas rápidas e altos volumes de solicitações. A opção A não atende ao requisito porque a compra de taxa de transferência provisionada em uma única região cria um gargalo regional e não aborda a disponibilidade multirregional ou picos de tráfego além da capacidade reservada. As novas tentativas aumentam a carga e a latência em vez de resolver a causa raiz. A opção C melhora o dimensionamento da camada de aplicação, mas não resolve os limites de rendimento do lado do modelo. O roteamento round-robin do lado do cliente não tem conhecimento da capacidade do modelo em tempo real e ainda pode enviar tráfego para regiões saturadas. A opção D é inadequada porque a inferência em lote com recuperação assíncrona foi projetada para cargas de trabalho off-line ou não interativas. Ele não pode atender a um requisito estrito de tempo de resposta de 2 segundos para um assistente de IA interativo. Portanto, a Opção B fornece a solução mais eficaz e alinhada à AWS para obter baixa latência, escalabilidade global e alto rendimento durante períodos de pico de uso.

Explicação: A abordagem com menor sobrecarga operacional é usar fluxos de trabalho gerenciados de avaliação de modelo do Amazon Bedrock com conjuntos de dados armazenados no Amazon S3 e, em seguida, publicar os resultados no Amazon CloudWatch para painéis. É exatamente isso que as opções B e C combinam. A etapa B coloca corretamente as entradas de avaliação padronizadas no Amazon S3 e se concentra em conceder ao fluxo de trabalho de avaliação as permissões corretas para ler esses conjuntos de dados. Na prática, o principal requisito é o acesso controlado aos objetos S3 usados ​​como conjuntos de dados de avaliação. O estabelecimento de permissões IAM e padrões de acesso privado (como o uso de padrões de conectividade VPC quando aplicável à postura de rede da organização) está alinhado com os requisitos da empresa e evita a construção de sistemas personalizados de armazenamento ou distribuição de dados para avaliadores. A Etapa C então operacionaliza o ciclo de vida da avaliação com infraestrutura mínima: uma função agendada do AWS Lambda inicia trabalhos de avaliação usando o local do conjunto de dados S3, e uma segunda função Lambda verifica o status do trabalho e envia resultados e sinais operacionais para o CloudWatch. Isso atende ao requisito da plataforma para exibir métricas de precisão em painéis porque as métricas/logs do CloudWatch podem ser visualizados em painéis e consultados por meio do CloudWatch Logs Insights. Ele também oferece suporte a comparações contínuas e padronizadas entre modelos, sem exigir que os desenvolvedores executem experimentos ad-hoc. As alternativas introduzem mais encargos operacionais. D e E contam com ferramentas baseadas no Amazon SageMaker, trabalhos de notebook e estruturas de avaliação de código aberto, que exigem mais gerenciamento de ambiente, controle de dependências, considerações de escalabilidade e manutenção ao longo do tempo. A inclui CORS, que é principalmente uma preocupação de acesso ao navegador e não aborda como os trabalhos de avaliação gerenciados pela Bedrock acessam com segurança o S3 no padrão típico de serviço a serviço. Portanto, B + C alcança avaliação de modelo padronizada, agendamento automatizado e observabilidade pronta para painel com o menor volume de operações.

Explicação: A opção C satisfaz melhor o requisito de testes de FM flexíveis em todos os ambientes, ao mesmo tempo que minimiza a complexidade operacional e se alinha às práticas de implantação recomendadas pela AWS. O Amazon Bedrock oferece suporte à invocação de modelos básicos sob demanda por meio da abstração FoundationModel, que permite que os aplicativos façam referência dinamicamente a diferentes modelos sem exigir capacidade provisionada dedicada. Isso é ideal para experimentação e testes A/B em ambientes de desenvolvimento e produção. O uso de um único aplicativo AWS CDK garante a consistência da infraestrutura e reduz a duplicação. A configuração específica do ambiente, como a seleção de diferentes IDs de modelo básico, pode ser externalizada por meio de parâmetros, variáveis ​​de contexto ou arquivos de configuração específicos do ambiente. Isso permite que os proprietários de produtos alternem facilmente entre FMs em cada ambiente sem modificar a lógica do aplicativo. Um único AWS CodePipeline com estágios de implantação distintos para desenvolvimento e produção é uma prática recomendada da AWS para implantações em vários ambientes. Ele impõe etapas consistentes de construção e implantação, ao mesmo tempo que permite a personalização em nível de ambiente. As ações de implantação do AWS CodeBuild permitem implantações automatizadas e repetíveis, reduzindo erros manuais e melhorando a governança. A opção A aumenta a complexidade ao introduzir vários pipelines e depende de modelos provisionados, que não são necessários para avaliação e experimentação de FM. A taxa de transferência provisionada é mais adequada para cargas de trabalho de produção previsíveis e de alto volume, em vez de trocas frequentes de modelo. A opção B cria sobrecarga operacional desnecessária ao duplicar aplicações e pipelines CDK, dificultando a manutenção a longo prazo. A opção D entra em conflito direto com as práticas recomendadas de infraestrutura como código ao recriar manualmente os recursos de desenvolvimento, o que aumenta o desvio de configuração e reduz a confiabilidade. Portanto, a Opção C fornece a solução mais flexível, escalável e alinhada à AWS para testar e alternar modelos básicos em ambientes de desenvolvimento e produção.

Explanation: Option B best fulfills all functional, scalability, and collaboration requirements by combining purpose- built AWS services with Amazon Bedrock capabilities. Amazon Bedrock Data Automation is designed to orchestrate large-scale, multimodal data processing pipelines and integrates naturally with foundation models for summarization and concept extraction. Using BDA to process document files ensures consistent preprocessing and model invocation at scale, which is essential for handling more than 10,000 sources per day with high concurrency. Integrating Amazon Textract for PDFs enables accurate extraction of structured and unstructured text from scanned and digital documents, while Amazon Transcribe is the appropriate service for converting recorded videos into text for downstream semantic analysis. These services are optimized for their respective media types and feed clean, normalized inputs into Bedrock foundation models, improving the quality of contextual summaries. Storing processed content in Amazon S3 with versioning enabled directly addresses the requirement for version control. S3 versioning provides immutable object history and rollback capabilities without additional complexity. Metadata storage in Amazon DynamoDB supports high-throughput, low- latency access patterns and scales automatically to handle peak upload concurrency. Real-time collaboration is achieved through AWS AppSync GraphQL subscriptions combined with DynamoDB. AppSync enables real-time updates to connected clients whenever study materials are created or modified, making it well suited for collaborative editing and live synchronization. DynamoDB streams integrate seamlessly with AppSync to propagate changes efficiently. The other options misuse services or fail to meet key requirements. Amazon SNS does not support collaborative state synchronization, Amazon DocumentDB is not optimized for versioned document storage, Amazon Neptune is unsuitable for document-centric workloads, and Amazon ElastiCache is not designed for durable storage or version control. Option B aligns with AWS best practices for scalable, multimodal generative AI systems built on Amazon Bedrock.

Explicação: A combinação das opções C e D oferece observabilidade abrangente e em tempo real para cargas de trabalho do Amazon Bedrock com a menor sobrecarga operacional, contando com integrações nativas e serviços gerenciados. O Amazon Bedrock publica métricas integradas do CloudWatch para invocações de modelo e uso de token. A opção C aproveita essas métricas nativas diretamente, permitindo que as equipes criem painéis centralizados do CloudWatch sem pipelines de dados adicionais ou processamento personalizado. Os alarmes do CloudWatch fornecem alertas baseados em limites para consumo de token, permitindo controle proativo de custos e uso em todos os modelos básicos. Essa abordagem está alinhada com a orientação da AWS para usar métricas de serviço nativas sempre que possível para reduzir a complexidade operacional. A opção D complementa o CloudWatch, permitindo visualizações avançadas específicas das partes interessadas por meio do Amazon Managed Grafana. A integração zero-ETL permite que as métricas do Bedrock e CloudWatch sejam visualizadas diretamente no Grafana sem construir pipelines de ingestão ou gerenciar camadas de armazenamento. Os painéis Grafana são particularmente adequados para atender diferentes públicos, como equipes de engenharia, finanças e produtos, cada um com visualizações personalizadas do uso e tendências de tokens. A opção A introduz complexidade desnecessária ao adicionar uma camada de business intelligence que é mais adequada para análises históricas do que para monitoramento operacional em tempo real. A opção B é útil para análise profunda de logs, mas requer manutenção de consulta e não fornece painéis eficientes em tempo real em escala. A opção E envolve vários serviços e fluxos de dados personalizados, aumentando significativamente a sobrecarga operacional em comparação com a observabilidade nativa baseada em métricas. Ao combinar painéis e alarmes do CloudWatch com os recursos de visualização de ETL zero do Managed Grafana, a empresa obtém visibilidade em tempo real, painéis flexíveis e alertas automatizados em todos os modelos básicos do Amazon Bedrock com esforço operacional mínimo.

Explicação: A opção B está correta porque usa o recurso de avaliação gerenciada no Amazon Bedrock que se destina especificamente à comparação de modelos básicos usando um conjunto de prompts consistente e produzindo resultados estruturados com o mínimo de ferramentas personalizadas. Em um fluxo de trabalho de avaliação Bedrock, você fornece um conjunto de dados de entrada de prompts, normalmente no formato JSON Lines para que cada linha represente um registro de avaliação. Armazenar o arquivo JSONL no Amazon S3 permite que a Bedrock leia o conjunto de dados em escala e grave resultados de avaliação padronizados de volta no S3 para análise downstream, compartilhamento e retenção. O principal requisito é avaliar a qualidade e a segurança em vários modelos. Um trabalho de avaliação Bedrock pode usar um modelo de juiz para pontuar os resultados gerados em relação a critérios definidos. Essa abordagem suporta comparações repetíveis e iguais porque o mesmo modelo de juiz e rubrica de pontuação podem ser aplicados a cada modelo de base candidato. Os modelos candidatos são configurados como geradores, o que significa que cada execução de trabalho de avaliação usa um FM selecionado para produzir respostas para o mesmo conjunto de prompts, e o modelo juiz avalia essas respostas. Isso atende ao requisito de gerar relatórios de avaliação que ajudem um cientista de dados a selecionar o melhor FM. A opção A não usa trabalhos de avaliação Bedrock e uma base de conhecimento mais RetrieveAndGenerate é um padrão RAG, não uma estrutura de avaliação. Produziria respostas, mas não uma pontuação e relatórios padronizados adequados para a seleção do modelo. A opção C está incorreta porque os resultados da avaliação Bedrock são entregues ao S3, e não diretamente a um destino de BI, e a seleção do FM candidato como avaliador entra em conflito com o padrão pretendido de uso de um modelo de juiz estável. A Opção D utiliza indevidamente as bases de conhecimento e os tipos de avaliação de recuperação quando o requisito é a avaliação do modelo com base imediata, em vez de avaliar a qualidade da recuperação.

Explicação: A opção C aborda diretamente a causa raiz de respostas truncadas e inconsistentes usando fragmentação semântica e recuperação dinâmica recomendadas pela AWS, em vez de processamento de fragmentos estático ou sequencial. A documentação do Amazon Bedrock enfatiza que os modelos básicos têm janelas de contexto fixas e que o envio de entradas superdimensionadas ou mal estruturadas pode levar ao truncamento, à perda de contexto e à degradação da qualidade da saída. A fragmentação semântica quebra documentos com base no significado, em vez de contagens fixas de tokens. Ao usar um limite percentual de ponto de interrupção e buffers de frase, o conteúdo permanece coerente e semanticamente completo. Essa abordagem reduz a probabilidade de conceitos importantes serem divididos em partes, o que é uma causa comum de resultados de resumo inconsistentes. A API RetrieveAndGenerate foi projetada especificamente para lidar com documentos grandes que excedem a janela de contexto de um modelo. Em vez de forçar todo o conteúdo em uma única chamada de inferência, a API gera incorporações para blocos e seleciona dinamicamente apenas os blocos mais relevantes com base na semelhança com a consulta do usuário. Isso garante que o FM receba apenas contexto de alto valor enquanto permanece dentro dos limites da janela de contexto. A opção A é ineficaz porque encadear blocos sequencialmente não se alinha com a forma como os FMs processam o contexto e corre o risco de exceder os limites do contexto ou introduzir informações irrelevantes. A opção B melhora a estrutura, mas ainda depende de blocos principais maiores, o que pode levar a ineficiências no processamento de documentos muito grandes. A opção D processa segmentos de forma independente, o que muitas vezes causa perda de contexto global e resumos inconsistentes. Portanto, a Opção C é a solução mais robusta e alinhada à AWS para resolver problemas de truncamento e consistência ao processar grandes documentos técnicos com o Amazon Bedrock.

Explicação: A opção B está correta porque o aplicativo está atualmente invocando o identificador do modelo básico, que roteia o tráfego para o pool de capacidade sob demanda em vez do rendimento provisionado adquirido pela empresa. No Amazon Bedrock, a taxa de transferência provisionada é anexada a um recurso provisionado específico criado por meio das APIs de taxa de transferência provisionada. Para consumir essa capacidade reservada, as solicitações de inferência devem ter como alvo o identificador de recurso provisionado que representa o rendimento adquirido, e não o identificador de modelo genérico usado para inferência sob demanda. O trecho de código usa modelId="anthropic.claude-v2". Este valor seleciona o ponto final sob demanda para esse modelo. Como resultado, as solicitações estão sujeitas a cotas sob demanda e comportamento de limitação, enquanto a taxa de transferência provisionada permanece ociosa. Isso explica diretamente a observação do CloudWatch: as métricas de capacidade provisionada mostram capacidade não utilizada porque nenhum tráfego está sendo direcionado para o recurso provisionado, e o caminho sob demanda está sendo limitado porque excede os limites sob demanda aplicáveis ​​durante o volume de pico. Substituir o valor modelId pelo ARN de throughput provisionado retornado pelo fluxo de trabalho CreateProvisionedModelThroughput garante que a invocação do tempo de execução seja roteada para a capacidade reservada. Depois que o tráfego é direcionado corretamente, as unidades de modelo adquiridas fornecem o rendimento consistente necessário para um desempenho previsível durante o horário comercial, e é exatamente por isso que o rendimento provisionado é usado. A opção A poderia aumentar a capacidade, mas não resolve o problema central de que o aplicativo não está usando o recurso provisionado. A opção C pode reduzir temporariamente o impacto da limitação, mas adiciona latência e não garante um rendimento consistente; também ainda desperdiça a capacidade provisionada. A opção D altera o mecanismo de entrega de resposta, mas a limitação é um problema de roteamento de capacidade e de cota, não um problema de API de streaming.