A maioria dos comitês de seleção de IA corporativa enfrenta o mesmo problema: três propostas parecidas, três promessas parecidas e quase nenhuma clareza sobre a arquitetura por trás do agente. As propostas vão prometer integração com a base de conhecimento, respostas com fonte e redução de carga humana. Algumas serão, na prática, um chatbot com prompt longo e conteúdo colado no contexto. Poucas vão mostrar uma arquitetura RAG (Retrieval-Augmented Generation) bem desenhada — e a diferença só aparece no terceiro mês de operação, quando o time descobre que o "agente" não consegue responder sobre o produto novo porque ninguém ensinou ele.
A pergunta que o decisor B2B precisa fazer antes de assinar o contrato é: como exatamente esse fornecedor estrutura ingestão, indexação e recuperação? E como vou saber se a resposta foi inventada ou veio do meu próprio conteúdo? Esse post desce uma camada na auditoria — depois de você ter avaliado canal e UX do chatbot, agora é hora de olhar a arquitetura do conhecimento que sustenta o agente.
Principais pontos
- RAG real é arquitetura, não prompt longo: envolve pipeline de ingestão, chunking, embeddings, store vetorial e estratégia de recuperação — cada etapa tem decisão técnica que afeta qualidade da resposta.
- Fine-tuning, prompt engineering e RAG resolvem problemas diferentes: confundir os três é o primeiro sinal de que o fornecedor não entende o que está vendendo.
- Reconfiguração manual a cada novo documento é red flag: agente sério extrai configuração e contexto dos próprios documentos do cliente, sem operador remontando prompt toda semana.
- Alucinação não é bug isolado, é sintoma de recuperação ruim: se o agente inventa resposta, na maior parte dos casos o problema está antes do LLM — no que foi recuperado, ou no que não foi.
- Multi-behavior num único agente exige roteamento por intenção: vender, agendar, suportar e cobrar no mesmo canal sem confundir contexto pede arquitetura de skills, não três bots disfarçados.
- Confidence score e fallback humano são parte do design, não enfeite — agente que não sabe quando passar pra pessoa é agente que vai derrubar NPS.
Quando o comitê está avaliando proposta de IA conversacional, a tentação é olhar UI bonita e fluxo demo. Mas o que vai sustentar (ou afundar) o projeto em produção é a camada que ninguém mostra na apresentação. É exatamente nesse tipo de avaliação técnica que parceiros como a Vertis Tech entram em consideração — não pra vender mais um agente, mas pra ajudar a entender o que perguntar.
O que RAG faz e o que ele não faz
Retrieval-Augmented Generation é uma arquitetura em que o modelo de linguagem (LLM) não responde só com o que aprendeu no treinamento — ele consulta uma base externa do cliente, recupera os trechos mais relevantes pra pergunta, e usa esse contexto recuperado pra gerar a resposta. A vantagem é direta: o agente responde sobre o catálogo da sua empresa, sua política de garantia, seu manual interno — coisas que o modelo base não conhece e não deveria conhecer.
O que RAG não faz: ele não substitui fine-tuning quando o problema é estilo de escrita ou domínio terminológico muito específico, e não substitui prompt engineering quando o problema é forma de raciocínio. Os três são complementares. Fornecedor que vende RAG como solução pra qualquer problema, ou que confunde "subi um PDF no system prompt" com RAG, está vendendo outra coisa.
A pergunta técnica concreta pro comitê é: o que acontece quando eu adiciono um documento novo na base de conhecimento? Se a resposta envolve "a gente reconfigura o prompt", "atualiza a base e refazemos o deploy" ou "isso entra no roadmap", o fornecedor não tem ingestão automatizada. Se a resposta envolve "o documento é ingerido, chunked, embedado e indexado automaticamente; em prazo curto o agente responde sobre o conteúdo dele com citação", aí tem pipeline RAG funcional.
As cinco etapas da arquitetura — e o que perguntar em cada uma
Não é necessário dominar todos os termos técnicos das próximas seções pra tomar a decisão. O ponto é saber quais perguntas fazer e perceber quando o fornecedor responde com clareza ou foge do assunto.
1. Ingestão
O que entra na base? PDF, planilha, Notion, site público, FAQ, transcrição de chamada, contrato? Como o fornecedor lida com formato bagunçado, OCR de scan, tabela complexa?
Pergunta pro comitê: "me mostre como vocês ingerem um PDF com tabela e quanto tempo leva pra esse conteúdo ficar respondível pelo agente". Resposta vaga ou "depende do caso" é sinal de pipeline imaturo.
2. Chunking
O documento ingerido precisa ser quebrado em pedaços (chunks) que vão pro índice vetorial. Chunk muito grande dilui relevância na recuperação. Chunk muito pequeno perde contexto. Como o fornecedor decide o tamanho? Tem chunking semântico (que respeita parágrafo, seção, frase) ou só corta a cada N caracteres?
Pergunta pro comitê: "qual estratégia de chunking vocês usam e por quê?". Resposta tipo "padrão da biblioteca" sem reflexão é sinal de que ninguém pensou no problema.
3. Embeddings
Cada chunk vira um vetor numérico via modelo de embeddings (text-embedding-3, BGE, jina, voyage, e por aí vai). A escolha do modelo afeta qualidade da recuperação e custo de operação. Modelo proprietário americano? Modelo open-source rodando em GPU própria? Qual o trade-off LGPD se os embeddings de documentos confidenciais saem da rede da empresa?
Pergunta pro comitê: "qual modelo de embedding vocês usam, onde ele roda, e que dado meu sai da minha infra?". Resposta evasiva aqui costuma esconder problema de governança.
4. Recuperação
Dada a pergunta do usuário, como o sistema recupera os chunks mais relevantes? Busca puramente vetorial (cosine similarity)? Hybrid search (vetorial + BM25)? Re-ranking com modelo cross-encoder? Filtragem por metadata (departamento, data, tipo de documento)?
Pergunta pro comitê: "como vocês evitam que o agente responda com chunk irrelevante mas semanticamente parecido?". Fornecedor que nunca pensou em hybrid search ou re-ranking provavelmente vai ter precisão de recuperação baixa em base grande.
5. Geração e fallback
Os chunks recuperados entram no contexto do LLM com a pergunta. Como o prompt é montado? Tem citação de fonte na resposta? Tem confidence score? O que acontece quando a recuperação volta vazia ou com chunks de baixa similaridade?
Pergunta pro comitê: "o que o agente faz quando ele não tem certeza?". Resposta correta é alguma combinação de "responde indicando incerteza", "passa pra humano", "pede mais contexto pro usuário". Resposta tipo "ele sempre responde" é vermelha — esse agente vai alucinar.
RAG vs fine-tuning vs prompt engineering — quando usar cada um
Decisor B2B raramente precisa entender a matemática, mas precisa entender a decisão:
- Prompt engineering resolve forma. Como o agente deve se apresentar, que tom usar, que estrutura de resposta seguir, quando escalar pra humano. É leve, rápido e essencial — mas não ensina nada novo pro modelo.
- RAG resolve conhecimento. Como o agente sabe sobre a sua empresa, seu produto, seu cliente, sua política. É a base pra qualquer agente corporativo que precisa responder com informação proprietária e atualizada.
- Fine-tuning resolve domínio profundo. Como o agente raciocina sobre um vocabulário muito específico (jurídico, médico, financeiro técnico) ou um estilo de escrita altamente padronizado. É pesado, demorado, e raramente necessário se você não tentou RAG bem feito antes.
A regra prática: se o fornecedor está oferecendo fine-tuning como primeira solução pra "ensinar a IA sobre sua empresa", desconfie. Na maior parte dos cenários corporativos, RAG bem arquitetado entrega resultado melhor, mais rápido de iterar e mais fácil de manter atualizado.
Multi-behavior num único agente
Empresa séria não quer três chatbots — um pra vendas, um pra agendamento, um pra suporte. Quer um ponto de contato que entenda o que o usuário precisa e roteie internamente. Isso é multi-behavior, e exige arquitetura de skills, intents ou tools — não três sistemas colados.
Pergunta pro comitê: "como o agente sabe se a mensagem é dúvida de produto, pedido de agendamento ou reclamação?". Resposta sofisticada envolve classificação de intenção, ferramentas (tools) que o agente decide invocar, e contexto compartilhado entre turnos. Resposta tipo "tem um menu de opções no início" é fluxograma disfarçado de IA.
Red flags na proposta
Resumindo o que separa fornecedor de IA sério de agente maquiado:
- Documentação técnica vaga sobre o pipeline RAG (ou inexistente).
- Reconfiguração manual a cada novo documento ingerido.
- Sem citação de fonte na resposta — agente diz coisas mas não mostra de onde tirou.
- Sem confidence score nem fallback humano configurável.
- Demos que sempre rodam em cima da mesma base estática.
- Promessa de "treinar a IA com seus dados" sem distinguir RAG de fine-tuning.
- Sem resposta clara sobre onde os embeddings rodam e que dado sai da rede.
Como a Vertis Tech ajuda em projetos de agente de IA corporativo
A Vertis Tech é fábrica de software brasileira focada em CRM, automação e IA aplicada. Cada projeto é dimensionado conforme volume de conhecimento, criticidade da operação, integrações necessárias e exigências de governança do cliente. A depender do escopo, a implantação pode contemplar:
- Discovery técnico orientado a outcome, pra entender se o cliente realmente precisa de RAG, fine-tuning ou apenas uma estratégia melhor de prompt e ferramentas, antes de codar qualquer coisa.
- Pipeline de RAG com ingestão, chunking e indexação da base de conhecimento, reduzindo dependência de reconfiguração manual a cada documento novo.
- Stack auditável e versionável, com banco relacional, store vetorial e LLMs escolhidos conforme nível de governança e custo exigidos pelo projeto.
- Agente multi-intenção desenhado pra vendas, agendamento, suporte e cobrança no mesmo canal, com roteamento por intenção e fallback humano por confiança.
- Governança de dados considerada desde o desenho, com atenção a LGPD, segregação de dados por cliente e rastreabilidade das respostas.
- Documentação técnica acessível ao comitê de TI, pra que a arquitetura seja auditável antes, durante e depois da implantação.
Perguntas frequentes
RAG funciona pra base de conhecimento pequena, com menos de 100 documentos?
Sim, e até é mais fácil de acertar precisão. A vantagem do RAG não é só escala — é manter o conhecimento atualizado sem refazer prompt. Mesmo com 30 documentos, RAG bem feito ganha de prompt longo porque permite ingestão contínua e citação de fonte.
Quanto tempo leva pra colocar um agente RAG em produção?
Depende muito do contexto, mas como referência inicial: discovery e setup de pipeline costuma levar algumas semanas, e o primeiro agente respondendo com qualidade aceitável costuma sair em alguns meses, não em alguns dias. Fornecedor prometendo "em uma semana no ar" provavelmente está vendendo template, não solução.
Preciso de GPU própria pra rodar RAG?
Na maior parte dos casos, não — embeddings podem ser feitos via API e o LLM também. Faz sentido pensar em infra própria quando o volume é alto, quando o requisito de LGPD é mais rígido (dado sensível que não pode sair do país), ou quando o custo de API se torna relevante na operação.
Como sei se o agente está alucinando depois que ele já está em produção?
Boa arquitetura tem observabilidade: log de consulta, chunks recuperados, prompt final montado, resposta gerada e feedback do usuário. Sem isso, alucinação só é detectada quando o cliente final reclama — o que costuma ser tarde demais.
Vale mais usar uma plataforma pronta de agente ou construir sob medida?
Depende do problema. Plataforma pronta resolve casos simples e padronizados rápido. Sob medida faz sentido quando o agente precisa integrar com sistemas internos específicos, lidar com dado proprietário sensível, ou diferenciar a empresa via experiência conversacional única. A pergunta certa não é "qual é melhor", é "o que meu caso de uso pede".
Agente de IA corporativo bem feito é arquitetura, não demo. A diferença entre o fornecedor que vai entregar resultado em produção e o que vai gerar dor de cabeça em três meses está na camada que ninguém mostra na apresentação inicial — ingestão, chunking, embeddings, recuperação, fallback. Vale o trabalho de descer essa camada antes de assinar o contrato.
Quer auditar se a arquitetura RAG do fornecedor que você está avaliando é real ou apenas um chatbot maquiado?
