EmoLLM: ein Fine-Tuning-Baukasten für psychologische Beratungsdialoge

Welches Problem die Konfigurationssammlung löst

Ein Basismodell wie InternLM2_5_7B_chat antwortet auf die Bitte um Rat mit allgemeinen Floskeln. Wer es auf psychologische Beratung ausrichten will, braucht drei Dinge: einen Dialogdatensatz mit der richtigen Tonalität, eine Trainingskonfiguration, die auf die Modellarchitektur passt, und eine Evaluation, die nicht nur den Trainingsverlust misst. EmoLLM liefert genau diese drei Teile als Repository. Die Zielgruppe sind Entwickler, die bereits Zugang zu einer GPU mit ausreichend VRAM haben und wissen, was QLoRA bedeutet. Das README beschreibt die Kette als verstehen, unterstützen, helfen und ordnet das Projekt damit als Gesprächsassistenz ein, nicht als Diagnosewerkzeug. Wer eine fertige API sucht, ist hier falsch; das Repository ist eine Trainings- und Deployment-Vorlage.

Sechzehn Konfigurationen und was sie unterscheidet

Das README listet eine Tabelle mit Modell, Trainingsart und Konfigurationspfad. Die Spanne reicht von InternLM2_1_8B_chat mit Vollfeintuning über Qwen1_5-0_5B-Chat bis zu Mixtral 8x7B_instruct mit QLoRA. Jede Zeile verweist auf eine Datei unter xtuner_config/, etwa internlm2_5_chat_7b_qlora_oasst1_e3.py oder chatglm3_6b_lora_alpaca_e3.py. Das ist der eigentliche Inhalt des Projekts: keine eigene Trainingsbibliothek, sondern Parameterdateien für XTuner, den Fine-Tuning-Rahmen aus dem InternLM-Umfeld. Die Dateinamen kodieren bereits die wichtigsten Entscheidungen. qlora bedeutet 4-Bit-Quantisierung der Gewichte, lora bedeutet Adapter ohne Quantisierung, full bedeutet vollständiges Feintuning. Wer die Konfiguration für Baichuan2_13B_chat öffnet, sieht andere Zielmodulnamen als bei LLaMA3_8B_instruct, weil die Attention-Schichten anders heißen. Das ist der konkrete Nutzen: die Portierungsarbeit zwischen Modellfamilien ist bereits erledigt.

Datenfluss vom Datensatz zum Adapter

Der Ablauf folgt dem XTuner-Muster. Ein Datensatz im Alpaca- oder OASST1-Format wird über einen Pfad in der Konfigurationsdatei referenziert, der Tokenizer des Basismodells verarbeitet die Dialoge, und das Training schreibt entweder einen LoRA-Adapter oder ein vollständiges Checkpoint-Verzeichnis. Die Dateinamen der Konfigurationen nennen die Herkunft des Datensatzes: oasst1 bei den InternLM2_5- und DeepSeek-MoE-Varianten, alpaca bei den ChatGLM3- und Baichuan2-Varianten. EmoLLM bringt daneben eigene Datensätze und Evaluationsroutinen mit, die das Repository unter eigenen Verzeichnissen führt. Nach dem Training folgt die Zusammenführung von Adapter und Basismodell, danach die Konvertierung in ein Format, das die Inferenz-Engine laden kann. Für die Auslieferung verweist das README auf eine OpenXLab-Anwendung mit der Bezeichnung EmoLLMV3.0 sowie auf ModelScope-Repositories für einzelne Gewichte. Der Datenfluss endet also nicht beim Checkpoint, sondern schließt eine Weboberfläche ein.

Installation und Training: die realen Befehle

Das README gibt für den Einstieg die üblichen Schritte vor: Repository klonen, eine virtuelle Umgebung anlegen, dann XTuner und die modellspezifischen Abhängigkeiten installieren. Das Training selbst läuft über xtuner train mit dem Pfad zur Konfigurationsdatei, also etwa xtuner train ./xtuner_config/internlm2_5_chat_7b_qlora_oasst1_e3.py. Die Konfiguration enthält die Schlüssel für Batch-Größe, Lernrate und Sequenzlänge; genau diese Werte unterscheiden sich zwischen den Dateien. Ein Beispiel aus dem Dateinamen internlm2_7b_base_qlora_e10_M_1e4_32_64.py: e10 steht für zehn Epochen, 1e4 für eine Lernrate von 1e-4, 32 und 64 für Batch-Größe und Akkumulationsschritte. Wer diese Konvention einmal verstanden hat, kann die Konfigurationen ohne Blick in die Datei vergleichen. Für die Inferenz nach dem Training verweist das README auf LMDeploy und auf eine Gradio-Oberfläche im Repository. Diese Angaben stammen aus dem README; ich habe keinen dieser Befehle ausgeführt.

Wo das Projekt an seine Grenzen stößt

Der wichtigste Vorbehalt steht nicht im Repository, sondern ergibt sich aus seinem Zuschnitt. EmoLLM ist eine Sammlung von Trainingsrezepten, kein evaluiertes Produkt. Das README beschreibt die Fähigkeiten des Modells als Verstehen, Unterstützen, Helfen, liefert aber in dem vorliegenden Ausschnitt keine Zahlen zu Fehlantworten, zu gefährlichen Ratschlägen oder zum Verhalten bei Hinweisen auf Selbstgefährdung. Für ein System, das Menschen in psychischen Krisen begleiten soll, ist das die entscheidende Lücke. Ein weiterer Vorbehalt ist technischer Natur: Die Konfigurationen binden an XTuner und an dessen Versionsstand. Wer eine andere Trainingsbibliothek nutzt, kann die Dateien als Referenz lesen, aber nicht direkt verwenden. Die Qualität der resultierenden Modelle hängt außerdem stark vom verwendeten Datensatz ab, und das README macht nicht durchgängig transparent, welcher Datensatz hinter welcher veröffentlichten Gewichtsdatei steht. Bei einem sensiblen Anwendungsfeld ist das ein Mangel.

Was EmoLLM von einem RAG-Ansatz unterscheidet

Der naheliegende Vergleich ist ein Retrieval-Augmented-Generation-System auf Basis eines allgemeinen Chatmodells. Der Unterschied liegt im Angriffspunkt. RAG lässt die Gewichte unverändert und schiebt relevante Textabschnitte in den Kontext; das Modell bleibt ein Allrounder, dessen Tonfall sich nicht ändert. EmoLLM verändert die Gewichte durch Fine-Tuning und prägt damit den Gesprächsstil selbst. Das ist teurer und schwerer zu aktualisieren: Wer den Tonfall ändern will, muss neu trainieren, während ein RAG-System nur eine neue Dokumentenversion braucht. EmoLLM adressiert das, indem das README RAG als eigenen Bestandteil neben Vortraining, Nachtraining, Datensatz, Evaluation und Deployment aufführt. Beide Verfahren schließen sich also nicht aus. Für Wissensfragen zu Therapieverfahren ist RAG das passendere Werkzeug, für die Grundhaltung im Dialog das Fine-Tuning.

Pflegeaufwand, Lizenz und was vor dem Einsatz zu prüfen ist

Das Repository steht unter der MIT-Lizenz, was die kommerzielle Nutzung des Codes erlaubt. Diese Lizenz gilt aber nur für den Code in diesem Repository, nicht automatisch für die Basismodelle. InternLM, Qwen, Baichuan, LLaMA und ChatGLM haben eigene Lizenzbedingungen, die teils Nutzungsbeschränkungen enthalten; vor einem produktiven Einsatz ist das für das konkret gewählte Basismodell zu klären. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stelle, an der man nachsehen muss. Der Pflegeaufwand ergibt sich aus der Zahl der Konfigurationen: Sechzehn Varianten bedeuten sechzehn Stellen, an denen eine Änderung an XTuner oder am Tokenizer nachgezogen werden muss. Die Release-Historie zeigt drei Veröffentlichungen zwischen Oktober 2024 und Mai 2025, wobei die jüngste als v0.6 datiert ist. Ob alle Konfigurationen denselben Stand haben, lässt sich aus dem Repository-Ausschnitt nicht beurteilen.

Redaktionelles Fazit

Wer bereits mit XTuner arbeitet und chinesischsprachige Beratungsdialoge fine-tunen will, findet hier fertige Konfigurationsdateien und einen dokumentierten Datenpfad. Wer ein produktionsreifes Beratungssystem sucht, sollte zuerst prüfen, ob das Repository überhaupt Evaluationsergebnisse zu Sicherheitsgrenzen und Fehlantworten enthält, bevor er eine der Modellgewichte einsetzt.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. SmartFlowAI/EmoLLM on GitHub