IA não deveria perder tempo reinventando ETL

O progresso recente na IA é muito empolgante. As pessoas o estão usando de várias maneiras inovadoras, desde melhorar as experiências de suporte ao cliente e escrever e executar códigos, até criar novas músicas e até mesmo acelerar a tecnologia de imagens médicas.

Mas, no processo, surgiu uma tendência preocupante: a comunidade de IA parece estar reinventando a movimentação de dados (também conhecida como ETL). Independentemente de chamá-los de conectores, extratores, integrações, carregadores de documentos ou qualquer outra coisa, as pessoas estão escrevendo o mesmo código para extrair dados das mesmas APIs, formatos de documentos e bancos de dados e, em seguida, carregá-los em bancos de dados vetoriais ou índices para seus LLMs.

O problema é que construir e manter oleodutos robustos de extração e carregamento do zero é um grande compromisso. E há tanta arte anterior nessa área que, para quase todos os engenheiros ou empresas no setor de IA, é uma grande perda de tempo reconstruí-la. Em um espaço onde notícias de última hora surgem aproximadamente a cada hora, o foco principal deve ser tornar seu produto principal incrível para seus usuários, não fazer missões secundárias. E para quase todos, o produto principal não é a movimentação de dados; é o molho mágico alimentado por IA que você está preparando.

Muito já foi escrito ( 1 , 2 ) sobre os desafios envolvidos na construção de pipelines robustos de Extração, Transformação e Carregamento (ETL), mas vamos contextualizá-lo dentro da IA.

Por que a IA precisa da movimentação de dados?

Os LLMs treinados em dados públicos são ótimos, mas sabe o que é ainda melhor? AIs que podem responder a perguntas específicas para nós, nossas empresas e nossos usuários. Adoraríamos que o ChatGPT pudesse aprender todo o wiki da nossa empresa, ler todos os nossos e-mails, mensagens do Slack, anotações e transcrições de reuniões, conectar-se ao ambiente de análise da nossa empresa e usar todas essas fontes ao responder às nossas perguntas. Ou, ao integrar IA em nosso próprio produto (por exemplo, com Notion AI ) , queremos que o modelo de IA de nosso aplicativo conheça todas as informações que temos sobre um usuário ao ajudá-lo.

A movimentação de dados é um pré-requisito para tudo isso.

Esteja você ajustando um modelo ou usando a Geração Aumentada de Recuperação (RAG), você precisa extrair dados de onde quer que estejam, transformá-los em um formato digerível por seu modelo e, em seguida, carregá-los em um armazenamento de dados que seu aplicativo AI pode acessar para atender seu caso de uso.

O diagrama acima ilustra como isso se parece ao usar o RAG, mas você pode imaginar que, mesmo que não esteja usando o RAG, é improvável que as etapas básicas sejam alteradas: você precisa extrair, transformar e carregar, também conhecido como ETL, os dados para crie modelos de IA que conheçam informações não públicas específicas para você e seu caso de uso.

Por que a movimentação de dados é difícil?

Construir um MVP funcional básico para extração de dados de uma API ou banco de dados é geralmente – embora nem sempre – possível em um aviso rápido (<1 semana). A parte realmente difícil é torná-lo pronto para produção e mantê-lo assim. Vejamos alguns dos desafios padrão que vêm à mente ao construir tubulações de extração.

Extrações incrementais e gerenciamento de estado

Se você tiver qualquer volume de dados significativo, precisará implementar a extração incremental de forma que seu pipeline extraia apenas os dados que não viu antes. Para fazer isso, você precisará ter uma camada de persistência para acompanhar quais dados cada conexão extraiu.

Tratamento de erros transitórios, backoffs, recomeço em caso de falha(s), air gap

Fontes de dados upstream o tempo todo, às vezes sem nenhum motivo claro. Seus pipelines precisam ser resilientes a isso e tentar novamente com as políticas de retirada corretas. Se as falhas não forem tão transitórias (mas ainda não são sua culpa), seu pipeline precisa ser resiliente o suficiente para lembrar de onde parou e retomar do mesmo local assim que o upstream for corrigido. E, às vezes, o problema proveniente do upstream é grave o suficiente (como uma API eliminando alguns campos cruciais dos registros) que você deseja pausar todo o pipeline até examinar o que está acontecendo e decidir manualmente o que fazer.

Identificação e correção proativa de erros de configuração

Se você estiver criando pipelines de extração de dados para extrair os dados de seus clientes, precisará implementar algumas verificações defensivas para garantir que todas as configurações fornecidas por seus clientes para extrair dados em nome deles estejam corretas e, se não estiverem, rapidamente dar-lhes mensagens de erro acionáveis. A maioria das APIs não facilitam isso porque não publicam tabelas de erros abrangentes e, mesmo quando o fazem, raramente fornecem pontos de extremidade que você pode usar para verificar as permissões atribuídas a, por exemplo, tokens de API. verificações com feedback rápido para o usuário.

Autenticação e gerenciamento de segredos

As APIs variam em simplicidade, desde autenticação de token de portador simples até, uh, implementações “criativas” de tokens de sessão ou OAuth de token de uso único. Você precisará implementar a lógica para executar a autenticação, bem como gerenciar os segredos que podem ser atualizados uma vez por hora, possivelmente coordenando atualizações secretas em vários trabalhadores simultâneos.

Otimizando as velocidades de extração e carregamento, simultaneidade e limites de taxa

E por falar em trabalhadores simultâneos, você provavelmente desejará implementar a simultaneidade para obter uma alta taxa de transferência para suas extrações. Embora isso possa não importar em pequenos conjuntos de dados, é absolutamente crucial em conjuntos maiores. Embora as APIs publiquem limites de taxa oficiais, você precisará descobrir empiricamente os melhores parâmetros de paralelismo para maximizar o limite de taxa fornecido a você pela API sem colocar o IP na lista negra ou com limite de taxa para sempre.

Adaptando-se às alterações da API upstream

As APIs mudam e assumem novos comportamentos ou peculiaridades não documentadas o tempo todo. Muitos fornecedores publicam novas versões de API trimestralmente. Você precisará ficar de olho em como todas essas atualizações podem impactar seu trabalho e dedicar tempo de engenharia para manter tudo atualizado. Novos endpoints surgem o tempo todo e alguns mudam de comportamento (e nem sempre você fica sabendo).

Agendamento, monitoramento, registro e observabilidade

Além do código que extrai dados de APIs específicas, você provavelmente também precisará criar alguns recursos horizontais aproveitados por todos os seus extratores de dados. Você vai querer algum agendamento, bem como registro e monitoramento para quando o agendamento não funcionar ou quando outras coisas derem errado e você precisar investigar. Você provavelmente também deseja alguma observabilidade, como quantos registros foram extraídos ontem, hoje, semana passada etc. e de quais terminais de API ou tabelas de banco de dados eles vieram.

Bloqueio de dados ou hash

Dependendo de onde você está extraindo dados, você pode precisar de alguns recursos de privacidade para bloquear ou hash colunas antes de enviá-los para baixo.

Para ser claro, o acima não se aplica se você quiser apenas mover alguns arquivos como uma coisa única.

Mas se aplica quando você está criando produtos que requerem movimentação de dados. Mais cedo ou mais tarde, você precisará lidar com a maioria dessas preocupações. E embora nenhum deles seja uma ciência de foguetes intransponível, juntos, eles podem adicionar rapidamente um ou vários empregos em tempo integral, ainda mais quanto mais fontes de dados você estiver extraindo.

E essa é exatamente a dificuldade em manter a extração de dados e pipelines: a maior parte de seu custo vem do investimento incremental contínuo necessário para manter esses pipelines funcionais e robustos. Para a maioria dos engenheiros de IA, esse não é o trabalho que agrega mais valor aos usuários. Seu tempo é melhor gasto em outro lugar.

Então, o que um engenheiro de IA precisa fazer para mover alguns dados por aqui?

Se você precisar de extração de dados e carregamento de pipelines, experimente as soluções já disponíveis em vez de criar automaticamente as suas próprias. Provavelmente, eles podem resolver muito, senão todas as suas preocupações. Caso contrário, construa o seu próprio como último recurso.

E mesmo que as plataformas existentes não ofereçam suporte a tudo o que você precisa, você ainda deve conseguir chegar lá com uma estrutura portátil e extensível. Dessa forma, em vez de construir tudo do zero, você pode chegar a 90% do caminho com recursos prontos na plataforma e apenas construir e manter os últimos 10%. O exemplo mais comum são as integrações de cauda longa: se a plataforma não for fornecida com uma integração para uma API necessária, uma boa plataforma facilitará a escrita de algum código ou até mesmo uma solução sem código para criar essa integração e ainda obtém todos os recursos úteis oferecidos pela plataforma. Mesmo que você queira a flexibilidade de apenas importar um conector como um pacote python e acioná-lo da maneira que quiser a partir do seu código, você pode usar uma das muitas ferramentas EL de código aberto, como os conectores Airbyte ou Singer.

Para ser claro, a movimentação de dados não está completamente resolvida. Há situações em que as soluções existentes realmente ficam aquém e você precisa criar novas soluções. Mas esta não é a maioria da população de engenharia de IA. A maioria das pessoas não precisa reconstruir as mesmas integrações com Jira, Confluence, Slack, Notion, Gmail, Salesforce, etc... repetidamente. Vamos apenas usar as soluções que já foram testadas em batalha e abertas para qualquer pessoa usar, para que possamos adicionar o valor com o qual nossos usuários realmente se preocupam.