ИИ в поиске поставщиков: когда модель не нужна

На планёрке решают: «Сделаем умный поиск по поставщикам — подключим нейросеть, и закупка найдёт кого угодно по описанию».

Через месяц демо красивое. В бою — галлюцинации, ответ за секунды вместо мгновений, а по ИНН система иногда «креативит» вместо того, чтобы попасть в одну карточку.

Знакомо? Так выглядит ставка на «ИИ найдёт всё сам» без разделения точного и смыслового поиска.

Проблема не в выборе модели. Проблема в том, что поиск миллионов юрлиц пытаются решить одним «умным» вызовом, а не конвейером: точное совпадение отдельно, смысл — отдельно, бизнес-правила — отдельно.

Три ступени, в которых узнаёте себя: - Excel и вкладки. Закупщик гуглит, копирует в таблицу, сверяет глазами. Неделя на сложную позицию — обычное дело. - Каталог «только по строке». ИНН и точное название работают. «Производитель щитового оборудования в ЦФО» — уже провал или мусорная выдача. - «Просто LLM». Генеративная модель в runtime по миллионам карточек: нестабильная задержка, риск выдумать компанию, дорогой unit economics. Красиво на питче — опасно в проде.

Ориентир по деньгам: → неделя слепого sourcing на сложную позицию часто 80–250 тыс. ₽ фонда закупки и упущенного срока сделки → ошибка в юрлице / ИНН — ещё один круг согласований и риск сорвать поставку → «переписать всё на чат с LLM» обычно дороже и медленнее, чем пилот: лексика + точечная семантика на боевом индексе

Как мы сделали в Найде (asknayda.ru) — публичный пилот на ~4,5 млн карточек: → лексика (OpenSearch) — ИНН, точное имя, фильтры → ИИ-модель bge-m3 включается на смысловых запросах и слабой лексике, а не на каждый клик → слияние двух списков кандидатов в одну выдачу → бизнес-ранжирование правится без редеплоя API → цель по скорости: p95 ниже 300 мс на типовых запросах витрины

Семантика у нас — не «чат отвечает списком компаний». Это embedding: текст → вектор → ближайшие соседи. Генеративка в runtime по миллионам юрлиц даёт риск выдумать компанию и нестабильную задержку. Для sourcing предсказуемость важнее «креативной» выдачи.

Рамка «когда да / когда нет»: → да: запрос на естественном языке, синонимы, «похожий поставщик», слабый лексический сигнал → нет: чистый ИНН, короткое точное название с уверенным попаданием, навигация фильтрами → ещё рано: нет правила «один ИНН — одна карточка» — сначала entity, иначе ИИ размножит дубли

Перед «умным поиском» в своём каталоге проверьте пять ворот: есть владелец справочника; есть правило сущности; есть лексика со скоростью ответа; назвали, когда модель не вызывается; пилот меряет качество выдачи, а не факт «модель подключена».

Пилот здесь — не макет на тысяче «чистых» строк. Это боевой индекс и реальные формулировки закупщиков. Ищем качество выдачи, а не обещание «ИИ всё сам».

Полный разбор архитектуры и стадии пилота — статья «Как мы сделали поиск организаций для asknayda.ru: лексика, ИИ и пилот»: https://ninelab.ru/blog/asknayda-b2b-search-engine?utm_source=setka&utm_medium=social&utm_campaign=ninelab_setka_asknayda_b2b_search_engine

У вас поиск по справочнику сейчас «строка или нейросеть» — или уже разделены точный и смысловой контуры?

#B2B #поиск #закупки

ИИ в поиске поставщиков: когда модель не нужна | Сетка — социальная сеть от hh.ru