Skip to content
··5 Min. Lesezeit

Drei Monate später: Immer noch am Coden, immer noch am Lernen, manchmal immer noch feststeckend

Nach 10 Monaten Coden mit KI-Assistenten habe ich gelernt, dass sie wie Praktikanten sind – mächtig, aber auf spezifische Anweisungen angewiesen, was bedeutet, dass ich Frameworks tiefgehend verstehen muss, um echte Probleme zu lösen, wie meinen langsamen Chatbot schnell zu machen.

Update (2026): Das S&P 500 Financial Chatbot-Projekt wurde schließlich eingestellt. Sydney ist zurück und konzentriert sich jetzt auf Blog-Inhalte und Produkte. Sydney ausprobieren →


Ich habe mich gefragt, ob ich dieses Update zu meiner Coding-Reise überhaupt schreiben soll. Die Fortschritte waren nicht aufsehenerregend oder nach außen hin sichtbar – warum also die Mühe?

Nun, vielleicht dient dieser Beitrag als gute Erinnerung für mein zukünftiges Ich, dass Fortschritt manchmal langsamer werden kann und Wachstum oft in Schüben erfolgt.

Seit meinem letzten Beitrag über den Aufbau eines selbst-evaluierenden Chatbots Mitte April habe ich einige Kurse belegt:

Warum diese Kurse?

Ich möchte meine persönlichen Erfahrungen und Gedanken bei der Wahl dieser Kurse teilen. Meine Hoffnung ist, dass es denjenigen von euch helfen kann, die sich auf einer ähnlichen Reise befinden (oder bald sein werden).

Besser werden im Anleiten der Maschine

Es ist jetzt etwa 10 Monate her, seit ich neben meinem Vollzeitjob mit dem Coden angefangen habe. (Ihr könnt mehr darüber lesen, wie ich Meinen eigenen Chatbot ohne Coding-Erfahrung gebaut habe: Gelernte Lektionen, veröffentlicht im Oktober 2023.)

Ich hätte es definitiv NICHT ohne die Hilfe von Generative AI geschafft (ob ChatGPT, Anthropic Claude oder Microsoft CoPilot in Visual Studio Code). Je mehr ich code, desto mehr erkenne ich jedoch, dass diese Grundlagenmodelle zwar leistungsfähig sind, aber immer noch wie Praktikanten sind. Sie sind noch nicht gut darin, zu planen oder mehrdeutige Aufgaben zu lösen. Je spezifischer unsere Anweisungen, desto besser das Ergebnis.

Das bedeutet, dass ich zunehmend spezifischer mit meinen Coding-Anweisungen werden muss. Aber wie? Bisher habe ich beschrieben, was ich in natürlicher Sprache möchte. Obwohl das auf einem grundlegenden Niveau funktioniert, ist es für komplexere Aufgaben unzureichend.

Dann stellt sich die nächste logische Frage: Was soll man lernen?

Fokus auf die Business/User-Probleme, die ich lösen möchte

Mein Chatbot (Codename Sydney) für diese Website war (vielleicht ist er es noch) langsam. Die Langsamkeit tritt sowohl bei auf:

  • der Startzeit
  • als auch während des Gesprächs

Streaming ist nicht aktiviert, sodass Nutzer relativ lange warten müssen, um die vollständige Antwort zu sehen.

Mein Ziel war (ist) also einfach: es schnell und reaktionsschnell machen.

Mein Ziel ist einfach: es schnell und reaktionsschnell machen. Aber ohne mehr Grundlagenwissen ist es schwierig, das in handhabbare Probleme aufzuteilen. Deshalb habe ich mich entschieden, mehr über skalierbare, sichere und schnelle Frontend-Frameworks, Backend-Frameworks und den Full Stack (einschließlich Datenbanken) zu lernen.

Meine Erfahrungen mit React und Django bisher

  • React: React ist im Vergleich zu Django relativ einfacher zu lernen und einzusetzen. (Klar!) Das aktuelle Chatbot-Frontend verwendet React, und ich habe festgestellt, dass Claude und ChatGPT die meisten Coding-Aufgaben problemlos bewältigen können. Auch die Bereitstellung in einer Produktionsumgebung mit React war recht einfach, und die Chatbot-Seite scheint während der Gespräche reaktionsschneller zu sein.
  • Django: Django und das Django Rest Framework (DRF) hatten eine steilere Lernkurve, insbesondere bei der Bereitstellung mit einer Cloud SQL-Datenbank und der Gewährleistung der Sicherheit. Djangos umfassende Natur bedeutet, dass die Bereitstellung mit dem richtigen Sicherheitsniveau einige Zeit in Anspruch nahm. Ich KANN jedoch immer noch KEIN HTML-Streaming in einer Produktionsumgebung mit DRF zum Laufen bringen! Obwohl ich es mit WebSockets zum Laufen bringen könnte, weicht dieser Ansatz erheblich von DRF ab, sodass ich ihn noch nicht übernommen habe.

Falls du also ein Framework oder eine Antwort kennst, wie Langgraph-Streaming mit einem einfachen Frontend funktioniert – lass es mich wissen!

Was ist mit dem Financial Chatbot, den ich im April erwähnt habe?

Die gute Nachricht ist, dass dieses Projekt das Interesse vieler von euch geweckt hat – ich habe zahlreiche Fragen und Kommentare erhalten. Die schlechte Nachricht? Ich bin noch lange nicht fertig T.T Hier ist warum:

1. Ausgewogenes Verhältnis zwischen Abrufqualität, monatlichen Vector Store-Kosten und Embedding-Kosten

Wie im April-Beitrag erwähnt, bewerte ich Weaviates Serverless Cloud Vector Store. Er kostet jedoch echtes Geld. Für dieses Projekt rechne ich wahrscheinlich mit:

  • Datenvolumen: Mehr als 10 Millionen, möglicherweise 12,5 - 15 Millionen Datenobjekte.
  • Kostenschätzung: Bei einer Vektordimension von 512 könnten die monatlichen Kosten zwischen 600 und 750 US-Dollar liegen.

Dieser Betrag ist für ein Unternehmen in einer Produktionsumgebung handhabbar, könnte aber für ein Nebenprojekt wie dieses zu hoch sein. Ich muss also Wege finden, die Kosten zu senken.

Basierend darauf, wie die Weaviate-Preisgestaltung funktioniert, gibt es zwei Hebel: die Anzahl der Datenobjekte reduzieren oder die Vektordimension reduzieren. Beide kommen mit unterschiedlichen Kompromissen.

Möglichkeiten zur Reduzierung von Datenobjekten

  • Aggressives Text Cleaning: Die Reduzierung der Gesamtgröße des Textes in den 10K- und 10Q-Einreichungen könnte helfen, wenn man bedenkt, dass wir es mit 500 Unternehmen im S&P 500 zu tun haben, jedes mit mehreren Einreichungen über die letzten 10 Jahre. Ich denke, ich habe diese Option ausgeschöpft.
  • Erhöhung der Chunk-Größe: Durch die Erhöhung der Chunk-Größe von 256 auf 512, 1.000, 2.000 oder 3.000 kann ich die Anzahl der Datenobjekte um das 2-, 4- oder 10-fache reduzieren. Dies kann jedoch die Abrufqualität verringern, da größere Chunks tendenziell weniger präzise sind.

Möglichkeiten zur Reduzierung der Vektordimension

Die Reduzierung der Vektordimension scheint direkt mit der Abrufqualität korreliert zu sein – je niedriger die Dimension, desto schlechter die Abrufqualität. Ich experimentiere noch mit verschiedenen Embedding-Modellen wie OpenAIs "text-embedding-3-small" und "text-embedding-3-large" mit verschiedenen Dimensionen. Falls du gute Empfehlungen hast, teile sie bitte!

Die Verwendung des "text-embedding-3-large"-Modells von OpenAI erhöht auch die Kosten während der Embedding-Phase. Zum Beispiel hat es mich 4,5 US-Dollar gekostet, Embeddings für die 10K/10Q-Einreichungen von 23 Unternehmen über die letzten 10 Jahre mit einer Vektordimension von 1024 zu generieren. Das bedeutet, es könnte über 100 US-Dollar für den gesamten S&P 500 kosten. (Ja, ich bin ein bisschen ein Pfennigfuchser. Wusstest du das nicht? :P)

2. Latenz bei Query Translation, Structuring und Retrieval

Je ausgefeilter die Query Translation und das Structuring, desto bessere Suchbegriffe / Content Search Terms können wir generieren, was zu einem Retrieval höherer Qualität führt. Dies erhöht jedoch auch die Latenz.

  • Query Translation ist der Schritt, bei dem wir das Modell bitten, die anfängliche Benutzerfrage in Teilfragen zu übersetzen, die besser für das Retrieval geeignet sind. Zum Beispiel kann das Modell mit der ursprünglichen Frage "Wie hat sich Airbnbs Operating Margin von 2020 bis 2022 verändert?" Teilfragen generieren wie:
[
"What was Airbnb's operating margin in the 10-K filing for the year 2020?",
"What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"What was Airbnb's operating margin in the 10-K filing for the year 2022?"
]
  • Query Structuring ist der Schritt, bei dem wir das Modell bitten, diese Fragen in eine Search Query oder Content Search Query für das Retrieval umzuwandeln, zusammen mit relevanten Filtern. Für Frage 1 könnte das Modell Folgendes zurückgeben:
\{
    "content_search": "What was Airbnb's operating margin in the 10-K filing for the year 2021?",
    "company_conformed_name": "Airbnb, Inc.",
    "form_type": "10-K",
    "conformed_period_of_report": "2021-12-31"
\}

Beim Retrieval gilt: Je mehr Ergebnisse wir zurückgeben, desto länger dauert es für das Modell, sie zu verarbeiten. Weniger Ergebnisse zurückzugeben bedeutet schnellere Antwortzeiten, aber möglicherweise eine niedrigere Antwortqualität aufgrund fehlenden Kontexts.

Zusammenfassung

Es gibt mehr, womit ich mich beschäftige, aber da dieser Beitrag bereits länger als erwartet ist, höre ich hier auf.

Lernst du auch neben dem Vollzeitjob coden? Wie entscheidest du, was du als Nächstes lernst, wenn alles gleich wichtig erscheint?

Viele Grüße,

Chandler

Weiterlesen

Mein Weg
Vernetzen
Sprache
Einstellungen