Vicco LabsVicco Labs
Construindo um assistente conversacional em produção · Parte 1
Redis Stack como camada de retrieval para LLM

Você já usou Redis além de cache simples?

Cache miss virou consulta lenta na API, p95 subiu, custo de LLM subiu. Foi onde descobri o Redis Stack como camada de retrieval e análise determinística pra aplicações com LLM.

4 MAR 2026·3 min de leitura·Redis / RAG / LLM / Cache
REDIS

Até pouco tempo atrás, pra mim era exatamente isso: GET/SET, TTL, expiração e vida que segue.

Depois comecei a usar como cache persistente das matrizes de embeddings de um roteador semântico (via RedisVectorStore), guardando chaves por fingerprint + intent, com NPZ comprimido. Depois acrescentei Redis Checkpointer para LangGraph, garantindo persistência de estado entre runs e threads. Funcionava bem… mas era só o começo da minha aproximação com o Redis.

Quando um assistente conversacional (com LLM) começa a depender de APIs pesadas e bases grandes (catálogo de produtos, histórico de preferências, eventos…), a conta chega rápido:

cache miss → consulta lenta na API → p95 sobe → UX sofre → custo de LLM sobe = uma experiência ruim para o usuário.

Foi aí que descobri o Redis Stack como uma camada de retrieval e análise determinística para aplicações com LLM. O que mais me surpreendeu foi ver que ele entrega, de graça (ou quase), coisas que antes eu achava que precisavam de um vector DB separado ou Elasticsearch:

  • busca fuzzy nativa (tolerar "teniz" → "tênis", "cdbi ipca" → "CDB IPCA");
  • busca por vetores (embeddings) para similaridade semântica;
  • filtros estruturados poderosos (tags, ranges numéricos, full-text);
  • análise em tempo real (métricas, eventos, séries temporais).

Tudo rodando dentro do mesmo Redis, sem montar uma infraestrutura paralela.

Onde isso pode se encaixar

  • e-commerce: produtos similares + faixa de preço + estoque disponível;
  • suporte ao cliente: achar tickets ou FAQs relevantes mesmo com erro de digitação;
  • logística: detectar picos de atraso e correlacionar com rotas/eventos em tempo real;
  • mídia/conteúdo: recomendação híbrida (semântica + tags + recência).

Mas não existe almoço grátis

Os trade-offs aparecem rápido:

  • RAM e índices custam caro (principalmente quando você joga vetores + indexação pesada);
  • tuning e modelagem NoSQL exigem disciplina (fat, slim, híbrido - cada um tem seu preço);
  • ingestão e updates podem virar gargalo se o volume for alto e a indexação não for bem pensada.

Mesmo assim, quando a dor principal é latência + custo de LLM + dependência excessiva do modelo, vale a pena analisar caso a caso. No meu caso, mudou completamente o jogo.

Semana que vem vou falar sobre outro assunto que casou muito bem com o Redis Stack: modelagem de dados Fat vs Slim vs Híbrido, como cada modelo impacta custo, performance e flexibilidade (e qual usei no final pra resolver o meu problema).

Já conhecia o Redis Stack (RedisJSON + RediSearch + Vector)? Como usou e qual foi o maior trade-off que enfrentou?