S&P500 Agent MVP gestartet: Finanzfragen beantwortet, gestützt auf SEC-Daten

Update (2026): Der S&P 500 Agent wurde eingestellt. Dieser Beitrag dokumentiert den ursprünglichen MVP-Launch zu historischen Zwecken. Sydney konzentriert sich jetzt auf Blog-Inhalte und Chandlers Produkte. Die aktuelle Sydney ausprobieren →

---

Hallo zusammen,

ich freue mich, mitteilen zu können, dass seit meinem letzten Beitrag über meinen Kampf mit dem S&P500 Agent die MVP-Version bereit ist! :D Lass mich erläutern, was dieses Minimum Viable Product kann und wie es entstanden ist.

Was kann dieser MVP?

1. Ein Jahrzehnt an Daten erkunden: Die Datenbank des Agenten enthält die letzten 10 Jahre an Unternehmensfakten, die bei SEC EDGAR eingereicht wurden. Ziemlich ordentlich, oder?
2. Zuverlässige Antworten: Da er auf tatsächlichen, bei der SEC eingereichten Fakten basiert, kann man der Qualität der Antworten vertrauen.
3. Faktencheck freundlich: Der Agent enthält stets Referenzdaten in seiner Endantwort. Falls du skeptisch bist, kannst du es selbst nachprüfen!
4. Knifflige Fragen meistern: Er kann halbkomplexe Fragen wie "Vergleiche den Umsatz von Apple und Microsoft zwischen 2020 und 2022?" oder "Wie hat sich Microsofts Operating Margin von 2020 bis 2022 verändert?" bewältigen. Warum sind diese halbkomplex? Nun, der Agent muss "überlegen" und diese breiten Fragen in kleinere aufteilen, Informationen aus der Datenbank abrufen und dann alles zusammensetzen.
   • Um zum Beispiel die erste Frage zu beantworten, muss der Agent den individuellen Umsatz der einzelnen Unternehmen für jedes Jahr 2020, 2021 und 2022 kennen und dann den Vergleich anstellen.
5. Aktuell (fast): Das Cut-off-Datum ist August 2024. Alles, was nach diesem Datum bei der SEC eingereicht wurde, ist in dieser MVP-Version nicht enthalten.
6. HTML-Streaming: Streaming funktioniert! Juhu! :D Es stellte sich heraus, dass DRF und React nativ Streaming unterstützen, also haben wir mit Langgraph einen reaktionsschnellen Gesprächsablauf, der in einem leicht lesbaren Format angezeigt wird. Ich habe schon eine Weile mit HTML-Streaming gekämpft.

Ein Blick unter die Haube

Falls du noch liest, möchtest du wahrscheinlich mehr darüber wissen, wie ich diesen MVP gebaut und einige der zuvor erwähnten Herausforderungen überwunden habe. Lass uns also ein bisschen technisch werden!

1. Abgespeckte Daten: Anstatt vollständige 10-K- oder 10-Q-Berichte zu verwenden, nutze ich die "Facts", die bei der SEC eingereicht wurden. Das bedeutet, unsere Datenbank ist deutlich kleiner – weniger als 2 GB! Unten sind einige Beispiele dafür, was öffentliche Unternehmen bei der SEC eingereicht haben:

  "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"

Das bedeutet auch, dass ich keinen großen, schnellen Vector Store benötige, der sehr teuer ist (im Bereich von 600 bis 700 US-Dollar/Monat).

2. Cloud SQL PostgreSQL als Hauptdatenbank: Ich verwende Cloud SQL PostgreSQL als Hauptdatenbank. Da ich bereits Cloud Run CI/CD von GCP verwendete, war es sinnvoll, bei Googles Angeboten zu bleiben. Das ist ein brandneues Konzept für mich, also musste ich lernen, wie man die Datenbankmigrierung von lokal in die Cloud durchführt und dann das Backend so konfiguriert, dass es mit der Cloud SQL-Datenbank über private IP funktioniert. Die Dokumentation von GCP war dabei sehr hilfreich.

3. React trifft Django: Dies ist mein erstes erfolgreiche Mal, dass ich sowohl das React-Frontend als auch das Django Rest Framework (DRF)-Backend mit einer Cloud SQL-Datenbank bereitgestellt habe. Es war eine Reise des Ausprobierens, aber ChatGPTs o1-preview und Anthropic Claude 3.5 Sonnet waren eine riesige Hilfe. Sie sind in der Tat sehr leistungsfähig, besonders wenn man ihnen genug Kontext zu dem Problem gibt, das man lösen möchte.

4. Smarter Agent: Der Agent ist mit Langgraph gebaut. Er verfügt über zwei Haupttools: Google Search und ein Financial Question Answering Tool. Er entscheidet anhand deiner Frage, welches er verwenden soll.

5. Wie werden SQL-Abfragen generiert?

Es ist nicht einfach, eine generische/breite Benutzerfrage in geeignete SQL-Abfragen umzuwandeln, die für die Datenbank geeignet sind. Einer der Hauptgründe dafür ist, dass Unternehmen bei der Einreichung von Finanzkennzahlen an die SEC finanzielle Konzepte/Terminologien verwenden, die für normale Menschen nicht intuitiv sind.

Zum Beispiel kann "Umsatz" durch mehrere Fakten repräsentiert werden wie:

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

Und bei verschiedenen Unternehmen können sie für dasselbe Konzept unterschiedliche Labels wählen. Zum Beispiel verwendet Apple "Revenue from Contract with Customer, Excluding Assessed Tax" während Tesla "Revenue" verwendet.

Oder wenn du nach "Operating Margin" fragst, könnte das keine Tatsache sein, die das Unternehmen bei der SEC einreicht. Stattdessen reichen sie den Gesamtumsatz und das Operating Income (Loss) ein.

Eine weitere Situation ist, wenn Unternehmen ihren Namen im Laufe der Zeit geändert haben, sodass du sicherstellen musst, dass die SQL-Abfragen sowohl den alten Namen als auch den neuen Namen enthalten.

Wie weise ich die Maschine also an, das richtige Fakten-Label für eine bestimmte breite Frage auszuwählen?

Ich verwende Hybrid Search mit Weaviate, um die relevantesten Fakten oder Labels zu finden und diese zurück an das LLM-Modell zu senden.

6. Schrittweises Testen ist entscheidend

Vor der endgültigen Bereitstellung in der Produktion habe ich den Prozess in Schritte aufgeteilt und jeden einzelnen getestet:

1. Lokaler Test des DRF-Backends mit einer lokalen Datenbank.

2. Docker Container Backend-Test mit lokaler Datenbank.

3. Migration der PostgreSQL-Datenbank zu Cloud SQL und Test.

4. Docker Container Backend-Test mit Cloud SQL.

5. React Frontend lokaler Test.

6. React Frontend mit Produktions-Backend und Cloud SQL.

7. Migration des React-Frontends zu Wordpress in der Produktion.

8. End-to-End-Testing.

Diesen schrittweisen Ansatz musste ich auf die harte Tour lernen. Anfangs habe ich einige Schritte übersprungen und in größeren Chunks getestet, aber die Sprachmodelle (LLM) konnten nicht genau feststellen, wo die Dinge schiefgelaufen sind.

Was kommt als Nächstes?

1. Das Cold-Start-Problem beheben: Momentan braucht der Agent etwas Zeit, um die erste Frage zu beantworten. Ich arbeite an einer kostengünstigen Lösung.
2. Zwischenschritte für Nutzer anzeigen: Während der Beantwortung komplexer Fragen wie "Vergleiche den Umsatz von Apple und Microsoft zwischen 2020 und 2022" braucht der Agent Zeit, um die endgültige Antwort zu generieren. Das Anzeigen der Schritte, an denen der Agent in Echtzeit arbeitet, könnte die Benutzererfahrung verbessern.
3. Mit 10-K/10-Q-Textinhalt anreichern: Ich plane, relevantere Textinhalte aus 10-K- und 10-Q-Einreichungen einzubeziehen, um detailliertere Antworten zu geben.

Das war's von mir für jetzt. Probier die MVP-Version aus und lass mich wissen, was du denkst! Hast du schon etwas mit Finanzdaten oder SEC-Einreichungen gebaut? Ich würde gerne von deinen Erfahrungen hören – hinterlasse einen Kommentar unten oder schreib mir direkt (chandler@chandlernguyen.com).

Viele Grüße,

Chandler