Woher der Begriff kommt, und was davon relevant ist, wenn Frontmatter als Metadaten-Träger beim Chunking und Indexieren von Dokumenten in einer Vektordatenbank verwendet wird.
Front Matter ist nur eines von drei Teilen, in die ein Buch traditionell gegliedert wird — zur Abgrenzung:
Beim Indexieren für eine Vektordatenbank wird ein Dokument typischerweise in Chunks zerlegt, jeder Chunk embeddet und zusammen mit einem Metadaten-Objekt gespeichert. Frontmatter ist der übliche Ort, an dem diese Metadaten im Quelldokument selbst deklariert werden — meist als YAML-Block am Anfang der Datei — statt sie erst zur Laufzeit zu raten oder aus dem Dateisystem abzuleiten.
Der Vorteil: Die Metadaten wandern mit dem Dokument, sind versionierbar (z. B. in Git), von Menschen lesbar und lassen sich beim Ingestion-Schritt 1:1 in das metadata-Feld des Vektor-Records übernehmen — ganz gleich ob Pinecone, Weaviate, Qdrant, Chroma oder pgvector als Backend dient.
--- title: "SLA-Richtlinie Enterprise-Kunden" doc_id: "kb-2026-0341" source: "confluence://legal-space/sla-policy" version: "3.2" created_at: 2025-11-04 updated_at: 2026-07-19 author: "j.mustermann@beispiel-gmbh.de" language: "de" category: "legal" tags: ["sla", "enterprise", "support"] access_level: "internal" --- Inhalt des Dokuments, der anschließend gechunkt und embedded wird …
Bei Markdown ist Frontmatter ein reiner Community-Konvention-Trick: freier Text, den sich niemand vorschreibt. Andere Dateiformate lösen dasselbe Grundbedürfnis — Metadaten unabhängig vom sichtbaren Inhalt mitzuführen — über eigene, teils sogar standardisierte Mechanismen.
Bei Word und PowerPoint (beide im OOXML-Format, technisch ein ZIP-Container) stecken die Metadaten in zwei internen XML-Dateien: docProps/core.xml und docProps/app.xml. Interessant dabei: Die Core-Properties sind explizit auf Dublin Core gemappt — dort taucht der dc:-Präfix aus der letzten Frage tatsächlich 1:1 auf (dc:title, dc:creator, dc:subject, dcterms:created). Der Nutzer setzt diese Felder über Datei → Informationen → Eigenschaften — es gibt aber keine automatisch vorgeschaltete Seite oder Tabelle im Dokument selbst; sichtbare Deckblätter mit Metadaten-Feldern sind immer manuell gestaltete Vorlagen. Frei definierbare Zusatzfelder (das Äquivalent zu category oder access_level) lassen sich über Erweiterte Eigenschaften → Benutzerdefiniert anlegen.
Bei PDFs gibt es zwei parallele Schichten: das ältere Info-Dictionary (Title, Author, Subject, Keywords) und XMP-Metadata — ein eingebettetes XML-Paket, wieder auf Dublin-Core-Basis.
Bei E-Mails ist die Analogie am direktesten: RFC 5322 schreibt einen Header-Block vor einer Leerzeile vor dem eigentlichen Body vor — From, To, Subject, Date, Message-ID, References. Strukturell praktisch identisch zu YAML-Frontmatter, nur ohne ----Trenner. Ein Teil davon setzt der Nutzer (Betreff, Empfänger), ein Teil der Mail-Client automatisch (Datum, Message-ID).
| Format | Wo die Metadaten stecken | Wie sie gesetzt werden |
|---|---|---|
| Markdown (.md) | YAML-Block am Dateianfang | Nutzer schreibt den Block direkt als Text |
| Word / PowerPoint (.docx / .pptx) |
docProps/core.xml + app.xml im OOXML-Container (Dublin-Core-Felder) |
Nutzer über Eigenschaften-Dialog; frei definierbare Felder über „Benutzerdefiniert" |
| Info-Dictionary + eingebettetes XMP-Metadaten-Paket | Erstellende Anwendung beim Export, nachträglich per Tool (Acrobat, ExifTool) änderbar | |
| E-Mail (.eml) | RFC-5322-Header-Block vor einer Leerzeile | Teils Nutzer (Betreff, Empfänger), teils automatisch vom Mail-Client (Datum, Message-ID) |
Für die Indexierungspipeline heißt das: Bei Office-Formaten, PDFs und E-Mails extrahiert der Parser (z. B. python-docx, python-pptx, extract-msg, Unstructured, LlamaParse, Microsoft markitdown) die nativen Metadaten automatisch — dafür brauchst du kein eigenes Frontmatter. Was diese Formate nicht nativ mitbringen — category, access_level, department im Sinne deiner Pipeline — musst du trotzdem zusätzlich zuführen, etwa über die „Benutzerdefinierten Eigenschaften" bei Office-Dateien oder eine separate Mapping-Tabelle pro Quelle/Ordner.
| Feld | Zweck | Herkunft |
|---|---|---|
| doc_id / origin_id | Eindeutige ID des Ursprungsdokuments (meist UUID) — für Updates, Re-Indexierung, Löschung | System |
| source / source_uri | Pfad oder URI zur Originalquelle (Dateisystem, Confluence, S3, Web-URL) | System |
| filename | Ursprünglicher Dateiname, unabhängig vom internen Speicherpfad | System |
| origin | Ingestion-Kanal, z. B. file-upload, web-crawler, confluence-sync | System |
| content_hash / checksum | Hash des Inhalts zur Deduplizierung und zum Erkennen von Änderungen (Re-Embedding nur bei Diff) | System |
| Feld | Zweck | Herkunft |
|---|---|---|
| chunk_id | Eindeutige ID des einzelnen Chunks, oft {doc_id}_{index} | Chunking |
| chunk_index / total_chunks | Position im Dokument, z. B. „Chunk 20 von 181" — ermöglicht Nachbarschafts-Retrieval | Chunking |
| section / heading | Überschrift des Abschnitts, aus dem der Chunk stammt (verbessert Zitierbarkeit) | Chunking |
| page_number | Seitenzahl bei PDFs — wichtig für exakte Quellenangaben | Chunking |
| start_char / end_char | Offset im Originaltext, für Highlighting oder Re-Assembly | Chunking |
Diese Gruppe steht bewusst nicht in der Frontmatter: Sie hängt von der gewählten Chunk-Größe und Overlap-Strategie ab und existiert erst, nachdem der Chunker gelaufen ist — bei jedem Re-Indexierungslauf können sich die Werte ändern.
| Feld | Zweck | Herkunft |
|---|---|---|
| created_at / updated_at | Erstellungs- bzw. letztes Änderungsdatum der Quelle — für zeitliche Filterung („nur aktuelle Version") | Nutzer |
| ingested_at | Zeitpunkt der Indexierung in die Vektor-DB (unabhängig vom Dokumentdatum) | System |
| version | Dokumentversion, relevant wenn mehrere Fassungen parallel existieren können | Nutzer |
| embedding_model | Welches Embedding-Modell verwendet wurde — wichtig bei Modellwechsel/Migration | System |
| Feld | Zweck | Herkunft |
|---|---|---|
| category / type | Grobe Einordnung, z. B. policy, ops, legal | Nutzer |
| tags[] | Frei vergebbare Schlagwörter für feingranulare Filterung | Nutzer |
| department / owner | Organisatorische Zuordnung, unterstützt Multi-Tenant-Trennung | Nutzer |
| access_level / acl | Berechtigungsstufe (z. B. public, internal, confidential) — essenziell, damit die Suche keine Inhalte zurückgibt, für die der fragende User keine Berechtigung hat | Nutzer |
| language | Sprachcode — relevant bei mehrsprachigen Korpora und sprachspezifischen Embedding-Modellen | Nutzer |
dc: ist ein XML/RDF-Namespace (http://purl.org/dc/elements/1.1/), nötig nur in XML/RDF-Serialisierungen wie RSS/Atom, OAI-PMH oder XMP-Metadaten in PDFs. In einem flachen JSON-Metadatenobjekt für eine Vector-DB entfällt der Präfix — man übernimmt nur die Begriffsebene, nicht die Schreibweise:chunk_id, section) ergänzt. Ohne diese Vererbung verliert man nach dem Chunking den Bezug zur Quelle.department = "support") vorab eingeschränkt, bevor die kostenintensive Ähnlichkeitsberechnung läuft.snake_case für Feldnamen. Eine einheitliche Namenskonvention über alle Quellen hinweg erleichtert spätere Filter-Queries erheblich.Document.metadata) und LlamaIndex (Node.metadata) lassen bewusst freie Dicts zu. In der Praxis konvergieren aber fast alle Pipelines auf dieselbe Kernmenge: source, doc_id, chunk_id, created_at/updated_at, category/tags.