← Neueste Arbeiten
💬 NLP

RAGAL: A Frugal, Fully Local Retrieval-Augmented Assistant for Technical Support at a Government Agency

Dieses Paper präsentiert RAGAL, einen vollständig lokalen, ressourcenbeschränkten Retrieval-Augmented Assistant für eine rumänische Regierungsbehörde, der durch die Priorisierung von Retrieval-Engineering und Embedder-Feinabstimmung gegenüber größeren Generatormodellen eine hohe Leistung bei sensiblen Daten erzielt, während er neuartige Techniken wie Anchor Distillation zur Vermeidung von SQL-Halluzinationen sowie einen CPU-basierten Offline-Judge zur Bewertung von Ausgaben ohne Cloud-Abhängigkeiten einführt.

Ursprüngliche Autoren: Dan Musetoiu

Veröffentlicht 2026-07-22
📖 8 Min. Lesezeit🧠 Tiefgang

Ursprüngliche Autoren: Dan Musetoiu

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten einen superintelligenten Roboter-Bibliothekar, der Millionen von Büchern lesen und jede Frage beantworten kann, die Sie ihm stellen. Normalerweise müssen Sie, um diesen Roboter zum Arbeiten zu bringen, Ihre Fragen und die Bücher an ein riesiges, cloudbasiertes Gehirn in einem fernen Rechenzentrum senden. Aber was, wenn Ihre Bibliothek topgeheime Regierungsakten enthält, die es illegal ist, das Gebäude zu verlassen? Was, wenn Sie die Cloud überhaupt nicht nutzen können? Dies ist das Rätsel, das im Herzen von Retrieval-Augmented Generation (RAG) liegt. Betrachten Sie RAG als einen zweistufigen Tanz: Zuerst scannt der Roboter schnell einen spezifischen Stapel von Dokumenten, um die relevantesten Seiten zu finden (Retrieval); zweitens nutzt er diese Seiten, um eine kluge, präzise Antwort zu schreiben (Generation). Die große Frage für viele Organisationen ist: Können wir diesen Roboter vollständig innerhalb unserer eigenen Mauern bauen, unter Verwendung eines einzigen, bescheidenen Laptops, ohne jemals ein einziges Byte an Daten in die Außenwelt zu senden?

Dieses Papier erzählt die Geschichte von RAGAL, einem Projekt einer rumänischen Regierungsbehörde, das genau einen solchen Roboter gebaut hat. Sie standen vor drei unmöglich klingenden Regeln: Keine Daten durften jemals das Gebäude verlassen, der Roboter durfte Antworten nur entwerfen (Menschen mussten auf den „Senden“-Knopf drücken), und sie mussten dies alles auf einem handelsüblichen Laptop mit nur 8 GB Arbeitsspeicher erledigen. Anstatt aufzugeben, verwandelten sie dieses „frugale“ Setup in ein Labor für kluge Ingenieurskunst. Sie entdeckten, dass das Geheimnis des Erfolgs nicht darin bestand, ein größeres, teureres Gehirn zu kaufen, sondern dem Roboter beizubringen, wie er Informationen besser sucht. Durch die Feinabstimmung ihrer Suchmaschine auf echte Support-Tickets und die Verwendung eines cleveren Tricks namens „Anchor Distillation“, um zu verhindern, dass der Roboter gefälschte Datenbankbefehle erfindet, schufen sie ein System, das sicher und effektiv arbeitet. Sie bauten sogar einen „Zeitlupen-Richter“ – ein massives KI-Modell, das so langsam auf ihrer CPU läuft, dass es nicht in Echtzeit chatten kann, aber perfekt geeignet ist, um die Hausaufgaben des Roboters über Nacht zu bewerten. Das Ergebnis ist ein Bauplan dafür, wie jede Organisation mit strengen Datenschutzregeln einen hilfreichen KI-Assistenten bauen kann, ohne jemals die Cloud zu benötigen.

Die Geschichte von RAGAL: Ein Roboter, der niemals das Haus verlässt

Lernen Sie RAGAL kennen, den neuen Assistenten für eine rumänische Regierungsbehörde, die ländliche Investitionsfonds verwaltet. Diese Behörde bearbeitet täglich tausende von sensiblen Dokumenten und Support-Tickets. Da diese Dateien private Bürgerdaten enthalten, ist es strengstens untersagt, dass sie das Gebäude der Behörde verlassen. Das bedeutet, dass sie die üblichen, leistungsstarken KI-Tools, die in der Cloud leben, nicht nutzen konnten. Sie mussten ihren eigenen „vollständig lokalen“ Roboter bauen, und zwar auf einem einzigen Laptop mit einer Grafikkarte, die nur über 8 GB Speicher verfügt – eine winzige Menge nach KI-Standards.

Das Team musste drei strikte Regeln befolgen, die sie „Constraints“ nennen:

  1. Null Egress: Kein einziges Stück Daten durfte jemals das Gebäude verlassen. Keine Fragen an die Cloud senden, keine Trainingsdaten aus dem Internet herunterladen. Alles musste auf ihrer eigenen Hardware stattfinden.
  2. Nur Lesen: Der Roboter war ein Schreiber, kein Akteur. Er konnte SQL-Code entwerfen (Anweisungen zur Behebung von Datenbankfehlern) oder Erklärungen schreiben, aber er konnte diese Befehle niemals tatsächlich ausführen. Ein Mensch musste sie prüfen und ausführen.
  3. Frugalität: Das gesamte System wurde auf einem handelsüblichen Laptop entwickelt, trainiert und getestet.

Die große Entdeckung: Besseres Suchen schlägt größeres Gehirn

Das Team begann mit einer verbreiteten Annahme: Um bessere Antworten zu erhalten, benötigt man ein größeres, klügeres KI-Modell. Doch sie fanden schnell heraus, dass das falsch war. Ihr erster großer Sieg kam nicht durch die Aufrüstung des „Gehirns“ (des Generators), sondern durch die Aufrüstung der „Suchmaschine“ (des Retrievers).

Sie erkannten, dass es nicht ausreichte, den Roboter einfach nur nach Dokumenten suchen zu lassen. Sie mussten ihm beibringen, wie er sucht. Sie bauten ein Hybrid-Suchsystem, das zwei Methoden kombinierte: eine „dichte“ Suche, die die Bedeutung von Wörtern versteht, und eine „dünne“ Suche, die nach exakten Schlüsselwortübereinstimmungen sucht. Sie fügten auch einen „Verkehrspolizisten“ (Intent Routing) hinzu, der entscheidet, welche Art von Dokument gesucht werden soll, basierend auf der Frage. Wenn Sie nach einem Verfahren fragen, sucht er in Handbüchern; wenn Sie nach einer Datenbankkorrektur fragen, sucht er in alten Support-Tickets.

Diese einfache Änderung war ein massives Upgrade. Vor jedem aufwendigen Training steigerte diese Hybrid-Suche ihre Erfolgsquote von 62 % auf 81 %. Es war die günstigste und effektivste Verbesserung, die sie vornahmen.

Das 8-GB-Wunder: Training auf einem Laptop

Die nächste Herausforderung war das Training der Suchmaschine auf ihren eigenen Daten. Sie hatten etwa 15.000 gelöste Support-Tickets und interne Dokumente. Sie wollten die Suchmaschine lehren, die spezifische Sprache ihrer Behörde zu verstehen.

Normalerweise erfordert das Training eines Modells wie dieses einen massiven Supercomputer. Aber das Team hatte nur 8 GB Speicher. Sie entdeckten eine versteckte Falle: Auf ihrem Windows-Laptop würde der Grafikkartentreiber Daten lautlos in den regulären Computerspeicher „auslagern“, wenn der Platz knapp wurde, was das Training unglaublich langsam machte, ohne jemals abzustürzen. Es war, als würde man versuchen, einen Marathon mit einem Rucksack voller Wasser zu laufen, von dem man gar nicht wusste, dass man ihn trägt.

Um dies zu beheben, nutzten sie ein spezielles Rezept:

  • 8-Bit-Optimizer: Eine Methode, um die Mathematik, die der Computer berechnen muss, zu verkleinern.
  • Gradient Checkpointing: Eine Technik, die Speicher spart, indem sie einige Schritte neu berechnet, anstatt sie zu speichern.

Mit diesen Tricks gelang es ihnen, ihre Suchmaschine in nur 72 Minuten auf diesem einzelnen Laptop vollständig zu trainieren. Die Ergebnisse waren beeindruckend: Die Fähigkeit, das richtige Dokument unter den Top 10 Ergebnissen zu finden (Recall@10), sprang von 0,663 auf 0,850.

Die stille Falle: Eine Domäne, zwei Welten

Hier wird die Geschichte knifflig. Als sie die Suchmaschine nur auf den Support-Tickets trainierten, wurde sie wirklich gut darin, Tickets zu finden. Aber auf eine stille und unsichtbare Weise wurde sie schlechter darin, die offiziellen Dokumente zu finden. Das Training hatte das Verständnis der Suchmaschine „deformiert“ und dazu geführt, dass sie vergaß, wie man mit den formalen Dokumenten umgeht.

Sie entdeckten dies erst, weil sie ein separates Testset speziell für Dokumente erstellt hatten. Hätten sie das nicht getan, hätten sie geglaubt, ihr System sei perfekt, während es in Wirklichkeit bei der Hälfte ihrer Daten versagte. Um dies zu beheben, ohne Daten in die Cloud zu senden, nutzten sie einen cleveren Trick namens GenQ. Sie verwendeten eine lokale KI, um fiktive Fragen für ihre Dokumente zu generieren, wodurch sie einen neuen Trainingsdatensatz schufen, der beide Welten ausbalancierte. Dies reparierte den Schaden, und die Suchmaschine war nun wieder großartig darin, sowohl Tickets als auch Dokumente zu finden.

Sicherheit geht vor: Den Roboter am Lügen hindern

Da der Roboter Datenbankbefehle entwarf, musste das Team sicherstellen, dass er niemals Dinge erfindet (Halluzinationen). Sie verwendeten eine Technik namens Anchor Distillation. Anstatt die KI den SQL-Code von Grund auf neu schreiben zu lassen, nahmen sie echten, funktionierenden Code aus vergangenen Tickets, kopierten ihn exakt und ließen die KI nur den Text um ihn herum schreiben (erklären, was er tut und wann man ihn verwendet). Dies machte es unmöglich, dass der Roboter gefälschte Datenbankbefehle erfand, da der Code selbst ein echter, verifizierter „Anker“ war.

Sie fanden auch einen überraschenden Vorteil beim Maskieren von PII (Verbergen von Namen und Identifikationsnummern). Als sie echte Namen durch Platzhalter wie <user> oder <project_id> ersetzten, bevor sie das Training starteten, schrieb der Roboter tatsächlich bessere Antworten. Er hörte auf, Namen spezifischer Personen aus alten Tickets zu kopieren, und begann statndessen, flexible Vorlagen zu schreiben, die für jeden verwendet werden konnten.

Der langsame Richter

Wie bewertet man schließlich einen Roboter, wenn man keine Cloud-basierte KI zur Kontrolle seiner Arbeit nutzen kann? Das Team baute einen „langsamen Richter“. Sie verwendeten ein massives KI-Modell (744 Milliarden Parameter), das zu groß war, um schnell zu laufen. Es lief auf der Hauptprozessor (CPU) ihres Computers anstatt auf der Grafikkarte und bewegte die Daten während des Prozesses vom Datenträger. Es war unglaublich langsam und benötigte etwa 10 bis 13 Minuten, um eine einzige Antwort zu bewerten. Aber weil es so intelligent war, war es perfekt geeignet, um die Hausaufgaben des Roboters über Nacht zu bewerten.

Sie fanden heraus, dass dieser langsame Richter eine gute „Zweitmeinung“ war, aber nicht perfekt. Er widersprach manchmal menschlichen Experten, insbesondere bei den sehr besten oder sehr schlechtesten Antworten. Die Lektion war, den Richter zu nutzen, um Trends und Muster zu finden, aber immer eine menschliche Fachkraft zur Überprüfung der spezifischen Urteile hinzuzuziehen.

Das Fazit

Das RAGAL-Projekt beweist, dass man keinen Supercomputer oder die Cloud benötigt, um einen leistungsstarken, sicheren KI-Assistenten zu bauen. Indem man sich auf kluge Ingenieurskunst konzentriert – bessere Suchstrategien, sorgfältige Datenhandhabung und strikte Sicherheitsregeln – kann ein kleines Team mit einem einzigen Laptop ein System schaffen, das die Privatsphäre respektiert und echten Wert liefert. Sie haben gezeigt, dass der beste Weg, voranzukommen, manchmal darin besteht, langsamer vorzugehen, alles lokal zu halten und sehr genau auf die Details zu achten.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →