Transformers.js and embeddings: semantic search without server infrastructure

Классическая ошибка в поиске: пользователь вводит «недорогой ноутбук» — и видит пустую выдачу, потому что в базе продукт называется «бюджетный лэптоп». Machine Learning Mastery публикует подробный разбор того, как заменить keyword-поиск семантическим — используя Transformers.js и sentence embeddings прямо в браузере, без серверного бэкенда.

В чём проблема с обычным поиском Стандартный keyword-поиск сравнивает символы, а не смысл.

Если запрос и документ не совпадают буквально — результата нет, хотя слова синонимичны. Это баг, который команды воспроизводят раз за разом: добавляют синонимы вручную, правят стоп-слова, подключают ElasticSearch — и всё равно упускают нестандартные формулировки. Проблема системная. Пользователи не думают о том, как называется товар в базе: они описывают, что им нужно. «Тихий кулер», «ноут для учёбы», «телефон с хорошей камерой» — это запросы, которые keyword-движок либо не поймёт, либо вернёт нерелевантный результат. Семантический поиск решает задачу иначе: он переводит текст в числовой вектор (embedding), который отражает смысл. «Недорогой ноутбук» и «бюджетный лэптоп» окажутся в векторном пространстве рядом, потому что семантически близки. Вместо сравнения строк движок вычисляет косинусное сходство между векторами запроса и документов.

Как работает Transformers.js Transformers.js — JavaScript-порт библиотеки Hugging Face Transformers.

Она запускает языковые модели прямо в браузере или Node.js без серверного API. Модели загружаются как ONNX-веса и исполняются через WebAssembly или WebGPU.

Для семантического поиска нужны sentence embedding-модели — они обучены превращать предложения в плотные векторы фиксированной размерности. Популярный выбор для старта — `all-MiniLM-L6-v2` от Sentence-Transformers: весит около 25 МБ, не требует GPU и работает достаточно быстро для клиентского кода. Базовая архитектура поиска: Инициализируем pipeline: `pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2')` Индексируем базу: прогоняем каждый документ через модель, сохраняем векторы При запросе: векторизуем текст пользователя тем же способом Вычисляем косинусное сходство между вектором запроса и всеми векторами в индексе * Возвращаем топ-N документов с наибольшим показателем близости Для небольших баз (до нескольких тысяч записей) индекс хранится прямо в памяти или `localStorage` — никакой серверной инфраструктуры не нужно.

Плюсы и реальные ограничения Главное преимущество — нулевой бэкенд.

Всё работает на клиенте: модель скачивается один раз, эмбеддинги считаются локально. Подходит для документационных порталов, статических блогов, внутренних дашбордов и всего, что живёт без постоянного сервера. Ограничения тоже существенные. Линейный перебор O(n) начинает тормозить на десятках тысяч документов — там нужна HNSW-индексация через библиотеки вроде `hnswlib-node`. Общие embedding-модели могут ошибаться на узкоспециализированной лексике: в таких случаях лучше работает гибридный режим — BM25 для точного совпадения плюс эмбеддинги для смыслового.

Что это значит Барьер для внедрения умного поиска значительно снизился.

Раньше это требовало серверного Python-стека, векторной базы данных и отдельного API. Теперь фронтенд-разработчик может добавить семантический поиск в статический сайт за несколько строк JavaScript — и он будет работать даже офлайн.