RAG с малой моделью прямо в браузере

Разработчик под ником из сообщества Lobsters реализовал полноценный конвейер retrieval-augmented generation (RAG) целиком в браузере: поиск по собственному блогу выполняется через 4-мегабайтную таблицу поиска, а найденные фрагменты суммирует небольшая языковая модель, работающая на GPU или CPU пользователя. Сервер, API-ключ и учётная запись не нужны — всё, что вводит пользователь, не покидает его машину. Проект получил название «ask my blog».

Поиск сначала показывает четыре наиболее релевантных фрагмента в виде карточек, а модель формирует резюме в двух предложениях поверх них. Загрузка модели происходит только по явному клику, поскольку требует скачивания нескольких сотен мегабайт с Hugging Face; браузер кэширует файл, и предусмотрена кнопка очистки кэша. Автор сознательно ограничил бюджет размером в несколько сотен мегабайт, чтобы страница оставалась доступной для читателей с мобильным интернетом.

Среди кандидатов с готовыми сборками ONNX для браузера рассматривались SmolLM2 (135M и 360M параметров), Gemma 3 270M, LFM2.5-350M, Qwen2.5-0.5B и Qwen3-0.6B. Для сравнения добавлены две модели, которые никогда не попали бы на страницу: Gemma 4 E2B со скачиванием 3,1 ГБ и Claude Haiku 5.5 через API. Автор также отметил неочевидную деталь: у ряда моделей 4-битная сборка q4 оказалась больше q4f16, поскольку экспорт q4 хранит таблицу эмбеддингов в полной 32-битной точности — например, SmolLM2-360M весит 390 МБ в q4 против 275 МБ в q4f16 при идентичном выводе.

Для оценки качества использованы 30 вопросов из предыдущего теста семантического поиска, переформулированных как реальные вопросы, плюс 15 вопросов, на которые блог заведомо не отвечает. Большинство из них — «почти попадания», провоцирующие модель на правдоподобные, но неверные ответы: про GPU для Llama 70B, про BM25 и TF-IDF, про дообучение Kokoro. Каждая модель получала одинаковые четыре фрагмента и один промпт, а оценку достоверности ответов проводил Opus 5.5; 20 из этих оценок автор проверил вручную и согласился с судьёй в 16 случаях.

Результат оказался неутешительным: ни одна готовая модель размером менее 350 МБ не пригодна для этой задачи. Они достоверны максимум в трёх случаях из тридцати и охотно отвечают почти на любой вопрос — так, SmolLM2-360M посоветовала для Llama 70B карты NVIDIA GTX 960 или 970, Gemma 3 270M назвала «RTX 3090, RTX 3080, 3070M», а LFM2.5-350M упомянула «TensorRT 60+». Только Gemma 4 E2B корректно заявила, что в предоставленных фрагментах нет информации о выборе GPU.

Модели ошибаются и на вопросах, на которые блог отвечает: LFM2.5 описала фильтр Блума как хеш-таблицу, хотя это битовый массив. Автор признаёт, что поиск не передал модели нужный раздел — четыре фрагмента касались сценариев использования и демо, а не устройства фильтра, поэтому качество резюме ограничено качеством найденных пассажей. По умолчанию проект загружает Qwen3-0.6B: при 579 МБ она выходит за изначальный бюджет, но остаётся самой маленькой моделью, дающей достоверный ответ хотя бы в половине случаев, тогда как меньшие варианты почти гарантированно проваливаются.

Отдельная проблема — зацикливание: SmolLM2-135M повторяла «Search from your URL bar», а Gemma 3 270M выдала строку из пятёрок до исчерпания токенов. Штраф за повторения (1,15) устраняет зацикливание, но не повышает достоверность — модели просто начинают писать более разнообразный бессмысленный текст. Идея с порогом релевантности работает для далёких вопросов вроде рецепта хлеба (0,25 против порога 0,45), но «почти попадания» набирают 0,54–0,63 и проходят фильтр, так что автору ещё предстоит доработать ранжирование в своём поисковике.