> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2026/w20-heuristic-systems-and-the-checkout-strategy-platform.md).

# W20-Heuristic System et plateforme de stratégies du paiement

La semaine dernière, Weng Jiayi, ingénieur en post-entraînement chez OpenAI, a publié [Learning Beyond Gradients](https://trinkle23897.github.io/learning-beyond-gradients/). Il y propose un nouveau paradigme. Des stratégies programmées, une représentation de l'état, des canaux de retour, un historique d'expériences, des capacités de rejeu et de test, une mémoire historique et un mécanisme de mise à jour exécuté par un agent de programmation peuvent constituer un Heuristic System (HS) qui évolue continuellement sous l'effet du Heuristic Learning (HL). Ce qui est mis à jour est la structure logicielle, pas les paramètres d'un réseau neuronal.

En le lisant, j'ai trouvé la coïncidence frappante. N'est-ce pas une description exacte de ce que fait notre plateforme de stratégies du paiement, ou de ce qu'elle cherche à devenir ?

Il faut réexaminer l'idée selon laquelle cette plateforme évoluerait simplement en remplaçant des règles par des algorithmes. Selon les concepts de l'article, nous construisons plutôt un Heuristic System. La couche de règles protège en temps réel les contraintes métier. Celle des grands modèles construit hors ligne des représentations structurées de l'état. Celle des petits modèles prend les décisions stratégiques à partir de l'état complet. Les trois évoluent ensemble au moyen d'une chaîne de données, d'un système d'expérimentation et de tests de régression communs.

Beaucoup de règles heuristiques ne sont pas inutiles ; leur entretien coûte simplement trop cher. Avec les bons outils, la courbe de maintenance s'aplatit et un système de règles peut être conservé durablement. Parmi les presque mille règles du paiement, la plupart ne sont pas erronées. Elles se sont accumulées dans un système sans couches distinctes, sans couverture de tests et sans gestion du cycle de vie, jusqu'à rendre la complexité incontrôlable.

La boucle centrale du HL est : retour de l'environnement -> lecture du contexte -> modification de la policy / des tests -> nouvelle vérification -> enregistrement du résultat -> tour suivant. Dans le paiement, cette boucle est aujourd'hui rompue. Les journaux de décision sont incomplets, le système d'expérimentation manque et les capacités de simulation et de rejeu n'existent pas. L'entrée « retour de l'environnement » n'est pas collectée sous une forme structurée. La chaîne complète de données, les journaux de décision, les expériences et le rejeu des stratégies à construire ne sont donc pas de simples capacités de support : ce sont les infrastructures de la boucle HL.

Un HS exige une représentation structurée de l'état. Sans elle, la policy ne peut décider qu'à partir de caractéristiques superficielles, quelle que soit la complexité du modèle. Le travail des grands modèles dans le KYC du paiement consiste précisément à construire cette représentation. Il ne s'agit pas de recommandation en temps réel, mais de transformer des caractéristiques comportementales difficiles à exprimer directement en étiquettes structurées utilisables par les stratégies en aval : par exemple, savoir si un utilisateur emploie WeChat par habitude ou parce qu'il est sensible aux subventions.