ИИ в поиске поставщиков: когда модель не нужна
На планёрке решают: «Сделаем умный поиск по поставщикам — подключим нейросеть, и закупка найдёт кого угодно по описанию».
Через месяц демо красивое. В бою — галлюцинации, ответ за секунды вместо мгновений, а по ИНН система иногда «креативит» вместо того, чтобы попасть в одну карточку.
Знакомо? Так выглядит ставка на «ИИ найдёт всё сам» без разделения точного и смыслового поиска.
Проблема не в выборе модели. Проблема в том, что поиск миллионов юрлиц пытаются решить одним «умным» вызовом, а не конвейером: точное совпадение отдельно, смысл — отдельно, бизнес-правила — отдельно.
Три ступени, в которых узнаёте себя: - 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
У вас поиск по справочнику сейчас «строка или нейросеть» — или уже разделены точный и смысловой контуры?
· 12.08
NineLab делает поиск и high-load контуры под каталоги: Discovery 1–2 недели (источники, entity, SLO), потом пилот на боевом объёме. Вопросы — в личные или ninelab.ru/contacts.
Живой сервис: asknayda.ru · канал: @ninelab_ru
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён