MSEB da Google Research: implementação de codificadores de áudio segundo o contrato do benchmark e avaliação em quatro classes de tarefas
Análise prática do pacote mseb==0.1.0: arquitetura em camadas types, encoder e evaluators, dois encoders de demonstração num corpus sintético e chamada direta das métricas de classificação, clustering, pesquisa e segmentação. O material mostra como adaptar o seu próprio modelo ao MultiModalEncoder abstrato, interpretar o formato SoundEmbedding e criar TaskMetadata para posterior envio para o benchmark.

Finalidade e camadas do benchmark
MSEB — Massive Sound Embedding Benchmark, da Google Research. O pacote é instalado como mseb==0.1.0. O benchmark divide-se em três camadas.
typesdefine os tiposSound,SoundEmbedding,ScoreeTaskMetadata.encodercontém a classe base abstrataMultiModalEncoder— o contrato implementado pelo modelo.evaluatorscontém avaliadores para diferentes tarefas.
Estas camadas separam a descrição dos dados, a interface do modelo e a medição da qualidade. Critério prático: a camada encoder define os requisitos do encoder, enquanto evaluators define os da avaliação.
Contrato do encoder e tipos de dados
encoder contém a classe base abstrata MultiModalEncoder. Esta classe é o contrato implementado pelo modelo. types define Sound, SoundEmbedding, Score e TaskMetadata.
SoundEmbedding armazena embeddings com a forma (N, D) e marcas temporais com a forma (M, 2). As marcas indicam o início e o fim do intervalo em segundos. Se M == N, as marcas correspondem a quadros individuais. Se M == 1, o embedding refere-se à enunciação inteira. O campo embedding pode conter N strings em vez de vetores. SoundEmbedding também inclui contexto e estatísticas de codificação, incluindo as dimensões da entrada e do embedding.
Score descreve a métrica, o seu valor, o intervalo permitido e a descrição. TaskMetadata é recolhido no final da avaliação e utilizado numa submissão real.
Critério prático: o encoder deve devolver um SoundEmbedding com dimensões corretas e preencher Score para cada tarefa.
Dois exemplos de encoders: volume e timbre
O guia implementa dois encoders diferentes. Um mede o volume ao longo do tempo, o outro, o timbre. São aplicados a um pequeno corpus de áudio sintético. O corpus é criado no notebook, por isso não é necessário descarregar dados.

De acordo com a descrição do guia, os dois encoders apresentam resultados diferentes consoante o avaliador. Isto significa que a escolha da característica influencia a qualidade em diferentes tarefas. Critério prático: é necessário testar ambas as abordagens para classificação, agrupamento, pesquisa e segmentação.
Avaliação em quatro classes de tarefas
Os embeddings são avaliados em tarefas de classificação, agrupamento, pesquisa e segmentação. Nos exemplos, são importados ClassificationEvaluator, ClusteringEvaluator, RetrievalEvaluator e SegmentationEvaluator. As funções das métricas são chamadas diretamente. No final, é recolhido TaskMetadata, utilizado numa submissão real.
O pacote também lista avaliadores para reranking e transcrição.
Os avaliadores de classificação, agrupamento, pesquisa e segmentação dependem apenas de NumPy e scikit-learn. Os avaliadores de reranking e transcrição utilizam Whisper.
| Tarefa | Avaliador | Dependências |
|---|---|---|
| Classificação | ClassificationEvaluator | NumPy, scikit-learn |
| Agrupamento | ClusteringEvaluator | NumPy, scikit-learn |
| Pesquisa | RetrievalEvaluator | NumPy, scikit-learn |
| Segmentação | SegmentationEvaluator | NumPy, scikit-learn |
| Reranking | avaliador de reranking | Whisper |
| Transcrição | avaliador de transcrição | Whisper |
Critério prático: para as quatro classes de tarefas, NumPy, scikit-learn e CPU são suficientes. Para reranking e transcrição, é necessário o Whisper.
Dependências e requisitos de execução
Os passos apresentados são executados em CPU, sem descarregar um conjunto de dados. Os avaliadores de classificação, agrupamento, pesquisa e segmentação dependem apenas de NumPy e scikit-learn. Os avaliadores de reranking e transcrição utilizam Whisper. O executor de tarefas utiliza TensorFlow e apache-beam.
Estas dependências determinam o ambiente de execução. Para as quatro classes de tarefas, não são necessários GPU nem dados externos. Para reranking, transcrição e execução do executor de tarefas, são necessários componentes adicionais.
Critério prático: se o objetivo for testar rapidamente um encoder em tarefas de classificação, agrupamento, pesquisa e segmentação, bastam uma CPU e as bibliotecas indicadas.
Critérios práticos de seleção
A implementação do encoder deve estar em conformidade com MultiModalEncoder. O SoundEmbedding devolvido deve conter embeddings com a forma (N, D) e marcas temporais com a forma (M, 2). O campo embedding pode conter N strings em vez de vetores. Score deve descrever a métrica, o valor, o intervalo permitido e a descrição. TaskMetadata é recolhido no final e utilizado numa submissão real.
Para a avaliação de classificação, agrupamento, pesquisa e segmentação, são adequados ClassificationEvaluator, ClusteringEvaluator, RetrievalEvaluator e SegmentationEvaluator. Dependem de NumPy e scikit-learn. Para reranking e transcrição, é necessário o Whisper.
Critério prático: o encoder é escolhido de acordo com a tarefa. Os dois exemplos de encoder — volume e timbre — apresentam resultados diferentes consoante o avaliador. Ambos os encoders devem ser testados no conjunto de tarefas pretendido.
Perguntas mais frequentes
Materiais semelhantes
Todos os materiais
Avaliação de agentes de programação no desenvolvimento XR interativo: resultados do GenXR-Bench
Foi publicado o GenXR-Bench, um conjunto de 112 tarefas especializadas para avaliar de ponta a ponta agentes de programação no desenvolvimento interativo de XR: desde o aprimoramento de funcionalidades e a correção de defeitos até a criação de aplicações com verificação do comportamento em dispositivos de consumo. Entre os dez modelos testados, o melhor resultado foi de 50,9% no Pass@1; entre as falhas recorrentes estão o processamento de eventos assíncronos de sensores, a ancoragem de objetos no espaço real e a compreensão das interações em contextos físicos.
5 novembro 2026
Anotação híbrida de imagens: a automatização acelera o treino de modelos de visão por computador
O artigo descreve como a pré-anotação por algoritmos reduz o trabalho manual e melhora a qualidade dos conjuntos de dados de treino, bem como por que motivo a verificação por amostragem humana continua a ser necessária. São abordadas as limitações do método em condições difíceis de captura e em tipos de objetos raros.
5 novembro 2026
Da recompensa escalar à fronteira de Pareto: síntese de RTL com aprendizagem por reforço multiobjetivo
É proposto um método para treinar um modelo de linguagem a gerar não apenas um esquema, mas um conjunto de candidatos RTL com diferentes compromissos entre área, latência e consumo de energia; a recompensa é calculada com base na contribuição de cada variante para o hipervolume da fronteira de Pareto. No RTLLM v2, o hipervolume relativo aumentou 13,3 p.p. em relação à versão de base sem otimização de PPA e 14,4 p.p. em relação ao treinamento por reforço com um único objetivo.
5 novembro 2026