Quando as empresas implementam ferramentas de IA empresarial, descobrem frequentemente que o seu lago de dados pode ser profundo, mas é confuso. Mesmo que comecem com dados cuidadosamente seleccionados, uma má gestão das alterações de dados pode ter consequências graves a jusante.
Chad Sanderson é o CEO e fundador da Gable.ai, onde ajuda as organizações a melhorar a qualidade dos dados em escala.
Tive oportunidade de falar com ele sobre a importância da qualidade dos dados e sobre a forma como os contratos de dados podem garantir que as aplicações baseadas em grandes quantidades de dados mantêm a sua integridade.
P: Tem experiência como jornalista. Quer contar-nos como acabou por se dedicar aos dados e como se apaixonou pela ciência dos dados e pela qualidade dos dados?
Chad Sanderson: "A ciência dos dados foi algo que comecei a praticar como jornalista porque tinha o meu próprio sítio Web e precisava de configurar a análise da Web. Aprendi tudo sobre o GA4, comecei a fazer testes A-B, ciência de dados muito básica. Depois, gostei tanto que passei a trabalhar a tempo inteiro, aprendi estatística e acabei por ir trabalhar para a Oracle como analista e cientista de dados.
Depois, comecei a gerir equipas no domínio dos dados. No início, era mais nas equipas de experimentação e análise. Depois, comecei a dedicar-me mais à engenharia de dados e, por fim, às infra-estruturas, às plataformas de infra-estruturas de dados.
Trabalhei na plataforma de Inteligência Artificial da Microsoft. E também liderei a plataforma de IA e de dados numa empresa de tecnologia de transporte de mercadorias em fase avançada chamada Convoy."
P: Falou recentemente no MDS Fest sobre contratos de dados e como isso permite às empresas ter esta governação de dados federada. Quer explicar brevemente do que se trata?
Chad Sanderson: "Os contratos de dados são uma espécie de mecanismo de implementação da governação de dados federados e da gestão de dados federados.
Basicamente, no mundo antigo, ou seja, no mundo legado, on-prem, há 20 anos, havia arquitectos de dados que construíam todo um ecossistema de dados numa empresa, a começar pelas bases de dados transaccionais, os sistemas ETL, todos os vários mecanismos que transformam os dados e, basicamente, os preparam para análise e ciência de dados e IA.
E todos esses dados foram fornecidos aos cientistas por uma equipa centralizada. Pode pensar-se nisto da mesma forma que um bibliotecário gere uma biblioteca.
Asseguram a entrada e saída de livros, a organização dos livros, o que facilita aos investigadores encontrar a informação de que necessitam para os seus projectos.
Mas o que aconteceu 15 anos depois, 20 anos depois, foi que passámos para a nuvem e para os engenheiros de software, e o software comeu o mundo, como diz Mark Andreessen, e todas as empresas decidiram tornar-se uma empresa de software. A forma como as empresas geriam os negócios de software consistia em permitir que as equipas de engenharia se movessem o mais rapidamente possível para criar aplicações de uma forma super iterativa e experimental.
Isto significava que todos os dados que estas aplicações estavam a gerar já não estavam sujeitos ao planeamento da estrutura e à forma como foram concebidos e organizados pelo arquiteto de dados. Bastava pegar em toda esta informação e atirá-la para um local chamado lago de dados. E o lago de dados era muito confuso.
A responsabilidade de dar algum sentido a todo este tipo de informação pantanosa recaiu sobre o engenheiro de dados. Assim, é possível viver um pouco em ambos os mundos, com uma camada de aplicação descentralizada e totalmente federada e uma camada de dados muito, muito centralizada e equipas de engenharia de dados a fazer o seu melhor para lhes dar algum sentido.
O contrato de dados é um mecanismo para que as equipas de dados a jusante e as equipas de engenharia de dados digam: "Estamos a começar a utilizar estes dados de uma determinada forma.
Temos algumas expectativas em relação a eles. E isso significa que os engenheiros que criam os dados assumem a sua propriedade da mesma forma que um arquiteto de dados assumiria a propriedade de todo o sistema um ano antes. E é isso que permite que a governação e a qualidade sejam dimensionadas.
Se não tivermos isso, ficamos com este tipo de situação caótica".
P: E é o tipo de situação em que o lixo entra e sai. Se alterarmos algo muito pequeno nos nossos dados, isso pode ter ramificações profundas a jusante.
Chad Sanderson: "Sim, é exatamente isso. E há muitas empresas que tiveram impactos realmente infelizes nos seus modelos de IA apenas por alterações relativamente pequenas que os criadores de aplicações não consideram importantes.
Por exemplo, digamos que está a recolher o aniversário de alguém porque quer enviar-lhe automaticamente uma mensagem de aniversário muito bonita.
Pode estar a armazenar essa informação de aniversário em três colunas com o mês, o ano e a data de aniversário. Pegamos em toda essa informação e podemos fazer algumas coisas interessantes com ela. Mas se o engenheiro disser: "Sabes que mais, dividir isto em três colunas diferentes é uma estupidez.
Só quero ter uma coluna para a data. Não há problema. E eles vão fazer isso porque torna a sua aplicação mais fácil de utilizar.
Mas quem está a jusante e está a utilizar esses dados está à espera de três colunas. Por isso, se amanhã só receberem uma e as duas que estavam a utilizar desaparecerem, tudo o que tinham construído vai por água abaixo.
É o tipo de coisa que está sempre a acontecer nas empresas".
P: É o diretor executivo de uma empresa chamada Gable. Quais são alguns dos principais desafios que as empresas enfrentam e que espera resolver? Como é que a vossa plataforma aborda alguns desses problemas?
Chad Sanderson: "O maior desafio que ouvimos da maioria das empresas que estão a entrar no espaço da IA e do ML, pelo menos do lado dos dados, são realmente duas coisas. A primeira é a propriedade. Ou seja, se sou alguém que está a construir sistemas de IA, estou a construir os modelos, preciso de alguém que se aproprie dos dados que estou a utilizar e que se certifique de que esses dados são tratados como uma API.
Se é um engenheiro de software e depende da aplicação de outra pessoa, está a fazê-lo através de uma interface. Essa interface está bem documentada. Tem expectativas muito claras.
Existem SLAs. Espera-se que o sistema funcione durante um determinado período de tempo. Se houver bugs, alguém vai lá e corrige-os.
E é por esta razão que se pode sentir confortável em depender de aplicações que não são apenas as que construiu. E em dados, é isso que estamos a fazer quando extraímos dados do conjunto de dados de outra pessoa, como uma base de dados, por exemplo. E depois estamos a construir um modelo em cima disso.
Estamos a depender de uma interface, mas atualmente não há muita propriedade sobre essa interface. Não existe um verdadeiro SLA. Não há muita documentação.
Pode mudar a qualquer altura. E se fosse assim que as APIs funcionassem, todo o nosso ecossistema da Internet estaria num caos. Nada funcionaria.
Por isso, o que muitas empresas e equipas de dados anseiam neste momento é a capacidade de confiar que os dados que estão a utilizar serão amanhã os mesmos que eram ontem. Essa é uma parte. E um dos resultados realmente essenciais disso é a qualidade dos dados.
Preocupamo-nos em garantir que os dados correspondem às nossas expectativas. Digamos que estou a trabalhar com alguns dados de expedição e estou a consumir algumas informações sobre distâncias de expedição de mercadorias. Esperaria sempre que essa funcionalidade de distância de transporte significasse aquilo que espero que signifique e não significasse subitamente uma coisa diferente, certo?
Se eu disser que esta é a distância de envio em milhas, amanhã não quero que de repente signifique quilómetros, porque a IA não vai saber que mudou de milhas para quilómetros. Ela não tem o contexto para entender isso.
O objetivo da Gable é garantir que essas expectativas e SLAs muito claros estão em vigor, que todos os dados que as equipas estão a utilizar para a IA são claramente propriedade da empresa e que toda a organização compreende a forma como as diferentes pessoas dentro da empresa estão a utilizar os dados e onde esse amor e cuidado são realmente necessários".
P: Grande parte da ênfase é colocada na garantia da qualidade dos dados para permitir a IA, mas a IA está a permitir-lhe fazer isso melhor?
Chad Sanderson: "A IA é espetacular, francamente. Penso que estamos a meio de um ciclo de moda, sem dúvida, 100%.
Por isso, as pessoas vão fazer algumas afirmações sobre o que a IA pode fazer que são bizarras. Mas penso que se formos realistas e nos concentrarmos apenas no que a IA pode fazer neste momento, já existe muito valor acrescentado para a nossa empresa em particular. Assim, o principal valor acrescentado da Gable, o que fazemos de forma diferente de todos os outros, é a interpretação de códigos.
Gable não é uma ferramenta de dados. Somos uma ferramenta de engenharia de software concebida para as complexidades dos dados. E podemos interpretar código que, em última análise, produz dados para descobrir o que esse código está a fazer.
Assim, se eu tiver, digamos, um evento que está a ser emitido a partir de um sistema de front-end, e sempre que alguém clica num botão, há um código que diz: "Este botão foi clicado". Quero enviar um evento chamado botão clicado para uma base de dados. E depois, a partir dessa base de dados, vamos enviá-lo para o nosso lago de dados.
E depois, a partir do nosso lago de dados, enviamo-lo para modelar o treino de um sistema de IA. E o que o Gable pode fazer é dizer que, se um engenheiro de software decidir alterar a forma como o evento do botão clicado no código está estruturado, o que teria um impacto em toda a gente a jusante, podemos reconhecer que isso aconteceu durante o processo DevOps.
Por isso, quando um engenheiro de software está a consultar o GitHub e a fazer alterações ao seu código, pode dizer, oh, espere um segundo, antes de fazer esta alteração, detectámos que algo correu mal aqui.
Grande parte dessa interpretação de código foi desenvolvida utilizando mais aprendizagem automática e métodos baseados em análise estática.
Mas a IA, que é muito hábil no reconhecimento de convenções, como padrões de codificação comuns, faz um excelente trabalho ao fornecer contexto sobre o motivo pelo qual as pessoas estão a fazer alterações no código ou qual é a sua intenção. Por isso, há muitas formas interessantes de aplicar a IA ao nosso produto em particular."
P: Se as empresas quiserem tirar partido da IA, vão precisar de dados. Quais são, na sua opinião, as maiores oportunidades para as empresas gerirem e desenvolverem os seus dados? Como é que elas podem capitalizar e preparar-se para isso?
Chad Sanderson: "Por isso, penso que todas as empresas que pretendem tirar partido da IA têm de elaborar uma estratégia de dados. E penso que haverá duas estratégias de dados que serão hiper-relevantes para todas as empresas.
A primeira é que, neste momento, os grandes modelos iterativos, os LLM, os LLM públicos que todos conhecemos, como OpenAI, Nuvem, Gemini, AnthropicA Comissão Europeia, por seu lado, está a utilizar principalmente dados disponíveis ao público, dados que se podem obter na Internet.
E isto tem definitivamente utilidade para um modelo amplo e geral. Mas um dos desafios com estes LLMs é algo chamado janelas de contexto, ou seja, quanto mais informação têm para raciocinar, pior é o seu trabalho. Assim, quanto mais restrita for a tarefa que lhes pudermos fornecer com uma quantidade limitada de contexto, mais eficazes serão.
É como uma pessoa, certo? Se eu lhe der a informação de um livro e depois lhe perguntar sobre um parágrafo muito específico na página 73, a sua capacidade de se lembrar dele será provavelmente baixa. Mas se eu lhe der apenas um capítulo para ler, é provável que faça um trabalho muito melhor.
Por isso, penso que muitos destes modelos gerais não vão ser tão úteis para as grandes empresas. E vamos começar a ver modelos cada vez mais pequenos que são mais orientados para o contexto. Portanto, são baseados em contextos mais pequenos.
E a forma de obter um contexto de alta qualidade e bem sintonizado é através da obtenção de dados excelentes e bem sintonizados sobre esse aspeto específico, seja ele qual for, que estamos a analisar. E penso que os dados se vão tornar o fosso competitivo para a maioria das empresas.
Por isso, penso que esse vai ser um grande investimento que muitas empresas vão ter de fazer. Precisamos de recolher o máximo de dados de alta qualidade possível para os podermos introduzir nestes modelos e não utilizar os modelos mais amplos com janelas de contexto mais alargadas."
P: Como é que coisas como o GDPR e a CCPA na Califórnia vão afetar a forma como as pessoas ou as empresas lidam com a qualidade e a segurança dos dados?
Chad Sanderson: "Penso que o RGPD e a CCPA são bons exemplos de como muitas empresas estão preocupadas com a regulamentação destes modelos generativos no futuro.
Mesmo que os Estados Unidos digam "isto está bem", se a UE decidir que não está, em última análise, temos de aplicar estas normas a toda a gente, certo? O grande problema do RGPD é que não é possível saber se um cliente que acede ao seu sítio Web é da Europa ou dos Estados Unidos.
E, certamente, é possível fazer a geolocalização e coisas do género. Mas pode haver um europeu nos Estados Unidos que esteja a utilizar a sua aplicação e o RGPD não discrimina entre essa pessoa e alguém que esteja a viver na Europa. Tem de ter a capacidade de os tratar da mesma forma.
E isso significa que, efetivamente, é preciso tratar todos os clientes da mesma forma, porque não se sabe quem é a pessoa que está do outro lado. E isso exige muita governação, muita inovação tecnológica muito interessante, muitas mudanças na forma como se lida com o marketing e coisas do género. E penso que, provavelmente, vamos assistir a algo semelhante com a IA quando a regulamentação começar a ser aplicada.
A Europa já está a começar a pressionar nesse sentido. E é por isso que é mais seguro para muitas empresas fazerem as suas próprias coisas, certo? Eu tenho o meu próprio jardim murado.
Estou a utilizar apenas os dados que recolho das nossas próprias aplicações. E esses dados não estão a sair. Não estamos a seguir os clientes pela Internet.
Estamos apenas a analisar os padrões de utilização efectiva dos nossos serviços. Penso que isso se vai tornar muito importante. Outra coisa que penso que se vai tornar importante são os fornecedores de dados.
Assim, os fornecedores de dados existem há muito tempo, ou seja, os dados como um serviço, em que se diz: "Olha, vou fornecer-te informação actualizada sobre o tempo e tu pagas-me para ter acesso a essa informação. E sou eu que já passei pelos obstáculos de a tornar segura, acessível e fiável. E certifico-me de que a qualidade dos dados é elevada.
Isso já está a acontecer. Mas penso que isso vai explodir nos próximos cinco a dez anos se precisarmos de dados que não podemos recolher nas nossas próprias aplicações internas. E penso que, nesse mundo, o conceito destes contratos vai tornar-se ainda mais importante.
E isso vai estar associado a um contrato literal. Se estou a pagar para que os dados tenham um determinado aspeto, tenho certas expectativas em relação a eles.
Não espero que esses dados mudem subitamente da última vez que mos deu para hoje, porque agora podem realmente ter um impacto no meu modelo de aprendizagem automática, que tem um impacto nos meus resultados.
Interagimos diariamente com ferramentas de IA, mas quase nunca pensamos nos dados em que estes modelos se baseiam. A curadoria e a gestão de dados vão ser cruciais, especialmente para as empresas que estão a implementar a IA internamente."
A curadoria de dados, a gestão da qualidade e o controlo vão tornar-se mais cruciais à medida que as empresas criam produtos que dependem de dados consistentemente bons.
Se quiser saber mais sobre contratos de dados e como tirar o máximo partido dos dados da sua empresa, pode contactar Chad Sanderson ou saber mais em Gable.ai.
