.webp){kind=small}
A maioria das equipes que desenvolvem sistemas de geração aumentada por recuperação (RAG) para classificação de alto risco faz a mesma aposta arquitetônica: direcionar todos os casos ambíguos diretamente para o modelo de linguagem e confiar que o contexto recuperado resolverá o problema. Isso funciona bem em uma demonstração. O problema surge no momento em que o sistema precisa sobreviver a uma auditoria, a um órgão regulador ou a um responsável pela conformidade que questione o motivo de uma decisão específica ter sido tomada seis meses atrás. Passei o último ano construindo sistemas de classificação baseados em RAG em ambientes empresariais regulamentados, onde o custo de uma resposta errada não é uma resposta ruim de um chatbot. Uma decisão precisa resistir ao escrutínio muito tempo depois de o modelo tê-la produzido.
Esse ambiente impõe uma filosofia de design diferente da que a maioria dos conteúdos de engenharia de IA pressupõe. Eis o que muda quando você não pode se dar ao luxo de ser probabilístico em tudo e como uma arquitetura em cascata resolve isso. O apelo de rotear tudo por meio de um grande modelo de linguagem (LLM) é óbvio: menos componentes móveis, iteração mais rápida, o modelo lida com casos extremos imprevistos. O problema surge mais tarde, em três pontos. Primeiro, auditabilidade. "O modelo decidiu com base no contexto recuperado" não é uma resposta aceitável. É necessário um caminho de decisão que um humano possa reconstruir sem executar a inferência novamente e esperar o mesmo resultado. Segundo, custo em escala.
Se o seu sistema processa dezenas de milhares de casos por dia e cada um deles chega a uma chamada de LLM com vários documentos recuperados em contexto, a sua conta de inferência e a latência escalam com o volume de uma forma que a lógica baseada em regras não escala. Terceiro, e menos discutido, desvio do modelo nos casos fáceis. Os LLMs são excelentes em julgamentos sutis. Eles são inconsistentes, de maneiras difíceis de detectar, em casos que deveriam ter uma resposta determinística. Uma correspondência estruturada clara com critérios conhecidos nunca deve depender do humor de um modelo de linguagem. A solução: Pare de tratar o LLM como a linha de frente e comece a tratá-lo como o caminho de escalonamento. Na prática, isso significa um pipeline de três estágios. O primeiro estágio é determinístico.
Correspondências exatas, comparações de campos estruturados e qualquer coisa com uma regra clara são resolvidas aqui sem nenhuma chamada de modelo. Esta etapa deve resolver a maior parte do volume, frequentemente mais da metade, dependendo da qualidade dos seus dados, e cada decisão é totalmente explicável porque é uma consulta, não uma inferência. A segunda etapa é onde a recuperação mostra sua importância. Para os casos que sobrevivem à primeira etapa — e quero dizer sobreviver no sentido de não terem sido claramente resolvidos — você constrói uma camada de recuperação que extrai as evidências específicas relevantes para a ambiguidade: decisões anteriores de revisores em casos semelhantes, documentos contextuais que explicam um conflito aparente ou precedentes históricos que esclarecem um caso extremo. A etapa de recuperação é mais importante do que a etapa de geração aqui.
Se você recuperar o contexto errado, mesmo o melhor modelo de linguagem do mundo produzirá uma resposta errada, confiante e bem fundamentada. A terceira etapa é a chamada do LLM (Modelo de Linguagem Local), e ela deve ver apenas os resíduos que as etapas um e dois não conseguiram resolver. Esta é a parte que as pessoas pulam quando projetam sua primeira versão, e é a alavanca mais importante tanto para custo quanto para qualidade. Em um sistema no qual trabalhei, encaminhar apenas os 10 a 15% dos casos genuinamente ambíguos para o LLM reduziu o custo de inferência em aproximadamente 6 vezes em comparação com uma linha de base totalmente baseada no LLM, ao mesmo tempo que melhorou a consistência na maioria determinística, tornando-a praticamente perfeita.
Assim que um caso chega ao estágio LLM, a maioria das equipes adota um prompt neutro: "Avalie se este caso deve ser aprovado ou sinalizado". Essa abordagem é inadequada para classificações de alto risco, porque o custo dos dois tipos de erro não é simétrico. Ignorar algo que realmente precisava de atenção pode causar danos reais posteriormente. Sinalizar incorretamente algo que estava correto custa tempo do revisor e causa atraso. Esses dois resultados raramente são igualmente ruins, mas um prompt neutro pede ao modelo que os trate como se fossem. Um prompt de risco assimétrico torna essa compensação explícita para o modelo, em vez de deixá-lo adivinhar sua tolerância ao risco.
Concretamente, isso significa instruir o modelo a tratar a incerteza como um motivo para intensificar o alerta, em vez de simplesmente eliminá-la, fornecendo exemplos calibrados de ambos os tipos de erro com suas consequências detalhadas e solicitando uma pontuação de confiança juntamente com a classificação, em vez de uma resposta binária. A pontuação de confiança se torna seu segundo ponto de cascata: qualquer resultado abaixo de um determinado limite é encaminhado a um revisor humano em vez de ser resolvido automaticamente, independentemente da classificação do modelo. Isso parece um pequeno detalhe de engenharia de prompt. Na prática, é a diferença entre um sistema que reduz a carga de trabalho do revisor e um que silenciosamente aumenta o risco enquanto aparenta estar funcionando.
As métricas de avaliação RAG padrão não foram criadas pensando nesse caso de uso e usá-las sem adaptação lhe dará uma falsa sensação de confiança. Alguns ajustes que fazem a diferença. A qualidade da recuperação precisa ser medida separadamente da precisão da classificação final. Um sistema pode ter excelentes pontuações de classificação de recuperação e ainda tomar decisões finais ruins se a etapa de geração ponderar incorretamente as evidências. Monitore-as independentemente. Seu conjunto de avaliação precisa de uma sobreamostragem deliberada dos casos que chegam ao estágio três, já que é aí que o julgamento do seu sistema é realmente testado. Se o seu conjunto de avaliação espelhar a sua distribuição de produção, ele será dominado pelos casos determinísticos que sua cascata já lida bem, e você ficará cego exatamente para as falhas que mais importam.
O LLM como avaliação por juiz funciona para este domínio, mas somente se o prompt do juiz codificar o mesmo enquadramento de risco assimétrico que o seu prompt de produção. Um juiz que trata ambos os tipos de erro igualmente favorecerá sistematicamente a compensação errada quando você estiver ajustando seu sistema. Finalmente, construa um ciclo de feedback dos resultados confirmados de volta para o seu corpus de recuperação. Quando um revisor humano anula uma decisão do modelo, esse caso e sua resolução correta devem se tornar um contexto recuperável para futuros casos semelhantes. Sem isso, o tratamento de casos ambíguos pelo seu sistema nunca melhora, ele apenas continua cometendo o mesmo tipo de erro na mesma proporção.
.jpg)
