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

Поэтому это не пост «векторы против ключевых слов». Речь идёт о скучном, практичном сочетании: vector + full-text, в одной системе, с предсказуемым поведением.

Azure AI Search и Manticore Search оба могут выполнять гибридный поиск. Но они ощущаются совершенно по‑разному в повседневной эксплуатации.

Azure оптимизирует быструю доставку. Manticore оптимизирует работу с поиском в течение длительного времени. Это различие проявляется меньше в первую неделю — и гораздо сильнее к шестому месяцу.

Где «универсальный поиск» перестаёт работать

Существует целый класс поисковых задач, которые выглядят простыми, пока вы их не запустите: поиск по документам, базы знаний, внутренние инструменты, всё, что состоит из «маленьких фрагментов» (абзацев/разделов) и содержит множество метаданных.

Именно здесь управляемые абстракции начинают просачиваться, а значения по умолчанию перестают быть вашими друзьями.

В итоге вы начинаете заботиться о таких вещах, как:

• строгие фильтры (рабочее пространство/проект, регион, владелец/команда, метки времени, тип документа, видимость, версия)
• фразы/близость (потому что формулировка имеет значение)
• стабильный ранжир (чтобы результаты не менялись из недели в неделю)
• подсветка/фрагменты, выглядящие как реальные цитаты, а не «AI vibes»

И да, семантический/векторный поиск помогает — но он не заменяет основы полнотекстового поиска и объяснимость.

Как только вы попадаете в этот мир (фильтры, фразы, стабильный ранжир, «почему это заняло такое место?»), поиск перестаёт быть чем‑то, что просто «включаешь», и становится тем, что вы будете настраивать и отлаживать со временем. Тогда появляется реальный выбор: принять уровень абстракции управляемого сервиса или запустить движок, где ранжирование и выполнение более явные.

Это разделение довольно точно соответствует Azure AI Search против Manticore.

Два способа решить это

Самый простой способ понять это:

• Azure AI Search — это управляемый сервис, который вы арендуете. Вы меняете контроль на удобство (и получаете ограждения в стиле Azure).
• Manticore Search — это поисковый движок, который вы запускаете. Вы получаете настройки и регуляторы, а также ответственность за сервер, на котором он работает.

Если вам нужен лишь «достаточно хороший поиск» плюс простая интеграция, Azure трудно превзойти. Если вам нужно спорить о релевантности и выигрывать, Manticore проще в эксплуатации.

Сравнение стоимости: управляемый vs самостоятельный хостинг

Это одно из самых значительных практических различий между этими двумя подходами, и оно часто становится очевидным только спустя несколько месяцев в продакшене.

Стоимость Azure AI Search

Azure AI Search тарифицируется как управляемый облачный сервис. Вы выделяете ёмкость (реплики и разделы) и платите за эту ёмкость почасово, независимо от того, используется она полностью или нет.

У этой модели есть несколько практических последствий:

• Стоимость масштабируется с выделенной ёмкостью, а не с реальным объёмом запросов.
• Высокая доступность и более высокая пропускная способность умножают затраты (реплики × разделы).
• Векторный поиск увеличивает нагрузку на память, что часто заставляет перейти на более высокие уровни быстрее, чем ожидалось.
• Вы не можете «масштабировать до нуля» — сервис стоит деньги, пока существует.

В реальных настройках команды часто начинают с небольших размеров, а затем постепенно масштабируются по мере роста индексов, увеличения объёма запросов или ужесточения требований к задержке. Со временем обычно Azure AI Search достигает сотен долларов в месяц, а для более требовательных нагрузок четырёхзначных сумм в месяц — это не редкость.

Во всём этом нет ничего удивительного — вы платите за полностью управляемый сервис с SLA, встроенной избыточностью и тесной интеграцией с Azure. Но важный момент в том, что рост стоимости может ощущаться косвенно: вы не всегда видите чёткую, линейную связь между «мы изменили X» и «счёт вырос».

Стоимость Manticore Search

Сам Manticore Search — бесплатный и с открытым исходным кодом. Нет расходов на лицензирование. Вы платите за инфраструктуру и эксплуатацию.

На практике это обычно означает:

• один или несколько ВМ (или контейнеров)
• хранилище
• мониторинг и резервные копии
• некоторое время на операции

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

Ключевое различие — прозрачность: если затраты растут с Manticore, это обычно из‑за того, что вы явно добавили ОЗУ, процессор или машины. Посередине нет непрозрачных расчётов сервисных единиц.

Точка перелома

Если ваш приоритет — минимальные эксплуатационные усилия и глубокая интеграция с Azure, стоимость Azure AI Search может быть разумным компромиссом.

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

Azure AI Search: работает быстро, но со временем становится размытым

У Azure есть надёжный движок по ключевым словам: анализаторы, стемминг, фразы/близость, карты синонимов, профили оценки, фильтры и необязательный слой семантического ранжирования. Вы можете быстро выпустить что‑то.

Боль начинается, когда вы выходите за пределы демо и начинаете поддерживать его:

• Настройка в основном «переключить эти веса» (профили оценки), плюс, возможно, семантическое ранжирование.
• Оценка менее прозрачна от начала до конца, чем у Manticore. Вы можете настраивать с помощью профилей оценки/анализаторов и измерять результаты, но не получаете того же ощущения «читать запрос, понимать ранжирование».
• Гибридное объединение управляется; результаты по ключевым словам и векторные результаты объединяются с помощью Reciprocal Rank Fusion (RRF). Это удобно. Также сложнее проанализировать, когда топ‑10 выглядит неверно.

На практике это часто превращается в компенсирующую логику на уровне приложения: повышение релевантности, фильтрацию или постобработку результатов, потому что поисковый движок не полностью удовлетворяет вашим требованиям. Такая логика сложнее тестировать, объяснять и позже удалять.

Если вам никогда не приходилось объяснять «почему это №1?», когда кто‑то рассержен, то всё в порядке. Если приходилось, вы уже знаете, как это больно.

Также: всё это определяется в терминах сервиса — схема JSON, API Azure, ограничения Azure. Практический минус — привязка к поставщику: как только ваша модель индексации, анализаторы, профили оценки и шаблоны запросов становятся ориентированы на Azure, последующий переход требует реальных усилий.

Manticore Search: явный, и честно… удобнее отлаживать

Manticore происходит из классического мира информационного поиска и ставит функции полнотекстового поиска на передний план: оценка в стиле BM25, сопоставление на уровне полей, фразы/близость, фильтрация и язык запросов, похожий на SQL. Вы можете посмотреть запрос и понять, что он делает. И, что важнее, вы можете объяснить это человеку, не работающему с поиском.

Пример: «обычный» полнотекстовый запрос

SELECT doc_id, WEIGHT()
FROM documents
WHERE MATCH('"data retention policy"~3')
  AND department = 'Finance'
  AND effective_date >= '2022-01-01'
ORDER BY WEIGHT() DESC
LIMIT 10;

Эта часть «WEIGHT()» не волшебство; она часть ментальной модели. Это важнее, чем многие думают.

Гибридный поиск без догадок

В Azure гибридный поиск — «запустить оба, объединить с помощью RRF». В Manticore гибридный поиск — «сделать это, затем это, затем отфильтровать и применить вторичную сортировку». На слайде это выглядит менее элегантно, но очень практично.

Пример (сначала вектор, затем текст, затем явная сортировка):

SELECT doc_id, knn_dist(), WEIGHT()
FROM documents
WHERE knn(embedding, 50, 'how to rotate api keys safely')
  AND MATCH('"key rotation" | "rotate keys"')
ORDER BY knn_dist() ASC, WEIGHT() DESC
LIMIT 10;

Вы можете прочитать этот запрос вслух, и он не звучит как молитва. В этом суть.

Одна деталь: результаты KNN в основном упорядочены по векторному расстоянию; дополнительные критерии ORDER BY уточняют порядок внутри этого набора KNN (подумайте о разбивке по ничьим/вторичной сортировке), а не «полностью объединяют» оценки в единый комбинированный ранг.

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

Продукты, ориентированные на хранение, не заменяют поиск (они лишь заставляют использовать вторую систему)

Это часто возникает в Azure: вы выбираете хранилище документов (Cosmos DB, DocumentDB/Mongo API и т.д.) и надеетесь, что оно также покрывает поиск.

Это не будет, по крайней мере для чего‑то на уровне чанков или чувствительного к релевантности. Вы быстро захотите:

• фразы/близость
• настройку релевантности сверх базового текстового сопоставления
• более точный контроль ранжирования
• гибрид (вектор + ключевое слово), который можно понять

В итоге вы всё равно добавляете Azure AI Search и теперь поддерживаете две отдельные вещи: хранение + поиск, плюс конвейер индексации между ними. Это может быть полностью приемлемо. Просто не притворяйтесь, что это одна система.

Свежесть и «моя правка дошла?»

В Azure обновления — это вызовы API со своей семантикой (и нужно быть осторожным с частичными обновлениями). Когда контент меняется, векторные поля нужно обрабатывать явно. Это выполнимо, просто… работа приложения.

Таблицы реального времени в Manticore ведут себя больше как база данных: вставка/обновление/удаление, и полнотекстовые + векторные индексы поддерживают актуальность вместе. Если вы создаёте, например, поиск товаров или документов, где всё постоянно меняется, это кажется проще.

«Мы хотим Azure, желательно управляемый» (справедливо)

Если у вашей компании по умолчанию «всё управляемо», Azure AI Search соответствует этой концепции. Вы подключаете его, принимаете модель сервиса и идёте дальше.

Если вы хотите Manticore с минимальными проблемами в Azure, честно: он не управляемый, но может быть скучным.

Azure AI Search лучше всего работает, когда поиск — инфраструктурная зависимость. Manticore лучше, когда поиск — часть продукта.

Типичная конфигурация, не превращающаяся в научный проект:

• храните документы в любом Azure‑хранилище, которому уже доверяете (Blob, БД и т.д.)
• запускайте Manticore на одной VM (или позже небольшом VMSS) в VNet
• поддерживайте чанкирование/сегментацию + индексацию как простой конвейер воркеров (очередь + воркер, или что уже используете)
• рассматривайте поиск как почти безсостояний сервис: снимки/резервные копии, метрики и замену, а не «домашние серверы»

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

Вы всё ещё владеете им, но вас не заставляют создавать сложный кластер, если он не нужен.

Практическое замечание: почему векторный поиск меняет счёт

Гибридный поиск — это не только «ключевое слово + вектор». Это также CPU + RAM.

• Работы, ориентированные на ключевые слова, в основном нагружают CPU.
• Работы, ориентированные на векторы, в основном потребляют память.
• Индексация на уровне чанков часто умножает оба ресурса: больше строк, больше векторов, больше метаданных, больше фильтров.

В Azure AI Search это обычно проявляется как «нам нужно больше мощности» (и счёт следует за выделенными единицами).
В Manticore это обычно выглядит как «нам нужно больше RAM/CPU» (и вы выбираете размер VM).

Те же физические принципы — разная ценовая модель.

Краткое замечание: «может, тогда Elastic?»

Elastic способен, и в Azure это знакомый выбор. Обмен обычно операционный: больше движущихся частей, больше настроек, больше «ухода и кормления кластера».

Если вы уже успешно его используете, отлично. Если нет, и всё, что вам нужно — поиск документов на уровне чанков, который работает, это может ощущаться как приведение целого оркестра, потому что вам нужен лишь скрипка.

Опыт разработчика (как это ощущается в редакторе)

Конкретный пример: поиск документов на уровне пунктов

Если вам нужен стресс‑тест, который быстро выявит компромиссы поиска, то это он: разбейте документы на пункты/разделы, проиндексируйте эти фрагменты, а затем попросите людей найти конкретную формулировку под строгими фильтрами.

Почему это безжалостно:

• Фраза/близость действительно важны. Система, которая лишь “similar” покажет похожие варианты, тратящие время.
• Фильтры не являются опциональными. Пользователи будут рассматривать их как жёсткие ограничения, и они заметят, когда “almost matching” проскользнут.
• Доверие хрупко. Если люди не могут понять, почему результат #1, они перестают доверять поиску и начинают обходить его.

Во что это обычно превращается (примерно):

• каждый пункт становится строкой/документом с clause_id, document_id, clause_path (или любым другим названием) и текстом пункта
• поля метаданных становятся жёсткими фильтрами (workspace/matter, jurisdiction/region, dates, version, visibility, etc.)
• опционально: embedding для каждого пункта для части “find me similar language”
• UI получает полный документ отдельно и отображает пункт с фрагментом/highlight, которое легко проверить

Базовый полнотекстовый поиск (предсказуемый, простой для объяснения). Используйте его, когда люди знают формулировку, которую ищут:

SELECT clause_id, document_id, WEIGHT()
FROM clauses
WHERE MATCH('"limitation of liability"~3')
  AND jurisdiction = 'AU'
  AND effective_date >= '2022-01-01'
ORDER BY WEIGHT() DESC
LIMIT 10;

Где подходят embeddings: они могут быть отличными для расширения охвата (“find similar language”), но они не “thinking”. На практике семантический поиск может оказаться в неловком промежуточном положении: сначала выглядит умным, а затем раздражает людей, потому что не достаточно надёжно умный.

Итак, вот шаблон, который обычно работает:

• Если пользователь вводит почти точные ключевые слова → используйте чистый полнотекстовый поиск (BM25/WEIGHT()).
• Если пользователь вводит идею (“cap on liability”, “excluded damages”) → используйте embeddings для получения кандидатов, затем уточните их полнотекстовым поиском + фильтрами.

Гибридный пример (семантические кандидаты → строгий текст + метаданные → упорядочивание по расстоянию):

SELECT clause_id, document_id, knn_dist(), WEIGHT()
FROM clauses
WHERE knn(embedding, 50, 'cap on liability and excluded damages')
  AND MATCH('"limitation of liability" | "consequential damages"')
  AND jurisdiction = 'AU'
ORDER BY knn_dist() ASC, WEIGHT() DESC
LIMIT 10;

Что это на самом деле делает:

• knn(...) выбирает набор кандидатов по смыслу.
• MATCH(...) + фильтры делают его проверяемым (вы можете указать на слова на странице).
• Результаты в основном сортируются по векторному расстоянию; WEIGHT() уточняет внутри этого набора KNN.

Если вам нужна реальная аргументация, делайте её после извлечения (например, запустите LLM над топ‑N кандидатами).

Это также место, где подходят рабочие процессы в стиле RAG. Поддержка RAG в Manticore находится в roadmap (см. issue #2286 ) — и к моменту, когда вы читаете это, она может уже быть выпущена.

И тогда какой выбрать?

• Если вы хотите “don’t make me run search infra” и уже глубоко в Azure, Azure AI Search — очевидный выбор. Вы будете двигаться быстро.
• Если релевантность поиска — функция продукта (не галочка), и вы планируете настраивать и отлаживать её месяцами, вероятно, предпочтёте Manticore. Вы можете быть требовательными и точными, не борясь с управляемыми абстракциями.

Небольшое практичное правило: если ваша команда не может или не хочет владеть поиском как системой, выбирайте Azure. Если ваша команда может им владеть, выбирайте вариант, который позволяет видеть, что происходит — обычно это значит, что Manticore — более спокойный долгосрочный выбор.