A AWS adicionou a amazon-opensearch-service skill ao seu Agent Toolkit, e eu a submeti a um teste de full-stack construindo um backend de geração aumentada por recuperação (RAG) no Amazon OpenSearch Serverless NextGen. A ferramenta reduz drasticamente o tempo necessário para configurar um cluster OpenSearch de nível de produção, mas ainda falha quando você pede a um agente de IA para configurar a busca vetorial no ambiente serverless NextGen.

Por que a skill é importante

O OpenSearch é agora a stack padrão para empresas que precisam de texto pesquisável, análise de logs e, cada vez mais, busca de similaridade baseada em vetores. Configurar um cluster exige dezenas de decisões interconectadas: políticas de criptografia, isolamento de rede, funções de acesso a dados, dimensionamento de instâncias, alocação de shards e, para cargas de trabalho vetoriais, a escolha do mecanismo k-NN. Erre um passo e você acabará com um superprovisionamento dispendioso ou um pipeline de busca quebrado.

A nova skill promete um agente de IA que traduz instruções em linguagem natural na série exata de chamadas de API e arquivos de configuração necessários para uma implantação completa do OpenSearch.

O que a skill realmente é

Não é um chatbot com o qual você pode conversar. Pense nela como uma base de conhecimento estruturada que um agente de codificação automatizado pode consultar. O pacote inclui:

  • Fórmulas de dimensionamento que transformam o volume de consultas esperado e o tamanho dos dados em recomendações concretas de tipo de instância e nível de armazenamento.
  • Lógica de seleção de mecanismo que combina padrões de carga de trabalho (apenas texto, híbrido, vetor puro) com o mecanismo k-NN ou configuração de busca híbrida apropriada.
  • Checklists de migração que mapeiam esquemas do Solr ou Elasticsearch para equivalentes no OpenSearch.
  • Receitas de Query DSL que fornecem snippets prontos da Linguagem de Domínio Específico (DSL) do OpenSearch para padrões de busca comuns.

A skill gira em torno de cinco tarefas principais:

  1. Migração – conversão de esquemas existentes de Solr/ES.
  2. Provisionamento – cálculo de tamanhos de instância, níveis de armazenamento e políticas de rede.
  3. Busca – escolha de mecanismos k-NN, configurações de busca híbrida e ajuste de parâmetros de relevância.
  4. Análise de logs – manipulação de consultas Piped Processing Language (PPL) e definições de pipeline.
  5. Análise de rastreamento (trace) – configuração de coletores OpenTelemetry e pipelines do Data Prepper.

Onde ela brilha

Durante meu teste, a maior economia de tempo foi a lógica de sequenciamento de políticas. A skill conhece a ordem correta e me entrega um checklist passo a passo, o que reduziu drasticamente meu tempo de configuração.

Para domínios gerenciados clássicos, as recomendações da skill sobre upgrades de instância e matemática de shards correspondem à configuração real do cluster. Ela lê a contagem atual de nós, o uso de armazenamento e a latência de consulta, informando se você precisa de mais shards, instâncias maiores ou um nível de armazenamento diferente. Esse tipo de conselho baseado em contexto geralmente fica espalhado por várias documentações da AWS.

A skill também entende flags específicas do NextGen, como scale-to-zero, que instrui o serviço serverless a liberar recursos de computação quando a coleção estiver ociosa. Ao sinalizar isso corretamente, a ferramenta mantém os custos baixos sem ajustes manuais.

A lacuna evidente

O tratamento da skill para mapeamento vetorial no NextGen Serverless ainda está preso à lógica do Classic. Quando pedi ao agente para configurar uma coleção habilitada para vetores, ele sugeriu um mecanismo FAISS. No Classic Serverless, você pode escolher um mecanismo k-NN, mas o NextGen abstrai isso — a aceleração vetorial é gerenciada automaticamente e você não pode especificar o mecanismo de forma alguma. Portanto, a recomendação falha completamente.

Uma segunda imprecisão, menos dramática, envolveu as expectativas de latência de gravação. O assistente alertou sobre atrasos de gravação de 30 a 60 segundos, um número que se aplicava a implantações mais antigas do Classic Serverless. No meu teste com NextGen, os documentos tornaram-se pesquisáveis em cerca de dois segundos, tornando o aviso obsoleto.

Esses erros importam porque muitas equipes adotam o NextGen justamente por seu modelo operacional simplificado. Se o assistente de IA aplicar configurações da era Classic em um cluster NextGen, isso pode causar falhas de implantação ou ciclos de depuração desnecessários.

Quem deve (e quem não deve) usá-la

Se você costuma subir clusters OpenSearch — seja para busca de texto completo, agregação de logs ou cargas de trabalho híbridas — a skill é uma rede de segurança sólida. Ela detecta falhas comuns, como:

  • Esquecer de anexar políticas de criptografia antes da criação da coleção.
  • Provisionar acidentalmente uma coleção Classic quando uma NextGen seria mais barata e fácil de gerenciar.
  • Selecionar um tamanho de instância que não consiga sustentar grandes cargas de trabalho vetoriais.

Para equipes cuja necessidade principal é busca vetorial pura, a skill oferece pouca vantagem. O serviço S3 Vectors da Amazon oferece um caminho mais rápido e barato para pipelines de RAG simples, e não exige as etapas complexas de provisionamento com as quais a skill ajuda.

O que observar a seguir

A skill já é útil, mas sua próxima iteração precisa de duas atualizações:

  1. Lógica vetorial consciente do NextGen – o assistente deve reconhecer que a seleção de engine é desnecessária e, em vez disso, guiar o usuário pelos parâmetros que realmente afetam o desempenho vetorial no modelo serverless (ex: limites de dimensão, tamanho do lote).
  2. Benchmarks de latência atuais – a base de conhecimento deve ser atualizada com os números mais recentes de latência de escrita tanto para Classic quanto para NextGen, para que os usuários tenham expectativas realistas.

Enquanto isso, trate a skill como um guia, não um substituto para um engenheiro de OpenSearch experiente.

Conclusão

A skill amazon-opensearch-service reduz a curva de aprendizado para configurações complexas do OpenSearch e ajuda a evitar erros de política dispendiosos. Suas limitações restringem-se aos recursos vetoriais serverless mais recentes, o que significa que ela continua sendo um assistente valioso para a maioria das cargas de trabalho — desde que você verifique qualquer conselho relacionado a vetores com a documentação mais recente do NextGen.