Fairmarkit: ML System Design

Сначала нужно описать продуктовый сценарий: заказчик создает заявку, система предлагает поставщиков, заказчик редактирует список, поставщики отвечают bid/no-bid/ignore, затем выбирается победитель.

Начинать стоит не с "возьмем embeddings", а с границ решения. Fairmarkit управляет стартовым списком поставщиков для закупочной заявки. Дальше заказчик может удалить или добавить поставщиков, отправить приглашения, получить bid/no-bid/ignore и выбрать победителя.

Формулировка ML-задачи: по заказчику, заявке и доступной базе поставщиков вернуть top-K поставщиков, которые с высокой вероятностью окажутся релевантными для приглашения и дадут полезный результат закупки. При этом нужно учитывать обязательные поля заявки, категории заказчика, географию, сроки, количество/единицы измерения и историю взаимодействий.

Важно отделить цель продукта от proxy labels. Бизнес хочет экономить время заказчика и повышать качество закупки, а модель может оптимизировать recall подходящих поставщиков, вероятность ответа/ставки, вероятность не быть удаленной заказчиком и downstream winner signal. Эти сигналы не равнозначны, поэтому их нужно обсуждать явно.

Рекомендации ценны как хороший стартовый список: они сокращают ручной поиск, показывают новых релевантных поставщиков и помогают заказчику быстрее получить конкурентные предложения.

Ручное редактирование не отменяет рекомендательную систему, а задает ее роль. Система должна дать хороший стартовый список, чтобы заказчик не искал поставщиков с нуля. Если рекомендации качественные, заказчик меньше удаляет, меньше добавляет вручную, быстрее запускает закупку и получает больше релевантных предложений.

Из этого следуют продуктовые метрики: доля предложенных поставщиков, оставшихся в списке приглашений; manual add/delete rate; response или bid rate среди рекомендованных поставщиков; coverage новых полезных поставщиков; время до отправки заявки; downstream success, например наличие хотя бы одного приемлемого предложения или победителя среди рекомендованных.

Для B2B важно не обещать только top-1 precision. У заказчика могут быть внутренние предпочтения и ограничения, поэтому хорошая рекомендательная система должна быть управляемой: filters, explanations, diversity, business rules и возможность ручного override остаются частью продукта.

Нужны поля заявки, профиль заказчика, профиль поставщика, исторические приглашения, ручные правки, bid/no-bid/ignore, победители и история сделок; миллион поставщиков требует retrieval stage перед ranker.

Данные стоит разделить на сущности. Заявка: title, description, quantity, unit, category tree, close date, address, business unit. Заказчик: company, user, предпочитаемые поставщики, история, внутренние категории, география и ограничения. Поставщик: profile, categories, served regions, прошлые заявки, response behavior, win/bid history.

Логи процесса особенно важны: кого система показала, кого заказчик удалил, кого добавил, кому отправили приглашение, кто ответил bid/no-bid/ignore, кто стал победителем. Это дает не один label, а несколько сигналов релевантности и friction.

Масштаб больше миллиона поставщиков означает, что нельзя гонять дорогой ranker по всем. Нужен candidate generation: business filters, geo/category constraints, lexical search, vector search или precomputed candidate pools. Ranker работает только по top-N candidates и использует более богатые признаки заказчика, заявки и поставщика.

Сначала собрать high-recall candidate pool через hard filters, lexical/vector retrieval и business constraints, затем rerank по признакам заказчика, заявки, поставщика и истории взаимодействий.

Candidate generation должен быть дешевым и recall-oriented. В него входят hard filters по availability, geography, category compatibility, compliance и ограничениям заказчика; lexical/full-text search по title/description/profile; vector retrieval по заявке и представлению поставщика; возможно несколько generators с merge/dedup.

Ranking stage получает top-N поставщиков из retrieval и считает более дорогие признаки: историю взаимодействий заказчика и поставщика, response rate поставщика, win/bid history, category similarity, geo distance, deadline fit, предпочтения заказчика, ручные удаления/добавления, freshness и diversity constraints. Модель может быть GBDT/LambdaMART/learning-to-rank или более сложный neural reranker, но baseline должен быть простым.

Serving: online-заявка идет в retrieval service, затем ranker, затем post-processing rules. Важно логировать exposure и decision context, чтобы offline evaluation и retraining не теряли, какие поставщики вообще были доступны и показаны.

Для retrieval важен recall@K по поставщикам, которые могли дать полезный ответ; для ranker лучше использовать graded labels из bid, no-bid, delete/add и winner, а не только binary winner.

Winner label полезен, но слишком узкий. Поставщик мог быть релевантным, сделать bid и проиграть по цене или срокам. Заказчик мог удалить поставщика до приглашения, что является сильным негативным feedback. No-bid и ignore тоже разные сигналы: no-bid может значить нерелевантность или временную недоступность, ignore может быть проблемой attention.

Для candidate generation главная offline-метрика - recall@K по множеству потенциально релевантных поставщиков: поставщики с bid, вручную добавленные поставщики, historical winners в похожих заявках, поставщики, которых заказчик не удалил. Precision на retrieval stage вторична, если ranker справляется.

Для ranker можно использовать graded relevance: winner > bid responder > not deleted/invited > shown only; удаление заказчиком и explicit no-bid ниже. Метрики: NDCG@K или MAP/MRR, если есть graded/order labels; hit rate winner/bid@K; delete rate; manual add rate; online - time-to-submit, bid rate, успешная закупка, customer satisfaction и retention.

Runtime: разобрать заявку, нормализовать признаки, достать candidates, ранжировать, применить rules/diversity и залогировать exposure; cold start закрывается content/profile features, category text, geography, defaults и exploration.

Inference pipeline: заказчик создает заявку, сервис нормализует поля и таксономию заказчика, строит признаки/embedding заявки, применяет hard filters, запускает несколько retrievers, объединяет candidates, считает online/precomputed features, вызывает ranker, применяет business rules и возвращает top-K поставщиков. После показа обязательно логируется exposure и контекст решения.

Новый заказчик: меньше персональной истории, поэтому больше веса на content заявки, metadata компании, category text и global priors. Новый поставщик: использовать profile, self-declared categories, geo, external/vendor attributes и exploration slots. Редкая категория: fallback на parent category, текстовое описание, похожие категории и human/customer rules.

Нужны graceful fallbacks: если embedding service или feature store недоступны, система должна вернуть rule-based или lexical candidates, а не пустой список. Для B2B-продукта empty recommendations могут быть хуже менее точных recommendations.

Нельзя слепо embedding-ить category id: нужно использовать hierarchy, category text/description, локальные mappings заказчика, historical co-occurrence и fallback на parent/global taxonomy.

Проблема в том, что category name не всегда семантически полезен. У одного заказчика это "laptops", у другого внутренний код "A-16", у третьего дерево другой глубины. Поэтому sentence embedding category name может работать только на части данных.

Практичный подход: хранить category id заказчика как categorical feature; использовать hierarchy path и parent categories; добавлять category description, если она есть; маппить локальные категории в global taxonomy там, где возможно; строить статистики по историческим заявкам и поставщикам внутри категории; использовать text/item description как независимый сигнал.

В модели category features лучше комбинировать с текстом заявки, географией, историей поставщика и предпочтениями заказчика. Для cold или бессмысленных category codes fallback идет на parent category, text description заявки и historical behavior. Важно измерять качество отдельно по компаниям-заказчикам, потому что taxonomy drift может быть локальным.

Представление поставщика лучше строить из profile, category/geo distributions, response history и агрегированных сигналов по заявкам; простое среднее embeddings теряет интерпретируемость и быстро устаревает.

Простая идея - взять все заявки, где поставщик участвовал, и усреднить request embeddings. Это может дать baseline, но у него много проблем: embedding меняется после новых событий, смешивает разные домены и категории, плохо объясняется заказчику, теряет multimodal/structured признаки и может переусреднить поставщика, который работает в нескольких нишах.

Более надежное representation: признаки профиля поставщика, served geographies, category distribution, response/bid/win rates, recency, история по конкретным заказчикам, price/service constraints, textual description и агрегаты по successful requests. Можно иметь несколько vectors или feature blocks вместо одного "super embedding".

Для retrieval можно использовать вектор поставщика, но для final ranker стоит сохранить interpretable features. В B2B важна debuggability: почему поставщик показан, почему он подходит закупочной заявке, какие constraints сработали.

Selection bias видно по coverage и повторному показу одних поставщиков; снижать его можно exploration slots, counterfactual logging, stratified sampling и осторожными labels для losing bids.

Bias возникает потому, что модель обучается на поставщиках, которых старая система уже выбрала для показа или приглашения. Поставщики вне exposure почти не получают labels, и новая модель начинает усиливать старые предпочтения.

Диагностика: coverage поставщиков, category/geography coverage, доля повторно показанных поставщиков, long-tail exposure, add/delete rate по компаниям-заказчикам, качество на exploration buckets. Нужно логировать propensities или хотя бы policy/version/context, чтобы понимать, почему поставщик был показан.

Mitigation: controlled exploration slots, diversity constraints, randomization внутри безопасных buckets, active learning для редких категорий, debiased/off-policy evaluation там, где хватает данных. Labels должны быть аккуратными: winner - сильный positive; bid responder, который проиграл, не hard negative; no-bid и ignore имеют разный смысл; удаление заказчиком может быть сильнее negative, но тоже зависит от контекста.