DEV Community: Lincoln Romais

# RAG em 2026: Do Básico ao Agêntico — Guia Prático com Python

Lincoln Romais — Mon, 13 Jul 2026 00:55:45 +0000

Se você já usou o ChatGPT, o Claude ou qualquer assistente de IA para responder perguntas sobre documentos internos da sua empresa, provavelmente já usou RAG sem saber. Neste artigo vamos entender o que é RAG, por que ele existe, como funciona na prática — com código Python — e quais são as tendências mais recentes que estão redefinindo essa arquitetura em 2026.

O problema que o RAG resolve

LLMs como GPT, Claude ou Gemini são treinados com um corpus de dados até uma certa data (o knowledge cutoff). Isso gera dois problemas:

Conhecimento desatualizado: o modelo não sabe o que aconteceu depois do treinamento.
Conhecimento genérico: o modelo não conhece os documentos internos da sua empresa, seu banco de dados de produtos, ou seus contratos.

A saída "óbvia" seria fazer fine-tuning do modelo com seus dados. Mas isso é caro, lento, e precisa ser refeito toda vez que os dados mudam.

O RAG (Retrieval-Augmented Generation) resolve isso de outra forma: em vez de "ensinar" o modelo, você busca a informação relevante em tempo real e a entrega como contexto na hora da pergunta.

Pergunta do usuário
      │
      ▼
 [Retriever] ──busca──▶ [Base de conhecimento]
      │
      ▼
Contexto relevante + Pergunta
      │
      ▼
   [LLM] ──▶ Resposta grounded (fundamentada)

Anatomia de um pipeline RAG básico

Vamos construir um RAG simples do zero, sem frameworks, só para entender os conceitos. Depois falamos de ferramentas prontas.

1. Chunking — quebrando documentos em pedaços

Documentos grandes não cabem inteiros no contexto do LLM, e mesmo se coubessem, buscar em um texto inteiro é menos preciso do que buscar em pedaços menores e mais específicos.

def chunk_text(text: str, chunk_size: int = 500, overlap: int = 50) -> list[str]:
    """Divide o texto em chunks com sobreposição para não perder contexto nas bordas."""
    words = text.split()
    chunks = []
    start = 0
    while start < len(words):
        end = start + chunk_size
        chunk = " ".join(words[start:end])
        chunks.append(chunk)
        start += chunk_size - overlap
    return chunks

documento = """
RAG combina recuperação de informação com geração de texto...
(imagine um documento de várias páginas aqui)
"""
chunks = chunk_text(documento, chunk_size=100, overlap=20)
print(f"Documento dividido em {len(chunks)} chunks")

Dica prática: o overlap evita que uma frase importante seja cortada exatamente na fronteira entre dois chunks e perca sentido.

2. Embeddings — transformando texto em vetores

Um embedding é uma representação numérica do significado de um texto. Textos com significados parecidos geram vetores próximos no espaço.

from openai import OpenAI

client = OpenAI()

def gerar_embedding(texto: str) -> list[float]:
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=texto
    )
    return response.data[0].embedding

# Exemplo
vetor = gerar_embedding("Como cancelo minha assinatura?")
print(len(vetor))  # ex: 1536 dimensões

Frases como "Como cancelo minha assinatura?" e "Quero encerrar meu plano" terão vetores próximos, mesmo sem compartilhar nenhuma palavra — isso é a mágica da busca semântica.

3. Indexação — armazenando os vetores

Para buscar rapidamente entre milhares (ou milhões) de vetores, usamos um banco vetorial. Aqui vai um exemplo simples com ChromaDB, que roda localmente:

import chromadb

chroma_client = chromadb.Client()
colecao = chroma_client.create_collection(name="documentos")

# Indexando os chunks
for i, chunk in enumerate(chunks):
    colecao.add(
        documents=[chunk],
        ids=[f"chunk_{i}"]
    )

O ChromaDB gera os embeddings automaticamente por baixo dos panos (ou você pode passar os seus próprios).

4. Retrieval — buscando o que é relevante

def buscar_contexto(pergunta: str, top_k: int = 3) -> list[str]:
    resultados = colecao.query(
        query_texts=[pergunta],
        n_results=top_k
    )
    return resultados["documents"][0]

pergunta = "Como funciona o overlap no chunking?"
contexto = buscar_contexto(pergunta)
print(contexto)

5. Geração — juntando tudo

def responder_com_rag(pergunta: str) -> str:
    contexto = buscar_contexto(pergunta)
    contexto_formatado = "\n\n".join(contexto)

    prompt = f"""Responda à pergunta usando APENAS o contexto abaixo.
Se a resposta não estiver no contexto, diga que não sabe.

Contexto:
{contexto_formatado}

Pergunta: {pergunta}
"""

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}]
    )
    return response.choices[0].message.content

print(responder_com_rag("Como funciona o overlap no chunking?"))

Pronto — esse é um RAG funcional, ainda que simples. Ele já resolve boa parte dos casos de uso. Mas, na prática, esse pipeline "ingênuo" falha bastante. Vamos entender por quê.

Por que RAG simples falha (e como consertar)

Estudos de 2026 mostram que quando um sistema RAG erra, a causa é o retrieval na maioria esmagadora dos casos — não a geração. Ou seja: o LLM está sendo alimentado com o contexto errado e, mesmo assim, gera uma resposta fluente e convincente. Isso é perigoso porque parece certo.

Os problemas mais comuns:

Gap semântico: a pergunta do usuário usa vocabulário diferente do documento (ex: "cancelar assinatura" vs. "encerramento de conta").
Poluição de contexto: buscar 10 chunks quando só 2 são relevantes dilui o sinal e piora a resposta.
Chunks quebrados: um chunk de tamanho fixo pode cortar uma tabela no meio ou uma frase pela metade.

Solução 1: Busca híbrida (vetorial + lexical)

Nem tudo é semântica. Se o usuário busca por um código de erro específico (ERR_504) ou um nome próprio, a busca vetorial pode falhar — mas uma busca por palavra-chave (BM25) acerta na hora. A busca híbrida combina os dois:

from rank_bm25 import BM25Okapi

# Índice lexical (palavra-chave)
tokenized_chunks = [c.split() for c in chunks]
bm25 = BM25Okapi(tokenized_chunks)

def busca_hibrida(pergunta: str, top_k: int = 3, peso_vetorial: float = 0.6):
    # Busca vetorial (semântica)
    resultados_vetoriais = colecao.query(query_texts=[pergunta], n_results=top_k)

    # Busca lexical (BM25)
    scores_bm25 = bm25.get_scores(pergunta.split())

    # Aqui você combinaria os rankings (ex: Reciprocal Rank Fusion)
    # Simplificado para fins didáticos
    return resultados_vetoriais, scores_bm25

Solução 2: Reranking

Depois de recuperar, por exemplo, 20 candidatos com busca rápida (barata), usa-se um modelo mais caro e preciso — um cross-encoder — para reordenar e escolher só os 3-5 melhores.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

def rerank(pergunta: str, candidatos: list[str], top_k: int = 3) -> list[str]:
    pares = [(pergunta, c) for c in candidatos]
    scores = reranker.predict(pares)
    ranqueados = sorted(zip(candidatos, scores), key=lambda x: x[1], reverse=True)
    return [chunk for chunk, score in ranqueados[:top_k]]

Essa é considerada uma das melhorias de maior custo-benefício em RAG: retrieval barato traz muitos candidatos, reranking caro escolhe os melhores.

Solução 3: HyDE (Hypothetical Document Embeddings)

Uma técnica elegante: em vez de buscar diretamente pela pergunta do usuário, pedimos ao LLM para gerar uma resposta hipotética primeiro, e buscamos pelo embedding dessa resposta. Por quê funciona? Porque a resposta hipotética usa o vocabulário do domínio, mais parecido com o dos documentos, do que a pergunta original do usuário.

def hyde_retrieval(pergunta: str) -> list[str]:
    resposta_hipotetica = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": f"Responda hipoteticamente: {pergunta}"}]
    ).choices[0].message.content

    return buscar_contexto(resposta_hipotetica)

As tendências de 2026

Com essa base, dá pra entender melhor para onde o RAG está indo:

RAG Agêntico

O padrão dominante hoje trata a busca como um processo iterativo de decisão, não uma etapa única. Um agente pode decidir buscar, avaliar se a evidência é suficiente, refinar a busca, ou até consultar múltiplas fontes (SQL, grafo, busca vetorial) antes de responder.

def rag_agentico(pergunta: str, max_tentativas: int = 3) -> str:
    contexto_acumulado = []
    for tentativa in range(max_tentativas):
        contexto = buscar_contexto(pergunta, top_k=3)
        contexto_acumulado.extend(contexto)

        # O próprio LLM avalia se já tem evidência suficiente
        avaliacao = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{
                "role": "user",
                "content": f"Contexto: {contexto_acumulado}\n\n"
                            f"Pergunta: {pergunta}\n\n"
                            f"O contexto é suficiente para responder? Responda SIM ou NAO."
            }]
        ).choices[0].message.content

        if "SIM" in avaliacao.upper():
            break
        # Se não, reformula a busca (ex: gera sub-perguntas) e tenta de novo

    return responder_com_rag(pergunta)

GraphRAG

Em vez de recuperar apenas chunks de texto isolados, o GraphRAG recupera subgrafos — entidades e as relações entre elas. Isso é poderoso quando a resposta depende de conectar várias informações espalhadas (ex: "quais projetos o funcionário X liderou que envolveram o cliente Y?"), algo que a busca vetorial pura tem dificuldade de capturar.

RAG auto-corretivo

O sistema avalia sua própria resposta antes de entregá-la ao usuário e refaz a busca se a confiança for baixa — reduzindo bastante as alucinações em domínios de alto risco (saúde, jurídico, financeiro).

Segurança e governança

Com RAG virando peça central de sistemas empresariais, surgiram preocupações novas: envenenamento de corpus (alguém injeta documentos maliciosos na base para manipular respostas) e a necessidade de controle de acesso granular — para que o RAG não vire uma forma de vazar dados que o usuário não deveria ver.

E para documentos gigantes? (livros, relatórios, corpus enormes)

Tudo que vimos até aqui parte de um pressuposto: chunks tratados como uma lista "achatada" (flat), todos no mesmo nível, competindo entre si na busca. Isso funciona bem para bases pequenas, mas quebra em dois cenários comuns:

Documentos muito longos (um livro, um relatório de 300 páginas): a resposta certa pode exigir juntar informação de capítulos diferentes.
Corpus muito grande (milhares de documentos): comparar a pergunta com todos os chunks de todos os documentos fica caro e impreciso.

Para isso, surgiram técnicas que adicionam estrutura hierárquica ao índice, em vez de tratar tudo como uma lista plana.

RAPTOR — árvore de resumos recursivos

A ideia do RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval) é simples de entender, mas poderosa: em vez de indexar só os chunks originais, ele constrói uma árvore.

Nível 2:        [Resumo geral do documento]
                    /              \
Nível 1:   [Resumo seção A]   [Resumo seção B]
              /      \             /      \
Nível 0:  chunk1   chunk2     chunk3   chunk4   (texto original)

Como isso é construído:

Gera embeddings de todos os chunks originais (nível 0).
Agrupa (clustering) chunks semanticamente parecidos.
Para cada grupo, pede ao LLM um resumo abstrativo.
Repete o processo sobre os resumos, criando o próximo nível da árvore, até sobrar só um resumo geral no topo.

Na hora da busca, o sistema compara a pergunta com nós de todos os níveis simultaneamente — tanto chunks bem específicos quanto resumos de alto nível — e retorna a melhor mistura. Isso é o que permite responder perguntas de síntese ("do que trata esse relatório de forma geral?") e perguntas pontuais ("qual foi o valor mencionado na seção 4.2?") com o mesmo índice.

Implementação simplificada:

from sklearn.cluster import KMeans
import numpy as np

def gerar_resumo(textos: list[str]) -> str:
    """Pede ao LLM um resumo abstrativo de um grupo de chunks."""
    texto_unido = "\n\n".join(textos)
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{
            "role": "user",
            "content": f"Resuma o texto abaixo de forma concisa, preservando os fatos-chave:\n\n{texto_unido}"
        }]
    )
    return response.choices[0].message.content

def construir_arvore_raptor(chunks: list[str], n_clusters: int = 3, niveis: int = 2) -> list[list[str]]:
    """Constrói uma árvore RAPTOR simplificada: retorna uma lista de níveis,
    cada um contendo os textos (chunks originais ou resumos) daquele nível."""
    arvore = [chunks]  # nível 0 = chunks originais
    nivel_atual = chunks

    for _ in range(niveis):
        if len(nivel_atual) <= n_clusters:
            break  # já convergiu para poucos nós, não vale a pena agrupar mais

        # Embeddings do nível atual
        embeddings = np.array([gerar_embedding(t) for t in nivel_atual])

        # Clustering
        k = min(n_clusters, len(nivel_atual))
        kmeans = KMeans(n_clusters=k, random_state=42, n_init=10).fit(embeddings)

        # Gera um resumo por cluster
        proximo_nivel = []
        for cluster_id in range(k):
            membros = [t for t, label in zip(nivel_atual, kmeans.labels_) if label == cluster_id]
            proximo_nivel.append(gerar_resumo(membros))

        arvore.append(proximo_nivel)
        nivel_atual = proximo_nivel

    return arvore

def indexar_arvore(arvore: list[list[str]]):
    """Indexa todos os níveis da árvore na mesma coleção vetorial."""
    for nivel_idx, nivel in enumerate(arvore):
        for i, texto in enumerate(nivel):
            colecao.add(
                documents=[texto],
                metadatas=[{"nivel": nivel_idx}],
                ids=[f"n{nivel_idx}_c{i}"]
            )

# Uso
arvore = construir_arvore_raptor(chunks, n_clusters=3, niveis=2)
indexar_arvore(arvore)
# A busca (colecao.query) agora retorna candidatos de qualquer nível —
# tanto chunks originais quanto resumos — misturados por relevância.

Quando usar: ótimo para um único documento longo (livro, relatório) onde perguntas de síntese são comuns. Limitação importante: pesquisas recentes mostram que essa abordagem em árvore perde precisão quando o espaço de busca cresce para nível de corpus inteiro, com milhões de tokens espalhados por muitos documentos — RAPTOR foi pensado para profundidade (um documento longo), não para largura (muitos documentos).

RAG hierárquico em 2 estágios — documento primeiro, chunk depois

Uma alternativa mais simples e barata, ótima quando você tem muitos documentos (não necessariamente cada um gigante): em vez de comparar a pergunta com todos os chunks de todos os documentos de uma vez, faça em duas etapas.

def busca_hierarquica_2_estagios(pergunta: str, top_documentos: int = 3, top_chunks: int = 3):
    # Estágio 1: busca em nível de DOCUMENTO (usando resumo/embedding de cada doc inteiro)
    docs_relevantes = colecao_documentos.query(
        query_texts=[pergunta],
        n_results=top_documentos
    )

    # Estágio 2: busca só DENTRO dos documentos encontrados no estágio 1
    resultados_finais = []
    for doc_id in docs_relevantes["ids"][0]:
        chunks_do_doc = colecao_chunks.query(
            query_texts=[pergunta],
            n_results=top_chunks,
            where={"documento_id": doc_id}  # filtra só chunks desse documento
        )
        resultados_finais.extend(chunks_do_doc["documents"][0])

    return resultados_finais

Isso funciona porque reduz drasticamente o espaço de busca: em vez de vasculhar milhares de chunks, você primeiro elimina os documentos irrelevantes e só depois refina. Um corpus de 100 documentos com 20 chunks cada (2.000 chunks) pode cair para ~60 comparações de similaridade — cerca de 33x menos custo — mantendo o mesmo recall, desde que o estágio 1 não erre o documento certo.

Parent-Child Retrieval — busca precisa, contexto generoso

Outra técnica simples e muito usada na prática: você indexa chunks pequenos (uma ou duas frases) para ter a busca mais precisa possível, mas guarda a referência de qual "chunk pai" (um parágrafo maior, ou o documento inteiro) cada um pertence. Quando um chunk-filho é encontrado na busca, você recupera o pai para dar ao LLM.

def indexar_com_hierarquia_pai_filho(documento: str, doc_id: str):
    paragrafos = documento.split("\n\n")  # os "pais"

    for p_idx, paragrafo in enumerate(paragrafos):
        parent_id = f"{doc_id}_p{p_idx}"
        frases = paragrafo.split(". ")  # os "filhos", granularidade menor

        for f_idx, frase in enumerate(frases):
            colecao.add(
                documents=[frase],
                metadatas=[{"parent_id": parent_id, "parent_text": paragrafo}],
                ids=[f"{parent_id}_f{f_idx}"]
            )

def buscar_com_contexto_do_pai(pergunta: str, top_k: int = 3) -> list[str]:
    resultados = colecao.query(query_texts=[pergunta], n_results=top_k)
    # Retorna o texto do PAI, não do filho — contexto mais rico pro LLM
    return [meta["parent_text"] for meta in resultados["metadatas"][0]]

A vantagem: a busca compara a pergunta com unidades pequenas e específicas (mais fácil de "casar" semanticamente), mas o LLM recebe um contexto maior e mais coerente, em vez de uma frase solta fora de contexto.

GraphRAG e MegaRAG — quando a resposta exige conectar pontos

Para perguntas que exigem raciocínio multi-hop — tipo "quais projetos o funcionário X liderou que envolveram o cliente Y?" — nenhuma das técnicas acima resolve bem, porque a resposta não está em um único chunk, está na relação entre entidades espalhadas pelo documento.

O GraphRAG ataca isso construindo um grafo de conhecimento a partir dos documentos (entidades + relações), depois agrupa entidades relacionadas em "comunidades" e gera resumos hierárquicos desses grupos. Na busca, em vez de retornar chunks, ele retorna subgrafos — o que permite ao LLM seguir cadeias de relação que a busca por similaridade pura nunca capturaria.

# Pseudocódigo conceitual — bibliotecas como Neo4j + LLM, ou frameworks
# como Microsoft GraphRAG cuidam da parte pesada na prática

def construir_grafo(documento: str):
    entidades_e_relacoes = extrair_entidades_relacoes_com_llm(documento)
    grafo = montar_grafo(entidades_e_relacoes)  # ex: Neo4j
    comunidades = detectar_comunidades(grafo)   # ex: algoritmo de Louvain
    resumos_comunidades = {
        c: gerar_resumo(nos_da_comunidade(grafo, c)) for c in comunidades
    }
    return grafo, resumos_comunidades

def busca_graphrag(pergunta: str, grafo, resumos_comunidades):
    comunidades_relevantes = buscar_comunidades_relevantes(pergunta, resumos_comunidades)
    subgrafo = extrair_subgrafo(grafo, comunidades_relevantes)
    return subgrafo  # entregue ao LLM como contexto estruturado

A variante MegaRAG estende essa ideia para documentos multimodais — livros e relatórios com diagramas, figuras e tabelas — extraindo entidades tanto do texto quanto do conteúdo visual.

Qual técnica escolher?

Cenário	Técnica recomendada
Um documento longo, perguntas de síntese	RAPTOR
Muitos documentos, corpus grande	Hierárquico em 2 estágios
Precisão na busca + contexto rico na resposta	Parent-Child Retrieval
Perguntas que conectam entidades/relações (multi-hop)	GraphRAG
Documentos com tabelas, figuras, diagramas	MegaRAG

Na prática, essas técnicas não são mutuamente exclusivas — é comum combinar, por exemplo, parent-child retrieval com busca hierárquica em 2 estágios, ou usar RAPTOR dentro de cada documento de um corpus que também tem busca em 2 estágios no nível macro.

Conclusão

RAG começou como "busque uns chunks e jogue no prompt", mas evoluiu para uma camada de raciocínio, memória e governança em torno dos LLMs. Se você está começando, o pipeline básico (chunking → embeddings → índice vetorial → retrieval → geração) já resolve muita coisa. Mas conforme sua aplicação cresce — seja em complexidade das perguntas ou em tamanho dos documentos — vale a pena investir em busca híbrida, reranking, estruturas hierárquicas (RAPTOR, busca em 2 estágios, parent-child) e, dependendo do caso, em padrões agênticos ou baseados em grafo.

A régua de qualidade em 2026 não é mais "o RAG funciona?", é "o RAG erra graciosamente, sabe quando não sabe, e protege os dados que não deveria expor?".

Gostou do artigo? Deixe um comentário contando qual parte do seu pipeline RAG te dá mais dor de cabeça — retrieval, chunking ou avaliação de qualidade.

Construindo um Índice Estatístico para Prever o Campeão da Copa 2026

Lincoln Romais — Tue, 30 Jun 2026 12:17:30 +0000

Como combinei dados reais da fase de grupos com histórico e ranking FIFA para ranquear os favoritos — e o que os números dizem sobre Brasil, Argentina e França

Toda Copa do Mundo traz a mesma pergunta: quem vai ganhar?

A maioria das respostas vem de palpite, torcida ou memória afetiva. Resolvi fazer diferente. Neste artigo, vou mostrar passo a passo como construí um índice composto usando dados reais da competição — e como você pode reproduzir (ou questionar) cada decisão que tomei.

Spoiler: a matemática coloca Argentina e França numa classe à parte. Mas o Brasil tem um argumento histórico que nenhum outro time consegue igualar.

O Problema: por que não usar só a tabela de pontos?

A primeira ideia óbvia é olhar para quem está liderando o grupo. Mas isso tem um problema sério: a fase de grupos não é equilibrada.

Um time pode ter 9 pontos enfrentando adversários fracos, enquanto outro tem 6 pontos num grupo muito difícil. Além disso, a Copa não termina na fase de grupos — e títulos mundiais não aparecem em nenhuma tabela de classificação.

Precisamos de um índice que capture três coisas ao mesmo tempo:

Forma atual — como o time está jogando agora
Qualidade do elenco — o quanto ele é tecnicamente superior
DNA de campeão — histórico de desempenho e conquistas em Copas

As 5 Dimensões do Índice

Depois de testar algumas combinações, cheguei a 5 variáveis com pesos distintos:

Dimensão	Variável	Peso
Forma atual	Aproveitamento na fase de grupos	35%
Equilíbrio tático	Eficiência gols pró / gols contra	20%
Tradição	Histórico em Copas do Mundo	20%
Conquistas	Número de títulos mundiais	15%
Qualidade	Ranking FIFA atual	10%

Por que esses pesos?

35% para aproveitamento porque a forma atual é o dado mais fresco e direto que temos. Um time que venceu os 3 jogos está tecnicamente em melhor momento do que um que empatou dois.

20% para eficiência porque marcar muitos gols não adianta se você também toma muitos. A proporção gols pró / (gols pró + gols contra) mede equilíbrio entre ataque e defesa de forma mais honesta do que o saldo de gols isolado.

20% para histórico porque Copa do Mundo é um torneio de pressão extrema. Times com tradição de semifinal e final tendem a performar melhor nas fases decisivas — é algo difícil de quantificar, mas impossível de ignorar.

15% para títulos porque há uma diferença real entre ter conquistado a Copa e nunca ter chegado lá. Normalizei pelo máximo possível (5, que é o Brasil).

10% para ranking FIFA porque o ranking captura a qualidade média do elenco ao longo do tempo, não só os últimos 3 jogos.

O Código

Toda a lógica cabe em uma função:

def calc_score(time: dict) -> float:
    # Aproveitamento: pontos obtidos sobre máximo possível (9)
    aproveitamento = time["pts"] / 9

    # Eficiência: proporção do total de gols que foram marcados pelo time
    eficiencia = time["gp"] / max(time["gp"] + time["gc"], 1)

    # Histórico: normalizado de 0 a 1 (entrada: 0–100)
    historico = time["historico"] / 100

    # Títulos: normalizado pelo máximo histórico (5 = Brasil)
    titulos = min(time["titulos"] / 5, 1)

    # Ranking FIFA: invertido (rank 1 = melhor) e normalizado
    rank = (10 - min(time["rank_fifa"], 10)) / 9

    return (
        aproveitamento * 35 +
        eficiencia     * 20 +
        historico      * 20 +
        titulos        * 15 +
        rank           * 10
    )

Simples, sem biblioteca, sem magia. Cada linha tem uma justificativa clara.

Os Dados de Entrada

Coletei os dados reais da fase de grupos via SportRadar em 29/06/2026. Os dados históricos são referência pública do ranking FIFA e do acervo de títulos de cada seleção.

FAVORITOS = [
    {"nome": "Argentina",  "pts": 9, "gp": 9, "gc": 2, "v": 3, "e": 0, "d": 0,
     "titulos": 3, "rank_fifa": 1, "historico": 95},

    {"nome": "França",     "pts": 9, "gp": 9, "gc": 2, "v": 3, "e": 0, "d": 0,
     "titulos": 2, "rank_fifa": 2, "historico": 88},

    {"nome": "Brasil",     "pts": 7, "gp": 7, "gc": 3, "v": 2, "e": 1, "d": 0,
     "titulos": 5, "rank_fifa": 5, "historico": 92},

    {"nome": "Espanha",    "pts": 7, "gp": 8, "gc": 2, "v": 2, "e": 1, "d": 0,
     "titulos": 1, "rank_fifa": 3, "historico": 82},

    {"nome": "Alemanha",   "pts": 6, "gp": 7, "gc": 4, "v": 2, "e": 0, "d": 1,
     "titulos": 4, "rank_fifa": 4, "historico": 85},

    {"nome": "Inglaterra", "pts": 7, "gp": 6, "gc": 2, "v": 2, "e": 1, "d": 0,
     "titulos": 1, "rank_fifa": 6, "historico": 75},

    {"nome": "Portugal",   "pts": 5, "gp": 4, "gc": 3, "v": 1, "e": 2, "d": 0,
     "titulos": 0, "rank_fifa": 7, "historico": 70},

    {"nome": "Holanda",    "pts": 7, "gp": 6, "gc": 2, "v": 2, "e": 1, "d": 0,
     "titulos": 0, "rank_fifa": 8, "historico": 72},
]

A variável historico é uma métrica composta que criei manualmente, baseada em presença em finais, semifinais e títulos nos últimos 40 anos, normalizada de 0 a 100. É a parte mais subjetiva do modelo — e é justo assumir isso.

Calculando e Ordenando

# Calcula o score de cada time e ordena do maior para o menor
ranking = sorted(
    [{**t, "score": calc_score(t)} for t in FAVORITOS],
    key=lambda t: t["score"],
    reverse=True
)

max_score = ranking[0]["score"]

# Normaliza para um índice de 0–100%
ranking_final = [
    {**t, "indice": round((t["score"] / max_score) * 100, 1)}
    for t in ranking
]

Normalizar pelo maior score transforma o resultado em um índice relativo: o favorito vira 100% e os outros ficam proporcionais a ele. Isso é mais fácil de comunicar do que um número bruto como "86.4".

Os Resultados

Aplicando a fórmula nos dados de 29/06/2026:

🇦🇷 Argentina   ████████████████████████████████████████ 100.0%
🇫🇷 França      ████████████████████████████████████████  97.3%
🇧🇷 Brasil      ████████████████████████████████████      91.3%
🇪🇸 Espanha     ███████████████████████████████████       87.0%
🇩🇪 Alemanha    █████████████████████████████████         83.1%
🏴󠁧󠁢󠁥󠁮󠁧󠁿 Inglaterra  ███████████████████████████████           77.8%
🇳🇱 Holanda     ████████████████████████████████          79.3%
🇵🇹 Portugal    ████████████████████████████              69.6%

Lendo os números

Argentina (100%) — campanha perfeita: 9 pontos, 9 gols marcados, 2 sofridos, saldo de +7, ranking FIFA #1. O único "custo" no índice é ter menos títulos históricos que Brasil e Alemanha.

França (97.3%) — praticamente empatada com a Argentina nos dados da fase de grupos. O que separa as duas é o menor número de títulos (2 contra 3) e o histórico ligeiramente inferior. Na prática, estão em nível igual.

Brasil (91.3%) — o peso histórico salva o Brasil de uma posição mais baixa. Com aproveitamento de 77.8% (inferior aos dois primeiros) e 3 gols sofridos, a campanha atual não é a mais dominante. Mas 5 títulos e um historico: 92 puxam o score para cima.

Espanha (87%) — o dado mais surpreendente positivo. Melhor saldo de gols entre todos os favoritos (8 pró, 2 contra), mas penalizada pelo menor número de títulos (1) e ranking FIFA #3.

Alemanha (83.1%) — 4 títulos mundiais garantem uma base histórica forte, mas a única derrota na fase de grupos e os 4 gols sofridos puxam o score para baixo.

O Que o Modelo Não Captura

Toda análise estatística tem limites. Ser transparente sobre eles é parte do trabalho.

Este índice não considera:

Chaveamento do mata-mata — um sorteio favorável ou desfavorável pode redefinir tudo. Uma Argentina que pega Portugal nas quartas enfrenta desafio muito diferente de uma que pega Marrocos.
Lesões — o dado de hoje pode ser inútil amanhã. Um jogador-chave fora muda o time completamente.
Forma individual — Messi em grande fase vale mais do que qualquer número no modelo. Estatística agregada não captura picos de performance individual.
Pênaltis — a Inglaterra sabe bem o que acontece quando o jogo vai para a loteria das penalidades. Não existe variável histórica boa o suficiente para prever isso.
Pressão psicológica — times que nunca ganharam uma Copa podem travar em decisões. Isso aparece parcialmente no historico, mas de forma imperfeita.

Como Você Pode Melhorar Esse Modelo

Se quiser ir além, aqui estão algumas extensões possíveis:

1. Simular o chaveamento

Em vez de só calcular um índice, você pode simular os confrontos do mata-mata com probabilidades baseadas no score de cada time. Monte Carlo com 10.000 simulações daria uma distribuição de chances de título.

import random

def simular_copa(times: list, simulacoes: int = 10000) -> list:
    vitorias = {t["nome"]: 0 for t in times}

    for _ in range(simulacoes):
        campeao = simular_mata_mata(times)  # sua lógica aqui
        vitorias[campeao] += 1

    return sorted(
        [{"nome": nome, "prob": round(v / simulacoes * 100, 1)}
         for nome, v in vitorias.items()],
        key=lambda x: x["prob"],
        reverse=True
    )

2. Adicionar dados de jogadores

Integrar dados individuais (gols, assistências, minutos jogados) para criar um score de elenco mais granular, em vez de usar apenas o ranking FIFA.

3. Atualizar em tempo real

Conectar a uma API de dados esportivos e recalcular o índice após cada jogo. O score muda a cada resultado — e a Copa ainda tem muitos jogos pela frente.

4. Ajustar pesos com machine learning

Se você tiver dados históricos de Copas anteriores, pode usar regressão logística para aprender os pesos ótimos em vez de defini-los manualmente.

Conclusão

Com os dados disponíveis em 29/06/2026, Argentina e França são as seleções em melhor forma — campanhas perfeitas, defesas sólidas e histórico de alto nível. O Brasil aparece em terceiro, sustentado pelo maior acervo de títulos da história, mas com margem para melhorar na fase eliminatória.

O modelo é simples por design. Não porque o problema é simples — Copa do Mundo é caótica por natureza — mas porque modelos simples e transparentes são mais honestos do que caixas-pretas sofisticadas que fingem certeza onde não existe nenhuma.

A estatística aqui é uma lente. Quem decide o campeonato ainda é o futebol.

Código Completo

O dashboard interativo com todos os dados está disponível em HTML puro, sem frameworks — basta abrir no navegador.

👉 *Dash interativo

Dados coletados via SportRadar · 29/06/2026

Tags: #python #datascience #futebol #copa2026 #estatistica #worldcup

# Criei um assistente que me manda os papers do dia traduzidos no Telegram

Lincoln Romais — Wed, 27 May 2026 20:02:57 +0000

Se você acompanha pesquisa em IA, sabe que o HuggingFace Papers solta novos papers todo dia. O problema? São dezenas de abstracts em inglês, e ler tudo manualmente é inviável no dia a dia.

Resolvi automatizar isso: um script Python que busca os papers do dia, joga cada abstract pro meu LLM local via Ollama, traduz pra português e manda tudo pro Telegram. Sem pagar por API, sem nada na nuvem.

Neste artigo vou te mostrar como funciona e como você pode replicar em menos de 10 minutos.

O que o projeto faz

Consulta a API do HuggingFace e pega os papers em alta do dia
Para cada paper, manda o abstract pro Ollama (LLM rodando localmente) pedir uma tradução e resumo em português
Formata a mensagem com título, autores, upvotes e o resumo traduzido
Envia cada paper como mensagem separada no Telegram

O resultado no Telegram fica assim:

🤖 HuggingFace Papers — 27/05/2026
Top 8 papers do dia, traduzidos com llama3
──────────────────────────────

1. *Scaling Laws for Reward Model Overoptimization*
👥 Leo Gao, John Schulman, Jacob Hilton
💬 142 upvotes

📝 Investigamos como o desempenho de modelos de linguagem muda quando otimizamos 
excessivamente contra um modelo de recompensa (reward model). Descobrimos que o 
desempenho no proxy aumenta mas o desempenho verdadeiro diminui — um fenômeno 
conhecido como overoptimization. Nossos experimentos mostram leis de escala 
previsíveis para esse comportamento...

🔗 HuggingFace | arXiv

Pré-requisitos

Python 3.10+
Ollama instalado com llama3 (ou qualquer modelo que você tiver)
Um bot no Telegram (leva 2 minutos criar)

Estrutura do projeto

hf-digest/
├── hf_digest.py      # script principal
├── config.py         # suas configurações
└── get_chat_id.py    # helper para descobrir o chat_id

O código

`config.py`

Começa pela configuração. Tudo em um lugar só, fácil de ajustar:

TELEGRAM_BOT_TOKEN = "SEU_TOKEN_AQUI"
TELEGRAM_CHAT_ID   = "SEU_CHAT_ID_AQUI"
OLLAMA_URL         = "http://localhost:11434"
OLLAMA_MODEL       = "llama3"
MAX_PAPERS         = 8

Buscando os papers

A API do HuggingFace retorna os papers do dia em JSON. Simples assim:

def fetch_papers() -> list[dict]:
    today = datetime.now().strftime("%Y-%m-%d")
    url = f"https://huggingface.co/api/daily_papers?date={today}"

    headers = {"User-Agent": "Mozilla/5.0 (compatible; HFDigestBot/1.0)"}
    response = requests.get(url, headers=headers, timeout=20)
    response.raise_for_status()

    papers = response.json()
    return papers[:MAX_PAPERS]

Traduzindo com Ollama

Aqui mora a mágica. O Ollama expõe uma API REST local no localhost:11434. A gente manda um prompt e ele retorna a resposta do modelo:

def translate_with_ollama(text: str) -> str:
    prompt = f"""Você é um assistente especializado em IA e ML. 
Traduza e resuma o seguinte abstract para o português brasileiro.
Mantenha termos técnicos em inglês entre parênteses quando necessário.
Responda APENAS com o resumo, sem frases introdutórias.

Abstract:
{text}"""

    payload = {
        "model": OLLAMA_MODEL,
        "prompt": prompt,
        "stream": False,
    }

    response = requests.post(
        f"{OLLAMA_URL}/api/generate",
        json=payload,
        timeout=120,
    )
    return response.json()["response"].strip()

O stream: False faz o Ollama esperar processar tudo antes de responder — mais fácil de lidar do que streaming para esse caso de uso.

Enviando pro Telegram

O bot do Telegram aceita Markdown, então dá pra formatar bem as mensagens:

def send_telegram(text: str) -> bool:
    url = f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage"
    payload = {
        "chat_id": TELEGRAM_CHAT_ID,
        "text": text,
        "parse_mode": "Markdown",
        "disable_web_page_preview": True,
    }
    response = requests.post(url, json=payload, timeout=15)
    return response.ok

Juntando tudo no `main()`

def main():
    papers = fetch_papers()

    # Cabeçalho
    send_telegram(f"🤖 *HuggingFace Papers — {datetime.now().strftime('%d/%m/%Y')}*")

    for i, paper in enumerate(papers, start=1):
        abstract = paper["paper"].get("summary", "")

        translated = translate_with_ollama(abstract)
        message = format_paper(paper, i, translated)
        send_telegram(message)

    send_telegram(f"✅ {len(papers)} papers enviados!")

Setup em 5 minutos

1. Instale a dependência

pip install requests

2. Crie o bot no Telegram

Abra o Telegram e procure @botfather
Envie /newbot, siga as instruções
Copie o token e cole em config.py

3. Descubra seu Chat ID

Envie qualquer mensagem pro seu novo bot e rode:

# get_chat_id.py
import requests
from config import TELEGRAM_BOT_TOKEN

r = requests.get(f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/getUpdates")
updates = r.json()["result"]
chat_id = updates[-1]["message"]["chat"]["id"]
print(f"Seu chat_id: {chat_id}")

4. Suba o Ollama e rode

ollama serve
python3 hf_digest.py

Por que rodar o LLM localmente?

Poderia ter usado a API da OpenAI ou do Gemini para traduzir. Mas há algumas vantagens em rodar local:

Custo zero — sem pagar por token
Privacidade — os abstracts não saem da sua máquina
Sem rate limit — processa quantos papers quiser
Funciona offline — depois de baixar o modelo, não precisa de internet pra traduzir

O llama3 faz um trabalho muito bom em traduções técnicas. Se quiser mais velocidade, o phi4 ou gemma3 também funcionam bem e são mais leves.

Automatizando com cron

Para receber o digest todo dia de manhã sem precisar rodar manualmente, adicione ao crontab:

crontab -e

0 9 * * * cd /caminho/para/hf-digest && python3 hf_digest.py >> digest.log 2>&1

Possíveis melhorias

Algumas ideias para evoluir o projeto:

Filtrar por área: só receber papers de NLP, ou de RL, por exemplo
Score de relevância: pedir pro LLM avaliar o quão relevante é pra você com base no seu perfil
Salvar em banco: guardar um histórico local dos papers lidos
Interface web: um painel simples para ler os papers traduzidos no navegador
Suporte a outros feeds: conectar com arXiv diretamente ou com Papers With Code

Código completo

O projeto completo está disponível no GitHub: [https://github.com/lromais/ai_newsletters]

Se você testar e fizer alguma melhoria, compartilha nos comentários! E se tiver dúvida em algum passo do setup, é só perguntar.

Tags: python, ai, ollama, telegram, machinelearning

# Arquitetando RAG Multi-Agente em Produção na AWS — Do Conceito à Operação

Lincoln Romais — Mon, 25 May 2026 13:23:40 +0000

Um guia completo de arquitetura para sistemas de recuperação aumentada com múltiplos agentes, controle de tokens e observabilidade em ambientes produtivos.

Por que RAG simples não é suficiente em produção?

RAG (Retrieval-Augmented Generation) resolve um dos maiores problemas dos modelos de linguagem: a alucinação. Em vez de confiar apenas no conhecimento que o modelo carrega internamente, você recupera documentos relevantes em tempo real e os injeta no contexto antes de gerar a resposta. O resultado é mais preciso, rastreável e atualizado.

O problema começa quando você tenta colocar isso em produção de verdade — com volume, complexidade e custo para controlar.

Um agente único fazendo tudo ao mesmo tempo vira gargalo rapidamente. Ele busca, raciocina, valida e responde, tudo em uma cadeia linear. Quando a tarefa exige cruzar múltiplas fontes, validar dados, ou raciocinar em múltiplos passos, a qualidade cai, a latência sobe e o custo explode.

A solução é dividir responsabilidades. Especializar. Orquestrar. É aí que entra a arquitetura multi-agente.

Conceitos Fundamentais — Antes de Começar

Se você já conhece esses termos, pode pular esta seção. Se não, vale dois minutos aqui antes de mergulhar na arquitetura.

RAG (Retrieval-Augmented Generation) é a técnica de buscar informações externas antes de gerar uma resposta. Em vez de o modelo responder só com o que aprendeu no treinamento, ele primeiro consulta documentos reais e usa esse conteúdo como base. O resultado é mais preciso e rastreável.

Agente é um programa autônomo que recebe uma tarefa, decide como executá-la e age para completá-la — podendo chamar ferramentas, APIs ou outros agentes no processo. Em arquiteturas multi-agente, cada agente tem uma especialidade e trabalha de forma coordenada com os demais.

Chunk é um pedaço de um documento maior. Como modelos de linguagem têm um limite de quanto texto conseguem processar de uma vez, os documentos são quebrados em fragmentos menores antes de serem indexados. O tamanho do chunk afeta diretamente a qualidade da busca e o custo das chamadas ao modelo.

Embedding é a transformação de um texto em um vetor numérico — uma lista de números que representa o significado daquele texto. Textos com significados parecidos geram vetores parecidos. É essa propriedade que permite encontrar documentos relevantes para uma pergunta sem depender de palavras-chave exatas.

Banco Vetorial (Vector Store) é um banco de dados especializado em armazenar e buscar vetores por similaridade. Na AWS, o OpenSearch Serverless cumpre esse papel. Você passa o vetor da pergunta e ele retorna os vetores de chunks mais próximos semanticamente.

Token é a unidade de medida de texto para modelos de linguagem. Grosseiramente, um token equivale a três ou quatro caracteres em português. Modelos cobram por token consumido — tanto no input (o que você envia) quanto no output (o que o modelo responde). Controlar tokens é controlar custo.

Cache Semântico é um mecanismo que armazena respostas anteriores e as reutiliza quando uma nova pergunta tem significado parecido — mesmo que as palavras sejam diferentes. Diferente do cache tradicional, que exige igualdade exata, o cache semântico usa similaridade de vetores para decidir se pode reaproveitar uma resposta.

Orquestrador é o agente central que coordena os demais. Ele recebe a pergunta, decide quais agentes acionar, em qual ordem, e consolida o resultado final. Nenhum agente especialista se comunica com o usuário diretamente — tudo passa pelo orquestrador.

Action Group é um mecanismo do Bedrock Agents que mapeia uma intenção a uma função executável — geralmente uma Lambda. Permite que o agente acesse sistemas externos como bancos de dados, APIs e serviços internos de forma controlada.

Guardrails são filtros configuráveis que o Bedrock aplica antes e depois da chamada ao modelo. Eles detectam e bloqueiam conteúdo sensível, dados pessoais (PII) e tentativas de manipulação do modelo — tanto no que o usuário envia quanto no que o modelo responde.

Reranker é um modelo secundário que recebe os resultados da busca vetorial e os reordena com um critério mais refinado. A busca vetorial é rápida mas imperfeita — o reranker faz uma segunda passagem mais cuidadosa para garantir que os chunks mais relevantes chegam ao modelo.

A Visão Geral da Arquitetura

Antes de entrar em cada camada, é importante entender o fluxo completo de uma requisição:

Uma pergunta chega pelo API Gateway, que cuida de autenticação e rate limiting. Ela é recebida pelo Orquestrador, que classifica a intenção, define o orçamento de tokens e distribui o trabalho para os agentes especializados. Esses agentes buscam, processam e validam as informações, consultando o pipeline de RAG — composto pelo banco vetorial, pelos documentos e pelo modelo de embeddings. A resposta consolidada volta ao usuário.

Cada componente tem uma responsabilidade clara e isolada. Isso é o que permite escalar, depurar e otimizar cada parte de forma independente.

Camada 1 — Ingestão e Indexação de Documentos

Tudo começa antes dos agentes. Seus documentos precisam estar indexados de forma inteligente para que a busca funcione bem depois.

O pipeline de ingestão

Os documentos brutos ficam armazenados no Amazon S3. Um processo de ingestão — que pode rodar em Lambda para documentos pequenos ou em Fargate para processamentos mais pesados — lê esses arquivos e os quebra em pedaços menores chamados chunks.

O tamanho do chunk não é um detalhe cosmético. É uma decisão de arquitetura com impacto direto em qualidade e custo. Chunks muito pequenos perdem contexto. Chunks muito grandes inflam o custo de cada chamada ao modelo. O intervalo mais equilibrado em produção fica entre 256 e 512 tokens por chunk, com um overlap de 50 tokens entre chunks adjacentes para não perder continuidade de raciocínio.

Cada chunk é então transformado em um vetor de embeddings pelo Amazon Bedrock — usando Titan Embeddings ou Cohere — e armazenado no OpenSearch Serverless, que serve como banco vetorial com suporte a busca por similaridade (kNN). Os metadados de cada chunk — de qual documento veio, quantos tokens tem, data de ingestão, domínio — ficam no DynamoDB para rastreabilidade e controle.

Por que o chunking mal feito é a raiz de muitos problemas

Se você cortar o texto de forma ingênua — a cada X caracteres independentemente do conteúdo — um único chunk pode conter partes de assuntos completamente diferentes. Isso polui o vetor resultante e confunde a busca semântica. O agente de recuperação vai trazer chunks irrelevantes não por falha sua, mas porque o índice foi mal construído na origem.

O chunking semântico resolve isso: você respeita parágrafos, seções e marcações do documento antes de cortar. É mais trabalhoso de implementar, mas tem impacto direto na qualidade das respostas.

Camada 2 — Os Agentes e seus Papéis

A arquitetura multi-agente funciona como uma empresa bem estruturada. Cada agente tem uma função definida e nenhum deles faz tudo.

O Orquestrador — o gerente da operação

O Orquestrador é o único ponto de contato com o mundo externo. Quando uma pergunta chega, ele:

Classifica a intenção — é uma pergunta factual simples? Uma análise que exige múltiplas fontes? Uma consulta que precisa cruzar sistemas diferentes? Cada tipo de intenção tem um caminho diferente no fluxo.

Define o orçamento de tokens antes de qualquer chamada ao modelo, calculando quanto contexto pode ser passado sem estourar os limites ou o custo.

Distribui o trabalho para os agentes especializados e consolida as respostas antes de devolver ao usuário.

O Orquestrador nunca executa o trabalho diretamente. Ele coordena.

O Agente de Recuperação — só busca, nada mais

Este agente tem uma responsabilidade única: dado uma pergunta, trazer os trechos de documentos mais relevantes do banco vetorial. Ele transforma a pergunta em vetor, consulta o OpenSearch e retorna os resultados ranqueados por similaridade.

Ele não interpreta, não raciocina, não responde. Só recupera. Essa separação permite otimizar a busca de forma independente sem impactar o resto do sistema.

O Agente de Síntese — quem fala com o modelo

O Agente de Síntese recebe o contexto montado — a pergunta original mais os chunks selecionados — e chama o modelo de linguagem para gerar a resposta. É aqui que o orçamento de tokens definido pelo Orquestrador é aplicado: o contexto passado para o modelo nunca ultrapassa o limite estabelecido.

O Agente de Validação — a última linha de defesa

Antes de a resposta chegar ao usuário, o Agente de Validação a revisa. Ele verifica coerência com as fontes, detecta possíveis alucinações e garante que regras de negócio e compliance estão sendo respeitadas. Em ambientes regulados — financeiro, saúde, jurídico — esse agente não é opcional.

Agentes adicionais conforme o caso

Dependendo da complexidade do sistema, você pode adicionar um Agente de Sumarização para comprimir histórico de conversas longas, e Agentes de Domínio especializados em áreas específicas — financeiro, RH, técnico — com índices e prompts otimizados para cada contexto.

Camada 3 — Controle de Tokens: o coração da arquitetura

Este é o ponto que separa quem conhece RAG de quem colocou RAG em produção. O custo de um sistema baseado em modelos de linguagem é diretamente proporcional ao número de tokens consumidos. Sem controle, o custo é imprevisível e cresce sem relação com o valor entregue.

Budget de tokens por camada

A primeira decisão é definir quanto cada parte do sistema pode consumir. O system prompt reserva uma cota fixa. A pergunta do usuário ocupa uma parte variável. O contexto recuperado tem um limite máximo calculado dinamicamente. O Orquestrador gerencia esse orçamento e garante que nenhuma chamada ao modelo ultrapasse os limites definidos.

Seleção inteligente de chunks

O agente de recuperação pode trazer 20 chunks relevantes do OpenSearch, mas você não passa todos para o modelo. Você seleciona apenas os de maior score de relevância até atingir o limite de tokens disponível. Os outros são descartados antes de chegar ao modelo. Isso economiza tokens sem comprometer a qualidade, desde que a seleção seja bem feita.

Cache semântico — o maior alavancador de economia

O cache tradicional funciona por igualdade exata: a mesma pergunta recebe a mesma resposta sem chamar o modelo. O problema é que perguntas semanticamente idênticas raramente são escritas da mesma forma.

O cache semântico resolve isso com vetores. Quando uma pergunta chega, você a transforma em vetor e compara com os vetores das perguntas já cacheadas no ElastiCache com Redis. Se a similaridade for superior a um threshold — tipicamente entre 0.92 e 0.95 — você considera equivalente e retorna a resposta cacheada sem consumir nenhum token do modelo.

O threshold é um parâmetro que você calibra com o tempo baseado nos dados reais do seu sistema. Muito alto e o cache raramente acerta. Muito baixo e você retorna respostas incorretas para perguntas diferentes. Em ambientes corporativos com perguntas repetitivas, o cache semântico pode eliminar 30 a 40% das chamadas ao modelo.

O cache semântico fica antes de qualquer agente no fluxo. O Orquestrador consulta o Redis primeiro. Se houver hit, a resposta é devolvida imediatamente. Se não houver, o fluxo segue normalmente e ao final a nova pergunta e resposta são gravadas no Redis para as próximas chamadas.

Compressão de contexto

Antes de passar os chunks para o modelo, você pode comprimi-los sem perder o significado essencial. Técnicas de compressão de prompt — como o LLMLingua — conseguem reduzir o contexto em até quatro vezes mantendo a precisão das respostas. Isso é especialmente útil quando os documentos são longos e técnicos.

Sumarização de histórico de conversa

Em fluxos conversacionais, o histórico cresce a cada turno. Sem controle, você passa o histórico completo em cada chamada, e o custo cresce linearmente com a conversa. A solução é manter um resumo compacto e atualizado da conversa ao invés do histórico bruto. O Agente de Sumarização faz essa compressão periodicamente, mantendo o contexto relevante sem inflar o consumo de tokens.

Rastreamento granular por agente e por sessão

Cada chamada ao modelo deve registrar no DynamoDB: qual agente chamou, quantos tokens de entrada e saída foram usados, o custo estimado e o identificador da sessão. Isso permite análise de custo por usuário, por feature, por tipo de pergunta e por agente — essencial para identificar onde está o desperdício e onde otimizar.

Camada 4 — Acesso a Múltiplas Fontes de Dados

Em cenários corporativos, a resposta frequentemente exige informações de sistemas diferentes. Um funcionário perguntando se é elegível a um bônus, por exemplo, pode exigir dados do sistema financeiro e do sistema de RH ao mesmo tempo.

Action Groups e Lambdas especializadas

O Bedrock Agents permite configurar Action Groups que mapeiam intenções a funções Lambda específicas. Cada Lambda é responsável por acessar uma fonte de dados diferente — banco relacional via query SQL, API REST de um sistema legado, ou qualquer outro sistema de registro.

A chave aqui é minimização de dados: as Lambdas não devolvem o dado bruto completo para o modelo. Elas processam e devolvem apenas o que é necessário para responder a pergunta. Ao invés de passar o salário exato do funcionário, você passa uma classificação — elegível ou não elegível. O modelo recebe o insumo necessário sem ter acesso a informação sensível além do necessário.

Segurança em três camadas

A segurança em sistemas multi-agente com acesso a dados sensíveis precisa ser pensada em profundidade, não em um único ponto.

Na camada de infraestrutura, as Lambdas que acessam sistemas internos rodam dentro de uma VPC privada sem acesso à internet. As credenciais ficam no Secrets Manager, nunca em variáveis de ambiente. O acesso é controlado por IAM roles com privilégio mínimo — cada Lambda só pode acessar exatamente o que precisa.

Na camada do modelo, o Bedrock Guardrails atua em dois momentos: no input, bloqueando perguntas que tentam extrair dados sensíveis diretamente; e no output, detectando e mascarando informações como CPF, número de conta, dados pessoais antes de a resposta chegar ao usuário. Você configura políticas de PII e o Bedrock as aplica automaticamente.

Na camada de auditoria, o CloudTrail registra toda chamada feita a sistemas externos, criando uma trilha completa de quem perguntou o quê, quando, e quais sistemas foram consultados. Em ambientes regulados, isso não é opcional.

Camada 5 — Orquestração dos Fluxos

Para conectar os agentes e gerenciar fluxos complexos com retry, paralelismo e tratamento de erros, você tem duas opções principais na AWS.

AWS Step Functions

O Step Functions é a escolha para fluxos com lógica complexa. Você define estados, transições e condições de forma declarativa. Se a pergunta é simples, o fluxo vai direto para síntese. Se é complexa, passa por recuperação, validação e síntese em sequência, com retry automático em caso de falha. O histórico de cada execução fica visível no console, o que facilita muito o diagnóstico de problemas em produção.

Bedrock Agents

O Bedrock Agents oferece orquestração nativa com memória e integração direta com Action Groups e bases de conhecimento. É mais rápido de implementar e ideal para MVPs ou equipes menores. A contrapartida é menos transparência sobre o que acontece internamente — o que dificulta o controle fino de tokens e o diagnóstico de problemas de custo.

Para sistemas com SLAs definidos de custo e performance, a combinação de Lambda + Step Functions + Bedrock SDK direto oferece mais controle, mesmo exigindo mais esforço de construção.

Camada 6 — Observabilidade e Diagnóstico de Problemas

Em produção, se você não consegue ver o que está acontecendo, você não consegue otimizar — e quando algo quebra, você não consegue encontrar a causa.

AWS X-Ray para tracing distribuído

O X-Ray instrumenta cada chamada entre os componentes do sistema e monta um mapa visual do fluxo de cada requisição. Você consegue ver quanto tempo cada agente levou, onde está o gargalo, qual etapa falhou e em qual contexto. Quando o custo aumenta inexplicavelmente, o X-Ray é onde você começa: compare traces do período normal com traces do período problemático para identificar o que mudou.

CloudWatch para métricas e alertas

Além dos logs, você configura métricas customizadas no CloudWatch para tokens de entrada e saída por agente, latência por etapa e taxa de cache hit. Com essas métricas, você cria alarmes: se o custo diário ultrapassar um threshold, um SNS dispara um alerta e pode acionar throttling automático. Se a latência P99 ultrapassar dez segundos, a Lambda escala horizontalmente.

Cost Explorer e Cost Anomaly Detection

O Cost Explorer com filtragem por tag de agente permite ver exatamente onde o custo está sendo gerado. O Cost Anomaly Detection monitora o padrão de gasto e avisa automaticamente quando há desvios — essencial para pegar bugs que causam loops de chamadas ao modelo antes que o custo exploda.

O processo de investigação de anomalias de custo

Quando o custo aumenta sem explicação óbvia, o processo de investigação tem três passos em sequência. Primeiro o Cost Explorer, para isolar em qual agente ou modelo o custo está crescendo. Depois o X-Ray, para comparar os traces do período normal com os do período anômalo e identificar se o número de chamadas aumentou ou se as chamadas ficaram mais caras. Por fim o CloudWatch, para determinar se o problema está no input — contexto inflado — ou no output — respostas muito longas.

As causas mais comuns de custo inexplicado são: cache semântico parou de funcionar por alguma atualização ou falha no Redis; um loop entre agentes causado por um bug que faz o orquestrador chamar o mesmo agente múltiplas vezes; histórico de conversa crescendo sem controle porque a sumarização parou; ou chunks que ficaram maiores depois de uma mudança inadvertida no pipeline de ingestão.

Stack Completa Recomendada

Consolidando todas as camadas, a stack de referência para um sistema RAG multi-agente em produção na AWS fica assim:

Ingestão: S3 para armazenamento, Lambda ou Fargate para processamento, Bedrock Titan Embeddings para vetorização, OpenSearch Serverless para indexação vetorial, DynamoDB para metadados de chunks.

Cache: ElastiCache com Redis para cache semântico, consultado antes de qualquer agente.

Orquestração: API Gateway para exposição e rate limiting, Lambda Orchestrator para roteamento e controle de budget, Step Functions para fluxos complexos com retry e paralelismo.

Agentes: Lambda individuais por agente (Recuperação, Síntese, Validação, Sumarização) consumindo Bedrock SDK diretamente.

Acesso a dados: Action Groups do Bedrock Agents mapeando para Lambdas especializadas dentro de VPC privada, com credenciais no Secrets Manager e acesso controlado por IAM.

Segurança: Bedrock Guardrails para PII e controle de conteúdo, CloudTrail para auditoria de acesso a sistemas.

Observabilidade: X-Ray para tracing distribuído, CloudWatch com métricas customizadas de tokens e custo, Cost Explorer com tags por agente, Cost Anomaly Detection para alertas proativos.

Considerações Finais

Arquitetar RAG em produção é fundamentalmente diferente de construir um protótipo funcional. O protótipo responde perguntas. A arquitetura de produção responde perguntas de forma confiável, com custo previsível, com segurança auditável, e com capacidade de escalar sem surpresas.

Os três princípios que regem essa arquitetura são separação de responsabilidades — cada agente faz exatamente uma coisa bem feita; controle de custo como cidadão de primeira classe — tokens são o principal insumo e precisam ser gerenciados com a mesma seriedade que qualquer outro recurso de infraestrutura; e observabilidade desde o início — você não consegue otimizar o que não consegue medir.

A combinação desses princípios com os serviços certos da AWS produz um sistema que não apenas funciona, mas que você consegue operar, entender e evoluir com confiança ao longo do tempo.

Tem dúvidas sobre alguma camada específica ou quer aprofundar algum dos conceitos? Deixa nos comentários.

DEV Community: Lincoln Romais

# RAG em 2026: Do Básico ao Agêntico — Guia Prático com Python

O problema que o RAG resolve

Anatomia de um pipeline RAG básico

1. Chunking — quebrando documentos em pedaços

2. Embeddings — transformando texto em vetores

3. Indexação — armazenando os vetores

4. Retrieval — buscando o que é relevante

5. Geração — juntando tudo

Por que RAG simples falha (e como consertar)

Solução 1: Busca híbrida (vetorial + lexical)

Solução 2: Reranking

Solução 3: HyDE (Hypothetical Document Embeddings)

As tendências de 2026

RAG Agêntico

GraphRAG

RAG auto-corretivo

Segurança e governança

E para documentos gigantes? (livros, relatórios, corpus enormes)

RAPTOR — árvore de resumos recursivos

RAG hierárquico em 2 estágios — documento primeiro, chunk depois

Parent-Child Retrieval — busca precisa, contexto generoso

GraphRAG e MegaRAG — quando a resposta exige conectar pontos

Qual técnica escolher?

Conclusão

Construindo um Índice Estatístico para Prever o Campeão da Copa 2026

O Problema: por que não usar só a tabela de pontos?

As 5 Dimensões do Índice

Por que esses pesos?

O Código

Os Dados de Entrada

Calculando e Ordenando

Os Resultados

Lendo os números

O Que o Modelo Não Captura

Como Você Pode Melhorar Esse Modelo

Conclusão

Código Completo

# Criei um assistente que me manda os papers do dia traduzidos no Telegram

O que o projeto faz

Pré-requisitos

Estrutura do projeto

O código

config.py

Buscando os papers

Traduzindo com Ollama

Enviando pro Telegram

Juntando tudo no main()

Setup em 5 minutos

Por que rodar o LLM localmente?

Automatizando com cron

Possíveis melhorias

Código completo

# Arquitetando RAG Multi-Agente em Produção na AWS — Do Conceito à Operação

Por que RAG simples não é suficiente em produção?

Conceitos Fundamentais — Antes de Começar

A Visão Geral da Arquitetura

Camada 1 — Ingestão e Indexação de Documentos

O pipeline de ingestão

Por que o chunking mal feito é a raiz de muitos problemas

Camada 2 — Os Agentes e seus Papéis

O Orquestrador — o gerente da operação

O Agente de Recuperação — só busca, nada mais

O Agente de Síntese — quem fala com o modelo

O Agente de Validação — a última linha de defesa

Agentes adicionais conforme o caso

Camada 3 — Controle de Tokens: o coração da arquitetura

Budget de tokens por camada

Seleção inteligente de chunks

Cache semântico — o maior alavancador de economia

Compressão de contexto

Sumarização de histórico de conversa

Rastreamento granular por agente e por sessão

Camada 4 — Acesso a Múltiplas Fontes de Dados

Action Groups e Lambdas especializadas

Segurança em três camadas

Camada 5 — Orquestração dos Fluxos

AWS Step Functions

Bedrock Agents

Camada 6 — Observabilidade e Diagnóstico de Problemas

`config.py`

Juntando tudo no `main()`