Новости и разборы
Гибридный поиск: почему токенизация важна не меньше эмбеддингов
Почему гибридный поиск пропускает артикулы, версии и слова с диакритикой. Как проверить BM25, токенизацию и эмбеддинги на реальных запросах.
Сотрудник ищет инструкцию для AC-42, а поиск поднимает документы о похожем устройстве AC-24. В другом запросе название café не совпадает с введённым cafe. Если такой поиск снабжает AI-поддержку контекстом, модель может уверенно объяснить неподходящую инструкцию. Замена модели не устраняет различие между нужным объектом и похожим текстом.
Гибридный поиск объединяет семантический сигнал эмбеддингов и лексическое ранжирование, например BM25. Первый помогает находить смысловые переформулировки; второй — документы с нужными терминами. Но лексическая часть работает с токенами, полученными при анализе текста. Именно этот этап стоит проверить, когда поиск пропускает артикулы, названия версий или слова на другом языке.
Что изменилось в инструментах анализа текста
В материале Weaviate от 14 мая 2026 года описаны возможности версии 1.37: настройки анализа текста по свойствам, accent folding и API для просмотра токенизации. Провайдер показывает два отдельных набора токенов: индексируемые и используемые при обработке запроса. Это помогает увидеть, где нормализация или стоп-слова меняют лексический сигнал.
Это описание конкретной базы и версии. Оно не означает, что тот же контракт есть у любого поискового движка или в уже установленной версии Weaviate. Для своей системы нужно сверить конфигурацию, клиентскую библиотеку и условия изменения индекса. Инженерная идея шире продукта: проверять представление текста до того, как сравнивать итоговый ответ модели.
Разные поля требуют разных правил
Описание товара и его артикул выполняют разные функции. В описании полезно привести регистр к единому виду и отделить слова от пунктуации. В идентификаторе дефис, подчёркивание или регистр могут быть частью значения. Один общий анализатор способен сделать удобнее описание и одновременно испортить точное различение объектов.
Weaviate перечисляет методы word, lowercase, whitespace и field. В примере провайдера word разбивает строку User_42 - café на слова и число, а field сохраняет всю строку одним токеном. Выбирать метод следует по фактическому поисковому поведению поля. Сохранение строки целиком полезно для точного значения, но само по себе не делает её удобной для свободного вопроса пользователя.
В условном каталоге можно разделить артикул, название, описание и язык документа. Запрос с явным артикулом сначала проверяет точное поле; запрос «как очистить фильтр» обращается к текстовым инструкциям. Это предложенная архитектура, которую нужно испытать на своих данных. Проектирование собственного API показывает, какие договорённости о ресурсах, доступе и ответах требуют отдельного описания; историческая схема проекта не подтверждает внедрение этого поиска.
Диакритика и стоп-слова не являются универсальным шумом
Accent folding может сопоставить café и cafe. В Weaviate описан анализ как на стороне индекса, так и на стороне запроса, а также возможность сохранить выбранные символы без преобразования. Это важно, если различие действительно отделяет названия или позиции каталога. Агрессивная нормализация, удобная для одного языка, может объединить значения, которые бизнес считает разными.
Со стоп-словами аналогичная история. Служебное слово может быть несущественным в длинной инструкции и значимым в названии бренда. Провайдер описывает настройки стоп-слов по свойствам с токенизацией word и уточняет, что в этом механизме стоп-слова остаются в индексе, но исключаются из запроса BM25. Поэтому изменение списка не эквивалентно удалению слов из сохранённых документов.
Для русскоязычного каталога нельзя считать поддержку латинской диакритики доказательством правильной обработки русской морфологии. Нужны собственные примеры словоформ, смешанного RU/EN и транслитерации. Если система обслуживает несколько языков, пригодность каждого анализатора оценивают отдельно.
Сначала оценивать найденные документы
В обзоре качества retrieval от 6 мая автор описывает по своему исследовательскому опыту несколько ошибок: устаревшие материалы, семантически близкие, но недостаточные фрагменты и низкую релевантность результатов top-k. Это опубликованные автором наблюдения, а не универсальная оценка всех RAG-систем. Для практической проверки полезно отделить поиск источника от генерации объяснения.
Соберите небольшую контрольную выборку: точный артикул, соседний артикул, название версии, вопрос с опечаткой, слово с диакритикой, русская словоформа и смысловая переформулировка. У каждого запроса должны быть ожидаемые документы и явно неподходящие совпадения. Добавьте вопросы, на которые в базе нет ответа: всегда возвращать несколько фрагментов ещё не значит находить полезные сведения.
Сравнивать стоит лексический поиск, векторный поиск и их сочетание на одной выборке. Результат фиксируют до передачи в модель: появился ли нужный документ, какое место занял, попали ли рядом опасно похожие версии. Настройка весов гибридного ранжирования имеет смысл после проверки токенов, иначе она может лишь скрыть дефект одного сигнала.
Когда причина лежит за пределами токенизации
Правильные токены не спасают документ, в котором артикул находится в одном фрагменте, а применимая инструкция — в другом без связующего контекста. Также не помогут, если материал старый или недоступен пользователю. Обработка документов и данных включает подготовку входа и проверку преобразований: эти операции напрямую влияют на то, что вообще попадает в индекс.
Если источник представляет собой PDF с таблицами и графиками, следующий вопрос — сохранена ли структура при извлечении. Это отдельная тема поиска по таблицам и диаграммам PDF. Если ответ требует цепочки отношений между договором, поставщиком и объектом, точные слова также не решат всю задачу: стоит рассмотреть выбор между графом знаний и векторным RAG.
Для первого улучшения достаточно выбрать одну группу пропущенных запросов, увидеть её токены и сравнить альтернативную настройку на контрольной выборке. Затем оценить итоговые ответы на тех же вопросах. Гибридный поиск становится полезным, когда оба сигнала соответствуют задаче; его преимущество над другими вариантами нужно подтверждать, а не выводить из названия архитектуры.