Como avaliar o Command R 08-2024 diante de evidências incompletas em RAG

A que pergunta esta avaliação responde

Um sistema de geração aumentada por recuperação, ou RAG, recebe documentos recuperados e os utiliza como contexto para responder. O teste proposto aqui faz uma pergunta delimitada: quando recebe um conjunto de trechos documentais, o Command R 08-2024 distingue o que esses trechos sustentam, o que contradizem e o que não permitem responder? O objetivo não é medir toda a capacidade linguística do modelo nem reproduzir uma pontuação publicada pelo fornecedor.

A unidade de análise será uma resposta produzida com um contexto documental especificado. Serão avaliados separadamente a exatidão da resposta, o respaldo de suas afirmações, a qualidade das citações, o tratamento de contradições e a decisão de se abster. Separar essas dimensões evita que uma resposta fluente ou uma pontuação agregada ocultem falhas diferentes: por exemplo, uma conclusão correta por acaso, uma citação que menciona o tema sem comprovar a afirmação ou uma abstenção diante de informações explícitas.

O escopo também exclui conclusões gerais sobre todas as versões do Command R, sobre o Command R+ ou sobre o desempenho em produção de um sistema completo. Um teste com corpus, instruções e parâmetros determinados descreve esses elementos específicos. Por si só, não permite afirmar que o modelo terá o mesmo desempenho com outros documentos, usuários, configurações de recuperação ou condições de serviço.

Identificar o modelo antes de testá-lo

O nome comercial não basta para identificar de forma reproduzível qual sistema gerou uma resposta. O registro deve incluir o identificador exato, o canal de acesso, a data de cada execução e a configuração disponível. Também deve guardar a solicitação enviada e, quando o canal permitir, os parâmetros de geração e quaisquer metadados retornados. Se um fornecedor alterar o modelo por trás de um nome sem permitir fixar uma revisão, essa limitação deve constar da metodologia.

A documentação da Cohere sobre a atualização de agosto identifica o Command R 08-2024 e apresenta melhorias em recuperação aumentada multilíngue e uso de ferramentas. Essa descrição serve para documentar o que o fornecedor afirma sobre a atualização, mas não constitui uma avaliação independente das métricas deste protocolo. Portanto, o texto de uma ficha de modelo ou uma avaliação do fornecedor não deve substituir o experimento controlado proposto aqui.

A documentação disponível da Oracle identifica o cohere.command-r-08-2024 em seu serviço e marca o modelo como descontinuado. Esse dado permite apontar uma limitação nesse canal, mas não demonstra que o identificador esteja indisponível em outros. Já o repositório da Cohere Labs identifica uma versão de pesquisa com pesos abertos. Antes de executar o teste, seria necessário verificar diretamente qual artefato ou serviço será utilizado, qual versão específica está disponível e quais condições de uso se aplicam. As fontes fornecidas não bastam para confirmar a disponibilidade atual nem todos os parâmetros operacionais.

Construir um corpus com três condições

O conjunto deve incluir três classes de casos, separadas desde a etapa de projeto. Nos casos de evidência suficiente, uma resposta pode ser derivada de uma ou mais passagens identificáveis. Nos casos contraditórios, dois ou mais documentos sustentam versões incompatíveis de um dado relevante. Nos casos sem evidência suficiente, o material fornecido não permite responder de forma justificada, mesmo que a pergunta pareça plausível. Essa terceira categoria não deve ser confundida com um documento difícil de encontrar: a ausência precisa ser verificada no corpus definido para o teste.

É recomendável usar documentos controlados, com origem e data registradas, e redigir as perguntas antes de observar as respostas do modelo. Para cada pergunta, um revisor deve determinar previamente quais passagens a sustentam, se há conflito e quais informações estão faltando. Essa revisão define o rótulo de referência e reduz o risco de decidir, depois, que uma resposta inesperada estava correta apenas por parecer razoável.

O corpus deve representar os usos que se pretende estudar sem introduzir diferenças acidentais entre as categorias. Se os casos contraditórios forem muito mais longos ou tiverem formatos diferentes dos casos com evidência suficiente, o resultado poderá refletir essas diferenças além da capacidade de reconhecer conflitos. Uma tabela de composição deve informar o número de perguntas por condição, a quantidade e a extensão dos documentos, os idiomas, as datas e quaisquer critérios de seleção. Essas decisões não devem ser apresentadas como uma amostra universal da documentação interna.

Fixar a recuperação, as instruções e a execução

Para avaliar o comportamento do modelo diante das evidências, todos os componentes que afetam o contexto precisam ser descritos. Se a pergunta for fornecida junto com trechos já selecionados, o teste avalia a resposta do modelo condicionada a esses trechos, e não a qualidade de um mecanismo de busca. Se for utilizado um componente de recuperação, também devem ser preservados a consulta, os documentos candidatos, a ordem, o número de trechos e a regra de seleção. Sem essa distinção, uma falha do mecanismo de recuperação pode ser atribuída ao modelo generativo, ou vice-versa.

A instrução deve ser igual em todos os casos, exceto quando uma comparação controlada modificar deliberadamente uma variável. Ela deve indicar como apresentar as evidências e o que fazer quando estiverem ausentes ou em conflito. A forma de solicitar a abstenção exige atenção especial: uma instrução ambígua pode medir tanto a interpretação do prompt quanto a capacidade de reconhecer insuficiência. Por isso, o texto literal deve ser publicado, e a instrução não deve ser ajustada caso a caso após a observação das respostas.

O plano deve especificar quantas execuções serão feitas por pergunta. Se o canal não permitir controlar ou conhecer determinados parâmetros, isso precisa ser anotado. Repetir uma execução pode ajudar a observar a variabilidade, mas não transforma automaticamente o conjunto em uma amostra representativa. Também devem ser preservadas as saídas com falhas e as respostas que não respeitarem o formato solicitado, em vez de serem descartadas silenciosamente.

Medir cada dimensão separadamente

A exatidão factual deve avaliar se a resposta corresponde ao que pode ser estabelecido a partir do corpus e da referência revisada. O respaldo das afirmações faz uma pergunta diferente: cada afirmação substantiva da resposta é apoiada pelos documentos fornecidos? Uma resposta pode acertar o dado principal e acrescentar detalhes que o corpus não sustenta; um único rótulo de «correta» ocultaria esse problema.

A avaliação das citações deve verificar se a passagem indicada sustenta a afirmação específica associada a ela. Uma correspondência temática não basta: uma citação que menciona uma devolução não comprova necessariamente o prazo citado. Quando a saída não incluir referências explícitas a passagens, essa dimensão deve ser marcada como não avaliável ou adaptada ao formato acordado, e não pontuada como se as citações existissem.

A resolução de contradições deve medir se a resposta detecta o conflito, identifica as versões relevantes e evita apresentar uma delas como indiscutível sem fundamento nos documentos. A abstenção apropriada deve distinguir entre abster-se por falta de respaldo e recusar-se desnecessariamente quando o corpus contém uma resposta. É possível informar taxas ou contagens para cada categoria, sempre acompanhadas dos denominadores, das regras de anotação e de exemplos. Não é recomendável reduzir todas as dimensões a uma pontuação agregada sem justificar como são ponderadas.

Anotação, controles e contaminação

A anotação deve seguir regras escritas antes da revisão das saídas. Quando viável, dois revisores podem avaliar de forma independente e sem saber qual configuração produziu cada resposta. Os desacordos não devem desaparecer em uma média opaca: é preciso registrar em quais dimensões há divergências, como cada caso foi resolvido e quais exemplos continuam ambíguos. Também convém preservar tanto as respostas originais quanto a versão normalizada utilizada na análise, explicando qualquer transformação.

A contaminação do conjunto de avaliação é uma limitação distinta da qualidade da recuperação. Perguntas ou documentos que já tenham aparecido em dados de treinamento podem influenciar uma resposta, mas as fontes disponíveis aqui não permitem determinar se isso ocorreu em um conjunto específico. Deve-se descrever o que se sabe sobre a origem dos documentos e a data de criação das perguntas, além de explicitar qual exposição prévia não pode ser verificada. Não se deve afirmar que um conjunto está livre de contaminação sem evidências suficientes para sustentar essa conclusão.

Os controles também incluem verificar se os rótulos de referência não revelam inadvertidamente a resposta na própria pergunta, se os trechos são fornecidos de maneira consistente e se falhas de acesso não são confundidas com respostas do modelo. Se o prompt, a recuperação ou o corpus forem modificados durante o estudo, a nova condição deve ser tratada como uma variante separada e documentada. A comparabilidade depende de ser possível reconstruir o que mudou.

Comparabilidade e limites de interpretação

Um teste desse tipo descreve o comportamento observado sob uma configuração, um corpus e instruções específicos. Isso não basta para concluir que o Command R 08-2024 é adequado a qualquer sistema RAG, nem para classificar modelos avaliados com documentos, prompts, canais de acesso ou rubricas diferentes. Uma comparação direta com o Command R+ exigiria uma avaliação paralela, com versões identificadas e condições equivalentes; o protocolo aqui descrito não fornece resultados comparativos.

As afirmações do fornecedor sobre uma atualização podem ajudar a identificar quais aspectos se pretende aprimorar, mas não devem ser convertidas em resultados deste experimento. Da mesma forma, o estado de disponibilidade em um canal não descreve necessariamente outros canais. Se um acesso reproduzir pesos abertos e outro utilizar um serviço gerenciado, o relatório deve tratá-los como configurações distintas, a menos que seja possível verificar que correspondem ao mesmo artefato e a condições comparáveis.

A possibilidade de generalização também depende do projeto do corpus. Um conjunto pequeno ou concentrado em uma área documental pode ser útil para detectar falhas e ajustar uma configuração, mas não justifica prometer o mesmo comportamento em outros domínios, idiomas ou tipos de documento. O relatório deve comunicar incerteza e cobertura, e não apenas o resultado mais chamativo. Se não for possível identificar e fixar o modelo exato, a decisão metodologicamente honesta é não publicar pontuações atribuídas a essa versão.

Publicar para que outras pessoas possam repetir o teste

Um relatório reproduzível deve incluir o protocolo, o identificador e o canal de acesso, a data de execução, as instruções literais, a configuração registrada, o formato do contexto, as perguntas, as regras de anotação e os resultados discriminados por dimensão. Também deve explicar como foram tratadas as saídas inválidas, os erros do serviço e as divergências entre revisores. Se algum elemento não puder ser compartilhado, é preciso especificar qual e por quê; a ausência de um artefato não deve ser disfarçada como se o método fosse totalmente reproduzível.

Antes de publicar documentos ou consultas, é necessário verificar se há direitos, requisitos de confidencialidade ou outras condições que impeçam sua divulgação. Se não for possível compartilhá-los, alternativas possíveis incluem descrever a estrutura do conjunto, publicar exemplos sintéticos claramente identificados como tais ou permitir uma avaliação controlada. Essas opções não substituem automaticamente a publicação dos dados: reduzem a possibilidade de repetição independente, e essa limitação deve ser explícita.

Para uma equipe, a conclusão prática é usar o teste como ferramenta de diagnóstico, não como autorização automática para implantar. Se o sistema responde com citações, é importante verificar se elas sustentam as afirmações. Se o principal risco são documentos desatualizados ou contraditórios, esses casos devem ser testados com materiais próprios e regras de resolução adequadas. E, se for necessária uma abstenção segura, é preciso definir o comportamento aceitável para aquele domínio antes de observar as respostas.

Conclusão: um protocolo não é um resultado

A pergunta útil não é se um modelo «cita bem» em abstrato, mas o que ele faz diante de evidências definidas e sob condições que outras pessoas possam inspecionar. Separar evidência suficiente, contradição e ausência permite projetar controles diferentes para cada situação. Separar exatidão, respaldo, qualidade das citações e abstenção impede que uma única pontuação ou uma resposta convincente esconda erros relevantes.

As fontes verificadas fornecidas permitem identificar o Command R 08-2024 na documentação da Cohere e em um repositório da Cohere Labs, além de observar que a documentação da Oracle consultada marca o modelo como descontinuado nesse serviço. Elas não demonstram que o teste proposto tenha sido executado, não confirmam a disponibilidade atual em todos os canais e não comprovam resultados independentes sobre citações, contradições ou abstenção. Por isso, este artigo apresenta o projeto e as condições de validade, sem atribuir pontuações ao modelo.

Uma equipe que queira aplicar o protocolo à documentação interna deverá criar seu próprio conjunto revisado, definir o que significa uma resposta respaldada e decidir quais níveis de incerteza são aceitáveis. Somente depois de verificar a versão e executar as condições registradas fará sentido informar resultados. Mesmo então, as conclusões estarão limitadas à configuração e ao corpus estudados.

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.