Deutsche Texte mit spaCy sauber zu verarbeiten ist dann einfach, wenn das Modell zur Aufgabe passt. Bei Physik wird es schnell anspruchsvoller: Formeln, Einheiten, Abkürzungen und Fachbegriffe verhalten sich anders als Nachrichtentext, auf dem die offiziellen Pipelines trainiert wurden. Genau deshalb lohnt sich ein nüchterner Blick auf die verfügbaren deutschen Modelle, ihre Stärken und ihre Grenzen im echten Einsatz.
Die wichtigsten Punkte auf einen Blick
- Für Deutsch bietet spaCy aktuell vier offizielle Pipelines:
de_core_news_sm,de_core_news_md,de_core_news_lgundde_dep_news_trf. - Die drei
core_news-Modelle sind auf Nachrichtentext trainiert;mdundlgbringen zusätzlich Wortvektoren mit,smnicht. - Für Physiktexte reicht ein Standardmodell oft als Startpunkt, aber Formeln, Einheiten und Spezialabkürzungen brauchen fast immer Regeln oder Nacharbeit.
- Wenn du nur einen schnellen Baseline-Stack willst, nimm
sm; für semantische Aufgaben istmdmeist der sinnvollste Kompromiss. - Für maximale Robustheit bei Syntaxaufgaben ist das Transformer-Modell interessant, kostet aber spürbar mehr Rechenzeit und Speicher.
Was deutsche spaCy-Modelle wirklich abdecken
Die deutschen spaCy-Modelle sind keine Spezialwerkzeuge für Physik, sondern allgemeine NLP-Pipelines für deutschsprachige Texte. Sie liefern dir je nach Variante Tokenisierung, Lemmatisierung, POS-Tagging, morphologische Merkmale, Abhängigkeitsanalyse und bei den core_news-Modellen auch Named Entity Recognition. Das ist ein solider Grundstock, aber eben ein Grundstock.
Der wichtigste Punkt ist für mich die Trainingsdomäne: Die offiziellen deutschen Modelle sind auf Nachrichtentexte ausgerichtet. Das funktioniert im Fließtext oft ordentlich, aber in Fachtexten verschiebt sich die Fehlerquelle. Nicht jedes Problem ist ein Modellproblem. In Physik kommen häufig Schreibweisen vor, die ein allgemeines Sprachmodell nur halb versteht: Formeln, Indizes, griechische Buchstaben, Einheiten, Literaturverweise und zusammengesetzte Fachwörter.
- Gut abgedeckt sind normaler Satzbau, grobe Lemmata und einfache syntaktische Beziehungen.
- Teilweise abgedeckt sind Entitäten wie Organisationen, Orte oder bekannte Personen, sofern sie in den Trainingsdaten ähnlich vorkamen.
- Schwach abgedeckt sind fachliche Spezialmuster, Messgrößen, Formeln und sehr domänenspezifische Benennungen.
Genau deshalb arbeite ich bei solchen Projekten nie nur mit einem Modell, sondern immer mit einer klaren Aufgabentrennung: Was kann das Basismodell, und was muss ich mit Regeln oder zusätzlichem Training ergänzen? Von dort ist der Schritt zur Modellauswahl viel leichter.
Welche Pipeline ich für welchen Zweck wählen würde
Auf der spaCy-Modellseite für Deutsch sind aktuell vier offizielle Pipelines aufgeführt. Die Wahl ist weniger eine Glaubensfrage als eine Abwägung zwischen Geschwindigkeit, Speicherbedarf, Vektoren und Genauigkeit. Ich würde sie so einordnen:
| Modell | Stärken | Grenzen | Mein typischer Einsatz |
|---|---|---|---|
de_core_news_sm |
Klein, schnell, guter Einstieg für erste Prototypen | Keine Wortvektoren, begrenzte semantische Tiefe | Baselines, Tests, Vorverarbeitung mit engem Ressourcenbudget |
de_core_news_md |
Solider Kompromiss, zusätzlich mit Vektoren | Größer als sm, aber noch gut handhabbar |
Semantische Suche, Clustering, robuste Standardpipeline |
de_core_news_lg |
Mehr Vektoren, oft bessere Abdeckung im Alltag | Schwerer, langsamer, speicherintensiver | Wenn Qualität wichtiger ist als knappe Laufzeit |
de_dep_news_trf |
Transformer-basiert, stark bei Syntax und strukturellen Aufgaben | Rechenintensiv, im Betrieb deutlich anspruchsvoller | Anspruchsvolle Analyse, wenn Hardware und Latenz passen |
Für Physikprojekte ist meine Faustregel recht schlicht: Wenn du zuerst einen belastbaren Baseline-Workflow brauchst, nimm de_core_news_md. Wenn du auf engem Budget arbeitest, reicht sm oft für Vorverarbeitung und grobe Extraktion. Wenn du längere Texte, bessere semantische Nähe und etwas mehr Substanz bei Ähnlichkeitsaufgaben brauchst, lohnt sich lg. Und wenn du die syntaktische Robustheit wirklich ausreizen willst, schaue ich mir das Transformer-Modell an.
Wichtig ist dabei ein nüchterner Blick auf die Herkunft der Modelle: Alle vier sind auf Nachrichtentexte trainiert. Für technische oder wissenschaftliche Texte ist das kein K.-o.-Kriterium, aber es erklärt, warum der Sprung von „funktioniert“ zu „funktioniert zuverlässig im Fachkontext“ oft zusätzliche Arbeit braucht. Genau dort setzt der nächste Schritt an: saubere Installation, schneller Testlauf und dann der Abgleich mit deinem eigenen Korpus.
So installierst und lädst du ein deutsches Modell sauber
Der praktische Einstieg ist unkompliziert. Ich installiere das Modell zuerst als Paket und lade es dann in Python. Für einen ersten Test reicht das kleine oder mittlere Modell völlig aus.
python -m spacy download de_core_news_mdimport spacy
nlp = spacy.load("de_core_news_md")
doc = nlp("Die Energiedichte steigt bei kleinerem Volumen.")
for token in doc:
print(token.text, token.lemma_, token.pos_)Wenn du nur Tokenisierung brauchst oder eigene Komponenten von Grund auf aufbauen willst, ist auch eine leere deutsche Pipeline sinnvoll:
import spacy
nlp = spacy.blank("de")Das ist kein Ersatz für ein trainiertes Modell, aber ein sauberer Ausgangspunkt für Spezialpipelines. Gerade in Physikprojekten ist das nützlich, wenn du nur bestimmte Muster erkennen willst und nicht jede allgemeine Sprachfunktion benötigst. Ich achte außerdem darauf, Versionen nicht gedankenlos zu mischen: Wenn du auf eine neue spaCy-Hauptversion wechselst, solltest du die passenden Pipeline-Pakete neu einspielen, statt alte Artefakte einfach weiterzuverwenden.
Sobald das Modell läuft, zeigt sich in Physiktexten sehr schnell, wo die eigentlichen Reibungsverluste liegen: bei Tokenisierung, Einheiten, Formeln und Spezialbegriffen.
Warum Physiktexte ein anderes Datenprofil haben
Physiktexte sehen für Menschen oft klar aus, für NLP-Systeme aber überraschend fragmentiert. Ein Ausdruck wie E = hν ist sprachlich kein normaler Satzbestandteil, m/s² ist keine gewöhnliche Wortform, und ΔE oder λ verhalten sich in einem Textfluss anders als ein klassisches Lexem. Dazu kommen Abkürzungen, Bindestrichkonstruktionen, Messwerte und Mischformen aus Deutsch und Englisch.
Typische Stolperstellen
- Formeln und Gleichungen, die Token an Stellen trennen, an denen du sie eigentlich zusammenhalten möchtest.
- Einheiten und Größenangaben wie
Pa,J,kWh,m/s²oder zusammengesetzte Schreibweisen mit Leerzeichen und Sonderzeichen. - Fachbegriffe mit vielen Morphemen, etwa in der Festkörperphysik, Optik oder Quantenmechanik.
- Gemischte Schreibweisen aus Deutsch, Englisch, Symbolen und Abkürzungen, wie sie in Artikeln, Laborprotokollen und Vorlesungsunterlagen üblich sind.
Lesen Sie auch: Zeta-Potenzial - Was es wirklich über Stabilität aussagt
Was ich daran anpasse
Hier lohnt sich kein blindes Vertrauen auf das Basismodell. Ich ergänze zuerst EntityRuler, wenn ich feste Muster wie Einheiten, Konstanten, Institute oder Messreihen erkennen will. Das ist eine regelbasierte Schicht, die bekannte Muster zuverlässig markiert. Für flexible Formulierungen nutze ich Matcher; damit kann ich Textmuster für ganze Phrasen oder Strukturen definieren, ohne das Modell neu zu trainieren.
-
EntityRulerhilft bei stabilen Mustern mit klaren Schreibweisen. -
Matcherist nützlich, wenn eine Fachphrase in mehreren Varianten auftaucht. - Eigene Tokenizer-Ausnahmen sind sinnvoll, wenn Formeln oder Einheiten sonst auseinanderfallen.
- Feinjustierung mit eigenen Trainingsdaten lohnt sich erst dann, wenn dieselben Fehler immer wieder auftreten.
Ich würde Physiktexte deshalb nie nur als „deutsches NLP-Problem“ behandeln. Es ist ein Mischfall aus Sprachverarbeitung, Mustererkennung und domänenspezifischer Vorarbeit. Genau aus diesem Grund trägt ein klarer Arbeitsablauf mehr als die bloße Wahl eines größeren Modells.
Ein Arbeitsablauf, der in Projekten wirklich trägt
Wenn ich ein deutschsprachiges Physikprojekt starte, beginne ich nicht mit Training, sondern mit einem kleinen, realistischen Testset. Schon 100 bis 200 Sätze aus dem echten Zielkorpus reichen oft, um die groben Schwächen zu sehen. Für Entitäten, Formeln und Satzgrenzen zählt nicht der Eindruck, sondern das Verhalten an echten Beispielen.
- Ich starte mit
de_core_news_mdals Baseline, weil die Vektoren für viele Standardaufgaben einen spürbar besseren Ausgangspunkt liefern. - Ich prüfe Tokenisierung, Lemmata, Satzgrenzen und Entitäten auf einer kleinen Stichprobe aus echten Physiktexten.
- Ich ergänze Regeln für Einheiten, Symbole, Konstanten und wiederkehrende Fachmuster.
- Ich bewerte Fehler mit Precision, Recall und F1, statt mich auf ein Bauchgefühl zu verlassen.
- Ich trainiere erst dann nach, wenn dieselben Fehlertypen im Korpus wirklich wiederkehren.
Gerade bei Fachtexten ist eine kleine, gut gewählte Evaluationsmenge oft wertvoller als ein großes, unstrukturiertes Korpus. Wenn das Modell auf 20 zufällig ausgewählten Sätzen gut aussieht, sagt das wenig. Wenn es auf 150 echten Textsegmenten stabil arbeitet, wird es interessant.
Ich achte außerdem auf die Trennung zwischen genereller Sprachverarbeitung und domänenspezifischer Logik. Das Modell sollte möglichst viel Vorarbeit übernehmen, aber nicht gezwungen werden, alles allein zu lösen. Von dort aus geht es vor allem um langfristige Stabilität und saubere Pflege.
Worauf ich bei deutschsprachigen Physikprojekten langfristig achte
Ein gutes NLP-Setup ist nicht nur eine Frage des ersten Runs, sondern der Wartbarkeit. Fachtexte verändern sich, Quellen wechseln, und schon kleine Anpassungen am Korpus können die Qualität verschieben. Deshalb plane ich immer drei Dinge mit ein: Versionierung, Fehlerbeobachtung und Domänenanpassung.
- Versionierung: Modelle, Regeln und Trainingsdaten gehören zusammen dokumentiert, sonst ist ein späterer Qualitätsvergleich kaum möglich.
- Fehlerbeobachtung: Wiederkehrende Fehlmuster wie falsch getrennte Einheiten oder verpasste Fachentitäten sollten gesammelt werden, statt sie einzeln zu korrigieren.
- Domänenanpassung: Bei Physiktexten ist oft nicht das Sprachmodell der Engpass, sondern die fehlende Fachlogik im Umfeld des Modells.
Wenn ich heute ein deutsches Physikprojekt aufsetzen würde, würde ich fast immer mit de_core_news_md beginnen, die Ergebnisse gegen einen kleinen echten Korpus prüfen und dann gezielt Regeln ergänzen. Nur wenn die syntaktische Analyse im Vordergrund steht und genug Rechenleistung vorhanden ist, würde ich das Transformer-Modell bevorzugen. Die beste Wahl ist in solchen Projekten selten das größte Modell, sondern das Modell, das sich sauber an die eigene Aufgabe anschließen lässt.
Für die meisten Fälle ist die richtige Reihenfolge deshalb simpel: erst die Baseline stabil machen, dann die Fachmuster absichern, erst danach über Feinoptimierung nachdenken. Genau so bleibt aus einem allgemeinen deutschen NLP-Modell ein Werkzeug, das in Physiktexten wirklich verlässlich arbeitet.