Как мы сделали поиск организаций для asknayda.ru: лексика, ИИ и пилот

Закупщик ищет поставщика не «в Google», а в хаосе: отраслевые списки, Excel от коллег, старые визитки и десяток вкладок. Название помнит примерно, ИНН — нет, категорию формулирует своими словами. Из этой боли выросла Найда — B2B-поиск организаций на asknayda.ru.

Ниже — как мы устроили поиск на миллионах карточек: где работает классическая лексика, когда включается ИИ-модель bge-m3, как сливается гибридная выдача, и почему продукт сейчас на стадии пилота.

Задача продукта: не «ещё один каталог», а рабочий поиск

Найда («спроси Найду») — каталог поставщиков и производителей РФ. Правило entity простое и жёсткое: один ИНН — одна карточка, без дублей «ООО Ромашка» в трёх вариантах написания.

• поиск по названию, ИНН, категории и роли;
• карточка компании с классификаторами и похожими поставщиками;
• кабинет claim: поставщик заявляет и обогащает профиль;
• управляемое ранжирование (политика обновляется без редеплоя API);
• контакты для гостя маскируются, полный доступ — после авторизации.

Масштаб, с которым живёт витрина: порядка 4,5 млн карточек в индексе и цель по скорости — p95 < 300 мс на типовых запросах. Подробнее продукт разобран в кейсе Найды.

Как устроен поиск: два контура и слияние

Поиск — это не один «умный» вызов LLM. Это конвейер с понятными слоями.

Шаги запроса на витрине:

1. нормализация текста (пробелы, регистр, очевидный мусор);
2. классификация типа запроса: ИНН / точное имя / смысловой / смешанный;
3. лексический поиск в OpenSearch (почти всегда);
4. при необходимости — embedding запроса моделью bge-m3 через TEI и поиск соседей в Qdrant;
5. слияние кандидатов через RRF;
6. бизнес-правила ранжирования и маскирование контактов для гостя.

ИИ-модель bge-m3: что это и когда включается

Семантический слой — это не ChatGPT в поиске. Это embedding-модель bge-m3 (multilingual), развёрнутая через Text Embeddings Inference (TEI). Она превращает текст запроса и тексты карточек в векторы; ближайшие соседи ищутся в Qdrant.

Почему не гонять модель на каждый клик:

• для ИНН и точного юрлица лексика уже даёт правильный top-1;
• лишний векторный round-trip — цена latency и железа;
• пользователь sourcing-а ценит предсказуемость сильнее «креативной» выдачи.

Когда bge-m3 включается:

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

Когда модель не нужна (остаётся OpenSearch):

• запрос — ИНН (10/12 цифр) или явный идентификатор;
• короткое точное название с уверенным лексическим попаданием;
• навигация фильтрами каталога без текстового «описания желаемого».

Итог для продукта: ИИ — усилитель релевантности на смысловых запросах, а не замена справочника. Гибрид через RRF позволяет не выбирать «либо строка, либо вектор»: оба списка кандидатов складываются в одну выдачу, после чего отрабатывает ranking policy.

Почему так, а не «просто LLM отвечает списком компаний»

Генеративная модель в runtime-поиске по 4+ млн юрлиц — это риск галлюцинаций, нестабильная latency и дорогой unit economics. Embedding + ANN (Qdrant) + лексика дают:

• объяснимую выдачу (можно разобрать, откуда кандидат);
• стабильный SLO на витрине;
• возможность крутить бизнес-правила отдельно от модели.

Backend карточек, claim и биллинга — Go + PostgreSQL + Redis; витрина — Next.js. Поиск остаётся отдельным продуктовым контуром со своими метриками качества, а не «фичей чата».

Стадия пилота: что уже в бою, что ещё проверяем

asknayda.ru — публичный пилот на боевом индексе. Это важно различать:

• Уже в проде: поиск и карточки на миллионах организаций, SEO-витрина, кабинет поставщика, claim, базовый контур модерации и Premium-биллинга.
• В фокусе пилота: качество выдачи на реальных формулировках закупщиков, калибровка ranking policy, сценарии claim/обогащения, обратная связь по «почему я вижу именно этих».
• Ещё не цель пилота: «зрелый маркетплейс со всеми вертикалями и идеальной полнотой профиля каждой компании».

Пилот здесь — не прототип на 1 000 строк Excel. Это запуск продукта с настоящим индексом и настоящими пользователями, где мы сознательно ограничиваем scope вокруг поиска как ядра и собираем сигналы, прежде чем раздувать roadmap.

Что взять из этого кейса в свой продукт

1. Разделите точный и смысловой поиск — разные триггеры, общая выдача.
2. Назовите модель явно (у нас bge-m3) и опишите, когда она не вызывается.
3. Держите ranking policy отдельно от индекса — иначе каждое A/B превращается в релиз.
4. Пилот на боевом объёме данных ценнее идеального демо на 5 000 «чистых» карточек.

Нужен похожий поиск по своему справочнику поставщиков, номенклатуре или партнёрам — разберём архитектуру и смету пилота. Смотрите кейс Найды, живой сервис asknayda.ru или оставьте заявку.

Смежные материалы: разработка SaaS-платформы, API под ИИ-агентов, высоконагруженная разработка на Go.