При создании профессиональных локальных библиотек материалов и музыки традиционные поисковые архитектуры часто сталкиваются с серьезными проблемами. Когда пользователь вводит в строку поиска «эпический массивный импульс» или «спокойное пианино», поиск в базе данных, основанный на разделении ключевых слов (например, SQLite FTS5), может точно найти только те треки, которые содержат именно эти слова в своих полях. Из-за этого океан аудиоматериалов с богатыми тегами (но с другой терминологией) канет в лету.
Чтобы полностью решить эту болевую точку, в нашем последнем низкоуровневом рефакторинге мы полностью перешли на архитектуру Гибридного поиска (Hybrid Search), которая объединяет векторную базу данных LanceDB и модель BGE-M3.
I. Преодоление ограничений SQLite FTS5
В предыдущих версиях PureLab основной поиск полностью полагался на модуль полнотекстового поиска SQLite (FTS5). Эта архитектура проста и чрезвычайно быстра, но в реальных бизнес-сценариях она столкнулась с узкими местами:
- Семантический разрыв: поисковые запросы пользователей часто не идеально совпадают с реальными аудио-тегами (например, поиск по слову «счастливый» может пропустить треки с тегом «радостный»).
- Слабое межъязыковое сопоставление: музыкальные метаданные чрезвычайно фрагментированы в многоязычных описаниях. Простой токенизатор не может установить семантические связи между языками.
II. Двухполосный поиск и Гибридная Архитектура
Чтобы внедрить семантический уровень, мы не отказались от лексического поиска. Вместо этого мы приняли модель Двухполосного поиска и Слияния RRF (Reciprocal Rank Fusion), глубоко встроив LanceDB поверх существующей архитектуры SQLite.
1. Независимые таблицы проекций и BGE-M3 Embeddings
Для каждой нормализованной пользовательской библиотеки (Root) мы создали независимую проекционную таблицу text_vectors в ее каталоге .lancedb/.
- Локальный вывод ONNX: когда срабатывает механизм перестроения индекса (Фаза B), система запускает фоновый движок на основе
ort, передает текст метаданных в локальную модель BGE-M3 Int8 ONNX, создает высококачественные 1024-мерные векторыf32и вставляет (upsert) их в базу данных. - Журнал (Ledger) и Механизм Повтора: Чтобы предотвратить принудительное прерывание масштабных задач векторизации из-за ограничений производительности устройства, мы разработали таблицу
text_vector_index_ledgerв SQLite. Она отслеживает состояние каждой строки текста (pending,indexed,failed), позволяя системе беспрепятственно возобновлять и повторять попытки с точки прерывания, даже если программа неожиданно перезапустится.
2. Два Провайдера: Лексический и Семантический
Когда пользователь вводит поисковый запрос, архитектура на бэкэнде разделяется на два основных Провайдера:
- LexicalRetrievalProvider: продолжает обеспечивать сильное жесткое сопоставление через FTS5 (гарантируя 100% выдачу при прямом поиске по именам файлов и четким тегам).
- SemanticRetrievalProvider: загружает среду вывода BGE, вычисляет вектор пользовательского запроса (Query) и передает его в ANN (Approximate Nearest Neighbor) LanceDB для семантического поиска.
III. Искусство Слияния Рангов: Text-Priority RRF
Объединение результатов с обеих полос и представление итогового списка (ResultList) — настоящая проблема.
Вместо использования переранжировщика Cross-encoder с высокой задержкой, мы используем настроенный алгоритм Text-Priority RRF (Reciprocal Rank Fusion) для постобработки:
$$
Score_{RRF} = \frac{1}{K + \text{Rank}{Lexical}} + \frac{W{Semantic}}{K + \text{Rank}_{Semantic}}
$$
[!NOTE]
В нашей реализации:
- $K = 60$
- Вес лексического совпадения $W_{Lexical} = 1.0$
- Вес семантического совпадения $W_{Semantic} = 0.95$
Применяя небольшую скидку на вес (0.95) к семантической стороне, мы гарантируем, что если лексические термины аудиофайла совпадают напрямую, он всегда будет занимать более высокое место, чем те, которые являются просто «семантически похожими». Это максимизирует восстановление традиционных ожиданий от «поиска», дополняя его семантически релевантными скрытыми жемчужинами в длинном хвосте.
IV. Параллелизм Двух Библиотек: Фильтрация Музыки и Материалов
Различные сценарии применения имеют совершенно разные требования к индексации. В результатах, извлеченных LanceDB (TextVectorSearchHit), мы привязали функции к library_type (“music” или “material”) и surface.
Это означает, что даже если пользователь одновременно управляет сотнями гигабайт lossless-альбомов и коллекциями звуковых эффектов, конвейер поиска может выполнить точное разделение признаков во время поиска ANN, гарантируя, что звуковые эффекты окружающей среды никогда не попадут в ваши плейлисты музыкальных жанров.
Заключение
Проблема поиска в локальной библиотеке из миллиона треков по сути заключается в поиске баланса между точностью и полнотой в условиях ограниченных вычислительных ресурсов. Гибридная поисковая архитектура, сочетающая LanceDB с легкой моделью ONNX, не только сохраняет конфиденциальность пользовательских данных, но и поднимает опыт поиска на беспрецедентную высоту. В будущих версиях мы также планируем изучить фрагментацию метаданных (chunking) для поддержки поиска по более длинным полям описания.