Recherche in Archiven, Bibliotheken & Kulturerbe-Sammlungen

Archive, Bibliotheken und Museen verwahren riesige Bestände, deren Katalogdatensätze dünn sind, in einer Sprache verfasst und nach Provenienz statt nach den Fragen der Menschen geordnet. KI macht handschriftliche und gedruckte Seiten durchsuchbar, bildet Datensätze und Bilder in einem gemeinsamen semantischen Raum ab und lässt Nutzer in natürlicher Sprache sprachübergreifend fragen, mit Antworten, die den genauen Datensatz nennen. Die Fachkraft (Archivar/Bibliothekar) bleibt die Instanz für Beschreibung und Zugang.

Problem & Nutzen

• Heute: Die Recherche stützt sich auf hierarchische Findbücher, Schlagwortsuche und die Erfahrung im Lesesaal. Das meiste digitalisierte Material sind Bilder ohne Text; viele Stücke haben nur eine Beschreibung auf Serienebene. Nutzer müssen die richtigen Begriffe, Schreibvarianten und historischen Ortsnamen kennen.
• KI-Nutzen: Volltextsuche in handschriftlichen und gedruckten Seiten, Suche auf Begriffsebene (semantisch) und über Sprachgrenzen hinweg, Suche per Beispielbild, automatische Vorschläge für Sachbegriffe, Personen und Orte sowie dialogbasierter Zugang mit Quellenangaben.
• Größenordnung (Beispiele, von den Portalen selbst): Archivportal-D listet etwa 270 Archive, mehr als 170.000 Bestände und über 36 Millionen Objekte [3]; Europeana ermöglicht den Zugang zu Objekten von über 2.000 europäischen Einrichtungen, mit grob 34 Millionen Bild- und 25 Millionen Textobjekten [4]; Transkribus meldet über 200 Mio. transkribierte Seiten [1]. Solche Mengen lassen sich nicht manuell beschreiben.
• Geprüfte Kosteneinsparungen werden hier nicht genannt; Einrichtungen sollten ihre eigene Ausgangslage messen (siehe Kennzahlen).

Varianten

• Staats-/Kommunal-/Kirchenarchive: Findbuchsuche plus HTR von Registern, Protokollen, Kirchenbüchern.
• Bibliotheken: semantische Katalogsuche, Recherche in digitalisierten Zeitungen und Frühdrucken.
• Museen/Galerien: Bild- und Textsuche über Objektdatensätze (LIDO), „ähnliches Objekt finden“.
• Firmenarchive & Mittelstand: Firmengeschichte, Marken-/Produktarchive, technische Zeichnungen (siehe DOC-013), durchsuchbar für Marketing, Patente und Service.
• Genealogie/private Nutzung: Familienforscher, die Register durchsuchen; Heimat- und Geschichtsvereine.
• Aggregatoren: Portale im Stil von Europeana / Deutscher Digitaler Bibliothek mit mehrsprachiger Suche [3][4][5].
• Die Handschriftentranskription selbst ist DOC-005; dieser Anwendungsfall ist die Recherche-Schicht darüber.

So funktioniert es

1. Bestände (Findbücher, Katalogisate, Scans, Audio/Video)
2. Erfassung: HTR/OCR + Layout-Parsing (ALTO / PAGE XML / TEI) für Scans
3. Normalisierung: Abbildung auf Standardschemata (EAD3, RiC-O, LIDO, EDM) und IIIF-Manifeste
4. Anreicherung: NER (Personen, Orte, Daten), Normdaten-Verknüpfung (GND, Wikidata), Übersetzung, Schlagwortvorschläge
5. Index: hybrid BM25 + dichte Embeddings (Text und Seite/Bild), Metadatenfilter, Rechte-/Zugangsmarkierungen
6. Suche: Anfrage umformulieren
7. hybride Suche
8. Reranker
9. Filter nach Zugangsrechten
10. Darstellung: Trefferliste mit hervorgehobenem Bereich im IIIF-Viewer; optional RAG-Antwort mit Quellenangaben
11. Rückmeldung: Archivar prüft KI-vorgeschlagene Metadaten; Korrekturen fließen zurück

• Suche (Retrieval): Hybride lexikalische + semantische Suche ist unverzichtbar, weil historische Schreibweisen, OCR-/HTR-Rauschen und Eigennamen reine Embeddings scheitern lassen. Seitenbild-Retriever im Stil von ColPali (Multi-Vektor-Modelle) bilden Seitenbilder direkt ab und vermeiden fehleranfällige OCR-Pipelines bei Layouts mit Tabellen oder Stempeln [7].
• Standards: Records in Contexts (RiC-O v1.1, eine OWL-Ontologie für die Archivbeschreibung als Linked Data) [6], IIIF für die Bildauslieferung [8], Europeana Data Model für die Aggregation [4].
• Mensch-in-der-Schleife (Human-in-the-Loop): KI-generierte Beschreibungen werden gekennzeichnet und zur fachlichen Freigabe eingereiht; Zugangsbeschränkungen (Sperrfristen, Schutzfristen für personenbezogene Daten) werden vor der Suche durchgesetzt.

Datenaufbereitung

Dies ist der datenintensivste Anwendungsfall dieser Reihe. Das Material besteht aus Katalogdatensätzen und Findbüchern (Archiv- oder Bibliothekssystem, oft alte Datenbanken oder Word- und Excel-Listen), Scans und Mikrofilm, Audio und Video und in kleinen Einrichtungen aus Papierregistern. Die Dateien liegen typischerweise im Sammlungsverwaltungssystem, auf Dateiablagen und auf externen Laufwerken.

Typische Lücken: keine oder unvollständige Digitalisierung, Scans ohne Textebene, HTR für Handschriften nötig, uneinheitliche Katalogschemata, Dubletten und Schreibvarianten von Namen, fehlende Kennzeichen für Rechte und Schutzfristen sowie personenbezogene Daten in nicht öffentlichen Unterlagen.

Schritte der Aufbereitung: - Bestände inventarisieren und eine Digitalisierungspriorität festlegen (PREP-001, PREP-006). - Nach einem Standard scannen (z. B. TIFF/JPEG2000 mit IIIF-Auslieferung) und OCR/HTR mit Transkribus oder Kraken ausführen; ALTO/PAGE XML aufbewahren. - Katalogdaten auf EAD3, RiC-O oder LIDO abbilden und Normnamen gegen die GND bereinigen (PREP-010, PREP-012). - Vor der Indexierung Kennzeichen für Zugangsrechte ergänzen (PREP-023, PREP-025). - Eine Testmenge echter Nutzerfragen mit von Archivaren beurteilter Relevanz aufbauen (PREP-018); verwandt: DOC-005, DOC-014, DOC-018.

Die Datenaufbereitung ist der größte Kostenblock, typischerweise 50 bis 70 Prozent des Gesamtaufwands, weil Digitalisierung und Qualitätskontrolle mit der Größe der Sammlung wachsen.

Umsetzungswege

Welcher Weg für wen

• Öffentliche Hand: Weg B in einer souveränen EU- oder deutschen Cloud, weil Archive und Bibliotheken eine individuelle Portalanbindung brauchen und das Vergaberecht EU-Hosting begünstigt; nicht öffentliche Unterlagen gehen zu Weg C.
• Großunternehmen: Weg B, weil Firmenarchive und Mediatheken die Anbindung an bestehende DAM/DMS brauchen und ein verwalteter, in der EU gehosteter API-Stack den Betriebsaufwand gering hält.
• Entwickler: Weg C, weil Kraken/eScriptorium, Docling und offene Suchmodelle volle Kontrolle bieten und für Einrichtungen mit eingeschränkten Beständen wiederverwendet werden können.
• Privat: Weg A, weil Werkzeuge wie Transkribus die Transkription für Familien- und Heimatgeschichte ohne technische Kenntnisse ermöglichen.
• KMU: Weg A, weil kleine Archive, Vereine und Unternehmen schnell durchsuchbare Transkriptionen brauchen und Transkribus (Österreich, EU) ein ausgereiftes Produkt zu moderaten Preisen ist.

Weg A — Kaufen (Standardsoftware; empfohlen für kleine Archive und Vereine)

• Transkribus (READ-COOP, österreichische Genossenschaft, EU): HTR in über 100 Sprachen, Volltextsuche über Sammlungen hinweg, öffentliche Seiten; Daten werden auf eigenen Servern in Österreich verarbeitet; API ab dem Tarif Scholar [1]. Starke Standardwahl für handschriftliches Material.
• Archiv-/Bibliothekssoftware mit Suche: Archivverwaltungssysteme (z. B. Arcinsys, FAUST, AUGIAS, scopeArchiv), Bibliothekssysteme und Discovery-Schichten (z. B. Ex Libris Primo, EBSCO Discovery, VuFind-basiert), Museumssysteme (z. B. museum-digital, MuseumPlus). Prüfen Sie Roadmaps zu KI-Suche, EU-Hosting und EAD-/LIDO-/IIIF-Export.
• Unternehmenssuche mit RAG: Allgemeine Plattformen (KNOW-001/KNOW-002) können Exporte indexieren, bieten aber meist keine hierarchiebewusste Suche (Bestand/Serie/Einzelstück) und keine Behandlung von Sperrfristen.
• Wählen Sie A, wenn: ein kleines Archiv oder ein Verein schnell durchsuchbare Transkriptionen ohne Entwickler möchte.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen für Einrichtungen mit Entwicklern)

• Modelle: ein mehrsprachiges Embedding-Modell und Reranker in einer EU-Region, ein LLM mit strukturierter Ausgabe und Quellenangaben (z. B. Mistral, Claude oder Gemini in EU-Regionen; Azure OpenAI EU Data Zones) für Umformulierung von Anfragen, Antworterzeugung und Metadatenvorschläge; ein VLM für Fotos und Seitenlayout.
• Index: OpenSearch/Elasticsearch hybrid oder Qdrant/Weaviate/pgvector mit BM25 nebeneinander.
• Pipeline: Transkription über die Transkribus-API oder einen Cloud-Dienst für Dokumenten-KI, danach Anreicherung und Indexierung; Ergebnisse über das bestehende Portal und den IIIF-Viewer (Mirador, Universal Viewer) bereitstellen.
• Wählen Sie B, wenn: eine mittelgroße Einrichtung oder ein Aggregator Entwickler oder einen Integrator hat und individuelle Rangfolge und Portalanbindung braucht. Vollständig öffentliches, bereits veröffentlichtes Material unterliegt kaum Datenbeschränkungen; nicht öffentliche Unterlagen brauchen einen Auftragsverarbeitungsvertrag und Hosting in der EU.

Weg C — Selbst betreiben (Open Source)

• Erfassung: Kraken mit eScriptorium (trainierbare Layoutanalyse und HTR für historische und nicht-lateinische Schriften, Apache-2.0, Ausgabe als ALTO/PAGE XML) [2]; Docling (MIT) für moderne PDFs [9]; offene VLM-basierte OCR-Modelle.
• Suche: offene mehrsprachige Embedding-Modelle (BGE-M3-Klasse, multilingual-e5) mit Rerankern; Seitenbild-Retriever der ColQwen-Familie (es gibt Varianten unter Apache-2.0; prüfen Sie die Lizenz jedes Modells) [7].
• Betrieb: vLLM/Ollama mit einem Open-Weight-LLM (Familien Qwen, Mistral, Llama); OpenSearch oder Qdrant; Cantaloupe oder ein ähnlicher IIIF-Bildserver; Mirador/Universal Viewer.
• Hardware: HW3 (eine GPU mit 48–141 GB) für HTR-Stapel, Embeddings und ein 30–70B-LLM; HW2 genügt für reine Suchbereitstellungen mit einem kleineren LLM. Die anfängliche Massentranskription kann als zeitlich begrenzter Auftrag angemietet werden.
• Wählen Sie C, wenn: nicht öffentliche Unterlagen (Personalakten, Polizei- oder Kirchenakten, eingeschränkte Bestände), Souveränitätsanforderungen oder sehr große Mengen die Verarbeitung in der Cloud unannehmbar machen.

Weg D — Eigenes Training

Lohnt sich für HTR auf eine bestimmte Handschrift, Schrift oder Epoche: ein Erkennungsmodell auf transkribierter Referenzdatenbasis (Ground Truth) trainieren oder feinabstimmen (typischerweise einige Dutzend bis einige hundert Seiten für ein erstes brauchbares Modell; mehr für schwierige Handschriften, ohne Gewähr). Zweites Ziel: an die Domäne angepasste Embeddings für historische Sprache und kontrollierte Vokabulare, anhand von Klickprotokollen und Relevanzurteilen der Archivare. Gemeinschaftliche Modell-Repositorien (Transkribus-Modelle, Kraken-Modell-Repository) verringern den Bedarf [1][2].

Stand der Technik (2026)

• Grundlage der Recherche ist nun die Erkennungsqualität: HTR/OCR für historische Dokumente ist für viele Schriften produktionsreif, schwankt aber stark mit Handschrift, Schrift und Scan-Qualität; bewahren Sie immer die Konfidenzwerte und das Seitenbild neben dem Text auf.
• Seitenbild-Suche (ColPali-Familie) und VLM-basierte Analyse lassen Einrichtungen Layouts, Stempel, Karten und Tabellen ohne perfekte OCR durchsuchen [7].
• Hybride Suche + Reranking + Metadatenfilter übertrifft reine Vektorsuche bei historischer Sprache; hierarchisches RAG, das den Kontext Bestand/Serie/Einzelstück berücksichtigt, ist ein aktives Praxisfeld.
• Linked-Data-Modellierung wandert von EAD zu RiC-O/RiC-CM (v1.1 veröffentlicht 2025), sodass KI-extrahierte Beziehungen als Graph gespeichert werden können (KNOW-013) [6].
• Grenzen und Fehlerbilder: halluzinierte Provenienz oder Datierungen in erzeugten Zusammenfassungen; Verzerrung zugunsten gut beschriebenen Materials in Mehrheitssprachen; HTR-Fehler bei Namen (den wichtigsten Suchbegriffen); auf moderner Sprache trainierte Embedding-Modelle; koloniale oder veraltete Begriffe in Altbeschreibungen, die ohne Kontext übernommen oder „korrigiert“ werden; Kosten und Zeit für die Neuverarbeitung von Millionen Seiten. Unabhängige Benchmark-Zahlen für die Werkzeuggeneration 2026 konnte ich nicht überprüfen und nenne daher keine.

Gemeinsame Bausteine & Kombinationen

• Gleicher Erfassungs-Stack: DOC-005 (Handschriftenerkennung & historische Transkription), DOC-014 (Dokumentenverarbeitung für RAG) – ein GPU-Server (HW3) bedient alle.
• Gleicher Such-Stack: KNOW-001 (semantische Unternehmenssuche), KNOW-002 (RAG über Dokumente), KNOW-016 (multimodale Bild-/Video-/Audio-Archivsuche) teilen Embeddings, Vektordatenbank, Reranker und die IIIF-/DAM-Schicht.
• Anreicherung: KNOW-013 (Wissensgraph / GraphRAG) für Netzwerke aus Personen, Orten und Ereignissen; LANG-009 (Übersetzung) für den sprachübergreifenden Zugang; DOC-018 (Anonymisierung/Schwärzung) vor der Veröffentlichung von Unterlagen mit geschützten personenbezogenen Daten.
• Hardware: Embedding- und Reranker-Modelle plus ein LLM auf einem HW3-Knoten; Stapel-HTR auf denselben GPUs außerhalb der Öffnungszeiten.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen bis zum Start; Abo- bzw. guthabenbasiert, die Kosten richten sich nach der Zahl der verarbeiteten Seiten [1].
• Weg B: typischerweise 3–9 Monate für die Anbindung an ein produktives Portal; Kostentreiber sind die Massen- transkription, die Embedding-Berechnung des gesamten Bestands (einmalig) und die LLM-Kosten je Anfrage.
• Weg C: 6–12 Monate mit eigenem oder Partnerteam; GPU-Server plus Betrieb; Hauptkosten sind die Integration in Archivsysteme und die Qualitätskontrolle, nicht die Hardware.
• Kennzahlen: Anteil der Sammlung mit Volltext; HTR-Zeichen-/Wortfehlerrate an einer zurückgehaltenen Stichprobe; Recall@k und nDCG an einer Testmenge echter Nutzerfragen mit von Archivaren beurteilter Relevanz; Rate der Anfragen ohne Treffer; Richtigkeit der Quellenangaben in erzeugten Antworten; Anteil der angenommenen KI-Metadatenvorschläge; Zeit für die Beschreibung eines Stücks; Anfragevolumen im Lesesaal und online.

Menschen & Veränderung

Wer und wann: Die Geschäftsleitung und die Abteilungsleitung (Archiv- oder Bibliotheksleitung) klären zu Beginn Umfang und Prioritäten. Archivare und Bibliothekare legen als Endanwender die Metadatenregeln fest und prüfen von der ersten Pilotphase an die KI-vorgeschlagenen Beschreibungen. Die IT baut die Pipeline; die Datenschutzbeauftragten und Legal/Compliance klären Fristen, Urheberrecht und personenbezogene Daten, bevor nicht öffentliche Unterlagen indexiert werden. Dateneigner (Schenker, Deponenten, Herkunftseinrichtungen) sind anzuhören, wo Verträge die Nutzung einschränken.

Betriebsrat: In der Regel nein, weil das System die Beschäftigten nicht überwacht; prüfen Sie dies, wenn Lesesaal- oder Mitarbeiter-Suchprotokolle je Person ausgewertet werden (§87 Abs. 1 Nr. 6 BetrVG). In öffentlichen Einrichtungen wird der Personalrat rechtzeitig über veränderte Arbeitsabläufe unterrichtet (entsprechend §90 Abs. 1 Nr. 3 BetrVG nach BPersVG/Landesrecht).

Datenschutz: Personenbezogene Daten in nicht öffentlichen Unterlagen sind wahrscheinlich, daher ist eine DSFA (Art. 35 DSGVO) ratsam, ein AVV (Art. 28 DSGVO) mit jedem Auftragsverarbeiter ist Pflicht, und Schutzfristen müssen vor der Suche durchgesetzt werden.

KI-Kompetenz: Art. 4 KI-Verordnung (AI Act) verlangt Maßnahmen zur Förderung der KI-Kompetenz der Beschäftigten; schulen Sie Archivare zu HTR-Fehlern und halluzinierten Quellenangaben (GUIDE-006, GUIDE-005).

Kommunikation und Pilot: Pilot mit einem gut beschriebenen Bestand und einer kleinen Gruppe Freiwilliger (GUIDE-009, GUIDE-008).

Bedenken: „Ersetzt KI die fachliche Erschließung?“ Nein: KI-Vorschläge werden gekennzeichnet und von Fachkräften freigegeben, die weiterhin bestimmen, was zu offiziellen Metadaten wird.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise minimales Risiko – ein Such- und Beschreibungswerkzeug ist kein Anwendungsfall nach Anhang III. Ein Chatbot über die Sammlung löst die Offenlegung nach Art. 50 aus (Nutzer müssen wissen, dass sie mit KI interagieren); KI-generierte Beschreibungen, die öffentlich bereitgestellt werden, sollten gekennzeichnet werden [10]. Der Einsatz derselben Werkzeuge für z. B. das Profiling von Personen aus Archiven von Polizei oder Nachrichtendiensten würde das Bild ändern (Strafverfolgung/Anhang III) und ist nicht Gegenstand.
• DSGVO: Archive verwahren personenbezogene Daten (Register, Personal-, Gerichts-, Gesundheitsakten, auch besondere Kategorien). Die Archivierung im öffentlichen Interesse hat Privilegien (Art. 89 DSGVO und nationale Archivgesetze), aber Zugang, Schutzfristen (z. B. 30 Jahre nach dem Tod oder 110 Jahre nach der Geburt in vielen deutschen Archivgesetzen; prüfen Sie das anwendbare Bundes-/Landesrecht) und Rechte Dritter gelten weiter. Setzen Sie Zugangsregeln im Index durch, nicht nur im Frontend; keine eingeschränkten Unterlagen an APIs außerhalb der EU senden.
• Urheberrecht und Rechte: Verwaiste Werke, Datenbankrechte und Lizenzbedingungen (Rechteangaben wie RightsStatements.org) müssen bis in die Ergebnisse mitgeführt werden; prüfen Sie die Schranken des EU-Urheberrechts für Text- und Data-Mining, bevor Sie Modelle auf Sammlungen Dritter trainieren oder feinabstimmen.
• Berufsethik & Provenienz: KI-Ausgaben müssen von der durch Archivare erstellten Beschreibung unterscheidbar sein; führen Sie ein Prüfprotokoll, wer/was jede Aussage erzeugt hat (archivische Authentizität).
• Gegenmaßnahmen: Zugriffsfilter vor der Suche, Anzeige der Konfidenz, menschliche Freigabe der Anreicherung, Red-Team-Anfragen auf sensible Bestände, Verarbeitung in der EU/On-Premises für nicht öffentliche Unterlagen.

Erste Schritte

1. Einen abgegrenzten Pilotbestand wählen (z. B. einen Bestand oder einen Zeitungstitel) mit gemischtem handschriftlichem und gedrucktem Material und einer bekannten Menge von 50–100 echten Nutzerfragen.
2. Digitalisieren oder nach IIIF + ALTO/PAGE XML exportieren; HTR/OCR mit Transkribus oder Kraken ausführen und die Fehlerrate an einer von Hand geprüften Stichprobe messen.
3. Einen hybriden Index (BM25 + Embeddings + Reranker) mit Metadaten zu Zugangsbeschränkungen aufbauen und ihn mit der aktuellen Suche anhand der Fragenmenge vergleichen, beurteilt durch Archivare.
4. Eine Antwortschicht mit Quellenangaben und KI-vorgeschlagene Metadaten erst ergänzen, wenn die Suche gut ist; alle KI-Ausgaben kennzeichnen.
5. Rechtsgrundlage, Aufbewahrungs- und Zugangsregeln dokumentieren, dann die Skalierung und die Integration in das Archivinformationssystem planen.

Quellen

1. Transkribus (READ-COOP) — https://www.transkribus.org/
2. Kraken OCR/HTR engine — https://github.com/mittagessen/kraken
3. Archivportal-D (Deutsche Digitale Bibliothek) — https://www.archivportal-d.de/
4. Europeana — About us — https://www.europeana.eu/en/about-us
5. Deutsche Digitale Bibliothek portal — https://www.deutsche-digitale-bibliothek.de/
6. ICA Records in Contexts Ontology (RiC-O v1.1) — https://www.ica.org/standards/RiC/ontology
7. ColPali (page-image document retrieval) — https://github.com/illuin-tech/colpali
8. IIIF — Why IIIF — https://iiif.io/get-started/why-iiif/
9. Docling — https://github.com/docling-project/docling
10. EU AI Act Article 50 (transparency) — https://artificialintelligenceact.eu/article/50/