HubSpot рассказал, что его внутренний семантический поиск дорос до сервиса на 20 млрд векторов, которым пользуются более 38 команд. Для русскоязычных разработчиков и техлидов здесь важна не сама цифра, а вывод: когда поиск становится опорой для AI-агентов, RAG и дедупликации данных, проблемы начинаются не на демо-этапе, а в эксплуатации.
Как пишет InfoQ, внутри HubSpot эта платформа называется VaaS, или Vector as a Service. По сути, это прослойка перед Qdrant, которая берет на себя не только хранение и поиск, но и более скучную, хотя обычно куда более болезненную часть работы: контроль доступа, генерацию эмбеддингов, версионирование данных и сбор обратной связи. Компания отдельно подчеркивает, что рост использования агентных сценариев сделал качество выдачи и задержки критичнее, чем раньше. И это звучит знакомо всем, кто уже успел выйти из режима «давайте прикрутим векторный поиск к чат-боту» в режим «почему оно тормозит в проде и кто ответит за recall».
Не база данных, а сервис вокруг нее
В качестве движка HubSpot выбрал Qdrant. Причины вполне прагматичные: систему можно запускать on-premises, у нее есть named vectors, гибридный поиск, многоэтапные запросы и weighted reranking. Вдобавок Qdrant дает понятные рычаги для контроля затрат, включая квантизацию и хранение данных на диске. Но интереснее другое: HubSpot не пошел в полностью управляемый внешний сервис, а развернул Qdrant у себя. Это позволило встроить платформу во внутренние инструменты трассировки, учета расходов, rate limiting, масштабирования и безопасности, а заодно не отдавать контроль над клиентскими данными наружу. Для крупного SaaS-бизнеса это уже не инженерный каприз, а вопрос архитектурной дисциплины.
Масштаб у этой истории вполне производственный, без скидки на красивую презентацию. По данным компании, текущая платформа охватывает более 200 индексов, свыше 140 кластеров, пять регионов и две среды. Пиковая запись доходит до 100 тыс. запросов в секунду. Отдельные коллекции содержат миллиарды точек, и здесь начинает работать неприятная математика распределенных систем: даже один неудачно сбалансированный шард способен вынудить кластер масштабироваться раньше, чем это действительно нужно. То есть цена ошибки уже измеряется не только лишними миллисекундами, но и вполне материальными инфраструктурными расходами.
Изначально все было гораздо прозаичнее. По словам Олега Терешина и Xin Liu, ранняя версия собиралась через Helm и обслуживала небольшое число потребителей. Пока система маленькая, такого набора хватает: выкатывать можно быстро, ручные операции терпимы, сложная автоматика кажется избыточной. Но рост числа команд и кластеров быстро превращает этот подход в технический налог. Авторы формулируют это предельно прямо: ручные операции не переживают масштабирование. В какой-то момент проблема уже не в том, сколько у вас векторов, а в том, сколько ночных дежурств нужно, чтобы все это хозяйство не рассыпалось.
Почему Helm перестал справляться
В HubSpot объясняют, что отказались от прежней схемы в пользу внутреннего Kubernetes Operator framework. Причина не в моде на операторов, а в ограничениях Helm для такого класса нагрузки. Он не умеет делать API-вызовы, не подходит для автоскейлинга по внешним метрикам и плохо справляется с более сложным жизненным циклом stateful-систем. В результате управление кластерами переложили на сущности, которые внутри компании называют Translators. Они каждые 60 секунд сверяют желаемое состояние системы с фактическим и приводят инфраструктуру в порядок. За этой почти бюрократической формулировкой скрывается то, что обычно и определяет зрелость платформы: автоматическое создание и вывод кластеров из эксплуатации, перемещение шардов, восстановление репликации и снижение операционной нагрузки на команду.
Эффект, по версии HubSpot, уже вполне измерим. Время запуска нового кластера сократилось с часов до минут, а необходимость держать standby-кластеры исчезла. Та же модель reconciliation теперь отвечает и за горизонтальное масштабирование, и за ребалансировку шардов, и за восстановление после сбоев репликации. Если перевести с платформенного на человеческий, компания добилась того, что векторная инфраструктура начала вести себя как нормальный внутренний сервис, а не как набор вручную подкручиваемых инстансов, которые еще вчера жили в статусе «proof of concept, но уже почему-то кормят полкомпании».
Контекст у этой истории шире самого HubSpot. Те же проблемы всплывают и у других игроков рынка векторного поиска. Qdrant в своих рекомендациях по крупным инсталляциям делает акцент не только на сотнях миллионов векторов, но и на том, как удержать latency и accuracy в рабочих пределах. Pinecone, как пересказывает InfoQ со ссылкой на публикацию компании в LinkedIn, описывал собственный рост с 40 млн до 600 млн векторов и делал ставку на высокий recall, разделение хранения и вычислений и надежность как полноценную продуктовую функцию. Общий мотив у всех один: когда retrieval становится частью критического пути для AI-функций, выигрывает не тот, у кого самый громкий анонс, а тот, кто умеет держать под контролем задержки, стоимость и предсказуемость поведения.
Для разработчиков здесь довольно прикладной вывод. Семантический поиск больше не выглядит как отдельная AI-фича, которую можно прикрутить поверх основного продукта в виде экспериментального слоя. Если он используется для агентов, RAG и операций вроде дедупликации контактов, он быстро превращается в базовый сервис уровня платформы данных. А значит, обсуждать придется не только качество эмбеддингов или выбор модели ранжирования, но и вещи, от которых обычно хочется спрятаться в соседний backlog: версионирование индексов, awareness к фильтрам, мониторинг recall и latency, перенос шардов, восстановление реплик и контроль memory skew. Бизнес-вывод тоже несложный: AI-нагрузка дорожает не только из-за инференса. Очень часто реальные деньги начинают утекать в инфраструктурную обвязку вокруг поиска.
Следующий интересный вопрос для рынка звучит так: кто первым научится делать такой семантический поиск дешевым и управляемым не только для гигантов с собственной платформенной командой. Пока кейс HubSpot показывает довольно трезвую картину: сама векторная база данных уже давно не центр истории, центр истории теперь в автоматизации вокруг нее. Первоисточник с цифрами и деталями можно посмотреть в .