Я бы сказал — частично раскрыта. Точный контур в примерах как раз и является решением. Не буду называть его полным, поскольку решение не является полностью универсальным. Сейчас прорабатывается вариант нейронная сеть обеспечивает object detection и bounding box, после чего в полученном прямоугольнике пытаемся получить четкую геометрию.
Рад, что вы даже зарегистрироваться решили ради этого комментария :) Давайте разберем основные моменты:
Конструктивная критика всегда во благо. Было интересно посмотреть, как работает розетка, поскольку в большинстве моментов поиск действительно адекватный.
Упоминание прямых рук очень напоминает владельцев ВАЗов — машина ок, едет, двери закрываются, если руки прямые — вообще проблем нет, даже ТО дешевле. Но смысл ведь «найти и купить», а не «попытаться найти, решить логическую задачу и возможно найти, а может быть и нет»
Что значит «и круглая голова»? :)
Если у вас нет ML и знаний (подразумевается knowledge graph) — как жить собираетесь?
Синонимы и бизнес-правила — крутые инструменты, вот только пока все проблемы найдутся, пока для них все правила пропишутся… А ведь это еще поддерживать нужно
«Нормально искать» это как? Использовать «широкий запрос», который уточнять фасетами? Или «не нашел — иди в каталог»?
Посыл статьи в другом — сложно улучшать поиск, не имея полной картины и более или менее быстрого способа проверить «глобальную ситуацию». Прикрутили характеристики — отвалился какой-то процент хороших запросов. И так со всем. «fiskars x27» — четкий сфокусированный intent, который должен в большинстве случаев приводить к покупке.
Подобные проблемы есть везде, но мы говорим о двух разных классах задач. Поиск по продуктам работает с хорошо структурированной информацией, с конечным количеством продуктов и более или менее понятным поведением пользователей (они хотят что-то купить).
А вот любопытно, это именно один запрос такой (подразумевается бизнес-правило) или тип запроса (работает более сложная структура данных и анализ). Ваше мнение?
Из вашего комментария следует, что статья предлагает не искать по всему контенту, хотя все как раз наоборот, поиск по всему контенту критичен, просто он должен учитывать контекст и зависимости, а не тупо находить ключевые слова
Есть много стратегий, которые позволяют выдать сколь-нибудь релевантные продукты. Если следовать вашей логике — священный рандом наше все
Обе стороны согласны, что вопрос неооднозначный, только в вашем мире пользователи вместо «да ну лесом, поищу в другом магазине», говорят: «они такие лапочки, попробую другой запросик, вдруг повезет». Я только предлагаю не терять тех, кто мыслит в негативном ключе (большинство)
В контексте обсуждаемой задачи (убедиться, что базовый поиск работает и человек, пришедший с четким намерением, получит желаемое) вполне работает
В данном конкретном случае это верное утверждение. В более глобальном смысле описываемый подход является одним из
Тоже верно подмечено: именно неявно заданные «золотые» наборы (или простой способ проверки полученных результатов на соответствие таковым) могут сохранить массу ресурсов
В любом случае, благодарю за комментарии и внимательность. Напишу вам отдельно, когда junit для поиска будет готов.
Да, но это отдельная история. Кстати, даже если did-you-mean не реализован, проблема относительно легко решается синонимами. Человеки ошибаются, поэтому:
Если мы говорим о близости двух последовательностей символов — то это как раз очень серьезное упрощение. Asus и ass несомненно близки (levenshtein distance = 1), но, согласитесь, совершенно несравнимы :)
Кроме того, с точки зрения покупателя, это слишком «глубокие» детали. Он не получает желаемого и, что часто хуже, видит продукты, которые уж точно не ожидает увидеть (в итоге
разочарование, негативное отношение к магазину и т.д.)
Во-вторых, как вы объективно отличите ошибку в запросе (которую надо исправить, чтобы продать) от правильного запроса, который исправлять не надо?
Не хотел бы смешивать поиск, did-you-mean и search query-disambiguation-logic. Напишу отдельно о том, как можно действительно понять и поправить пользователя. В данном конкретном случае предусловие очень простое — поисковый запрос не содержит ошибок.
Очень, очень, очень базовой. Она, несомненно, должна быть, но вопрос в том, какую долю — опять-таки, объективно — из поисковых запросов этот инструмент покрывает.
А вот это очень хороший вопрос. Давайте проследим следующую цепочку рассуждений (для обычного e-commerce проекта):
текстовый поиск преобладает
product title обычно имеет наибольший вес при поиске
несколько уникальных ключевых слов в поисковой строке, совпадающих с таковыми в названии продукта (title), однозначно гарантируют продукту большой score
Если, по какой-либо причине, эта логика нарушается (например, кто-то указал запредельно большой вес для описания продукта), то у нас проблема, о которой точно нужно знать, поскольку это, как вы отметили, база.
Соответственно, покрытие поисковых запрос не слишком критично. Причины две:
поисковые запросы это история, мы не знаем что и как будут искать дальше
если ломается базовая логика поиска — любой запрос потенциально «испорчен»
Для поисковых запросов обычно используют precision@k или MAP, потому что для построения нормальных precision/recall вам нужно работать со всем массивом возвращенных результатов, а это не очень осмысленно.
Да, все правильно, полный result set никто не анализирует, тем не мене «правильный» (или золотой) набор необходим в любом случае
А если чуть более детально, чем интересный? Компаний, которые разрабатывают XACML инструменты, не так много, соответственно опыт сотрудника одной из них очень интересен. Поделитесь?
> Хотя эта схема из стандарта может выглядеть немного устрашающе на первый взгляд, в ней все довольно просто.
На самом деле нет :)
К сожалению, этот психологический прием не работает с XACML. Вспомнилась статья в университетском журнале — после слов «несложно показать, что» следовало несколько страниц формул. У вас похожий подход, «XACML простой», а затем, предположительно, многостраничное пояснение «простых моментов» :)
Например, PolicySet может содержать вложеный PolicySet, который в свою очередь является «контейнером» для других PolicySet'ов и т.д., соответственно финальная иерархия будет достаточно сложной для понимания (на каждом уровне свой combining algorithm и т.д.)
Все еще легко? Тогда насколько хорошо вы сможете объяснить факт существования следующей таблицы? :)
> Тестирование выполнения политик. Администратор может указать нужный контекст, выбрать политики и пошагово изучить процесс вычисления, используя для этого удобный интерфейс.
Мы ведь говорим о системе, которая может быть life-critical. Соответственно, один из вопросов: сможет ли Администратор быть на все 100% уверен в своем наборе политик проведя несколько «точечных» тестов с несколькими контекстами?
Но это я так, на самом деле спасибо за статью и за все детали. С ней порог вхождения существенно ниже.
Условный ROI вполне поддается оценке и подсчету, это ведь development tool впервую очередь. Из реальных примеров: один известный банк решает как-то более цивилизованно управлять доступом к своим документам, сервисам и т.д. Внутренний отдел, который занимается разработкой и интеграцией оценивает задачу и предлагает варианты. Все варианты оцениваются с точки зрения затрат на разработку, разветывание, интеграцию и т.д.
Один из вариантов предполагает «завязку» на стандарте и приоретение готового решения/инфраструктуры. Стоимость других вариантов также известна. Сравнивают, видят приятную экономию и времени и денег, принимают решение о покупке.
Хочу опровергнуть ваше финальное утверждение. Бизнес как раз и покупает ABAC, причем очень активно. Покупают и средние и большие компании. Я, признаться, не сторонник XACML, хотя и работаю в компании, которая решения исключительно на его базе и продает.
Основная проблема на мой взляд — стандарт явно «не удался»: местами перегружен ерундой, местами откровенно сложен, ну и просто достаточно высокий порог вхождения. Но, как уже было отмечено, это стандарт.
Проблема еще и в том, что XACML не очень легко спрятать за красивой «ширмой», как это делает, например, С с ассемблером. Но решение можно найти всегда. А компании, которые купят или разработают XACML решения, образуют новый рынок, на котором появятся новые инструменты, облегачающие работу и оптимизирующие все и вся.
Да, от PAP очень многое зависит :) Дело в том, что я как раз и работаю в Axiomatics. Работаю достаточно долго и уже успел насмотреться на многие страшилки XACML. Тема для отдельного разговора, на самом деле, но вы правильно заметили, это стандарт, после этого можно переходить к минусам :)
ABAC тоже решает многие проблемы только на бумаге. Предполагаю, вы используете XACML, насколько сложны ваши полиси? Все легко и удобно? Только не говорите про ALFA :)
Посыл статьи в другом — сложно улучшать поиск, не имея полной картины и более или менее быстрого способа проверить «глобальную ситуацию». Прикрутили характеристики — отвалился какой-то процент хороших запросов. И так со всем. «fiskars x27» — четкий сфокусированный intent, который должен в большинстве случаев приводить к покупке.
В любом случае, благодарю за комментарии и внимательность. Напишу вам отдельно, когда junit для поиска будет готов.
Видел куда более заковыристые списки :)
Если мы говорим о близости двух последовательностей символов — то это как раз очень серьезное упрощение. Asus и ass несомненно близки (levenshtein distance = 1), но, согласитесь, совершенно несравнимы :)
Кроме того, с точки зрения покупателя, это слишком «глубокие» детали. Он не получает желаемого и, что часто хуже, видит продукты, которые уж точно не ожидает увидеть (в итоге
разочарование, негативное отношение к магазину и т.д.)
Не хотел бы смешивать поиск, did-you-mean и search query-disambiguation-logic. Напишу отдельно о том, как можно действительно понять и поправить пользователя. В данном конкретном случае предусловие очень простое — поисковый запрос не содержит ошибок.
А вот это очень хороший вопрос. Давайте проследим следующую цепочку рассуждений (для обычного e-commerce проекта):
Если, по какой-либо причине, эта логика нарушается (например, кто-то указал запредельно большой вес для описания продукта), то у нас проблема, о которой точно нужно знать, поскольку это, как вы отметили, база.
Соответственно, покрытие поисковых запрос не слишком критично. Причины две:
Да, все правильно, полный result set никто не анализирует, тем не мене «правильный» (или золотой) набор необходим в любом случае
Например moto+g6 — фломастеры
На самом деле нет :)
К сожалению, этот психологический прием не работает с XACML. Вспомнилась статья в университетском журнале — после слов «несложно показать, что» следовало несколько страниц формул. У вас похожий подход, «XACML простой», а затем, предположительно, многостраничное пояснение «простых моментов» :)
Например, PolicySet может содержать вложеный PolicySet, который в свою очередь является «контейнером» для других PolicySet'ов и т.д., соответственно финальная иерархия будет достаточно сложной для понимания (на каждом уровне свой combining algorithm и т.д.)
Все еще легко? Тогда насколько хорошо вы сможете объяснить факт существования следующей таблицы? :)
Мы ведь говорим о системе, которая может быть life-critical. Соответственно, один из вопросов: сможет ли Администратор быть на все 100% уверен в своем наборе политик проведя несколько «точечных» тестов с несколькими контекстами?
Но это я так, на самом деле спасибо за статью и за все детали. С ней порог вхождения существенно ниже.
Один из вариантов предполагает «завязку» на стандарте и приоретение готового решения/инфраструктуры. Стоимость других вариантов также известна. Сравнивают, видят приятную экономию и времени и денег, принимают решение о покупке.
Основная проблема на мой взляд — стандарт явно «не удался»: местами перегружен ерундой, местами откровенно сложен, ну и просто достаточно высокий порог вхождения. Но, как уже было отмечено, это стандарт.
Проблема еще и в том, что XACML не очень легко спрятать за красивой «ширмой», как это делает, например, С с ассемблером. Но решение можно найти всегда. А компании, которые купят или разработают XACML решения, образуют новый рынок, на котором появятся новые инструменты, облегачающие работу и оптимизирующие все и вся.