Постоянные читатели этого блога узнают, что в последние несколько месяцев я подробно изучал процесс разработки стратегии поиска , то есть различные способы, с помощью которых профессионалы решают проблему удовлетворения сложных информационных потребностей.
Некоторые профессии (например, специалисты по подбору персонала) используют сложные поисковые запросы для удовлетворения потребностей в ресурсах, генерируя такие запросы:
(“business analyst” or “systems analyst” or “system analyst”
or “data analyst” or “requirements analyst” or “functional
analyst”) and crystal and report* and analy* and data near
analy* and not inventory and not retail and not (ecommerce
or “e-commerce” or b2b or b2c)Этот конкретный запрос предназначен для поиска кандидатов, которые соответствуют типичному брифу клиента . Как видите, это по сути сложное логическое выражение, и задача создания и оптимизации таких выражений является темой ряда форумов в социальных сетях .
Другие профессии используют другой подход. Медицинские работники, особенно те, которые участвуют в создании систематических (литературных) обзоров , как правило, применяют поэтапный подход, такой как этот (опубликованная стратегия Medline по добавлению калорий в оральный белок для детей с хроническим заболеванием ):
randomized controlled trial.pt.
controlled clinical trial.pt.
randomized.ab.
placebo.ab.
clinical trials as topic.sh.
randomly.ab.
trial.ti.
1 or 2 or 3 or 4 or 5 or 6 or 7
(animals not (humans and animals)).sh.
8 not 9
exp Child/
ADOLESCENT/
exp infant/
child hospitalized/
adolescent hospitalized/
(child$ or infant$ or toddler$ or adolescen$ or teenage$).tw.
or/11-16
Child Nutrition Sciences/
exp Dietary Proteins/
Dietary Supplements/
Dietetics/
or/18-21
exp Infant, Newborn/
exp Overweight/
exp Eating Disorders/
Athletes/
exp Sports/
exp Pregnancy/
exp Viruses/
(newborn$ or obes$ or “eating disorder$” or pregnan$ or childbirth or virus$ or influenza).tw.
or/23-30
10 and 17 and 22
32 not 31В этом типе формализма стратегия поиска строится постепенно, как набор дискретных выражений, на которые ссылаются по номеру строки и которые объединяются с использованием различных операторов. Этот тип процедурного подхода имеет то преимущество, что стратегии могут быть созданы с использованием таких методов, как последовательные дроби , строительные блоки и так далее. Это также позволяет поисковику просматривать количество результатов, возвращаемых на каждом шаге, и соответствующим образом корректировать выражение.
За последние несколько месяцев я привык видеть довольно сложные стратегии поиска, часто превышающие сто и более строк. Тем не менее, некоторые вещи в формализме кажутся немного странными.
Во-первых, использование логических операторов, связанных через пронумерованные линии, скорее напоминает мне BASIC первого поколения . Я не говорю, что у языка не было своего места, но несколько десятилетий спустя мы хотели бы думать, что теперь мы используем более структурированные подходы. Но, что более важно, что происходит со всеми этими номерами строк — действительно ли они лучший способ организовать коллекцию логических выражений? Когда нам больше всего нужен принципиальный механизм для структурирования нашего подхода, кажется, что мы вынуждены полагаться на что-то столь же произвольное, как и номер строки. Как скажет любой студент-компьютерщик, либеральное использование таких утверждений «goto» действительно считается вредным .
Во-вторых, и, продолжая метафору языка программирования, я задаюсь вопросом, насколько велика поддержка для создания выражений, синтаксически правильных и семантически прозрачных. Например, хорошо разработанный (программный) язык должен поддерживать такие понятия, как:
- Инкапсуляция: концепция, при которой данные и функции упакованы в один компонент. В некоторой степени это верно в отношении построчного подхода, описанного выше, но оно компрометируется отсутствием возможностей для именования и вызова дискретных элементов вычислений (кроме произвольного числа).
- Абстракция: способность обобщать из набора поведений, например, использование шаблона, который может быть заполнен для данного экземпляра. В приведенном выше примере мы видим, что строки с 11 по 17, вероятно, предназначены для выражения элемента совокупности процесса PICO . Так почему бы не абстрагировать этот компонент? Таким образом, когда нам нужно (повторно) использовать его, он может быть создан для каждого конкретного случая, например, взрослые мужчины в стратегии X, младенцы женского пола в стратегии Y и так далее. (Хорошо, я знаю, что некоторые люди приравнивают абстракцию к сокрытию деталей реализации , но я думаю, что смысл обобщения здесь более уместен).
Точно так же я могу представить себе случаи, когда мы хотели бы, чтобы наша стратегия поиска включала в себя другие понятия, такие как наследование, модульность и т. Д. Поэтому мне остается задуматься: почему дизайн стратегий поиска явно изменился так мало, когда языки программирования изменились так быстро?
Конечно, если вы пишете управляющее программное обеспечение для Airbus 320, вы можете утверждать, что вам нужны инструменты и подходы, которые на несколько порядков сложнее, чем ваша «средняя» стратегия поиска. Но оба усилия пытаются найти элегантные и экономные способы выражения сложных логических конструкций, оба связаны с синтаксической корректностью, и оба нуждаются в семантической прозрачности и прагматической эффективности. Интересно — этот формализм немного похож на клавиатуру QWERTY — некорректный и устаревший дизайн, но тот, который повсеместно распространен чуть больше, чем соглашение?