Ein Web-zu-MCP-Wissensmotor: Quellenregister, doppelte Reviewer und Datenschutzmechanismen
Wie ein Quellenregister, eine Persistenzspeicherung, ein Redaktionsteam mit zwei Reviewern sowie ein nur zum Lesen zugänglicher MCP-Server tägliche Webänderungen in eine zuverlässige, datenschutzkonforme Wissensbasis verwandeln.
Quellen: Building an Authoritative Web-to-MCP Knowledge Engine
Forscher, die sich mit der Literatur beschäftigen, Patienten, die neue Studien mit ihren eigenen Unterlagen abgleichen, sowie Koordinatoren für Behindertenunterstützung oder Betreuer, die sich mit rasch ändernden Richtlinien auseinandersetzen, haben eine gemeinsame tägliche Aufgabe. Sie müssen herausfinden, was sich geändert hat, wann und wer das gesagt hat – und sie möchten nicht jeden Morgen im Internet suchen müssen, um dies herauszufinden. Die gängigen Tools reichen dabei nicht aus. Schlüsselwortalarme behandeln einen Blog eines Anbieters genauso wie eine offizielle gesetzliche Änderung, speichern nichts außer dem Inhalt des Posteingangs und können keine privaten Unterlagen einsehen. Chatbots mit Suchfunktion fassen zusammen, was an diesem Morgen am meisten angezeigt wurde, stützen sich auf die veraltete Hierarchie in ihren Trainingsdaten, vergessen Dokumente vom Vortag und verwechseln oder erfinden manchmal Daten und Fakten.
Eine Lösung ist ein System, das die Praktiker als Horizontscan bezeichnen. Es funktioniert als aus dem Internet zusammengestellte Wissensdatenbank, als täglicher Überblick sowie als abfragbarer Server, der das Model Context Protocol (MCP) verwendet. Es sammelt ausschließlich Daten aus zuverlässigen, von Menschen überprüften Quellen, achtet auf Abonnements und Lizenzen und führt einen Speicher, der mit jedem geplanten Ablauf erweitert wird. Wenn es für einen bestimmten Tag nur wenige Belege gibt, kann ein Nutzer entscheiden, nichts zu veröffentlichen, und lediglich ein Protokoll hinterlassen, das den Grund erläutert. Der Speicher überdauert jede einzelne Ausgabe und kann zu jedem Zeitpunkt ausgewählter Perspektiven unter Berücksichtigung der eigenen Daten abgefragt werden – stets hinter einer redigierten lokalen Datenschutzgrenze. Der Kontext des Nutzers wird in die Diskussion einbezogen, gelangt aber niemals in den Speicher. Da persönliche, klinische sowie fallbezogene Details dort nie eingetragen werden, entspricht diese Struktur dem Australian Privacy Act 1988 (Cth), während der öffentliche Speicher weiterhin von allen im Bereich geteilt werden kann.
Die erste Implementierung überwacht Regeln und Preise für Australiens National Disability Insurance Scheme (NDIS), wobei falsche Startdaten oder Preisobergrenzen den Betroffenen schaden können. Ein Scheduler triggert um 06:00 Uhr Sydney-Zeit. Die Redaktion veröffentlicht entweder den Bericht oder hält ihn zurück und notiert jedes Mal einen ausdrücklichen Grund in einem Laufprotokoll, während der Datenspeicher weiterhin wächst. Der Bericht landet in einem Slack-Kanal, wo die Nutzer über das vorhandene Wissensmanagement durch das Taggen von Claude auf die Daten zugreifen können, wodurch der MCP-Server aufgerufen wird. Ein Bericht aus einer Woche zeigte beispielsweise an, dass Teilnehmerdaten möglicherweise auf Palantirs Analyseplattform gelangt sind, zusammen mit einem Urteil der Fair Work Commission bezüglich einer Kündigung wegen Verstößen gegen den NDIS-Verhaltenskodex.
Die Daten und Links in jeder Ausgabe stammen aus gespeicherten Fakten, und jede Zitierung muss mit einem im System gespeicherten Abschnitt übereinstimmen. Dieses Register basiert auf dem NDIS, doch durch das Austauschen der Zeilen kann dieselbe Struktur auch einem Forschungsbereich, einer Gesundheitsstörung oder einer Regulierungsbehörde folgen.
Sammlung, gesteuert durch ein Quellenregister
Die Sammlung wird durch ein Quellenregister sowie eine Konfigurations-Tabelle der überwachten Endpunkte gesteuert – und nicht durch das, was eine Suchmaschine am höchsten rankt. Jede Zeile beschreibt eine Quelle nach einem festen Schema: Name des Verlags, Zugriffsmethode, Abfragedauer, Autoritätsstufe, Einschränkungen bei der Wiederverwendung, Lizenzbedingungen sowie Regeln zur Extraktion von Daten.
Es existieren vier Autoritätsstufen:
- T1 umfasst die primären Register eines Bereichs, wie Gesetze, offizielle Urteilsfeeds oder Zitierindexe.
- T2 umfasst offizielle Regierungsbehörden und Aufsichtsorgane.
- T3 umfasst Spitzenorganisationen und Berufsverbände.
- T4 umfasst zuverlässige Medien und Kommentare.
Jede Zeile enthält außerdem eine von drei Wiederverwendungsbeschränkungen, damit die Bedingungen des Verlags eingehalten werden:
- REUSE_OK bedeutet, dass der vollständige Text gespeichert werden kann, da eine offene Lizenz dies erlaubt.
- LINK_SUMMARISE_ONLY bedeutet, dass nur ein Hyperlink und ein kurzer Auszug beibehalten werden.
- NO_BULK entfernt den Endpunkt aus der automatisierten Abrufung und sendet ihn zur manuellen Überprüfung.
Zusätzlich werden in den Zeilen Informationen über den Host aufgezeichnet, wie beispielsweise Verzögerungen bei der Crawling-Ausführung oder Beschränkungen für Hub-Seiten, wie zum Beispiel weniger als drei datierte Artikel. Ohne diese Notizen handelt es sich bei einer Zeile um einen statischen Bookmark, den ein Sammler nicht sicher ausführen kann.
Die gleiche Registerstruktur wird auch auf andere Felder übertragen:
- Zur wissenschaftlichen Forschung verweisen die T1-Reihen auf Zitierindexe wie MEDLINE, Crossref und OpenAlex in Kombination mit Repositorien für Volltexte im Offenzugang sowie Zeitschriften-Feeds, die nur Abstracts oder Links bereitstellen.
- Zur Verwaltung der persönlichen Gesundheit verweisen die Reihen auf offizielle Leitlinien für eine bestimmte Erkrankung sowie auf Produktinformationen von Medikamenten der zuständigen Aufsichtsbehörde, ergänzt durch überprüfte klinische Feeds.
- Zur Beobachtung rechtlicher Angelegenheiten und Gerichtsverfahren folgt die Haupt-T1-Reihe dem offiziellen Urteils-Feed des Gerichts.
Eine dynamische Suchfunktion ergänzt die feste Liste, damit diese nicht veraltet. Jeden Morgen werden mehrere gezielte Suchen in einer sekundären Liste von Quellen durchgeführt, wobei Obergrenzen für die Anzahl der Wörter, die Anzahl der Abrufversuche pro Quelle sowie ein Gesamtbudget an Seiten pro Suche gelten. Um zeitliche Genauigkeit zu gewährleisten, werden automatisch alle Seiten entfernt, die keinen nachprüfbaren Erscheinungstermin haben oder einen zukünftigen Termin aufweisen. Offene Konsultationen mit Fristen sind die einzige Ausnahme: Sie werden in einer Überwachungsliste geführt, täglich erneut abgerufen und als laufende Anfragen markiert. Seiten von Hosts, die nicht auf der Liste stehen, erhalten eine niedrige Autoritätsstufe, sodass externe Kommentare entsprechend gekennzeichnet werden.
Direktes Lesen der hochrangigen Register
Jedes Feld hat eine übergeordnete Quelle, die allen anderen Vorrang hat – sei es ein Gesetzesregister, ein Primärzitierungsindex oder eine Gerichtsdatenquelle. Der Sammler liest diese über strukturierte APIs ein. Beispielsweise bezieht der NDIS-Pipeline die Primärgesetze über die OData-API des Federal Register of Legislation. Sie bevorzugt strukturierte EPUB-Dateien gegenüber PDFs und führt täglich eine Delta-Prüfung anhand eines gespeicherten Cursors durch, um Neuerungen zu identifizieren. Lange Gesetzestexte werden in Blöcke von jeweils 60.000 Zeichen aufgeteilt und Stück für Stück extrahiert, damit die Grenzen des Modells nicht überschritten werden.
Eindeutige Identifikatoren unterscheiden eine tatsächliche rechtliche Änderung von einer routinemäßigen Neindekxisierung:
- As-made-Instrumente sind neu verabschiedete Gesetze des Parlaments, die aktive Änderungsbenachrichtigungen auslösen.
Einpflege unabhängig von der Veröffentlichung
Rohdaten werden mit SHA-256 gehashed und vor Beginn jeder Synthese in Postgres geschrieben, wodurch der Speicher bei jedem Lauf wächst – unabhängig davon, ob eine Ausgabe veröffentlicht wird oder nicht. Der Veröffentlichungszustand wird deterministisch festgelegt, wobei die Einschränkung UNIQUE(briefing_date, channel) den serialisierten Inhalt sowie dessen JSON-Hash speichert. Falls ein Lauf fehlschlägt oder die Übertragung an den Kanal nicht gelingt, findet der nächste Lauf die ausstehende Reservierung und veröffentlicht den eingefrorenen Inhalt anstelle von neuem Text.
Drei Arten von Morgenläufen hinterlassen unterschiedliche Spuren:
- An einem ruhigen Morgen ohne neue Fakten werden Dokumente in einer Transaktion als geprüft markiert und anschließend archiviert.
- An einem zurückgehaltenen Morgen, an dem ein Redakteur den Entwurf ablehnt, wird keine Bewertungsspur erstellt und die Dokumente werden in die Warteschlange des nächsten Morgens zurückgegeben.
- An einem veröffentlichten Morgen werden die zitierten Dokumente als bearbeitet und aus dem Verkehr gezogen markiert.
Durch die Beibehaltung der ursprünglichen Versionen wird eine strenge zeitliche Nachvollziehbarkeit gewährleistet. Eine im März gestellte Frage nach dem Wissensstand im Januar wird ausschließlich anhand der im Januar gespeicherten Passagen beantwortet, unberührt von späteren Änderungen auf der Live-Webseite.
Die Redaktion
Um Halluzinationen zu vermeiden, gilt bei der Erstellung eines Entwurfs eine strenge Regel: Das Modell bearbeitet niemals direktem Zugriff auf faktische Daten.
Der Code entfernt alle wörtlichen Datumsangaben und URLs aus einem Beweismittelpaket, bevor dieses den Ersteller erreicht. Deterministische Musterprüfungen lehnen jeden Entwurf ab, der einen rechtlichen oder operativen Status wie „in Kraft“ oder „beginnt“ angibt. Überprüfte Datumsangaben werden erst nach der Annahme des Entwurfs wieder eingefügt, und zwar aus Datenbankfeldern, damit ihre Herkunft im Text erhalten bleibt. Diese Regel hilft in allen genannten Bereichen: Stichprobenumfänge, Effektabschätzungen und Medikamentendosen bleiben an die Datenbankdaten gebunden und gelangen nicht in das parametrische Speicher des Modells.
Der Arbeitsablauf folgt einem deterministischen, mehrstufigen Workflow:
- Planung und Ausschluss. Ein Planer weist jedes Dokument einer bestimmten Angelegenheit zu oder gibt einen expliziten Grund für dessen Ausschluss an, beispielsweise Doppelung, Unbedeutendheit oder unzureichende Beweise.
JSON-Schemata, deterministische Validatoren sowie zwei Kritiker und ein Renderer definieren den Vertrag. Offener Text kann mit überall gehosteten Inferenzwerkzeugen verarbeitet werden, doch Speicher, die private Gesundheitsinformationen oder unveröffentlichte Forschungsergebnisse enthalten, müssen die Inferenz innerhalb lokaler Grenzen durchführen.
Aufrufe über MCP und Hinzufügen privaten Kontexts pro Sitzung
Ein nur zum Lesen zugelassener Server, der das Model Context Protocol implementiert, stellt den persistenten Speicher über drei Tools zur Verfügung: search_knowledge_base, get_document und list_changes. Zur Gewährleistung der Faktengenauigkeit müssen Suchauszüge, die auf Serverseite erzeugt werden, an Wortgrenzen enden. Ein Satzteil, der mitten im Wort abgeschnitten wird, kann dazu führen, dass ein generatives Modell den fehlenden Text in der Präsentationsschicht plausibel ergänzt – ein Risiko, das bei Medikamentendosen oder gesetzlichen Grenzwerten nicht akzeptiert werden kann.
Die öffentlichen Beweismittel sind für alle in einem Bereich identisch, doch jeder Benutzer kommt mit einem privaten Kontext. Ein Compliance-Team möchte eine neue Regel im Vergleich zur internen Richtlinie prüfen, während ein Arzt aktualisierte Forschungsergebnisse im Zusammenhang mit der Vorgeschichte eines einzelnen Patienten betrachten möchte. Die Vermischung öffentlicher Beweismittel mit sensiblen lokalen Aufzeichnungen in einer einzigen Datenbank würde ernsthafte Probleme hinsichtlich der Datenerfassungskette und der Privatsphäre verursachen.
Daher trennt die Architektur den öffentlichen Speicher vom privaten Kontext. Sensible persönliche und klinische Daten bleiben in authentifizierten lokalen Umgebungen hinter einer strengen Vertrauensgrenze. Überprüfte öffentliche Fakten werden auf Anfrage vom nur zum Lesen zugänglichen MCP-Server bereitgestellt, und der Assistent kombiniert sie mit lokalen Aufzeichnungen ausschließlich innerhalb der aktuellen Sitzung des Benutzers. Der private Kontext gelangt niemals in den gemeinsamen Speicher, wodurch die öffentliche Datenbank weiterhin von vielen Benutzern genutzt werden kann.
Warum offene Suchfunktionen und einfache Abrufmethoden unzureichend sind
Das Direktverwenden eines autonomen Agenten für offene Websuche oder einen standardmäßigen RAG-Connector erfüllt nicht die Anforderungen an Vertrauenswürdigkeit in hochriskanten Bereichen. Live-Suchfunktionen ignorieren Einschränkungen bezüglich der Wiederverwendung durch Verlage, speichern keine gehashten Herkunftsangaben, die von Prüfern überprüft werden könnten, und können nicht angeben, was sich seit gestern geändert hat. Wenn ein unbegründeter Assistent über den Umfang seiner Indizierung hinaus befragt wird, neigt er dazu, zu raten oder unvollständige Fakten fortzusetzen, wodurch Fehler in nachfolgende Analysen übergehen.
Dieses Design findet sich in mehreren Bereichen wieder:
- In der NDIS sowie im breiteren Behindertensektor bilden gesetzliche Änderungen und Preisanpassungen den politischen Kontext, während die Budgetpläne der Teilnehmer sowie Fallunterlagen diesen nur während einer Live-Sitzung entsprechen.
Die Überlassung der faktischen Genauigkeit an ein unbegründetes Sprachmodell ist ein Risiko. Ein strukturiertes Quellenregister, eine Datenbank, die zuerst gespeichert wird, ein Redaktionsbüro mit zwei Kritikern sowie ein nur zum Lesen zugänglicher MCP-Server unter dem Assistenten verwandeln flüchtige Web-Updates in eine Wissensbasis, die autoritativ, datenschutzkonform und zuverlässig ist.