Consultora de data engineering em Utrecht
Criamos pipelines que fornecem os mesmos dados aos modelos e relatórios e medimos o que muda. Para Rijkswaterstaat, desenvolvemos um pacote de monitorização genérico.
Desenvolvemos um único pacote genérico de monitorização para todos os modelos de IA que a Rijkswaterstaat tem em produção
A Rijkswaterstaat colocou vários modelos de IA em produção. A monitorização manual de data drift e prediction drift não é escalável, por isso desenvolvemos um pacote para detetar drift e outliers, utilizando, entre outras ferramentas, Python, Alibi Detect e Pydantic. “A DSL apresentou uma solução engenhosa que podemos utilizar com proveito.” Nanine Overgaauw, Rijkswaterstaat - SRE Data Science
O nosso modelo deteta quando um sistema de origem é substituído?
Nas grandes organizações de Utrecht e arredores, os registos de ativos, as redes de medição e os sistemas de gestão de processos e de planeamento alimentam relatórios e modelos. Se uma coluna ou unidade mudar, o modelo continua a calcular como se nada fosse. Criamos pipelines que bloqueiam essas alterações e as tornam visíveis.
O treino, a produção e a verificação usam os mesmos dados, provenientes de pipelines que pode inspecionar
Ingestão com validação de esquemas
Os dados de cada fonte são primeiro recebidos sem alterações. Depois, a pipeline verifica colunas, tipos e regras. Para a Fokker Services Group, os controlos de qualidade dos dados estão integrados na plataforma de dados.
Entradas e saídas do modelo documentadas
Documenta-se o que um modelo recebe e devolve. É nessa documentação que assenta a monitorização, como no pacote de deteção de drift e outliers para Rijkswaterstaat.
Releases pelas etapas DTAP
As pipelines e a infraestrutura passam do desenvolvimento à produção como código. Para a SNG, automatizámos o processo de release pelas etapas DTAP, recorrendo, entre outras ferramentas, ao Terraform.
Muitas fontes, um único modelo de dados
Para a Vivara, desenvolvemos uma plataforma de dados que recolhe diariamente dados de fontes como SAP, Magento e SharePoint, com um único modelo de dados para todos os departamentos.
A partir de um modelo em funcionamento, rastreamos os dados até cada fonte
-
Um modelo, todas as suas fontes
Rastreamos um modelo até cada tabela e cada sistema que o alimenta e identificamos os respetivos responsáveis.
-
Criar a ingestão e os controlos
Pipelines com verificações de esquema e regras de qualidade dos dados, mais uma tabela com os dados de entrada e os resultados do modelo.
-
Reutilizar para o seguinte
O modelo ou relatório seguinte usa a mesma ingestão de dados. Depois, a gestão fica a cargo da sua equipa ou da nossa.
Precisamos agora de uma consultora de data engineering ou devemos começar por outra coisa?
Adequado se
Vários modelos ou relatórios dependem de dados de muitos sistemas, a ingestão de dados foi criada separadamente para cada projeto e ninguém se apercebe quando uma fonte muda. Está em Utrecht ou nos arredores e procura uma equipa que se desloque até si.
Não é adequado se
Procura um data engineer para trabalhar temporariamente com a sua equipa: nesse caso, a cedência temporária de um profissional é mais adequada. Se ainda nada funciona com base nos dados, comece por perguntar que decisão precisa de melhorar.
O que determina a dimensão
O número de fontes e modelos, a existência de uma plataforma, a frequência de atualização dos dados, os requisitos de segurança e a parte da gestão que ficará a cargo da sua equipa.
Ficaremos dependentes da vossa escolha?
Trabalhamos com Databricks, Microsoft Fabric ou com o ambiente que já existe e escolhemos o que se adequa à infraestrutura de IT existente. Definimos antecipadamente os acordos relativos à documentação e à gestão.
Onde deve detetar um erro nos dados: na origem, na pipeline ou no modelo?
Na origem
Escolha esta opção se o erro tiver origem num único sistema e o respetivo responsável o puder corrigir, por exemplo, com um campo obrigatório ou uma unidade de medida fixa no registo de ativos.
Na pipeline
Escolha esta opção se vários modelos e relatórios utilizarem a mesma fonte. Uma validação do esquema ou uma regra de qualidade dos dados interceta o erro uma só vez, para todos.
No modelo
Escolha esta opção se os dados estiverem tecnicamente corretos, mas a realidade estiver a mudar. O nosso conselho: meça o drift nos dados de entrada do modelo, além de fazer as verificações na pipeline, e não em vez delas.
Construímos plataformas de dados e as pipelines que lhes dão suporte, enquanto parceiro da Databricks e da Microsoft
A Data Science Lab trabalha com dados e IA desde 2016, a partir de Amesterdão. Construímos plataformas de dados para a Fokker Services Group e a Vivara, entre outros, e partilhamos conhecimento no nosso laboratório e nos Techdays.

Na primeira conversa, decidimos em conjunto por que modelo ou relatório começar
Stef Stoelwinder
Desenvolvimento de NegócioStef é o seu primeiro ponto de contacto. Na primeira conversa, falamos sobre as suas fontes e os seus modelos, nas suas instalações em Utrecht, em Amsterdam ou online.
E-mail info@datasciencelab.nl
Telefone +31 (0)20 3636 724
De que sistemas obtêm atualmente dados os seus modelos e relatórios?
Indique que sistemas, modelos e plataforma utiliza. Respondemos por e-mail ou marcamos uma primeira conversa.
Mensagem enviada
Obrigado pela sua mensagem. Entraremos em contacto consigo o mais rapidamente possível.
Perguntas frequentes
Garante que os dados de todos os seus sistemas chegam de forma fiável a um único local, através de pipelines e de uma plataforma que concebe, constrói e mantém. Os modelos em produção exigem mais: os mesmos dados para treino e produção, verificações na ingestão e entradas do modelo definidas. Os modelos em si pertencem ao domínio de data science. Saiba mais sobre data engineering.
Se preferir ter um data engineer de Utrecht ou arredores na sua própria equipa, pode contratar um data engineer através de nós. Esse profissional continua a ser nosso colaborador.
Porque o modelo se baseia no que viu durante o treino. Se um sistema de origem for substituído, uma unidade passar de metros para centímetros ou uma coluna adquirir outro significado, o modelo continua a produzir resultados, mas menos precisos. Ninguém recebe uma mensagem de erro.
Por isso, faça as verificações na ingestão. As tabelas Delta no Databricks impõem o esquema na escrita dos dados: rejeitam colunas que a tabela não reconhece e exigem que os tipos de dados correspondam. Assim, qualquer alteração ao esquema é deliberada. Pode validar em Python, com Pydantic, os dados que chegam num ficheiro ou através de uma API.
Guardando a entrada e o resultado de cada previsão, juntamente com os dados de treino. No Databricks, as inference tables fazem isso: registam os pedidos e as respostas de um model serving endpoint numa tabela Delta no Unity Catalog. Depois, pode usar data profiling para acompanhar o desempenho e o data drift.
A Rijkswaterstaat tem vários modelos de IA em produção. Para esses modelos, desenvolvemos um package genérico para deteção de drift e outliers, com ferramentas como Alibi Detect, uma biblioteca Python para deteção de outliers e drift. Leia o caso de estudo da Rijkswaterstaat ou saiba mais sobre MLOps.
Através de lineage: um registo das queries e dos ficheiros que alimentam uma tabela, dos jobs e notebooks que a modificam e dos dashboards e versões de modelos que a utilizam. O Unity Catalog regista automaticamente estas relações para queries no Databricks, até ao nível da coluna. Se o responsável por um sistema de origem quiser eliminar uma coluna, pode ver antecipadamente quem será afetado.
Sem um catálogo deste tipo, pode manter uma lista por pipeline, mas esta fica rapidamente desatualizada. Saiba mais sobre a configuração do Unity Catalog.
Para sistemas de IA de risco elevado, o artigo 10.º exige que os dados de treino, validação e teste estejam sujeitos a práticas adequadas de data governance e gestão de dados. Os conjuntos de dados devem ser relevantes, suficientemente representativos e, tanto quanto possível, isentos de erros e completos para a finalidade prevista. As pipelines que registam a origem dos dados ajudam a demonstrá-lo.
Devido ao pacote Omnibus da IA, os requisitos relativos ao anexo III só se aplicam a partir de 2 de dezembro de 2027. Ajudamos a fazer o levantamento; cabe ao seu departamento jurídico ou de compliance decidir se o seu modelo é de risco elevado. Saiba mais sobre o Regulamento da IA.
Depende do ambiente de TI que já existe. Construímos soluções com Databricks e Microsoft Fabric. Para a Fokker Services Group, estamos a construir uma plataforma de dados com Databricks, Azure e dbt, entre outras ferramentas, estruturada segundo a arquitetura medalhão. Para perceber como as camadas bronze, prata e ouro formam um lakehouse, saiba mais sobre a construção de um data lakehouse.
Se precisar sobretudo de reunir fontes estruturadas e exportações de dados, sem executar modelos na plataforma, um data warehouse costuma ser suficiente.
Quando um único relatório depende de um único sistema, ou quando o problema não é técnico, mas sim a falta de um responsável por uma fonte de dados. Nesse caso, comece por definir acordos de data governance, não por construir uma pipeline. Se o que falta é sobretudo capacidade na sua equipa, integrar temporariamente um profissional faz mais sentido do que iniciar um projeto.
Se preferir começar por comparar algumas consultoras, consulte a comparação de consultoras de data engineering. Se estiver na Holanda do Sul, conheça a nossa consultora de data engineering em Roterdão. Se a primeira questão for decidir que modelo construir e quem o irá gerir, consulte consultor de IA em Utrecht.
Como continuar a desenvolver a fundação de dados que sustenta os seus modelos?
- Data engineeringA nossa abordagem à base técnica de BI e IA: conceber uma nova plataforma ou gerir um ambiente existente.
- Contratar um data engineerSe quiser desenvolver a ingestão de dados internamente, mas precisar temporariamente de um profissional da nossa equipa para trabalhar ao lado dos seus engenheiros.
- Consultora de data engineering em RotterdamPara organizações em Zuid-Holland que pretendem reunir dados de sensores e de ERP numa única plataforma.