Опубликован проект STRIZH — компактный dense-эмбеддер на 24,4 млн параметров, предназначенный для русского RAG на одноузловых конфигурациях, где генеративная LLM, реранкер и индексация конкурируют за ресурсы одного GPU. Исходной проблемой стало то, что на узле AMD Strix Halo с 128 ГБ unified memory вычислительное время GPU является узким местом, а не объём памяти. Тяжёлые эмбеддеры вроде bge-m3 при фоновой переиндексации снижали throughput генерации на 92%, тогда как STRIZH — всего на 28%, при этом скорость индексации была в 12,6 раза выше. В полном RAG-конвейере с четырьмя пользовательскими потоками STRIZH поддержал 14,0 транзакций в минуту против 6,0 у bge-m3, а при фиксированных 200 онлайн-запросах в секунду генерация просела лишь на 2% против 7%. Примечательно, что без фоновой индексации STRIZH преимущества не показал — в этом профиле bge-m3 оказался немного быстрее, а пропускную способность определяли реранк, prefill и генерация.

Технически STRIZH построен на базе RuModernBERT-small: взято 12 слоёв, затем после неудачной попытки повторить пространство учителя через MSE модель была обучена retrieval-донору на контрастивной задаче, из него отобраны четыре слоя [0, 5, 9, 11] и доучен student на русских, английских и смешанных парах с hard negatives от BGE-M3. Итоговый эмбеддер использует mean pooling, L2-нормированный вектор размерности 384 и не требует обязательных query/passage-префиксов. Архитектура поддерживает контекст до 8192 токенов, хотя обучение велось на последовательностях длиной до 256 токенов. На прогретом рантайме llama.cpp/Vulkan (Strix Halo, concurrency 16) модель обрабатывает около четырёх тысяч коротких запросов в секунду, при этом Recall@10 на отфильтрованной подвыборке составил 0,751, а на полном локальном наборе — 0,800.

Зачем понадобился ультралёгкий эмбеддер? Проектная топология предполагает размещение на одном iGPU генеративной LLM, dense-поиска, реранкера и периодической переиндексации корпуса. Даже несколько сотен мегабайт bge-m3 при параллельной работе создают заметную конкуренцию за compute, особенно во время индексации. Замеры показали, что одной онлайн-нагрузки недостаточно для высокой конкуренции — она проявляется именно при фоновой индексации. Поэтому автор сформулировал требования: меньше 30 млн параметров, основной язык русский, dense single-vector retrieval, работа без обязательных префиксов, mean pooling, поддержка GGUF и llama.cpp/Vulkan, качество заметно выше rubert-tiny2, при этом английский и смешанный текст не должны полностью развалиться. Готовые альтернативы, такие как USER2-small, multilingual-e5-small и тот же bge-m3, качественнее, но STRIZH не призван их заменить — он оптимизирован для другого режима: русского RAG на общем GPU с жёстким ограничением на стоимость первой стадии поиска.

Сразу после публикации модели разработчик обнаружил критическую ошибку: в файле tokenizer_config.json осталось значение model_max_length=256. При принудительном обрезании входов до 256 токенов Recall@10 упал с 0,589 до 0,448, то есть на 14,1 процентного пункта, опустившись до уровня rubert-tiny2. Таким образом, одна цифра в конфиге почти полностью обесценила всю работу. Эта ошибка демонстрирует, насколько критична правильная настройка длины последовательности для retrieval-задач, особенно для моделей, рассчитанных на длинные документы. Корректная архитектура STRIZH поддерживает до 8192 токенов, но финальные обучающие прогоны проводились с max_seq_length=256, что может ограничивать качество на длинных текстах, хотя автор отмечает, что качество измерялось на входах до ~1024 токенов и способность обрабатывать 8192 остаётся непроверенной.

Для российского рынка локальных RAG-систем STRIZH представляет интерес как пример эффективного сжатия модели под конкретное аппаратное ограничение. В условиях, когда производители оборудования, такие как AMD, продвигают универсальные решения с большой unified memory, но ограниченной вычислительной мощностью GPU, компактный эмбеддер позволяет развернуть полноценный RAG-конвейер на одном узле без существенной деградации качества. Важно, что STRIZH является открытым проектом — это даёт возможность российским разработчикам адаптировать модель под свои задачи, дообучать на собственных данных и интегрировать в существующие инфраструктуры. Кроме того, ошибка с длиной последовательности служит ценным уроком для сообщества: даже небольшая оплошность в конфигурации может нивелировать все преимущества компактной архитектуры, поэтому к аудиту таких параметров нужно подходить особенно тщательно. Учитывая тренд на импортозамещение и использование доступного оборудования, подобные лёгкие эмбеддеры могут стать основой для многих корпоративных и исследовательских RAG-решений в России.

Перспективы проекта связаны прежде всего с устранением обнаруженного недостатка и проведением полноценного near-duplicate аудита, чтобы подтвердить отсутствие утечки данных в evaluation. Открытым остаётся вопрос точности модели на длинных последовательностях до 8192 токенов, а также масштабируемость на другие GPU и операционные системы. В сообществе разработчиков RAG-систем STRIZH может стать эталоном для ситуаций, когда важна скорость первой стадии поиска ценой небольшого снижения абсолютного качества. Решение опубликовано в открытом доступе, что позволит другим исследователям повторить методику сжатия и адаптировать её под свои задачи. В более широком контексте STRIZH демонстрирует, что даже при жёстких ограничениях на вычислительные ресурсы можно получить практичную retrieval-модель, если правильно расставить приоритеты между качеством и пропускной способностью — этот баланс особенно актуален для российских организаций, где доступ к мощным GPU может быть ограничен.