Construindo seu próprio AI Chat Assistant — quando off-the-shelf vira teto baixo

Felipe Vieira 22 de maio de 2026 🇧🇷 Português 11 min read

Construindo seu próprio AI Chat Assistant — quando off-the-shelf vira teto baixo — cover

ChatGPT, Claude e Gemini resolvem bem tarefas genéricas e conversas avulsas. Mas no momento que seu assistente vira customer-facing, a equação inteira muda.

Seus usuários precisam de um assistente que conheça seu produto, suas políticas, e o histórico deles com você. Esse conhecimento mora nos seus sistemas — não nos dados de treino do modelo. Dá pra injetar em runtime, claro, mas dado proprietário vem com restrições reais: geralmente é grande demais pra caber numa context window, sensível demais pra mandar pra API de terceiro, e dinâmico demais pra ficar parado num prompt estático.

Além dos dados, você não consegue configurar comportamento por completo, não integra além de uma aba do browser, e o custo escala com cada conversa. Por isso times sérios constroem o próprio assistente — e este post cobre como.

Por que construir o seu próprio?

Quando o custo, controle, ou compliance importam, off-the-shelf vira teto baixo. Cinco razões pra justificar o investimento:

Off-the-shelf é ótimo pra uso pessoal e protótipo interno. Construir o seu é pra quando o assistente é o produto, ou uma feature central.

O que você vai construir

Diagrama de arquitetura mostrando as quatro camadas do assistente: context engineering, generation engine, persistent memory, e SSE streaming

Um assistente conversacional estilo ChatGPT que você controla por completo: seu próprio system prompt, sua personalidade, suas regras. Requisitos:

O que esse sistema NÃO faz: não recupera documentos externos (sem RAG), não tem expertise de domínio além do que o modelo já sabe, e não toma ações nem chama tools. É puramente conversacional. RAG e tool calling ficam pra posts futuros — aqui o foco é dominar o esqueleto.

Pra esse build usamos uma API de modelo (OpenAI, Anthropic, ou similar). O provedor cuida de GPU, scaling e otimização de inferência — o ponto de partida certo pra quase todo time. Quando você cresce além da API, migra pra modelo open-source self-hosted servido com vLLM, llama.cpp, ou SGLang.

Parte 1 — O que acontece quando você manda uma mensagem

Quando você chama uma API de modelo, muita coisa rola entre a request e o primeiro token aparecer na tela. Você nunca precisa tocar numa GPU, mas entender o que acontece ajuda a raciocinar sobre latência, custo e trade-offs.

De texto pra tokens

Frase sendo dividida em chunks de tokens coloridos, cada um mapeado pra um ID numérico, e a palavra strawberry quebrada em três pedaços mostrando por que LLMs não contam letras

Antes do modelo processar sua mensagem, ele converte texto em números. Modelos não leem palavras — eles trabalham com tokens, chunks pequenos de texto mapeados pra IDs numéricos. Um token pode ser uma palavra inteira ("the"), parte de uma palavra ("un", "believ", "able"), ou um único caractere.

O processo de quebrar texto em tokens chama tokenization. Existem várias formas:

O algoritmo mais comum é Byte Pair Encoding (BPE). BPE começa com caracteres individuais e iterativamente funde os pares mais frequentes num único token. Palavras comuns como "the" ou "and" viram tokens únicos. Palavras raras ou longas são quebradas em pedaços significativos. "Unbelievable" pode virar três tokens: "un" + "believ" + "able". O vocabulário fica gerenciável (tipicamente 30.000 a 100.000 tokens), e palavras novas são processadas via decomposição em sub-pedaços conhecidos. Ferramentas pra inspecionar tokens: OpenAI Tokenizer e tiktoken (lib Python).

É por isso que LLMs erram tarefas que pra humano são triviais. Pergunte "quantos R's tem em strawberry?" — o modelo pode errar porque nunca vê letras individuais. "Strawberry" pode ser tokenizado como "str" + "aw" + "berry", então o modelo literalmente não consegue contar os R's porque eles estão espalhados em fronteiras de token. Reverter palavra, contar caracteres, etc — tudo difícil pelo mesmo motivo.

Tokenization tem consequência prática direta pra construir chat assistant:

Como o modelo chegou aqui: do pretraining ao chat

O modelo que você chama passou por um pipeline multi-estágio pra virar assistente de chat, e cada estágio tem consequência direta no produto que você está construindo.

Pretraining é onde o modelo aprende linguagem. Treinado num corpus massivo (livros, websites, código, papers), aprende a prever o próximo token dado todos os anteriores. Auto-supervisionado — ninguém rotula os dados. O modelo lê trilhões de tokens e aprende padrões. Pretraining é o que dá ao modelo conhecimento geral, gramática, capacidade de escrever código — e a tendência de produzir texto plausível, verdadeiro ou não. Quando seu assistente afirma um fato errado com confiança, esse comportamento vem do pretraining: o modelo aprendeu a produzir continuações prováveis, não verdades verificadas.

Post-training é o que transforma o preditor de texto em assistente de chat. O modelo pretreinado é bom em completar texto, mas não sabe seguir instruções, manter conversa, ou recusar pedidos prejudiciais. Conserta em duas etapas:

  1. SFT (Supervised Fine-Tuning): treina o modelo em exemplos curados de boas conversas — usuário faz pergunta, resposta humana mostra qual seria o ideal. Ensina o formato e estilo de assistente útil.
  2. RLHF (Reinforcement Learning from Human Feedback): avaliadores humanos comparam pares de respostas e escolhem a melhor. O modelo aprende dessas preferências, ficando mais útil, mais preciso, e menos propenso a output prejudicial.

É por isso que o mesmo base model pode parecer completamente diferente dependendo de como foi pós-treinado — e também por que system prompts funcionam: o modelo foi especificamente treinado pra seguir instruções nível-developer durante o post-training. Para uma visão profunda, veja o paper InstructGPT e o post da Hugging Face sobre RLHF.

Scaling laws — por que existem modelos mini e nano

Scaling laws governam a relação entre tamanho do modelo, dado de treino e performance. Pesquisa notável (Kaplan et al. na OpenAI e o paper Chinchilla da DeepMind) mostrou que performance melhora previsivelmente quando você aumenta parâmetros e tokens de treino, seguindo curvas power-law.

É por isso que a indústria continua construindo modelos maiores: dobrar o tamanho produz ganhos previsíveis e mensuráveis. Pra você como builder, scaling laws explicam o trade-off custo-capacidade que enfrenta:

O tiered pricing dos provedores (frontier / mini / nano) mapeia direto na curva de scaling. Entender isso permite tomar a decisão de model routing que cobrimos a seguir.

Parte 2 — Model routing: o truque que corta 60-80% do custo

Router de circuito dividindo queries em dois caminhos — modelo pequeno barato e modelo grande caro — com medidores de custo mostrando diferença dramática

A maioria das queries de um chat assistant é trivial: "qual o horário de funcionamento?", "como cancelo minha assinatura?", "oi tudo bem?". Mandar tudo isso pro frontier model é desperdício caro.

Model routing classifica cada query antes da inferência e roteia pro modelo apropriado:

Implementações práticas: RouteLLM da LMSys, OpenRouter auto-routing, ou um classifier simples (regex + embedding similarity) custom. Em volumes acima de 10K conversas/dia, economia típica é 60–80% sem perda perceptível de qualidade.

Parte 3 — Context engineering

O system prompt é onde sua personalidade, regras, formato de output e guardrails vivem. Mas context engineering é mais que isso: é como você empacota tudo que o modelo precisa pra responder bem.

Componentes que entram em toda request:

  1. System prompt: identidade, regras, formato (ex: "Você é o assistente do produto X. Sempre responda em PT-BR. Recuse perguntas fora do escopo do produto.").
  2. Few-shot examples: 2-5 exemplos de bom comportamento. Reduz hallucination dramaticamente sem precisar fine-tuning.
  3. Conversation history: turnos anteriores da sessão. Compactar agressivamente quando passar de N turnos (técnica: multi-turn compaction — resumir os 10 turnos mais antigos num resumo curto).
  4. User context: nome, plano, perfil, idioma — injetado dinamicamente.
  5. Persistent memory: preferências e fatos extraídos de sessões anteriores (técnica abordada em post anterior sobre memória de agents).
  6. Mensagem atual do usuário: a query crua, idealmente sanitizada contra prompt injection.

Order matters. System prompt no topo, então few-shot, depois user context, depois history, e por último a mensagem atual. Modelos prestam mais atenção no início e no fim — o famoso efeito lost in the middle (Liu et al., 2023).

Parte 4 — Output controls: temperature, top-p, top-k

Esses três parâmetros controlam quão criativo ou determinístico o modelo é:

Combine: temperature controla a "temperatura" do sorteio, top-p/top-k limitam o pool. Default razoável pra chat assistant geral: temperature=0.7, top-p=0.9. Para extração estruturada (JSON output): temperature=0, JSON mode habilitado.

Parte 5 — Como saber que funciona: evals e LLM-as-Judge

"Funcionou pra mim no terminal" não vale em produção. Você precisa de:

Ferramentas que automatizam evals: LangSmith, Phoenix da Arize, OpenAI Evals, Braintrust e promptfoo (CLI open-source).

Stack recomendada pra começar amanhã

Conclusão

Construir o próprio assistente não é decisão de "AI hype" — é decisão de produto. Quando privacidade, controle de comportamento, integração no fluxo e custo em escala importam, off-the-shelf vira teto baixo. A maior parte da complexidade não está no modelo (a API resolve), está em context engineering, model routing, evals contínuos e guardrails.

O esqueleto que cobrimos aqui é genérico — RAG, tool calling, multi-agent, voice, são camadas que você empilha em cima. Mas se você não acerta o esqueleto, nenhuma camada extra salva. Comece simples, instrumente desde o dia 1, e itere com base em eval — não em "achismo".