O guia definitivo para começar com IA
Uma pincelada passo a passo de como começar seu projeto
Traduzido por Victor Tseimazides do original de Cassie Kozyrkov
Muitos times tentam começar um projeto de IA aplicada por mergulhar em algoritmos e dados antes de descobrir os outputs e objetivos desejados. Infelizmente, isto é como criar um cachorrinho em um apartamento em Nova Iorque por alguns anos e então se surpreender que ele não consiga guiar ovelhas por aí.
Você não pode esperar que irá conseguir algo de útil pedindo aos magos que espalhem a magia da aprendizagem de máquina (machine learning, em inglês) no seu negócio sem algum esforço seu antes.
Ao invés disso, o primeiro passo é que o dono — esse é você! — forme uma visão clara do que quer do seu cão (ou sistema de AM/IA) e de como saber que você o treinou com sucesso.
Meu artigo anterior discutiu o porquê, agora é hora de mergulhar no como dar este primeiro passo para Aprendizagem de máquina (AM)/Inteligência Artificial (IA), com todas as suas pequenas sub-etapas.
Este guia de referência é densamente compactado e longo, então sinta-se à vontade para se atentar apenas às letras grandes e títulos para um curso intensivo de dois minutos ou vá direto para a versão resumida do checklist. Eis o índice:
- Descubra quem está no comando
- Identifique o caso de uso
- Faça algumas verificações da realidade
- Crie uma métrica de desempenho com sabedoria
- Defina critérios de testes para superar vieses humanos
Elenco de personagens: tomador de decisão, eticista, engenheiro de ML/IA, analista, especialista qualitativo, economista, psicólogo, engenheiro de confiabilidade, pesquisador de IA, especialista em domínio, especialista em UX, estatístico, teórico de controle de IA.
Descubra quem está no comando
As tarefas que estamos prestes a atacar são de responsabilidade do adulto responsável pelo projeto. Este é aquele que toma as decisões. Se um pesquisador PhD é selecionado para este papel, deve ser por causa da habilidade daquela pessoa em tomar decisões e seu profundo conhecimento do seu negócio. Se você está prestes a colocá-lo(a) neste papel e depois desconfia dele(a), você escolheu a pessoa errada. A entidade que estamos chamando de Tomador de Decisão (pode ser uma pessoa ou um comitê) é aquele que deve dar a palavra final. Eleja seu benevolente ditador com sabedoria.
Se o tomador de decisão é alguém que você planeja desconfiar mais tarde, você está fazendo isto errado.
Se o tomador de decisão não é bem versado na arte e ciência de tomada de decisões, há uma solução: faça uma dupla com um especialista qualitativo. Mas se a pessoa no comando não entende do seu negócio, você também pode apenas economizar esse dinheiro agora.
Identifique o caso de uso
Foque nos outputs
O ponto chave é que AM/IA não é mágica e não resolve todos os problemas. É um rotulador de coisas e é sua responsabilidade descobrir o que você precisa que seja rotulado.
Rotulação de coisas não significa somente classificação — “Esta foto é um gato ou não?” — isto não é pensar suficientemente grande. Por rótulo eu quero dizer output. Pode ser uma categoria, um número, uma frase, uma forma de onda, um ID de grupo, uma ação única, um movimento de joystick, uma sequência de ações, Sim/Não para se algo é uma anomalia…são tantas possibilidades!
Não contrate aquele guru PhD antes de ter confirmado que você precisa dele. Foque nos outputs primeiro.
Se você leu meu artigo recente sobre como algoritmos funcionam, você terá notado que o artigo deu como certo que vale a pena rotular xícaras de chá como gostei/não gostei. Quem decidiu gastar o tempo de todo mundo com este caso de uso estúpido?! Como ele ajuda o negócio? Este rotulador deveria mesmo existir? Supondo que possa ser feito, vale a pena construí-lo?
Este é o tipo de trabalho que você está fazendo agora, meu amigo. É a primeira coisa a ser feita.
Só porque você pode fazer algo, não significa que é um bom uso do tempo de qualquer um.
Imagine que seu sistema de AM/IA está operacional e se pergunte se você está feliz em ter gastado recursos da empresa para fazê-lo. Não? Continue fazendo brainstorm. Melhor descobrir que ninguém precisa da sua aplicação antes que vários PhDs gastem suas vidas nisso.
Esta tarefa pode ser difícil porque há tantas opções, então se acomode em um sofá confortável e medite. Experimente meu exercício da ilha dos bêbados se você precisar de uma ajudinha no brainstorm.
Agora não é hora de inputs
Alguns dos seus caras de decisão são incrivelmente fluentes com dados. Você pode falar sobre inputs e outputs tudo de uma vez…e você entende a diferença. Meu conselho pode te surpreender: resista à tentação! Simplesmente não fale de inputs ainda. Sério. Eu sei que você pode, mas não o faça. Aqui vão dois de vários motivos.
Motivo 1: Oportunidades perdidas
Este é o óbvio. Alguns dos seus stakeholders não são tão fluentes como você e eles se confundem facilmente. No começo, você pode estar falando sobre suas ideias para eles esperando garantir recursos para o seu projeto e você realmente não quer que eles entendam mal o porquê vale a pena ter seu sistema. Não confunda eles! Continue focado(a). Diga a eles o que você faz, não como você faz.
Pergunte a si mesmo, “Este é o fim ou o meio?” Se é o meio, não fale sobre isso por enquanto.
O problema com muitas das pessoas fluentes é que você pensa que elas compartilham da sua fluência. Algumas pessoas absolutamente brilhantes em tecnologia me surpreenderam por não ter esta habilidade, então agora eu sei não dar isso como certo.
Para algumas pessoas, dados são dados. É tudo a mesma coisa. (Caro leitor, se você não tem certeza se você é fluente nisso, realmente se force a diminuir o ritmo. Continue se perguntando: “Isto é o fim ou o meio?” Certifique-se que você foque no fim agora.) Stakeholders podem não conseguir seguir a linha do seu argumento, o que significa que seu discurso irá por água abaixo e você irá perder a chance de fazer o mundo mais incrível com IA.
Motivo 2: Acordo tácito
Sendo uma engenheira que vive no meio de engenheiros por bastante tempo, eu percebi que o nosso tipo de gente adora se ater aos detalhes. Que a visão do todo vá pro inferno, é tão divertido apresentar cada pequeno detalhe, especialmente quando alguém está errado sobre algo. Nós amamos quando há algum rigor técnico.
Então eis a tragicomédia: quando você gastou as últimas 6 horas argumentando com seus amigos sobre se a variável x (bruta, padronizada, ou normalizada?) é um bom input com registro adequado para prever um output y, você normalizou a ideia de que y vale a pena. Você pára de perguntar qual o ponto em trabalhar somente em y em primeiro lugar e acaba construindo coisas que não precisam ser construídas.
Isto é sobre o uso para as multidões
Vamos imaginar que automatizar a rotulação S/N de chás é o caso de uso que você escolheu. Certifique-se que você não está pensando em rotular apenas uma ou duas xícaras. AM/IA fazem sentido para automatizar várias decisões repetidas. Não é para usar uma única vez.
ML/IA não é para ser usado uma única vez, então se certifique que seu negócio precisa de um número incrível de itens a ser rotulados.
Você está imaginando rotular pelo menos alguns milhares? E quando estiver implementado, você tem certeza que você não pode apenas procurar a resposta ao invés de prevê-la? Ótimo. Vamos continuar.
Pegue uma caneta, escreva todos os rótulos que você vai aceitar (binário S/N neste exercício é fácil de escrever, mas você poderia ter escolhido fazê-los mais exóticos se você precisasse ser mais criativo). Escreva como você saberia se a resposta é certa para um deles. Escreva como os erros seriam. Espere erros em aprendizagem de máquina! Se você espera perfeição, é melhor recuar calmamente antes que a decepção esmague a sua alma.
Você pode não estar preparado para aprendizagem de máquina
Ainda tendo dificuldades para escolher um caso de uso? Considere dar uma pausa em AM/IA em favor de análise de dados por um tempo. O objetivo da análise de dados é gerar inspiração para o tomador de decisão. Uma vez que você está inspirado, você pode voltar para AM/IA e começar de novo. Análise de dados (também conhecido por mineração de dados, em inglês data mining) é uma grande ideia para todos os projetos, enquanto AM/IA é apenas para os projetos nos quais o objetivo é usar dados para automatizar a rotulação de coisas. Embora a matemática por detrás seja frequentemente a mesma, os processos são muito diferentes. Mineração de dados é sobre maximizar a velocidade da descoberta, enquanto AM/IA é sobre performance na automação. Em mineração de dados, há apenas um erro que seu time pode cometer, enquanto AM/IA tem uma lista incrível de coisas com potencial de arruinar seu projeto. Aventure-se nesta dor de cabeça apenas quando tiver um caso de uso que valha a pena.
Para quem é isso? Pense nos seus usuários!
Para quem é a sua invenção deslumbrante? Quem se beneficia? Essa é uma ótima hora para consultar um especialista de UX (experiência do usuário, em inglês user experience) e mapear os usuários previstos para o seu aplicativo.
Idealizar novas tecnologias frequentemente começa com o “quê”, mas é importante cobrir o “quem” antes de proceder para o “como”.
Algo que aprendi passando tempo com designers de UX é que minha descrição padrão de quem são meus usuários…geralmente é bastante ingênua. Eu pensei sobre usabilidade para beneficiários indiretos, para a sociedade como um todo, para outros negócios, para sistemas de máquinas usando os outputs como inputs e assim por diante? Para evitar um design de UX ruim, por favor aproveite para pensar sobre todas as categorias diversas de usuários antes de seguir em frente. Usuário não significa apenas o cliente ou o usuário final no sentido mais óbvio.
É ético seguir em frente?
E se sua ideia não for uniformemente benéfica a todos? Enquanto estiver mapeando seus casos de uso ideais, considere aqueles que poderiam ser prejudicados pela existência do seu sistema. Eu não digo apenas competidores na sua indústria. Algum humano poderia ser prejudicado pela sua aplicação? Isto é especialmente importante se sua tecnologia for dimensionada para milhões ou bilhões.
Pense sobre os humanos que sua criação impacta! Quem se beneficia e quem pode ser prejudicado?
Se você se importa em desenvolver tecnologia de uma maneira ética e responsável, é seu dever pensar sobre todas as pessoas que sua criação poderia afetar. Pensar sobre eles depois que você já a construiu é irresponsável. A hora para isso é agora! Um eticista pode ajudá-lo a tirar um pouco do peso nos ombros. Trazê-los a bordo como consultores é uma grande ideia se o seu projeto tem o potencial de afetar fortemente o bem-estar humano. Junto do seu especialista de UX, a participação deles em um projeto irá te ajudar a garantir que os grupos afetados pela sua criação terão voz.
Faça algumas verificações da realidade
Uma vez que você pode articular claramente quais os rótulos que você vai escolher, é hora de uma rápida verificação da realidade: você tem dados sobre este problema?
Falta de acesso a dados significa que não faz sentido seguir em frente. Apesar de que você pode conseguir o que precisa online — há uma tendência crescente em disponibilizar dados gratuitamente (por exemplo aqui).
Porém ainda precisam ser relevantes. Você sabe que não pode usar meus padrões de consumo de marmita para prever o nível de açúcar no sangue. Dados inúteis claramente não valem. Você não precisa analisar dados ainda (isso será mais tarde no projeto) mas você precisa checar que você realmente tem algo a analisar quando a hora chegar. Falta de dados significa ficar sem AM/IA.
Sem acesso a dados relevantes ou sem computadores para processá-los? Não tem um jeito bom de dizer isso…
Você também precisará verificar que você tem a potência computacional para processar seus dados. (Você já ouviu falar do meu empregador? Eles têm bastante e gostam de compartilhar. Só estou dizendo.)
Verificação da realidade
Certifique-se que você pode responder sim a todos estes pontos. Cada um deles é provável de ganhar seu próprio guia no futuro — fique ligado. Esta é apenas uma passada rápida em questões para identificar um projeto que não deve ser iniciado.
- Tarefa apropriada: Você está automatizando várias decisões/rótulos? Onde você não pode simplesmente procurar a resposta perfeita a cada vez?
- Expectativas razoáveis: Você entende que o seu sistema pode ser excelente, mas não será sem falhas? Você pode viver com o erro ocasional?
- Possível em produção: Independentemente de de onde vem estas decisões/rótulos, você será capaz de serví-los em produção? Você pode reunir os recursos de engenharia para fazer isso na escala que está antecipando? Você irá olhar para esta questão em mais detalhes quando se sentar com engenheiros, mas, por enquanto, o vislumbre de um teste de sanidade será suficiente.
- Dados de onde aprender: Existem inputs potencialmente úteis? Você consegue acesso a eles? (É ok se os dados não existem ainda, mas você precisa ter um plano para coletá-los em breve.)
- Exemplos suficientes: Quando você está tomando algo com o seu amigo estatístico ou engenheiro de aprendizagem de máquina e você casualmente menciona o número de exemplos disponíveis e o tipo de resultado que você está querendo, a expressão deles é livre de restrições? (Vou te ensinar como desenvolver esta intuição em um artigo futuro.)
- Computadores: Você tem acesso a poder computacional suficiente para lidar com o tamanho da sua base de dados? (Tecnologias de nuvem fazem disso um sim automático para qualquer pessoa aberta a considerar usá-las.)
- Time: Você está confiante que pode montar um time com as habilidades necessárias?
- Verdade absoluta: A menos que você esteja atrás de aprendizado não-supervisionado, você tem acesso aos resultados? Se não, você pode pagar seres humanos para fazê-los por você, realizando a tarefa?
- Sanidade de registro: É possível dizer qual input vai com qual output, certo?
- Qualidade de registro: Você confia que os dados são realmente o que seus provedores dizem ser? (Para aprender com exemplos, você precisa de bons exemplos para aprender.)
Monte seu time
Uma vez que você zerou a lista de verificação de realidade, é hora de começar a recrutar, o que você pode fazer em paralelo com o restante deste guia. Meu conselho sobre os papéis que você procura estão aqui.
Crie uma métrica de desempenho com sabedoria
Saiba como balancear
A próxima parte pode ser um pouco complicada se você for novo nisso. Você é encarregado de decidir quanto vale cada tipo de resultado. A xícara de chá nojenta que ganhou um S é duas vezes pior que a deliciosa que perdemos? 3.4823 vezes? Você é quem sabe!
Tendo dificuldades? Pegue alguém que goste de números e peça ajuda para um brainstorm. Especialistas qualitativos são especialmente treinados para isto, mas uma pessoa boa com números fará isso rapidinho. Se você quer a melhor ajuda, convoque um economista.
Economistas acabam sendo conselheiros surpreendentemente úteis para projetos de IA.
Agora que você já descobriu como balancear vários resultados em uma única saída, é hora de pensar sobre como você gostaria de pontuar alguns milhares deles de uma vez. Usar a média é uma escolha média, mas você não precisa ser médio. De novo, o tomador de decisão é o chefe aqui. O jeito certo de pontuar depende do que é certo para o seu negócio.
(Opcional) Modo especialista é pesado em simulações
Projetos complicados e complexos se beneficiam tremendamente de simulações. É aí que um analista especializado em gerar dados falsos mas plausíveis pode te ajudar em ver as potenciais consequências das escolhas que vocês está fazendo neste artigo.
Um bom ensaio ajuda a noite de gala correr tranquila.
Simulação te dá um bom ensaio, que te ajuda a resolver um monte de coisinhas antes de você ter de começar seu projeto pra valer. Como em análise de dados, é necessário tirar um pouco da carga do mandato do tomador de decisão para meditar bastante e pensar em tudo.
Faça sua métrica
Existem diferentes jeitos de fazer uma métrica. No nosso exemplo do chá, você poderia ir pela mais simples: acuracidade, vulgo “Não esteja errado.” Cada erro é igualmente ruim (0), cada resposta correta é igualmente boa (1), então você tira a média (que você estava se coçando para tirar — alguém precisa colocar um limite central no quão atraente as pessoas acham as médias).
Espera aí, talvez ao invés disso você tenha FOMO (fear of missing out ou medo de ficar por fora, em português) quando se trata de bons chás e você está feliz em ter insucessos ao longo do caminho? Bem, isto é uma métrica diferente chamada recall (às vezes traduzido como revocação). Ou talvez você não queira gastar seu tempo e você precisa ter certeza de que quando o sistema diz “Gostoso” realmente irá valer a pena beber, mas não há problemas em perder chás bons. Esta é uma métrica completamente diferente chamada de precisão. Vamos desacelerar e nos aprofundar em métricas em um outro post. Por ora, esqueça como elas são chamadas, apenas invente uma que reflita aquilo que for certo para o seu negócio.
Precisa de ajuda? Seu economista já se foi? Sem problemas! Talvez você tenha um amigo que ama criar jogos? Geeks dos jogos têm treinado para isto sem saber a vida toda! Se você não anda com essa turma, você pode chamar seu especialista qualitativo, já que é o trabalho dele ajudar o tomador de decisão a esclarecer suas opiniões nesse tipo de coisa.
Peça para um especialista revisar
Em aplicações nas quais o bem-estar humano está substancialmente em risco, procure se consultar com um painel de especialistas para verificar se não é possível obter uma pontuação alta na sua métrica de uma maneira perversa e prejudicial.
Quais especialistas? Você conhece aquela em que um tomador de decisão, um eticista, um teórico de controle de IA, um estatístico, um pesquisador de experiência de usuário, um economista comportamental, um especialista de domínio e um engenheiro de confiabilidade vão para um bar…?
Claro, isso pode ser exagerado em aplicações de negócios benignas, então a familiaridade básica do seu especialista qualitativo com cada uma dessas disciplinas te garante e os instintos do seu amigo criador de jogos também te levam por um caminho bastante similar.
Olá, métrica de desempenho de negócios!
Quando você terminar, você vai ouvir um coro angelical. Você criou sua métrica de desempenho de negócios!
Isto não é a mesma coisa que uma função de perda (vamos falar sobre elas mais tarde). Quando se trata de métricas, as possibilidades são infinitas e cabe ao tomador de decisão descobrir o que é realmente importante. Caso você esteja ansioso para lidar com isso, estou preparando mais alguns artigos para te ajudar a dominar o desenvolvimento de métricas.
(Alerta de jargões) Algo que seus especialistas de IA deveriam saber
Aqui vai uma coisa com nuances que você pode pular até descobrirmos mais sobre em um post posterior, mas se você sabe o que é uma função de perda, irá perceber que temos duas métricas em jogo. Se isto não significa nada para você, não vamos nos preocupar com isso agora, seu trabalho aqui é apenas se assegurar que seus especialistas de AM/IA leiam o próximo parágrafo. Muitos deles perderam esta aula na faculdade. Aviso: muitos tomadores de decisão vão achar que a leitura parece um pesadelo cheio de jargões sem sentido — minhas desculpas! — então basta seguir em frente.
A função de perda é para otimização, não para testes.
“Em AM/IA aplicada, a função de perda serve para otimização, não para teste estatístico. Teste estatístico deve perguntar, “Isto funciona bem o suficiente para ser construído/lançado?”, onde “funciona” deveria ser definido pelo problema de negócios e o seu dono. Você não deve alterar seu problema de negócio para se adequar às suas ambições de otimização. Por conveniência, você é livre para otimizar usando uma função padrão de perda que se move na mesma direção da função que a imaginação do seu líder acabou de gerar (faça verificação de correlação* analiticamente ou com simulações), mas por favor teste com a função dele.** Você tem usado perda para todas as avaliações? Não se preocupe, é um erro comum que pode ter algo a ver com padrões de software, formato do curso na faculdade, e absenteísmo de tomador de decisão em IA.”
** Se nenhuma função padrão de perda correlaciona decentemente com a métrica de desempenho, por favor alerte seu tomador de decisão agora que o que ele está pedindo é muito difícil e provavelmente requer investimento em pesquisadores de otimização.
** Tendo divergência com os especialistas de IA, leia isto. Apesar de não ser sobre funções, a ideia geral sobre trabalhar com tomador de decisão é válida.
Defina os critérios de testes
Defina sua população de interesse
Falar sobre o funcionamento do seus sistema não faz sentido até que você especifique em quais instâncias você pretende que ele funcione. Todos os inputs do verão dos EUA? Todos os inputs globais? (Isto é diferente!)
Antes de prosseguir, você precisa definir sua população estatística de interesse, a ampla coleção de instâncias em que seu sistema precisa demonstrar boa performance antes de dar a luz verde. Tenho um guia de duas partes para você caso precise dar uma atualizada sobre isso.
Comprometa-se a descartá-lo!
Agora que você tem sua métrica de desempenho e sua população à mão, você tem mais um trabalho a fazer antes de colocar os pés para cima. Já que chegar aqui pode levar meses, seus pobres pés devem estar muito doloridos.
Eis a última tarefa: decidir sobre o desempenho mínimo que você está disposto a aceitar, pois estou prestes a te fazer prometer que você não vai deixar este sistema assumir a rotulação por você a menos que ele seja bom o bastante.
O que significa “bom o bastante”? Quão criterioso você deveria ser? Fica a seu critério, mas você precisa se comprometer agora.
Definir o critério de antemão faz parte de como você se mantém (e a mim) a salvo de aprendizagem de máquina e IA horríveis.
Este critério não é uma estrela-guia. Você também pode ter um nível de desempenho que você pede para seu time alcançar (perfeição?), mas não é isso o que você vai testar. Teste contra o mínimo.
Você tem uma espécie tendenciosa
Por que você está inventando este corte agora, antes mesmo de montar um time para este projeto? Acontece que como membros da espécie humana, nós sofremos de alguns adoráveis vieses cognitivos (não diga custo irreparável/sunk cost ou efeito de doação ou viés de confirmação a menos que você queira que aquele economista apareça do nada de novo, desta vez com um psicólogo a reboque) que se resumem a isto: quando humanos investem tempo e esforço em algo, nós nos apaixonamos por aquilo que fizemos… mesmo que isso seja um monte de lixo venenoso. Então nos encontramos negociando: “Ah, mas o desempenho não é tão ruim. Estou até orgulhosa de 12% de acuracidade. Talvez nós possamos lançá-lo mesmo assim? Por que eu não testo de novo com 10%? Viu? Ele passa. É estatisticamente significativamente bom o bastante.”
Se você quer se afundar nesse triste assunto comigo por mais 6min, quem sou eu para te parar?
Nós humanos nos apaixonamos com o que pusemos esforço… mesmo que isto seja um monte de lixo venenoso.
Enquanto ainda estamos sóbrios(!) e antes que coloquemos muito de nós mesmos nisso, vamos dar uma olhada fria e dura no problema de negócios e dizer, “Se ele não atender a este requisito mínimo, prometo que MORRERÁ.”
Melhor que humanos?
Espero que agora você tenha uma ideia do porquê sou forçada a reprimir uma risada quando me perguntam, “IA é melhor do que os humanos nas coisas?”
Melhor que humanos? As redundâncias são redundantes.
Se seu criador exigisse que o sistema fosse melhor que humanos e fizesse o teste propriamente, então se não fosse melhor que humanos… eles o descartariam. Se ele existe, então sim. A menos que eles não exigissem que fosse melhor que humano, o que neste caso, provavelmente não é. Por que as pessoas estão me perguntando? Pergunte àqueles tomadores de decisão como eles definem seus critérios e testes. (Falando em populações, o sistema é supostamente melhor do que quais humanos? Aquele único voluntário?)
Além disso, não vamos ficar muito obcecados sobre se as máquinas são ou não melhores que nós nas coisas. Meu computador sempre foi melhor que eu … em multiplicar. Isto não me incomoda nem um pouco. Meu balde é melhor do que eu para segurar água. Qual o ponto de uma ferramenta se ela não reduz seu esforço ou aumenta o que você pode alcançar?
Ao invés disso, foque em se é bom o bastante para ser útil.
Não demande tanto
Sempre exigir desempenho melhor que o humano pode fazer com que você perca o lucro. É um pouco como dizer que você só irá contratar um medalhista de ouro olímpico para assentar tijolos para você. Talvez um atleta olímpico seja melhor que o seu cara médio, mas ter uma barra tão alta para contratação pode te deixar sem opções. Diminua a barra para onde eles fazem bom sentido para os negócios, mas não abaixo disso. Definir a barra de testes para o seu mínimo é compatível com incentivos, como diria um economista. (Se você acaba de sair do MBA e quer gastar seu conhecimento em design de mecanismos, estamos essencialmente configurando um leilão de BDM para nosso procedimento de teste de hipóteses.)
Não perca uma solução rentável testando-a contra uma barra excessivamente alta.
Às vezes automação oferece menor qualidade por unidade que produtos artesanais, mas a escala e velocidade da máquina fazem isto valer a pena para o seu negócio. Isso vale a pena para o seu negócio? Ei, você está no comando, não eu. Boa sorte!
Para um resumo curto para este longo texto, veja a versão checklist.
Este é o passo número um de AM/IA feito! O passo número dois envolve dados e hardware (e engenheiros!), então você pode querer retocar o seu vocabulário em antecipação às próximas atrações.
Se você achou que alguma das ideais deste guia vale a pena, conte-as a sejá lá quem em sua rede for mais provável de se encontrar no papel de decisão. Vamos construir uma nova safra habilidosa e responsável de líderes de IA para um futuro brilhante de IA!
Aprenda mais sobre ciência de dados e inteligência artificial em português.
