Blog

IA no Setor Financeiro: Oportunidades e Novos Desafios de Governança

O setor de serviços financeiros (FSI, do inglês Financial Services Industry) está usando IA para transformar a forma como instituições atendem seus clientes. As aplicações são variadas: gerenciamento proativo de portfólios, refinanciamento automático de hipotecas quando as taxas caem, e até negociação de prêmios de seguros em nome dos clientes.

Mas essa adoção acelerada traz consigo um conjunto de preocupações que não podem ser ignoradas — especialmente no que diz respeito à Governança, Risco e Conformidade (GRC). Para ajudar organizações do setor financeiro a navegarem esses desafios, a AWS acaba de anunciar a versão atualizada do Guia do Usuário AWS para Governança, Risco e Conformidade na Adoção Responsável de IA em Serviços Financeiros.

O Que o Guia Cobre

O documento é abrangente e foi estruturado para oferecer considerações práticas em dimensões-chave da adoção responsável de IA:

• Governança
• Gestão de riscos
• Conformidade regulatória
• Gestão de dados
• Gestão de modelos
• Gestão de agentes de IA

Para cada uma dessas dimensões, o guia mapeia capacidades específicas de serviços AWS que podem ser utilizados pelas organizações. Entre os serviços destacados estão:

• Amazon Bedrock AgentCore
• Amazon Bedrock Guardrails
• Amazon Bedrock Agents
• Amazon SageMaker Autopilot
• Amazon SageMaker Model Monitor

Como Acessar e Recursos Complementares

O guia está disponível gratuitamente no portal de whitepapers da AWS e é complementar a outros materiais já publicados pela empresa, como:

• Guia de Uso Responsável de IA da AWS
• AWS Cloud Adoption Framework para IA
• AWS Well-Architected Framework – Responsible AI Lens
• AWS Well-Architected Framework – Generative AI Lens
• AWS Well-Architected Framework – Machine Learning Lens

À medida que o ambiente regulatório e as boas práticas continuarem evoluindo, a AWS promete publicar atualizações no AWS Security Blog e no AWS Compliance Center.

Por Que Isso Importa para Equipes Brasileiras

Para times de tecnologia, conformidade e segurança que atuam no mercado financeiro brasileiro, esse guia é um ponto de partida relevante. O setor financeiro no Brasil está sujeito a regulações rigorosas — e a pressão para adotar IA de forma responsável só tende a crescer. Ter um framework estruturado, com mapeamento direto para serviços de nuvem, facilita tanto o planejamento quanto as conversas com áreas de risco e auditoria.

Fonte

Introducing the updated AWS User Guide to Governance, Risk, and Compliance for Responsible AI Adoption (https://aws.amazon.com/blogs/security/introducing-the-updated-aws-user-guide-to-governance-risk-and-compliance-for-responsible-ai-adoption/)

O problema com streaming de voz em tempo real

Desenvolver aplicações de streaming ao vivo com interação de voz em tempo real é um desafio técnico considerável. Restrições de largura de banda de rede podem causar alta latência e degradação de qualidade em aplicações onde o tempo é crítico. Barreiras de idioma limitam a interação eficaz entre humanos e máquinas em comunicações multilíngues. Escalabilidade e resiliência exigem um equilíbrio difícil entre desempenho e custos de infraestrutura. E a compatibilidade entre navegadores e dispositivos móveis demanda esforço significativo de desenvolvimento, especialmente para startups.

Para endereçar esses desafios, a AWS documentou uma solução baseada na combinação do Amazon Nova 2 Sonic com o Amazon Kinesis Video Streams WebRTC. O WebRTC é responsável por ajustar dinamicamente o bitrate em redes instáveis, o que ajuda a manter a qualidade do áudio enquanto reduz conexões perdidas. O Nova Sonic, por sua vez, viabiliza diálogos naturais em linguagem humana, permitindo que usuários interajam de forma mais fluida no idioma de sua preferência. Ambos os serviços são totalmente gerenciados pela AWS, escalando automaticamente com alta resiliência.

Nova Sonic e WebRTC: entendendo cada peça

Pipelines tradicionais de agentes de voz geralmente envolvem módulos separados para reconhecimento de fala, processamento de linguagem e síntese de voz. O Nova Sonic oferece uma arquitetura unificada de fala-para-fala (speech-to-speech) que viabiliza conversas de voz em tempo real entre usuários e agentes de IA com baixa latência. Com compreensão e geração de fala unificadas, o Nova Sonic entrega uma IA conversacional natural, próxima à interação humana. O modelo oferece diferentes estilos de fala e interfaces de ferramentas para agentes externos, permitindo construir interfaces de voz mais responsivas e com maior consciência contextual.

Um pipeline de streaming típico é composto por três componentes principais: fonte de mídia, servidor de mídia e consumidor de mídia. Esses componentes se comunicam por protocolos como RTMP, RTSP, HLS, MPEG-DASH e WebRTC.

A Comunicação em Tempo Real pela Web (WebRTC) é um protocolo público que moderniza o streaming ao vivo ao fornecer conexões diretas ponto a ponto (peer-to-peer) em tempo real, sem necessidade de plugins ou instalações adicionais. Essa abordagem elimina a necessidade de servidores intermediários e reduz significativamente a latência. Entre todos os protocolos de streaming de mídia, o WebRTC entrega a menor latência.

O WebRTC também inclui recursos nativos como streaming com taxa de bits adaptativa (ABR), correção antecipada de erros (FEC) e gerenciamento de buffer de jitter. Esses recursos ajustam automaticamente o consumo de largura de banda e resolvem problemas de perda de pacotes em conectividade fraca, mantendo conversas fluentes mesmo em condições de rede precárias. A natureza de código aberto do WebRTC e sua ampla compatibilidade com navegadores (Chrome, Firefox, Safari, Edge, Android, iOS, entre outros) aceleram a adoção da solução. Ele também é bem adequado para o processamento em tempo real de fluxos de mídia com funções de IA.

Arquitetura da solução

Existem vários cenários em que faz sentido implantar soluções de streaming ao vivo com interação de voz multilíngue:

• Veículos conectados que auxiliam motoristas com capacidades de tradução em tempo real.
• Fábricas inteligentes que suportam comunicação entre operadores de diferentes culturas por meio de sistemas de controle de qualidade ativados por voz.
• Aplicações de robótica que fornecem interações de atendimento ao cliente multilíngue.
• Dispositivos de casa inteligente que oferecem controle por voz em diferentes idiomas, possibilitando suporte técnico global por meio de tradução de áudio e orientação visual em tempo real.

A solução documenta como implantar o Nova Sonic em conjunto com o Kinesis Video Streams como um serviço WebRTC gerenciado, incluindo integração de ferramentas com fontes populares como Geração Aumentada por Recuperação (RAG), Protocolo de Contexto de Modelo (MCP) e Strands Agents.

O fluxo da arquitetura funciona da seguinte forma:

• [1] No aplicativo cliente, os usuários estabelecem o processo de negociação WebRTC conectando-se ao canal de sinalização WebRTC do Kinesis Video Streams. Os dados de áudio e vídeo são transmitidos por meio da conexão WebRTC bidirecional.
• [2] Após a troca de mensagens de sinalização para oferta/resposta do Protocolo de Descrição de Sessão (SDP) e candidatos de Estabelecimento de Conectividade Interativa (ICE), o cliente e o servidor iniciam as tentativas de conexão peer bidirecional, permitindo a transmissão de dados com baixa latência.
• [3] O canal de mídia lida com streaming de áudio e vídeo em tempo real com controle de taxa de bits adaptativa e negociação de codec. O canal de dados fornece transmissão confiável e ordenada de dados arbitrários da aplicação (textos, arquivos, mensagens de controle). Ambos utilizam criptografia Segurança da Camada de Transporte de Datagrama (DTLS) e os protocolos Utilitários de Travessia de Sessão para NAT (STUN)/Travessia Usando Retransmissores em torno de NAT (TURN) para travessia de Tradução de Endereço de Rede (NAT).
• [4] O processador de eventos de fala-para-fala orquestra a interação de eventos de entrada e eventos de saída com o Nova Sonic. Na solução, eles são categorizados em eventos de mídia transmitidos pelo canal de mídia WebRTC, e dados de texto transmitidos pelo canal de dados WebRTC.
• [5] O SDK Python é utilizado para estabelecer uma conexão HTTP/2 para streaming bidirecional com o Nova Sonic, suportando comunicação de dados de mídia em tempo real com latência mínima.
• [6] Além da conversa de áudio fala-para-fala com conhecimento pré-treinado, o Nova Sonic suporta chamadas assíncronas de ferramentas para acessar servidores MCP, Strands agents ou RAG.

Comparação com a solução WebSocket

Comparada à opção de implantação via WebSocket, a solução de fala-para-fala baseada em WebRTC oferece uma camada de rede diferente, mais adequada para dispositivos móveis e de IoT. Esses dispositivos frequentemente exigem conexões de baixa latência sem alta largura de banda de rede. A solução também incorpora uma camada personalizada de Detecção de Atividade de Voz (VAD) para uma experiência de usuário aprimorada.

Mudança no protocolo de streaming de áudio

Os dados de voz são transmitidos pelo canal de mídia WebRTC em modo streaming — especificamente pelo track de áudio da conexão peer no formato Protocolo de Transporte em Tempo Real Seguro (SRTP), em vez de mensagens WebSocket. Os recursos WebRTC (como oferta/resposta SDP, DTLS, Protocolo de Controle de Transmissão de Fluxo (SCTP), SRTP e conexão peer) foram implementados usando a biblioteca Python aiortc.

Mecanismo de detecção de voz humana

O cliente WebRTC em React captura continuamente o áudio e o envia para o servidor WebRTC em Python. Para suprimir ruídos, aumentar a precisão da fala e reduzir os tokens de áudio para o Nova Sonic, a solução aplica a Detecção de Atividade de Voz (VAD) ao pipeline no lado do servidor, com base na biblioteca Python WebRTCVAD. Construída sobre um Modelo de Mistura Gaussiana (GMM), essa biblioteca é leve, estável e rápida para processamento de áudio em nível de frame WebRTC. Outras bibliotecas como Silero VAD e Pyannote VAD também podem ser utilizadas.

Adaptação do formato de dados de áudio

O WebRTC define padrões específicos de formato de áudio e vídeo. Ao enviar e receber dados de áudio por uma conexão WebRTC, é necessário realizar algumas adaptações de formato:

• [1] Frames estéreo intercalados exigem a extração do canal de áudio esquerdo ou direito;
• [2] Taxas de amostragem de 48kHz ou outras serão reamostradas para 16kHz, conforme exigido pela API do Nova Sonic;
• [3] Valores de dados Int16 serão convertidos para Float32 para maior precisão de cálculo.

Para mais detalhes técnicos, consulte a documentação no GitHub.

Exemplos práticos da solução

O repositório no GitHub disponibiliza uma amostra genérica e dois exemplos de cenários específicos: casa inteligente e veículo conectado. Esses padrões podem ser adaptados para suas próprias aplicações.

Exemplo de casa inteligente

No cenário de casa inteligente, o usuário abre um diálogo com o Nova Sonic para controlar dispositivos IoT. Para ilustrar um pipeline de comandos completo, a solução utiliza uma Base de Conhecimento do Amazon Bedrock para recuperar tópicos MQTT e gerar respostas de IA. Em seguida, conecta-se ao servidor MCP para AWS IoT Core para entregar as mensagens de comando. Os passos de configuração estão disponíveis no readme do exemplo smart-home no GitHub.

Exemplo de veículo conectado

No cenário de veículo conectado, o sistema estabelece monitoramento em tempo real para detectar comportamentos perigosos de uso de celular por motoristas. O sistema utiliza assistentes de voz para perguntar se o motorista precisa de assistência e verificar sua atenção. A equipe de supervisão pode acessar feeds de monitoramento em tempo real em um canal de vídeo independente para confirmar o status de segurança de veículos e motoristas. As conexões WebRTC simultâneas são independentes entre si, com criptografia TLS dedicada. Os passos de configuração estão disponíveis no readme do exemplo connected-vehicle no GitHub.

Próximos passos

A solução documentada pela AWS demonstra como construir uma aplicação baseada em WebRTC que combina o Amazon Nova 2 Sonic com o Amazon Kinesis Video Streams WebRTC para endereçar barreiras comuns no streaming ao vivo — como degradação de desempenho em redes instáveis e ausência de inteligência conversacional. A base de código disponível pode ser usada como ponto de partida para construir aplicações de assistente de voz de baixa latência, inteligentes e robustas para dispositivos inteligentes e veículos conectados.

Para se aprofundar no tema:

• Leia o blog de fala-para-fala para conhecer os recursos mais recentes do Amazon Nova 2 Sonic.
• Explore o repositório de fala-para-fala no GitHub para mais cenários de uso.
• Consulte o Guia do Desenvolvedor do Amazon Kinesis Video Streams para mais casos de uso de streaming ao vivo.

Fonte

Build real-time voice streaming applications with Amazon Nova Sonic and WebRTC (https://aws.amazon.com/blogs/machine-learning/build-real-time-voice-streaming-applications-with-amazon-nova-sonic-and-webrtc/)

O que foi anunciado

A AWS anunciou que o Amazon SageMaker Data Agent agora está disponível para domínios do SageMaker Unified Studio configurados com o Centro de Identidade do IAM (IAM Identity Center). Com essa expansão, analistas e engenheiros de dados passam a contar com as capacidades de Inteligência Artificial (IA) do Data Agent diretamente nos ambientes de notebooks e no Query Editor do SageMaker.

O que o Data Agent faz na prática

A proposta central do Data Agent é eliminar a necessidade de escrever manualmente código complexo — como joins SQL, agregações e transformações em Python. Em vez disso, o profissional descreve em linguagem natural o que deseja analisar e o agente gera o código adequado, já conectado às fontes de dados configuradas no ambiente.

As fontes de dados suportadas incluem:

• Amazon Athena
• Amazon Redshift
• Amazon S3
• AWS Glue Data Catalog

Principais capacidades

O Data Agent vai além de simplesmente gerar código. Entre os recursos disponíveis, destacam-se:

• Contexto conversacional: o agente mantém o histórico da conversa entre células do notebook, tabelas selecionadas e histórico de consultas, propondo planos passo a passo antes de gerar o código.
• Casos de uso variados: cálculo de taxas de crescimento de receita trimestral, geração de visualizações, transformação de DataFrames e otimização de performance de queries — tudo via linguagem natural.
• Fix with AI (Corrigir com IA): funcionalidade de depuração inteligente que analisa erros de execução e sugere correções, acelerando o ciclo de desenvolvimento.

Disponibilidade e como começar

O recurso já está disponível em todas as regiões comerciais da AWS onde o Amazon SageMaker Unified Studio é suportado.

Para começar a usar, basta acessar um projeto no SageMaker Unified Studio, abrir um notebook ou o Query Editor e selecionar o painel do Data Agent.

Para mais detalhes, a AWS disponibiliza a página oficial do Amazon SageMaker Unified Studio e a documentação “Use o SageMaker Data Agent” no guia do usuário do SageMaker Unified Studio.

Fonte

Amazon SageMaker Data Agent now available for IAM Identity Center domains (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-sagemaker-data-agent-idc/)

O desafio de governança no fine-tuning de LLMs

Realizar fine-tuning de Modelos de Linguagem de Grande Escala (LLMs) em ambientes que combinam serviços de diferentes provedores traz um desafio específico: como manter governança rigorosa sobre os dados sem abrir mão das melhores ferramentas de Aprendizado de Máquina (ML) disponíveis?

Quando se usa o Amazon SageMaker AI em conjunto com o Databricks Unity Catalog, esse problema fica ainda mais evidente. O Unity Catalog gerencia metadados e permissões, enquanto os dados em si ficam armazenados no Amazon Simple Storage Service (Amazon S3) — quando o ambiente de nuvem escolhido é a AWS. O risco é que os jobs de treinamento do SageMaker AI acessem esses dados no S3 contornando o modelo de autorização granular do Unity Catalog, criando lacunas de auditoria e exposição a riscos de conformidade.

Em indústrias reguladas, saber exatamente quais dados treinaram quais modelos não é opcional — é um requisito crítico. Sem um padrão de integração estruturado, perde-se visibilidade sobre essa linhagem, e a conformidade fica comprometida.

Visão geral da solução

A solução demonstrada pela AWS aborda esse problema integrando três serviços principais: o Unity Catalog para governança centralizada, o Amazon EMR Serverless para pré-processamento com Apache Spark, e o SageMaker AI para o treinamento do modelo. O fluxo completo realiza as seguintes etapas:

• Leitura dos dados de treinamento a partir de uma tabela gerenciada pelo Unity Catalog, com controles de governança aplicados
• Pré-processamento dos dados usando EMR Serverless com Apache Spark
• Fine-tuning do modelo Ministral-3-3B-Instruct via jobs de treinamento do SageMaker AI
• Rastreamento da linhagem de dados no Unity Catalog, desde os dados brutos até o modelo treinado

Os componentes e suas funções na arquitetura são os seguintes:

• Amazon SageMaker AI Studio – JupyterLab Space: orquestração do fluxo e treinamento do modelo
• Amazon EMR Serverless: pré-processamento de dados com Spark, sem gerenciamento de clusters
• Databricks Unity Catalog: catálogo de metadados, governança e rastreamento de linhagem
• Hugging Face: acesso ao modelo pré-treinado
• Amazon S3: armazenamento de dados e artefatos do modelo
• AWS Secrets Manager: gerenciamento seguro de credenciais

No fluxo operacional, o usuário acessa o SageMaker AI Studio, inicia o pré-processamento via job do EMR Serverless — que acessa os dados no S3 gerenciado pelo Unity Catalog usando OAuth armazenado no Secrets Manager — e, após o processamento, o job de treinamento do SageMaker AI busca o modelo no Hugging Face, realiza o fine-tuning e devolve os artefatos ao bucket S3. Por fim, o modelo é registrado no Unity Catalog com linhagem de dados completa.

Pré-requisitos

Antes de iniciar, é necessário ter acesso e permissões configuradas para os seguintes serviços AWS: SageMaker AI, EMR Serverless, Amazon S3, AWS Secrets Manager, AWS Identity and Access Management (IAM), Amazon Virtual Private Cloud (Amazon VPC), Amazon CloudWatch Logs e Amazon Elastic Container Registry (Amazon ECR). Também é necessário ter uma VPC com acesso à internet configurado.

No lado do Databricks, os requisitos são: configurar o Unity Catalog para o Workspace, habilitar acesso externo a dados no Metastore (desativado por padrão) e criar credenciais OAuth (Client ID e secret) para acesso programático ao Databricks.

Passo a passo da implementação

O tutorial completo está disponível no notebook LLM_Finetunig_SageMaker_AI_Unity_Catalog.ipynb, que deve ser executado no SageMaker AI Studio. Para isso, acesse o Console do Amazon SageMaker AI, crie um domínio Studio se necessário (usando a configuração rápida), e crie um JupyterLab Space com a instância ml.m5.2xlarge, imagem Sagemaker Distribution 3.8.0 e 5 GB de armazenamento.

Etapa 1: Configuração AWS

Nesta etapa, são criados os recursos base: bucket S3 gerenciado pelo Unity Catalog com upload do dataset, secret no AWS Secrets Manager para as credenciais OAuth do Databricks, e as roles de Gerenciamento de Identidade e Acesso (IAM) necessárias para o EMR Serverless e o SageMaker AI.

O dataset utilizado são os arquivos SEC EDGAR (Sistema Eletrônico de Coleta, Análise e Recuperação de Dados da Comissão de Valores Mobiliários dos EUA) — especificamente formulários 10-K e 10-Q de empresas do S&P 500 de 2023 a 2024, com foco na seção de Fatores de Risco. Os dados são armazenados em formato JSON no S3, com a seguinte estrutura:

s3://aws-blog-smai-uc-bucket-ACCOUNTID/
├── raw/
│   └── risk_factors/
│       ├── form_type=10-K/
│       │   └── fiscal_year=2024/
│       │       └── cik=0000320193/
│       │           └── risk_factors.json
│       └── form_type=10-Q/
│           └── fiscal_year=2024/
│               └── quarter=1/
│                   └── cik=0000320193/
│                       └── risk_factors.json
├── curated/
│   └── ml/

Para autenticação, a solução usa OAuth para service principals (OAuth M2M), que gera tokens de curta duração. As credenciais são criadas seguindo a documentação do Databricks e armazenadas no AWS Secrets Manager.

As políticas de IAM para o EMR Serverless e para o SageMaker AI concedem acesso ao bucket S3 gerenciado pelo Unity Catalog, ao Secrets Manager e ao CloudWatch Logs. A role do SageMaker AI inclui também permissões para o ECR. Veja os exemplos de política abaixo:

Role do EMR Serverless:

emr_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                f"arn:aws:s3:::{UC_MANAGED_BUCKET}/*",
                f"arn:aws:s3:::{UC_MANAGED_BUCKET}"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": [
                f"arn:aws:secretsmanager:{AWS_REGION}:{AWS_ACCOUNT_ID}:secret:databricks/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": f"arn:aws:logs:{AWS_REGION}:{AWS_ACCOUNT_ID}:*"
        }
    ]
}

Role de execução do SageMaker AI:

sagemaker_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                f"arn:aws:s3:::{UC_MANAGED_BUCKET}/*",
                f"arn:aws:s3:::{UC_MANAGED_BUCKET}"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": [
                f"arn:aws:secretsmanager:{AWS_REGION}:{AWS_ACCOUNT_ID}:secret:databricks/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams"
            ],
            "Resource": f"arn:aws:logs:{AWS_REGION}:{AWS_ACCOUNT_ID}:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage"
            ],
            "Resource": "*"
        }
    ]
}

Etapa 2: Configuração do Databricks Unity Catalog

Nesta etapa, o bucket S3 é registrado como External Location no Unity Catalog. Em seguida, são criados os objetos de banco de dados: catálogo, schemas e tabela externa. As permissões necessárias são concedidas ao Service Principal — incluindo USE CATALOG, USE SCHEMA, SELECT na tabela de dados brutos e CREATE TABLE nos schemas de curadoria e ML.

Após a configuração, o cliente Databricks é inicializado e a conexão com o Unity Catalog é testada:

# Initialize Databricks client
from databricks.sdk import WorkspaceClient

w = WorkspaceClient(
    host=UNITY_WORKSPACE_URL,
    client_id=DATABRICKS_CLIENT_ID,
    client_secret=DATABRICKS_CLIENT_SECRET
)

table_info = w.tables.get(f"{UNITY_CATALOG_NAME}.{UNITY_SCHEMA_DATA}.{UNITY_TABLE_NAME}")
print(f"Table: {table_info.name}")
print(f"Storage Location: {table_info.storage_location}")
print(f"Table Format: {table_info.data_source_format}")

A saída esperada confirma a tabela, sua localização no S3 e o formato Delta:

Table: risk_factors
Storage Location: s3:// aws-blog-smai-uc-bucket-ACCOUNTID/raw/risk_factors
Table Format: DataSourceFormat.DELTA

Etapa 3: Configuração da aplicação EMR Serverless

O EMR Serverless é criado em uma VPC com acesso à internet. Isso é necessário porque, como o EMR Serverless não inclui suporte nativo ao Delta Lake (pelo menos até fevereiro de 2026), a aplicação Spark precisa baixar os arquivos JAR do Delta Lake do repositório Maven Central durante a inicialização. Sem acesso à internet, esse download falha e o job não consegue resolver o formato de tabela Delta.

Etapa 4: Pré-processamento com EMR Serverless

Um script de pré-processamento lê os fatores de risco do SEC EDGAR da tabela Delta, filtra e limpa os dados, formata o conteúdo como prompt no estilo instrução para fine-tuning e grava os resultados como tabela Delta no S3. Os parâmetros Spark necessários para habilitar o Delta Lake são configurados assim:

jobDriver={
    'sparkSubmit': {
        'sparkSubmitParameters': ' '.join([
            '--packages io.delta:delta-spark_2.12:3.2.0',
            '--conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension',
            '--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog'
        ])
    }

Após a conclusão do job, os dados pré-processados são registrados como tabela Delta no schema de curadoria do Unity Catalog via SDK do Databricks, usando um SQL warehouse serverless.

Etapa 5: Fine-tuning com SageMaker AI

Com o dataset preparado, o job de treinamento do SageMaker AI realiza o fine-tuning do modelo Ministral-3-3B-Instruct-2512, disponível no Hugging Face. Trata-se de um modelo compacto de 3 bilhões de parâmetros da Mistral AI, otimizado para seguir instruções com bom desempenho em tarefas de raciocínio.

O script de treinamento aplica duas técnicas de eficiência de memória: quantização em ponto flutuante de 8 bits (FP8) para reduzir o uso de memória, e Adaptação de Baixa Classificação (LoRA) para treinar apenas 1–2% dos parâmetros em vez dos 3 bilhões completos. Os dados são tokenizados com janela de contexto de 1.024 tokens. O treinamento usa uma instância ml.g5.16xlarge, e os artefatos do modelo são enviados ao bucket S3 ao final do job.

Etapa 6: Registro do modelo no Unity Catalog

Após o upload dos artefatos para o S3, o modelo fine-tunado é registrado no schema ML do Unity Catalog usando o MLflow gerenciado pelo Databricks via SDK. Um experimento MLflow é criado para registrar metadados de treinamento — hiperparâmetros, tabela de origem, detalhes do job — e o modelo é versionado com documentação que inclui linhagem dos dados de origem, serviço de treinamento e especificações do modelo.

Etapa 7: Criação de linhagem de dados no Unity Catalog

O Unity Catalog captura automaticamente a linhagem de dados para workloads executados dentro do Databricks. Para workloads externos — como jobs do EMR Serverless e jobs de treinamento do SageMaker AI — é possível adicionar metadados e linhagem através da API de Metadados Externos e da API de Linhagem Externa. Essa capacidade de “traga sua própria linhagem de dados” (atualmente em prévia pública desde abril de 2026) oferece uma visão completa da linhagem no Unity Catalog.

Para o fluxo completo, são criados os seguintes objetos de linhagem:

• Metadados externos do job EMR Serverless
• Linhagem upstream: tabela bruta → job EMR Serverless
• Linhagem downstream: job EMR Serverless → tabela pré-processada
• Metadados externos do job de treinamento do SageMaker AI
• Linhagem upstream: tabela pré-processada → job de treinamento
• Linhagem downstream: job de treinamento → versão do modelo

Com isso, é possível visualizar o grafo completo de linhagem — dos dados brutos ao modelo fine-tunado — diretamente no console do Unity Catalog.

Limpeza dos recursos

Após validar a solução, a AWS recomenda remover os seguintes recursos para evitar cobranças contínuas: aplicação EMR Serverless, buckets e objetos S3, roles e políticas IAM, secrets no AWS Secrets Manager, recursos de VPC e objetos do Unity Catalog (catálogo, schema, tabela e service principal).

Conclusão

A integração entre Databricks Unity Catalog e Amazon SageMaker AI apresentada pela AWS demonstra como é possível realizar fine-tuning de LLMs com governança contínua, sem comprometer segurança ou conformidade. Combinando o Unity Catalog para controle de acesso e linhagem, o EMR Serverless para pré-processamento escalável e o SageMaker AI para treinamento, o resultado é um pipeline de ML governado de ponta a ponta — adequado para ambientes de produção e indústrias reguladas.

O padrão pode ser reutilizado com outros LLMs e datasets maiores, servindo como base para workloads de IA generativa em ambientes multicloud com requisitos rigorosos de auditoria.

Fonte

Fine-tune LLM with Databricks Unity Catalog and Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/fine-tune-llm-with-databricks-unity-catalog-and-amazon-sagemaker-ai/)

O que mudou com o EU AI Act em agosto de 2025

Em 2 de agosto de 2025, o EU AI Act passou a vigorar com novos requisitos para organizações que trabalham com modelos de inteligência artificial de propósito geral — os chamados modelos GPAI (Inteligência Artificial de Propósito Geral). Uma das exigências centrais afeta diretamente quem realiza fine-tuning de grandes modelos de linguagem (LLMs, na sigla em inglês): é preciso rastrear o consumo computacional do treinamento, medido em operações de ponto flutuante, ou FLOPs (Operações de Ponto Flutuante).

O motivo é simples: a regulação precisa distinguir quem apenas usa um modelo existente (o chamado usuário downstream) de quem efetivamente cria um novo modelo — e, portanto, assume as responsabilidades legais de um provedor GPAI. Essa distinção depende diretamente de quanto processamento computacional foi consumido durante o fine-tuning.

A regra de um terço e os limiares de FLOPs

O EU AI Act adota a chamada “regra de um terço”: se o fine-tuning consumir mais de um terço do processamento computacional usado no pré-treinamento original do modelo, a organização passa a ser tratada como provedora GPAI — com todas as obrigações que isso implica.

A lógica regulatória por trás desse limite de 30% é que modificações que consomem mais de um terço do processamento original tendem a alterar significativamente o comportamento do modelo, criando efetivamente um novo modelo com riscos distintos.

Na prática, existem três cenários e limiares aplicáveis:

• Processamento de pré-treinamento conhecido e ≥ 10²³ FLOPs: o limiar é 30% do processamento real de pré-treinamento.
• Processamento de pré-treinamento desconhecido ou < 10²³ FLOPs: aplica-se o limiar padrão de 3,3×10²² FLOPs.
• Modelos de Risco Sistêmico (pré-treinamento ≥ 10²⁵ FLOPs): o limiar é 3,3×10²⁴ FLOPs (se o processamento base for desconhecido).

Como os provedores de modelos raramente publicam os FLOPs exatos de pré-treinamento, a maioria das organizações se enquadra no segundo cenário — o limiar padrão de 3,3×10²² FLOPs.

Para orientar a tomada de decisão, vale seguir este fluxo:

• Você conhece os FLOPs de pré-treinamento do modelo base? Se não, aplique diretamente o limiar padrão de 3,3×10²² FLOPs.
• Se sim: o pré-treinamento é ≥ 10²⁵ FLOPs? Use o limiar de Risco Sistêmico (3,3×10²⁴ FLOPs).
• Se não: o pré-treinamento é ≥ 10²³ FLOPs? Use 30% do valor real.
• Se também não: aplique o limiar padrão de 3,3×10²² FLOPs.

Como exemplo prático: o fine-tuning do Llama-3-70B — cujo pré-treinamento estimado é de pelo menos 1,5×10²⁴ FLOPs — define o limiar em 4,5×10²³ FLOPs. Superar esse valor significa assumir as obrigações completas de provedor GPAI, que incluem divulgar detalhes da arquitetura e do processo de treinamento, publicar a lista de fontes de dados utilizadas e demonstrar conformidade com a legislação europeia de direitos autorais. O descumprimento pode resultar em multas de até €15 milhões ou 3% do faturamento global anual, o que for maior.

Por que o rastreamento manual de FLOPs é um problema

Calcular FLOPs manualmente apresenta três desafios concretos. Primeiro, as fórmulas são complexas e variam dependendo do método de treinamento: fine-tuning completo ou métodos eficientes em parâmetros, como LoRA (Adaptação de Baixo Posto), que atualizam apenas um subconjunto dos parâmetros do modelo. Segundo, determinar o limiar aplicável é difícil porque os valores de processamento de pré-treinamento raramente são publicados pelos provedores. Terceiro, manter um histórico de auditoria — um registro permanente das métricas de conformidade para revisão regulatória — ao longo de múltiplos jobs de treinamento gera sobrecarga operacional considerável.

Erros nesse cálculo podem mudar completamente a classificação regulatória da organização, com consequências legais e financeiras significativas.

O Fine-Tuning FLOPs Meter: solução open source da AWS

Para resolver esses desafios, a AWS disponibilizou o toolkit open source Fine-Tuning FLOPs Meter, integrado ao Amazon SageMaker AI. A ferramenta está disponível no repositório Amazon SageMaker Generative AI recipes e se integra a fluxos de treinamento baseados em Hugging Face.

O toolkit cobre três estágios do ciclo de fine-tuning:

• Estimativa pré-treinamento (opcional): um utilitário independente permite comparar os FLOPs esperados entre diferentes métodos (LoRA, Spectrum e fine-tuning completo) antes de lançar o job. Útil para planejamento e para verificar o quão próxima uma configuração está do limiar regulatório.
• Rastreamento em tempo real (funcionalidade principal): usa um TrainerCallback do Hugging Face para calcular FLOPs durante o treinamento, combinando análise baseada na arquitetura do modelo e monitoramento de hardware via NVML (Biblioteca de Gerenciamento NVIDIA).
• Trilha de auditoria pós-treinamento: ao final do treinamento, gera automaticamente um arquivo JSON com as métricas completas de conformidade, que pode ser persistido no Amazon Simple Storage Service (Amazon S3) ou no Amazon DynamoDB.

A ativação do rastreamento exige apenas uma linha no arquivo de configuração YAML da receita:

compute_flops: true

Como os FLOPs são calculados

O toolkit implementa dois métodos de cálculo, ambos executados automaticamente:

Método analítico (baseado em arquitetura)

É o método primário para fins de conformidade regulatória. O EU AI Act (Seção A.2.1) descreve a fórmula padrão para transformers densos:

C ≈ 6 × P × D

Onde P é o número de parâmetros e D é o número de tokens de treinamento. Essa fórmula assume fine-tuning completo. Para métodos eficientes em parâmetros como LoRA ou Spectrum, o toolkit usa uma fórmula aprimorada:

F_ft = (4 × N_total + 2 × N_trainable) × tokens_processed

O detalhamento é o seguinte: 4 × N_total representa o passo forward (2×) mais o cálculo do gradiente no passo backward por todas as camadas (2×), incluindo as congeladas; 2 × N_trainable representa o cálculo do gradiente apenas para os pesos treináveis. Para fine-tuning completo, onde todos os parâmetros são treináveis, a fórmula se reduz a 6 × N × D, equivalente à fórmula da regulação europeia.

Método baseado em hardware (limite superior conservador)

Usa monitoramento de GPU via NVML com a fórmula:

C = N_gpus × L × H × U

Onde N_gpus é o número de GPUs, L é a duração do treinamento em segundos, H é o desempenho teórico de pico (FLOPs) e U é a utilização. O toolkit usa U = 1.0 (100% de utilização) para produzir um limite superior conservador.

Lógica de limiar

A função determine_compliance_threshold() implementa a lógica do EU AI Act:

EU_AI_ACT_GPAI_THRESHOLD = 1e23 # 10²³ FLOPs
EU_AI_ACT_DEFAULT_THRESHOLD = 3.3e22 # Um terço de 10²³

if pretrain_flops is None or pretrain_flops < EU_AI_ACT_GPAI_THRESHOLD:
    threshold = EU_AI_ACT_DEFAULT_THRESHOLD # "default_3.3e22"
else:
    threshold = 0.30 * pretrain_flops # "30pct_of_actual_pretraining"

Integração com jobs de treinamento no SageMaker AI

O FLOPs Meter funciona como um TrainerCallback do Hugging Face. Ao iniciar o treinamento, o script verifica o flag compute_flops e, se ativado, inicializa o FlopsMeterCallback com a contagem de parâmetros do modelo e a variável de ambiente opcional PRETRAIN_FLOPS. Um TokenCountingSFTTrainer customizado substitui o SFTTrainer padrão para contar tokens não-padding a cada passo de treinamento.

Veja o trecho de código de inicialização do callback:

n_total = sum(p.numel() for p in model.parameters())
n_trainable = sum(p.numel() for p in model.parameters() if p.requires_grad)

flops_cb = FlopsMeterCallback(
    pad_token_id=tokenizer.pad_token_id,
    pretrain_flops=pretrain_flops,  # from PRETRAIN_FLOPS env var
    sample_nvml=True,
    n_total=n_total,
    n_trainable=n_trainable,
    model_name=model_args.model_name_or_path,
    num_epochs=training_args.num_train_epochs,
)

Ao final do treinamento, o callback grava um arquivo flops_meter.json em /opt/ml/output/. O pipeline então faz o upload para o Amazon S3 e persiste os dados no Amazon DynamoDB, criando uma trilha de auditoria permanente.

Exemplo prático: Llama-3.2-3B no SageMaker AI

O walkthrough demonstrado pela AWS utiliza o modelo meta-llama/Llama-3.2-3B-Instruct (3,21 bilhões de parâmetros). Como a Meta não publicou os FLOPs exatos de pré-treinamento desse modelo, o caminho do limiar padrão se aplica automaticamente: 3,3×10²² FLOPs.

A configuração de receita para Llama-3.2-3B com LoRA e rastreamento de FLOPs ativado é:

model_name_or_path: meta-llama/Llama-3.2-3B-Instruct
dataset_id_or_path: your-dataset.jsonl
use_peft: true
compute_flops: true
per_device_train_batch_size: 8
num_train_epochs: 10
learning_rate: 2e-5
peft_config:
  r: 8
  lora_alpha: 16
  target_modules: ["q_proj", "v_proj"]

Para lançar o job de treinamento via SDK Python do SageMaker:

from sagemaker.modules.configs import Compute, SourceCode
from sagemaker.modules.train import ModelTrainer

training_instance_type = "ml.g5.4xlarge"

pytorch_image_uri = sagemaker.image_uris.retrieve(
    framework="pytorch",
    region=sess.boto_session.region_name,
    version="2.7.1",
    instance_type=training_instance_type,
    image_scope="training",
)

source_code = SourceCode(
    source_dir="./sagemaker_code",
    command="bash sm_accelerate_train.sh --config hf_recipes/meta-llama/Llama-3.2-3B-Instruct--vanilla-peft-qlora.yaml",
)

compute = Compute(
    instance_type=training_instance_type,
    instance_count=1,
    volume_size_in_gb=300,
)

model_trainer = ModelTrainer(
    training_image=pytorch_image_uri,
    source_code=source_code,
    compute=compute,
    role=role,
    environment={
        "FLOPS_METER_NVML": "1",
    },
)

model_trainer.train()

Como os FLOPs de pré-treinamento não são conhecidos para esse modelo, a variável de ambiente PRETRAIN_FLOPS é omitida e o limiar padrão é aplicado automaticamente.

Documentação de conformidade gerada

Ao término do treinamento, o toolkit gera um arquivo flops_meter.json com as métricas necessárias para documentação regulatória:

{
  "Flops_architecture": "1.45e+13",
  "Flops_hardware": "1.52e+15",
  "Flops_original": null,
  "N_total": 1585294704,
  "N_trainable": 680094720,
  "threshold_type": "default_3.3e22",
  "threshold_value": "3.30e+22",
  "pct_of_pretrain": 0.000000439,
  "exceeds_30pct": false,
  "tokens_processed": 2150,
  "model_name": "meta-llama/Llama-3.2-3B-Instruct",
  "num_epochs": 10,
  "training_duration_seconds": 245.30,
  "gpu_name": "NVIDIA A10G",
  "instance_type": "ml.g5.4xlarge",
  "training_job_name": "pipelines-abc123-TrainingStep-xyz789",
  "recipe_config": "hf_recipes/meta-llama/Llama-3.2-3B-Instruct--vanilla-peft-qlora.yaml"
}

O campo Flops_architecture deve ser usado como métrica primária de conformidade — ele reflete com precisão a configuração real do treinamento. O campo Flops_hardware fornece um limite superior conservador, útil como margem de segurança para relatórios mais cautelosos. O campo exceeds_30pct é o indicador booleano para avaliação rápida de conformidade.

O que fazer se o limiar for ultrapassado

Se o relatório de conformidade mostrar exceeds_30pct: true, a organização é classificada como provedora GPAI sob o EU AI Act. Os próximos passos incluem: documentar a arquitetura do modelo e o processo de treinamento; preparar uma lista pública das fontes de dados de treinamento; demonstrar conformidade com a legislação europeia de direitos autorais; e considerar a consulta a assessoria jurídica especializada em regulações de IA da União Europeia.

Vale notar que existem obrigações adicionais caso o modelo GPAI seja classificado como de Risco Sistêmico. Uma alternativa técnica é reduzir o escopo do treinamento — menos épocas, dataset menor ou migração para LoRA — para permanecer abaixo do limiar.

Escala para cargas de trabalho em produção

O exemplo de demonstração utilizou um dataset pequeno (2.150 tokens). Em produção, o processamento típico envolve milhões de tokens. Para referência: o fine-tuning do Llama-3.2-3B em 1 milhão de tokens com LoRA resulta em aproximadamente 6,7×10¹⁸ FLOPs — bem abaixo do limiar de 3,3×10²². Já o fine-tuning completo no mesmo dataset consome aproximadamente 1,9×10¹⁹ FLOPs, aproximando-se mais do limiar.

Como regra prática, a preocupação com conformidade começa quando os FLOPs atingem 10²¹ ou mais — cerca de 3% do limiar padrão. A partir desse ponto, recomenda-se executar o utilitário de estimativa pré-treinamento antes de cada job. Para a maioria dos jobs de fine-tuning com LoRA em modelos abaixo de 10 bilhões de parâmetros, o resultado permanece bem abaixo do limiar mesmo com milhões de tokens de treinamento.

Fonte

Navigating EU AI Act requirements for LLM fine-tuning on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/navigating-eu-ai-act-requirements-for-llm-fine-tuning-on-amazon-sagemaker-ai/)

O problema clássico do ovo e da galinha no processamento de documentos

Quem já trabalhou com Processamento Inteligente de Documentos (IDP) conhece bem o dilema inicial: antes de extrair informações de documentos, você precisa de um schema que defina o que deve ser extraído. Mas como criar esses schemas quando você tem milhares de documentos sem saber quais tipos existem na coleção? Fazer isso manualmente, em escala, consome tempo e recursos consideráveis, tornando difícil justificar o investimento em iniciativas de IDP.

Para resolver exatamente esse problema, a AWS apresentou a funcionalidade de descoberta multi-documento no IDP Accelerator. Ela atua como uma etapa de pré-processamento automatizada, analisando documentos desconhecidos, agrupando-os por tipo e gerando schemas prontos para uso.

O que é o IDP Accelerator

O IDP Accelerator é uma solução escalável, serverless e de código aberto para processamento automatizado de documentos e extração de informações. Para configurá-lo para tipos específicos de documentos, é necessário um arquivo de configuração que define as classes e os campos a serem extraídos. Um exemplo mínimo está disponível no repositório GitHub do IDP Accelerator.

O IDP Accelerator já contava com um Módulo de Descoberta capaz de gerar uma configuração de classe a partir de um único documento de exemplo. O problema é que esse recurso exige que o usuário já conheça as classes de documentos e consiga identificar um exemplo representativo para cada uma. A nova funcionalidade multi-documento remove esse pré-requisito, acelerando o caminho para aplicar o IDP Accelerator a coleções de documentos sem rótulo.

Como a solução funciona

A nova funcionalidade está integrada ao Módulo de Descoberta existente como uma capacidade “Múltiplos Documentos”, ao lado da opção “Documento Único” já disponível. A orquestração é feita por uma máquina de estados do AWS Step Functions e por funções do AWS Lambda para computação serverless.

Os documentos são processados a partir de um bucket do Amazon Simple Storage Service (Amazon S3) ou de um arquivo Zip enviado diretamente. Os modelos disponíveis pelo Amazon Bedrock geram os schemas, que são automaticamente integrados ao arquivo de configuração do IDP Accelerator.

O fluxo completo acontece em três grandes etapas: geração de embeddings, agrupamento de documentos e geração agêntica de schemas — com uma etapa adicional de análise e reflexão ao final.

Detalhes técnicos do pipeline

Geração de embeddings

O processo começa convertendo cada documento em um embedding vetorial — uma representação numérica das características visuais do documento. Para documentos com múltiplas páginas, apenas a primeira página é utilizada.

A solução usa embeddings visuais em vez de texto extraído por OCR (Reconhecimento Óptico de Caracteres). A razão é que embeddings visuais capturam layout, formatação e pistas estruturais que distinguem tipos de documentos mesmo quando o conteúdo textual é semelhante. O modelo padrão adotado é o Cohere Embed v4, disponível pelo Amazon Bedrock. A etapa de embedding já trata automaticamente questões como compressão de imagem, lógica de retry e controle de taxa de requisições.

Agrupamento de documentos

Com os embeddings gerados, a solução precisa descobrir quantos tipos de documentos existem na coleção. Para isso, utiliza o silhouette score (pontuação de silhueta), uma métrica que mede o quão bem separados estão os grupos entre si e o quão compactos são os documentos dentro de cada grupo.

Usando o algoritmo k-means, o sistema testa valores de k (número de grupos) de 2 a 20 por padrão e seleciona o agrupamento com a maior pontuação de silhueta. Para garantir grupos significativos, cada cluster precisa ter pelo menos dois documentos. Se necessário, o limite superior de k é reduzido abaixo de 20 para satisfazer essa restrição.

Validação da abordagem de embeddings e clustering

Para validar a abordagem, a AWS realizou experimentos com o Cohere Embed v4 sobre um subconjunto do dataset OCR-benchmark, disponível no bucket de conjunto de testes implantado com o stack CloudFormation do IDP Accelerator. Esse subconjunto contém 293 documentos distribuídos em 9 tipos: cheque bancário, contrato de locação comercial, extrato de cartão de crédito, nota de entrega, inspeção de equipamento, glossário, formulário de petição, imóvel e escala de turnos.

O objetivo era verificar se o k-means conseguia identificar corretamente esses agrupamentos usando o modelo de embedding. O resultado foi expressivo: a maior pontuação de silhueta ocorreu exatamente em k=9, correspondendo ao número real de tipos de documentos no dataset.

Para visualizar os resultados, foi gerado um gráfico t-SNE (Incorporação de Vizinhos Estocásticos Distribuídos em t — t-SNE), uma técnica de visualização que reduz dados de alta dimensionalidade para um espaço bidimensional preservando as relações entre os pontos. O gráfico mostrou os clusters claramente separados, cada um correspondendo a um tipo de documento.

O agrupamento atingiu um Índice Rand Ajustado (ARI) e uma Informação Mútua Normalizada (NMI) perfeitos, ambos com valor 1.0. O ARI mede o quão bem o agrupamento corresponde aos grupos reais, enquanto o NMI quantifica a informação compartilhada entre os clusters previstos e os reais. Cada cluster mapeou um-para-um para uma classe de documento real com 100% de pureza.

Esses resultados demonstram que embeddings multimodais de alta qualidade permitem classificação de documentos totalmente não supervisionada — sem nenhum dado de treinamento rotulado. Vale ressaltar, porém, que o desempenho nesse dataset de benchmark não garante resultados similares em outras coleções de documentos, pois as características específicas de cada dataset influenciam diretamente a qualidade dos resultados.

Geração agêntica de schemas

Após a identificação dos clusters, o pipeline entra na fase agêntica. Para cada cluster, um Strands Agent é invocado para determinar o tipo de documento e gerar um schema. A escolha pelo Strands Agents se deve à abordagem orientada pelo modelo, que oferece ao LLM a flexibilidade de raciocinar autonomamente sobre cada schema.

O agente precisa visualizar documentos em diferentes posições dentro do cluster para capturar toda a variedade antes de gerar o schema — por exemplo, um documento próximo ao centro, um na periferia e um a distância intermediária. Uma abordagem determinística e fixa de amostragem não funcionaria aqui, pois a qualidade do agrupamento depende fortemente dos documentos específicos de cada coleção.

Para isso, o agente conta com duas ferramentas especializadas:

• Ferramenta de Análise de Cluster — Recupera IDs de documentos ordenados por distância do centróide do cluster, permitindo que o agente amostre estrategicamente ao longo do espectro de variação dentro do cluster.
• Ferramenta de Visualização de Documento — Busca e comprime imagens de documentos para inspeção visual, tratando automaticamente as restrições de tamanho para a janela de contexto do modelo.

O prompt de sistema do agente incorpora conhecimento de domínio sobre convenções de JSON Schema e requisitos da configuração do IDP Accelerator. O agente é instruído a:

• Amostrar documentos estrategicamente, parando cedo se já tiver cobertura suficiente.
• Gerar JSON Schemas com metadados adequados, definições de tipo e descrições.
• Incluir anotações específicas do IDP Accelerator como x-aws-idp-document-type e x-aws-idp-evaluation-method. O campo x-aws-idp-evaluation-method é utilizado pela extensão de avaliação baseada no Stickler.
• Criar definições reutilizáveis ($defs) para estruturas comuns como endereços, itens de linha e informações fiscais.
• Aplicar métodos de avaliação adequados conforme o tipo de campo: EXACT para strings, NUMERIC_EXACT para números e LLM para objetos complexos ou aninhados.

Os agentes rodam em paralelo, então não é necessário esperar que um cluster termine para o próximo começar.

Análise e reflexão dos schemas

Após cada agente gerar seu schema de forma independente, uma etapa de análise avalia a diferenciação entre os resultados. Ela verifica se os agrupamentos descobertos estão bem separados ou se há sobreposições, e se os schemas gerados são completos e consistentes. O sistema identifica redundâncias ou duplicações entre tipos de documentos e apresenta recomendações concretas, como mesclar clusters ou refinar definições de campos. O resultado final é um relatório de qualidade com uma visão geral legível das classes identificadas, visível nos detalhes do job de descoberta no IDP Accelerator.

Como executar a descoberta multi-documento

Passo 1: Criar uma nova configuração

Acesse a seção de Configuração no console do IDP Accelerator e selecione Visualizar/Editar Configuração. Escolha Schema de Documento > Limpar Tudo para criar uma configuração vazia. Em seguida, selecione Salvar como Versão, forneça um nome descritivo e confirme.

Passo 2: Executar a descoberta multi-documento

Com a configuração criada, acesse a seção de Descoberta e selecione a opção Múltiplos Documentos. Escolha a versão de configuração recém-criada e configure a fonte de documentos: selecione Caminho S3 ou Upload Zip, escolha o bucket de origem e especifique o prefixo S3 onde os documentos estão armazenados. Os documentos precisam estar em um dos buckets existentes do IDP Accelerator (Discovery Bucket, Test Bucket ou Input Bucket) para usar a opção de bucket de origem. Clique em Iniciar Descoberta para acionar a máquina de estados.

Passo 3: Monitorar o job e visualizar os resultados

Uma nova entrada aparecerá na tabela de jobs de Descoberta Multi-Documento, mostrando o status de execução, a etapa atual e metadados. Após a conclusão, acesse os detalhes do job para visualizar o Relatório de Qualidade. As classes descobertas e seus schemas JSON são automaticamente integrados ao arquivo de configuração.

Boas práticas para melhores resultados

Antes de executar o job de descoberta multi-documento em larga escala, vale considerar algumas recomendações:

• Como o workflow processa apenas a primeira página de cada PDF, certifique-se de que os arquivos de entrada sejam documentos individuais. Pacotes com múltiplos documentos ainda não são suportados.
• Após obter os resultados iniciais, revise o relatório de qualidade com cuidado para identificar problemas como clusters sobrepostos ou distribuições desiguais de documentos antes de finalizar os schemas.
• Se a qualidade dos schemas for inconsistente entre clusters, verifique se a coleção tem uma distribuição muito desigual de tipos de documentos. Executar o job em um subconjunto mais balanceado pode ajudar o agente a produzir clusters e schemas mais confiáveis.

Próximos passos após a descoberta

O que fazer depois depende do que o workflow encontrou nos documentos:

• Schemas limpos e baixa sobreposição no relatório: o caminho está livre para executar o IDP em escala. Os schemas já estão automaticamente adicionados ao campo de classes do arquivo de configuração do IDP Accelerator.
• Relatório indicou clusters sobrepostos: revise as recomendações e use-as para refinar os schemas gerados, o que pode incluir mesclar schemas similares em uma única classe ou ajustar definições de campos para reduzir sobreposição.
• Qualidade inconsistente entre clusters: verifique a distribuição dos tipos de documentos na coleção e considere executar o job em um subconjunto mais balanceado.

Conclusão

A funcionalidade de descoberta multi-documento resolve um desafio clássico no processamento de documentos: você precisa de schemas para processar documentos, mas precisa processar documentos para construir schemas. A solução combina embeddings visuais, agrupamento automático e geração agêntica de schemas com LLMs multimodais, transformando uma coleção opaca de documentos desconhecidos em classes e schemas estruturados, prontos para revisão humana.

Quem quiser experimentar ou contribuir com a solução pode acessar o repositório GitHub do IDP Accelerator para abrir issues ou pull requests.

Fonte

Automate schema generation for intelligent document processing (https://aws.amazon.com/blogs/machine-learning/automate-schema-generation-for-intelligent-document-processing/)