Was entstand
Entstanden ist eine Portfolio-Seite mit eingebautem Chat, der Fragen zu Projekten, Skills und Berufserfahrung beantwortet. Die Antworten kommen nicht aus statischen Textbausteinen, sondern aus einer kleinen RAG-Pipeline auf Basis meiner eigenen Profildaten.
Gebaut wurden Backend, Indexierung, Azure-Setup, Deployment und das Chat-Frontend. Kein Template, kein Baukasten, kein kopiertes Starter-Projekt.
Wie dieses Projekt gebaut wurde – das eigentliche USP
Design und Layout der Website waren bereits da. Neu gebaut wurden Backend, KI-Anbindung, Azure-Infrastruktur und Deployment-Strecke. Von der ersten Spezifikation bis zur Live-URL hat das rund 7 Stunden gedauert.
Der entscheidende Punkt war nicht "KI macht den Job", sondern ein sauberer Arbeitsmodus mit GitHub Copilot Agent Mode nach dem Muster Spec → Feature → Build → Review:
1
Spec firstBevor Code entsteht, steht die Aufgabe sauber da: Ziel, Inputs, Outputs, Abhängigkeiten und Grenzen.
2
One feature at a timeEmbedding-Pipeline, Suchindex, Prompting und Deployment wurden nacheinander gebaut, getestet und abgenommen.
3
Der Entwickler als ArchitektDie KI hilft beim Schreiben und Recherchieren. Architektur, Datenmodell und Sicherheitsgrenzen habe ich festgelegt.
4
Fehler als Teil des ProzessesProbleme bei Deployment, Index-Aufbau und Azure-Authentifizierung wurden nicht kaschiert, sondern gelöst.
Tech Stack
| Schicht | Technologie |
| Backend | Python 3.12, FastAPI, Uvicorn |
| KI – Sprache | Azure OpenAI GPT-4o (East US 2) |
| KI – Embeddings | text-embedding-3-large, 3072 Dims |
| Wissensindex | Azure AI Search, Free Tier, 107 Chunks |
| Storage | Azure Blob Storage, 4 Markdown-Dateien |
| Hosting | Azure App Service B1 Linux, Germany West Central |
| CI/CD | GitHub Actions, Service Principal (RBAC) |
| Frontend | Statisches HTML/CSS/JS, kein Framework |
Architektur-Entscheidungen
Warum RAG statt Fine-Tuning? Die Daten ändern sich und sollen direkt korrigierbar bleiben. RAG passt hier besser, weil der Chat bei jeder Anfrage auf den aktuellen Datenbestand zugreift.
Warum statisches Frontend? HTML, CSS und etwas JavaScript reichen für diesen Use Case aus und halten den Fokus auf Backend und Systemintegration.
Warum Azure? OpenAI, Search, Storage und Hosting laufen im selben Stack. Das vereinfacht den Betrieb und spiegelt zugleich typische Unternehmensarchitekturen wider.
Der Prozess in 6 Schritten
1
Spec und DatenstrategieDie sichtbare Profilansicht kommt aus JSON, der Chat greift separat auf geprüfte Markdown-Quellen im Suchindex zu.
2
BackendEmbed → Retrieve → Augment → Generate. Der Prompt begrenzt Rolle und Wissensbasis klar.
3
Frontend und DatenschichtKarriere-Ansicht und Minimal-CV hängen an derselben Datenquelle und laufen nicht auseinander.
4
Azure-InfrastrukturApp Service liefert API und Seiten aus, AI Search hält den Vektorindex, Blob Storage die Quelldateien.
5
WissensindexVier Markdown-Dateien wurden in 107 überlappende Chunks zerlegt und neu in den Index geschrieben.
6
CI/CDDeployments laufen per Service Principal statt Publish Profile, weil Azure Basic Auth standardmäßig deaktiviert.
Stolpersteine
Automatisch generierter Azure-WorkflowKonkurriert beim Merge mit dem eigenen Workflow. Sofort identifizieren und entfernen.
App Settings nicht sofort aktivNeu gesetzte Secrets greifen erst nach explizitem App-Neustart.
Index und Storage sind unabhängigLöschen aus Blob Storage hat keinen Effekt auf den Vektorindex – beide Schichten separat bereinigen.
Sonderzeichen in JSONDeutsche Anführungszeichen in Markdown brechen JSON-Parser. Zeichenkodierung explizit berücksichtigen.
Kostenanalyse
Fixkosten / Monat
~$13.10
730 h × $0.018 App Service B1 · AI Search Free · Storage < $0.01
| Szenario | App Service | OpenAI | Gesamt |
| Demo / Portfolio (~30 Anfragen) | $13.10 | $0.23 | ~$13.33 |
| Bewerbungsphase (~200 Anfragen) | $13.10 | $1.55 | ~$14.65 |
| Starker Traffic (~1.000 Anfragen) | $13.10 | $7.75 | ~$20.85 |