Статьи

Правила поиска (бизнеса)!

Октябрь 12, 2018

Вступление

Один из самых частых запросов, которые мы получаем от клиентов, заключается в том, что им нужны более простые способы выражения бизнес-потребностей в рамках их поисковой инфраструктуры. Например, представьте, что вы большой сайт электронной коммерции, и вы хотите добавить фасеты для 4 «C» алмазного качества каждый раз, когда кто-то искал слово «diamond», но когда появляется запрос на «наушники», вы хотите добавить аспекты размера, стиля, производителя и т. д.

В поисковой платформе LucidWorks это использовалось для того, чтобы ваша поисковая команда реализовывала достаточно обширный бизнес-уровень, который был достаточно гибким, чтобы позволить вам изменять подобные вещи, не выпуская новый код, не перебрасывая сервер и т. Д. В некоторых контекстах LucidWorks имел некоторые минимальные возможности для выражения изменений в релевантности на основе потребностей бизнеса. Например, редакторское повышение ( QueryElevationComponent на языке Solr) позволяет повысить конкретные результаты до вершины набора результатов для заданных запросов или исключить конкретные документы. Кроме того, возможности функции Solr(функциональные запросы и сортировка по функциям) позволяют выражать довольно сложные выражения для повышения содержимого на основе значений определенных полей. К сожалению, если ваша поисковая команда не раскрыла эти вещи через интерфейс администратора, для использования этих возможностей по-прежнему требовался программист или, по крайней мере, кто-то, знающий о конфигурации Solr, для добавления возможностей. В LucidWorks 2.1 мы решили исправить эти ограничения, внедрив решение, которое позволило бы пользователям лучше выражать потребности бизнеса в динамичной и динамичной среде. Тем не менее, в отличие от большинства поисковых систем, которые принимают « не изобретено здесь»«Подходя к функциональности и затрачивая много усилий на создание чего-либо с нуля (угадайте, кто за это платит?), Мы решили, что будет гораздо полезнее использовать возможности существующего, очень большого и вполне способного сообщества бизнес-правил и их проверенные механизмы для захвата динамических бизнес-требований. Для этого мы добавили две функциональности в LucidWorks 2.1:

  1. Основа для интеграции 3 — й партии бизнес — правила , решения в контексте поиска, как во время индексации, а также время поиска. Таким образом, если в вашей компании уже есть механизм правил, такой как IBM JRules или Fair Isaac Blaze Advisor, вы можете воспользоваться этими инвестициями, подключив их к LucidWorks через нашу инфраструктуру. Обратите внимание, что для этого вам придется написать некоторый код, но он довольно минимален, и мы будем рады помочь.
  2. Работающая, полностью интегрированная реализация, использующая лицензионный движок Red Hat Apache по правилам Drools, который позволяет пользователям применять бизнес-правила в широком спектре функциональных возможностей LucidWorks, о которых мы расскажем ниже. Несмотря на странное название (которое является отличительной чертой открытого исходного кода), Drools — это надежный, хорошо поддерживаемый, хорошо документированный проект с открытым исходным кодом, широко используемый.

Quick Drools Primer

После оценки ряда механизмов правил, как закрытых, так и открытых, мы выбрали Drools по ряду причин:

  1. Простой в использовании язык правил со связанным веб-редактором
  2. Реализует алгоритм Rete , который в значительной степени является стандартом для такого рода вещей.
  3. 100% создание Java для простой установки и интеграции
  4. Apache лицензирован
  5. Стоимость (т.е. бесплатно как в пиве)

На Drools уже есть много учебных пособий, книг и тому подобного, поэтому я не буду вдаваться в подробности о Drools, кроме краткого обзора и нескольких ресурсов. Drools работает так, что приложения вводят факты в так называемую рабочую память, а затем оценивают, какие пользовательские правила должны быть запущены с учетом фактов в рабочей памяти. Правила — это, по сути, предложения if-then, которые позволяют авторам правил выражать, какие факты должны быть истинными (предложение «if» или «когда» в жаргоне Drools), а затем то, что должно происходить, когда факт является истинным (предложение «then» ). Факт в Drools — это, по сути, любой Java-объект, который приложение хочет внедрить. Для LucidWorks факты — это такие вещи, как входной запрос или индексируемый документ и другие объекты, используемые для обработки запросов в Solr.В качестве примера написания правил в Drools, которые оперируют фактами, вот «Hello LucidWorks»:

    rule "HelloLucidWorks"

    no-loop

    when

    $rb : ResponseBuilder();

    then $rb.rsp.add("hello", "lucidworks"); end

Все, что он делает, это проверяет, есть ли в рабочей памяти объект с именем ResponseBuilder (знакомые с Solr распознают его как один из ключевых объектов при обработке запросов в SearchComponent), а затем добавляют пару ключ-значение в этот ResponseBuilder. , Естественно, как и во всех примерах «Hello World», это не так уж интересно, за исключением того, что быстро замечает, что Drools во многом похож на Java и что это похоже на программирование, оба из которых верны на первый взгляд. Drools выглядит как Java, но он также поддерживает правила написания пользователя через пользовательский интерфейс Guvnor (который не очень похож на программирование или Java) или через домен-специфический язык (DSL), который можно адаптировать к вашему конкретному домену. Вместо того, чтобы превратить это в длинное руководство по Drools, давайте двигаться дальше, но не без предварительного обращения к следующим ресурсам:после чего мы попробуем это в действии:

  • www.drools.org — главное место, где можно начать с Drools и найти всю последнюю документацию
  • Слюни Книги на Амазоне. Обратите внимание, что есть несколько хороших, но не забудьте получить одну версию 5.

LucidWorks + Drools

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

  1. Загрузите LucidWorks со страницы загрузки и установите его в соответствии с инструкциями по установке и запустите LucidWorks. Я буду ссылаться на место установки, которое вы выберете здесь, как $ LW_HOME.
  2. Загрузите образец документов электронной почты Apache с http://www.lucidimagination.com/devzone/technical-articles/scaling-mahout и распакуйте его (tar -xf ibm.tar.gz). Я буду ссылаться на расположение этих файлов как $ CONTENT.
  3. Войдите в администратор LucidWorks по адресу http: // localhost: 8989 / и создайте новую коллекцию с именем ASFArchives.
  4. Создайте новый источник данных файловой системы и укажите его на $ CONTENT (то есть полный путь к каталогу, в который вы распаковали ibm.tar.gz). Я назвал свой источник данных «Маленький» и использовал значения по умолчанию для остальных параметров. Для получения дополнительной информации см. Руководство пользователя LucidWorks .
  5. После сохранения источника данных начните сканирование. Вы можете зафиксировать результаты в любое время, зайдя по адресу http: // localhost: 8989 / и нажав кнопку фиксации (она также будет зафиксирована сама по себе, но если ваш нетерпеливый человек, как я, вы можете принудительно ее применить).
  6. Через некоторое время попробуйте выполнить поиск, например «cocoon» ( http: // localhost: 8989 / collection / ASFArchives / search? Q = cocoon )
  7. Мы вернемся к этим данным позже, однако, как только сканирование будет завершено, вы должны увидеть примерно 370 000 документов в коллекции.

Пока это все для настройки, поэтому давайте переключимся и сосредоточимся на написании некоторых правил. В LucidWorks 2.1 наша интеграция требует редактирования файла правил Drools с помощью текстового редактора. Вы также можете использовать пользовательский интерфейс Drools Guvnor и сохранить файлы в нужном месте, но я лично не проверял это. Наша настройка по умолчанию поставляется с набором файлов правил по умолчанию, которые подключаются в различные места внутри LucidWorks. Все эти файлы правил находятся в $ LW_HOME / conf / solr / cores / asfarchives_1 / conf / rules (для каждого вашего ядра) и имеют суффикс файла .drl. В каталоге правил должно быть 4 файла, названных и описанных ниже:

  • defaultDocs.drl — содержит правила, которые применяются во время индексации как часть процессора обновлений в Solr.
  • defaultFirst.drl — содержит правила, которые применяются во время поиска и запросов на фасетирование до запуска других компонентов Solr SearchComponents. Другими словами, это лучшее место для работы с необработанным запросом, прежде чем будут рассчитаны какие-либо результаты.
  • defaultLast.drl — содержит правила, которые применяются после запуска других компонентов поиска. Другими словами, это лучшее место, чтобы изучить результаты и внести изменения
  • defaultLanding.drl — содержит правила, которые можно использовать для короткого замыкания поисковых запросов все вместе.

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

Чтобы начать, давайте откроем defaultFirst.drl в редакторе. Тебе следует увидеть:

# This file contains Lucid’s default rules, as specified in the default solrconfig.xml
    # The default configuration uses this rules file in three places:
    # 1. The Landing Page component, which can be used to short circuit results and just return a landing page
    # 2. The RulesComponent configured to run before all other SearchComponents (there is also
    # one configured to run after all other components, except debug.
    # 3. The RulesDocTransformer, which can be used to alter the fields on a document before it
    # is written out.
    #
    # Rule writers may rely on, when using the RulesComponent, the LandingPageComponent or the RulesDocTransformerFactory, the fact that
    # the name of the “handler” (specified in the configuration) will be available as part of the Request context (request.getContext().get(“rulesHandler”)) along
    # with the phase the component is in (prepare or process — getContext().get(“rulesPhase”)) such that rules can be written that target a specific
    # handler and/or a specific phase.
    #
    #
    package rules;

    #Some common imports
    import org.apache.solr.handler.component.ResponseBuilder;
    import function com.lucid.rules.drools.DroolsHelper.*;
    import org.apache.solr.common.SolrDocument;
    import org.apache.lucene.search.Query;
    import org.apache.solr.common.params.SolrParams;
    import org.apache.solr.common.params.ModifiableSolrParams;

    import org.slf4j.Logger;
    global org.slf4j.Logger logger;

With that out of the way, let’s write a rule.  In this case, I want to force a query of “cocoon” (since we are searching Apache email archives) to only return results that contain both “cocoon” and “compiled” (just for grins, it really isn’t meaningful in a real situation.)  To do this, we need to add a rule to defaultFirst.drl file.   For a reference, run the query now (http://localhost:8888/solr/ASFArchives/lucid?q=cocoon&start=0&rows=10&wt=json&indent=true&rules=false&role=DEFAULT) and examine some of the results.  As the name implies, this rules file gets fired first, before things like query parsing take place so we will be operating on the query String, as opposed to the parsed Query object (for those familiar with Lucene, which we can also do if we want using other rules files.)  Here’s a sample of what the rule might look like:

    rule “cocoon”
    no-loop
    when
    $rb: ResponseBuilder($qStr : req.params.get(“q”).contains(“cocoon”));
    then
    addToResponse($rb, “origQuery”, $qStr);
    modRequest($rb, “q”, “cocoon AND compiled”);
    end

Правило довольно простое. Сначала мы расскажем Drools кое-что о правиле (name, no-loop), а затем предложение «if». В этом случае мы хотим увидеть, соответствует ли параметр запроса Solr («q») слову «кокон». Если это так, то правило сработает и сделает две вещи:

  1. Запишите исходный запрос в ответ как «origQuery», чтобы наше приложение могло знать, что запрос был изменен
  2. Измените запрос, установив параметр «q» для нового запроса.

Методы addToResponse и modRequest являются частью импорта DroolsHelper и предоставляются LucidWorks. Класс DroolsHelper содержит множество удобных методов для манипулирования фактами в ваших правилах. Они описаны в документации LucidWorks. Следует отметить одну вещь: поскольку вы изменяете факт в системе, вы должны быть осторожны, чтобы не помещать Drools в бесконечный цикл из-за того, что он затем повторно оценит все правила, что вызовет повторное срабатывание этого правила. Модификатор правила «без цикла» предотвращает это. У Drools также есть некоторые другие механизмы для управления этим поведением в более сложных ситуациях, поэтому я советую вам прочитать документацию, чтобы узнать больше.

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

  1. Перезапустите LWE, который не подходит для работающей системы, но работает.
  2. Измените настройку индексации, например время мягкого принятия
  3. Нажав на Solr CoreAdmin. Смотрите http://wiki.apache.org/solr/CoreAdmin

Теперь попробуйте выполнить запрос сверху снова, но на этот раз мы включим компонент правил: http: // localhost: 8888 / solr / ASFArchives / lucid? Q = cocoon & start = 0 & rows = 10 & wt = json & indent = true & rules = true & role = DEFAULT в запросе, передавая rules = true вместо false. Просматривая свои результаты, вы должны увидеть несколько вещей:

В ответ:

"origQuery":"cocoon"

В responseHeader вы заметите, что параметр «q» изменен: 

"q":"cocoon AND compiled"
  1. Гораздо меньше результатов, и они содержат как кокон, так и скомпилированный (или варианты компиляции, так как мы находимся)

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

Теперь вы можете задаться вопросом, откуда ему знать, что параметр «q» находится в рабочей памяти? Это потому, что я знаю, что все входящие SolrParams находятся в рабочей памяти (подробнее о том, как это работает позже с помощью так называемого FactCollector) при работе с поисковыми запросами, а также следующие, многие из которых предоставлены для удобства, так как многие из них также могут быть доступ через объект ResponseBuilder:

  • Объект ResponseBuilder
  • Объект IndexSchema
  • Объект SolrRequest
  • Контекст (это карта в Solr)
  • SolrResponse (именно так мы смогли написать в него origQuery)
  • Все запросы фильтра (параметры fq)
  • Все аспекты фасетов (при условии расчета фасетов)
  • Спецификация сортировки (SortSpec)
  • Спецификация группировки (GroupingSpecification)
  • Результаты (DocListAndSet)

На стороне индексирования FactCollector имеет команду ввода (AddUpdateCommand), документ ввода и IndexSchema. Преобразователь правил имеет документ для вывода, внутренний идентификатор документа Lucene и IndexSchema. Каждая из этих вещей может быть полезна, когда речь идет о написании правил. А пока давайте закончим, рассмотрев некоторые другие варианты использования и идеи, касающиеся использования правил.

Управляя Землей

Если вы обращали внимание, вы, вероятно, заметили, что мы поставляем несколько файлов правил по умолчанию. Они позволяют вставлять правила в разные части запросов как для индексации, так и для поиска. Например, у нас есть клиенты, которые накладывают свою таксономию на документы во время сканирования / индексации, просматривая найденный URL-адрес, а затем просматривая соответствующую категорию и добавляя ее в качестве поля в документе на основе правил. В других случаях документы изменяются динамически по мере их выхода из LucidWorks путем добавления или изменения полей с использованием возможностей преобразователя документов Solr. first »движок правил, который использует файл правил defaultFirst.drl. Дополнительную информацию смотрите в документации.) В качестве еще одной удобной уловки,имейте в виду, что все переданные параметры представляются Drools как факты, а остальная часть LucidWorks игнорирует их. Так, например, вы можете передавать такие вещи, как идентификаторы пользователей, местоположения пользователей или другую бизнес-информацию, предоставляемую вашим приложением, а затем использовать их в своих правилах.

Кроме того, есть несколько других вещей, которые вы можете сделать, чтобы настроить установку в соответствии с вашими потребностями. Например, поскольку большая часть этого реализована как SearchComponent, вы можете разместить его в любом месте цепочки SearchComponent, которую вы хотите (хотя первый и последний, вероятно, наиболее полезны.) Вы также можете предоставить свой собственный FactCollector. FactCollector отвечает за внедрение, как вы уже догадались, фактов в рабочую память. Например, LucidWorks на самом деле поставляется с двумя реализациями FactCollector. Первый — это базовый FactCollector, который мы использовали до сих пор и который используется по умолчанию. Вторым является StatsFactCollector, который расширяет FactCollector и вносит системную статистику в рабочую память на основе статистики LucidWorks JMX.Почему это полезно? Допустим, вы работаете со сложным приложением, которое включает значительные скачки трафика Теперь, в большинстве ситуаций, вы просто хотите добавить оборудование, но это не всегда возможно, и поэтому вы можете установить некоторые правила, которые будут срабатывать только при срабатывании определенных сбоев, таких как порог загрузки запроса. , Что делают эти правила? Они упрощают запросы, чтобы уменьшить использование ресурсов. Например, вы могли бы:

  • Удалить необязательные аспекты
  • Упростите запросы, которые, как известно, очень дороги (например, подстановочные знаки).
  • Отключите проверку орфографии, выделение, Больше как это или псевдо-релевантность LucidWorks
  • Сортировать только по баллам

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

Если вы внедрили свой собственный FactCollector, вы можете вводить факты из Solr не так, как мы решили, или факты из других систем в целом. Чтобы загрузить ваш, вам просто нужно передать имя класса как часть solrconfig.xml. Если вы будете искать в этом файле FactCollector, вы увидите пример.

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

37
Share: