Die Aufgabenstellung

Die wissenschaftliche Literatur wächst schneller, als eine Forscherin sie lesen kann, und die Fragen, auf die es ankommt, reichen über einen ganzen Bestand statt über ein Paper. Die Stichwortsuche gibt eine Rangliste zurück und überlässt der lesenden Person das Öffnen, Überfliegen, Vergleichen und Zusammensetzen. Dieses System liefert die belegte Antwort direkt und als Stream, über einen Bestand an Papern der Sprachverarbeitung, bereitgestellt von zwei Docker-Diensten.

Die Aufgabe ist eine Frage-Antwort-Aufgabe in offener Domäne über einem vorab indexierten Bestand. Zu einer Frage in natürlicher Sprache holt das System die 7 besten Textstellen aus einem Index mit etwa 47 800 Chunks auf FAISS und BM25 (aus den 888 Papern des Trainings-Splits von QASPER, das 5 049 Fragen zu 1 585 Papern der Sprachverarbeitung enthält) und schreibt dann mit einem lokalen Modell eine belegte Antwort mit Quellenangabe.

Die Architektur der Anwendung

Der Stack besteht aus 2 Diensten unter Docker Compose: einem FastAPI-Backend auf Port 8080 und einer Chainlit-Chatoberfläche auf Port 8001. Beide Container laufen mit network_mode: host, was dem Backend direkten Zugriff auf Ollama auf dem Host gibt. Das Frontend wartet auf ein Backend, das seine Health-Prüfung bestanden hat (condition: service_healthy), fragt /health alle 30 Sekunden ab und räumt eine Startphase von 300 Sekunden ein, damit der Download der Artefakte beim ersten Start durchläuft.

Die FAISS-Indizes liegen bei etwa 230 MB (dense.index bei 147 MB, die Metadaten bei 31 MB, sparse.pkl bei 51 MB). gdown holt sie beim ersten Start von Google Drive. compose.yml bindet dafür kein Volume ein, also laden sie neu, sobald der Container neu erstellt wird. Das Backend erkennt CUDA und wählt HuggingFace Transformers auf der GPU oder Ollama auf der CPU, ohne dass jemand die Konfiguration ändert.

Die RAG-Pipeline in 4 Stufen

Stufe 1. Hybrides Retrieval. Die dichte FAISS-Suche (SPECTER2-Embeddings, 768 Dimensionen, ein flacher Inner-Product-Index) wird mit der dünnbesetzten BM25-Suche über Reciprocal Rank Fusion (k=60) verschmolzen. Die Anwendung behält die 50 besten Kandidaten.

Stufe 2. ColBERT-v2-Reranking. Die Token-Embeddings der Dokumente entstehen offline, also kostet die Anfragezeit nur ein MaxSim über Token-Embeddings. Das erkauft die Genauigkeit eines Cross-Encoders im Maßstab des Retrievals und schneidet die besten 50 auf die besten 7 herunter.

Stufe 3. Das CRAG-Gate. Die CRAG-Prüfung (Yan et al., 2024) kennzeichnet jede Textstelle als Correct, Ambiguous oder Incorrect. Besteht keine Textstelle, greift das Backend auf die besten 3 zurück und antwortet trotzdem, statt abzulehnen.

Stufe 4. Generierung im Stream. Auf einer GPU führt HuggingFace Transformers Llama-3.1-8B-Instruct aus. Ohne GPU führt Ollama Llama 3 aus. Das Modell schreibt ein kurzes Reasoning und dann eine endgültige Antwort mit Zitaten [Doc N] im Text und 6 Runden Gesprächsgedächtnis. Eine asynchrone Warteschlange schiebt die Tokens an einen NDJSON-Streaming-Endpunkt.

Die CI/CD-Pipeline

Jeder Push auf master startet einen GitHub-Actions-Workflow, der sich mit dem automatischen GITHUB_TOKEN bei GHCR anmeldet, also ohne zu verwaltende Secrets, und danach beide Docker-Images unter 2 Tags baut und pusht: :latest und :sha-<commit>. Das Backend-Image klont die Forschungs-Pipeline an einem festen Commit. compose.yml zieht das Frontend-Image aus GHCR und baut das Backend lokal.

Die Evaluation

Die Evaluation liegt im Forschungs-Repository, an 150 QASPER-Fragen, geprüft gegen von Menschen markierte Belege. Im Referenzlauf vom 2026-09-02 lag die ALCE-Zitationsgenauigkeit bei 0,654 und der Recall bei 0,674, mit 128 von 150 beantworteten Fragen. Die Korrektur des Bewertungscodes zählte so viel wie die Pipeline selbst: Genauigkeit und Recall teilten sich einen Nenner und stimmten deshalb in jeder bewerteten Zeile überein. Die vollständige Studie, samt der Gewinne beim Beleg-Recall durch indexierte Tabellen, steht auf der Seite des hybriden RAG-Projekts.

Die Wirkung

• Fertige Images. Die CI veröffentlicht die Images von Backend und Frontend bei jedem Push in GHCR. compose.yml zieht das Frontend-Image und baut das Backend, das seine Indizes beim ersten Start von Google Drive lädt, also keine Python-Umgebung anzulegen und kein Index von Hand herunterzuladen. Der CPU-Modus braucht Ollama auf dem Host.
• Läuft auf der CPU. Das Ollama-Backend arbeitet auf gewöhnlicher Hardware, mit etwa 2 bis 5 Tokens pro Sekunde.
• Nachvollziehbares Reasoning. Jede Antwort zeigt ihren Reasoning-Block vor der endgültigen Antwort, damit die lesende Person die Logik dahinter prüfen kann.
• Rückfragen funktionieren. 6 Runden Gedächtnis ersparen es, den Kontext erneut zu nennen.