Cohere Embed 4: como migrar um índice multimodal sem misturar espaços vetoriais

A unidade de análise é o modelo junto com o índice

Trocar o modelo de embeddings não equivale a substituir apenas uma peça intercambiável do mecanismo de busca. O modelo transforma documentos e consultas em vetores; o índice organiza esses vetores e permite compará-los. A recuperação depende de ambas as partes compartilharem uma representação compatível e de a consulta ser processada com uma configuração adequada. Por isso, ao avaliar o Cohere Embed 4 — identificado como `embed-v4.0` na documentação do fornecedor —, a unidade de análise deve ser o conjunto formado pelo modelo, a configuração de entrada, os vetores, o índice e a regra de comparação.

A consequência operacional é importante: não se deve incorporar, sem validação, ao mesmo espaço de busca vetores produzidos por um modelo anterior e vetores gerados pelo Embed 4. O fato de ambos produzirem vetores com o mesmo comprimento não demonstra que as coordenadas tenham o mesmo significado. Também não basta mudar a dimensão de saída no sistema de armazenamento. Se o modelo for substituído, o procedimento prudente é gerar novamente as representações dos documentos e das consultas com uma configuração compatível e manter o índice anterior disponível durante a avaliação.

Este guia propõe um método para decidir se vale a pena migrar, adicionar uma rota multimodal ou manter a solução atual. Não parte do pressuposto de que o Embed 4 seja superior ao sistema existente: as especificações descrevem capacidades declaradas e a documentação de uso, mas o efeito sobre a relevância depende do corpus, das consultas e da implementação. A análise concentra-se na recuperação; não compara modelos generativos nem atribui qualidade à resposta final de um sistema RAG.

O que a Cohere declara sobre o Embed 4

A Cohere apresenta o Embed 4 como um modelo multimodal capaz de gerar representações a partir de texto, imagens e entradas mistas. Entre os exemplos documentados de entradas mistas estão páginas de PDF que incluem texto e imagens. Isso permite considerar casos que não se limitam à busca de texto extraído de arquivos: uma página pode contribuir com informações textuais e visuais para a representação. No entanto, o suporte a uma modalidade não garante que todos os documentos dessa modalidade sejam interpretados corretamente, nem que a recuperação melhore numa tarefa específica.

As informações publicadas pela Cohere declaram dimensões de saída de 256, 512, 1024 e 1536, além de um contexto de 128k. São especificações do fornecedor, não uma promessa de que todos os canais de acesso aceitem exatamente os mesmos formatos, limites ou parâmetros. A API da Cohere, o Amazon Bedrock e o Oracle Cloud Infrastructure, por exemplo, são interfaces diferentes. Antes de desenhar uma migração, é preciso verificar a documentação do serviço que será realmente utilizado e registrar o nome exato do modelo, a região ou o serviço, quando aplicável, os limites vigentes e o formato das solicitações.

A dimensão faz parte do contrato entre o gerador de embeddings e o índice: determina o tamanho de cada vetor e, portanto, afeta a compatibilidade, o armazenamento e as operações de busca. Uma dimensão menor pode reduzir o volume de dados associado aos vetores, mas não se deve inferir que a qualidade da recuperação será preservada. Da mesma forma, uma dimensão maior não garante melhor desempenho no corpus. É necessário comparar as alternativas usando as mesmas consultas, os mesmos julgamentos de relevância e as mesmas condições operacionais.

O Embed 4 tem um parâmetro `input_type` associado à finalidade da entrada. Na documentação de embeddings da Cohere, `search_document` identifica entradas de documentos e `search_query`, consultas de busca. Num fluxo de recuperação, usar o tipo correspondente em cada lado faz parte da configuração que deve permanecer coerente entre a indexação e a consulta. Não convém tratar esse parâmetro como uma etiqueta descritiva dispensável: o processo deve respeitar os valores aceitos pelo endpoint escolhido e verificar como se aplicam a texto, imagens ou entradas mistas.

Por que não convém misturar vetores de modelos diferentes

Um vetor é uma representação numérica produzida por um modelo sob determinada configuração. A busca vetorial costuma ordenar candidatos usando uma medida de similaridade ou distância. Para que essa comparação faça sentido, os vetores de documentos e consultas precisam ser gerados de modo compatível com o método usado para recuperá-los. Uma dimensão idêntica apenas indica que as listas numéricas têm o mesmo comprimento; não estabelece que suas posições sejam comparáveis entre dois modelos.

A métrica de distância também faz parte da configuração do índice. Ao migrar, não se deve mudar a métrica de comparação sem verificar o efeito nos resultados. A documentação da Cohere descreve medidas de similaridade para embeddings, mas a escolha concreta depende da integração e do índice. A equipe deve registrar qual medida o sistema atual usa, qual será usada pelo candidato e se o mecanismo de busca normaliza os vetores ou aplica outras transformações.

A separação deve ser mantida tanto no armazenamento quanto na avaliação. Identificar cada vetor com o modelo, a dimensão, a modalidade processada e a versão da configuração permite reconstruir como ele foi produzido. Se os índices antigo e novo forem mantidos em paralelo, cada consulta deverá gerar o vetor correspondente a cada índice. Não se deve enviar a um índice de um modelo uma consulta transformada em embedding por outro apenas para simplificar o encaminhamento, salvo se um teste deliberado demonstrar que essa combinação é válida para o caso de uso.

Um erro comum é avaliar apenas a resposta gerada por uma aplicação RAG. Uma resposta convincente pode esconder que os documentos relevantes não apareceram entre os primeiros resultados; também pode depender do conhecimento prévio do modelo gerador. Para avaliar a camada de embeddings, é preciso inspecionar o que o mecanismo de busca recuperou e confrontar os resultados com julgamentos de relevância independentes do texto que o modelo generativo produzir depois.

Migrar documentos e consultas com rastreabilidade

Uma migração controlada começa com um inventário do índice vigente. Registre o modelo e seu identificador, a dimensão, o método de distância, a estratégia de divisão em fragmentos, as transformações anteriores, o tipo de entrada, os idiomas cobertos e os metadados preservados. No caso multimodal, anote também quais modalidades são extraídas ou enviadas, como as páginas são identificadas e que relação existe entre o vetor e o fragmento original. Sem esse inventário, uma diferença nos resultados pode decorrer do modelo, da divisão em fragmentos ou de uma mudança inadvertida no pré-processamento.

Em seguida, construa o índice candidato como uma nova versão. Gere novamente os embeddings dos documentos, mantenha chaves estáveis que relacionem cada vetor à sua fonte e registre qualquer item que não tenha sido processado. Não sobrescreva as representações antigas durante o teste. Para cada execução, guarde a combinação de modelo, dimensão, tipo de entrada, data e versão do processo. Assim, será possível reproduzir uma comparação e detectar se dois testes aparentemente iguais usaram configurações diferentes.

A consulta deve seguir uma rota equivalente. O serviço de busca identifica qual índice está sendo consultado e usa o tipo de entrada previsto para as consultas. Durante um período de coexistência, a mesma consulta lógica pode ser enviada à rota antiga e à candidata, mas cada uma deve gerar seu próprio embedding. Se houver uma etapa posterior que combine resultados, seus efeitos devem ser medidos separadamente; caso contrário, será difícil atribuir uma melhoria ou regressão ao Embed 4.

Para incorporar imagens e páginas de PDF, documente o tratamento dos arquivos no canal específico. A documentação da Cohere apresenta um fluxo de busca semântica com páginas de PDF e conteúdo misto, mas os limites e formatos exatos precisam ser verificados na API ou plataforma escolhida. Não extrapole automaticamente as regras da Cohere para Bedrock ou OCI, nem faça o caminho inverso. Também não interprete o contexto declarado como autorização para enviar qualquer arquivo sem considerar as restrições de tamanho, estrutura ou formato.

Protocolo de teste: corpus, consultas e relevância

Antes de comparar modelos, fixe um corpus de avaliação e evite alterá-lo entre as execuções. Inclua documentos frequentes, difíceis e pouco consultados; se a busca abranger mais de um idioma, inclua exemplos de cada um. Para avaliar a multimodalidade, não basta acrescentar algumas imagens: identifique tarefas em que a informação visual seja necessária, documentos com texto e imagem, páginas com tabelas e casos em que o conteúdo extraído por OCR possa estar incompleto. O objetivo é representar o uso previsto, não construir uma amostra que favoreça antecipadamente um modelo.

Prepare consultas reais ou elaboradas a partir de necessidades observáveis e registre quais documentos ou fragmentos devem ser considerados relevantes. Os julgamentos podem ser binários ou graduados, mas as regras precisam ser as mesmas na comparação entre o sistema vigente e o candidato. Convém incluir consultas diretas e ambíguas, termos pouco frequentes, nomes próprios e perguntas cuja resposta dependa de uma imagem ou tabela. Uma consulta não deve receber um julgamento de relevância apenas porque o sistema atual a resolve corretamente: é preciso definir o que se espera recuperar.

A análise deve examinar posições e conjuntos recuperados. Recall@k permite observar se os elementos relevantes estão presentes entre os primeiros k resultados; precision@k, que proporção dos resultados iniciais é considerada relevante; e nDCG@k pode ser útil quando os julgamentos distinguem níveis de relevância. São métricas possíveis, não uma garantia de que um único indicador resuma a utilidade do sistema. A equipe deve combinar antecipadamente quais valores de k e quais critérios de promoção importam para a experiência real.

Segmente os resultados por idioma, modalidade e tipo de consulta. Uma melhora geral pode esconder uma queda num idioma minoritário ou em documentos com imagens. Da mesma forma, uma média satisfatória não elimina casos de falha críticos. Preserve exemplos de consultas para as quais o novo modelo recupera resultados diferentes, examine-os com especialistas do domínio e diferencie erros de indexação, de divisão em fragmentos, de configuração e de relevância do próprio embedding.

Métricas operacionais e efeitos da dimensão

A qualidade da recuperação não é o único critério de decisão. Meça a latência em condições comparáveis, tanto para gerar embeddings quanto para pesquisar, e registre os recursos necessários para processar o corpus e manter o índice. Separe o custo da criação ou reconstrução dos embeddings do custo de atender às consultas habituais. Valores e tempos dependem do fornecedor, do canal de acesso, do tamanho das entradas, da dimensão escolhida e da carga; não é possível deduzi-los apenas da ficha do modelo.

Compare as dimensões disponíveis num teste que mantenha constantes os demais fatores. Verifique o tamanho efetivo do armazenamento no índice, as consequências para a transferência e o comportamento da recuperação. Se o fornecedor descrever uma estratégia Matryoshka ou a possibilidade de escolher diferentes dimensões, trate isso como uma opção de configuração a medir, não como prova automática de equivalência entre tamanhos. Reduzir a dimensão pode aliviar certas cargas operacionais, mas também pode mudar quais documentos aparecem primeiro.

Registre também a proporção de entradas rejeitadas, truncadas ou processadas de maneira diferente da esperada. Num teste multimodal, a porcentagem de documentos que não chegaram ao índice pode alterar as métricas de recuperação e dar uma impressão enganosa do modelo. Apresente separadamente a cobertura do processamento, a qualidade da recuperação nos casos válidos e os resultados totais que consideram as falhas. Uma comparação justa não deve excluir silenciosamente os documentos difíceis para uma das configurações.

Promoção, reversão e documentação

Defina, antes de executar o teste, quais resultados seriam suficientes para promover o índice candidato. Os critérios podem combinar limites de recuperação por segmento, ausência de regressões em consultas críticas, limites aceitáveis de latência e custo e uma cobertura mínima de processamento. Não existe um limite universal: ele depende da importância de cada caso, do nível de serviço e do custo dos erros. A decisão deve se basear em evidências observáveis, não na impressão de que as respostas de demonstração parecem melhores.

A reversão deve fazer parte do desenho da migração. Preserve o índice anterior, sua configuração e a relação entre os identificadores dos documentos e os vetores. Se a promoção falhar, a rota de consulta deve voltar à versão anterior sem adicionar ao índice antigo vetores do candidato nem perder a rastreabilidade. Numa transição gradual, identifique cada resultado com o índice e a configuração que o produziram; evite combinar saídas das duas versões sem uma política de fusão testada.

Documente o resultado, inclusive as limitações: idiomas com amostras pequenas, modalidades não avaliadas, entradas que o canal não aceita e diferenças entre fornecedores. Se a equipe operar diretamente com a Cohere, o Amazon Bedrock ou a OCI, registre qual documentação e quais limites se aplicam a essa integração. A ficha de um modelo oferecido por uma plataforma não deve se transformar numa afirmação geral sobre qualquer endpoint que use o nome Embed 4.

Uma migração será defensável se outra pessoa puder reconstruir qual corpus foi testado, com que modelo e parâmetros, quais consultas e julgamentos foram utilizados, quais métricas foram calculadas e como se chegou à decisão. A documentação pública da Cohere ajuda a definir capacidades e parâmetros declarados; validar o desempenho da recuperação no próprio ambiente continua sendo responsabilidade da equipe.

O que se pode concluir e o que exige avaliação própria

A documentação da Cohere declara para o Embed 4 capacidades de texto, imagem e entradas mistas, dimensões selecionáveis e um contexto amplo; os exemplos incluem busca em páginas de PDF. A API e os guias do fornecedor descrevem parâmetros relevantes para a recuperação, como `input_type`. Essas informações permitem planejar um teste e entender quais configurações precisam ser verificadas. Não demonstram que um índice de outro modelo possa ser reutilizado diretamente, que determinada dimensão seja ideal ou que a recuperação vá melhorar num conjunto específico de documentos.

A pergunta útil não é se o Embed 4 é, em abstrato, melhor, mas se uma configuração definida de `embed-v4.0` obtém resultados de recuperação aceitáveis para os documentos, idiomas, modalidades e restrições operacionais da equipe. Para responder, é preciso construir um índice candidato separado, recalcular documentos e consultas de maneira compatível, avaliar com julgamentos de relevância e registrar custo e latência. Só depois dessa comparação faz sentido decidir se o sistema vigente será substituído ou se será adicionada uma rota multimodal.

Para quem explora modelos e ferramentas na área de descoberta da Inferama, essa abordagem oferece um critério de comparação que vai além de uma ficha técnica. A página do Cohere Embed 4 e as informações sobre a Cohere como organização podem ajudar a localizar o modelo e sua documentação; a escolha operacional, por sua vez, deve ser justificada pelos resultados reproduzíveis do índice e das consultas reais.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.