System design e IA: quando, qual e como utilizar um rerank? Parte I

Uma coisa comum que percebo entre novos profissionais que trabalham com sistemas que integram IA (sejam engenheiros ou cientistas de dados) é não considerar as decisões sobre modelos e seus impactos em termos de engenharia e produto. Decisões técnicas (seja um if ou um novo gpt) tomadas sem uma análise de dados adequada, resultam em problemas no design do sistema. Atualmente trabalho com IAs no contexto jurídico, especificamente para CGU, e decisões ruins tem um impacto alto pois até um pouco de latência significa reduzir o desempenho de funcionários altamente capacitados e com uma demanda muito alta de trabalho.

Neste post, vou discutir como analisar a adoção de um rerank em um sistema de Recuperação de Respostas (RAG) sob a perspectiva de design de sistemas. Isso pode ser útil tanto para entrevistas quanto para otimizar o desempenho de sistemas que você já utiliza. As principais perguntas que abordarei são:

• As interações dos meus usuários justificam a complexidade adicional do rerank?
• Qual modelo de rerank devo utilizar?
• Como a mudança de modelo impactará o sistema? Os thresholds e fluxos permanecerão?
• O rerank está gerando mais custos, mas melhorando a experiência do usuário (UX) ?
• Está reduzindo custos e melhorando a UX ao mesmo tempo?

Levantar essas perguntas desde o início é crucial, porque tecnologias populares podem consumir recursos sem gerar o retorno esperado — ou até piorar a experiência dos usuários. Decisões de engenharia são cruciais, às vezes mais importantes do que ter acesso ao modelo mais recente com boas pontuações, e para fazer essas decisões você precisa metrificar.

O Problema do Contexto em LLMs

Em sistemas que utilizam LLMs, o contexto é um recurso caro. O aumento da quantidade de contexto processado não apenas piora a latência, mas também eleva a chance de o modelo gerar respostas incorretas ou “alucinações” (ao adotar um novo LLM busque sempre as métricas de needle-in-a-haystack). Embora a abordagem mais comum — buscar os vetores mais similares ao input do usuário com base na similaridade semântica dos embeddings — resolva boa parte dos casos, nem sempre é suficiente. Isto é, a similaridade semântica entre a pergunta de um usuário e alguns chunks não garante que esses chunks sejam úteis para responder à pergunta.

A imagem a seguir ilustra isso de forma mais clara:

Imagem extraída de https://arxiv.org/pdf/2405.19893

Agora mesmo que a similaridade semântica seja suficiente para seus usuários, você pode encontrar casos em que múltiplos chunks possuem pontuações muito próximas. Isso torna difícil escolher um corte adequado no contexto, especialmente se estiver utilizando um threshold simples. Thresholds e fluxos são decisões de negócio que impactam todo o produto. Por exemplo, você pode configurar seu sistema para redirecionar a pergunta a um humano quando nenhum chunk atinge uma similaridade superior a 0.5. Resumindo os principais problemas que surgem quando o “R” do seu RAG não está suficientemente otimizado:

• Custo: O processamento de contexto excessivo aumenta o consumo de tokens e os custos de infraestrutura.
• Latência: Contextos maiores geram tempos de resposta mais longos, o que prejudica a experiência do usuário.
• Confiabilidade: O sistema pode se tornar menos eficaz, tentando encontrar a “agulha no palheiro” sem sucesso.

O Trade-off de Acurácia vs. Performance

Em tutoriais e mesmo consultorias você pode se deparar com a seguinte solução para um sistema para reduzir todas essas dores que discutimos acima ao usar somente similaridade semântica

Um dos primeiros passos para projetar um sistema eficiente é entender problema que você está tentando resolver, considerando principalmente:

• Quem são seus usuários e como eles interagem com o sistema;
• A escala do sistema;
• O desempenho esperado;
• Os custos envolvidos.

Se você sair implementando tecnologias ou bibliotecas você pode acabar empilhando problemas.

Observabilidade e Métricas

Para monitorar o desempenho do seu sistema RAG, é essencial registrar as similaridades dos chunks utilizados no contexto, assim como dos chunks ideais que deveriam ter sido selecionados. Essa última observação só é possível se você tiver um dataset curado. Se você ainda não mantém registros dessas métricas de similaridade, o mais adequado é investir tempo na implementação desses logs, em vez de tentar aplicar um rerank sem dados para embasar suas decisões.

Supondo que você tenha um dataset curado, com perguntas e a marcação dos chunks que deveriam conter a resposta, é possível analisar os logs da aplicação para identificar os diferentes cenários que ocorrem. Dependendo do sistema, você pode observar uma mistura de casos, como os que serão apresentados a seguir.

(Os chunks com a informação necessária para responder à questão estão marcados em negrito e sublinhado.)

Vamos analisar cada caso

Case 1 (ótimo):

Retrieval:

• Similaridades de topo altas
• Similaridades de fundo baixas
• Chunks corretos estão no topo

Corte por threshold:

• O threshold é efetivo para cortar os chunks irrelevantes

Usuário:

• Recebe a resposta correta
• Baixa latência (contexto pequeno)

Custo:

• Econômico: você economizou tokens
• O usuário está satisfeito

Case 2 (bom):

Retrieval:

• Similaridades de topo altas
• Similaridades de fundo também altas
• Chunks corretos estão no topo

Corte por threshold:

• O threshold é inefetivo

Usuário:

• Provavelmente recebe a resposta correta
• O contexto grande pode causar o problema da “agulha no palheiro”
• Latência alta devido ao tamanho do contexto

Custo:

• Tokens desnecessários geraram aumento de custos
• O usuário pode estar satisfeito, mas houve ineficiência

Case 3 (ruim):

Retrieval:

• Similaridades de topo baixas
• Similaridades de fundo baixas

Corte por threshold:

• O threshold foi efetivo para cortar os chunks irrelevantes

Usuário:

• Não recebe a resposta correta
• Baixa latência (contexto pequeno)

Custo:

• Econômico: você economizou tokens
• No entanto, o usuário não está satisfeito, pois a resposta correta não foi fornecida, mesmo que estivesse disponível

Case 4 (terrível):

Retrieval:

• Similaridades de topo altas
• Similaridades de fundo baixas
• O chunk correto está mais abaixo

Corte por threshold:

• O threshold foi efetivo, mas cortou o chunk correto

Usuário:

• Recebe a resposta errada
• Baixa latência (contexto pequeno)

Custo:

• Desperdício de tokens, pois foram utilizados para retornar uma resposta incorreta
• O usuário pode assumir que a resposta está correta, o que é perigoso
• É necessário implementar mecanismos para evitar o envio de respostas erradas

A predominância de cada caso vai depender de diversas variáveis:

• Modelo de embedding usado, idioma e contexto da sua aplicação: Por exemplo, em contextos jurídicos, embeddings podem ter um desempenho inferior, gerando vetores muito próximos uns dos outros. Isso dificulta, ou até inviabiliza, o projeto de um sistema com uma regra de corte simples, como um score mínimo de similaridade.
• Tipo de usuário majoritário e base de conhecimento: Se você está indexando um FAQ e uniu corretamente tanto a pergunta quanto a resposta antes de realizar o embedding para cada item, uma busca por similaridade pode ser suficiente para atender às necessidades do usuário.
• Tipo de técnica para quebra dos textos: A maneira como você divide os textos pode impactar diretamente a precisão do sistema de retrieval, influenciando a quantidade de tokens processados.
• Complexidade da fase de retrieval: Se o seu sistema envolve etapas mais complexas, como filtragem por metadados ou técnicas como text2query, o contexto utilizado na fase de inferência do modelo pode ser pequeno o suficiente para que os ganhos de uma melhor ordenação dos chunks não justifiquem o aumento de latência e complexidade.

Quando e qual Rerank vale a pena? Thresholds duros e suaves

Agora que o problema já está claro, e você acredita que o rerank pode ser útil, surgem outras perguntas:

• Como posso inserir isso na arquitetura impactando o mínimo possível a latência?

• Como convencer os PMs a investirem mais dinheiro?

Para responder a essas perguntas, vou trazer um caso real que analisei. Eu tinha aproximadamente 100 questões de usuários com os chunks com a informação necessária marcados. Para cada questão, salvei o texto de cada chunk e a similaridade cosseno. Nessas questões, a quantidade de tokens no contexto estava, em média, em torno de 8000 tokens, e os chunks não possuíam tamanho uniforme.

A primeira coisa que podemos avaliar é o corte do contexto usando diferentes modelos de rerank. Nesse caso, utilizei três modelos: Cohere Multilingual, InRanker Base e InRanker Small. Os dois últimos são abertos e foram criados pela UNICAMP.

Para cada pergunta e seu respectivo conjunto de chunks, avaliei os scores obtidos por cada rerank. O que vamos analisar é: dado um threshold para o score do rerank, quantos porcento dos tokens que iriam para o contexto podem ser eliminados? A seguir, temos o gráfico que ilustra esses resultados.

Com tudo isso em mãos, podemos pensar de forma mais criteriosa nas decisões de engenharia e negócios.

O Cohere Multilingual é um modelo proprietário e, dependendo do seu caso de uso, pode ser mais caro do que utilizar um modelo InRanker hospedado em uma VM. No entanto, surgem os trade-offs.

Nesse caso, o Cohere apresentou um corte de contexto mais significativo. O InRanker Base, mesmo com um threshold próximo de 0.9, mal atinge a porcentagem de corte mínimo obtida com o Cohere. Como nosso dataset é curado, eu pude avaliar que com um threshold próximo de 75% temos uma boa margem de segurança para manter os chunks com a informação necessária dentro do contexto. Isso tem algumas implicações no design do sistema:

• Embora o Cohere possa ser mais caro por chamada e introduza maior latência, ele proporciona um ganho substancial no corte do contexto, com thresholds mais duros.
• Com thresholds mais duros e um contexto menor, o dinheiro extra que você pode estar gastando com o reranker da Cohere pode ser compensado por:
• Economia de tokens gastos na inferência do seu modelo.
• Redução da latência na inferência do seu modelo de linguagem.

O gráfico acima pode ser útil para orientar um time técnico, mas como ter uma visão financeira? Uma possibilidade seria traçar um mapa da porcentagem de tokens economizados com base no tamanho médio do contexto sem a regra de corte, e colorir por economia financeira, levando em consideração uma regra específica. Para simplificar, utilizei números fictícios de consumo diário de tokens e os custos de tokens por milhão do GPT-4o e do custo por chamada reranker Cohere Multilingual.

Novos insights:

• Quanto menor o contexto enviado aos LLMs, maior deve ser a porcentagem de tokens economizada por meio de algum critério de corte que você aplique no rerank.
• Mesmo que o gráfico pareça promissor, lembre-se do “Case 1”. Mesmo que o rerank gere um custo pequeno em cenários pessimistas, o aumento de latência ainda pode resultar em uma experiência desagradável para o usuário, afetando outras métricas importantes do seu negócio.

Agora você pode reavaliar seu sistema. Por exemplo, em casos onde a pergunta gera um contexto muito pequeno devido a um threshold baixo de similaridade ou à ausência de filtragem por metadados, não há motivos para aplicar um rerank. Uma alternativa seria redesenhar seu sistema nesses cenários.

Esta foi a primeira parte sobre design de sistemas envolvendo rerank e como ponderar algumas decisões. Na próxima, discutiremos métricas de qualidade para o ordenamento dos chunks.