Projekte

Ausgangslage

Ein zentraler Stammdatenbestand sollte laufend gegen öffentlich zugängliche Quellen geprüft und ergänzt werden. Bis dahin geschah das punktuell und von Hand. Änderungen fielen spät auf, der Pflegeaufwand war nicht planbar, und niemand konnte belastbar sagen, welcher Anteil des Bestands überhaupt aus öffentlichen Quellen zu decken ist.

Vorgehen

Bewusst zweistufig, statt sofort eine Pipeline zu bauen. In der ersten Stufe lief ein Prototyp vollständig auf lokalen Rechnern, ohne Serverinfrastruktur und damit ohne laufende Kosten, und hat je Zielfeld gemessen, was tatsächlich und in welcher Qualität abzuschöpfen ist.

Erst dieser Messbericht hat Umfang und Festpreis der Umsetzungsstufe festgelegt. Keine Seite trägt damit ein Blindrisiko, und teure Technik wird nur dort eingeplant, wo die Messung sie rechtfertigt. Seiten, die sich statisch auslesen lassen, brauchen keinen Browser-Renderer.

In der Umsetzung wurden die Extraktoren produktiv gehärtet: Parallelität, Wiederaufsetzbarkeit nach Abbruch, Wiederholungslogik, Renderer nur als Rückfallweg. Dazu ein Modul, das ein öffentliches Register anbindet, monatliche Veränderungen gegen den Vormonat bildet und die Einträge den Objekten des Bestands zuordnet.

Ergebnis

Ein monatlich reproduzierbarer Lauf, der je Objekt einen strukturierten Datensatz erzeugt, die Herkunft jedes Feldes belegt und auf günstiger Infrastruktur läuft. Die Grenze zum Kundensystem ist sauber gezogen: Wir liefern Daten, keine Klickstrecken.

Technik

Python, httpx, BeautifulSoup und selectolax, Playwright als Rückfallweg, Named-Entity-Erkennung, Polars, Delta und Parquet, Lakehouse-Anbindung, systemd und cron, Überwachung mit Alarmierung.

Ausgangslage

Ein gepflegter Referenzbestand sollte den Abnehmern zeigen, wo ihre eigenen Daten davon abweichen. Datensatz für Datensatz, Feld für Feld. Gefordert war die Rechenlogik dahinter, nicht die Darstellung.

Vorgehen

Die Analyse des fachlichen Regelwerks ergab, dass die Zuordnung vollständig deterministisch beschrieben ist. Damit war ein probabilistisches Verfahren für Record Linkage überflüssig. Diese Erkenntnis hat den Aufwand deutlich gesenkt und zugleich die Nachvollziehbarkeit erhöht: Jede Zuordnung lässt sich auf eine benannte Regel zurückführen.

Gebaut wurde eine schlanke Verarbeitung ohne eigene Datenbank und ohne Oberfläche. Sie nimmt die Daten entgegen, legt sie in der bestehenden Rechenumgebung ab, normalisiert, ordnet je Satz den passenden Referenzdatensatz zu und vergleicht feldweise. Zurück kommen Zuordnung, Bewertung und die konkreten Abweichungen je Feld, als Tabelle, auf der beliebige Darstellungen aufsetzen können.

Ebenso wichtig war, was wir nicht übernommen haben: Der Entwurf der fachlichen Regeln blieb beim Auftraggeber, der das Geschäft kennt. Der kommerziell riskante Punkt wurde vorab benannt und nicht im Angebot versteckt.

Ergebnis

Ein wiederholbarer Lauf, dessen Ergebnis als Datenprodukt vorliegt und intern wie für Endkundensichten verwendbar ist. Weil er in der vorhandenen Rechenumgebung läuft, entstehen praktisch keine zusätzlichen Betriebskosten.

Technik

Python, Record Linkage im Prozess auf DuckDB, Polars, Lakehouse-Anbindung für Lesen und Schreiben, optionale Adressnormalisierung. Bewusst ohne eigene Datenbank und ohne GPU, der Lauf verträgt Wartezeit.

Ausgangslage

Laufende Abgleiche produzieren zuverlässig eines: Abweichungen. Entscheiden kann sie nur ein Mensch mit Fachkenntnis, und effizient nur dann, wenn er alle Quellen nebeneinander sieht, den Beleg dazu, und wenn seine Entscheidung nicht im nächsten Monat erneut auf dem Tisch liegt.

Vorgehen

Jede Abweichung wird zu einem Fall mit stabilem Schlüssel aus Vergleichsachse, Objekt, Feld und den verglichenen Werten. Ändert sich ein Wert, entsteht ein neuer Fall. Wird die Quelle korrigiert, erlischt der alte von selbst, ohne dass jemand aufräumen muss.

Zu jedem Fall gehört der Beleg: die Seite, aus der der Wert gelesen wurde, gerendert aus dem Stichtags-Zwischenspeicher statt live abgerufen, damit Beleg und Datenstand zusammenpassen. Dazu Registereintrag und weitere Quellen als eigene Karten sowie ein regelbasierter Vorschlag, der begründet, welche Quelle vermutlich recht hat.

Alle Entscheidungen laufen in ein Protokoll, das im Folgelauf als Gegenprüfung wirkt: Was entschieden ist, taucht nicht wieder auf. Korrekturen fließen definiert in die Zielsysteme, nicht unkontrolliert in den Referenzbestand.

Ergebnis

Der Prüfaufwand konzentriert sich auf die Fälle, die wirklich eine menschliche Entscheidung brauchen. Entscheidungen sind dokumentiert, belegt und wiederverwendbar. Der Bestand wird mit jedem Lauf besser statt nur anders.

Technik

Python, JSONL- und Delta-Tabellen, Playwright-Rendering aus dem Zwischenspeicher, ein statisches HTML-Frontend ohne Ausrollaufwand, Export nach Excel und optional direkt in die Analyseplattform.

Ausgangslage

Dokumente, die demselben Zweck dienen, sehen selten gleich aus: andere Gliederung, andere Bezeichnungen, andere Reihenfolge. Vorlagenbasierte Auslesung scheitert daran regelmäßig, und die Pflege der Vorlagen wird selbst zum Projekt.

Vorgehen

Ein Vision-Modell liest die Seiten so, wie ein Mensch sie liest, Layout inbegriffen.

Die Zuordnung der gelesenen Inhalte auf ein einheitliches Zielschema ist ein eigener, prüfbarer Schritt. Sie ist damit nachvollziehbar und korrigierbar, statt in der Modellantwort zu verschwinden.

Unsichere Zuordnungen landen nicht still im Ergebnis, sondern in einer Prüfliste. Die Freigabe bleibt beim Menschen, Lücken werden lokalisiert statt geschätzt.

Ergebnis

Eine Verarbeitungsstrecke, die neue Dokumentvarianten ohne Vorlagenpflege aufnimmt und den manuellen Aufwand auf die Ausnahmen konzentriert.

Technik

Python, Vision-Sprachmodell, regelbasierte Nachprüfung der Zuordnung, strukturierte Ausgabe in ein einheitliches Schema.

Ausgangslage

In vielen Organisationen hängt ein erheblicher Teil des Tagesgeschäfts an einzelnen Personen. Ihr Wissen steht nirgends geschrieben, es wird erfragt, und das kostet beide Seiten Zeit. Klassische Werkzeuge setzen voraus, dass jemand dieses Wissen zuerst aufschreibt. Genau das passiert nie.

Vorgehen

Wir setzen dort an, wo die Person ohnehin ausführlich formuliert: in Korrespondenz, Notizen und Dialogen mit Assistenzsystemen. Diese Quellen werden aufbereitet und indexiert. Nachgefragt wird nur dort gezielt, wo die Auswertung eine echte Lücke zeigt, in kurzen Sitzungen statt in Dokumentationsmarathons.

Entscheidend für die Vertrauenswürdigkeit ist die Verweigerung. Ob das System antwortet, wird an den Rohwerten der einzelnen Suchwege entschieden, nicht am zusammengeführten Rang. Sonst sieht der schlechteste Treffer eines leeren Bestands aus wie ein perfekter.

Gemessen wird mit drei Zahlen statt einer: beantwortete Fragen, ehrlich verweigerte Fragen, und falsch beantwortete Fragen, die nahe null bleiben müssen. Die verweigerten sind zugleich die Liste dessen, was noch zu erfassen ist. Die Testfragen stammen von den Fragenden, nicht vom Wissensträger, und das Testset kommt nie in den Bestand. Sonst misst man Auswendiglernen.

Ergebnis

Ein lauffähiges System von der Erfassung über Suche und Bewertung bis zur Auswertung, je Kunde einzeln in einem europäischen Rechenzentrum betrieben. Jede Antwort trägt ihre Belegstelle.

Technik

Python, PostgreSQL mit Vektorerweiterung und deutschsprachiger Volltextsuche, hybride Suche mit Nachbewertung, FastAPI, Dokumentkonvertierung für gängige Office- und PDF-Formate, Modellzugriff über ein Gateway.

Ausgangslage

Die Datenbasis stand fest, der Zuschnitt nicht: Wie viel der Lösung bauen wir, mit welchen Werkzeugen, und wie kommt sie beim Endnutzer an? Als reine Rechenlogik, als eigenständige Anwendung oder eingebettet in ein bestehendes System? Solche Fragen kosten in Projekten erfahrungsgemäß mehr Zeit als die Umsetzung selbst, wenn sie nebenbei geklärt werden.

Vorgehen

Statt ein Angebot für die naheliegendste Variante zu schreiben, haben wir die möglichen Liefermodelle nebeneinandergestellt: von reiner SQL-Logik, die der Kunde selbst visualisiert, über die Kombination mit einem BI-Werkzeug und einen einbettbaren Baustein bis zur eigenständigen Anwendung mit Anmeldung und zur Vollintegration.

Je Modell ist festgehalten, was wir liefern, was beim Kunden bleibt, welche Werkzeuge nötig sind, wo der Aufwand liegt, und welche eine Frage vorab beantwortet sein muss, damit das Modell überhaupt trägt.

Dazu die Faktoren, die quer über alle Varianten wirken: Reifegrad der Daten, geforderte Aktualität, freie Auswertbarkeit, und vor allem die Mandantentrennung. Die Frage, wer die Datenisolation baut und verantwortet, verschiebt Aufwand und Risiko stärker als die Wahl der Oberfläche.

Ergebnis

Die Entscheidung fiel in einem Termin statt über mehrere Abstimmungsschleifen. Umfang und Verantwortungsgrenzen waren vor der Angebotslegung geklärt, inklusive der Empfehlung, dass das größte Szenario selten das richtige ist.

Technik

SQL-Marts und Sichten in der Lakehouse-Umgebung, BI-Modellierung mit zeilenbasierter Zugriffssteuerung, alternativ Schnittstelle plus eigenes Frontend.