Comment ProPost AI transforme le chaos LinkedIn en 365 brouillons par an

La plupart des outils de contenu LinkedIn échouent de la même manière. Ils génèrent un bon post, puis dérivent. Au troisième ou quatrième brouillon, le ton est décalé, la structure est différente, et l'utilisateur revient à tout écrire lui-même. ProPost AI a été construit pour résoudre ce mode de défaillance spécifique, produisant du contenu LinkedIn au rythme de 365 brouillons par utilisateur par an sans que la qualité ne se dégrade au fil du temps. Cette contrainte a façonné chaque décision architecturale que j'ai prise.

Le vrai problème était la dérive des prompts, pas la génération

L'hypothèse évidente est que la partie difficile d'une plateforme de contenu IA est de faire écrire correctement le modèle. Ce n'est pas le cas. N'importe quel modèle de langage décent peut produire un bon post LinkedIn donné un brief clair. La partie difficile est de produire le deux-centième post dans la même voix, avec la même logique structurelle, pour un utilisateur qui a défini ses préférences il y a six mois.

J'ai appelé cela la dérive des prompts. Sur un long historique de session, les fenêtres de contexte se remplissent, les prompts système sont compressés, et le modèle commence à faire la moyenne sur tout son entraînement plutôt que de rester ancré à la persona définie par l'utilisateur. La solution n'était pas d'écrire de meilleurs prompts. C'était de traiter le profil vocal de l'utilisateur comme un objet de données de première classe, stocké séparément, versionné, et injecté à nouveau dans chaque demande de génération plutôt que d'être accumulé dans un contexte roulant.

Cela signifiait construire une couche de persona qui s'intercalait entre l'interface utilisateur et l'API du modèle. Les marqueurs de ton de chaque utilisateur, les structures de post préférées et les clusters de sujets ont été sérialisés et stockés. Chaque appel de génération chargeait ce profil à partir de zéro. Le modèle ne voyait jamais ses propres sorties précédentes à moins que l'utilisateur ne les inclue explicitement comme exemples.

Planifier sur plusieurs réseaux sans chaos API

ProPost AI s'intègre à LinkedIn, Instagram, Facebook et d'autres grands réseaux. Chacune de ces plateformes a ses propres limites de débit, son cycle de vie de token OAuth et ses contraintes de format de post. Gérer cela sur un produit SaaS multi-locataire est véritablement fastidieux si vous ne l'architecturez pas correctement dès le départ.

J'ai construit une couche de planification basée sur une file d'attente qui traitait chaque connexion réseau comme un worker isolé. Un post planifié pour LinkedIn allait dans une file d'attente spécifique à LinkedIn avec sa propre logique de retry et son cycle de rafraîchissement de token. Un échec sur Instagram ne bloquait pas le worker LinkedIn. Chaque file d'attente était indépendamment observable, donc je pouvais voir exactement où une livraison avait échoué et pourquoi.

L'expiration du token était le mode de défaillance le plus courant dans les tests précoces. Les tokens OAuth pour les API sociales expirent selon des calendriers qui varient selon la plateforme et l'activité de l'utilisateur. J'ai ajouté un job de rafraîchissement proactif qui s'exécutait avant les fenêtres d'expiration plutôt que d'attendre un 401 pour déclencher un retry. Cela seul a éliminé la plupart des défaillances de planification silencieuses qui ont tourmenté la première version.

La génération d'images devait être contrainte pour être utile

La plateforme inclut la génération d'images aux côtés de la rédaction. La tentation avec la génération d'images est de donner aux utilisateurs une liberté maximale. Chaque paramètre exposé, chaque style disponible, contrôle créatif complet. J'ai essayé. Les utilisateurs ne l'ont pas utilisé.

Le problème était la fatigue décisionnelle. Un utilisateur qui doit poster trois fois par semaine ne veut pas configurer un pipeline de génération d'images à chaque fois. Il veut quelque chose qui semble cohérent avec sa marque et qui est prêt en moins de trente secondes. J'ai réduit l'interface à un petit ensemble de présets de style ancrés à la marque, chacun lié à un modèle de prompt de génération qui avait été testé pour les rapports d'aspect des images LinkedIn et les normes de densité visuelle.

Le résultat a été une génération plus rapide et une utilisation plus élevée. Contraindre les options était la bonne décision d'ingénierie, pas un compromis.

Garder la couche IA interchangeable

Une décision que j'ai prise tôt et dont je ne regrette pas : je n'ai jamais appelé directement l'API d'aucun fournisseur de modèle à partir de la couche application. Tous les appels de modèle passaient par une abstraction interne que je pouvais échanger sans toucher au code produit. Cela importait parce que le marché des modèles se déplaçait rapidement. Un fournisseur qui était le choix évident quand j'ai commencé à construire n'était pas nécessairement le bon choix six mois plus tard.

Ce modèle apparaît dans d'autres produits que j'ai construits. Sur Fursa, le moteur d'éligibilité des routes de visa, la même abstraction m'a permis d'exécuter différents modèles contre différentes tâches de classification sans réécrire la logique environnante. Sur Job Hunter, cela signifiait que je pouvais tester la qualité de génération entre les fournisseurs sans un cycle de déploiement complet. Garder la couche IA fine et interchangeable n'est pas une architecture intelligente pour elle-même. C'est une gestion des risques basique dans un marché où les capacités et les tarifs des fournisseurs changent trimestriellement.

Ce que je ferais différemment

Le système de versioning de persona a fonctionné, mais il était plus complexe qu'il n'avait besoin de l'être au départ. J'ai construit un schéma de versioning complet avant d'avoir la preuve que les utilisateurs itéreraient réellement sur leurs profils vocaux. La plupart des utilisateurs définissent un profil une fois et ne le changent jamais. Un simple journal append-only aurait suffi pour la première année, et j'aurais pu ajouter la ramification plus tard si les données montraient que les utilisateurs en avaient besoin.

J'ai aussi sous-estimé le fardeau du support du OAuth multi-réseau. Chaque plateforme a ses propres particularités, et quand le token linkedin d'un utilisateur expire silencieusement, il ne sait pas si le problème vient de la plateforme, de l'application ou de ses propres paramètres de compte. J'ai finalement ajouté un tableau de bord de santé de connexion qui affichait l'état du token par réseau, ce qui a réduit considérablement les tickets de support. J'aurais dû construire cela dans le premier sprint, pas le quatrième.

L'architecture de planification, la couche de persona, l'interface d'image contrainte, c'étaient les bons appels. Le versioning sur-ingéniérisé et l'observabilité retardée étaient les mauvais. Les deux valent la peine d'être connus si vous construisez quelque chose de similaire.

L'ingénierie est documentée si vous voulez regarder de plus près

ProPost AI est l'un de plusieurs produits IA que j'ai construits chez Dinovix. L'étude de cas complète couvre les métriques, la stack et les décisions en plus de détails. Si vous évaluez si le travail est réel, c'est le bon endroit pour commencer.

Si vous construisez quelque chose dans cet espace et voulez une conversation technique sur l'architecture, la gestion des limites de débit ou les modèles d'abstraction IA, la perspective d'ingénierie couvre comment j'aborde cette classe de problème. Ou si vous préférez demander directement, Kadon AI peut répondre à partir de l'enregistrement complet sans réunion.