Partizipation im Netz war lange gleichbedeutend mit „User erstellt Content“. In der aktuellen Welle verschiebt sich der Hebel: Partizipation heißt zunehmend, dass Nutzer Datenmodelle, Retrieval-Pfade und Agenten-Workflows definieren, die ihrerseits Content kuratieren, verdichten und ausführen. Wer Plattformen baut, muss daher nicht nur UIs und APIs entwerfen, sondern auch Repräsentationen (Schema, Graph, Embeddings), Steuerung (Policies, Tools, Actions) und Observability über generative Schritte hinweg.
Web 2.0 als Kontrast
Web 2.0 war die Partizipationswende über XML/RSS, Blogs, Tags und Social Bookmarking: Nutzer publizierten und vernetzten Inhalte, Plattformen aggregierten sie. Technisch dominierte ein Dokumenten- und Feed-Denken mit relativ klaren Produzenten/Abonnenten-Grenzen.
Datenstruktur vs. Semantic Web
XML: Was es versprach und was fehlte
XML versprach Trennung von Inhalt und Darstellung (XSLT), valide Strukturen (XSD) und semantische Auszeichnung auf Dokumentebene. In der Praxis blieb Semantik oft implizit: Ein XML-Elementname ist kein global eindeutiger Begriff, und ohne verbreitete Ontologien sowie robuste Extraktion/Verknüpfung blieb Interop meist auf bilaterale Integrationen beschränkt. Dazu kam: XML war „streng“ in der Authoring-Pipeline, aber nicht automatisch „bedeutungsvoll“ im Sinne maschineller Schlussfolgerung über Domains hinweg.
JSON-LD, Schema.org, Knowledge Graphs, Embeddings: Der praktische Durchbruch
Der pragmatische Gewinn kam, als Semantik in Web-Produktionssystemen billig wurde: JSON-LD lässt strukturierte Daten direkt neben dem gerenderten Inhalt ausspielen; Schema.org bietet ein de-facto Vokabular, das Suchmaschinen und viele Tools verstehen; Knowledge Graphs verbinden Entitäten über eindeutige IDs statt über Textgleichheit. Und entscheidend: LLM-Embeddings füllen die Lücke zwischen „strikt modelliert“ und „nur Text“, indem sie Ähnlichkeiten im Vektorraum bereitstellen, wo harte Ontologien fehlen oder zu teuer wären.
Auf Protokoll-/API-Ebene bedeutet das: Statt XML-Dokumente zu „parsen“, werden heute häufig (a) JSON-LD-Snippets extrahiert, (b) Entitäten normalisiert (z.B. via Wikidata/QIDs oder interne IDs), (c) Relationstriple/Properties in einen Graph-Store geschrieben und (d) Textfelder zusätzlich eingebettet, um Retrieval robust zu machen, selbst wenn Schemas unvollständig sind.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Web 2.0 → Web 3.0 → KI",
"author": { "@type": "Person", "name": "Redaktion" },
"datePublished": "2026-06-27",
"about": ["Knowledge Graph", "Embeddings", "Agenten"]
}Ein wichtiger Architekturpunkt: JSON-LD ist nicht „das Semantik-System“, sondern der günstige Einstiegspunkt, um Entitäten, Attribute und Kanten zu materialisieren. Der Rest passiert in Pipelines: Entity Linking, Dedupe, Confidence Scoring, Graph-Merges, und schließlich eine Retrieval-Schicht, die Graph-Abfragen (präzise) mit semantischem Retrieval (robust) kombiniert.
RSS → Recommendation Engines → Agentic Feeds
RSS war ein explizites Pull-Modell: Der Nutzer wählt Quellen, der Reader pollt Feeds, die Reihenfolge ist meist chronologisch. Recommendation Engines (YouTube, TikTok) haben das Modell gedreht: Der Feed ist ein Ranking-Problem, Optimierung erfolgt über implizites Feedback (Watchtime, Dwell, Skip), und Quellen sind nur ein Feature unter vielen. Der nächste Schritt sind agentische Feeds: Ein Agent entscheidet nicht nur, was gerankt wird, sondern auch, welche Quellen überhaupt gepullt, gecrawlt oder über APIs abgefragt werden, inklusive iterativer Nachrecherche.
Agentic RAG, Actions und MCP: Von „Ranking“ zu „Entscheidung“
Technisch ist das eine Verschiebung von „eine Anfrage, eine Antwort“ zu „Planen, Tool-Calls, Zwischenspeicher, Evaluation“. In LangChain ist das typischerweise ein Agent mit Toolset (HTTP, Datenbank, Vektorsuche) plus RAG; in Custom GPT Actions werden Tools über OpenAPI-Schemas angebunden; mit MCP-Servern wird Tooling standardisiert bereitgestellt (z.B. Zugriff auf interne Systeme, Dateien, Tickets, Metriken), sodass der Agent „quellenübergreifend“ arbeiten kann, ohne pro Integration ein neues Prompt-Monolith zu bauen.
Auf API-Ebene ist der Unterschied sichtbar: RSS ist eine einfache GET-URL, Recommendation Engines sind proprietäre APIs und Modelle, agentische Feeds bestehen aus Tool-Aufrufen mit Zustandsverwaltung. Entscheidend ist Governance: Rate Limits, erlaubte Domains, Datenklassifizierung und Audit-Logs pro Tool-Call werden zu First-Class-Anforderungen.
| Feed-Generation | Pull-/Steuerungsmodell | Personalisierung | Typische Formate/APIs | Typische Bausteine |
|---|---|---|---|---|
| RSS-Reader | Nutzer wählt Quellen, periodisches Polling | Gering (Filter, Ordner, Keywords) | RSS/Atom (XML), HTTP GET | Aggregator, Parser, Volltextsuche |
| Recommendation Engine | Plattform kuratiert Ranking | Hoch (implizite Signale) | Proprietäre APIs, Event-Streams | Feature Store, Ranking-Modelle, A/B-Testing |
| Agentic Feed | Agent wählt Quellen + Reihenfolge + Nachrecherche | Hoch + zielorientiert (Tasks, Kontext) | Tool-Calls, OpenAPI Actions, MCP, Vektorsuche | LLM-Gateway, Agent Runner, RAG, Policies, Observability |
Tags → Foundation Models + Vektorsuche
Social Bookmarking und Tagging waren menschliche Metadatenarbeit: flache Taxonomien, inkonsistente Schreibweisen, wenig Kontext (ein Tag sagt nicht, warum etwas relevant ist). Gleichzeitig war es eine frühe Form von „User-labeled Data“: Millionen kleiner Klassifikationsentscheidungen, nur eben ohne Modell dahinter.
Embedding-basierte Klassifikation und hybride Suche
Heute übernehmen Foundation Models große Teile dieser Metadatenarbeit. Inhalte werden eingebettet, automatisch clustert und klassifiziert man nach Ähnlichkeit, ergänzt durch Extraktion (z.B. Entitäten, Themen, Zitate). Praktisch wird das mit einer hybriden Suche kombiniert: Keyword (BM25/Term) für Präzision auf exakten Tokens, plus Vektorsuche für Synonyme, Paraphrasen und „gleiche Bedeutung, andere Worte“. Viele Systeme fahren beides parallel und mergen Ergebnisse mit einem Score-Fusion-Ansatz.
Typische Bausteine sind Vektor-Datenbanken wie pgvector/Postgres, Qdrant, Weaviate oder Pinecone, dazu ein Embedding-Service (lokal oder API), und ein Retrieval-Layer, der Filter (ACLs, Mandanten, Zeitfenster) exakt ausführt und danach semantisch rankt. „Personalisierung“ wird dabei oft nicht mehr nur als Profil verstanden, sondern als kontextabhängiger Filter: lokale Modelle auf dem Client oder Edge (für Datenschutz und Latenz) können Preferences als Vektor oder Regeln beisteuern, ohne dass Rohdaten zentral gespeichert werden müssen.
// Pseudocode: hybride Suche (Keyword + Vektor) mit Filter
query = "Incident Postmortem Kafka Consumer Lag"
filters = { tenantId: "acme", access: "team-sre", timeRange: "90d" }
kw = bm25.search(query, filters, topK=50)
vec = vector.search(embed(query), filters, topK=50)
results = fuse_rrf(kw, vec)
return rerank_with_llm(results, query)Partizipation 2.0 → Partizipation 3.0
Partizipation 2.0 war primär Publikation und Diskussion: Blogposts, Kommentare, Likes, Tags. Partizipation 3.0 ist operative Einflussnahme auf Modelle und Automationen: Nutzer geben strukturiertes Feedback (Daumen, Korrekturen, Präferenzen), kuratieren Datensätze, definieren Prompt- und Tool-Policies, bauen Custom GPTs oder eigene Agenten, die ihre Arbeitsschritte reproduzierbar machen.
Technisch relevant ist, dass Feedback nicht mehr nur „UI-Event“ ist, sondern Trainings- und Steuerdaten. RLHF ist das bekannte Dach, aber in produktiven Systemen sieht man häufiger eine Kombination aus (a) Online-Feedback für Ranking/Antwortauswahl, (b) Offline-Kuration für Evaluationssets, (c) Guardrails/Policies als Konfigurationsartefakte. Die „soziale Software“ steckt deshalb zunehmend in Workflow- und Agenten-Tooling: LangChain/LangGraph für Agent-States, n8n oder Make für Integrationsflüsse, ComfyUI für reproduzierbare Medienpipelines, plus Evaluationsframeworks (z.B. Ragas, OpenAI Evals-Patterns, eigene Golden Sets).
Eine nützliche Denkweise: Kommentare waren Nebenprodukte von Content. Feedbackdaten sind heute Primärartefakte, weil sie Retrieval, Reranking, Tool-Auswahl und Antwortstil messbar verändern. Das zwingt Plattformen, Versionierung (Prompts/Tools/Modelle), Auswertbarkeit (Tracing) und Datenzugriff (Consent, Löschbarkeit) wie „echte Software“ zu behandeln.
Technische Architektur heute (Plattform 2026)
Referenz-Stack: Komponenten statt Monolith
Ein realistischer Stack für eine partizipative Plattform 2026 ist modular und policy-getrieben. Kern ist ein LLM-Gateway (für Model-Routing, Caching, Rate Limits, PII-Filter), daneben eine Retrieval-Schicht (Vektor + Keyword + Graph), und ein Event-/Feed-Layer für Echtzeit. Die Datenebene ist zweigeteilt: (1) kuratierte, strukturierte Stores (Postgres, Graph-DB, Objekt-Storage) und (2) Embedding-Indizes für semantisches Retrieval. „Partizipation“ landet als Konfiguration und Daten: Feedback-Events, Regeln, Tool-Rechte, eigene Agent-Workflows.
Datenfluss: Ingestion → Embeddings → Retrieval → Agentenlauf
Ingestion ist nicht mehr nur ETL, sondern „semantisches ETL“: Quellen (Docs, Tickets, Chats, Repos) werden normalisiert, chunked, mit Metadaten versehen (ACL, Tenant, Typ, Zeit), eingebettet, und optional in einen Knowledge Graph überführt (Entitäten/Kanten). Relevante Patterns: inkrementelle Updates via Change Data Capture, Backfills bei Modellwechseln (neue Embeddings), und getrennte Indizes pro Sicherheitsdomäne, damit ACL-Filter nicht nur „nachträglich“ passieren.
Retrieval erfolgt häufig in drei Stufen: Filter (hart, z.B. ACL/Zeitraum), Kandidaten (hybrid: BM25 + Vektor), Reranking (Cross-Encoder oder LLM). Agenten kommen dann ins Spiel, wenn die Anfrage nicht „eine Antwort“ ist, sondern ein Task: z.B. „erstelle Release Notes“, „finde Regression, öffne Ticket, informiere Team“. Hier sind Zustandsmaschinen (LangGraph) oft besser als freie Agenten, weil sie deterministischer und auditierbarer sind.
Lokale Inference vs. Cloud-API: Betriebsentscheidungen
Die praktische Frage ist weniger „Cloud oder on-prem“, sondern „welche Schritte müssen lokal sein“: Embeddings können oft lokal laufen (Kosten, Datenschutz, deterministische Re-Indexierung), während große Generationsmodelle je nach SLA über Cloud-APIs laufen. Ein verbreitetes Modell ist Hybridbetrieb: lokales kleines Modell für Klassifikation, PII-Redaktion, einfache Reranks; Cloud-Modelle für komplexe Synthese; und eine einheitliche Gateway-Schicht, die Logging/Tracing und Policies erzwingt.
Was sich gegenüber Web-2.0-Architekturen deutlich ändert, ist Observability: Nicht nur Requests und SQL-Queries zählen, sondern Prompt-Versionen, Tool-Calls, Retrieval-Kandidaten, Token-Kosten, sowie „Antwortqualität“ gegen Golden Sets. Ohne diese Telemetrie bleibt Partizipation 3.0 ein Bauchgefühl-System, das niemand verlässlich steuern kann.
Fazit
Die Evolutionslinie Web 2.0 → Web 3.0 → KI ist weniger ein Medienwechsel als ein Wechsel der Kontrollpunkte: von Dokumenten und Feeds zu Repräsentationen (JSON-LD/Graph/Embeddings) und schließlich zu agentischen Steuerflüssen (Tools, Actions, MCP) mit messbarer Governance. Wer 2026 „Partizipation“ baut, baut Feedback- und Policy-Systeme, Retrieval-Architektur und reproduzierbare Agenten-Workflows — nicht nur Kommentarspalten und Upload-Formulare.