Introdução
A implementação de sistemas de Inteligência Artificial em ambientes corporativos regulados apresenta desafios únicos que vão muito além da precisão técnica. Quando cada decisão do modelo pode ser auditada por órgãos reguladores meses depois, a arquitetura tradicional de Retrieval Augmented Generation (RAG) – que envia todos os casos para o modelo de linguagem – revela suas limitações. Uma nova abordagem, baseada em arquitetura em cascata, está demonstrando como é possível reduzir os custos de inferência em até 6 vezes, mantendo ou até melhorando a qualidade das decisões em sistemas críticos.
Esta transformação é especialmente relevante para o mercado brasileiro, onde setores como financeiro, saúde e jurídico operam sob rigorosas regulamentações. A experiência de Vineet Vijay, engenheiro líder em IA que passou o último ano construindo sistemas RAG para ambientes empresariais regulados, oferece insights valiosos sobre como repensar a arquitetura desses sistemas quando o custo de um erro vai muito além de uma resposta incorreta de chatbot.
Os custos ocultos de enviar tudo para o LLM
A abordagem convencional de sistemas RAG tem um apelo óbvio: simplicidade arquitetural. Ao rotear todos os casos através de um Large Language Model, reduz-se a complexidade do sistema e acelera-se o desenvolvimento inicial. O modelo, em teoria, consegue lidar com casos não previstos e nuances contextuais. No entanto, essa aparente vantagem esconde três problemas fundamentais que só se revelam quando o sistema entra em produção real.
O primeiro é a auditabilidade. Em setores regulados no Brasil, como o bancário sob supervisão do Banco Central ou o de saúde sob vigilância da ANVISA, simplesmente dizer que ‘o modelo decidiu baseado no contexto recuperado’ não é uma resposta aceitável. Auditores e oficiais de compliance precisam conseguir reconstruir o caminho decisório sem depender de reexecutar a inferência – algo impossível de garantir com modelos probabilísticos que podem gerar respostas diferentes para o mesmo input.
O segundo problema é o custo em escala. Quando um sistema processa dezenas de milhares de transações diárias – realidade comum em grandes bancos ou seguradoras brasileiras – e cada uma gera uma chamada para o LLM com múltiplos documentos no contexto, os custos de inferência e a latência escalam linearmente com o volume. Isso contrasta drasticamente com lógica determinística baseada em regras, cujo custo marginal é praticamente zero.
O terceiro, e talvez mais sutil, é a deriva do modelo em casos simples. LLMs são excelentes para julgamentos nuançados e complexos, mas demonstram inconsistência surpreendente em decisões que deveriam ser determinísticas. Um caso claro de correspondência estruturada contra critérios conhecidos não deveria depender do ‘humor’ probabilístico de um modelo de linguagem.
A arquitetura em cascata: uma nova filosofia de design
A solução proposta por Vijay inverte completamente a lógica tradicional: em vez de tratar o LLM como linha de frente, ele se torna o caminho de escalação. Esta arquitetura em cascata divide o processamento em três estágios distintos, cada um otimizado para um tipo específico de decisão.
O primeiro estágio é puramente determinístico. Correspondências exatas, comparações de campos estruturados e qualquer caso com regra clara são resolvidos aqui, sem nenhuma chamada para modelo. Este estágio, surpreendentemente, consegue processar mais da metade do volume em muitos casos, dependendo da qualidade dos dados. Cada decisão é completamente explicável porque é baseada em lookup direto, não em inferência probabilística.
O segundo estágio é onde o componente de retrieval do RAG realmente brilha. Para os casos que sobrevivem ao primeiro filtro – e ‘sobreviver’ aqui significa não ter sido claramente resolvido – constrói-se uma camada de recuperação que busca evidências específicas relevantes para a ambiguidade: decisões anteriores de revisores em casos similares, documentos contextuais que explicam conflitos aparentes, ou precedentes históricos que esclarecem casos extremos.
É crucial entender que neste design, a etapa de retrieval importa mais que a de generation. Se o sistema recupera o contexto errado, mesmo o melhor modelo de linguagem do mundo produzirá uma resposta confiante, bem fundamentada e completamente errada.
O terceiro estágio é finalmente a chamada para o LLM, mas agora ele vê apenas o resíduo que os estágios anteriores não conseguiram resolver – tipicamente apenas 10 a 15% do volume total. Esta única mudança arquitetural foi responsável pela redução de 6x nos custos de inferência observada por Vijay, ao mesmo tempo em que melhorou a consistência nas decisões determinísticas para níveis praticamente perfeitos.
Prompts para riscos assimétricos: uma lição crítica
Quando um caso finalmente chega ao estágio do LLM, a maioria das equipes comete um erro sutil mas crítico: usar prompts neutros como ‘Avalie se este caso deve ser aprovado ou sinalizado’. Esta abordagem ignora uma realidade fundamental dos sistemas de alto risco: o custo dos dois tipos de erro raramente é simétrico.
Considere o contexto de uma instituição financeira brasileira avaliando transações suspeitas. Deixar passar uma transação genuinamente problemática pode resultar em lavagem de dinheiro, com consequências regulatórias severas. Por outro lado, sinalizar incorretamente uma transação legítima causa atraso e requer tempo de um analista para revisão. Estes dois resultados claramente não têm o mesmo custo, mas um prompt neutro trata ambos como equivalentes.
A solução é construir prompts que explicitam esta assimetria de risco. Isso significa instruir o modelo a tratar incerteza como razão para escalar, não para aprovar; fornecer exemplos calibrados de ambos os tipos de erro com suas consequências detalhadas; e solicitar um score de confiança junto com a classificação. Este score se torna um segundo ponto de cascata: qualquer resultado abaixo de determinado threshold vai para revisão humana, independentemente da classificação sugerida pelo modelo.
Avaliação e feedback: fechando o ciclo de aprendizado
As métricas tradicionais de avaliação de sistemas RAG não foram projetadas para este caso de uso e aplicá-las sem adaptação criará uma falsa sensação de segurança. Vijay destaca várias adaptações críticas necessárias.
Primeiro, a qualidade do retrieval precisa ser medida separadamente da precisão da classificação final. Um sistema pode ter excelentes scores de ranking na recuperação e ainda assim tomar decisões ruins se a etapa de generation interpretar mal as evidências. É essencial rastrear estas métricas independentemente.
Segundo, o conjunto de avaliação precisa sobreamostrar deliberadamente os casos que chegam ao terceiro estágio, já que é onde o julgamento do sistema realmente é testado. Se o conjunto de testes espelha a distribuição de produção, será dominado pelos casos determinísticos que a cascata já resolve bem, criando um ponto cego exatamente para as falhas mais importantes.
Terceiro, quando se usa ‘LLM as judge’ para avaliação, o prompt do juiz deve codificar a mesma assimetria de risco do prompt de produção. Um juiz que trata ambos os tipos de erro igualmente favorecerá sistematicamente o trade-off errado durante o ajuste do sistema.
Por fim, é fundamental construir um loop de feedback dos resultados confirmados de volta para o corpus de retrieval. Quando um revisor humano reverte uma decisão do modelo, esse caso e sua resolução correta devem se tornar contexto recuperável para casos similares futuros. Sem isso, o sistema continua cometendo a mesma categoria de erro indefinidamente.
Implicações para o mercado brasileiro
A experiência de Vijay tem implicações profundas para empresas brasileiras implementando IA em ambientes regulados. Bancos processando milhões de transações diárias, seguradoras avaliando sinistros, empresas de saúde analisando prontuários – todos podem se beneficiar desta abordagem arquitetural.
O modelo em cascata é particularmente relevante considerando o ambiente regulatório brasileiro. Com o avanço de regulamentações como a LGPD e frameworks específicos de cada setor, a capacidade de explicar e auditar decisões automatizadas não é apenas desejável – é obrigatória. A arquitetura proposta oferece um caminho para compliance sem sacrificar os benefícios da IA moderna.
Além disso, a redução de custos em 6x tem impacto direto na viabilidade econômica desses projetos. Com o real desvalorizado tornando os custos de API em dólar ainda mais onerosos para empresas brasileiras, otimizações desta magnitude podem ser a diferença entre um projeto piloto e uma implementação em escala de produção.
Conclusão
A lição mais ampla da experiência de Vijay transcende os detalhes técnicos da implementação RAG. Em domínios onde respostas erradas têm consequências reais – e isso inclui a maior parte das aplicações empresariais críticas – o trabalho de engenharia mais valioso não é fazer o modelo lidar bem com tudo, mas decidir o que nunca deveria ter sido trabalho do modelo em primeiro lugar.
A arquitetura em cascata não é uma solução alternativa para limitações dos LLMs. É o que um sistema RAG maduro parece quando você realmente teve que defender suas decisões para alguém cujo trabalho é encontrar falhas em sua lógica. Para equipes brasileiras construindo sistemas de IA para qualquer domínio regulado ou de alto risco, a pergunta que vale a pena fazer antes de escrever o primeiro prompt não é ‘Como faço o modelo lidar bem com isso?’, mas sim ‘Quais partes desta decisão nunca deveriam ter sido responsabilidade do modelo?’
Esta mudança de mentalidade – de usar IA para tudo para usar IA onde ela realmente agrega valor único – pode ser a chave para construir sistemas que não apenas impressionam em demonstrações, mas sobrevivem ao escrutínio do mundo real dos negócios regulados.
Fonte original: Este artigo foi adaptado e traduzido a partir da matéria “Cutting RAG inference costs 6x starts with deciding what never reaches the LLM” publicada em VentureBeat, disponível em https://venturebeat.com/orchestration/cutting-rag-inference-costs-6x-starts-with-deciding-what-never-reaches-the-llm.
