Forem: Gustavo Aleixo

Enhancing RAG Precision Using Bedrock Metadata

Gustavo Aleixo — Sat, 14 Jun 2025 18:44:35 +0000

Enhance Your Retrieval Accuracy with Bedrock Knowledge Base Metadata

In one of the projects where I worked with Retrieval-Augmented Generation (RAG) using AWS Bedrock and Knowledge Base, I encountered a retrieval accuracy issue. The client had multiple documents containing similar content, but each was tailored for different audiences.

Example Scenario:

Imagine a high school textbook and a college textbook. Both may cover the same subject matter, but typically, the college version contains more advanced content.

Now, how can we ensure that high school students only retrieve information from the high school materials, even when both files contain overlapping topics?

The solution I implemented for this challenge was to use metadata filters.

Why Use Metadata Filters?

Metadata filters allow you to classify your files in a way that Bedrock can understand and apply filters during retrieval. This ensures that responses are generated only from the relevant, filtered files, making your searches both faster and more accurate.

In my case, since I needed to separate and categorize the search results based on the target audience, I created a custom metadata attribute for each document.

How to Use Metadata with Bedrock Knowledge Base

If you’re using an S3 bucket as the source for your Knowledge Base, you can create a .metadata.json file for each document you upload. This JSON file should have the same name as the indexed file, with the .metadata.json extension.

Example:

For a college textbook (college-book.pdf), create:

File: college-book.pdf.metadata.json

Content:

{
  "metadataAttributes": {
    "level": "college"
  }
}

For a college textbook (high-school-book.pdf), create:

File: high-school-book.pdf.metadata.json

Content:

{
  "metadataAttributes": {
    "level": "high-school"
  }
}

Upload this files to the bucket S3:

After, you need run the sync on Knowledge base, await few minutes and that’s it !!!

Your sync history will show amount source and metadata files find in your bucket

Testing your metadata

To test your metadata, go to the Knowledge base scream and click in “Test Knowledge Base” button and:

Select your model
Search for “Data manipulation” section
Click in Filters
Select “Manual filters” option
Put in your metadata filter

Final Tip

When making a query to the Knowledge Base, use the metadata filter option provided by Bedrock (e.g., filtering by "level": "high-school"), so only documents with the specified metadata will be considered during retrieval.

By using this approach, you can dramatically improve the precision and relevance of your RAG applications with AWS Bedrock.

Escalando Containers com ECS Fargate Baseado em Mensagens SQS

Gustavo Aleixo — Mon, 10 Mar 2025 10:41:28 +0000

Em sistemas modernos, a necessidade de escalabilidade e processamento sob demanda é cada vez mais comum. Para lidar com grandes volumes de dados de forma eficiente, a combinação de serviços de mensageria, como o Amazon SQS, com uma plataforma de orquestração de containers, como o Amazon ECS, permite armazenar e distribuir mensagens de maneira assíncrona, garantindo que as aplicações processem as informações no seu próprio ritmo.

Neste artigo, vamos explorar como configurar essa arquitetura, utilizando o Amazon ECS Fargate para hospedar containers que escalam automaticamente com base no volume de mensagens na fila do SQS.

Requisitos

Para a realização deste laboratório, é necessário:

Possuir uma conta AWS.
Ter o AWS CLI instalado e configurado em sua máquina.

Arquitetura

Recursos da Arquitetura

Amazon SQS: Serviço de filas AWS.
Amazon ECS Fargate: Serviço de containers serverless.
AWS CloudWatch: Serviço de monitoramento e geração de métricas para autoscaling.
Application Auto Scaling: Serviço de gerenciamento automático de escalabilidade.

Fluxo da Arquitetura

Um sistema externo ou API envia mensagens para a fila SQS.
O Amazon CloudWatch monitora o número de mensagens na fila.
O Application Auto Scaling ajusta dinamicamente o número de tasks no ECS Fargate com base nas métricas do CloudWatch.
As tasks do ECS Fargate consomem e processam as mensagens.

Criando a Fila SQS

Com o AWS CLI configurado para sua conta, acesse o terminal e execute o comando abaixo, substituindo <regiao> pela sua região AWS:

aws sqs create-queue --region <regiao> --queue-name consumer-queue-ecs-sample.fifo --attributes '{"FifoQueue":"true"}'

Saída esperada no terminal:

{
    "QueueUrl": "https://sqs.<regiao>.amazonaws.com/<conta-aws>/consumer-queue-ecs-sample.fifo"
}

Copie a URL da fila que foi retornada pelo terminal e armazene!

Criando e Disponibilizando a Imagem no ECR

Para exemplificar, utilizaremos um script previamente criado para consumir as mensagens da fila. Vamos iniciar?

Clonando o Repositório do GitHub

git clone https://github.com/GustavoAleixo/consumer-queue-ecs-sample.git

Acesse a pasta do repositório:

cd consumer-queue-ecs-sample

Nesta pasta encontraremos:

|_ ecs
|  |__ ecs-trust-policy.json
|  |__ task-definition.json
|_ Dockerfile
|_ index.mjs
|_ README.md
|_ .env.example

Edite o arquivo task-definition.json e substitua <conta-aws> pelo número da sua conta AWS e <regiao> pela região utilizada anteriormente na criação da fila.

Renomeie o arquivo .env.example para .env e edite-o, substituindo <regiao> pela região utilizada e <url-fila> pela URL da fila armazenada anteriormente.

Criando a Função IAM para o ECS

O ECS precisa de permissões para acessar a fila SQS e registrar logs no CloudWatch. Execute os comandos abaixo:

aws iam create-role --role-name ecsTaskExecutionRole --assume-role-policy-document file://ecs/ecs-trust-policy.json

Agora, anexe as permissões necessárias:

aws iam attach-role-policy --role-name ecsTaskExecutionRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
aws iam attach-role-policy --role-name ecsTaskExecutionRole --policy-arn arn:aws:iam::aws:policy/AmazonSQSFullAccess

Criando e Configurando o ECS

Crie um cluster ECS:

aws ecs create-cluster --cluster-name consumer-queue-ecs-sample-cluster

Depois, registre a definição da task:

aws ecs register-task-definition --cli-input-json file://ecs/task-definition.json

Crie o serviço no ECS, substituindo <ID-SUBNET> e <ID-SECURITY-GROUP> pelos valores obtidos anteriormente:

aws ecs create-service \
    --cluster consumer-queue-ecs-sample-cluster \
    --service-name consumer-queue-ecs-sample-service \
    --task-definition consumer-queue-ecs-sample-task \
    --launch-type FARGATE \
    --desired-count 1 \
    --network-configuration "awsvpcConfiguration={subnets=[ID-SUBNET],securityGroups=[<ID-SECURITY-GROUP>],assignPublicIp=ENABLED}"

Configurando Auto Scaling

aws application-autoscaling register-scalable-target \
    --service-namespace ecs \
    --scalable-dimension ecs:service:DesiredCount \
    --resource-id service/consumer-queue-ecs-sample-cluster/consumer-queue-ecs-sample-service \
    --min-capacity 0 \
    --max-capacity 10

Crie uma política de auto scaling baseada na fila:

aws application-autoscaling put-scaling-policy \
    --service-namespace ecs \
    --scalable-dimension ecs:service:DesiredCount \
    --resource-id service/consumer-queue-ecs-sample-cluster/consumer-queue-ecs-sample-service \
    --policy-name SQS-Scaling-Policy \
    --policy-type StepScaling \
    --step-scaling-policy-configuration '{"AdjustmentType": "ChangeInCapacity","StepAdjustments": [{"MetricIntervalLowerBound": 1,"ScalingAdjustment": 1}]}'

Agora, vincule a política a uma métrica do CloudWatch:

aws cloudwatch put-metric-alarm \
    --alarm-name "SQS-Messages-Alarm" \
    --metric-name ApproximateNumberOfMessagesVisible \
    --namespace AWS/SQS \
    --statistic Sum \
    --period 60 \
    --threshold 1 \
    --comparison-operator GreaterThanOrEqualToThreshold \
    --dimensions Name=QueueName,Value=consumer-queue-ecs-sample.fifo \
    --evaluation-periods 1 \
    --alarm-actions <POLITICA-ARN> \
    --unit Count

Tudo pronto!!! 🚀

Testando o Auto Scaling

Agora que todos os componentes foram configurados, vamos validar se o Auto Scaling está funcionando corretamente.

Acesse o Console da AWS e navegue até a região onde os recursos foram criados.
No campo de busca, procure por ECS e selecione o serviço Amazon Elastic Container Service.

No painel do ECS, clique no cluster consumer-queue-ecs-sample-cluster.
Selecione o serviço consumer-queue-ecs-sample-service e clique na aba Tasks para visualizar as instâncias em execução.

Enviando Mensagens para a Fila SQS

Agora, vamos testar o comportamento do Auto Scaling enviando mensagens para a fila SQS. Abra o terminal e execute os comandos abaixo, substituindo <regiao> e <conta-aws> pelos valores correspondentes:

Envie a primeira mensagem:

   aws sqs send-message \
       --queue-url https://sqs.<regiao>.amazonaws.com/<conta-aws>/consumer-queue-ecs-sample.fifo \
       --message-body "Message of number 1" \
       --message-group-id "example" \
       --message-deduplication-id "number1"

Aguarde alguns segundos e envie a segunda mensagem:

aws sqs send-message \
    --queue-url https://sqs.<regiao>.amazonaws.com/<conta-aws>/consumer-queue-ecs-sample.fifo \
    --message-body "Message of number 2" \
    --message-group-id "example" \
    --message-deduplication-id "number2"

Validando a Escala Automática

Após alguns instantes, volte ao console do ECS e atualize a página. Você verá novas tasks sendo iniciadas automaticamente para processar as mensagens da fila.

Parabéns! 🎉 Agora, seu ambiente está configurado para escalar dinamicamente conforme a demanda.

Conclusão

Com essa arquitetura implementada, conseguimos criar um sistema que processa mensagens de forma eficiente e escalável. O Amazon ECS Fargate, aliado ao Amazon SQS e ao Application Auto Scaling, garante que nossa aplicação consiga lidar com diferentes cargas de trabalho automaticamente. Esse modelo permite otimizar recursos, reduzir custos e melhorar a eficiência do processamento de mensagens em sistemas distribuídos.

AWS Lambda vs Containers: Quando usar cada um?

Gustavo Aleixo — Mon, 17 Feb 2025 11:08:16 +0000

Com a crescente adoção da computação em nuvem, muitas empresas que migram para a AWS percebem a necessidade de modernizar ou refatorar suas aplicações para aproveitar ao máximo os benefícios da nuvem. Durante essa fase de descoberta do projeto, uma dúvida recorrente surge: Devo utilizar AWS Lambda ou contêineres?

AWS Lambda

Ideal para arquiteturas orientadas a eventos e aplicações que exigem escalabilidade automática, o AWS Lambda é um serviço de computação serverless que permite a execução de código sem a necessidade de gerenciar servidores.

Vantagens:

Escalabilidade automática: o Lambda escala automaticamente conforme a demanda, sem necessidade de intervenção manual.
Pagamento por uso: você paga apenas pelo tempo de execução do código.
Gerenciamento simplificado: não há necessidade de configurar ou manter servidores.
Integração nativa com serviços AWS: funciona perfeitamente com DynamoDB, S3, API Gateway e outros.

Limitações:

Tempo máximo de execução: atualmente limitado a 15 minutos por invocação.
Restrições de ambiente: não oferece controle total sobre a infraestrutura subjacente.
Cold start: pode haver um pequeno atraso na inicialização, especialmente para funções escritas em linguagens como Java e C#.

Containers

Os contêineres, por outro lado, oferecem maior flexibilidade e controle sobre o ambiente de execução. Com serviços como Amazon ECS (Elastic Container Service) e Amazon EKS (Elastic Kubernetes Service), é possível gerenciar aplicações conteinerizadas de maneira mais eficiente.

Vantagens:

Maior controle sobre o ambiente: permite personalizar bibliotecas, runtime e configurações.
Execução de processos mais longos: ideal para workloads de longa duração e aplicações complexas.
Portabilidade: facilita a movimentação de aplicações entre diferentes ambientes, como local, nuvem e híbrido.
Suporte a diversas linguagens e frameworks: enquanto o Lambda possui restrições, contêineres podem rodar praticamente qualquer tecnologia.

Desvantagens:

Gerenciamento de infraestrutura: requer a configuração e manutenção de clusters e redes.
Custo fixo: ao contrário do Lambda, pode haver custos mesmo quando a aplicação não está em uso.
Escalabilidade manual ou configurável: exige ajustes para escalar adequadamente.

E então, qual escolher?

A decisão entre Lambda e contêineres depende do caso de uso específico:

Utilize Lambda caso tenha uma aplicação baseada em eventos, que precise escalar rapidamente ou abstrair a necessidade de gerenciar uma infraestrutura.
Utilize contêineres caso precise de mais controle do seu ambiente, aplicações mais complexas ou que exijam um longo tempo de execução.

Conclusão

Tanto o AWS Lambda quanto os contêineres são ótimas opções para rodar aplicações na nuvem, cada um com suas vantagens e limitações. O ideal é avaliar os requisitos do seu projeto e considerar a melhor abordagem com base na escalabilidade, custo, tempo de execução e nível de controle necessário. Em muitos casos, uma abordagem híbrida combinando Lambda e contêineres pode ser a melhor solução para obter flexibilidade e eficiência na nuvem.

Serverless na AWS: O que é e por que você deveria considerar essa arquitetura?

Gustavo Aleixo — Thu, 13 Feb 2025 12:06:25 +0000

Serverless é um modelo de computação em nuvem que permite que equipes de desenvolvimento criem e executem aplicações sem a necessidade de gerenciar servidores. Em vez de configurar, escalar e manter a infraestrutura, os desenvolvedores podem focar na lógica do negócio, enquanto a provedora de nuvem cuida automaticamente da alocação de recursos.

Na AWS, existem diversos serviços baseados nessa arquitetura, como AWS Lambda, Amazon API Gateway, AWS Step Functions, DynamoDB, S3, entre outros. Quando integrados, proporcionam uma experiência totalmente gerenciada e escalável.

Benefícios da arquitetura Serverless

A utilização do serveless traz diversos benefícios para as empresas e seus desenvolvedores, incluindo:

Agilidade na entrega - Com menor preocupação com infraestrutura, os times podem focar ainda mais no desenvolvimento e lançamento de novas funcionalidades

Abstração da necessidade de um servidor - Por serem serviços gerenciados, não há necessidade de implantar atualizações, aplicar patches de segurança ou provisionar novas máquinas, pois tudo é gerenciado pela própria AWS.

Escalabilidade automática - A infraestrutura escala automaticamente de acordo com a demanda, garantindo que sua aplicação suporte picos de tráfego sem intervenção manual.

Redução de custos - O modelo de cobrança é on-demand, ou seja, cobra apenas pelo tempo de execução do código, evitando custos fixos com servidores inativos.

Alta disponibilidade e tolerância a falhas - A AWS distribui automaticamente a carga da aplicação para evitar interrupções, garantindo maior confiabilidade.

Integração com outros serviços AWS - Por serem nativos, os serviços Serverless permitem conexão com vários outros serviços da AWS, facilitando a construção de soluções escaláveis e eficientes.

Quanto utilizar o serverless?

Essa arquitetura é ideal para aplicações que precisam escalar de forma dinâmica, ter baixo custo de manutenção e responder rapidamente a eventos, como, por exemplo:

APIs e microservices – Para aplicações altamente escaláveis e desacopladas.

Processamento de dados via streaming – Para análises em tempo real de eventos e logs.

Execução de tarefas assíncronas – Para trabalhos como automação, notificações e ETL.

Pontos de atenção

Nem tudo são flores, e há alguns desafios na adoção desse modelo:

Limite de tempo de execução – No AWS Lambda, cada função tem um tempo máximo de execução de 15 minutos. Para workloads mais longos, é necessário utilizar serviços como ECS ou EC2.

Custos imprevisíveis em picos de uso – Como o modelo de cobrança é baseado em execução, períodos de alto tráfego podem gerar custos inesperados. Por isso, é essencial configurar alertas de custos e desenvolver pensando na otimização do fluxo de execução.

Conclusão

Serverless é uma excelente opção para muitas aplicações, mas não é uma solução universal. Avaliar bem os desafios e considerar casos de uso específicos ajuda a decidir se essa arquitetura é adequada para o seu projeto.