Agent S&P500 MVP lancé : répondre aux questions financières ancrées dans les données SEC

Mise à jour (2026) : L'agent S&P 500 a été retiré. Ce post documente le lancement original du MVP à des fins historiques. Sydney se concentre maintenant sur le contenu du blog et les produits de Chandler. Essaie le Sydney actuel →

---

Bonjour,

Je suis heureux de partager que depuis mon dernier post sur mes difficultés à travailler sur l'agent S&P500, la version MVP est prête ! :D Laisse-moi te guider à travers ce que ce produit minimum viable peut faire et comment il est né.

Que peut faire ce MVP ?

1. Plonger dans une décennie de données : La base de données de l'agent inclut les 10 dernières années de faits d'entreprises soumis à SEC EDGAR. Plutôt sympa, non ?
2. Des réponses fiables : Parce qu'elles sont ancrées dans des faits réels soumis à la SEC, tu peux faire confiance à la qualité des réponses.
3. Vérification des faits facilitée : L'agent inclut toujours des données de référence dans sa réponse finale. Donc si tu es sceptique, tu peux vérifier toi-même !
4. Gère des questions complexes : Il peut traiter des requêtes semi-complexes comme "Compare les revenus d'Apple et Microsoft entre 2020 - 2022 ?" ou "Comment la marge opérationnelle de Microsoft a-t-elle changé de 2020 à 2022 ?" Pourquoi sont-elles semi-complexes ? Eh bien, l'agent doit "raisonner" et décomposer ces questions larges en questions plus petites, chercher des informations dans la base de données, puis assembler le tout.
   • Par exemple, pour répondre à la première question, l'agent a besoin de connaître les revenus individuels de chaque entreprise pour chaque année 2020, 2021 et 2022, puis de faire la comparaison.
5. À jour (presque) : La date limite est août 2024. Tout ce qui a été soumis à la SEC après cette date n'est pas dans cette version MVP.
6. Streaming HTML : Le streaming fonctionne ! Yay ! :D Il s'est avéré que DRF et React supportent nativement le streaming, donc avec Langgraph, nous avons un flux de conversation réactif, affiché dans un format facile à lire. J'ai eu du mal avec le streaming HTML pendant un moment.

Un aperçu sous le capot

Si tu lis encore à ce stade, tu veux probablement en savoir plus sur la façon dont j'ai construit ce MVP et surmonté certains des défis que j'ai mentionnés avant. Alors, devenons un peu techniques !

1. Données allégées : Au lieu d'utiliser les rapports complets 10-K ou 10-Q, j'utilise les "Faits" soumis à la SEC. Cela signifie que notre base de données est significativement plus petite — moins de 2 Go ! Voici quelques exemples de ce que les entreprises publiques soumettent à la SEC :

  "AccruedRoyaltiesCurrent": \{
    "label": "Accrued Royalties, Current"
  \},
  "AccumulatedDepreciationDepletionAndAmortizationPropertyPlantAndEquipment": \{
    "label": "Accumulated Depreciation, Depletion and Amortization, Property, Plant, and Equipment"
  \},
  "AccumulatedOtherComprehensiveIncomeLossNetOfTax": \{
    "label": "Accumulated Other Comprehensive Income (Loss), Net of Tax"
  \},
  "AccumulatedOtherComprehensiveIncomeLossOtherThanTemporaryImpairmentNotCreditLossNetOfTaxAvailableforsaleDebtSecurities": \{
    "label": "Accumulated Other Comprehensive Income (Loss), Other than Temporary Impairment, Not Credit Loss, Net of Tax, Available-for-sale, Debt Securities"
  \},
  "AdditionalPaidInCapitalCommonStock": {
    "label": "Additional Paid in Capital, Common Stock"

Cela signifie aussi que je n'ai pas besoin d'un magasin vectoriel à grande échelle et haute vitesse, qui est très coûteux (dans la plage de 600 à 700 $/mois)

2. Cloud SQL PostgreSQL comme base de données principale : J'utilise Cloud SQL PostgreSQL comme base de données principale. Puisque j'utilisais déjà Cloud Run CI/CD de GCP, il était logique de rester avec les offres de Google. C'est un concept entièrement nouveau pour moi, donc j'ai dû apprendre à faire la migration de la base de données du local vers le cloud, puis comment configurer le backend pour fonctionner avec la base de données Cloud SQL en utilisant l'IP privée. La documentation de GCP a été utile.

3. React rencontre Django : C'est ma première expérience réussie de déploiement à la fois du frontend React et du backend Django Rest Framework (DRF) avec une base de données Cloud SQL. Ce fut un parcours d'essais et d'erreurs, mais le o1-preview de ChatGPT et Anthropic Claude 3.5 Sonnet ont été d'une grande aide. Ils sont vraiment très puissants, surtout quand tu leur donnes suffisamment de contexte du problème que tu résous.

4. Agent intelligent : L'agent est construit en utilisant Langgraph. Il a deux outils principaux : Google Search et un outil de réponse aux questions financières. Il décide lequel utiliser en fonction de ta question.

5. Comment les requêtes SQL sont-elles générées ?

Il n'est pas simple de convertir une question utilisateur générique/large en requêtes SQL adaptées à la base de données. L'une des principales raisons est que lorsque les entreprises soumettent les faits financiers à la SEC, elles utilisent des concepts/terminologies financières qui ne sont pas intuitifs pour les gens ordinaires.

Par exemple, le "chiffre d'affaires" peut être représenté par plusieurs faits comme :

• Revenue
• Revenue from Contract with Customer, Excluding Assessed Tax
• Revenue from related Parties
• Deferred Revenue
• etc...

Et d'une entreprise à l'autre, elles peuvent choisir d'utiliser des libellés différents pour le même concept. Par exemple, Apple utilise "Revenue from Contract with Customer, Excluding Assessed Tax" tandis que Tesla utilise "Revenue".

Ou quand tu demandes la "marge opérationnelle", ce n'est peut-être pas un fait que l'entreprise soumet à la SEC. À la place, elle soumet le chiffre d'affaires total et le résultat opérationnel (perte).

Une autre situation est celle où les entreprises ont changé de nom au fil du temps, donc tu dois t'assurer que les requêtes SQL incluent à la fois l'ancien nom et le nouveau nom.

Alors comment j'instruis la machine pour sélectionner le bon fait/libellé pour une question large particulière ?

J'utilise la recherche hybride avec Weaviate pour trouver les faits ou libellés les plus pertinents et les envoyer au modèle LLM.

6. Les tests par étapes sont essentiels

Avant le déploiement final en production, j'ai décomposé le processus en étapes et testé chacune :

1. Test local du backend DRF avec une base de données locale.

2. Test du backend en container Docker avec une base de données locale.

3. Migration de la base de données PostgreSQL vers Cloud SQL et test.

4. Test du backend en container Docker avec Cloud SQL.

5. Test local du frontend React.

6. Frontend React avec le backend de production et Cloud SQL.

7. Migration du frontend React vers WordPress en production.

8. Tests de bout en bout.

J'ai dû apprendre cette approche étape par étape à la dure. Au départ, j'ai sauté certaines étapes et testé en plus gros morceaux, mais les modèles de langage (LLM) ne pouvaient pas identifier exactement où les choses avaient mal tourné.

Et ensuite ?

1. Résoudre le problème de démarrage à froid : Pour l'instant, il faut un peu de temps à l'agent pour répondre à la première question. Je travaille sur une solution rentable.
2. Montrer les étapes intermédiaires aux utilisateurs : Lors de la réponse à des questions complexes comme "Compare les revenus d'Apple et Microsoft entre 2020 et 2022", il faut du temps à l'agent pour générer la réponse finale. Montrer les étapes sur lesquelles l'agent travaille en temps réel pourrait améliorer l'expérience utilisateur.
3. Enrichir avec le contenu textuel des 10-K/10-Q : Je prévois d'inclure plus de contenu textuel pertinent des déclarations 10-K et 10-Q pour fournir des réponses plus détaillées.

C'est tout de ma part pour l'instant. Essaie la version MVP et dis-moi ce que tu en penses ! As-tu essayé de construire quoi que ce soit avec des données financières ou des déclarations SEC ? J'adorerais entendre ton expérience — laisse un commentaire ci-dessous ou envoie-moi un email directement (chandler@chandlernguyen.com).

Cordialement,

Chandler