🎓 Academia Edition Artikel 3 von 7

Alle Ausgaben · Academia Edition

A walking path curving into the distanceYour Community, Your AI — CC BY 4.0

Plattform-KI vs. gemeinschaftlich gesteuerte KI – Eine strukturelle Analyse

Das Korpusproblem

Die Governance-Eigenschaften eines KI-Systems werden maßgeblich durch sein Trainingskorpus bestimmt. Dies ist kein nebensächliches Anliegen – es handelt sich um eine architektonische Eigenschaft erster Ordnung. (Begriffe wie Korpus, Fine-Tuning und Agent sind im Glossar definiert.)

Kommerzielle LLMs großer Plattformanbieter werden auf Korpora im Web-Maßstab trainiert: Milliarden von Dokumenten, die aus dem offenen Internet gesammelt wurden, ergänzt durch lizenzierte Datensätze und proprietäre Sammlungen. Die daraus resultierenden Systeme verfügen über ein breites Leistungsspektrum und entsprechend weit gefasste Annahmen hinsichtlich der Verteilung.

Das Internet als Trainingskorpus repräsentiert bestimmte Bereiche und Perspektiven überproportional stark:

Dementsprechend sind unterrepräsentiert:

Dieses Ungleichgewicht in der Verteilung lässt sich nicht durch eine Vergrößerung des Umfangs beheben. Ein größeres Web-Korpus verstärkt dieselben Verzerrungen. Es handelt sich um eine strukturelle Eigenschaft der Datenquelle, nicht um einen Stichprobenfehler.

Fachspezifische KI: Die Alternative und ihre Grenzen

Die „Village“-Plattform verfolgt einen anderen architektonischen Ansatz: ein kleineres Modell, das auf einem mehrschichtigen Korpus trainiert wurde, bei dem domänenspezifische Inhalte Vorrang vor der Breite haben.

Die Trainingsarchitektur besteht aus drei Schichten:

Plattformschicht. Gemeinsames betriebliches Wissen, das allen Instanzen gemeinsam ist – wie die Plattform funktioniert, welche Funktionen verfügbar sind, Navigationshilfe. Diese Ebene entspricht einer gemeinsamen Ontologie über alle Instanzen hinweg.

Community-Ebene. Inhalte, die für eine bestimmte Bereitstellung spezifisch sind – die Datensätze, Kommunikationen und Dokumente, die von der Community erstellt werden, die die Instanz betreibt. Diese Ebene unterscheidet eine Bereitstellung von einer anderen und verankert die Modellausgaben im lokalen Kontext.

Einwilligungsschicht. Eine strukturelle Einschränkung: Es gelangen keine Inhalte in den Trainingskorpus ohne die ausdrückliche, nachprüfbare Einwilligung des Urhebers. Dies wird architektonisch durchgesetzt, nicht durch Richtlinien.

Das daraus resultierende System ist enger gefasst als ein kommerzielles LLM. Es kann Themen außerhalb seines Trainingsbereichs nicht kompetent diskutieren. Es wird keine universell einsetzbaren kreativen Texte verfassen oder sich an weitreichenden Gesprächen beteiligen. Stattdessen bietet es Ergebnisse, die auf den Aufzeichnungen einer bestimmten Community basieren und anhand dieser Aufzeichnungen überprüfbar sind.

Einschränkungen dieses Ansatzes

Es sollten mehrere Einschränkungen berücksichtigt werden:

Eingeschränkte Allgemeingültigkeit. Ein domänenspezifisches Modell kann bei Aufgaben außerhalb seines Trainingsbereichs keine Unterstützung leisten. Community-Mitglieder, die allgemeine KI-Unterstützung benötigen, müssen ein separates System nutzen.

Einschränkungen hinsichtlich der Korpusgröße. Kleine Gemeinschaften produzieren nur begrenzte Inhalte. Ein Modell, das auf wenigen hundert Dokumenten trainiert wurde, verfügt über eine entsprechend schmale Wissensbasis. Die Qualität der Ergebnisse wird direkt durch den Umfang und die Qualität der Inhalte der Gemeinschaft begrenzt.

Verzögerung beim Nachtrainieren. Die Gemeinschaftsebene erfordert regelmäßiges Nachtrainieren, um neue Inhalte zu integrieren. Zwischen den Umschulungszyklen ist das Wissen des Modells veraltet. Die derzeitige Umschulungsfrequenz (wöchentlich, nach festem Zeitplan) kann für sich schnell verändernde Kontexte unzureichend sein.

Anfälligkeit des Fine-Tunings. Domänenspezifisches Fine-Tuning überlagert die bestehende Verteilung eines Basismodells mit neuen Mustern. Unter bestimmten Abfragebedingungen – insbesondere bei neuartigen oder komplexen Fragen – können sich die Muster des Basismodells wieder durchsetzen, ein Phänomen, das in der Fachliteratur als „katastrophales Vergessen“ bekannt ist. Inwieweit dies in der Praxis governance-relevante Ergebnisse beeinträchtigt, ist für dieses System noch nicht genau charakterisiert.

Guardian Agents: Architektur zur externen Verifizierung

Die Village-Plattform stützt sich nicht ausschließlich auf das Training, um die Qualität der Ergebnisse zu gewährleisten. Sie schaltet eine Verifizierungsschicht – bezeichnet als „Guardian Agents“ – zwischen den Modellausgaben und dem Endnutzer ein.

Die Guardian Agent-Architektur umfasst vier unabhängige Verifizierungsmechanismen:

Verifizierung der semantischen Verankerung. Die Ausgabe des Modells wird anhand von auf Embeddings basierenden Ähnlichkeitsmaßen mit dem Dokumentenkorpus der Community verglichen. Ausgaben, denen eine ausreichende Verankerung in tatsächlichen Datensätzen fehlt, werden markiert oder unterdrückt.

Zerlegung auf Behauptungsebene. Die Ausgabe wird in einzelne Behauptungen zerlegt, die jeweils unabhängig voneinander verifiziert werden. Dies behebt den häufigen Fehlerfall, bei dem eine Antwort eine Mischung aus fundierten und unbegründeten Aussagen enthält.

Überwachung von Verhaltensabweichungen. Eine Ebene zur Langzeitüberwachung verfolgt Muster in den Modellausgaben im Zeitverlauf und erkennt systematische Verschiebungen in Tonfall, Darstellung oder Genauigkeit, die auf eine Abweichung vom Verteilungsmuster oder eine Verschlechterung hindeuten könnten.

Integration adaptiven Feedbacks. Das Feedback der Community-Mitglieder (sowohl explizite Bewertungen als auch Korrekturen durch Moderatoren) wird in die Verifizierungsschwellenwerte einbezogen. Dadurch entsteht eine Rückkopplungsschleife, in der sich das Verifizierungssystem im Laufe der Zeit immer besser an die Erwartungen der Community anpasst.

Gegenargumente und Fehlerquellen

Die Guardian Agent-Architektur ist ein Forschungsbeitrag, kein gelöstes Problem. Mehrere Gegenargumente und Fehlerquellen verdienen eine eingehende Betrachtung:

Semantische Ähnlichkeit ist nicht gleichbedeutend mit Wahrheit. Die auf Einbettungen basierende Verifizierung misst semantische Nähe, nicht die sachliche Richtigkeit. Eine Aussage, die einem Quelldokument semantisch nahekommt, kann dennoch sachlich falsch sein – Paraphrasen können die Bedeutung umkehren, während die Embedding-Ähnlichkeit erhalten bleibt. Die Zerlegungsschicht auf Behauptungsebene behebt dieses Problem teilweise, doch es bleiben weiterhin falsch-positive und falsch-negative Ergebnisse.

Die Verifizierungsabdeckung ist unvollständig. Die „Guardians“ können Aussagen anhand vorhandener Datensätze überprüfen. Sie können jedoch keine Aussagen zu Themen verifizieren, die nicht durch die Datensätze der Community abgedeckt sind. Bei neuartigen Fragen steht das System vor der Wahl, entweder die Beantwortung zu verweigern (konservativ, aber wenig hilfreich) oder nicht verifizierbare Ergebnisse zu generieren (hilfreich, aber ungesichert). Die aktuelle Implementierung kennzeichnet Antworten mit geringer Konfidenz, anstatt sie zu unterdrücken, wodurch die Last der Verifizierung auf den Endnutzer verlagert wird.

Rückkopplungsschleifen können zu Verzerrungen führen. Der adaptive Rückkopplungsmechanismus geht davon aus, dass das Feedback der Community ein zuverlässiges Signal ist. In der Praxis kann das Feedback jedoch spärlich sein, zugunsten bestimmter Nutzergruppen verzerrt sein oder Präferenzen widerspiegeln, die im Widerspruch zur Genauigkeit stehen. Das System unterscheidet derzeit nicht zwischen Feedback, das sachliche Fehler korrigiert, und Feedback, das ästhetische oder ideologische Präferenzen widerspiegelt.

Rechenaufwand. Die vierstufige Verifizierung verursacht zusätzliche Latenz und Rechenaufwand. Bei zeitkritischen Abfragen kann dieser Aufwand die Benutzererfahrung so stark beeinträchtigen, dass das System nicht mehr genutzt wird – ein Governance-Versagen durch Nichtakzeptanz statt durch technische Fehler.

Delegation und der Kontrollort

Die vorangegangene Analyse betrifft das Korpus – dessen Muster das System trägt. Die agentische Wende (Artikel 1) führt eine zweite, orthogonale Achse ein: den Kontrollort, sobald das System handelt, anstatt lediglich zu beraten. Die Delegation einer Aufgabe an einen kommerziellen Akteur überträgt nicht nur Daten, sondern auch operative Befugnisse – die Fähigkeit, Maßnahmen (Transaktionen, Kommunikation, Datensatzänderungen) an einer Infrastruktur durchzuführen, die der Einsatzgeber nicht kontrolliert, wobei die Interventionspunkte vom Anbieter festgelegt werden. Aktuelle Kommentare charakterisieren dies als ein Problem der Rechenschaftspflicht und des Datenschutzes, das unter dem Deckmantel einer Frage nach den KI-Fähigkeiten auftritt. Die von der Community gesteuerte Alternative beseitigt die Delegation nicht; sie schränkt sie ein. Handlungen sind auf die eigenen Grenzen der Community beschränkt, auf reversible Vorgänge begrenzt und durch den Mechanismus zur Durchsetzung der Grenzen (Artikel 3) so geregelt, dass folgenschwere oder irreversible Handlungen einer menschlichen Autorisierung bedürfen. Der architektonische Anspruch besteht nicht darin, dass der Agent leistungsfähiger ist, sondern dass der Ort der Kontrolle überprüfbar und wiederherstellbar bleibt – eine Eigenschaft, die orthogonal zur reinen Leistungsfähigkeit ist und in dieser Analyse Vorrang vor ihr hat.

Der Kompromiss: Ein analytischer Rahmen

Die Wahl zwischen kommerzieller KI und gemeinschaftlich gesteuerter KI ist keine Wahl zwischen einer guten und einer schlechten Option. Es ist eine Wahl zwischen verschiedenen Kompromissprofilen:

Dimension Kommerzielle Plattform-KI Gemeinschaftlich gesteuerte KI
Funktionsumfang Hoch Gering (domänenspezifisch)
Verteilungsverzerrung Spiegelt den Korpus im Web-Maßstab wider Spiegelt den Korpus der Community wider
Überprüfbarkeit Gering (proprietär, undurchsichtig) Höher (Open Source, überprüfbar)
Datenhoheit Daten fließen zum Anbieter Daten verbleiben innerhalb der Community-Grenzen
Verifizierungsarchitektur Vom Anbieter kontrolliert Von der Community überprüfbar
Rechenressourcen Erheblich (Cloud-Maßstab) Begrenzt (lokal oder kleine Cloud)
Verallgemeinerbarkeit Hoch Gering (konstruktionsbedingt)
Handlungsbefugnis (agentlich) Durch den Anbieter vermittelt, wenige Eingriffspunkte Auf die Community beschränkt, durch Menschen gesteuert

Keines der beiden Profile ist kategorisch überlegen. Die geeignete Wahl hängt von den Governance-Prioritäten der implementierenden Community ab – ein Punkt, der selbst eine Governance-Entscheidung darstellt.

Replizierbarkeit und Verallgemeinerbarkeit

Eine Frage von besonderem Interesse für die Forschungsgemeinschaft ist, ob die Village-Architektur über ihren aktuellen Einsatzkontext hinaus replizierbar und verallgemeinerbar ist.

Die Plattform ist für den Multi-Tenant-Betrieb über verschiedene Gemeinschaftstypen hinweg ausgelegt (die aktuelle Implementierung unterstützt neun Produkttypen, von Kirchengemeinden über Naturschutzgruppen bis hin zu Alumni-Vereinigungen). Das Vokabularsystem passt die Terminologie an den Kontext der Community an, was auf ein gewisses Maß an Verallgemeinerbarkeit auf der Plattformebene hindeutet.

Allerdings schränken mehrere Faktoren fundierte Aussagen zur Verallgemeinerbarkeit ein:

Dies sind offene Forschungsfragen, keine endgültigen Entwurfsentscheidungen.


Die vollständige Guardian Agents-Architektur finden Sie unter Village AI on Agentic Governance. Die hier aufgeworfenen Fragen zur Delegation und zum Kontrollzentrum werden im Begleitkurs Agents at Work aus der Sicht der Praxis behandelt; Working with Claude befasst sich mit der Bewertung von Modellausgaben.

Fandest du diesen Artikel hilfreich? Dann teile ihn oder zeige den QR-Code zum Scannen.