Aller au contenu

Présentation de notre moteur d'horoscopes

Notre moteur d'horoscopes est un moteur d'astrologie déterministe conçu pour des applications de production réelles, et non pour la génération de texte de divertissement. Il combine le calcul de Swiss Ephemeris, l'activation stricte des facteurs et le rendu éditorial, afin que votre application reçoive des résultats de rapports stables, explicables et de haute qualité.

Cœur du moteur Déterminisme Modes Langage

Sur quoi vous travaillez

Au moment de l'exécution, le moteur calcule l'état céleste réel et assemble le sens à partir des facteurs astrologiques activés. Pour des charges utiles identiques, les sorties restent stables, byte par byte. Lorsque des entrées de personnalisation sont fournies, les vecteurs au niveau de la maison et du contexte de naissance s'activent pour produire des différences spécifiques à l'utilisateur.

Cela offre à votre équipe : - Résultats prévisibles pour les tests, le contrôle qualité et la mise en cache : les requêtes identiques renvoient toujours le même JSON. - Composition de rapports explicable grâce aux traces factor_details dans chaque section. - Un chemin simple allant des rapports de base aux rapports personnalisés premium. - Profondeur tenant compte des périodes : piles de facteurs quotidiennes (5-6 facteurs), hebdomadaires (10), mensuelles (11) et annuelles (13) avec des poids explicites.

Vue d'ensemble de l'architecture

Architecture du moteur complet

Architecture complète du moteur de prévisions

Architecture Requête-Réponse

Architecture Requête-Réponse pour les prévisions

Pipeline Déterministe1. Gateway valide l'authentification, les quotas et la politique de requête.

  1. Validation du contrat de requête applique le schéma et les options acceptés.
  2. Engine détermine la source de signe, la fenêtre de période et la configuration de l'éphéméride.
  3. Swiss Ephemeris calcule les positions, les aspects et les maisons (lorsque cela est possible).
  4. Couche d'agrégation échantillonne la période, extrait les événements (aspects, entrées, stations, lunations, éclipses) et classe les facteurs.
  5. Moteur d'interprétation mappe les spécifications des facteurs au contenu éditorial en utilisant un ordre fixe, des poids explicites et la sélection d'une variante de hachage stable.
  6. Moteur éditorial génère les récits de section à partir des packs de contenu V2 avec une composition spécifique à la période (ouverture → décalage → résultat).
  7. Gateway renvoie le payload du moteur plus les enveloppes d'entreprise (_enterprise, _api_metadata_) pour les métadonnées d'intégration.

Garanties de Déterminisme

Le déterminisme n'est pas un hasard — il est appliqué à chaque niveau :

Garantie Mécanisme d'application
Même payload → mêmes facteurs Ordre explicite des facteurs par période + poids fixes
Même facteurs → mêmes variantes de contenu Sélection d'index de hachage SHA-256 stable
Même variantes → même formulation Cycle de formulation déterministe à partir des packs de contenu V2
Même formulation → JSON identique Cohérence de la réécriture éditoriale + déduplication des lignes de séparation des sections

Cela signifie que vous pouvez hacher deux requêtes indépendantes avec le même corps et obtenir le même résultat, ce qui permet un stockage en cache fiable, des tests de régression QA et un débogage reproductible.

Rapports publics vs Personnalisés

Les deux sont des modes valides pour la production. La différence n'est pas de qualité ; c'est la profondeur d'activation.

Mode public (basé sur le signe)

Fournissez uniquement un signe et une date du zodiaque. Le moteur produit une lecture stable et partagée pour tous les utilisateurs ayant ce signe dans cette période.

  • Idéal pour les flux de public et le stockage en cache rentable (12 signes × 4 périodes × 365 jours = ~17 520 caches uniques par jour)
  • Pas de calculs de maisons — les affectations rising_sign, house_cusps et du corps house sont null
  • Adapté pour un déploiement rapide, les horoscopes de style magazine et les niveaux freemium### Mode personnalisé (tenant compte de la date de naissance)

Fournir le contexte de naissance (birth_time, coordonnées, fuseau horaire) pour activer des vecteurs plus profonds. Deux utilisateurs ayant le même signe peuvent recevoir des éditoriaux différents en raison du changement de position des maisons et du signe ascendant, ce qui modifie les scores des facteurs.

  • Champs obligatoires : birth_time (HH:MM) + birth_latitude + birth_longitude
  • Débloque : signe ascendant, 12 cuspes de maisons, affectation planète-maison et facteurs axés sur les maisons (daily_house_focus, weekly_house_focus, monthly_house_focus, yearly_house_focus)
  • Idéal pour les abonnements premium et les expériences à forte rétention
  • Prend en charge des modules d'application plus riches et des canaux de personnalisation

Modèle d'éditorial basé sur les facteurs

Le moteur est piloté par des piles de facteurs — des moteurs d'interprétation déterministes calculés à partir de captures célestes et d'agrégation de périodes. Chaque période a un ordre de facteurs défini et des poids explicites.

Piles de facteurs par période

Période Nombre de Facteurs Facteurs Clés
Quotidien 5-6 sun_in_sign, moon_in_sign, transits_archetypes, aspects, daily_house_focus
Hebdomadaire 10 weekly_moon_phase, planetary_focus, retrograde_archetypes, weekly_theme_archetypes, weekly_house_focus
Mensuel 11 monthly_lunation_archetypes, eclipse_archetypes, outer_planet_focus, monthly_theme_archetypes, monthly_house_focus
Annuel 13 jupiter_in_sign, saturn_in_sign, nodal_axis, yearly_house_focus, yearly_theme_archetypes

Couche supplémentaire de familles de rapports dédiée aux piles de facteurs : - Planètes: planet_core_archetypes, planet_condition_archetypes, planet_house_focus, planet_sign_archetypes - Date de naissance: solar_return_tone, birthday_year_reset, natal_sun_house_year_theme - Aspect: Piles basées sur l'aspect dominé, calculé ou surchargé - Transit: Piles basées sur le transit dominant, calculé ou surchargé

Chaque facteur possède un poids explicite (par exemple, moon_in_sign: 1.15 (quotidien), yearly_theme_archetypes: 1.30 (annuel)) qui influence la notation de la section et la dérivation de l'intensité.

Ce modèle évite les dérives aléatoires et maintient le ton éditorial lié aux facteurs calculés, avec une traçabilité complète dans factor_details.

Statistiques d'application personnalisées quotidiennes (Horoscope principal)

Pour le mode personnalisé quotidien, le moteur renvoie des blocs de statistiques d'application prêts à l'emploi à data.daily_personalized_stats. Ces blocs sont idéaux pour les cartes de tableau de bord et les widgets de résumé.Statistiques quotidiennes Activation

Déclencheur d'activation : period=daily et requête de naissance personnalisée incluant à la fois birth_time et coordinates.

Blocs clés :

  • overall_pulse — score de vitalité quotidienne composite
  • archetype_scores — décomposition en huit dimensions (wisdom, creativity, confidence, intuition, allure, romance, career, emotions)
  • harmony_discord — les 4 signes harmonieux et les 4 signes discordants
  • elemental_balance — répartition feu/terre/air/eau
  • momentum_channels — signaux de momentum planétaire

Contrôle de la densité des données :

  • daily_stats_detail: "full" pour les données complètes du diagramme avec des niveaux de confiance par bloc
  • daily_stats_detail: "compact" pour des charges de données client plus légères (idéal pour les widgets mobiles)

Points saillants de la conception de la requête

Le moteur prend en charge des contrôles clairs et typés pour la configuration et le comportement de rendu astrologique. Les options courantes incluent :

Champ Type Objectif
period chaîne daily, weekly, monthly, yearly
sections tableau Domaines de vie à inclure (par exemple, general, career, love_singles)
sign / birth chaîne / objet Source du signe (public vs personnalisé)
target_date chaîne Ancre de date explicite (YYYY-MM-DD) pour la reproductibilité
zodiac_system chaîne tropical ou sidereal
ayanamsa chaîne Système d'offset sidéral (lahiri, fagan_bradley, etc.)
house_system chaîne placidus, whole_sign, equal, koch
node_type chaîne Noyau lunaire réel (true) ou moyenne (mean)
tenant_id chaîne Isolation de l'espace de cache pour les environnements multi-locataires ou A/B

Garanties de forme de réponse dans le Gateway

Les réponses du Gateway passent par les données du moteur et ajoutent des wrappers :

  • _enterprise — informations sur le niveau de plan, les quotas et les limites de débit
  • _api_metadata_ — informations sur le point de terminaison, les langues prises en charge et le contexte de la requête

Pour les points de terminaison de rapports basés sur le moteur, _api_metadata_.supported_languages est uniquement en anglais :

{
  "_api_metadata_": {
    "supported_languages": ["en"]
  }
}

Politique de langue et de traduction

Les points de terminaison de rapports alimentés par le moteur en direct ne prennent actuellement en charge que lang=en. Cela est intentionnel pour préserver la nuance éditoriale déterministe en production tandis que la fiabilité de la traduction est organisée séparément. La couche d'aide à la traduction de la passerelle (lang=en|es|de|fr|pt) fournit une sortie traduite à la limite de l'API pour tous les points de terminaison de rapports autres que l'horoscope.

Pipeline de contenu : Packs de contenu V2


Contenu éditorial provenant de packs de contenu structurés V2 dans le référentiel de contenu du moteur. At runtime, the content repository selects variants deterministically via stable hash selection with a four-level fallback chain:

  1. Correspondance exacte (type_facteur + valeur_facteur + intensité)

---2. Toute valeur pour factor_type (factor_type + intensity)3. Tout facteur dans la section (section + intensité)

  1. Modèle de page de secours

This structure ensures editorial variety across intensities while preserving reproducibility for the same seed.

Modèle de confiance : Noyau fermé + Open Source léger

Notre moteur de production principal est à source fermée et optimisé pour la fiabilité enterprise, la profondeur et les opérations gérées. Il inclut :

  • Rapports personnalisés complets prenant en compte tous les aspects (toutes les périodes)
  • Rapports de cycle de naissance avec facteurs de retour solaire
  • Suites de rapports incluant : planète, aspect, transit, maison et rapport planète-maison
  • Carte de naissance avec rendu SVG configurable
  • Mise en cache Redis, métriques, vérifications de santé et mise à l'échelle horizontale

Afin de soutenir les astrologues indépendants et l'évaluation des développeurs, nous fournissons également le moteur open-source lite :

Utilisez OpAstro pour évaluer la qualité du moteur, explorer la logique de calcul des facteurs et vérifier l'intégration de Swiss Ephemeris. Mettez à l'échelle vers les routes d'entreprise de NumerologyAPI pour des couches de rapports plus riches, une couverture plus large des points de terminaison et des opérations de production gérées.

Chemin d'intégration1. Commencer par les rapports de niveau public — quotidiens/hebdomadaires/mensuels/annuels en utilisant uniquement sign. Aucune donnée de naissance n'est requise. Optimiser le cache.

  1. Ajouter des champs de naissance personnalisés — fournir birth_time + coordonnées pour débloquer des éditoriaux différenciés tenant compte des aspects astrologiques.
  2. Ajouter des familles de rapports spécialisées — points de terminaison planétaires, aspects, transits et maisons pour des surfaces de produits plus approfondies.
  3. Ajouter des points de terminaison de naissance — JSON complet du chart de naissance + roue SVG pour la visualisation et les flux de travail astrologiques avancés.
  4. Optimiser avec des sections — demander uniquement la sections dont votre UI a besoin (par exemple, ["general", "career"]) pour réduire la taille des données.
  5. Utiliser tenant_id pour l'isolation du cache — séparer les niveaux gratuits/premium ou les variantes A/B sans pollution du cache.

Stratégie de mise en cache

Mode Efficacité du cache Stratégie
Public (uniquement les signes) Élevée — ~17 520 caches uniques par jour Pré-chauffer le lendemain ; TTL de 1 à 4 heures
Personnalisé (tenant compte de la naissance) Inférieure — par utilisateur Clés de cache par utilisateur ; TTL de 24 heures ; Redis recommandé

Lectures suivantes