Manticore Search: полнотекстовый и векторный поиск в одном движке на своём сервере

Manticore Search — это поисковая база данных с открытым исходным кодом, которую разворачивают на своём сервере: она умеет полнотекстовый, векторный и гибридный поиск в одном запросе, индексирует данные в реальном времени, а основной язык запросов у неё — SQL, совместимый с MySQL. Код лежит на GitHub. Я уже разбирал Meilisearch для быстрого поиска по сайту и Qdrant для семантического поиска по документам. Manticore, по описанию проекта, закрывает обе задачи одним движком.

Что это и чем отличается от привычного поиска

Три вида поиска простыми словами.

• Полнотекстовый ищет по словам. Ввели «шуруповёрт аккумуляторный» — движок находит карточки с этими словами и ранжирует по их весу.
• Векторный ищет по смыслу. Запрос «чем закрутить саморез без провода» не содержит ни одного слова из карточки, но по смыслу совпадает — товар всё равно находится.
• Гибридный совмещает оба и выдаёт единый ранжированный список: точные совпадения не тонут, смысловые попадания добавляются сверху.

Обычно ради этого держат два хранилища — под текст и под векторы. Дальше в коде кто-то должен опросить оба, объединить выдачи и решить, чей результат выше. Это отдельная логика: писать, тестировать, сопровождать. Manticore, по описанию проекта, делает это одним запросом внутри движка.

Второе отличие — SQL. База подключается как обычная MySQL-совместимая: привычный клиент, привычный синтаксис, никакого нового SDK. Экономия здесь на входе нового человека в проект — SQL знает любой бэкендер, а собственный DSL поискового движка нет.

Третье — индексация в реальном времени. Товар добавили или отредактировали — он находится сразу. Для каталога с живыми остатками это принципиально: ночная переиндексация означает, что до утра поиск врёт.

Зачем это бизнесу на понятных примерах

Поиск — это место, где клиент либо находит нужное, либо уходит.

• Каталог с опечатками и синонимами. «Кандиционер», «саморез по металу», «наушники» вместо «TWS». Если поиск на это не отвечает, магазин теряет заказы молча.
• База знаний и документы. Инструкции, регламенты, договоры. Здесь чаще нужен смысл: сотрудник не помнит формулировку, он помнит суть.
• Подсказки в строке поиска. Варианты по мере ввода — это про скорость ответа, а не про интеллект.
• Поиск в личном кабинете. Заказы, счета, обращения. Главное тут не релевантность, а то, что человек видит только свои документы.

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

Когда один движок лучше двух, а когда нет

Оговорюсь прямо: если задача — мгновенный текстовый поиск с подсказками по каталогу на несколько тысяч позиций, отдельный лёгкий движок ставится быстрее. Тащить универсальный инструмент туда, где хватает специализированного, — типичная ошибка «на вырост», за которую платят сопровождением. Manticore выигрывает там, где оба сценария нужны одновременно.

Как я внедряю поиск: моя методика

Порядок у меня один и тот же, независимо от движка.

1. Сначала смотрю логи запросов. Прошу выгрузку того, что люди искали, и выдачи с нулём результатов. Единственный честный источник требований. Часто оказывается, что основная масса проблем — опечатки и артикулы, а семантика не нужна вовсе.
2. Решаю, нужен ли вектор. Он даёт качество, но добавляет модель эмбеддингов, её обновление и нагрузку. Если по логам видно, что запросы — это названия товаров и артикулы, вектор не нужен.
3. Проверяю русскую морфологию и опечатки на данных клиента. Не на демо-наборе. «Стулья» должны находить «стул», «шкафа» — «шкаф». Здесь сравнения движков из интернета расходятся с реальностью русскоязычного каталога.
4. Меряю скорость на боевом объёме. Миллион документов ведёт себя не так, как тысяча. Замер — на копии реальных данных.
5. Закладываю переиндексацию и бэкапы. Отдельно проверяю сценарий массового обновления: импорт прайса, миграция.
6. Слежу, чтобы поиск не открыл наружу лишнее. Самая частая дыра: индекс становится обходом прав доступа — человек вытаскивает поиском чужие документы, потому что фильтр по владельцу забыли положить в запрос. Проверяю до релиза, всегда.

Если это выглядит как то, что не хочется проходить самим, — ровно эту работу я делаю за клиента: от разбора логов до проверенного поиска на боевых данных.

Как развернуть и что учесть

Разворачивается на своей машине или на VPS у российского провайдера. Обычный путь — Docker: контейнер, конфигурация, данные на отдельном томе. Точные требования к ресурсам и версиям уточню по документации проекта при внедрении.

• Данные остаются в контуре компании. Каталог и документы клиентов не уезжают в облачный сервис. Если в индексе есть персональные данные, это прямо влияет на требования 152-ФЗ.
• Поиск не торчит наружу. Порт закрыт, доступ только из приложения, панель под паролем и HTTPS. Открытый в интернет движок с вашим каталогом — подарок конкурентам.
• Кто обслуживает. Обновления, мониторинг, реакция на «поиск перестал находить». Без ответственного это ломается тихо.
• Что делать при росте. Заранее решить, на каком объёме переезжаете на более мощную машину.

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

Частые вопросы

Что такое Manticore Search и для чего он нужен?

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

Чем гибридный поиск отличается от обычного?

Обычный ищет по словам и не найдёт документ, где нужных слов нет. Гибридный добавляет поиск по смыслу и объединяет оба результата в один список. Разница заметна на запросах живым языком, а не артикулом.

Нужен ли Manticore, если уже стоит Meilisearch или Qdrant?

Не обязательно. Если текстовый поиск работает и семантика не требуется, менять движок незачем. Смысл переезда появляется, когда нужны оба типа поиска.

Можно ли на этом построить ИИ-ответы по своим документам?

Да, гибридный поиск — это поисковый слой для RAG: он находит подходящие фрагменты, а языковая модель формулирует ответ. Качество ответа определяется качеством поиска, поэтому начинают с него.

Где хранятся данные при таком поиске?

На вашем сервере — в этом смысл self-hosted решения. Индекс, документы и логи запросов не уходят внешнему сервису: проще с 152-ФЗ и коммерческой тайной.

Коротко о главном

Manticore Search стоит рассматривать не как «ещё один поиск», а как способ закрыть текстовый и смысловой сценарии одним движком и одним SQL-запросом. Это выигрыш там, где иначе пришлось бы держать две базы и писать склейку выдач. Если нужен только быстрый поиск по словам — отдельный лёгкий движок проще и честнее. Выбор движка это малая часть результата: остальное — морфология на ваших данных, скорость на реальном объёме и права доступа в выдаче.

С чего начнём: пришлите выгрузку поисковых запросов за месяц и объём каталога или базы документов. Я скажу прямо, нужен ли вам векторный поиск, и предложу конфигурацию — один движок или связку. Дальше разверну на вашем сервере, наполню индекс, проверю морфологию на боевых данных и закрою права доступа. Связаться можно напрямую в Telegram, MAX или VK.