Il n'y a pas si longtemps, mon système a atteint un point de rupture.
Ce n'était pas un accident, c'était un problème de confiance. J'ai vu un ensemble de données client être ingéré, et au lieu d'une structure propre, le système a créé un désordre de duplicates. La même organisation apparaît trois fois dans le graphique de connaissances parce que les données de source utilisent trois conventions de nommage différentes: McKinsey & Company, McKinsey et Company, et Mckinsey. Pour un humain, il s'agit évidemment d'une seule entité. Pour un graphique, il s'agissait de trois nœuds séparés avec trois ensembles de relations déconnectés. Trois versions parallèles de la même vérité.
C'est à ce moment-là que j'ai arrêté de penser aux données comme à quelque chose que vous stockez simplement et j'ai commencé à penser à elles comme à quelque chose que vous archétiquement.
Tout est plus clair que le schéma suggère
Voici ce que personne ne vous prépare à faire lorsque vous construisez des systèmes qui traitent des données générées par l'homme: les humains sont extrêmement inconsistants. Je ne veux pas dire ça de façon charmante, mais de façon à briser toutes les hypothèses que votre schéma fait.
Une personne écrit Python. Une autre écrit Python Language of Programming. Un troisième écrit python en minuscules. Pour une comparaison naïve, ce sont quatre entités complètement différentes. Quatre nœuds. Quatre mensonges dans votre graphique.
Je ne voulais pas résoudre ce problème, je voulais juste construire un pipeline de données propre. Mais quand votre pipeline ingère des données humaines, ce désordre est le problème. Tout le reste est en aval.
Hiérarchie visuelle en tant que protocole d'ingénierie
Avant d'entrer en profondeur dans l'architecture technique, laissez-moi vous expliquer quelque chose dont les ingénieurs ne parlent pas assez:
Quand vous regardez un rapport ou un tableau de bord bien structuré, votre cerveau construit un modèle mental en moins de trois secondes. Vous savez instinctivement où se trouvent les données clés et l'importance relative de chaque section. Ce n'est pas un protocole de communication de données.
La façon dont vous présentez les données façonne les décisions que les gens en prennent. Quand je construis un système pour structurer l'information, je ne peux pas penser à la justesse du schéma. Je dois penser au poids perceptif. Sur quoi l'œil humain atterrit-il en premier ? Comment encoder ces priorités dans une structure de données sur laquelle un moteur de rendu peut réellement agir ?
Graphiques de connaissances: les relations sont les données
Une table de base de données stocke des faits. Un graphe de connaissances stocke le sens.
Dans mon graphique, chaque élément d'information est un nœud, mais l'intelligence réelle vit dans les bords:
- HAS_ATTRIBUTE: Lient une entité à ses propriétés spécifiques et contextuelles.
- BELONGS_TO: Associé un enregistrement à son organisation mère, qui a ses propres propriétés et relations.
- REQUIRES: Connecte un projet ou un enregistrement aux technologies ou compétences spécifiques impliquées.
Lorsque les données sont liées de cette façon, ce n'est pas seulement une liste; c'est une narration. Il émerge naturellement de la structure Je n'ai pas besoin d'écrire un code spécial génération narrative. Les relations sont l'histoire.
Densité des données: la contrainte est la caractéristique
Je suis obsédé par la densité des données. Un document dense n'est pas un document encombré; c'est un document où chaque élément gagne sa position. Dans mon système, la densité est imposée par des contraintes structurelles strictes:
- articles_per_category: 5: Vous ne répertoriez pas 47 attributs. Tu fais une liste des cinq qui comptent. La contrainte force la priorité.
- résumé: deux phrases. C'est tout. Dites-moi ce que c'est et pourquoi c'est important. Tout le reste est du bruit.
- Les phrases interdites: J'ai écrit une logique de validation réelle qui rejette les mots vides comme best-in-class ou synergie. Ils occupent de l'espace et ne communiquent rien.
Le bâton de normalisation: la plomberie que personne ne voit
Pour résoudre ce problème de « McKinsey », un stack à quatre couches a été conçu pour assurer l'intégrité des données :
- Normalité: Nettoyage des noms lors de l'ingestion et débarrassement des suffixes verbos.
- Déduplication fuzzy: Utilisation d'un seuil de similitude 0.82le plus élevé pour capturer Docker Container et Docker,mais assez bas pour maintenir Go et Git séparés.
- ** Identifiants déterministes:** Chaque nœud obtient un ID dérivé de son contenu (par exemple attr_python). Traiter la même entrée désordonnée deux fois, obtenir le même graphe propre une fois.
- Le moteur de mutation: Un système de dépêche qui gère les mises à jour et les corrections sans perdre l'origine des données.
Ce que j'ai appris de l'échec
Ce système a échoué de manière qui m'a appris plus que les succès. Il a une fois fusionné l'apprentissage automatique et l'exploitation automatique, car ils partageaient un score de similitude élevé. Cet échec m'a appris le fossé massif entre la validité structurelle et la signification sémantique.
J'ai aussi appris à considérer l'extraction automatisée comme une entrée non fiable. J'utilise maintenant des filtres de sonorisation pour m'assurer que le système ne hallucine pas les enregistrements qui semblent plausibles mais qui n'existent pas.
La ligne de fond
L'architecture de l'information est l'architecture de la confiance.** Lorsque les données sont normalisées et liées sémantiquement, les gens font confiance à la sortie. Quand il est plein d'orphelins et de duplicates, la substance n'a pas d'importance.
Le travail n'est pas seulement d'écrire du code, c'est de transformer le chaos en quelque chose de questionnable. Si vous voulez transformer le bruit en connaissance, vous n'avez pas besoin de stockage. Vous avez besoin d'architecture