Как мы проектировали поиск по закупкам и почему «найти больше» оказалось неправильной метрикой

Когда говорят об автоматизации закупок, обычно вспоминают электронные торговые площадки, аналитику, интеграции, API, автоматическую обработку документов и, конечно, искусственный интеллект ^[1]. Но до всего этого существует гораздо более простая задача: как среди большого потока закупок найти несколько процедур, которые действительно подходят конкретной компании?

На первый взгляд это обычная задача поиска по структурированной базе. У закупки есть название, заказчик, регион, начальная цена, сроки подачи заявок, классификаторы и другие параметры. Кажется, что достаточно проиндексировать данные, добавить несколько фильтров и показать пользователю результаты. На практике оказалось, что основная сложность начинается именно после этого.

Мы работаем с государственными и коммерческими закупками больше 11 лет, поэтому при проектировании системы поиска могли отталкиваться не только от структуры данных, но и от того, как подрядчики действительно выбирают новые контракты. И довольно быстро выяснилось: профессиональный тендерный специалист и собственник небольшой компании смотрят на одну и ту же закупку совершенно по-разному.

Сначала пришлось разделить поиск и анализ

Тендерному специалисту могут быть нужны требования документации, обеспечение заявки и исполнения контракта, опыт ^[2] участника, проект договора, сведения о заказчике и множество других параметров. У собственника бизнеса первый набор вопросов обычно гораздо короче: что нужно сделать, где находится объект, сколько стоит контракт, когда заканчивается приём заявок и способна ли компания вообще выполнить эту работу. И только если закупка проходит этот первичный фильтр, появляется смысл подробно изучать документацию.

Так одна большая задача разделилась на две: сначала найти потенциально интересный контракт, а затем понять, имеет ли смысл в нём участвовать.

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

Пользователь не думает категориями базы данных

Представим компанию, которая занимается ремонтом кровель. Для информационной системы её потенциальные заказы находятся внутри большого массива строительных процедур. Но подрядчику нужны не абстрактные «тендеры на строительство». Ему нужны кровельные работы в определённых регионах, в подходящем ценовом диапазоне и с такими условиями, при которых компания действительно способна исполнить контракт.

Дорожный подрядчик работает уже с другим сегментом закупок. Компания по внутренней отделке — с третьим. Подрядчик по инженерным системам — с четвёртым. Получается, что одна большая категория для информационной системы фактически представляет собой несколько совершенно разных рынков для бизнеса.

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

Это немного меняет привычный взгляд на поисковую систему. Большая выдача перестаёт быть признаком качества.

Почему одного поискового поля оказалось недостаточно

Самый привлекательный интерфейс можно представить очень просто: пользователь вводит «ремонт кровли» и получает идеальную подборку.

В реальных закупках всё оказалось менее элегантно. Даже достаточно конкретный запрос способен вернуть поставку кровельных материалов, проектирование, обследование конструкций, техническое обслуживание или работы в регионе, куда подрядчик никогда не поедет.

Поэтому поисковый запрос постепенно превратился в комбинацию нескольких измерений:

тематика + исключения + география + классификация + стоимость + сроки

В исходной модели для этого использовались ключевые слова, минус-слова, регион, ОКПД2, диапазон начальной цены контракта, дата публикации и срок подачи заявок.

Особенно интересными оказались минус-слова. Ключевые слова отвечают на вопрос, что должно присутствовать в выдаче. Исключения позволяют определить, чего там быть не должно. Если говорить языком информационного поиска, первые помогают работать с полнотой выдачи, вторые — с её точностью. Для пользователя всё значительно проще: ему приходится вручную открывать меньше ненужных карточек.

600 найденных закупок могут быть хуже 30

У систем поиска есть очень привлекательная метрика — количество найденных процедур. Чем цифра больше, тем солиднее выглядит результат.

Но представим две системы. Первая по запросу подрядчика нашла 600 закупок, вторая — 30. Если среди первых 600 действительно подходят пять процедур, а среди 30 — десять, вторая система очевидно полезнее.

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

Фактически вместо метрики «сколько мы нашли» появляется более содержательный вопрос: какая доля найденного действительно полезна пользователю?

Но бесконечно добавлять фильтры тоже нельзя

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

В какой-то момент простой поиск превращается в профессиональную аналитическую систему. На большом экране с этим ещё можно работать. На смартфоне двадцать параметров превращают поиск в довольно утомительную анкету.

Поэтому появляется обратная задача: определить минимальный набор параметров, который действительно улучшает качество выдачи, но не заставляет пользователя полчаса настраивать поиск.

Это обычный конфликт ^[3] между точностью настройки и сложностью интерфейса. Чем больше условий разрешено задать, тем точнее потенциальная выдача. Но чем сложнее настройка, тем выше вероятность, что пользователь просто не станет ей пользоваться.

Сохранённый запрос оказался важнее нового поиска

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

Поэтому логичным объектом системы становится не только закупка, но и поисковый профиль пользователя. Один раз задаётся комбинация параметров, после чего человек работает преимущественно с обновлениями выдачи. В исходной реализации такие наборы параметров сохранялись как шаблоны для повторного использования.

Это уже немного другой сценарий взаимодействия. Классический поиск выглядит как «сформулировал запрос → получил результат». Здесь полезнее модель «описал интересующий сегмент рынка → регулярно проверяю, что нового внутри него появилось».

По сути, поиск превращается в мониторинг.

Смартфон оказался полезен далеко не для всего

Отдельный вопрос возник с мобильным интерфейсом. Если система доступна на смартфоне, появляется естественное желание перенести туда как можно больше функций.

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

Изучать на телефоне проектную документацию на несколько сотен страниц можно. Работать с большой строительной сметой тоже можно. Вопрос только в том, зачем добровольно так с собой поступать.

Поэтому мобильный сценарий оказался гораздо короче: проверить новые результаты → быстро посмотреть основные параметры → сохранить интересное → позже перейти к полноценному анализу.

Телефон в этой модели не заменяет рабочее место тендерного специалиста. Он становится первым уровнем фильтрации.

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

Что показывать в карточке закупки

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

На практике это быстро перегружает интерфейс.

Если мобильная карточка содержит почти всё, что есть в исходной процедуре, пользователь начинает изучать её примерно столько же, сколько саму документацию. Поэтому мы пришли к другой логике ^[4]: первый экран должен отвечать не на вопрос «что вообще известно об этой закупке?», а на вопрос «стоит ли мне тратить на неё время?».

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

Следующий уровень — персонализированное ранжирование

Когда обычные фильтры начинают работать приемлемо, возникает более интересная задача.

Система потенциально может знать специализацию компании, регионы поиска, сохранённые запросы и поведение ^[5] пользователя: какие процедуры он открывает, какие сохраняет, а какие постоянно пропускает.

Тогда можно двигаться от обычной фильтрации к ранжированию.

Вместо:

«Вот 500 закупок, соответствующих формальным параметрам».

появляется:

«Вот несколько процедур, наиболее похожих на те, которые обычно интересуют эту компанию».

И здесь простой поисковик постепенно начинает приобретать признаки рекомендательной системы. В исходном проектировании мы как раз пришли к идее перехода от формальной фильтрации к персонализированной выдаче на основе поведения ^[6] пользователя.

А затем заканчиваются возможности метаданных

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

Особенно это заметно в строительстве. Существенная информация может находиться внутри технического задания, ведомости объёмов работ, сметы, проекта или приложенной спецификации.

Поэтому следующий логичный уровень развития подобных поисковых систем — анализировать не только карточку закупки, но и содержание прикреплённых документов. Такой переход уже требует других инструментов: полнотекстового поиска, извлечения сущностей, классификации документов, семантического поиска и потенциально языковых моделей. Именно анализ приложенной документации был обозначен как следующий логичный уровень системы в исходном материале.

Здесь, правда, появляется важное различие. Ошибка ^[7] обычного ранжирования означает, что пользователь увидит не самый подходящий результат. Ошибка при интерпретации документации может повлиять на решение бизнеса об участии в контракте.

Поэтому требования к точности и контролю результата становятся совершенно другими.

Что мы поняли в процессе

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

Гораздо интереснее оказались точность и полнота выдачи, отрицательные условия поиска, сохранённые поисковые профили, информационная архитектура карточки, ранжирование, поведенческие сигналы и анализ содержимого документов.

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

Иногда хороший инструмент не пытается выполнить работу за человека. Он просто уменьшает объём информационного шума, через который человеку приходится пройти перед принятием решения.

Для поиска закупок это оказалось гораздо важнее количества функций, которые можно было добавить в интерфейс.