Le calcul des caractéristiques devient plus important avec des capteurs supplémentaires, car les flux à débit fixe multiplient le travail par échantillon et créent davantage de relations de synchronisation et de fusion.
À raison d’un échantillon par seconde, 20 capteurs produisent 1,7 million d’observations par jour, contre 17,3 millions pour 200 capteurs. Le filtrage de chaque flux évolue à peu près avec le nombre de capteurs, tandis que les corrélations à l’échelle d’une pièce, la fusion des données d’occupation et les fenêtres chevauchantes ajoutent des opérations d’alignement et par paires. La fréquence d’échantillonnage est restée fixe, mais la surface totale des événements n’est pas restée la même pendant la période d’automatisation la plus chargée.
Le travail par capteur évolue avec le nombre de flux et d’échantillons
Une caractéristique telle que la moyenne glissante, la variance, la pente ou l’état d’un seuil traite chaque valeur reçue et conserve l’état de la fenêtre. Avec N capteurs à la fréquence f, le travail de base et le trafic d’événements évoluent presque comme N fois f lorsque le nombre de caractéristiques reste constant.
Une analyse du traitement des données de capteurs décrit le filtrage, l’agrégation, l’extraction de caractéristiques et la fusion comme des étapes distinctes. Chaque étape peut être répartie entre les appareils, les nœuds périphériques et les serveurs.
Les écritures en base de données, l’analyse des messages et les horodatages peuvent dominer les simples opérations arithmétiques. Dix fois plus de capteurs peuvent donc générer dix fois plus de surcharge de planification et de stockage, même lorsque chaque formule est peu coûteuse.
Les caractéristiques intercapteurs peuvent croître plus rapidement que linéairement
Les modèles d’occupation ou d’anomalie peuvent comparer plusieurs capteurs dans la même fenêtre temporelle. Une corrélation entre toutes les paires crée environ N au carré relations ; la fusion par groupes évolue avec le nombre de capteurs par pièce et la longueur de la fenêtre. La dérive des horloges et les échantillons manquants ajoutent des jointures et de l’interpolation.
Les recherches sur l’extraction de caractéristiques en périphérie considèrent l’extraction locale comme un moyen de réduire de plusieurs ordres de grandeur le volume de données en amont. Le calcul ne disparaît pas ; il se rapproche de la source.
Le chevauchement des fenêtres est également important. Recalculer chaque seconde une statistique sur 60 échantillons coûte plus cher que de maintenir un état incrémentiel. Une même fréquence d’échantillonnage ne signifie pas le même travail algorithmique lorsque le nombre de capteurs modifie le nombre de relations.
Quand le nombre de capteurs n’est pas le goulot d’étranglement
Davantage d’appareils peuvent n’ajouter que peu de coûts lorsqu’ils transmettent rarement des données, que les caractéristiques sont déclenchées par des événements et que les calculs sont indépendants et incrémentiels. Une seule caméra ou un seul capteur audio à haute fréquence peut peser davantage que des centaines de sondes de température.
Une analyse des charges de travail d’analyse en périphérie souligne que le placement de la charge et le type de données déterminent la pression exercée sur les ressources périphériques. Compter les appareils sans tenir compte des octets et des opérations ne suffit pas.
Le mécanisme cesse également de s’appliquer lorsque le délai de l’automatisation est dû aux nouvelles tentatives radio, aux verrous de base de données ou aux allers-retours vers le cloud plutôt qu’aux caractéristiques. Ajouter de la puissance de calcul n’est pas automatiquement la solution. Mesurez l’ancienneté de la file d’attente et l’exécution des caractéristiques avant d’attribuer la latence à l’échelle du parc de capteurs.
Rejouez différentes échelles de capteurs avant que les automatisations ne prennent du retard
Répertoriez pour chaque capteur la fréquence d’échantillonnage ou d’événements, la taille de la charge utile en octets, le nombre de caractéristiques, la longueur de la fenêtre et le groupe de fusion. Rejouez une, deux, cinq et dix fois le nombre actuel de flux tout en enregistrant le temps processeur par caractéristique, l’ancienneté de la file d’attente, la mémoire, les écritures en base de données et la latence de l’automatisation.
Utilisez les distinctions de placement présentées dans l’article sur le contexte des mesures effectuées par les capteurs afin d’éviter de considérer un désaccord environnemental réel comme une erreur de calcul. Conservez une normalisation identique des horodatages dans tous les tests d’échelle.
Si le processeur et l’ancienneté de la file d’attente augmentent linéairement, réduisez la surcharge par événement ou regroupez les écritures. S’ils accélèrent, examinez les jointures entre toutes les paires et les fenêtres chevauchantes. Préécrivez les synthèses incrémentielles, regroupez uniquement les capteurs associés et conservez les données brutes à une cadence plus faible lorsqu’elles ne servent pas à prendre une décision explicite.
Centre Tech & IA
Plus à lire

Comment mesurer la qualité de la récupération RAG locale et interpréter le rappel, la précision et la couverture des citations
Créez un jeu de test RAG local, calculez les principales métriques de récupération, interprétez leurs compromis et vérifiez si les affirmations des réponses sont...

Pourquoi le coût de l’évaluation du RAG devient-il plus important à mesure que la bibliothèque de documents s’agrandit, pour un même volume de requêtes ?
Comprenez pourquoi l’augmentation du corpus accroît l’effort d’évaluation du RAG sans augmenter le nombre de requêtes des utilisateurs, et comment les tests stratifiés maintiennent...

Pourquoi la surcharge des outils d’agent devient-elle plus importante à mesure que le nombre d’étapes du workflow augmente, pour une taille de modèle identique ?
Suivez comment les attentes séquentielles, l’augmentation du contexte, les nouvelles tentatives et la fiabilité se cumulent à chaque étape de l’agent, puis mesurez séparément...

