Une réflexion tardive sur un sujet récent. En fait, ce n'est pas vraiment nouveau, c'est plutôt un sujet récurrent : "Les personnes qui font de l'infrastructure doivent se rapprocher des affaires, sinon tout n'est qu'un château en Espagne." J'ai déjà mentionné plusieurs fois que notre entreprise est un acteur majeur de l'AIGC, se concentrant sur le secteur des deux dimensions. Nous faisons face à un problème récemment causé par Elasticsearch. Les œuvres d'art et les tâches générées publiées par nos utilisateurs sont toutes recherchables. Récemment, Elasticsearch a fréquemment rencontré des problèmes où certains nœuds de données étaient saturés, entraînant des problèmes de recherche en chaîne. Alors, comment pouvons-nous résoudre ce problème rapidement ? Avant d'en discuter davantage, nous devons réfléchir à la nature de l'opération de recherche dans ce contexte. À mon avis, il s'agit de gestion d'actifs. Dans le contexte de l'AIGC, le Prompt est sans aucun doute l'actif central de l'utilisateur, tandis que la tâche et l'œuvre d'art peuvent être considérées comme un aperçu (ou des attributs) de cet actif. Avec cette hypothèse, nous pouvons clairement comprendre qu'au moins dans sa forme actuelle, les attributs essentiels de l'entreprise ne peuvent pas faire de compromis pour des résultats techniques. En même temps, nous avons observé que la visibilité des œuvres d'art publiées par nos utilisateurs est différente de celle des tâches ; les œuvres d'art peuvent être recherchées publiquement et assument également la responsabilité du SEO, tandis que les tâches ne sont visibles que par les utilisateurs. En d'autres termes, la fréquence d'accès aux données et les besoins en ressources des deux sont assez différents. En d'autres termes, nous avons un besoin de multi-location pour l'index ES. Mais malheureusement, selon la conception actuelle d'ES, il n'a pas la capacité de multi-location. Bien que l'optimisation des requêtes soit une option inévitable à long terme, face à une entreprise en hypercroissance, diviser l'index en différents clusters et attribuer différentes puissances de calcul/disques selon les attributs de l'index, et essayer rapidement différentes solutions deviendra notre premier choix. Ce travail est actuellement en cours, les résultats sont inconnus, mais tout le processus de réflexion stratégique est quelque chose que je n'ai pas beaucoup considéré ces dernières années. Souvent, la solution technique optimale n'est pas nécessairement la solution optimale pour l'entreprise. Enfin, un dernier mot. Notre entreprise recrute, des postes de ML Engineer, ML Data/Full Stack/Backend/Marketing sont disponibles. Si vous souhaitez faire des choses intéressantes ensemble, n'hésitez pas à DM, je vous mettrai en contact avec votre patron.