IA em Foco

Tag: rag

  • Como Tornar Imagens de PDFs Pesquisáveis para RAG Sem Gastar com Todas Elas

    Como Tornar Imagens de PDFs Pesquisáveis para RAG Sem Gastar com Todas Elas

    Este artigo de Kezhan Shi, publicado no Towards Data Science, apresenta uma abordagem inteligente para tornar imagens de PDFs pesquisáveis em sistemas RAG — sem gastar dinheiro lendo todas elas.

    A série “Enterprise Document Intelligence” constrói um sistema RAG empresarial a partir de quatro blocos fundamentais. Neste quinto volume, o foco está em processar imagens de documentos de forma econômica, usando uma cascata ordenada por custo: um filtro barato, uma verificação de tipo, OCR clássico e, por último, um modelo de visão.

    O problema: nem toda imagem vale a pena

    O reflexo natural seria jogar um modelo de visão em cada imagem do PDF e seguir em frente. Mas essa é a abordagem errada. Um documento real está cheio de imagens que ninguém pesquisaria: o logotipo da empresa em cada página, ícones minúsculos, linhas divisórias, marcas d’água. Processar tudo com modelos caros é desperdício de dinheiro e de latência.

    A cascata de custo

    A solução proposta funciona em três etapas, da mais barata para a mais cara:

    1. Filtro gratuito: eliminar o ruído

    Antes de qualquer chamada de modelo, um filtro analisa sinais já disponíveis no dataframe de imagens e algumas estatísticas de pixel:

    • Tamanho mínimo: imagens com poucos pixels ou área muito pequena são ícones ou bullets, não figuras. Removidas.
    • Proporção suspeita: imagens muito longas e finas são linhas ou divisores. Fora.
    • Repetição entre páginas: o mesmo hash de conteúdo aparecendo na maioria das páginas é “chrome” — logotipo, cabeçalho, rodapé. Descartado.

    Em um relatório típico, só essa etapa remove a grande maioria das imagens antes de qualquer modelo rodar. O que sobra são as poucas que realmente carregam significado.

    2. Classificação por tipo

    As imagens que sobrevivem ao filtro não são todas lidas da mesma forma. Uma captura de tela de tabela é texto — OCR clássico resolve. Um gráfico de linhas não é texto — seu significado está nos eixos e na forma visual.

    A classificação usa sinais baratos de pixel: variação, saturação, proporção de fundo branco, densidade de bordas:

    • Painel em branco: dispersão de pixel baixa → pular (sem custo)
    • Imagem de texto: baixa saturação, estrutura de traços, fundo branco → OCR clássico (barato)
    • Imagem visual: saturada, sem margens brancas → modelo de visão (caro)

    O classificador é deliberadamente conservador: na dúvida, manda para o modelo de visão. Um OCR perdido custa uma chamada de visão; um OCR executado em um diagrama retorna labels soltos e lixo.

    3. Ação por tipo

    Tipo de imagem Ação Custo
    Muito pequena / formato estranho / repetida Descartar Zero
    Painel em branco / uniforme Pular Zero
    Imagem de texto (tabela, scan) OCR clássico Baixo
    Imagem visual (gráfico, foto) Modelo de visão Alto

    A escolha de design mais importante

    O artigo destaca dois princípios fundamentais:

    1. Logotipos são pegos pelo filtro de repetição, não pelo classificador: um logotipo pode ter duas cores chapadas ou ser uma marca d’água colorida. Tentar detectar logo por aparência é frágil. Mas um logo é “chrome” porque se repete em todas as páginas — e isso o filtro já captura.

    2. O classificador não tenta ser inteligente demais: classificar gráfico vs. diagrama vs. foto com sinais baratos não é confiável. Então o classificador só desvia imagens para OCR quando tem certeza absoluta de que é texto. Todo o resto vai para o modelo de visão. O viés é assimétrico de propósito.

    Por que isso importa

    Para quem constrói sistemas RAG empresariais, este artigo oferece um roteiro prático para processar documentos PDF sem desperdício. A lógica da cascata — começar pelo método mais barato e só escalar quando necessário — é um padrão que vale para muito além de processamento de documentos.

    O artigo completo, com implementações em Python e exemplos de código, está disponível no Towards Data Science.

  • Liquid AI lança LFM2.5-Embedding e ColBERT-350M: novos modelos de busca multilíngue em 11 idiomas

    Liquid AI lança LFM2.5-Embedding e ColBERT-350M: novos modelos de busca multilíngue em 11 idiomas

    A Liquid AI — startup fundada por ex-pesquisadores do MIT e conhecida por sua arquitetura alternativa aos transformers — acaba de lançar dois novos modelos de embedding que prometem busca multilíngue ultrarrápida em 11 idiomas, incluindo o português.

    Dois modelos, um backbone

    Os LFM2.5-Embedding-350M e LFM2.5-ColBERT-350M compartilham o mesmo backbone de 350 milhões de parâmetros, baseado na arquitetura LFM2.5 da Liquid AI. A diferença está na forma como representam o texto:

    • Embedding (Bi-Encoder Denso): Converte cada documento em um único vetor de 1024 dimensões. Ideal para busca rápida com o menor índice possível. Escolha quando velocidade e custo de armazenamento são prioridade.

    • ColBERT (Late-Interaction): Converte cada token em um vetor de 128 dimensões, permitindo comparação palavra por palavra entre consulta e documento. Oferece precisão superior e melhor generalização, com o trade-off de um índice maior. Também pode ser usado como reranker.

    Ambos os modelos são voltados para busca de contexto curto, como catálogos de produtos, bases de conhecimento FAQ e documentação de suporte — um encaixe natural para pipelines RAG (Retrieval-Augmented Generation).

    Arquitetura bidirecional adaptada

    O ponto de partida é o checkpoint LFM2.5-350M-Base, um modelo de uso geral que a Liquid AI adaptou com patches bidirecionais. Originalmente, a arquitetura LFM2 é causal (cada token olha apenas para o passado), o que funciona para geração de texto, mas não é ideal para recuperação de informação.

    A equipe substituiu a máscara de atenção causal por uma bidirecional, permitindo que cada token atenda ao contexto tanto à esquerda quanto à direita. As convoluções curtas também foram tornadas não-causais, misturando informações locais simetricamente ao redor de cada token.

    O resultado: 17 camadas (10 de convolução, 6 de atenção e 1 de pooling/densa), contexto de até 32.768 tokens e documentos afinados para 512 tokens — preservando a eficiência do backbone LFM2 enquanto produz as representações de contexto completo que a recuperação exige.

    Resultados em 11 idiomas

    Os modelos foram avaliados em dois benchmarks:

    • NanoBEIR: recuperação multilíngue
    • MKQA-11: QA cross-lingual de domínio aberto

    Ambos cobrem 11 idiomas: árabe, alemão, inglês, espanhol, francês, italiano, japonês, coreano, norueguês, português e sueco.

    O ColBERT lidera em ambas as médias, com 0,605 no NanoBEIR (melhoria significativa sobre os 0,540 do LFM2-ColBERT-350M anterior). O Embedding chega perto no MKQA-11, com 0,691. Ambos superam o Qwen3-Embedding-0.6B, um modelo maior.

    Latência e deploy

    A Liquid AI disponibilizou variantes GGUF para llama.cpp, permitindo execução em CPUs, laptops e dispositivos edge. Em uma MacBook Pro M4 Max (FP16), a latência mediana de consulta fica abaixo de 10 ms para embeddings pré-computados. Em GPUs H100 (FP16), as latências chegam a 1 ms.

    Para uso via Python, o Embedding roda com sentence-transformers e o ColBERT com PyLate, incluindo índice PLAID com FastPLAID para busca eficiente de similaridade. Ambos suportam fine-tuning com dados próprios.

    Disponibilidade

    Os modelos estão disponíveis no Hugging Face sob os identificadores LiquidAI/LFM2.5-Embedding-350M e LiquidAI/LFM2.5-ColBERT-350M. A Liquid AI recomenda o Embedding para pipelines RAG que priorizam custo e velocidade, e o ColBERT quando a precisão é o fator decisivo — especialmente em cenários cross-lingual onde a interação tardia captura nuances que embeddings densos podem perder.

  • Projeto Amazing Digital Dentures: os desafios de criar aventuras digitais com IA

    Projeto Amazing Digital Dentures: os desafios de criar aventuras digitais com IA

    Inspiração e objetivo inicial do projeto

    O projeto Amazing Digital Dentures foi inspirado na série animada The Amazing Digital Circus, que apresenta uma prótese dentária digital chamada Caine, vivendo em um circo virtual junto a clones digitais de humanos reais. A ideia central era criar um pet digital que enviasse o usuário em aventuras diárias, funcionando como uma espécie de lista de tarefas gamificada, capaz de potencializar a produtividade do mundo real.

    Desenvolvimento e principais dificuldades técnicas

    O idealizador utilizou o modelo Nemotron 30b para tentar gerar jogos completos em three.js, uma biblioteca JavaScript para gráficos 3D. Inicialmente, o projeto contou com prompts longos que explicavam detalhadamente o que o modelo deveria criar. No entanto, os resultados foram insatisfatórios, com jogos que não funcionavam corretamente.

    Em uma tentativa de melhorar, foram adicionados skill cards — habilidades pré-definidas para o motor de jogos, conforme documentação disponível em GitHub – Skills Game Engine. Essa abordagem, porém, sobrecarregou a janela de contexto do modelo, causando falhas.

    Mesmo ampliando a janela de contexto para suportar mais informações, os problemas persistiram. Para contornar, o desenvolvedor usou o Codex para condensar as habilidades em um único arquivo de texto e aplicou uma técnica chamada RAG (Retrieval-Augmented Generation) para consulta ao conteúdo, o que melhorou os resultados, mas ainda não foi suficiente para entregar jogos funcionais. Frequentemente, o resultado final eram telas em branco.

    Estado atual e funcionalidades disponíveis

    Diante dos obstáculos, o projeto foi pivotado para uma ferramenta mais simples, um HTML toymaker capaz de criar elementos básicos em uma única geração, como relógios, listas de tarefas, e jogos simples como snake e breakout. Tentativas de criar jogos mais complexos, como tetris, resultaram em falhas.

    O projeto está disponível para testes no Hugging Face Spaces: AmazingDigitalPetDentures.

    Reflexões e próximos passos

    O criador do projeto demonstrou interesse em explorar novas ideias e está aberto a sugestões para futuros rumos. A experiência evidencia as limitações atuais dos modelos de linguagem em gerar jogos complexos e interativos, especialmente quando combinados com bibliotecas gráficas como three.js. Também destaca a importância do ajuste fino do contexto e da integração de múltiplas ferramentas para alcançar resultados práticos.

    Links úteis

  • Plataforma Gemini Enterprise Agent e Agentic RAG: Avanços em Respostas Confiáveis para Consultas Empresariais Complexas

    Plataforma Gemini Enterprise Agent e Agentic RAG: Avanços em Respostas Confiáveis para Consultas Empresariais Complexas

    Desafio das Respostas Confiáveis em Ambientes Empresariais Multidados

    Os sistemas tradicionais de retrieval-augmented generation (RAG) enfrentam limitações ao lidar com consultas complexas que exigem múltiplas buscas em diferentes bases de dados. Por exemplo, uma pergunta sobre as especificações do servidor usado em um projeto pode retornar apenas um ID de servidor sem detalhar suas características, devido à fragmentação da informação em “ilhas” de dados. Isso gera respostas parciais ou negativas, comprometendo a confiabilidade.

    Agentic RAG: Uma Abordagem Multiagente Iterativa

    O Google Research, em colaboração com o Google Cloud, desenvolveu o Agentic RAG, um framework multiagente que supera as limitações dos modelos RAG convencionais. O sistema divide a consulta complexa em múltiplas etapas, planejando e executando buscas iterativas para garantir que o contexto coletado seja suficiente para uma resposta precisa.

    Arquitetura Multiagente e Fluxo de Trabalho

    • Orchestrator: Avalia a complexidade da consulta e delega tarefas aos agentes especializados.
    • Planner Agent: Mapeia os caminhos da informação, definindo a ordem das buscas, como consultar primeiro o banco financeiro e depois o de gestão de projetos.
    • Query Rewriter: Reescreve a consulta original em múltiplas perguntas específicas e otimizadas para busca.
    • Search Fanout Agent: Executa as buscas nos diferentes repositórios, coletando trechos relevantes.
    • Large Language Model (LLM): Consolida os dados recuperados para gerar a resposta final.

    Diferenciais do Agentic RAG: Persistência e Controle de Qualidade

    O grande diferencial do Agentic RAG é a presença do Sufficient Context Agent, um agente que atua como um inspetor de qualidade. Ele avalia se os trechos recuperados e o rascunho da resposta contêm todas as informações necessárias. Caso detecte lacunas, o agente especifica exatamente o que falta e orienta novas buscas, evitando respostas incompletas ou meramente negativas.

    Exemplo Prático: Consulta Médica Complexa

    Imagine um médico consultando sobre as medicações, restrições alimentares e reações alérgicas de um paciente após uma cirurgia, com critérios específicos para exclusões. O Agentic RAG segmenta a consulta, busca em bases distintas (farmácia, nutrição, notas clínicas), verifica se os dados estão completos e, se faltar informação, realiza buscas adicionais até garantir uma resposta fundamentada e confiável.

    Resultados de Benchmark e Avaliação

    O sistema foi testado no conjunto FramesQA, que exige múltiplos passos para responder perguntas, como comparar durações de episódios de séries populares. O Agentic RAG obteve até 34% mais precisão em datasets de factualidade, superando o RAG convencional. Em cenários com múltiplos corpora (bases de dados distintas), o sistema manteve alta acurácia (90,1%) e latência semelhante ao cenário de corpus único, demonstrando capacidade robusta de raciocínio e roteamento entre fontes heterogêneas.

    Limitações e Perspectivas Futuras

    Embora o Agentic RAG aumente a confiabilidade das respostas, a complexidade do sistema implica maior custo computacional e necessidade de ajuste fino para diferentes domínios. A pesquisa abre caminho para sistemas de IA mais auditáveis, rastreáveis e fundamentados, com potencial para transformar fluxos de trabalho empresariais e clínicos.

    Disponibilidade e Recursos

    O Agentic RAG está disponível em pré-visualização pública na Gemini Enterprise Agent Platform. Documentações técnicas detalhadas sobre o RAG Engine Cross Corpus Retrieval e o motor RAG podem ser consultadas para implementação e testes. Para desenvolvedores interessados, o repositório do Google Research está disponível em GitHub. Além disso, o Google Labs oferece experimentos interativos com IA em labs.google.

    Links úteis

  • Como Orquestrar Pipelines de IA Agentiva e Multimodal com Apache Camel

    Desafios na Engenharia de Sistemas de IA Agentiva e Multimodal

    Com a crescente adoção da inteligência artificial, sistemas modernos ultrapassam a simples chamada a modelos, evoluindo para fluxos de trabalho que combinam raciocínio, recuperação de informação e ações sequenciadas. A IA agentiva refere-se a sistemas onde o modelo atua como um agente de raciocínio, decidindo quais ferramentas usar e em que ordem executar tarefas. Já a IA multimodal permite trabalhar com diferentes tipos de entrada, como texto, imagens e dados estruturados, dentro do mesmo pipeline.

    Apesar da sofisticação desses sistemas, a maior dificuldade está na engenharia da solução como um todo, não na qualidade dos modelos. Estudos recentes mostram que a maior parte das falhas em projetos de IA corporativos decorrem da má integração e gestão dos componentes, e não da capacidade dos modelos em si.

    Apache Camel e LangChain4j: Uma Arquitetura para Sistemas de IA Robustos

    O artigo de Vignesh Durai, publicado no InfoQ, apresenta uma abordagem para desenvolver sistemas agentivos e multimodais usando Apache Camel como camada de orquestração e LangChain4j como runtime para o agente. Essa arquitetura promove a separação clara entre o raciocínio (feito pelo modelo de linguagem) e a execução (gerenciada pelo Camel), trazendo benefícios importantes para a confiabilidade e governança do sistema.

    Enquanto frameworks tradicionais de agentes integram raciocínio e controle de execução, dificultando o tratamento de erros e a escalabilidade, Apache Camel oferece padrões empresariais consolidados, como circuit breakers, validação de payloads e roteamento determinístico, facilitando monitoramento e manutenção.

    Principais Componentes da Solução

    • Raciocínio baseado em LLM: o modelo de linguagem grande (LLM) atua como o cérebro do agente, decidindo qual ferramenta ou modelo utilizar em cada passo.
    • Geração aumentada por recuperação (RAG): o sistema consulta bases de dados vetoriais para buscar informações relevantes que enriquecem o raciocínio do agente.
    • Classificação de imagens: modelos dedicados, como ResNet50 via TensorFlow Serving, analisam imagens anexadas, extraindo sinais úteis para a tomada de decisão.
    • Orquestração determinística: Apache Camel controla a sequência das ações, isolando falhas e garantindo resultados auditáveis e previsíveis.

    Estudo de Caso: Sistema de Triagem de Tickets de Suporte

    Como exemplo prático, o artigo detalha um sistema de triagem automática para tickets de suporte ao cliente que processa dados textuais, metadados e imagens anexadas. O objetivo é classificar o ticket em categorias e níveis de prioridade, recomendar equipes para atendimento, sugerir ações e fornecer citações de documentação interna.

    Esse sistema não é um chatbot, mas um pipeline não conversacional, garantindo que as decisões sejam estruturadas, auditáveis e integráveis a outros sistemas corporativos. A arquitetura multimodal permite que o agente selecione quais modelos e ferramentas usar para cada ticket, proporcionando flexibilidade e robustez.

    Fluxo de Controle e Integração

    Apache Camel gerencia as rotas principais do pipeline, coordenando as chamadas ao agente LangChain4j, consultas à base vetorial (exemplo: Qdrant), invocação do modelo de visão computacional e comunicação com provedores de LLM compatíveis com o padrão OpenAI.

    Essa separação entre raciocínio e execução permite que o sistema trate falhas parciais sem comprometer o fluxo completo, além de facilitar a auditoria e o monitoramento em ambiente corporativo.

    Implicações Práticas para Empresas e Engenheiros de IA

    O artigo aponta que, para que projetos de IA avancem além das provas de conceito e entreguem valor real, é fundamental adotar uma visão sistêmica e não apenas centrada no modelo. Apache Camel, apesar de ser uma ferramenta Java, oferece um conjunto robusto de padrões de integração que elevam a maturidade operacional dos pipelines de IA.

    Esse modelo é particularmente adequado para organizações que já contam com infraestrutura Java e buscam confiabilidade, governança e escalabilidade em suas soluções de IA multimodal e agentiva.

    Links úteis

  • AutoAdapt: A Revolução Automatizada na Adaptação de Grandes Modelos de Linguagem para Domínios Específicos

    O desafio da adaptação de grandes modelos de linguagem em ambientes críticos

    O uso de grandes modelos de linguagem (LLMs) em cenários reais e de alta complexidade, como nas áreas jurídica, médica e na resposta a incidentes em nuvem, ainda enfrenta barreiras significativas. A principal delas é a adaptação do modelo para requisitos específicos de domínio, que costuma ser um processo manual, lento, caro e difícil de reproduzir, comprometendo desempenho e confiabilidade.

    Como o AutoAdapt transforma a adaptação de domínio

    Para superar essas dificuldades, pesquisadores da Microsoft Research desenvolveram o AutoAdapt, um framework automatizado e consciente das restri̵̤es reais de implanta̤̣o. Ele planeja, seleciona estrat̩gias (como gera̤̣o aumentada por recupera̤̣o РRAG Рou fine-tuning) e realiza o ajuste fino dos hiperpar̢metros, tudo dentro de limites definidos de lat̻ncia, privacidade, hardware e or̤amento.

    Arquitetura e funcionamento do AutoAdapt

    • Adaptation Configuration Graph (ACG): uma representação estruturada do espaço de configurações possíveis, que mapeia todo o processo de adaptação garantindo a validade das combinações e facilitando a busca eficiente por soluções.
    • Agente planejador: responsável por selecionar e ordenar as etapas da adaptação, avaliando as estratégias propostas com base nos requisitos do usuário e iterando até encontrar um plano viável.
    • AutoRefine: um loop de otimização consciente do orçamento que realiza a afinação dos hiperparâmetros, escolhendo experimentos estratégicos para maximizar resultados mesmo com feedback limitado, substituindo semanas de ajustes manuais por um processo disciplinado e auditável.

    Resultados e avaliação prática

    Testado em diversas tarefas, como raciocínio, perguntas e respostas, codificação, classificação e diagnóstico de incidentes em nuvem, o AutoAdapt mostrou-se capaz de identificar estratégias eficazes de adaptação. Ele superou métodos baselines de última geração, alcançando maior taxa de sucesso e desempenho normalizado com um custo e tempo adicionais mínimos — cerca de 30 minutos e 4 dólares, respectivamente.

    Implicações para o uso real de LLMs

    O impacto do AutoAdapt vai além da simples melhoria técnica: ele transforma a adaptação de domínio em uma disciplina de engenharia, com processos explícitos, reprodutíveis e auditáveis. Isso é crucial em setores onde a deriva do conhecimento pré-treinado pode causar falhas críticas, como na elaboração de notas clínicas, triagem de incidentes ou interpretação de normativas regulatórias.

    Ao automatizar e acelerar a criação de modelos prontos para domínios específicos, o AutoAdapt torna os LLMs mais confiáveis e viáveis para aplicações reais sujeitas a restrições de latência, privacidade e orçamento.

    Recursos e acesso ao AutoAdapt

    O framework AutoAdapt está disponível como código aberto, oferecendo um ponto de partida concreto para equipes que desejam implementar adaptação de domínio automatizada. O repositório no GitHub inclui um arquivo README com instruções de instalação e início rápido:

    Por que acompanhar essa evolução?

    Com o avanço do AutoAdapt, equipes de desenvolvimento e operações podem reduzir drasticamente o tempo e o custo para adaptar LLMs a contextos específicos, com garantia de resultados reprodutíveis e auditáveis. Essa inovação é um passo fundamental para que modelos de linguagem sejam efetivamente usados em ambientes de missão crítica, onde a precisão e a confiabilidade são inegociáveis.

    Para saber mais, acompanhe as publicações da Microsoft Research e participe da discussão sobre os desafios da inteligência artificial em ambientes reais.

  • Protocol-H e a Revolução dos Sistemas RAG Hierárquicos para Análises Empresariais Complexas

    O avanço das soluções de Retrieval-Augmented Generation (RAG) tem sido um marco para análises que envolvem dados estruturados e não estruturados. No entanto, sistemas tradicionais apresentam limitações significativas ao lidar simultaneamente com bases SQL e coleções documentais, fenômeno conhecido como modalidade gap. O artigo do InfoQ AI/ML, escrito por Abhijit Ubale, detalha como a arquitetura hierárquica de agentes em sistemas RAG pode resolver esses desafios, utilizando como exemplo a implementação open source Protocol-H.

    O desafio do modality gap em ambientes corporativos

    Empresas enfrentam a necessidade de cruzar dados quantitativos estruturados (exemplos: tabelas de receita, margens, segmentos de clientes) com informações qualitativas extraídas de documentos (relatórios de mercado, análises competitivas, documentos regulatórios). Sistemas RAG tradicionais costumam tratar essas fontes de forma isolada, ou executando consultas SQL ou buscando documentos, o que gera respostas incompletas, imprecisas ou até alucinações — respostas geradas pelo modelo com informações incorretas ou não verificadas.

    Imagem relacionada ao artigo de InfoQ AI/ML
    Imagem de apoio da materia original.

    Por exemplo, um analista financeiro que pergunta “Por que as operações europeias estão com desempenho inferior?” pode receber dados quantitativos sem o contexto regulatório ou relatórios mercadológicos sem validação numérica. Essa lacuna exige intervenções manuais que comprometem a eficiência e a confiabilidade das análises.

    Arquitetura hierárquica e agentes especializados: o modelo Protocol-H

    O Protocol-H propõe uma arquitetura baseada em uma topologia supervisor-trabalhador, inspirada em hierarquias organizacionais humanas. Nessa estrutura, um agente supervisor atua como orquestrador, decompondo consultas complexas em tarefas específicas para agentes especializados — trabalhadores SQL para dados estruturados e agentes de busca vetorial para documentos.

    O supervisor:

    • Analisa a consulta para identificar quais modalidades de dados são necessárias;
    • Divide o problema em sub-tarefas atômicas (exemplo: encontrar clientes em determinada região, buscar tickets de suporte relacionados, correlacionar dados de churn);
    • Roteia cada sub-tarefa para o agente especializado adequado;
    • Combina os resultados parciais em uma resposta final coerente;
    • Gerencia erros por meio de mecanismos de reflective retry, que detectam e corrigem falhas antes da geração da resposta final.

    Agente SQL: consulta estruturada com consciência de esquema

    O agente SQL é projetado para executar consultas determinísticas e validadas contra bancos de dados empresariais (Snowflake, Redshift, BigQuery, etc.). Ele realiza:

    • Introspecção automática do esquema, identificando tabelas, colunas e relacionamentos, seja por chaves estrangeiras explícitas ou inferência heurística baseada em nomes de colunas;
    • Validação pré-execução para evitar erros de sintaxe e consultas mal formuladas;
    • Execução de consultas parametrizadas para evitar injeção de SQL e garantir segurança;
    • Mecanismos de retry reflexivo para corrigir erros como sintaxe inválida ou relacionamentos incorretos antes que esses erros se propaguem;
    • Respeito à segurança e controle de acesso, executando consultas com credenciais do usuário autenticado.

    Agente de busca vetorial: raciocínio semântico sobre documentos

    Paralelamente, o agente de busca vetorial realiza a recuperação semântica em coleções documentais, utilizando representações vetoriais para identificar conteúdos relevantes mesmo quando não há correspondência textual direta. Esse agente fornece insights qualitativos complementares aos dados estruturados.

    Benefícios práticos da orquestração hierárquica

    Em testes internos com o benchmark EntQA, a arquitetura hierárquica alcançou 84,5% de acurácia em consultas multi-hop, superando abordagens com agentes planos que atingiram 62,8%. Além disso, o uso do mecanismo de retry reflexivo reduziu em 60% as taxas de alucinação, aumentando a confiabilidade das respostas.

    Outro ponto crucial é a portabilidade: a arquitetura utiliza adaptadores no padrão Adapter para abstrair a comunicação com diferentes bancos de dados, garantindo que a lógica de orquestração funcione de forma transparente em Snowflake, Redshift, BigQuery e outros.

    O controle determinístico do fluxo, com gestão explícita de estado e consciência do esquema, viabiliza a implantação em ambientes corporativos que exigem auditoria, compliance e rastreabilidade.

    Impacto para o mercado e estratégias corporativas

    Para equipes de AI corporativas, Protocol-H representa um avanço na integração de múltiplas fontes de dados heterogêneas, mitigando riscos de respostas erradas e aumentando a transparência. Isso possibilita análises mais completas e confiáveis, essenciais para decisões de negócios estratégicas.

    O modelo hierárquico facilita a especialização dos agentes, simplifica a manutenção e permite escalabilidade, alinhando-se a demandas crescentes por soluções robustas e auditáveis em setores regulados, como finanças e saúde.

    Empresas que investem em AI podem adotar ou adaptar essa arquitetura para acelerar a maturidade de suas plataformas analíticas, reduzindo o custo de integração e aumentando a confiança nas respostas geradas.

    Links úteis para aprofundamento e experimentação

  • Amazon Bedrock e OpenSearch lançam busca inteligente híbrida com IA generativa para soluções RAG

    Amazon Bedrock e OpenSearch: inovação em busca híbrida para assistentes com IA generativa

    A Amazon Web Services (AWS) apresentou uma solução inovadora que combina Amazon Bedrock, Amazon Bedrock AgentCore, Strands Agents e Amazon OpenSearch para criar assistentes inteligentes baseados em IA generativa capazes de realizar buscas híbridas. Essa tecnologia é voltada para empresas que buscam respostas precisas e contextuais, integrando buscas semânticas e textuais em tempo real, ampliando as possibilidades das soluções Retrieval-Augmented Generation (RAG).

    O que é a busca híbrida e qual o diferencial da solução?

    Tradicionalmente, buscas baseadas em IA generativa utilizam modelos de linguagem para interpretar consultas e gerar respostas. Porém, apenas a busca semântica pode falhar quando é necessário combinar entendimento conceitual com filtros precisos, como localização ou datas. Por exemplo, ao buscar um “hotel de luxo com vista para o mar em Miami”, a busca semântica pode retornar hotéis em outras localidades costeiras, pois prioriza o significado conceitual em vez de atributos exatos.

    A solução híbrida apresentada pela AWS une:

    • Busca semântica via vetores de embeddings que capturam o significado do texto;
    • Busca textual com filtros rigorosos para atributos estruturados, como cidade, país e datas.

    Assim, o sistema consegue entregar resultados que são simultaneamente semanticamente relevantes e rigorosamente filtrados conforme os critérios do usuário.

    Como funciona a arquitetura da solução?

    A arquitetura é baseada em uma estrutura serverless que integra os seguintes componentes:

    • Amazon API Gateway: ponto de entrada seguro e escalável para as requisições dos usuários.
    • Amazon Bedrock AgentCore: orquestra o ciclo de raciocínio, ação e observação do agente, analisando as consultas, decidindo quais ferramentas usar, executando buscas híbridas e gerando respostas.
    • Amazon OpenSearch Serverless: armazena vetores de embeddings para busca semântica e campos estruturados para filtros textuais, executando consultas híbridas.
    • Strands Agents: framework open-source que facilita a criação e integração de ferramentas, como a função de busca híbrida, que o agente invoca dinamicamente conforme a consulta.

    Essa combinação permite respostas rápidas, escalabilidade automática, custo sob demanda e segurança integrada, com monitoramento via Amazon CloudWatch e controle de acesso pelo AWS IAM.

    Quem pode utilizar e como acessar?

    Empresas e desenvolvedores que desejam construir assistentes conversacionais avançados com IA generativa podem se beneficiar dessa solução. É especialmente indicado para setores que demandam consultas complexas a bases de dados dinâmicas, como turismo, e-commerce, atendimento ao cliente e business intelligence.

    Para começar, é necessário criar uma conta AWS (link para criação de conta). A integração com Amazon Bedrock AgentCore e Strands permite o desenvolvimento e implantação segura dos agentes. A documentação oficial e os tutoriais estão disponíveis para facilitar o uso:

    Aspectos práticos e impacto para o usuário final

    O agente generativo inteligente adapta sua estratégia de busca conforme a consulta do usuário, seja privilegiando buscas conceituais, filtros exatos ou ambos. Por exemplo, ele pode encontrar hotéis “aconchegantes” com base em descrições semânticas ou localizar hotéis em uma cidade específica com filtros rigorosos, tudo em tempo real.

    Essa flexibilidade supera limitações das implementações RAG tradicionais, que possuem fluxos fixos e não se adaptam dinamicamente às necessidades variáveis dos usuários. O resultado é uma experiência mais natural, precisa e eficiente, que pode ser aplicada em múltiplos cenários empresariais.

    Como funciona o desenvolvimento da busca híbrida com Strands e Bedrock AgentCore

    O código da ferramenta de busca híbrida é definido como uma função que gera embeddings para a busca semântica e aplica filtros textuais para localização, integrando-se ao agente via Strands. Exemplo simplificado da função em Python:

    from strands import tool

@tool
def hybrid_search(query_text: str, country: str = None, city: str = None):
    """Realiza busca híbrida combinando entendimento semântico e filtros de localização."""
    vector = generate_embeddings(query_text)
    query = {
        "bool": {
            "must": [{"knn": {"embedding_field": {"vector": vector, "k": 10}}}],
            "filter": []
        }
    }
    if country:
        query["bool"]["filter"].append({"term": {"country": country}})
    if city:
        query["bool"]["filter"].append({"term": {"city": city}})
    response = opensearch_client.search(index="hotels", body=query)
    return format_results(response)

    Essa função é orquestrada pelo Amazon Bedrock AgentCore, que decide quando e como utilizá-la conforme a consulta do usuário, garantindo respostas contextuais e precisas.

    Links úteis para aprofundamento e acesso

  • Como a Ring escalou o suporte global com Amazon Bedrock Knowledge Bases

    Desafios do suporte ao cliente na expansão internacional da Ring

    A Ring, subsidiária da Amazon especializada em segurança residencial, enfrentava limitações significativas em seu sistema de atendimento ao cliente ao expandir suas operações para múltiplos países. Inicialmente, o suporte era baseado em um chatbot rule-based desenvolvido com Amazon Lex, que apresentava restrições na variedade de interações e demandava manutenção constante. Durante picos de atendimento, 16% das conversas precisavam ser encaminhadas a agentes humanos, e os engenheiros dedicavam cerca de 10% do tempo à manutenção do sistema.

    Com a internacionalização, a Ring precisava de uma solução capaz de fornecer suporte contextualizado e preciso para diferentes regiões, considerando não apenas a tradução, mas também informações específicas de cada mercado, como normas e configurações técnicas.

    Requisitos para um sistema de suporte baseado em RAG

    • Localização global de conteúdo: Atendimento com informações regionais específicas, como voltagem e regulamentações, para 10 países, incluindo Reino Unido e Alemanha.
    • Arquitetura serverless gerenciada: Foco da equipe em experiência do cliente, evitando a gestão direta de infraestrutura.
    • Gerenciamento escalável de conhecimento: Utilização de tecnologia de busca vetorial para recuperação precisa em um repositório unificado, com pipelines automatizados para ingestão de conteúdo.
    • Otimização de desempenho e custos: Latência média de resposta entre 7 e 8 segundos, com arquitetura centralizada para reduzir complexidade e despesas, eliminando a necessidade de infraestrutura por região.

    Implementação técnica: arquitetura e workflows da Ring

    A Ring adotou uma arquitetura baseada em Retrieval-Augmented Generation (RAG) utilizando Amazon Bedrock Knowledge Bases, AWS Lambda, AWS Step Functions e Amazon S3. A gestão do conteúdo foi dividida em dois fluxos principais:

    Fluxo de ingestão e avaliação

    1. Upload de conteúdo: A equipe de conteúdo da Ring envia documentos de suporte para um bucket Amazon S3, organizados com metadados que indicam a localidade (exemplo: “en-GB” para Reino Unido) e outras propriedades.
    2. Processamento automático: Eventos do S3 acionam funções Lambda que processam o conteúdo, separando dados brutos e extraindo metadados para armazenamento estruturado.
    3. Criação diária da base de conhecimento: Orquestrada por AWS Step Functions, que copia dados para buckets específicos, cria versões da base de conhecimento com indexação vetorial e mantém versões independentes para facilitar testes e rollback.
    4. Avaliação e validação: Consultas de teste avaliam a precisão e qualidade da recuperação, com métricas publicadas em dashboards Tableau. Modelos de linguagem da Anthropic Claude Sonnet 4 são usados para julgar e promover a melhor versão para produção.

    Fluxo de promoção e atendimento ao cliente

    Na interação com o cliente, o chatbot recebe a consulta, que é processada por uma função Lambda para aplicar filtros baseados em metadados regionais (contentLocale) e realizar buscas na base validada. O conteúdo mais relevante é combinado com a pergunta para formar um prompt enriquecido, enviado a modelos de linguagem no Amazon Bedrock para gerar respostas contextualizadas e locais.

    ## Exemplo de filtro para conteúdo regional em Lambda
num_results = 10
market = "en-GB"
knowledge_base_id = "A2BCDEFGHI"
user_text = "How can I replace the doorbell battery?"

vector_search_config = {"numberOfResults": num_results}
vector_search_config["filter"] = {
  "equals": {
    "key": "contentLocale",
    "value": market
  }
}

response = boto3.client("bedrock-agent-runtime").retrieve(
  knowledgeBaseId=knowledge_base_id,
  retrievalQuery={"text": user_text},
  retrievalConfiguration={
    "vectorSearchConfiguration": vector_search_config,
  },
)

    Benefícios e resultados alcançados

    Com essa arquitetura, a Ring eliminou a necessidade de implantar infraestrutura por região, reduzindo o custo de expansão para novos mercados em 21%. A experiência do cliente se manteve consistente em 10 localidades internacionais, com respostas rápidas e contextualizadas. A abordagem serverless permitiu escalabilidade automática e diminuiu o esforço operacional da equipe técnica.

    Considerações arquiteturais e operacionais para sistemas RAG em escala

    • Escolha da base vetorial: A Ring utiliza Amazon OpenSearch Serverless para busca vetorial, mas Amazon S3 Vectors é uma alternativa mais econômica para casos de uso com buscas mais simples.
    • Versionamento: A Ring optou por bases de conhecimento separadas para cada versão, facilitando rollback e avaliação, mas é possível usar múltiplas fontes de dados em uma única base, com trade-offs em complexidade e manutenção.
    • Recuperação de desastres: Para alta disponibilidade, recomenda-se implantar recursos em múltiplas regiões AWS, incluindo bases de conhecimento, buckets S3 e funções Lambda, mantendo a sincronização dos dados.
    • Escalabilidade do modelo base: Amazon Bedrock oferece cross-Region inference (CRIS) para distribuir a carga de inferência entre regiões, aumentando a capacidade sem alterar a arquitetura da base de conhecimento.
    • Modelos de embedding e chunking: A escolha adequada impacta diretamente a precisão das buscas e a qualidade das respostas geradas.

    Links úteis para aprofundamento

  • NVIDIA e Hugging Face lançam pipeline para criação rápida de modelos de embedding específicos de domínio

    A NVIDIA, em parceria com a Hugging Face, lançou uma solução inovadora que permite a criação de modelos de embedding específicos para domínios particulares em menos de um dia e com apenas uma GPU. Essa novidade é especialmente útil para empresas e desenvolvedores que precisam de sistemas de recuperação de informação (RAG) capazes de entender nuances específicas de seus dados, como contratos, logs industriais, fórmulas químicas proprietárias ou taxonomias internas.

    O que foi lançado e para quem serve

    O novo pipeline de fine-tuning de embeddings transforma um modelo genérico, como o Llama-Nemotron-Embed-1B-v2, em um modelo especializado que entende os detalhes do seu domínio. Isso é fundamental porque modelos genéricos, treinados para entender a internet como um todo, não capturam as sutilezas necessárias para tarefas específicas. A solução é ideal para equipes que desenvolvem sistemas de busca semântica, recuperação de documentos e aplicações que exigem alta precisão na compreensão contextual.

    Imagem relacionada ao artigo de HuggingFace
    Imagem de apoio da materia original.

    Como funciona o processo de fine-tuning

    1. Geração automática de dados de treinamento: Utilizando o NeMo Data Designer e um LLM da NVIDIA (nvidia/nemotron-3-nano-30b-a3b), o pipeline lê documentos do seu domínio e gera pares de pergunta-resposta sintéticos de alta qualidade, sem necessidade de rotulagem manual.
    2. Mineração de “hard negatives”: Para melhorar a capacidade do modelo em distinguir documentos muito semelhantes, o pipeline identifica passagens que parecem relevantes, mas não são a resposta correta, tornando o treinamento mais robusto.
    3. Incorporação de perguntas multi-hop: Perguntas que exigem a conexão de informações de múltiplos documentos são geradas para treinar o modelo a recuperar contextos mais complexos e relevantes.
    4. Fine-tuning com aprendizado contrastivo: O modelo é ajustado usando uma arquitetura biencoder e técnicas de aprendizado contrastivo, com hiperparâmetros otimizados para garantir qualidade e estabilidade no treinamento, mesmo com conjuntos de dados pequenos.
    5. Avaliação padronizada: O desempenho é medido com a framework BEIR, usando métricas como nDCG, Recall, Precision e MAP, garantindo melhorias significativas na recuperação.
    6. Exportação e implantação: O modelo final é convertido para ONNX e TensorRT para acelerar a inferência, e pode ser implantado via NVIDIA NIM, oferecendo uma API compatível com OpenAI para integração direta em pipelines existentes.

    Disponibilidade e requisitos técnicos

    Para utilizar o pipeline, é necessário ter:

    • Um diretório com documentos do seu domínio em formatos texto (.txt, .md, etc.)
    • Uma GPU NVIDIA Ampere ou superior com pelo menos 80GB de memória (testado em A100 e H100)
    • Uma chave API NVIDIA válida, que pode ser obtida gratuitamente em build.nvidia.com

    O pipeline e os conjuntos de dados sintéticos estão disponíveis como projetos open source no GitHub e integrados à Hugging Face, facilitando o acesso e a experimentação.

    Imagem relacionada ao artigo de HuggingFace
    Imagem de apoio da materia original.

    Impacto prático e resultados reais

    Empresas como a Atlassian já aplicaram essa receita para treinar modelos em seus dados públicos do Jira, obtendo um aumento de 26,7% no Recall@60 — ou seja, o modelo recupera documentos relevantes com muito mais precisão dentro dos primeiros 60 resultados. Isso representa uma melhora direta na experiência de milhões de usuários que dependem da busca eficiente em sistemas corporativos.

    Como começar: links úteis e documentação

    Em resumo, essa solução democratiza e acelera o desenvolvimento de modelos de embedding especializados, reduzindo o tempo, custo e complexidade técnica envolvidos. Com ela, organizações podem melhorar significativamente a qualidade de suas buscas e sistemas de recuperação de informação, trazendo ganhos concretos para usuários finais e negócios.