Andrew Eun "Paixão pelo aprendizado de máquina". Tradução dos capítulos 47-58



Este é o segundo artigo com uma tradução de capítulos individuais do livro de Andrew Un, Passion for Machine Learning. Você pode ler a tradução dos capítulos anteriores aqui .

Este artigo se concentrará no aprendizado profundo de ponta a ponta, assim como o autor do livro compartilhará algumas maneiras de analisar os erros do algoritmo de aprendizado.

Aprendizagem profunda de ponta a ponta



Capítulo 47. O crescimento da aprendizagem de ponta a ponta



Suponha que você deseje criar um sistema para verificar as análises de produtos na Internet, que informará automaticamente se o autor da revisão gostou ou não deste produto. Por exemplo, você espera reconhecer a seguinte análise como muito positiva:

  • "Este é um ótimo esfregão!"

e o seguinte é extremamente negativo:

  • “Esta esfregona é de má qualidade, desculpe pela compra”

O problema de reconhecer opiniões positivas e negativas é chamado de "classificação de humor". Para criar esse sistema, você pode criar um "pipeline" de dois componentes:

  1. Analisador : Um sistema que anota texto com informações, identificando as palavras mais importantes. 1 Por exemplo, você pode usar o analisador para indicar todos os adjetivos e substantivos. Portanto, você receberá o seguinte texto anotado:

    • Este é um ótimo esfregão!

    1 De fato, o analisador anota o texto muito mais rico do que o descrito, mas essa descrição simplificada será suficiente para explicar o aprendizado profundo de ponta a ponta.

  2. Classificador de sentimentos : um algoritmo de aprendizado que recebe entrada de texto anotado e prevê seu humor geral. As anotações do analisador podem ser de grande ajuda para esse algoritmo: dando mais peso aos adjetivos, seu algoritmo pode ser rapidamente lembrado ao processar palavras importantes como "excelente" e ignorar palavras menos importantes como "isso".

Podemos visualizar esse pipeline de dois componentes da seguinte maneira:



Recentemente, houve uma tendência a substituir os pipelines por um único algoritmo de aprendizado. Um algoritmo de aprendizado de ponta a ponta para essa tarefa simplesmente pegaria o texto original e bruto "This is a great mop!" Como entrada e tentaria reconhecer diretamente seu humor:



Redes neurais são comumente usadas em sistemas de aprendizado de ponta a ponta. O termo "passagem" refere-se ao fato de solicitarmos ao algoritmo de aprendizado que vá diretamente da entrada para o resultado desejado. Ou seja, o algoritmo de aprendizado conecta diretamente o "final de entrada" do sistema ao "final de saída".

Nas tarefas em que há muitos dados, os sistemas ponta a ponta têm sido extremamente bem-sucedidos. Mas eles nem sempre são uma boa escolha. Os próximos capítulos darão mais exemplos de sistemas transversais, além de dicas sobre quando e quando não usá-los.


Capítulo 48. Exemplos adicionais de aprendizado transversal



Imagine que você deseja criar um sistema de reconhecimento de fala. Você pode construir um sistema de três componentes:



Os componentes funcionam da seguinte maneira:

  1. Funções computacionais: recupere recursos projetados manualmente, como MFCC ( coeficientes de cepstro de frequência de mel ), que tentam capturar o conteúdo de uma declaração enquanto ignoram propriedades menos importantes, como o passo na dinâmica.
  2. Reconhecimento de fonemas: alguns linguistas acreditam que existem unidades básicas de som chamadas "fonemas". Por exemplo, o som inicial "k" em "keep" é o mesmo fonema que o som "c" em "cake". Este sistema tenta reconhecer fonemas individuais em gravações de áudio.
  3. End Recognizer: pega uma sequência de fonemas reconhecidos e tenta vinculá-los a um registro de saída.

Em contraste com esse "pipeline", o sistema de ponta a ponta pode receber uma gravação de áudio na entrada e tentará transferi-la diretamente para a gravação de saída:



Até agora, descrevemos apenas "transportadores" completamente lineares de aprendizado de máquina: a saída é transmitida sequencialmente de um estágio para outro. Mas os transportadores podem ser mais complexos. Por exemplo, aqui está uma arquitetura simples para um veículo não tripulado:



Este transportador inclui três componentes: um detecta outros carros usando a imagem da câmera, o segundo detecta pedestres e, finalmente, o último componente calcula o caminho do nosso carro para evitar colisões com outros carros e pedestres.

Nem todos os componentes deste pipeline serão treinados. Por exemplo, a literatura sobre "planejar o movimento de robôs" descreve muitos algoritmos para o cálculo final do percurso de um carro. Muitos desses algoritmos não requerem treinamento.

Pelo contrário, a abordagem de ponta a ponta pode tentar receber leituras do sensor e girar diretamente o volante na direção certa:



Embora o treinamento de ponta a ponta tenha levado a muitos sucessos, essa nem sempre é a melhor abordagem. Por exemplo, o reconhecimento de fala de ponta a ponta funciona bem. Mas sou cético em relação ao treinamento transversal de direção autônoma para sistemas não tripulados. Os próximos capítulos explicam o porquê.


Capítulo 49. Treinamento transversal: prós e contras



Considere o exemplo anterior do pipeline de reconhecimento de fala:



Muitas de suas partes são projetadas "manualmente":

  • MFCC é um conjunto de recursos de áudio especialmente projetados. E, embora eles forneçam um resumo razoável de todo o áudio recebido na entrada, eles também simplificam o sinal recebido ao descartar algumas informações.
  • Os fonemas são uma invenção dos linguistas. Eles são uma representação imperfeita dos sons da fala. Como os fonemas são uma aproximação aproximada da realidade, um algoritmo que usa fonemas para representar a fala limitará a eficácia de todo o sistema de reconhecimento de fala.

  • Os sinais da MFCC são robustos para certas propriedades da fala que não afetam o conteúdo, como a afinação do orador. Assim, eles ajudam a simplificar a tarefa do algoritmo de aprendizado.
  • Na medida em que os fonemas são uma representação razoável da fala, eles também podem ajudar o algoritmo de aprendizado a entender os componentes básicos do som e, portanto, aumentar sua eficácia.

Ter mais componentes projetados à mão na maioria das vezes permite que um sistema de reconhecimento de fala aprenda com menos dados. O conhecimento obtido “manualmente” usando MFCC e fonemas “complementa” o conhecimento que nosso algoritmo obtém dos dados. Quando temos poucos dados, esse conhecimento é útil.

Agora considere o sistema de ponta a ponta:



Este sistema não possui conhecimento suficiente obtido "manualmente". Portanto, quando o conjunto de treinamento é pequeno, esse sistema pode funcionar pior do que um transportador projetado manualmente.

No entanto, quando o conjunto de treinamento é grande, não há restrições devido ao uso de MFCC ou fonemas. Se o algoritmo de aprendizado é uma rede neural suficientemente grande e se é treinado em um conjunto de treinamento suficientemente grande, ele tem um grande potencial e talvez até se aproxime da taxa de erro ideal.

Os sistemas de ponta a ponta tendem a ser bem-sucedidos quando há muitos dados marcados para ambas as extremidades - o "final de entrada" e o "final de saída". Neste exemplo, precisamos de um grande conjunto desses pares (áudio e transcrição). Quando dados desse tipo não estiverem disponíveis para você, aborde o aprendizado com muito cuidado.

Se você estiver trabalhando em uma tarefa de aprendizado de máquina na qual o conjunto de treinamento é muito pequeno, a maioria das informações disponíveis para o seu algoritmo será obtida graças à sua compreensão humana, ou seja, de componentes projetados manualmente.

Se você preferir não usar um sistema de ponta a ponta, precisará decidir quais etapas serão no seu pipeline e como elas devem se encaixar. No próximo capítulo, ofereceremos algumas idéias para projetar esses sistemas.


Capítulo 50. Seleção de Componentes de Pipeline: Disponibilidade de Dados



Quando você constrói um transportador que não é um sistema de ponta a ponta, quais componentes desse transportador serão uma boa escolha? Como você projeta o transportador afetará bastante o desempenho geral do sistema. Um fator importante é a capacidade de coletar dados com facilidade para treinar cada componente.

Por exemplo, considere esta arquitetura de direção autônoma:



Você pode usar algoritmos de aprendizado de máquina para detectar carros e pedestres. Além disso, não é difícil para eles coletar dados: existem muitos conjuntos prontos de dados de visão por computador com um grande número de carros e pedestres marcados. Você também pode usar o crowdsourcing (como o Amazon Mechanical Turk) para obter conjuntos de dados ainda maiores. Portanto, será relativamente fácil coletar dados de treinamento para criar um detector de carro e um detector de pedestres.

Pelo contrário, considere um sistema limpo de ponta a ponta:



Para treinar esse sistema, precisamos de um grande conjunto de elementos já mapeados (imagem = volante girando na direção certa). Essa é uma tarefa muito demorada e cara. Para coletar esses dados, é necessário que as pessoas dirijam carros e registrem dados sobre cada volta do volante. Você precisará de toda uma frota de carros especialmente equipados e um grande número de horas de trabalho para cobrir a maior variedade possível de situações. Isso torna o sistema de ponta a ponta muito difícil de aprender. É muito mais fácil tirar um grande conjunto de imagens rotuladas de carros e pedestres.

Em um sentido mais geral, se houver muitos dados disponíveis para o treinamento de módulos transportadores "intermediários" (como um detector de carro ou um detector de pedestres), será necessário pensar em usar um transportador composto por vários componentes. Esse método pode funcionar melhor, porque Você pode usar todos os dados disponíveis para treinar módulos intermediários.

Até que haja mais dados para modelos de ponta a ponta, acredito que a abordagem tradicional é muito mais promissora para direção autônoma: sua arquitetura combina melhor com a disponibilidade atual de dados.


Capítulo 51. Escolhendo Componentes do Transportador: Simplicidade da Tarefa



Além da disponibilidade de dados, você também deve considerar o segundo fator ao escolher componentes de pipeline: quão simples são as tarefas que os componentes individuais resolvem? Você deve tentar selecionar os componentes do transportador para que sejam fáceis de construir ou aprender. Mas o que significa um componente ser fácil de aprender?



Considere as seguintes tarefas de aprendizado de máquina, listadas em ordem crescente de complexidade:

  1. A definição é superexposta à imagem apresentada (como no exemplo acima).
  2. Determinar se uma imagem é tirada em ambientes internos ou externos.
  3. Determinando se há um gato na imagem.
  4. Determinando se há um gato na imagem com pêlo preto e branco.
  5. Determinação da existência de um gato siamês na imagem (qualquer raça específica de gatos).

Para cada um desses problemas de classificação binária, é necessário obter uma imagem na entrada e na saída 0 ou 1. Mas as tarefas listadas anteriormente na lista parecem ser mais fáceis de aprender nas redes neurais. Você pode treinar o algoritmo para tarefas mais simples com menos exemplos de treinamento.

No estágio atual do aprendizado de máquina, não há uma boa definição formal do que torna uma tarefa fácil ou difícil. 2 Com o crescimento da aprendizagem profunda e das redes neurais multicamadas, às vezes chamamos o problema de fácil, se ele pode ser resolvido com menos etapas de cálculo (por exemplo, usando redes neurais com um pequeno número de camadas), e chamamos a tarefa de difícil se exigir mais etapas. computação (que corresponde a uma rede neural profunda). Mas esta é uma definição informal.
2 Na teoria algorítmica da informação, existe o conceito de complexidade de Kolmogorov, que afirma que a complexidade da função que está sendo estudada é a duração do menor programa de computador que pode produzir essa função. Este conceito teórico encontrou várias aplicações práticas em IA.

Se você tiver a oportunidade de dividir uma tarefa complexa em subtarefas mais simples, codificando com precisão cada subtarefa, você fornecerá ao algoritmo um conhecimento mais importante que pode ajudá-lo a resolver com mais eficiência todo o problema.



Imagine que você está projetando um detector de gato siamês. Aqui está uma arquitetura de ponta a ponta limpa:



Pelo contrário, você pode usar um transportador de dois componentes:



Na primeira etapa (detector de gato), todos os gatos da imagem serão reconhecidos.



Em seguida, na segunda etapa, as imagens colhidas de cada um dos gatos detectados, uma de cada vez, são transferidas para o classificador da raça. E finalmente, se algum dos gatos detectados for um gato siamês, obtemos "1" na saída.



Comparado ao ensino de um classificador puramente de passagem que usa apenas tags 0/1, cada um dos dois componentes no pipeline (detector de gatos e classificador de raças) parece mais fácil de aprender e requer significativamente menos dados. 3
3 Se você estiver familiarizado com os algoritmos de detecção de objetos que são realmente utilizados na prática, entenderá que eles são treinados não apenas com os rótulos de imagem 0/1. Em vez disso, eles são treinados usando a estrutura restritiva fornecida como parte dos dados de treinamento. A discussão deles está além do escopo deste capítulo.

E o último exemplo, lembremos novamente o pipeline da tarefa de direção autônoma:



Usando esse transportador, você informa ao algoritmo que existem três etapas principais na condução de um carro:

  • Reconheça outros carros.
  • Reconheça pedestres.
  • Planeje a direção de mais movimentos.

Cada uma dessas etapas é uma tarefa mais simples e pode ser treinada com menos dados do que com uma abordagem puramente transversal.

Como resultado, ao decidir quais devem ser os componentes do pipeline, tente criar um pipeline em que cada componente seja uma função relativamente "simples" que só possa ser treinada em uma pequena quantidade de dados.


Capítulo 52. Aprendendo com informações imersivas



O algoritmo de classificação de imagem pega uma imagem de entrada X e produz um número inteiro, que é um rótulo para a categoria do objeto. Em vez disso, o algoritmo pode emitir uma frase inteira descrevendo a imagem?

Por exemplo:



Y = "Um ônibus amarelo está dirigindo pela estrada em meio a árvores e grama verde."

A aplicação tradicional do ensino com um professor envolve a presença de uma função treinada h: X → Y, onde a saída (y) é geralmente representada por um número inteiro ou natural. Por exemplo:

DesafioXY
AntispamE-mailSpam / Não Spam (0/1)
Reconhecimento de imagemImagemRótulo inteiro
Previsão de Preços ImobiliáriosCaracterísticas da casaPreço em dólares
Recomendação do produtoEspecificações do produto e do clienteProbabilidade de compra


Uma das coisas mais empolgantes sobre a aprendizagem profunda transversal é que ela nos permite aprender diretamente Y, o que é muito mais complicado que os números. No exemplo da tarefa de descrição da imagem mencionada acima, você pode aplicar alguma imagem (x) à entrada da rede neural e obter uma descrição imediata (y) na saída.

Aqui estão alguns exemplos:

DesafioXYCitação do trabalho
Descrição das ImagensImagemTextMao e outros, 2014
Tradução automáticaTexto em inglêsTexto em francêsSuskever e outros, 2014
Respostas às perguntasPar (texto + pergunta)Resposta à perguntaBordes e outros, 2015
Reconhecimento de falaÁudioTranscriçãoHannun e outros, 2015
Conversão de texto em falaTags de textoÁudioVan der Oord et al., 2016


Essa é uma tendência crescente no aprendizado profundo: quando você tem os pares rotulados (entrada e saída) corretos, às vezes pode escolher um treinamento de ponta a ponta, mesmo se a saída for uma frase, imagem, áudio ou qualquer outra saída que contenha muito mais informações, do que apenas números de etiqueta única.

Análise de erro parcial


Capítulo 53. Análise de erros em partes



Suponha que seu sistema seja construído usando um sofisticado pipeline de aprendizado de máquina e você gostaria de melhorar a eficiência do sistema. Qual parte do transportador você deve melhorar? Atribuindo erros a partes específicas do pipeline, você pode decidir como priorizar seu trabalho.

Vamos usar nosso exemplo de classificador de gatos siameses:



A primeira parte, um detector de gatos, detecta gatos e os corta para fora de toda a imagem. A segunda parte, o classificador de raças de gatos, decide se esse gato é um gato siamês. Você pode passar anos trabalhando para melhorar qualquer um desses dois componentes do transportador. Como você decide em qual componente focar?

Executando a análise de erros em partes, você pode tentar atribuir cada erro do algoritmo a uma das duas partes do pipeline (e às vezes as duas ao mesmo tempo). Por exemplo, o algoritmo classifica incorretamente essa imagem como não contendo um gato siamês (y = 0), embora o rótulo correto seja y = 1.



Vamos verificar manualmente o que o algoritmo faz em cada uma das duas etapas. Suponha que um detector de gato siamês detectou um gato da seguinte maneira:



Isso significa que o classificador da raça de gato receberá esta imagem:



O classificador da raça classifica corretamente esta imagem como não contendo um gato siamês. Portanto, o classificador de raças de gatos é inocente: ele recebeu um punhado de pedras na entrada e deu uma nota bastante razoável y = 0. De fato, uma pessoa que classifica a imagem cortada acima também prediz y = 0. Portanto, você pode atribuir claramente esse erro a detector de gato.

Por outro lado, se um detector de gato exibir a seguinte caixa delimitadora:



então você concluiria que o detector de gatos fez seu trabalho corretamente e o erro ocorreu devido ao classificador da raça.

Suponha que você tenha passado por 100 imagens classificadas incorretamente de uma amostra de validação e encontrado 90 erros relacionados a um detector de gatos e apenas 10 erros relacionados a um classificador de raça de gato. Você pode concluir com segurança que deveria se concentrar mais em melhorar o seu detector de gatos.

Além disso, você também encontrou com sucesso 90 exemplos em que o detector de gato trouxe a caixa delimitadora errada. Você pode usar esses 90 exemplos para uma
análise mais profunda dos erros do detector de gatos e ver como melhorá-los.

Nossa descrição de como atribuir o erro a uma parte do pipeline até agora tem sido informal: você analisa a saída de cada parte e vê se consegue decidir qual cometeu o erro. Este método informal pode ser suficiente. Mas no próximo capítulo, você também verá uma maneira mais formal de atribuir erros.


Capítulo 54. Atribuição de erro a uma parte específica



Vamos continuar com o nosso exemplo:



Suponha que o detector de gato tenha produzido esta caixa delimitadora:



Assim, o classificador da raça recebeu essa imagem cortada, após a qual emitiu incorretamente y = 0, ou seja, que não há gato na foto.



O detector de gatos fez um mau trabalho. Enquanto uma pessoa treinada, sem dúvida, será capaz de reconhecer o gato siamês nesta imagem cortada. Portanto, atribuímos esse erro a um detector de gatos, a um classificador de raças ou a ambos? Claro.

Se o número de casos controversos for pequeno, podemos tomar qualquer decisão e obter um resultado semelhante. Mas aqui está um teste mais formal, que permite atribuir com mais precisão o erro a exatamente uma parte:

  1. Substitua a saída do detector de gato por um quadro marcado manualmente.
  2. Passe a imagem cortada correspondente pelo classificador da raça. Se o classificador de raça ainda não classificar a imagem corretamente, atribua o erro ao classificador de raça. Caso contrário, atribua o erro ao detector de gato.

Em outras palavras, conduza um experimento no qual você envia dados ideais para a entrada do classificador de rochas. Nesse caso, são possíveis 2 opções:

  1. Mesmo com um quadro ideal, o classificador de raças erroneamente y = 0. Nesse caso, o classificador é sem dúvida o culpado.
  2. Tendo recebido um quadro ideal, o classificador da raça corretamente y = 1. Isso mostra que, se apenas o detector de gatos produzisse uma caixa delimitadora mais perfeita, a conclusão geral do sistema estaria correta. Assim, atribuímos o erro ao detector de gato.

Depois de executar essa análise de imagens classificadas incorretamente a partir da amostra de validação, agora você pode atribuir inequivocamente cada erro a um componente. Isso permite estimar a proporção de erros associados a cada componente do pipeline e, portanto, decidir em que focar sua atenção.


Capítulo 55. O caso principal de atribuição de erros



Aqui estão as etapas gerais para atribuir erros. Suponha que o pipeline tenha três estágios A, B e C, onde A é alimentado diretamente para B e B é alimentado diretamente para C.



Para cada erro que o sistema comete na amostra de validação:

  1. Tente substituir manualmente a saída do estágio A pela saída "ideal" (ou seja, caixa delimitadora "ideal" para o gato)) e continue com o restante do transportador B, C por essa saída. Se o algoritmo agora produzir o resultado correto, isso indica que apenas o estágio A deve melhorar sua própria saída para que todo o algoritmo funcione corretamente. Portanto, você pode atribuir esse erro ao componente A. Caso contrário, vá para a etapa 2.
  2. Tente substituir manualmente a saída do estágio B pela saída "perfeita". Se o algoritmo inteiro começar a funcionar corretamente, atribua o erro ao componente B. Caso contrário, vá para a etapa 3.
  3. Atribua o erro ao componente C.

Veja um exemplo mais complexo:



Seu drone usa este transportador. Como, usando a análise de erro fragmentada, para determinar em qual componente focar?

Você pode marcar os componentes da seguinte maneira:

  • A. Reconhecer carros.
  • B. Reconhecer pedestres.
  • C. Planeje o caminho.

Seguindo o procedimento descrito acima, suponha que você teste seu carro em um campo de treinamento fechado e encontre um caso em que o carro escolha uma manobra em uma direção mais nítida do que um motorista experiente faria. No mundo da direção não tripulada, esse evento é geralmente chamado de script. Nesse caso:

  1. A ( ) «» (.. ). B C , C ( ) «» A. , , A , . A. 2.
  2. B ( ) «» . , B. 3.
  3. C.

Os componentes do pipeline de aprendizado de máquina devem ser organizados de acordo com um gráfico acíclico direcionado (DAG), o que significa que você deve poder calculá-los em alguma ordem fixa da esquerda para a direita, e os componentes posteriores devem depender apenas das saídas dos componentes anteriores. Desde que a
disposição dos componentes na ordem A → B → C corresponda à ordem do DAG, a análise de erro continuará corretamente.

Você pode obter resultados ligeiramente diferentes se você trocar A e B:

  • A. Reconhecer peões (anteriormente reconhecimento de automóveis)
  • B. Reconhecer carros (anteriormente reconhecimento de pedestres)
  • C. Planeje o caminho do seu carro

Mas o resultado dessa análise ainda permanecerá verdadeiro e dará uma boa orientação sobre o que você deve focar sua atenção.


Capítulo 56. Análise de erros em partes e comparação com eficiência no nível humano



A condução de uma análise de erro em um algoritmo de aprendizado é semelhante ao uso da ciência de dados para analisar erros do sistema ML, a fim de ter uma idéia do que fazer em seguida. Na maioria dos casos, uma análise de erro fragmentada nos dirá qual componente vale a pena tentar melhorar acima de tudo.

Digamos que você tenha algum conjunto de dados sobre clientes que compram itens em um site. Um cientista de dados pode analisar dados de várias maneiras diferentes. Ele pode tirar muitas conclusões diferentes sobre se o site deve aumentar os preços, o valor dos clientes adquiridos por meio de várias campanhas de marketing e assim por diante. Não existe uma maneira “certa” única de analisar um conjunto de dados; existem muitas idéias úteis possíveis que podem surgir. Da mesma forma, não existe uma maneira "certa" de analisar erros. Nesses capítulos, você aprendeu alguns dos padrões de design mais comuns para obter informações úteis sobre o seu sistema ML, mas também pode experimentar livremente outros métodos de análise de erros.

De volta ao aplicativo de veículo não tripulado, no qual o algoritmo de detecção de carro exibe a localização (e possivelmente a velocidade) dos carros próximos, o algoritmo de detecção de pedestres exibe a localização dos pedestres mais próximos e essas duas saídas são finalmente usadas para planejar o caminho do carro.



Para depurar esse pipeline e não seguir estritamente o procedimento que você viu no capítulo anterior, você pode fazer as seguintes perguntas:

  1. A que distância está o algoritmo de reconhecimento de carro da eficiência humana na solução de um problema semelhante?
  2. Qual a distância do algoritmo de reconhecimento de pedestres do desempenho humano na solução de um problema semelhante?
  3. ? , , ( ). , « » , ?

Se você achar que um dos componentes do sistema está longe da eficiência humana, terá uma boa oportunidade de se concentrar em melhorar a eficácia desse componente.

Muitos processos de análise de erro funcionam melhor quando tentamos automatizar algo que uma pessoa pode fazer; portanto, comparamos os resultados com os de uma pessoa. A maioria dos exemplos anteriores tinha essa suposição implícita. Se você estiver construindo um sistema de ML no qual a saída final ou alguns dos componentes intermediários fazem coisas que nem uma pessoa consegue fazer bem, alguns desses procedimentos não se aplicam.

Essa é outra vantagem de trabalhar em problemas que as pessoas podem resolver - você possui ferramentas mais poderosas para analisar erros e, portanto, pode priorizar com mais eficiência o trabalho de sua equipe.


Capítulo 57. Detecção de Erros no Pipeline ML



E se cada componente individual do seu transportador ML mostrar eficiência no nível humano ou um pouco mais baixo, mas o transportador geral não corresponder ao nível humano? Normalmente, isso significa que o transportador tem falhas e precisa ser redesenhado. A análise de erros também pode ajudá-lo a descobrir se seu pipeline precisa ser redesenhado.



No capítulo anterior, colocamos a pergunta: cada um dos três componentes mostra eficiência no nível humano? Suponha que a resposta para todas as três perguntas seja afirmativa. Então:

  1. , , () .
  2. , , () .
  3. , , , , , ( ).

No entanto, seu veículo não tripulado lida com a condução significativamente pior do que uma pessoa. Ou seja, as pessoas que têm acesso às imagens da câmera podem planejar o caminho do carro muito melhor. Que conclusão você pode tirar?

A única conclusão possível é que seu pipeline de ML não foi projetado corretamente. Nesse caso, o componente que planeja o caminho do carro funciona, além de permitir dados recebidos que não contêm informações suficientes. Você deve se perguntar que outras informações que não estão na saída dos dois componentes anteriores são necessárias para um excelente planejamento do percurso do carro. Em outras palavras, que outras informações são usadas por um motorista experiente?

Suponha que você entenda que um motorista humano também precisa ver as marcações na estrada. Isso sugere que você deve fazer engenharia reversa do pipeline da seguinte maneira: 4


4 , , . «Task simplicity», 51, , . « » — , / .

Por fim, se você acha que seu pipeline como um todo não será capaz de alcançar a eficiência humana, mesmo que cada componente individual tenha eficiência no nível humano (lembre-se de que você está comparando com uma pessoa que tem a mesma entrada que o componente) , esse transportador tem desvantagens e deve ser reprojetado.

Conclusão


Capítulo 58. Crie uma super equipe, compartilhe esse conhecimento com os camaradas



Parabéns por completar este livro!
No capítulo 2, falamos sobre como este livro pode ajudá-lo a se tornar um super-herói em sua equipe.


A única coisa que pode ser melhor do que ser um super-herói é fazer parte de uma equipe de super-heróis. Espero que você compartilhe cópias deste livro com seus amigos e colegas de equipe e ajude a criar outros super-heróis!

Source: https://habr.com/ru/post/pt485190/


All Articles