Databricks AI Runtime Enfrenta Seu Verdadeiro Teste à Medida que Agentes Multiplicam Jobs de Treinamento

A Databricks afirma que sua equipe de pesquisa em IA aumentou em oito vezes os jobs de treinamento depois que agentes passaram a propor, iniciar e avaliar experimentos. Esse aumento transforma o Databricks AI Runtime, de infraestrutura de suporte, em um teste sobre se a pesquisa automatizada pode escalar sem desperdiçar GPUs escassas.

A empresa descreveu a mudança em uma publicação de engenharia de 15 de outubro sobre seu uso interno do AI Runtime, também chamado de AIR. Pesquisadores usam a plataforma para experimentos que vão de pequenos trabalhos de depuração a execuções de treinamento que envolvem centenas de GPUs por dias ou semanas.

A mudança importante não é simplesmente o fato de a Databricks treinar grandes modelos. Amazon, Google, Microsoft e provedores especializados de infraestrutura já oferecem caminhos gerenciados para treinamento distribuído. A Databricks faz uma afirmação mais específica: a mesma plataforma de dados governada pode sustentar um ciclo contínuo no qual agentes enviam experimentos, inspecionam resultados e escolhem o que tentar em seguida.

Esse ciclo cria um problema de infraestrutura mais difícil do que execuções ocasionais de treinamento em grande escala. Pesquisadores humanos toleram uma inicialização lenta, um erro pouco claro ou uma etapa de configuração manual quando executam alguns experimentos. Um agente pode enfrentar o mesmo problema centenas de vezes, transformando um pequeno atrito em um gargalo para toda a frota.

A Databricks publicou um relato detalhado do fluxo de trabalho, mas as evidências de desempenho continuam internas. A empresa não divulgou taxas de utilização, percentuais de jobs que falharam, ganhos na qualidade dos modelos ou custos por experimento bem-sucedido. Essas métricas ausentes decidirão se o treinamento com agentes da Databricks representa um modelo duradouro de pesquisa ou apenas gera mais atividade.

Databricks AI Runtime Deixa de Ser uma Ferramenta de Suporte e Vira o Plano de Controle da Pesquisa

O Databricks AI Runtime agora coordena um sistema experimental cuja carga de trabalho muda mais rápido do que uma equipe humana de operações consegue administrar manualmente.

Segundo o relato da AI Runtime da empresa, sua organização de pesquisa usa o AIR para desenvolver e testar modelos por trás de produtos como AI Functions. Essas funções incluem ferramentas para analisar e extrair informações de documentos empresariais.

O processo de pesquisa abrange ajuste fino supervisionado, aprendizado por reforço offline e aprendizado por reforço online. O ajuste fino supervisionado adapta um modelo com exemplos rotulados. Já o aprendizado por reforço melhora o comportamento com base no feedback de ações ou tarefas concluídas.

A Databricks afirma que os modelos envolvidos variam de alguns bilhões de parâmetros a quase um trilhão. Seus pesquisadores usam GPUs NVIDIA H100 e B300, dependendo da carga de trabalho. Os maiores jobs podem ocupar centenas de GPUs por dias ou semanas.

Esses números de destaque explicam apenas parte da carga operacional. A equipe também executa dezenas de milhares de jobs de treinamento e avaliação entre arquiteturas de modelos, conjuntos de dados, métodos de treinamento e combinações de hiperparâmetros. Uma plataforma de pesquisa precisa, portanto, lidar com dois formatos opostos de carga de trabalho.

Um formato é uma execução longa e cara de treinamento que não pode falhar sem consequências. Uma falha de nó ou de rede pode deixar centenas de GPUs ociosas e obrigar a equipe a retomar a partir de um checkpoint anterior. Mesmo quando os checkpoints limitam o dano, os pesquisadores ainda perdem tempo decorrido e capacidade de computação.

O outro formato consiste em muitos experimentos curtos. Esses jobs precisam de agendamento rápido, ambientes reproduzíveis e resultados comparáveis. Alguns segundos ou minutos de configuração desnecessária podem se acumular quando agentes de software continuam enviando novos trabalhos.

O AIR fica entre o código de pesquisa e a frota de GPUs subjacente. Pesquisadores podem especificar recursos por meio de uma interface de linha de comando, empacotar ambientes em contêineres Docker e enviar jobs sem provisionar manualmente cada cluster. A documentação do AI Runtime descreve o serviço como um ambiente gerenciado para criar, treinar e ajustar modelos de IA em infraestrutura de GPU.

A Databricks também conecta o AIR ao MLflow, seu sistema de rastreamento de experimentos. Os jobs de treinamento recebem automaticamente experimentos nos quais pesquisadores podem inspecionar logs, status e métricas. Agentes podem usar os mesmos resultados para determinar se uma tentativa melhorou o resultado-alvo.

O Unity Catalog fornece a camada de dados. O AIR monta dados de pesquisa governados para que o código de treinamento possa acessá-los por meio de operações familiares de sistema de arquivos. Essa abordagem mantém permissões e linhagem dos dados dentro do ambiente Databricks, ao mesmo tempo que permite aos pesquisadores preservar seu código de treinamento em contêineres.

Essa combinação muda o papel do AIR. Ele não é apenas uma maneira mais rápida de alugar aceleradores. Torna-se o plano de controle que conecta código, dados, agendamento, telemetria e decisões automatizadas.

Essa integração também é a fonte da tensão central da história. Cada camada adicional de automação cria mais demanda por uma infraestrutura que se comporte de maneira previsível. Se o runtime não conseguir manter inicializações, falhas e resultados compreensíveis, o agente de pesquisa perde o feedback necessário para escolher seu próximo experimento.

Por Que o Treinamento com Agentes da Databricks Gera Pressão em Toda a Pilha de IA

Um aumento de oito vezes nos jobs de treinamento desloca a restrição da atenção dos pesquisadores para a disciplina da infraestrutura.

A Databricks atribui a maior quantidade de jobs a um fluxo de pesquisa conduzido por agentes. Nesse ciclo, os agentes propõem mudanças nos modelos, iniciam várias tentativas, examinam métricas de treinamento, atualizam seus planos e enviam outro conjunto de experimentos.

A ideia se assemelha ao projeto autoresearch de Andrej Karpathy. Esse projeto fornece a um agente uma configuração compacta de treinamento de modelo de linguagem, uma métrica fixa de avaliação e permissão para editar o programa de treinamento. O agente executa tentativas repetidas e mantém as mudanças que melhoram a métrica.

O exemplo público de Karpathy é deliberadamente pequeno. A Databricks está aplicando o padrão mais amplo dentro de um ambiente corporativo de pesquisa, com projetos concorrentes, dados empresariais governados e cargas de trabalho distribuídas. Essa diferença eleva o peso operacional.

Um cientista humano pode reconhecer que uma mensagem de erro confusa reflete um problema temporário de capacidade. Um agente precisa de um resultado estruturado e acionável. Caso contrário, pode repetir a mesma configuração inadequada, abandonar uma ideia útil ou consumir recursos sem produzir evidências.

Inicializações rápidas importam pelo mesmo motivo. Um minuto de atraso é inconveniente para um pesquisador. Repetido em centenas de tentativas autônomas, o atraso reduz o número de hipóteses que podem ser testadas dentro de uma janela fixa de pesquisa.

O acesso confiável a métricas também se torna essencial. Um agente precisa saber qual execução foi concluída, qual configuração a produziu e se o resultado melhorou o objetivo pretendido. Um log ausente ou um artefato rotulado incorretamente pode comprometer a próxima etapa de planejamento.

Essa pressão vai além da Databricks. Plataformas gerenciadas de treinamento tradicionalmente competem em acesso a aceleradores, desempenho distribuído, orquestração e ferramentas para desenvolvedores. A pesquisa conduzida por agentes acrescenta outra exigência: a plataforma deve expor cada operação importante por interfaces que o software possa usar com segurança.

Amazon SageMaker HyperPod, Google Cloud Vertex AI, Microsoft Azure Machine Learning e provedores especializados de GPU enfrentam a mesma direção geral. Seus clientes querem cada vez mais que agentes iniciem experimentos e interpretem resultados, não apenas ajudem humanos a escrever código de treinamento.

A Databricks tem um ponto de partida distinto porque já gerencia dados empresariais, permissões e experimentos baseados em MLflow para muitos clientes. A empresa pode argumentar que levar a computação até dados governados reduz o trabalho de integração necessário para a pesquisa automatizada.

Essa vantagem não é automática. Uma plataforma estreitamente integrada pode simplificar um fluxo de trabalho enquanto torna a migração mais difícil. Equipes de pesquisa podem preferir agendadores portáteis, frameworks abertos de treinamento ou acesso direto à infraestrutura de nuvem quando precisam de configurações de rede incomuns.

O número de oito vezes também precisa ser interpretado com cautela. Mais jobs de treinamento não significam necessariamente oito vezes mais pesquisa útil. Os jobs podem diferir muito em duração, consumo de recursos, escopo e valor científico.

Um agente pode criar muitas execuções baratas de triagem antes de promover alguns candidatos a testes maiores. Isso seria eficiente. Também pode produzir experimentos repetitivos cujo valor marginal cai rapidamente.

A Databricks não publicou a distribuição por trás do aumento. Os leitores não sabem quantos jobs tiveram sucesso, quantos foram interrompidos automaticamente ou quanto tempo dos pesquisadores o fluxo de trabalho economizou. O número prova que a automação alterou o volume de trabalho, mas ainda não estabelece a produtividade da pesquisa.

Como o Databricks AI Runtime Mantém os Experimentos Automatizados em Movimento

O mecanismo central do AIR é um ciclo fechado de feedback construído com inicializações programáveis, verificações de integridade, métricas rastreadas e acesso governado a dados.

O ciclo começa quando um agente ou pesquisador propõe uma modificação. Essa mudança pode envolver uma receita de treinamento, arquitetura de modelo, conjunto de dados ou hiperparâmetro. O job é então executado dentro de um contêiner personalizado enviado pelas ferramentas da Databricks.

Usar o mesmo contêiner localmente e remotamente reduz a divergência entre ambientes. Os pesquisadores não precisam reconstruir uma pilha de software para cada execução distribuída. O Databricks Artifact Registry pode armazenar e compartilhar as imagens de contêiner usadas nos experimentos.

Em seguida, o AIR seleciona e provisiona os recursos solicitados. A Databricks afirma que suas otimizações de inicialização e de contêineres podem iniciar jobs de treinamento em segundos. Essa afirmação não foi comparada de forma independente com outras plataformas, mas a baixa latência de inicialização oferece suporte direto a experimentos repetidos por agentes.

Antes de uma carga de trabalho começar, a plataforma verifica se os nós de GPU atribuídos estão íntegros e conseguem se comunicar. Durante a execução, ela monitora condições que incluem problemas de driver de GPU, limitação térmica ou de energia e falhas de comunicação do NCCL.

NCCL é a biblioteca da NVIDIA para operações coletivas entre GPUs. Essas operações permitem que muitos processadores troquem atualizações de modelos durante o treinamento distribuído. Um único participante lento ou inacessível pode paralisar todo o grupo.

Quando o AIR identifica um nó não íntegro ligado a um job que falhou, a Databricks afirma que impede que jobs posteriores usem esse nó. O objetivo é evitar que uma falha de hardware cause falhas repetidas em vários experimentos.

A empresa explicou essa camada de confiabilidade em um relatório separado sobre integridade de GPU. Ele divide as falhas em travamentos visíveis, lentidões silenciosas e corrupção numérica.

Falhas visíveis são disruptivas, mas a degradação silenciosa pode ser mais cara. O treinamento distribuído geralmente avança na velocidade de seu worker mais lento. Uma GPU com limitação pode, portanto, reduzir a vazão de um cluster que, de outra forma, estaria íntegro.

A corrupção numérica apresenta um risco diferente. Um job pode ser concluído produzindo valores inválidos ou um modelo degradado. Um agente automatizado de pesquisa poderia então tratar um resultado ruim como evidência científica, a menos que o monitoramento detecte a falha subjacente.

A Databricks afirma que seu monitoramento abrange várias etapas. Testes de inicialização validam um nó antes de uma carga de trabalho começar. Verificações contínuas acompanham o hardware ativo, enquanto testes periódicos examinam a comunicação entre vários nós.

A empresa oferece uma ilustração útil de por que a escala importa. Usando uma premissa conservadora de um por cento ao ano para eventos de falha por GPU, a Databricks estimou que um trabalho de 30 dias com 256 GPUs enfrentaria cerca de 19 por cento de chance de um evento. Uma execução com 1.024 GPUs enfrentaria cerca de 57 por cento de chance.

Esses números são um modelo baseado em uma premissa, não taxas observadas de falhas do AIR. Ainda assim, explicam por que o tratamento de falhas não pode permanecer um caminho excepcional. Em escala suficientemente grande, eventos de hardware e rede tornam-se condições operacionais esperadas.

Após a execução de uma tentativa, o MLflow registra suas métricas e logs. O agente pode recuperar esses resultados, compará-los com execuções anteriores e decidir se mantém a alteração. Em seguida, atualiza seu plano e envia outra tentativa.

O acesso aos dados continua sendo governado pelo Unity Catalog durante todo esse ciclo. Isso é particularmente importante quando os experimentos usam documentos proprietários ou conjuntos de dados relacionados a clientes. O runtime não elimina questões de governança, mas mantém o acesso dentro de um sistema de permissões existente.

Juntos, esses elementos formam o mecanismo por trás do treinamento de agentes da Databricks. A plataforma só é valiosa quando cada etapa preserva contexto suficiente para a decisão seguinte. O agendamento sem métricas confiáveis não fecharia o ciclo. Métricas sem execução confiável poderiam recompensar ruído. Lançamentos automatizados sem governança poderiam criar uma exposição inaceitável de dados.

O Problema Mais Difícil É Alocar GPUs, Não Lançar Mais Trabalhos

Quando os agentes conseguem gerar experimentos continuamente, o recurso escasso passa a ser o acesso informado à capacidade computacional, e não as ideias de como utilizá-la.

A Databricks descreve cargas de trabalho de pesquisa com requisitos muito diferentes. Uma tarefa de depuração pode precisar de várias GPUs por um curto período. Um grande treinamento pode precisar de centenas delas por dias ou semanas. Ambos podem pertencer a projetos importantes com prazos sobrepostos.

O AIR inclui priorização e preempção de cargas de trabalho. A preempção pausa ou desloca trabalhos de menor prioridade para que tarefas urgentes possam usar os recursos necessários. A Databricks afirma que a capacidade ociosa de fim de semana pode sustentar experimentos exploratórios sem interromper pesquisas de maior prioridade.

Essa abordagem parece simples até que agentes autônomos entrem na fila. Agentes podem gerar trabalho muito mais rapidamente do que um comitê consegue analisar cada solicitação. Portanto, o agendador precisa refletir as prioridades de pesquisa antes de os trabalhos chegarem.

Uma política fraca pode criar diversos modos de falha. Experimentos automatizados curtos podem interromper repetidamente trabalhos mais longos. Um grande projeto pode reservar aceleradores escassos enquanto avança pouco. Agentes podem otimizar para seu próprio objetivo de avaliação sem considerar o valor de pesquisas concorrentes.

A utilização por si só não pode resolver essas escolhas. Uma frota pode permanecer ocupada enquanto produz resultados de baixo valor. A medida útil é o progresso por recurso restrito, algo muito mais difícil de definir entre projetos não relacionados.

Os trabalhos de treinamento também consomem mais do que tempo de GPU. Eles usam largura de banda de armazenamento, capacidade de rede, serviços de contêineres, rastreamento de experimentos e atenção dos pesquisadores. Oito vezes mais trabalhos podem revelar gargalos muito distantes dos aceleradores.

É aqui que a estratégia da Databricks confronta sua alternativa mais forte. As equipes podem montar uma infraestrutura modular de pesquisa com computação em nuvem, Kubernetes, agendadores de código aberto, armazenamento de objetos e ferramentas independentes de rastreamento. Esse caminho oferece flexibilidade e evita concentrar todo o fluxo de trabalho em uma única plataforma.

A rota integrada do AIR promete menos transferências entre sistemas. A Databricks gerencia o provisionamento de GPUs, registros de experimentos, dados governados e acesso programático dentro de um único sistema. A contrapartida é maior dependência das interfaces e premissas operacionais da Databricks.

Nenhuma das duas rotas vence para toda organização de pesquisa. Um laboratório de fronteira com experiência especializada em redes pode querer controle direto sobre cada camada. Uma equipe corporativa ajustando modelos perto de dados governados pode valorizar um fluxo de trabalho gerenciado mais do que a portabilidade da infraestrutura.

A Databricks está, na prática, apostando que a pesquisa conduzida por agentes aumenta o valor da integração. Uma pessoa consegue superar lacunas entre ferramentas com scripts e julgamento. Um processo autônomo precisa de interfaces previsíveis e estado legível por máquina em cada limite.

O mesmo ponto se aplica à memória institucional. Agentes precisam de acesso ao contexto dos experimentos, decisões anteriores e registros técnicos confiáveis. Equipes de engenharia que criam uma base de conhecimento pesquisável enfrentam um problema relacionado: informações armazenadas importam apenas quando os sistemas conseguem recuperar o contexto correto no momento certo.

No entanto, a integração não pode substituir o desenho da avaliação. Um experimento perfeitamente agendado ainda desperdiça capacidade computacional quando sua métrica não representa o comportamento desejado. Mais agentes podem amplificar um objetivo ruim com a mesma eficiência de um objetivo bom.

O Que o Aumento de Oito Vezes Não Mostra

A Databricks demonstrou maior throughput experimental, mas ainda não demonstrou ganhos proporcionais em qualidade de pesquisa ou eficiência computacional.

A publicação da empresa apresenta uma arquitetura detalhada e várias características concretas das cargas de trabalho. Ela não fornece um benchmark independente nem uma comparação controlada de antes e depois.

O aumento de oito vezes contabiliza trabalhos de treinamento. Ele não revela o total de horas de GPU, o tempo médio de fila, a utilização dos aceleradores, a frequência de execuções com falha ou o custo por melhoria aceita no modelo. Sem essas medidas, os leitores não conseguem separar o paralelismo produtivo da proliferação de trabalhos.

A qualidade do modelo é outra dimensão ausente. Agentes podem avaliar um alvo numérico claro, mas produtos reais frequentemente exigem vários objetivos concorrentes. A extração de documentos, por exemplo, pode envolver precisão, latência, formatação, comportamento multilíngue e tratamento de entradas incomuns.

Um ciclo de otimização pode melhorar um benchmark enquanto enfraquece outro. Ele também pode aprender a explorar fragilidades em um conjunto de avaliação. A revisão humana continua importante quando as medições não capturam todo o requisito do produto.

A Databricks aponta o KARL como exemplo de pesquisa que exige infraestrutura confiável. A pesquisa KARL da empresa aplica aprendizado por reforço a um agente de conhecimento corporativo. Trabalhos desse tipo combinam treinamento de modelos, interações geradas, avaliação e governança de dados.

Ainda assim, a existência de um projeto exigente não valida todos os benefícios alegados do AIR. A Databricks é tanto a operadora da plataforma quanto a parte que divulga os resultados. Sua equipe de pesquisa também é o “cliente zero”, o que cria um ciclo de feedback próximo, mas difere de uma implantação por cliente independente.

Equipes internas podem contatar diretamente os engenheiros da plataforma, tolerar interfaces pouco refinadas e influenciar o roteiro do produto. Usuários externos podem ter configurações de nuvem, requisitos de segurança ou canais de suporte diferentes.

A expressão “quase um trilhão” de parâmetros também precisa de contexto. A Databricks afirma que seus pesquisadores trabalham com modelos nessa faixa, mas não diz que todo modelo grande é treinado do zero. O ajuste fino e o aprendizado por reforço podem envolver perfis computacionais muito diferentes do pré-treinamento completo.

As alegações de confiabilidade merecem cuidado semelhante. Verificações pré-execução e quarentena de nós podem reduzir falhas repetidas, mas nenhuma camada de monitoramento detecta todas as falhas. Erros numéricos silenciosos continuam difíceis porque podem se assemelhar à instabilidade comum do treinamento.

Agentes autônomos também introduzem riscos de software que o monitoramento de hardware não consegue resolver. Um agente pode enviar uma configuração inválida, interpretar mal uma métrica ambígua ou selecionar repetidamente uma família de experimentos improdutiva. GPUs confiáveis podem executar um plano falho com alta eficiência.

Os controles de governança devem abranger ações, assim como dados. Um agente precisa de permissões suficientes para iniciar trabalhos e inspecionar resultados, mas acesso irrestrito elevaria riscos operacionais e de segurança. As equipes precisam de limites para recursos, conjuntos de dados, contêineres e comandos.

A empresa não divulgou como avalia decisões de agentes antes de execuções dispendiosas. Também não descreveu limites de aprovação, aplicação de orçamento, mecanismos de reversão ou a taxa com que humanos rejeitam propostas automatizadas.

Essas omissões não invalidam o fluxo de trabalho. Elas definem as evidências ainda necessárias. O caso futuro mais forte sobre como o Databricks AI Runtime funciona conectará o volume de trabalhos a melhorias aceitas, custos menores de falha e produtividade mensurável dos pesquisadores.

Três Sinais Determinarão se o Modelo Escala

A próxima etapa do Databricks AI Runtime será julgada por resultados úteis por GPU, adoção independente e salvaguardas em torno da experimentação autônoma.

O primeiro sinal é um benchmark de eficiência mais completo. A Databricks deve conectar o aumento de oito vezes nos trabalhos ao tempo de fila, às taxas de conclusão bem-sucedida, à utilização de GPUs e às melhorias aceitas nos modelos.

Um benchmark útil distinguiria pequenas tentativas de triagem de longas execuções distribuídas. Também informaria o denominador por trás de qualquer ganho de produtividade alegado. Mais experimentos importam quando identificam decisões melhores com uso igual ou menor de recursos.

Evidências de menor desperdício de computação fortaleceriam o argumento da Databricks. O aumento de horas de GPU sem ganhos comparáveis de pesquisa o enfraqueceria. O mesmo ocorreria se os agentes gerassem grandes volumes de novas tentativas, trabalhos redundantes ou resultados inconclusivos.

O segundo sinal é a adoção por clientes externos. A equipe interna de pesquisa da Databricks se beneficia do acesso direto aos engenheiros que construíram o AIR. Equipes independentes mostrarão se o fluxo de trabalho se transfere entre organizações.

Os estudos de caso mais convincentes descreveriam restrições reais, em vez de repetir alegações de lançamento. Os leitores devem observar evidências envolvendo múltiplos projetos, conjuntos de dados governados, treinamento distribuído e ciclos de experimentos controlados por agentes.

Clientes externos também devem relatar resultados operacionais. Latência de lançamento, recuperação de falhas, comportamento da fila e tempo gasto gerenciando infraestrutura seriam mais úteis do que declarações gerais sobre inovação mais rápida.

A adoção ampla reforçaria a ideia de que a Databricks pode transformar sua plataforma de dados em um plano de controle para pesquisa em IA. O uso limitado fora dos projetos de cliente zero sugeriria que a integração depende de conhecimento interno ou de condições excepcionalmente favoráveis.

O terceiro sinal é o modelo de governança para agentes de pesquisa. A Databricks precisa mostrar como as equipes limitam o uso de recursos, validam alterações propostas, isolam contêineres, auditam ações e interrompem um ciclo que não está gerando valor.

Controles claros sustentariam o argumento da empresa de que corporações podem automatizar a pesquisa sem abrir mão da supervisão. Controles fracos fariam o aumento de oito vezes parecer menos produtividade e mais demanda descontrolada.

As respostas dos concorrentes fornecerão outra pista dentro desse sinal. Plataformas de IA gerenciadas provavelmente tornarão seus agendadores, telemetria e sistemas de avaliação mais fáceis de operar por agentes. A Databricks precisará competir em qualidade mensurável do fluxo de trabalho, não apenas na disponibilidade de uma API.

A lição mais ampla já parece duradoura. Agentes de IA mudam os requisitos de infraestrutura antes de comprovarem que podem substituir o julgamento científico. Eles aumentam o número de decisões, trabalhos, logs e caminhos de falha que um sistema de pesquisa precisa administrar.

A Databricks construiu uma resposta coerente em torno de computação programável, MLflow, Unity Catalog e monitoramento da integridade das GPUs. Sua implantação interna mostra que esses componentes podem sustentar um volume muito maior de experimentos.

A questão não resolvida é se esse volume produz modelos melhores de forma eficiente. Desenvolvedores e compradores corporativos devem pedir métricas de resultados, distribuições de falhas e detalhes de governança antes de tratar a automação em si como progresso.

Para equipes que estão avaliando o Databricks AI Runtime, o próximo passo prático é definir um ciclo de pesquisa delimitado e medi-lo de perto. Acompanhe os testes concluídos, as descobertas úteis, as horas de GPU, as intervenções humanas e as propostas rejeitadas. Em seguida, compare esses resultados com uma linha de base conduzida por pesquisadores. O valor da plataforma surgirá dessas evidências, e não apenas da quantidade de tarefas.