Search engines
IT systems testing
Development for e-commerce
Increasing Conversion Rate
Search engine optimization
Comments 12
+1
Например, если в ассортименте магазина нет некоторых продуктов, не стоит их “находить”. И уж тем более смешными выглядят результаты, полученные путем неоправданного упрощения исходного поискового запроса

Во-первых, это не упрощение, а поиск по близости. Во-вторых, как вы объективно отличите ошибку в запросе (которую надо исправить, чтобы продать) от правильного запроса, который исправлять не надо?


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

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


PS


F-measure (Precision/Recall)

Для поисковых запросов обычно используют precision@k или MAP, потому что для построения нормальных precision/recall вам нужно работать со всем массивом возвращенных результатов, а это не очень осмысленно.

0
Во-первых, это не упрощение, а поиск по близости.

Если мы говорим о близости двух последовательностей символов — то это как раз очень серьезное упрощение. Asus и ass несомненно близки (levenshtein distance = 1), но, согласитесь, совершенно несравнимы :)

Кроме того, с точки зрения покупателя, это слишком «глубокие» детали. Он не получает желаемого и, что часто хуже, видит продукты, которые уж точно не ожидает увидеть (в итоге
разочарование, негативное отношение к магазину и т.д.)
Во-вторых, как вы объективно отличите ошибку в запросе (которую надо исправить, чтобы продать) от правильного запроса, который исправлять не надо?

Не хотел бы смешивать поиск, did-you-mean и search query-disambiguation-logic. Напишу отдельно о том, как можно действительно понять и поправить пользователя. В данном конкретном случае предусловие очень простое — поисковый запрос не содержит ошибок.
Очень, очень, очень базовой. Она, несомненно, должна быть, но вопрос в том, какую долю — опять-таки, объективно — из поисковых запросов этот инструмент покрывает.

А вот это очень хороший вопрос. Давайте проследим следующую цепочку рассуждений (для обычного e-commerce проекта):
  1. текстовый поиск преобладает
  2. product title обычно имеет наибольший вес при поиске
  3. несколько уникальных ключевых слов в поисковой строке, совпадающих с таковыми в названии продукта (title), однозначно гарантируют продукту большой score

Если, по какой-либо причине, эта логика нарушается (например, кто-то указал запредельно большой вес для описания продукта), то у нас проблема, о которой точно нужно знать, поскольку это, как вы отметили, база.
Соответственно, покрытие поисковых запрос не слишком критично. Причины две:
  • поисковые запросы это история, мы не знаем что и как будут искать дальше
  • если ломается базовая логика поиска — любой запрос потенциально «испорчен»

Для поисковых запросов обычно используют precision@k или MAP, потому что для построения нормальных precision/recall вам нужно работать со всем массивом возвращенных результатов, а это не очень осмысленно.

Да, все правильно, полный result set никто не анализирует, тем не мене «правильный» (или золотой) набор необходим в любом случае
+1
Он не получает желаемого и, что часто хуже, видит продукты, которые уж точно не ожидает увидеть

Вот вопрос "хуже ли то, что он видит неожиданные продукты" (в ситуации, когда искомых нет) — он совершенно не однозначный.


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

… и как часто это бывает?


Соответственно, покрытие поисковых запрос не слишком критично

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


тем не мене «правильный» (или золотой) набор необходим в любом случае

Ну да, без него банально невозможно оценить, как работает ваш поиск (даже если этой золотой набор задан неявно).

0
Давайте подытожим:

  1. Обе стороны согласны, что вопрос неооднозначный, только в вашем мире пользователи вместо «да ну лесом, поищу в другом магазине», говорят: «они такие лапочки, попробую другой запросик, вдруг повезет». Я только предлагаю не терять тех, кто мыслит в негативном ключе (большинство)
  2. В контексте обсуждаемой задачи (убедиться, что базовый поиск работает и человек, пришедший с четким намерением, получит желаемое) вполне работает
  3. В данном конкретном случае это верное утверждение. В более глобальном смысле описываемый подход является одним из
  4. Тоже верно подмечено: именно неявно заданные «золотые» наборы (или простой способ проверки полученных результатов на соответствие таковым) могут сохранить массу ресурсов


В любом случае, благодарю за комментарии и внимательность. Напишу вам отдельно, когда junit для поиска будет готов.
0
Я только предлагаю не терять тех, кто мыслит в негативном ключе (большинство)

Почему большинство-то? Откуда вы это знаете? Я вот не ухожу из таких магазинов.


В данном конкретном случае это верное утверждение.

Тогда вы оцениваете не "качество продуктового поиска" (заявленное в заголовке), а качество поиска по точному совпадению.

+1
Я вот не ухожу из таких магазинов.

наверное у Вас много свободного времени и очень большое желание все-таки найти «черную кошку в темной комнате» :)… уверен, что если магазин предлагает куклу как альтернативу мультитул, то скорее всего это не тот магазин и нет смысла искать мультитул в магазине игрушек… я бы ушел
0

Нет, я просто не вижу смысла уходить из амазона, если я не нашел в нем конкретный товар — на вероятность нахождения следующего товара это никак не влияет.

0

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

0
Да, но это отдельная история. Кстати, даже если did-you-mean не реализован, проблема относительно легко решается синонимами. Человеки ошибаются, поэтому:
microtic, mikrotic, microtik -> mikrotik

Видел куда более заковыристые списки :)
Only those users with full accounts are able to leave comments. , please.