Wie ich einen russischen Embedder auf 24 Millionen Parameter schrumpfte – und mit einer Ziffer fast ruinierte

Der Autor entwickelte einen kleinen russischen dichten Retriever namens STRIZH für ein lokales RAG-System, das auf einem AMD-Strix-Halo-Knoten mit 128 GB Unified Memory läuft. Die iGPU des Knotens wird von dem generativen LLM, dem Embedder, dem Reranker und der periodischen Neuindizierung gemeinsam genutzt, daher ist ein leichtgewichtiger Retriever erforderlich, um die Rechenkonkurrenz zu verringern. Nach einem fehlgeschlagenen Versuch der Embedding-Regression mit MSE-Verlust trainierte der Autor erfolgreich ein Retrieval-Spendermodell mit 12 Schichten unter Verwendung von kontrastivem Lernen und destillierte es dann auf 4 Schichten. STRIZH hat 24,4 Millionen Parameter, eine Vektorgröße von 384, Mean Pooling, keine Query-/Passage-Präfixe und unterstützt Kontext bis zu 8192 Token. Auf einem lokalen Korpus erreichte es Recall@10 von 0,751 auf einer gefilterten Teilmenge und 0,800 auf der vollständigen Menge. In Co-Residenz-Benchmarks mit Qwen3.6-35B-A3B verursachte STRIZH nur einen Produktionsdurchsatzabfall von 2 % gegenüber 7 % bei bge-m3 bei einer Online-Last von 200 Abfragen pro Sekunde und indizierte 46 Batches pro Sekunde gegenüber 4,9. Allerdings wurde nach der Veröffentlichung ein Fehler entdeckt: Die Tokenizer-Konfiguration hatte model_max_length=256, was, wenn es durchgesetzt wurde, zu einem Rückgang des Recall@10 von 0,589 auf 0,448 führte. Der Autor merkt an, dass STRIZH nicht dazu gedacht ist, größere Modelle wie USER2-small oder bge-m3 zu ersetzen, sondern eine Nische für effizientes dichtes Retrieval unter strengen Rechenbudgets zu füllen.