Open source · lu depuis la source
Le 13 août 2026, X a publié les poids de classement numériques qu'il avait retenus en janvier. La plupart des chiffres circulant sur « l'algorithme de X » sont erronés — généralement parce qu'ils étaient corrects pour le modèle de 2023, qui n'existe plus. Chaque nombre sur cette page est un lien vers la ligne de code source d'où il provient, épinglé à un commit.
182
paramètres en direct
modifiables sans déploiement
23
constantes compilées
nécessitent une modification du code
135
composants du pipeline
sources, filtres, évaluateurs
12
affirmations vérifiées
chacune par rapport à sa ligne source
2798
comptes nommés dans le code
retirés de Pour Vous à moins que vous ne les suiviez
Collez un lien vers n'importe quelle publication publique. Vous obtiendrez les règles qui s'y appliquent réellement — y compris les restrictions nationales qui peuvent la masquer — lues à partir du commit épinglé.
Les pondérations
X states it runs cron scripts that set the defaults in the repository's code to be the primary production values, and aims for experiments running at 10% or more of traffic to be visible in the repository. The values below are those defaults, read at the pinned commit.
Ce sont les poids que le "scorer" applique — mesurés, non promis. Avant le scoring, `perturbed()` multiplie 25 des 27 poids ci-dessous par `(sigma * perturbation_sign(salt, user_id, head)).exp()` — le signe étant fixe par spectateur et par tête. Les 2 qu'il laisse intacts sont les poids modificateurs : BidirectionalFollowDwellWeightBoost, BidirectionalFollowReplyWeightBoost. `WeightPerturbationSigma` et `WeightPerturbationSalt` sont des "feature switches" : X peut les modifier sans déployer de code. Au commit épinglé, `WeightPerturbationSigma` est de 0.0, et la garde `sigma <= 0.0` les renvoie inchangés. Lire à la source
Chaque ligne contient le code source dont elle est issue — appuyez surExpliquerpour déplier les lignes de code Rust réelles, sans quitter la page.
| Action | Pondération | vs un like | Source |
|---|---|---|---|
| binaryMultiplies the predicted probability of a discrete action. | |||
| share via copy linkShareViaCopyLinkWeight | 20 | 40× | |
| quoteQuoteWeight | 5 | 10× | |
| replyReplyWeight | 5 | 10× | |
| share via dmShareViaDmWeight | 5 | 10× | |
| follow authorFollowAuthorWeight | 4 | 8× | |
| shareShareWeight | 2 | 4× | |
| retweetRetweetWeight | 1 | 2× | |
| favoriteFavoriteWeight | 0.5 | 1× | |
| clickClickWeight | 0.3 | 0.6× | |
| open linkOpenLinkWeight | 0.2 | 0.4× | |
| video openVideoOpenWeight | 0.07 | 0.1× | |
| dwellDwellWeight | 0.05 | 0.1× | |
| photo expandPhotoExpandWeight | 0.05 | 0.1× | |
| quoted clickQuotedClickWeight | 0.05 | 0.1× | |
| post unexploredPostUnexploredWeight | 0.02 | 0× | |
| profile clickProfileClickWeight | 0 | — | |
| quoted vqvQuotedVqvWeight | 0 | — | |
| vqvVqvWeight | 0 | — | |
| not dwelledNotDwelledWeight | -0.02 | −0× | |
| block authorBlockAuthorWeight | -31.2 | −62× | |
| not interestedNotInterestedWeight | -47.52 | −95× | |
| mute authorMuteAuthorWeight | -58.8 | −118× | |
| reportReportWeight | -234 | −468× | |
| continuousApplies to a quantity (watch or dwell seconds), not a probability. | |||
| cont click dwell timeContClickDwellTimeWeight | 0.4 | — | |
| cont dwell timeContDwellTimeWeight | 0.004 | — | |
| modifierNot a head weight: adds to another weight, or gates a branch. | |||
| bidirectional follow reply weight boostBidirectionalFollowReplyWeightBoost | 15 | — | |
| bidirectional follow dwell weight boostBidirectionalFollowDwellWeightBoost | 0 | — | |
Le regroupement en binaire, continu et modificateur est le nôtre — the weights struct and each field's use in vm-ranker/scoring/value_model.rs. X ne publie pas cette taxonomie ; nous les séparons car seuls les binaires sont comparables entre eux.
Définissez une probabilité prédite pour chaque action et observez sa contribution au score. Seuls les poids qui multiplient une probabilité sont proposés ici — c'est l'arithmétique que le code exécute réellement.
Pourquoi il n'y a pas d'« équivalent de j'aime » ici : Weights multiply a predicted probability, not an engagement count. Dividing one weight by another does not yield an exchange rate between actions.
Vérification des affirmations
Ce ne sont pas des inventions. La plupart étaient des chiffres précis pour le "heavy ranker" que Twitter a publié en 2023, un pipeline Scala qui a depuis été remplacé. Ils ont continué à circuler après que la chose qu'ils décrivaient ait cessé d'exister.
Chaque affirmation ci-dessous contient les recherches qui la soutiennent — le modèle, les fichiers, le nombre — afin que vous puissiez les exécuter vous-même contre le commit épinglé. Vous n'en verrez jamais une ici qui nous contredit : si c'était le cas, cette page échouerait à se construire plutôt que de publier la phrase qu'elle réfute.
Contradicted by the source
“Un repost vaut 20 fois un like.”
RetweetWeight est de 1,0 et FavoriteWeight est de 0,5, donc un repost a deux fois le poids d'un like — pas vingt fois.
D'où cela vient : Aucune version publiée de l'algorithme n'a jamais utilisé 20. Le ranker lourd de 2023 a également pondéré le retweet à 1,0 contre le favori à 0,5.
Was true, of an older version
“Une réponse vaut 27 fois un like (ou 13,5 fois).”
ReplyWeight est de 5,0 contre FavoriteWeight de 0,5, soit dix fois — et quarante fois entre les suivis mutuels, car BidirectionalFollowReplyWeightBoost ajoute 15,0 au poids de la réponse pour les publications originales entre les comptes qui se suivent.
D'où cela vient : Les deux chiffres étaient réels, pour un modèle qui n'existe plus : le ranker lourd de 2023 a publié 27 le 31/03/2023, puis 13,5 le 05/04/2023. Ils décrivent un pipeline Scala remplacé par l'actuel en Rust.
Was true, of an older version
“Les clics sur votre profil valent 12 fois un like.”
ProfileClickWeight est de 0,0. Un clic sur le profil ne contribue en rien au score pondéré.
D'où cela vient : 12,0 était le poids en 2023 pour `good_profile_click` — un signal composé différent (ouvrir un profil ET ensuite aimer ou répondre). Le modèle actuel a une tête de clic de profil simple, pondérée à zéro.
No such parameter exists
“Un signet vaut 10 likes — les signets sont le signal le plus fort.”
Il n'y a pas de poids de signet dans param.rs, donc les signets n'entrent pas du tout dans le score pondéré. Ils ne sont cependant pas invisibles : bookmark_count est hydraté sur chaque candidat comme une caractéristique du modèle, et ClientTweetBookmark compte comme un engagement positif dans l'historique du spectateur. Lu, mais non pondéré.
D'où cela vient : Le rafraîchissement Scala de 2025 a bien déclaré un paramètre home_mixer_model_weight_bookmark — avec une valeur par défaut de 0,0. Aucune version publiée ne l'a jamais pondéré à 10.
Ce que nous avons recherché, au commit épinglé
Il n'y a pas de poids de signet dans param.rs
bookmark · 2 fichiers · 0 correspondances
bookmark_count est hydraté sur chaque candidat en tant que caractéristique du modèle
bookmark_count · 1 fichier · 5 correspondances
ClientTweetBookmark compte comme un engagement positif dans l'historique du spectateur
ClientTweetBookmark · 1 fichier · 1 correspondance
Right numbers, wrong reading
“Un signalement annule 468 likes (−234,0 ÷ 0,5).”
L'arithmétique est juste et la conclusion est toujours fausse. Les poids multiplient une PROBABILITÉ PRÉDITE, pas un nombre d'actions. X indique que la probabilité de base d'un signalement est plus de mille fois inférieure à celle d'un like, donc diviser un poids par un autre ne donne pas un taux de change entre les actions.
D'où cela vient : Celui-ci n'est pas obsolète — c'est une mauvaise interprétation de chiffres corrects, et il apparaît même sur des pages qui publient le bon tableau. X a ajouté un avertissement explicite à ce sujet dans son propre README le 14/08/2026.
No such parameter exists
“La vélocité d'engagement compte 1000×, l'autorité de l'auteur 50×, la récence 22×.”
Aucun paramètre nommé pour la vélocité, l'autorité ou la récence n'existe dans param.rs. L'âge n'est pas du tout un poids — c'est une coupure nette : AgeFilter supprime toute publication plus ancienne que MAX_POST_AGE, une constante compilée de 48 heures. Rien ne multiplie le score d'une publication par sa fraîcheur.
Ce que nous avons recherché, au commit épinglé
Aucun paramètre nommé pour la vélocité, l'autorité ou la récence n'existe dans param.rs
velocity|authority|recency · 1 fichier · 0 correspondances
AgeFilter supprime toute publication plus ancienne que MAX_POST_AGE
AgeFilter::new\(.*MAX_POST_AGE · 1 fichier · 1 correspondance
Contradicted by the source
“Un groupe coordonné peut enterrer votre publication en la signalant ou en la bloquant massivement.”
X aborde ce point directement dans les commentaires de param.rs, et le mécanisme qu'il décrit est vérifiable : le modèle prédit VOTRE probabilité d'une action, donc les recommandations sont personnalisées — les signalements d'une brigade affectent principalement ce qui est recommandé aux personnes similaires à cette brigade. Et un engagement ne compte que s'il se produit sur une publication servie dans le fil d'actualité principal : naviguer directement vers une publication, par exemple depuis un chat de groupe, n'a aucun impact sur le classement.
D'où cela vient : Une inférence raisonnable à partir des poids négatifs très importants, que les poids seuls ne supportent pas.
Ce que nous avons recherché, au commit épinglé
X aborde ce point directement dans les commentaires de param.rs
recommendations are personalized · 1 fichier · 1 correspondance
Was true, of an older version
“X a publié le code mais a retenu les poids de classement pour des raisons de sécurité.”
Vrai pour la version de janvier 2026, faux depuis le 13/08/2026. Les valeurs numériques par défaut sont maintenant dans param.rs, et X déclare que les scripts cron les maintiennent égales aux valeurs de production primaires.
D'où cela vient : Rapportage précis de la publication de janvier 2026, jamais mis à jour après août.
Ce que nous avons recherché, au commit épinglé
X déclare que les scripts cron les maintiennent égaux aux valeurs de production primaires
cron scripts that set the defaults · 1 fichier · 1 correspondance
Contradicted by the source
“Les publications contenant des liens externes sont déclassées.”
Dans le code de classement publié, OpenLinkWeight est POSITIF à 0.2 et appliqué inconditionnellement — l'ouverture d'un lien est récompensée. Les liens ne sont pénalisés que par des étiquettes de sécurité telles que MALICIOUS_URL et DO_NOT_AMPLIFY, qui concernent la destination, et non le fait de créer un lien externe.
Ce que nous avons recherché, au commit épinglé
Les liens ne sont pénalisés que par des étiquettes de sécurité telles que MALICIOUS_URL
MALICIOUS_URL · 7 fichiers · 1 correspondance
… et DO_NOT_AMPLIFY
DO_NOT_AMPLIFY · 7 fichiers · 1 correspondance
Contradicted by the source
“Une coche payante offre un boost de classement.”
Aucun multiplicateur premium, vérifié ou d'abonnement n'existe dans param.rs, et aucun rescaleur de ce type n'apparaît dans les scoreurs publiés. Le code de 2023 en contenait un — des multiplicateurs de 4.0 en réseau et 2.0 hors réseau pour les auteurs vérifiés Bleus — et il a disparu de l'arbre actuel. Limite honnête : Phoenix est un modèle appris dont les poids ne sont pas publiés, donc une corrélation apprise ne peut être exclue par la lecture du code.
D'où cela vient : Le pipeline Scala de 2023 appliquait réellement un multiplicateur de 4.0 / 2.0 pour les vérifiés Bleus.
Ce que nous avons recherché, au commit épinglé
Aucun multiplicateur premium, vérifié ou d'abonnement n'existe dans param.rs
premium|verified|subscription · 1 fichier · 0 correspondances
aucun tel rescoteur n'apparaît dans les scoreurs publiés
premium|verified|subscription · 8 fichiers · 0 correspondances
Contradicted by the source
“X publie désormais les demandes de retrait gouvernementales dans son dépôt open-source, et le Brésil est le seul pays listé.”
Le dépôt publie le MÉCANISME d'application, jamais une requête. Les règles qui suppriment une publication pour les spectateurs dans un pays restreint — LegalTakedown et LocalLawsTakedown — lisent une raison qui contient le code pays, mais cette raison est récupérée à l'exécution depuis un service non publié, et le type qui la contient (TakedownReason) est défini dans un "crate" absent du dépôt. X publie également l'infrastructure autour de ce type, en Scala : un filtre de lecture gizmoduck qui supprime les retraits non appliqués avant qu'une lecture ne soit renvoyée, une colonne et une transformation du service d'entités de tweets qui récupèrent les raisons de retrait d'une publication, et les tâches internes qui transforment ces raisons en étiquettes affichées à un compte sur lui-même. Ainsi, les structures Thrift qui le contiennent — Takedowns { country_codes, takedown_country_reasons } — sont lues par le code publié, dans 3 fichiers : `takedowns/gizmoduck/RedactUnenforcedTakedownsFilter.scala`, `takedowns/tweet-entity-service/TakedownReasonsTransform.scala`, `under-the-hood/scalding/UthPctdAccountTakedownEventsJob.scala`. Ce que cela ajoute est plus de MÉCANISME, pas une seule requête : au commit épinglé, aucun code pays n'est écrit à côté d'une raison de retrait en dehors des "fixtures" de test — les seuls codes à deux lettres que le code de retrait contient sont `xx`, `xy`, les sentinelles mondiales que la source nomme elle-même, qui signifient partout et sont l'opposé d'un pays. Et la méthode qui demanderait au service d'entités de tweets ces codes sous son propre nom, get_takedown_country_codes, n'apparaît nulle part dans le dépôt. Le Brésil est une chose entièrement différente : une liste codée en dur de 2795 comptes signalés à la Cour électorale, provenant de l'ensemble de données publiques des candidats, supprimés de "Pour vous" pour chaque spectateur dans le monde entier, à moins qu'il ne suive le compte — sans aucune condition de pays, ce qui est l'opposé du fonctionnement d'un retrait légal ici. Limite honnête : un dépôt sans pays codé en dur n'est pas une plateforme sans retraits par pays. Les requêtes existent ; elles vivent en dehors du dépôt, agrégées, dans le Centre de Transparence et le rapport DSA.
D'où cela vient : Le propre message de X du 14 août a annoncé deux choses : les poids de classement et le filtre électoral brésilien. Musk l'a cité le lendemain en 61 caractères — "Toute censure exigée par les gouvernements est désormais clairement visible" — sans nommer ni le dépôt, ni les demandes, ni les pays ; la presse l'a lié à une notification destinée aux utilisateurs qui avait été annoncée, mais non déployée. Les mots "demandes" et "dans l'algorithme open-source" apparaissent pour la première fois ensemble sur un compte agrégateur.
Ce que nous avons recherché, au commit épinglé
L'infrastructure Scala publiée lit les structures de retrait Thrift — Takedowns { country_codes, takedown_country_reasons }
\bTakedowns\b|\btakedownCountryReasons\b · 43 fichiers · 15 correspondances
Contradicted by the source
“Masquer un mot-clé masque chaque publication qui le contient.”
Un mot-clé masqué n'est pas une seule règle. Le service de chronologie publié l'applique avec 2 filtres qui ne lisent pas le même texte : ViewerMutedKeywordFilter, enregistré dans phoenix_candidate_pipeline.rs, le compare à tweet_text ; FollowingViewerMutedKeywordFilter, enregistré dans reverse_chron_posts_pipeline.rs, le compare à ancestor_texts, quoted_tweet_text et tweet_text. Les champs que seuls certains d'entre eux lisent — ancestor_texts et quoted_tweet_text — sont écrits par conversation_gap_ancestor_hydrator.rs, quote_hydrator.rs et quoted_post_text_hydrator.rs, enregistrés dans phoenix_candidate_pipeline.rs, phoenix_scores_pipeline.rs et reverse_chron_posts_pipeline.rs. Un pipeline qui n'exécute pas ces "hydrators" ne les remplit jamais : là, le texte d'une publication citée ou ancestrale n'est pas seulement non lu, il est absent. Au-delà de la chronologie, le moteur de règles de filtrage de visibilité — la couche qui peut masquer une publication où qu'elle apparaisse — contient ViewerMutesAuthor (Mutes) et ViewerMutesRetweets (MuteRetweets), et aucune règle dont la décision lit un mot-clé. Le seul résultat de mot-clé masqué que ce dépôt nomme, MatchesMutedKeyword, apparaît exactement 1 fois — dans graphql_results.rs — et seulement à gauche d'une branche de correspondance le mappant à une étiquette interstitielle. Rien ici ne le décide ; ce qui le fait n'est pas publié. Deux limites honnêtes. Ce dépôt est le service qui construit une chronologie : ce que le masquage fait dans les notifications ou dans la recherche est décidé ailleurs, dans un code que X ne publie pas, et une absence ici est une absence du dépôt, pas du produit. Et nous ne vous disons pas quel onglet chaque pipeline sert — ce câblage traverse plusieurs couches, et un mappage que nous ne pouvons pas extraire proprement est un mappage que nous ne publions pas.
D'où cela vient : Le masquage est un paramètre unique dans le produit, il est donc perçu comme une règle unique qui s'applique partout. Le code publié montre quelque chose de plus restreint : un mot-clé masqué est appliqué pendant qu'une chronologie est assemblée, et les filtres qui l'appliquent ne lisent pas tous le même texte — ainsi, une publication peut contenir le mot dans un endroit qu'aucun filtre sur ce chemin ne regarde jamais.
Le pipeline
Les sources candidates produisent des publications, les hydrateurs y attachent des caractéristiques, les filtres peuvent supprimer une publication purement et simplement, les scoreurs ne peuvent que la déplacer. Chaque nœud est lié à son fichier. Les arêtes déclarent comment nous les avons dérivées — lues à partir du code, données par l'agencement du répertoire, ou, au plus faible, appariées par nom.
Par pays
Deux listes de pays déterminent ce qui change en fonction de votre lieu de lecture, et elles n'ont pas la même signification. L'une retient les médias sensibles pour les spectateurs qui n'ont pas déclaré leur âge. L'autre décide simplement quels pays le modèle est autorisé à distinguer — tout autre pays devient « autre », ce qui n'est pas une restriction, mais seulement un angle mort. Chaque carte ci-dessous indique d'où provient sa propre liste : une constante appliquée par le code, ou une valeur de repli qu'un paramètre d'exécution peut remplacer.
Cliquez sur un pays en rose pour lire les comptes que ce code y nomme, un par un. Dans tout le référentiel, un seul pays possède une telle liste.
Comment cela est vérifié : « l'ensemble du dépôt » est vérifié sur l'ensemble du dépôt, et non sur une seule langue : chaque fichier sous le commit épinglé est lu, et une liste de comptes nommés est trouvée par sa FORME — un @identifiant écrit dans une ligne de commentaire, immédiatement suivi de l'identifiant numérique du compte. Cette forme ne dépend pas de Rust, ainsi, le jour où la même liste est publiée dans une autre langue, la compilation l'indique au lieu que la page reste silencieuse.
2798 comptes sont nommés directement dans le code source, par identifiant numérique et par pseudonyme. Tout le reste dans le chemin d'application agit sur une étiquette attachée à l'exécution, et cet étiquetage n'est pas publié.
Brazil2026ElectionFilterhome-mixer/filters/brazil_2026_election_filter.rs:73Identifiants d'utilisateur signalés au Tribunal électoral pour les élections brésiliennes de 2026.
Filtre pour les élections brésiliennes de 2026 Art. 28 § 1º-A de la Résolution électorale nº 23.610 : Les fournisseurs d'applications qui utilisent un système de recommandation pour les utilisateurs doivent exclure des résultats les chaînes et profils signalés au Tribunal électoral conformément aux termes du § 1º de cet article et, sauf en cas de promotion payante, le contenu qui y est publié. https://dadosabertos.tse.jus.br/dataset/candidatos-2026
⚠ Aucune condition de pays, de marché ou de localisation n'apparaît dans le fichier de filtre ou autour de la ligne qui l'enregistre. C'est une déclaration concernant le code publié — quel pipeline dessert quel marché peut être décidé dans une couche que X ne publie pas.
52 comptes supplémentaires sont nommés dans ce fichier et NE SONT PAS filtrés — le code explique pourquoi chacun a été laissé tel quel : 44 × « @… aucun compte actif trouvé. » ; 8 × « Nous pensons que le compte @… signalé par le candidat n'est pas le compte réel du candidat, nous ne le filtrons donc pas actuellement. » Ainsi, 2847 comptes nommés sont pris en compte ici, dont 2795 sont effectivement filtrés.
Enregistré dans le pipeline à home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:391
Les identifiants numériques dans le fichier sont obscurcis — le référentiel le dit lui-même. Les alias ne le sont pas.
ThunderServiceImplthunder/thunder_service.rs:30⚠ Aucune condition de pays, de marché ou de localisation n'apparaît dans le fichier de filtre ou autour de la ligne qui l'enregistre. C'est une déclaration concernant le code publié — quel pipeline dessert quel marché peut être décidé dans une couche que X ne publie pas.
Tous les 3 comptes, par ordre de source
Les identifiants numériques dans le fichier sont obscurcis — le référentiel le dit lui-même. Les alias ne le sont pas.
Cette liste est reproduite à partir d'un dépôt public Apache-2.0, qui stipule que les pseudonymes sont inclus pour la transparence. Nous rapportons ce que le code fait. Nous n'approuvons, ne vérifions ni ne jugeons les rapports qui ont placé un compte ici.
Retraits gouvernementaux
Le dépôt contient les règles qui masquent une publication aux lecteurs dans un pays qui l'a demandé. Il ne contient aucune requête, ni aucun pays : la raison qui porte le code pays est récupérée à l'exécution depuis un service que X ne publie pas.
0
requêtes de retrait publiées dans le dépôt
0
pays associés à une
2
règles agissant sur une raison de retrait
Comment cela est compté : chaque fichier du dépôt est scanné au moment de la compilation — pas seulement ceux de Rust, car l'infrastructure de retrait réside également en Scala, et une absence mesurée là où la chose n'est plus n'est pas une absence. Le code de test est supprimé à deux niveaux — les fichiers qu'un parent déclare `#[cfg(test)] mod …;` sont exclus, et dans le reste le corps `#[cfg(test)]` est coupé — et ce qui est recherché est un code pays écrit à côté d'une raison de retrait. Les codes à deux lettres que la source elle-même nomme mondialement (`xx`, `xy`) signifient partout plutôt qu'un pays : ils sont mis de côté et listés publiquement. La compilation échoue si ce nombre cesse d'être zéro — l'affirmation ci-dessus ne peut pas devenir obsolète d'elle-même.
reads a DMCA flag on the media
la règle délègue : le champ est lu dans TweetPredicate::HasDmcaMedia · rule_spec.rs:661, has_dmca_media() · tweet.rs:34
reads allow/deny country lists carried by the media — not a takedown reason
la règle délègue : le champ est lu dans media_restricted_in() · tweet.rs:68
reads the takedown reasons attached to the post at runtime — Dmca, LegalRequest, UnspecifiedReason
la règle délègue : le champ est lu dans takedown_in() · tweet.rs:58
reads the takedown reasons attached to the post at runtime — BystanderReport
la règle délègue : le champ est lu dans takedown_in() · tweet.rs:58
D'où vient le pays : le type qui le porte, TakedownReason, n'est défini dans aucun fichier de ce dépôt — il est importé de xai_core_entities, une bibliothèque qui n'est pas publiée ici.
Et la méthode qui récupérerait les pays d'un retrait, get_takedown_country_codes, n'apparaît nulle part dans le dépôt. L'interface existe du côté de X ; le code publié ne l'appelle jamais.
Lisez ceci correctement : un dépôt sans pays codé en dur n'est pas une plateforme sans retraits par pays. Les requêtes existent — elles vivent en dehors de ce dépôt, agrégées par pays et par semestre dans les rapports de transparence de X, jamais avis par avis. Ce qui est mesuré ici est ce que le code dit, pas ce que l'entreprise fait.
Méthode et limites
Les pondérations ci-dessus sont appliquées aux probabilités produites par Phoenix, un transformeur appris dont les paramètres entraînés ne sont pas publiés. La lecture du code ne peut pas exclure une corrélation que le modèle aurait apprise de lui-même.
X déclare retenir les modèles de prompt du LLM Grox et certaines règles d'application, afin de réduire la manipulation. Le code du classificateur et le moteur de règles sont publiés ; le texte du prompt ne l'est pas.
X affirme que les scripts cron maintiennent ces valeurs par défaut égales aux valeurs de production, et que les expériences dépassant environ 10 % du trafic devraient être visibles ici. Ce sont toutes deux des affirmations concernant un système que personne en dehors de X ne peut observer.
Les noms de paramètres et les extraits de code sont conservés en anglais : ils citent le code source, et un identifiant traduit ne correspondrait plus à la ligne qu'il référence. Les vérifications de revendication sont traduites — les identifiants qu'elles contiennent sont laissés tels quels.
C'est la méthode que nous vendons, appliquée à une source controversée : prendre quelque chose d'opaque, le transformer en un graphe où chaque valeur porte sa provenance, et refuser de publier un chiffre que nous ne pouvons pas citer. Nous faisons de même pour les marchés publics, les financements de recherche et les données d'entreprise.