Pipelines de ciência de dados e blobs de modelo monolítico

Normalmente, um tópico importante no DevOps é como cuidamos da criação e entrega automatizadas de artefatos de software.

Com o surgimento da ciência de dados, existe um novo tipo de artefato - blobs binários monolíticos que representam uma rede neural treinada, por exemplo, ou outros modelos de aprendizado de máquina. Esse blob pode ter um tamanho de muitos GB e sua criação ainda não é um AFAIK padronizado, que traz as organizações de volta à era anterior ao IC. No entanto, eles têm sua versão e coleções associadas de dados de treinamento (corpora), que tendem a crescer rapidamente também.

Quais são as práticas recomendadas para enfrentar esse novo desafio usando os métodos DevOps - se possível?

Pessoalmente, não vejo nenhuma razão pela qual um Repositório de Artefatos - a ferramenta recomendada do DevOps para gerenciar artefatos - não seja aplicável a redes neurais treinadas ou outros artefatos.

O tamanho do artefato pode ter algum limite superior para um repositório de artefatos específico, mas, nesse caso, seria uma limitação técnica ou de política, não fundamental / principial.

Quanto à aplicação de metodologias DevOps para o processo de produção desses artefatos, acho que a maioria, se não todas, pode ser aplicada igualmente bem, desde que os artefatos:

• são produzidos a partir de algum tipo de especificação que suporta controle de versão de mudança (equivalente ao código-fonte do software)
• são construídas através de um processo repetível e automatizável
• são validados usando algum tipo de verificação repetível e automatizável (semelhante ao controle de qualidade), eventualmente usando alguns dados de suporte (dados de treinamento nesse caso, equivalentes aos instantâneos do banco de dados, por exemplo)

Nota lateral: a entrega de código de software monolítico ainda é um grande negócio e é perfeitamente sustentável com as metodologias DevOps (com um pouco de cuidado), nem tudo pode ser dividido em microsserviços. Tamanho não importa o suficiente para tornar o DevOps não aplicável.

Eu recomendaria dar uma olhada no DVC - um sistema de controle de versão de código aberto para projetos de ciência de dados.

Uma das coisas básicas com as quais ele lida perfeitamente é o gerenciamento de arquivos de dados (junto com o código) - entradas, saídas (modelos), resultados intermediários. Semanticamente, é semelhante, git-lfsmas ao contrário git-lfs, é capaz de gerenciar arquivos como 100 GB e, o mais importante, não depende de armazenamento / formato proprietário. É completamente de código aberto e é compatível com qualquer armazenamento de rede como servidor para manter arquivos de dados - S3, armazenamento em nuvem GCP, SSH, FTP, etc.