Données & Pipelines
Ingestion, pgvector, entrepôt de données, RGPD, anonymisation
Un assistant ne vaut jamais mieux que ce qu’on l’autorise à lire. Presque tout le travail est en amont du modèle, dans la partie ingrate que personne ne montre en démo.
- 5+systèmes d’entreprise branchés comme sources d’ingestion
- 4produits dont j’ai modélisé les données pour l’entrepôt du groupe
- MITAnonDocs, open source, avec un SDK npm public
Ingérer là où la connaissance vit déjà
SharePoint, Google Drive, Jira, Airtable, CMS. Extraction, découpage, embedding et réindexation incrémentale, pour qu’un assistant réponde depuis la connaissance de l’entreprise et non depuis une copie qui a commencé à dériver le jour où on l’a faite.
Modéliser pour ceux qui poseront les questions plus tard
Chez Redspher, main dans la main avec les data analysts : schémas, extraction et qualité des données applicatives alimentant l’entrepôt BigQuery du groupe, sur les quatre produits dont j’avais la charge. Chez AI SmartTalk, la même discipline tournée vers l’intérieur — schémas de conversation, d’usage et de base de connaissance structurés pour l’analytique dès le départ.
Des contrats aux frontières, pas de l’espoir
Validation Zod et JSON Schema là où la donnée entre, Redis et RabbitMQ là où elle attend. Un pipeline qui accepte silencieusement une charge utile dont la forme a changé vous mentira pendant une semaine, et le bug que vous finirez par trouver ne sera pas au bon endroit.
La contrainte, c’est l’architecture
Hébergement européen, conformité RGPD, données personnelles retirées avant inférence, déploiements on-premise pour les clients dont les documents ne peuvent pas atteindre une API tierce. Ajouté à la fin, rien de tout ça ne marche. Conçu dedans, rien de tout ça ne coûte.
Stack
- PostgreSQL
- pgvector
- BigQuery
- Redis
- RabbitMQ
- SharePoint · Drive · Jira · Airtable
- Zod
- JSON Schema
- GDPR · EU hosting