Cohere Embed 4: como medir o custo de uma recuperação útil

A questão económica não é quanto custa uma chamada

O gasto associado a um modelo de embeddings costuma ser expresso numa unidade de faturação que depende do canal de acesso. Mesmo quando esse valor está confirmado, não responde, por si só, à questão importante para uma equipa de pesquisa: quanto custa obter resultados que cumpram um critério de utilidade para os utilizadores? Uma chamada barata pode gerar recuperações pouco pertinentes; uma configuração mais cara poderá melhorar os resultados, mas só será economicamente preferível se essa melhoria tiver valor no corpus e nas consultas realmente utilizadas.

Convém separar três questões. A primeira é comercial: que produto exato é faturado, através de que fornecedor ou canal, em que unidade e sob que condições. A segunda é técnica: que qualidade de recuperação alcança a configuração avaliada. A terceira é operacional: que outros componentes, como armazenamento ou infraestrutura de pesquisa, fazem parte do gasto total. Misturá-las num único valor pode dar uma aparência de comparação que os dados não sustentam.

A evidência fornecida para este artigo não confirma uma tarifa específica do Embed 4 Small ou Medium, nem a respetiva unidade de faturação. Por isso, não permite publicar uma classificação de custos entre variantes. Permite, no entanto, propor um teste reproduzível e especificar que informação deve ser recolhida antes de fazer a comparação.

O que verificar antes de comparar Small e Medium

Antes de executar um teste económico, registe o identificador exato do modelo, a variante que pretende utilizar e o canal de acesso. Não parta do princípio de que uma tarifa associada à Cohere também se aplica a um serviço de cloud que disponibiliza o modelo, nem de que as condições de um fornecedor se transferem para outro. A documentação disponível identifica o Embed 4 em serviços do Azure AI, Amazon Bedrock e Oracle Cloud Infrastructure, mas a informação recebida não estabelece que as respetivas condições de acesso ou faturação sejam iguais.

Para cada canal, confirme numa fonte oficial a tarifa em vigor, a unidade faturável, os mínimos ou encargos adicionais aplicáveis, a data da consulta e se a tarifa distingue variantes. Guarde uma cópia ou um registo verificável do que consultou: as tarifas podem mudar e a data faz parte da comparação. Se o preço for expresso numa unidade diferente daquela utilizada noutro canal, não converta os valores com base em equivalências que a documentação não sustente.

Também é necessário determinar o que é considerado uma entrada faturável e se o tratamento muda consoante a modalidade ou a configuração. A documentação de um serviço pode descrever parâmetros ou limites de pedidos, mas isso não demonstra, por si só, como a fatura é calculada. Se não for possível confirmar a ligação entre o limite técnico e a unidade comercial, mantenha os dois dados separados.

Conceber um teste que represente o trabalho real

Uma comparação útil começa com um corpus representativo, não com uma coleção escolhida por favorecer uma variante. Inclua documentos, consultas e padrões de utilização semelhantes aos da produção: idiomas, extensões, tipos de conteúdo e casos difíceis relevantes para o sistema avaliado. Se a aplicação pesquisar conteúdo multimodal, inclua esse material apenas quando o canal e a documentação aplicáveis permitirem testá-lo em condições claras.

Defina antes da medição o que significa uma recuperação útil. A equipa pode estabelecer, por exemplo, que resultados considera pertinentes para uma consulta e que ordem relativa espera entre eles. O importante não é adotar uma métrica por hábito, mas documentar o critério e aplicá-lo da mesma forma a todas as variantes. As consultas utilizadas para ajustar a configuração não devem ser confundidas com as reservadas para a avaliação final: separar os dois conjuntos ajuda a evitar que o resultado reflita apenas decisões tomadas sobre os mesmos casos.

Os juízos de relevância também precisam de um procedimento explícito. Registe quem avalia, que instruções recebe e como são resolvidas as divergências. Se vários avaliadores não estiverem de acordo, essa incerteza deve permanecer na análise. Uma pontuação agregada não corrige rótulos inconsistentes nem transforma uma amostra pequena em evidência conclusiva.

Medir a qualidade por consulta antes de resumir

A unidade prática de análise é cada consulta avaliada. Para cada uma, registe o que a configuração recuperou, que elementos foram considerados pertinentes e se o critério acordado foi cumprido. Consoante o objetivo do sistema, pode interessar a presença de resultados pertinentes entre os primeiros lugares, a cobertura dos elementos relevantes ou a qualidade da ordenação. A escolha depende da forma como a recuperação será utilizada; não se deve apresentar uma métrica como universalmente suficiente.

Depois de rever os resultados por consulta, calcule um resumo do conjunto e preserve também a distribuição. Duas variantes podem ter médias semelhantes e, ainda assim, comportar-se de forma diferente em consultas difíceis, idiomas específicos ou tipos de documento. Mostrar esses casos ajuda a detetar se uma melhoria geral é obtida à custa de um grupo de utilizadores ou de uma parte do corpus.

Defina um limiar de aceitação antes de ver os resultados da comparação. Se a equipa o redefinir depois de saber que variante ficou acima, o resultado deixa de ser um teste neutro. Quando a amostra ou os juízos disponíveis não permitirem distinguir uma pequena diferença do ruído, descreva o resultado como inconclusivo. Não transforme uma variação numérica numa melhoria demonstrada sem evidência suficiente.

Calcular o custo associado ao limiar

Depois de verificar a unidade e a tarifa do canal, calcule separadamente os componentes que a evidência permite quantificar. Se a tarifa se aplicar à geração de embeddings, registe o volume efetivamente processado e aplique a esse volume a unidade publicada. Não preencha o cálculo com uma unidade presumida nem apresente uma estimativa como gasto observado. Se o canal não publicar a condição necessária para reproduzir a conta, indique que não é possível calcular o custo com a informação disponível.

Para expressar o resultado como custo por recuperação que cumpre o objetivo, defina claramente o denominador. Pode ser o número de consultas de avaliação que atingem o limiar de relevância na configuração testada. O numerador deve corresponder ao gasto que está a ser atribuído e ao mesmo período ou conjunto de trabalho. Se o gasto medido cobrir a geração inicial de embeddings, não o descreva como custo completo de cada consulta sem explicar como esse gasto é distribuído e que pressupostos são utilizados.

É aconselhável publicar as quantidades intermédias, e não apenas o quociente final: volume processado, gasto atribuível, número de consultas avaliadas e número das que superam o critério. Assim, outra pessoa pode rever o cálculo e alterar pressupostos, como a dimensão do corpus ou a frequência de atualização. Um valor sem estes elementos pode ocultar diferenças de âmbito entre as variantes.

Texto e modalidades adicionais exigem condições equivalentes

As fontes disponíveis descrevem o Embed 4 como um modelo multimodal e referem a possibilidade de trabalhar com texto e imagens em determinados serviços. Essa descrição geral não basta para concluir que uma avaliação multimodal seja diretamente comparável entre canais, nem que todos ofereçam as mesmas condições de entrada, parâmetros ou faturação. O teste deve especificar que serviço é utilizado e que formato é aceite nesse contexto.

Para uma avaliação de texto, utilize consultas e documentos de texto coerentes com a aplicação. Para uma avaliação com imagens ou conteúdo intercalado, defina o material, as consultas e os critérios de relevância específicos dessa modalidade e confirme que o serviço escolhido aceita esse tipo de entrada. Não misture resultados de texto e multimodais num único valor se a composição da amostra ou o âmbito dos custos forem diferentes.

Os limites técnicos descritos por um fornecedor também não devem ser transferidos para outro. A documentação da Oracle incluída nas fontes refere-se ao Embed 4 na OCI; a documentação da Amazon Bedrock diz respeito à Bedrock, e a ficha do Azure AI corresponde ao respetivo catálogo. Antes de utilizar um limite de entrada no desenho do teste, verifique se é aplicável ao serviço e ao modo de utilização concretos que estão a ser avaliados.

Interpretar diferenças sem extrapolar

Uma comparação descreve apenas o corpus, as consultas, a configuração e as condições que foram avaliados. Não demonstra automaticamente que a mesma variante seja preferível noutro idioma, conjunto documental, volume de utilização ou serviço. Se a avaliação tiver sido feita numa amostra limitada, a conclusão deve restringir-se a essa amostra e expor as suas limitações.

Analise as consultas que falharam, e não apenas a média. Uma melhoria que surja em poucas consultas pode ser relevante se essas consultas forem críticas para o caso de utilização; também pode ser instável se depender de uma amostra reduzida ou de juízos discutíveis. A equipa deve decidir antecipadamente que tipos de falha são aceitáveis e que impacto teria cada um. A análise económica não substitui essa decisão sobre o risco para a qualidade.

Quando uma variante melhora ligeiramente a recuperação, pergunte se a diferença ultrapassa a incerteza da avaliação e se altera de forma útil a proporção de consultas que cumpre o limiar. Se não houver evidência suficiente, indique que não foi estabelecida uma diferença fiável. Evite apresentar uma classificação taxativa ou uma recomendação universal com base num teste local.

O que fazer quando os preços não são comparáveis

Se a informação oficial não identificar claramente o preço, a unidade faturável ou a variante abrangida, não crie uma classificação com base em excertos de páginas, anúncios gerais ou tarifas de outro canal. A página de preços da Cohere incluída nas fontes não confirma, no material disponível, uma tarifa ou unidade específica para o Embed 4 Small e Medium. O anúncio sobre preços para programadores fornece contexto sobre a política de preços, mas, por si só, não estabelece o preço dessas variantes.

Nesse caso, publique apenas o que tiver sido verificado: o canal avaliado, a data da verificação, as condições técnicas confirmadas e as métricas de qualidade observadas. Assinale que dados comerciais faltam e que conclusão fica bloqueada por essa ausência. Se um marketplace indicar faturação por utilização, mas o material consultado não apresentar a unidade nem uma tarifa concreta, essa descrição não permite deduzir um custo por consulta.

Esta limitação não invalida o teste de qualidade. Permite separar uma avaliação técnica reproduzível de uma análise de custos que ainda não pode ser concluída. Quando se obtiverem tarifas oficiais comparáveis, será possível completar o cálculo sem alterar as métricas já registadas, desde que os volumes e as condições correspondentes tenham sido guardados.

Lista prática para repetir a comparação

Uma comparação útil deixa um registo que outra equipa possa repetir. Guarde o identificador exato do modelo, o canal e a configuração; a composição do corpus e das consultas; as instruções e os juízos de relevância; os critérios de aceitação definidos antes da medição; e as métricas por consulta, além dos resumos. Registe também qualquer alteração feita durante o teste, uma vez que uma modificação pode dificultar a comparação com execuções posteriores.

Na parte económica, preserve a tarifa oficial consultada, a data, a unidade, a moeda e o âmbito, sempre que esses dados estejam disponíveis e sejam inequívocos. Registe os volumes processados e separe os custos de armazenamento, infraestrutura e operação quando forem conhecidos. Se não puderem ser documentados, deixe-os fora do cálculo e assinale que o resultado não representa o custo total do sistema.

Por fim, estabeleça quando o teste será repetido. Uma alteração de preço, canal, variante, configuração ou corpus pode mudar o resultado. O objetivo não é criar um rótulo permanente para a variante mais barata, mas manter uma decisão passível de revisão e ligada à evidência: que recuperação cumpre o objetivo, em que condições foi medida e que gasto verificável lhe pode ser atribuído.

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.