Cohere mantém 98,4% da qualidade de busca em consultas rápidas

Os sistemas RAG têm um problema de engenharia conhecido: a busca vetorial rápida reúne bem os candidatos, mas com frequência coloca no topo trechos parecidos com a pergunta pelas palavras, e não pelo sentido. Se eles forem passados direto a um modelo de linguagem, ele receberá contexto desnecessário, gastará mais tokens e terá mais chance de dar uma resposta confiante, porém errada.

A Cohere lançou o Embed 5 e o Rerank 5 na OpenRouter. O sentido prático do lançamento não está em surgirem mais dois nomes no catálogo de modelos. Agora é possível montar um pipeline de busca completo por meio de uma única API: criar um índice vetorial, encontrar candidatos, reordená-los com mais precisão e só então chamar o LLM. Contas e SDKs separados da Cohere não são necessários.

Como o trabalho é dividido

A indexação acontece uma única vez para todo o corpus de documentos. O texto é dividido em trechos, e o Embed 5 Pro transforma cada um deles em um vetor. Para os documentos, indica-se o modo search_document, e os vetores são normalizados para que a proximidade possa ser calculada com um simples produto escalar.

Quando o usuário faz uma consulta, o Embed 5 Fast atua no modo search_query. Pro e Fast usam um espaço vetorial comum, portanto não é preciso construir o índice uma segunda vez. De acordo com a Cohere, consultas feitas com o Fast sobre um índice criado pelo Pro mantiveram 98,4% da qualidade de uma configuração totalmente Pro em 40 conjuntos de dados. Se o Fast for usado tanto na indexação quanto na busca, o índice cai para 96,6%.

Imagine uma base de documentação com instruções para criar, revogar e substituir chaves de API. O usuário pergunta como trocar uma chave sem interromper o serviço. A busca vetorial encontra a instrução correta, mas ao lado dela podem aparecer páginas sobre criação de chaves, segredos de webhooks e rotação de logs. Elas são semanticamente próximas, embora não respondam à pergunta.

Por que uma segunda etapa é necessária

O Rerank 5 recebe a pergunta e cerca de 10–20 trechos encontrados, lê cada par por inteiro e devolve uma ordem mais precisa. No exemplo da Cohere, a instrução correta recebeu pontuação 0,808, enquanto dois resultados próximos, mas inúteis, não passaram do limiar de 0,3. Ao modelo de linguagem é enviada apenas uma seleção limpa de três a cinco trechos.

Essa divisão faz sentido: a busca inicial responde pela abrangência, e o reranker, pela precisão. Executar uma comparação pesada em todo o índice é caro demais, mas reler uma lista curta de candidatos é plenamente viável. Se nada restar após a filtragem, a chamada ao LLM pode ser dispensada por completo, informando com honestidade que não há resposta nos documentos.

A Cohere afirma separadamente que as pontuações do Rerank 5 são calibradas entre consultas e áreas temáticas. Isso permite usar um limiar de relevância único. Mas não convém tratar 0,3 como configuração universal: o limiar da demonstração precisa ser verificado com os seus próprios dados.

O que considerar antes da implantação

A demonstração usa NumPy como armazenamento, por isso serve para um protótipo, e não para carga de produção. Um sistema em produção exigirá pgvector, Qdrant, Pinecone, Weaviate ou outro banco de dados vetorial, controle de versões do índice e observabilidade de latência, custo e qualidade dos resultados.

O tamanho dos trechos também influencia o resultado. Trechos curtos demais perdem contexto, e os longos demais elevam o custo do reranqueamento. Os 1500 caracteres do exemplo são apenas um ponto de partida. O Rerank 5 aceita até 32 mil tokens para um par de consulta e trecho, mas um contexto permitido grande não torna trechos grandes automaticamente úteis.

O próximo passo prático é pegar algumas dezenas de perguntas reais de usuários, marcar manualmente os documentos corretos e comparar a taxa de acertos entre os cinco primeiros antes e depois do reranqueamento. Ao mesmo tempo, vale medir a latência e o custo adicionais. Se a qualidade subir de forma notável, o esquema de Pro para o índice, Fast para as consultas e Rerank para a seleção final oferece um caminho claro para acelerar o RAG sem reconstruir o sistema por completo.