Почему поиск по ключевым словам теряет упоминания

Классический мониторинг строится на словаре: название бренда, торговые марки, типовые опечатки. Такой подход ловит прямые вхождения, но пропускает описательные конструкции — «их колонка наконец заиграла», «взял эти наушники вместо прошлой модели», «после обновления приложение стало тормозить». В отзывах, Telegram-каналах и на форумах люди редко называют бренд так, как он записан в реестре товарных знаков.

Обратная проблема тоже есть: словарный поиск даёт шум. Однофамильные слова, названия городов, совпадения с именами людей — всё это попадает в отчёт и размывает картину. Векторная семантика решает обе задачи: находит смысловые упоминания и отсекает формальные совпадения.

Что такое векторная семантика применительно к бренду

Текст разбивается на фрагменты, каждый превращается моделью-эмбеддером в вектор — набор чисел, отражающий смысл. Запрос «упоминания нашего бренда в контексте доставки» тоже становится вектором. Дальше сравнивается косинусная близость: чем выше значение, тем ближе фрагмент по смыслу, а не по буквам.

На практике чистый вектор работает хуже гибрида. Продакшн-схема — это BM25 или полнотекстовый поиск плюс векторный отбор, объединённые через reciprocal rank fusion, и поверх — реранкер (cross-encoder), который пересортировывает топ-50 кандидатов. Только после этого в дело вступает LLM: она классифицирует тип упоминания, тональность, продукт и регион.

Как выглядит пайплайн в российской практике

Первый слой — сбор. API площадок отзывов, RSS, парсинг форумов, выгрузки из CRM и 1С, а также OCR скриншотов из мессенджеров: значительная часть негатива приходит картинками, и без распознавания текста она невидима.

Второй слой — подготовка. Чанкинг по 200–500 токенов с перекрытием, нормализация, удаление дублей репостов. Эмбеддинги складываются в векторную базу — Qdrant, pgvector или Milvus; для средних объёмов достаточно PostgreSQL с расширением.

Третий слой — извлечение и сведение сущностей. LLM вытаскивает структуру: бренд, модель, проблема, канал, дата. Затем entity resolution сводит алиасы, транслит, латиницу и кириллицу к одной карточке бренда — иначе «Brand», «Брэнд» и «брэнд_официальный» останутся тремя разными сущностями.

Где схема ломается

Порог отсечения по косинусной близости — главный источник ошибок. Слишком высокий — теряются косвенные упоминания, слишком низкий — в отчёт попадает весь корпус. Порог калибруется на размеченной выборке, а не подбирается на глаз.

Отдельная сложность — сарказм и отрицания. «Ну спасибо, бренд, за два часа ожидания» векторно близко к позитиву, и только LLM-слой с few-shot примерами различает тональность. Также стоит помнить про 152-ФЗ: персональные данные из отзывов лучше обрабатывать в приватном контуре, без отправки во внешние API.

Практические шаги

Соберите эталонную выборку 300–500 фрагментов и разметьте её вручную: упоминание есть или нет, тональность, продукт. Замерьте на ней текущий словарный поиск — получите baseline precision и recall.

Затем постройте минимальный гибридный поиск на одном канале, например на отзывах маркетплейса. Зафиксируйте метрики, добавьте реранкер, сравните. Расширяйте на новые источники только после того, как качество на первом стабилизировалось.

Обновляйте эмбеддинги бренда при запуске новых продуктов и кампаний: семантика запроса меняется вместе с рынком, а словарь алиасов требует ревизии не реже раза в квартал.

Как мы можем помочь

Мы внедряем приватные LLM и RAG-контуры для мониторинга упоминаний: собираем пайплайн от источников и OCR до векторного поиска, реранкинга и сведения сущностей, разворачиваем всё внутри инфраструктуры заказчика и интегрируем результаты с CRM или 1С. Начинаем с аудита текущего словаря и эталонной разметки, чтобы качество измерялось, а не ощущалось. Обсудить проект