OpenSearchCon 2026: Por que razão os agentes de IA precisam de mais do que uma base de dados vetorial

A OpenSearchCon North America 2026 realiza-se quando a “pesquisa” se está a tornar um problema muito maior do que encontrar documentos semelhantes. Os agentes de IA precisam de recuperar evidências, preservar contexto útil, chamar ferramentas e explicar o que aconteceu quando uma tarefa corre mal.

Uma base de dados vetorial resolve parte desse problema. Um agente sério também precisa de recuperação exata, metadados, atualidade, memória, rastreios de execução e permissões. A camada de dados de IA emergente parece menos “embeddings numa base de dados” e mais pesquisa + memória + observabilidade.

A OpenSearchCon 2026 mostra no que a pesquisa se está a tornar

A OpenSearchCon North America 2026 realiza-se de 22 a 24 de setembro em San Jose, na Califórnia.

A agenda continua a incluir relevância, Lucene, operações de clusters e observabilidade tradicional, mas grande parte da discussão de 2026 abrange agora RAG, recuperação híbrida, desempenho vetorial, MCP e observabilidade de agentes de IA.

Essa direção está alinhada com o roteiro de 2026 do projeto, que considera os agentes de IA uma nova classe de utilizador de pesquisa e inclui contexto agêntico, memória, encaminhamento de ferramentas e MCP.

A mudança importante não é o facto de a OpenSearch ter adicionado funcionalidades de IA.

A pesquisa está a tornar-se uma infraestrutura para sistemas que recuperam informação e depois atuam sobre ela.

Um agente de IA sério precisa de dois históricos pesquisáveis

A maioria dos tutoriais sobre RAG centra-se numa questão:

O que deve o modelo saber?

Os agentes de longa duração introduzem outra questão:

O que fez realmente o agente?

A primeira melhora as respostas. A segunda torna o sistema diagnosticável.

Isto é importante porque uma mensagem final de conversação pode ocultar um fluxo de trabalho falhado. Um agente pode afirmar que uma tarefa está concluída, mesmo que tenha recuperado o contexto errado, selecionado a ferramenta errada ou nunca tenha executado a ação esperada.

A OpenSearchCon tem uma sessão dedicada precisamente a este problema: Watching AI Workers: OpenSearch Observability for OpenClaw and Hermes-agent.

O caso de falha descrito é importante porque a solução não foi um melhor registo de conversação. Foi telemetria operacional: invocações do modelo, recuperação de contexto e chamadas de ferramentas representadas como rastreios.

Um agente cria dois tipos de histórico pesquisável: aquilo que sabia e aquilo que fez.

Muitas falhas de RAG acontecem antes de o LLM ver seja o que for

Quando uma resposta RAG está errada, substituir o modelo de linguagem é uma reação óbvia. Mas essa pode ser a camada errada para corrigir.

A sessão da OpenSearchCon Corrija a sua recuperação, corrija o seu RAG apresenta diretamente este argumento: muitas falhas aparentes de geração têm origem na camada de recuperação, que decide que evidências chegam sequer ao modelo.

A regra de depuração é simples:

o modelo não pode raciocinar sobre evidências que a recuperação nunca colocou no seu contexto.

O RAG em produção também precisa de resultados atuais, e não apenas semanticamente semelhantes. Um documento para a versão 2.0 de um software pode estar muito próximo, no espaço de embeddings, da versão 4.0 e, ainda assim, fornecer ao agente o procedimento errado.

Os metadados úteis para a recuperação podem, portanto, incluir:

• versão,
• data de publicação,
• produto ou ambiente,
• estado do documento,
• autoridade da fonte,
• e permissões de acesso.

A qualidade da recuperação é a relevância no contexto correto.

A pesquisa por palavras-chave não perdeu para a pesquisa vetorial

O crescimento da pesquisa vetorial incentivou uma narrativa simples: a pesquisa por palavras-chave era antiga e os embeddings eram a substituição.

A recuperação técnica torna essa distinção muito menos clara.

Uma consulta como Erro 802 do CUDA na RTX 5090 contém significado semântico e também tokens exatos que não devem desaparecer numa similaridade aproximada.

É por isso que a OpenSearchCon continua a dar ênfase à recuperação híbrida. A dificuldade não está apenas em executar pesquisas por palavras-chave e vetoriais em conjunto; está em decidir como as respetivas pontuações devem ser normalizadas, ordenadas e combinadas.

A escolha já não é entre palavras-chave e vetores. É determinar quanta exatidão e significado semântico cada consulta exige.

A pesquisa vetorial tem o seu próprio orçamento de memória

As discussões sobre hardware de IA local começam normalmente pela RAM e VRAM do modelo. O RAG introduz outro consumidor de memória: a recuperação.

Nas sessões sobre pesquisa vetorial da OpenSearchCon, fala-se cada vez mais de memória em grafos, compressão, recall, débito e latência P99 em conjunto. Em escalas de embeddings maiores, a memória torna-se parte da arquitetura de pesquisa, e não apenas um detalhe de implementação.

A implicação prática é simples:

um servidor RAG local precisa de um orçamento de recuperação, além de um orçamento para o modelo.

«Esta máquina consegue carregar o meu modelo?» já não é uma orientação de dimensionamento suficiente quando o mesmo anfitrião também incorpora documentos, mantém índices e executa agentes.

Os agentes transformam a observabilidade numa parte da camada de dados

A observabilidade tradicional pergunta se um pedido falhou, que serviço estava lento e o que dizem os registos.

Um agente acrescenta chamadas ao modelo, decisões de recuperação e execução de ferramentas.

O OpenSearch Agent Traces atual utiliza convenções do OpenTelemetry para representar operações de agentes, LLM, recuperação, incorporação e ferramentas.

Isto torna possíveis perguntas muito mais específicas:

• A recuperação demorou demasiado tempo?
• O agente chamou repetidamente a mesma ferramenta?
• Um ciclo de novas tentativas aumentou a utilização de tokens?
• O modelo fez uma escolha válida, mas a ferramenta falhou?
• Uma nova versão do agente alterou o comportamento de execução?

A memória persistente cria um problema relacionado com o ciclo de vida. Manter tudo para sempre aumenta a utilização do armazenamento e permite que o contexto antigo permaneça pesquisável; eliminar de forma demasiado agressiva faz com que o agente tenha de reaprender repetidamente informações úteis.

Isto significa que a memória do agente precisa de regras explícitas para:

• o que se torna memória de longo prazo,
• o que pode expirar,
• o que pertence a um histórico de auditoria,
• e o que deve deixar de influenciar recuperações futuras.

A memória do agente não é apenas uma funcionalidade de recuperação. É uma política do ciclo de vida dos dados.

A pesquisa torna-se um limite de segurança quando quem pesquisa pode agir

Uma pessoa que pesquise cópias de segurança falhadas e um agente que pesquise cópias de segurança falhadas criam riscos diferentes.

O utilizador pode inspecionar o resultado. O agente pode utilizar o resultado para chamar outra ferramenta.

O OpenSearch inclui um servidor MCP que pode disponibilizar pesquisa, PPL, SQL e informações do cluster a agentes compatíveis.

Quando a recuperação passa a fazer parte de um ciclo de ações, as permissões de pesquisa passam a fazer parte dos limites de capacidade do agente.

Três casos reais de IA autoalojada que mostram por que razão a camada de dados é importante

A distinção entre o modelo, a recuperação e o estado do agente torna-se mais fácil de compreender em sistemas reais autoalojados.

1. Um espaço de trabalho RAG privado tem uma carga de trabalho de dados separada da inferência

O AnythingLLM é um exemplo útil. A aplicação pode gerir documentos, embeddings e a recuperação, enquanto o modelo de linguagem é executado localmente, remotamente ou através de uma API.

O guia atual de hardware para RAG do AnythingLLM torna a separação explícita: a ingestão de documentos, os embeddings locais, os dados vetoriais e o armazenamento persistente criam os seus próprios requisitos de recursos, enquanto a inferência de modelos locais deve ser dimensionada separadamente.

É exatamente este o erro que a discussão da OpenSearchCon ajuda a esclarecer.

Um sistema RAG não tem um único requisito de hardware. Tem, pelo menos, dois:

• a carga de trabalho do modelo,
• e a carga de trabalho de conhecimento/recuperação.

À medida que a coleção de documentos cresce, a ingestão, a indexação, os metadados e as cópias de segurança podem tornar-se estrangulamentos, mesmo quando o modelo de linguagem não muda.

2. Um agente ativo 24 horas por dia, 7 dias por semana, cria um estado de execução persistente

O OpenClaw ilustra o outro lado do modelo dos Dois Índices.

Um gateway OpenClaw autoalojado pode manter conversas persistentes, executar chamadas de ferramentas, realizar tarefas agendadas, receber webhooks e coordenar vários fluxos de trabalho de agentes. O guia para um gateway privado de agentes de IA trata o agente como um serviço sempre ativo, e não como uma janela de conversa que desaparece quando se fecha um portátil.

Essa persistência cria questões operacionais que uma conversa normal não cria:

• Que ferramenta foi chamada pelo agente?
• Que tarefa falhou durante a noite?
• Quantas vezes foi repetida uma operação?
• Que contexto foi carregado antes da decisão?
• O agente comunicou que a operação foi concluída sem a concluir?

É por isso que a sessão de observabilidade OpenClaw/Hermes da OpenSearchCon é particularmente relevante para agentes autoalojados. Assim que o agente trabalha sem supervisão, o histórico de execução torna-se infraestrutura, não uma curiosidade de depuração.

3. A memória persistente torna-se parte da arquitetura do espaço de trabalho

Um fluxo de trabalho real do Hermes demonstra um terceiro padrão. Em vez de colocar tudo numa base de dados opaca do agente, um espaço de trabalho privado para agentes de IA pode separar o runtime do agente, a memória Markdown legível por humanos, o histórico do Git, os canais de comunicação e o armazenamento sempre ativo.

Essa arquitetura é útil porque a «memória do agente» não é necessariamente um único repositório de vetores monolítico.

Diferentes tipos de informação podem justificar regras de ciclo de vida diferentes:

A melhor arquitetura de memória pode não consistir em «guardar tudo para sempre». Consiste em decidir que tipo de estado representa realmente cada informação.

Quando é que alojar o OpenSearch por conta própria faz realmente sentido?

Esses exemplos não significam que todos os servidores de IA locais devam instalar o OpenSearch.

O próprio OpenSearch é uma infraestrutura com estado. Executá-lo implica gerir índices, memória JVM, armazenamento persistente, instantâneos, retenção, permissões, atualizações e recuperação.

O OpenSearch Observability Stack local pode ser executado através do Docker Compose, mas os pré-requisitos oficiais de instalação já exigem pelo menos 8 GB de RAM disponível.

Antes de o implementar, pergunte:

1. Que quantidade de dados estou realmente a indexar?
2. Preciso de combinar recuperação por palavras-chave e semântica?
3. A mesma plataforma de dados também irá armazenar registos, rastreios ou o estado dos agentes?
4. Estou disposto a operar outro serviço com estado?

A pergunta útil não é «consigo executar o OpenSearch em casa?». É «a minha pilha de IA tem complexidade de recuperação e observabilidade suficiente para o justificar?»

Dimensione o servidor de IA para mais do que o modelo

Quando a IA local ultrapassa uma interface de conversação, o planeamento do hardware muda.

Um servidor RAG ou de agentes de maiores dimensões pode precisar de recursos para:

• inferência do modelo,
• embeddings,
• índices de pesquisa,
• armazenamento de documentos,
• bases de dados,
• ambientes de execução de agentes,
• registos e rastreios,
• e cópias de segurança.

O atual guia de dimensionamento de hardware do Open WebUI ilustra o mesmo padrão: a memória da aplicação, o processamento de documentos, os embeddings e o armazenamento RAG são independentes dos requisitos de memória ou VRAM, muito maiores, de um LLM local.

Para cargas de trabalho que necessitam realmente de mais memória do sistema, conjuntos de dados distribuídos por várias unidades e inferência por GPU compatível numa só máquina, um servidor de IA local com muito armazenamento pode consolidar essas camadas. No entanto, o hardware deve ser escolhido com base no modelo, no corpus de vetores, no período de retenção e na simultaneidade reais, e não no rótulo «servidor de IA».

Mais GPU não resolve um índice de pesquisa subdimensionado, e mais armazenamento não resolve uma memória de modelo insuficiente.

O servidor de IA precisa de uma camada de dados, não apenas de um modelo maior

As discussões sobre IA local centram-se naturalmente nos modelos, porque os modelos dominam as tabelas de referência.

Mas os sistemas RAG e de agentes de longa duração acumulam gradualmente outra camada de infraestrutura:

• documentos e metadados,
• índices lexicais e vetoriais,
• memória do agente,
• integrações de ferramentas,
• registos e rastreios de execução,
• permissões,
• e políticas de retenção.

O modelo gera a resposta. A camada de dados determina que evidências lhe chegam, que contexto permanece e se alguém consegue explicar o que aconteceu quando o agente se comporta de forma inesperada.

Esta é a história mais abrangente por detrás do OpenSearchCon 2026.

Os agentes de IA estão a transformar a pesquisa de uma funcionalidade em infraestrutura.

Por isso, um agente sério precisa de respostas fiáveis para duas perguntas persistentes:

1. O que deve este agente saber neste momento?
2. O que fez realmente este agente?

Uma base de dados vetorial pode ajudar com a primeira. A infraestrutura de agentes em produção acaba por ter de responder a ambas.

Perguntas frequentes

Quando se realiza o OpenSearchCon North America 2026?

O OpenSearchCon North America 2026 realiza-se de 22 a 24 de setembro, em San Jose, Califórnia. A conferência aborda pesquisa de código aberto, observabilidade, recuperação vetorial, RAG e IA agêntica.

O OpenSearch é uma base de dados vetorial?

O OpenSearch pode armazenar e pesquisar embeddings vetoriais, mas é mais abrangente do que uma base de dados vetorial dedicada. Também suporta pesquisa lexical, recuperação híbrida, filtragem por metadados, análise e cargas de trabalho de observabilidade.

O OpenSearch é adequado para RAG?

Pode ser uma excelente opção quando o RAG requer pesquisa híbrida, filtragem por metadados e versões, avaliação da relevância ou uma grande coleção de documentos em constante mudança. Os sistemas RAG pessoais mais pequenos podem ser mais fáceis de operar com uma infraestrutura mais leve.

O que é a pesquisa híbrida no OpenSearch?

A pesquisa híbrida combina sinais lexicais, como BM25, com recuperação semântica ou vetorial. É especialmente útil quando uma consulta contém identificadores técnicos exatos e uma intenção mais ampla em linguagem natural.

O OpenSearch consegue monitorizar agentes de IA?

Sim. O OpenSearch Agent Traces utiliza telemetria baseada em OpenTelemetry para expor chamadas aos modelos, recuperações e utilização de ferramentas, juntamente com informações sobre latência e tokens.

O OpenSearch suporta MCP?

Sim. O OpenSearch fornece capacidades MCP que permitem aos agentes compatíveis aceder à pesquisa, PPL, SQL e a outras ferramentas de dados. As permissões continuam a ser importantes, porque as informações recuperadas podem alimentar diretamente as ações dos agentes.

Preciso do OpenSearch para um servidor RAG local?

Não necessariamente. Uma pequena coleção pessoal de documentos pode normalmente utilizar uma infraestrutura de recuperação mais simples. O OpenSearch torna-se mais apelativo quando o sistema precisa de índices maiores e em evolução, pesquisa híbrida, conhecimento partilhado, observabilidade ou várias cargas de trabalho de agentes.

De quanta RAM precisa o OpenSearch autoalojado?

Os requisitos dependem do tamanho do índice, das dimensões dos vetores, da carga de consultas e das políticas de retenção. A pilha local atual de observabilidade do OpenSearch indica pelo menos 8 GB de RAM disponível como pré-requisito, enquanto cargas de trabalho maiores de vetores e telemetria podem exigir substancialmente mais.