Сколько часов в неделю ваш ведущий инженер или аналитик тратит на то, чтобы найти причину специфической ошибки в корпоративных дампах Jira, Confluence, ERP и разрозненных логах? Вы думаете, минут пятнадцать, но реальность бьет по бюджету: это часы бездумного скроллинга нерелевантной выдачи. Внедрить семантический поиск по корпоративным данным под ключ: сроки, бюджет от 600 000 ₽ и как мерить, что он реально работает — это не рекламный слоган интеграторов, а суровая физика процесса, которую мы регулярно обсчитываем на реальных проектах. В MoranaLabs мы строим индустриальный ИИ, выжимаем максимум из edge-вычислений на железе заказчика без сливов в облако, гоняем хайлоад и реалтайм. Я вижу изнутри, как рушатся надежды на дешевый поиск по внутренним базам.
Коробочный поиск за три копейки мертв для энтерпрайза.
Он ищет по точному совпадению слов и понятия не имеет, что ваш внутренний проект «Кракен», аббревиатура «ПС-24» и «тот самый сервис биллинга» — это одно и то же. Настраивать синонимы вручную в ElasticSearch — работа для бесконечного штата асессоров, которого у вас нет. Векторный поиск, напротив, понимает контекст. Но вокруг него вырос плотный слой хайпа, обещающий магию из коробки за пару дней. Магии не будет. Будет суровая инженерия, профилирование нагрузки и борьба за релевантность.
Цена адекватности: из чего собирается бюджет на семантический поиск под ключ
На рынке полно иллюзий, что векторный поиск — это просто поднять контейнер с Qdrant или накатить pgvector поверх PostgreSQL, прогнать тексты через открытую модель эмбеддингов и выкатить в прод. Это карго-культ. Если вы сделаете так, ваши пользователи получат выдачу, в которой философские рассуждения о архитектуре из прошлогоднего блога будут ранжироваться выше, чем конкретный мануал по починке упавшего сервера, просто потому, что их векторы оказались математически ближе.
Настоящий корпоративный поиск всегда гибридный. Он объединяет классический лексический поиск (BM25) для точных совпадений артикулов и семантический векторный поиск (через графы HNSW) для понимания смысла. А поверх этого ложится тяжеловесная логика прав доступа и переранжирования. Ниже я привожу декомпозицию базового жизнеспособного проекта.
| Этап внедрения пайплайна | Инженерная задача и подводные камни | Доля в бюджете / Трудозатраты |
|---|---|---|
| Инвентаризация и парсинг источников | Выгрузка из Confluence, 1C, CRM, локальных шардов. Главная боль — парсинг тяжелых PDF, таблиц и OCR скан-копий. Если криво нарезать текст на чанки, векторы будут содержать мусор. | ~20% (от 120 000 ₽) |
| Построение гибридного индекса | Настройка пайплайна: эмбеддинги (например, E5 или BGE), генерация векторов, настройка BM25. Балансировка весов между лексикой и семантикой под вашу специфику. | ~30% (от 180 000 ₽) |
| Интеграция с ролевой моделью (RBAC) | Фильтрация выдачи на уровне векторной БД (payload filtering). Пользователь не должен видеть даже заголовки документов, к которым у него нет доступа. | ~25% (от 150 000 ₽) |
| Кросс-энкодер и переранжирование | Внедрение тяжелой модели для финальной сортировки топ-100 результатов, чтобы p99 latency укладывался в 300 мс, а на первое место всплывал самый релевантный ответ. | ~15% (от 90 000 ₽) |
| Тестирование и тюнинг метрик | Сбор эталонного датасета (Golden Set), прогон метрик NDCG@5 и MRR. Интеграция интерфейса в корпоративный портал. | ~10% (от 60 000 ₽) |
Поиск без жесткого учета прав доступа на уровне движка — это не фича, это критический инцидент информационной безопасности.
Многие самописные решения сначала ищут топ-10 документов по вектору, а потом на бэкенде отсекают те, на которые у пользователя нет прав. В результате, если младший аналитик ищет «штатное расписание», движок находит 10 документов топ-менеджмента, бэкенд их блокирует, и пользователь получает пустой экран, хотя в базе есть открытый регламент. Правильная архитектура требует проброса токенов доступа прямо в ядро HNSW-индекса. Это усложняет проект, но гарантирует, что поиск будет работать корректно и безопасно.
Метрики релевантности: как принимать работу и доказать ROI
Самый сложный этап во всем процессе — это не поднять кластер, а доказать, что система находит то, что нужно. В MoranaLabs мы внедряем семантический поиск с измеримым приемочным порогом, и этот порог невозможно определить на глаз. Формулировки вроде «стало искать лучше» не принимаются. Инженерия требует цифр.
До старта разработки формируется Golden Set — золотой стандарт запросов. Вы сажаете трех ключевых сотрудников из разных отделов и просите их выгрузить 200 реальных, кривых, сленговых поисковых запросов из их повседневной практики. Для каждого запроса они вручную указывают ID документа, который должен быть найден. Это муторная работа, от которой бизнес всегда пытается отказаться, но без нее проект обречен на вкусовщину.
Когда Golden Set собран, мы фиксируем baseline — как с этими запросами справляется текущий поиск портала. Обычно метрика MRR (Mean Reciprocal Rank — средний обратный ранг первого правильного ответа) болтается на уровне 0.15. Это значит, что нужный документ находится в среднем на седьмой-восьмой позиции, куда никто никогда не докликивает. Цель гибридного пайплайна — довести MRR минимум до 0.7, а метрику NDCG@5 (качество ранжирования первой пятерки результатов) — до 0.85.
Если система бьет эти цифры на тестовой выборке, она готова к проду. Вы получаете долю «нашел с первого раза» на уровне 75-80%. Дальше начинается чистая экономика. Возьмите логи старого поиска, посмотрите, сколько запросов в день делают ваши инженеры. Оцените время сессии, когда пользователь перебирает запросы, пытаясь переформулировать мысль. В среднем плохой поиск сжигает около 15-20 минут чистого времени специалиста в день. Умножьте это на 500 сотрудников и на их часовую ставку. Бюджет на кастомную разработку отбивается за первый же квартал эксплуатации, просто за счет того, что люди перестают делать работу базы данных.
Главное, что нужно понимать заказчику: качественный корпоративный поиск не покупается в виде архива с бинарником. Это всегда процесс адаптации математики под ваш конкретный хаос в документах. Наличие аббревиатур, отсутствие четкой структуры в Wiki, перемешка технической документации с бухгалтерскими регламентами — все это ломает стандартные эмбеддинги. Именно поэтому переранжирование (reranking) через кросс-энкодеры становится обязательным этапом, вытягивающим контекстно-зависимые документы наверх.
Требуйте от подрядчиков прозрачной метрики. Если вам продают просто «интеграцию векторной базы» без фиксации целевого NDCG на ваших данных — вам продают инфраструктуру, а не решение проблемы поиска.