Поисковая система

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

Это действительно сложная система, над которой я думала примерно 5 лет и потом писала об этом 2 месяца. Тут было два варианта — либо быть многословной, либо голословной. Я выбрала первое и прошу меня за это простить. И я не обещаю лёгкое чтиво.

Описание состоит из трёх документов:

  • Настоящий документ. Здесь подробно расписано, что я предлагаю.
  • Эволюция. Информационное пространство в разрезе прошлого, настоящего и будущего и место новой информационно-поисковая системы в нём, обоснование её необходимости и неизбежности, обоснование того, что есть тенденция в движении именно к такой модели, и что так как сейчас — не будет всегда.
  • План. С чего начать и первые шаги.

Введение

Этот документ — подробное описание идеи для будущего задаче-ориентированного поисковика. Он сможет отвечать на вопросы, сформулированные на естественном языке, а не в виде словосочетаний. Например, на вопросы «как», «где» и другие, если они служат тому чтобы найти решение проблемы или задачи. В данный момент я не рассматриваю информационные запросы из серии «в каком году родился Адам Смит», но «как получить введение в экономику» или «где купить книгу «Теория нравственных чувств» — да.

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

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

Информационное пространство

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

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

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

Рыночное пространство

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

Ось онтологии

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

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

  • Базовые потребности
    • Дом / Быт
    • Транспорт
    • Питание
    • Одежда / Обувь / Вещи
    • Здоровье / Красота / Спорт
    • Семья/ Дети
  • Реализация себя
    • Образование
    • Работа
    • Связь / Общениe
  • Отдых
    • Культура
    • Творчество
    • Путешествия
    • Развлечения

Тогда всё, что делает человек и проблемы, которые у него возникают, можно отнести к (нечёткому) подмножеству этих сфер. Между собой они могут пересекаться и входить в другие связи (часть-целое, общее-частное). Онтология может иметь любую детализацию, главное чтобы она была достаточно абстрактной, ведь здесь ещё нет самих вопросов. Раздел «беременность» может быть в разделе «семья», но не «как забеременеть» или «где сделать ЭКО». Это уже следующая ось.

Ось вопросов

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

Следующая ось представляет из себя «глубину» искомого поискового запроса. Насколько он детальный? Отражает то, насколько вопрошающий компетентен в данной сфере и, следовательно, насколько точно он формулирует запрос.

Здесь пространство запросов (внутри некоторой сферы) представлено в виде направленного ациклического графа, где на каждом следующем уровне идёт уточнение потребности человека.

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

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

Пример 1. Глаша купила права и машину. И вот однажды утром она обнаружила, что не работает ближний свет. Она идёт в интернет. Координаты её запроса в формате (<онтология>, <_уровень_: вопрос>) представлены так: (<автомобиль>, <_задача_: починить ближний свет>)

У неё есть 2 варианта – разбираться с причинами (работать с информационными благами) или отправиться в сервис. Она выбирает второе и ей выдаётся карта с ближайшими сервисами. #

Пример 2. Саша — заядлый автолюбитель. Однажды утром он обнаружил, что не работает ближний свет. Он сразу открыл блок предохранителей, нашёл там предохранители на ближний свет, поменял с другими той же силы тока и фары заработали. Тогда он заходит с мобилы в интернет и ищет: (<автомобиль>, <_потребность_: купить предохранитель на 10А, 2 шт>)

Обходится ему это в 20 рублей. Как следствие — можно составлять профиль пользователей, точнее их компетенций и выдавать им разные ответы, но об этом в главе 1.3 #

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

1) Уровень ниже (если он есть). Если запрос можно уточнить (на рисунке выше такие запросы обозначены белым фоном), то он имеет дочерние узлы, т.е. имеет уровень ниже. В качестве ответа на такой запрос нужно пользователю дать понимание: а какие варианты решения его задачи существуют, разбить её на возможные подзадачи. Здесь можно предложить пользователю детализировать вопрос.

2) Уровень выше (если он есть). Можно предложить подняться чуть выше и показать, к какой группе относится данный вопрос, т.е. с какими ещё смежными проблемами часто сталкиваются люди. Может быть у пользователя есть и эти проблемы, а он не знает. Ведь если мы говорим о невысоком уровне компетенции, то зачастую проблема не в поиске ответа, а в формулировании вопроса.

Во-первых, пользователь даже не знает, какие ключевые слова ему искать. Есть «осознанная некомпетентность», т.е. «я знаю, что я не знаю, поэтому я хочу узнать и ищу это», но есть и «неосознанная некомпетентность», т.е. «я не знаю, чего я не знаю». Сейчас данную задачу решает реклама — людям рассказывают о том, о чём они не додумались спросить.

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

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

3) Текущий уровень. Собственно, ответ на вопрос, который лежит на оси ответов. Об этом дальше.

Ось ответов

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

На схеме справа я разделила их на 9 категорий.

При этом запросы могут быть противоположные, они делятся на 2 типа: получение и отдача. Но ответы должны лежать рядом в информационном пространстве.

Можно разделить блага по нескольким параметрам:

Параметры ответов

Из обязательных параметров можно составить пространство возможных комбинаций значений. Всего их  .

Первые два — время и пространство, задают основной тип блага.

Основные типы ответов

Информационную услугу я объединила с информацией, т.к. информация в общем случае не исчезает. Создатель информации может не знать о том, что предоставленная им услуга (0, 1) одному лицу «пошла по рукам», ведь всё, что попадает в интернет, может быть записано и воспроизведено в любое время. Напротив, информацию (0, 0) можно уничтожить, уничтожив все её носители, и она превратится в услугу.

Для каждого из этих типов возможны разные комбинации состава потребителей и создателей. В таблице ниже в колонке «тип» это второе значение в формате:

<кол-во потребителей>x<кол-во создателей>

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

Я выделила 10 основных групп, которые встречаются на практике, объединив некоторые параметры (как я это сделала выше с информацией). Теперь координату каждого блага на оси ответов можно обозначить числом от 1 до 10ти.

Ось ответов

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

Сейчас по  данной оси в поисковиках блага никак не разделяются, это делается на уровне сервисов, примеры которых приводятся в последнем столбце.

К  вопросу представления данных в сегодняшних поисковиках я ещё вернусь, а пока вспомним примеры, описанные выше:

  1. Ответ на запрос о ведении бухгалтерии может лежать в категории 1, 3, 9, 10.
  2. Сломалась машина — в любой категории.Глаша выбирает 1, Саша выбирает 4, 5 или 6.
  3. Чистка лица — категория 1, 3.

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

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

О том, как выбирать из альтернатив, следующая глава.

Блага

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

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

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

Узел

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

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

  • простые: числа, выбор исключающий, выбор не исключающий, дата-время
  • текстовые: строка, текст, документ
  • медиа: изображение, видео, аудио

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

Пример. Возьмём координату на оси онтологии «автомобили». Какие свойства могут быть у автомобилей в общем случае? Марка, модель, год выпуска, коробка передач, литраж двигателя и т.д. (больше полей можно найти на авто.ру). Все эти поля простого типа (по ним можно сравнивать объекты). На авто.ру нельзя добавить новый автомобиль в каталог, не указав его марку или литраж. Это обязательные поля.

Рассмотрим запрос «покупка нового автомобиля». Параметры здесь наследуются из онтологии, плюс добавляются новые: дилер, его географические координаты, наличие, цена, возможность взять в кредит, расписание тест-драйвов и другие.

В координате «покупка автомобиля б/у» к составу полей из онтологии «автомобили» добавляются такие параметры: количество владельцев, состояние, и фото тут уже имеет смысл. Потому что если новый автомобиль можно выбрать исключительно по совокупности значений параметров простого типа, то б/у автомобиль так выбрать уже нельзя, его нужно оценить визуально.

Содержимое узла: блага

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

Блага, которые попадают в один узел, имеют описание в одинаковой системе параметров. А значит по этим параметрам их можно сравнивать.

Пользователь может указать:

  • по каким фильтровать
  • по каким сортировать (может даже составить функцию для сортировки)
  • какие параметры показывать 
  • a какие игнорировать (они не имеют значения)

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

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

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

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

Пример 1. Зачастую нам всё равно где покупать товар, если он обладает нужными нам свойствами. Продавца можно добавить в список игнорируемых и выбирать по параметрам и цене. По этому принципу действует uber — он группирует таксистов, потому что нам всё равно, кто их повезёт, главное чтобы машину подали как можно быстрее. Uber — частный случай данной информационной системы, точнее всего лишь один узел: (<такси>, <_задача_: переместить тело>, <услуга 1×1>) и все услуги таксистов находятся в этом узле. Его параметры: водитель, географические координаты, класс автомобиля, стоимость. Модель пользователя тоже включает географические координаты, а функция для сортировки благ — расстояние между ними.

Пример 2. Вернёмся к узлу «покупка нового автомобиля». В таком запросе не указана конкретная модель, значит это довольно высокоуровневый запрос по оси вопросов. Координаты: (<автомобиль>, <_цель_: покупка>, <4, 5>). Что ожидает пользователь, введя такой запрос? Скорее всего он хочет понять, а что вообще он может позволить себе купить. Он выбирает такие значения параметров:

  • Фильтры:
    • цена от и до,
    • только механическая коробка передач
  • Показывать:
    • марка,
    • модель
    • литраж двигателя
    • цена
    • фото
  • Игнорировать:
    • всё остальное

Модель пользователя

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

Пример. У нас ателье, мы шьём костюмы под заказ. Как построен наш бизнес процесс? Мы приглашаем человека, снимаем с него мерки, получаем пользовательскую модель, и в дальнейшем работаем с ней. Моделирование в том и заключается, чтобы подменять основной объект другим в контексте некоторой задачи, для которой эта модель приемлема. Нам в голову не придёт приглашать самого человека каждый раз, когда требуется принятие решений (подгонка по фигуре). Время человека слишком дорого. Аналогично мы можем смоделировать не только форму человека, но и его содержание: что он делает, чем интересуется, чего хочет.

Матрица компетенций

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

Пример: Я — не кухарка, мне не нужны рецепты, мне нужна еда под ключ. А вот если мне нужно развернуть сайт, то меня не интересуют веб-студии, мне нужна таблица, где будут описаны услуги разных хостинг-провайдеров, конфигурации их серверов и цены. Я отключаю онтологию игр, сериалов и TV.

Время и пространство

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

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

Параметры по умолчанию

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

Пример 1. На тему фильтров. У меня ВАЗ 2113. Если я ищу запчасти, то вероятнее всего мне нужны запчасти именно на мою машину. У меня ребёнок — девочка, 2 года. Если я ищу одежду или другие запросы в онтологии «дети», это должно быть учтено. У меня — linux. Если я ищу приложение для прототипирования, мне не подойдёт axure. И ещё не надо мне показывать рекламу игр.

Пример 2. На тему сортировки. Если мой час стоит 1000 рублей, то я могу ввести функцию , где  — мои временные затраты на получение блага а часах, а y — стоимость затрат на получение блага в деньгах. Если есть 2 варианта: заказать доставку или взять самовывозом, то решение я буду принимать такое, чтобы значение этой функции было минимально. Вероятнее всего, я не поеду на другой конец города в магазин и выберу доставку. Однако, если я покупаю редкую машину с рук, то вполне возможно, что я поеду за ней куда-нибудь в Тверь.

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

Контекст

Ещё один факт про пользователя: это не статическая сущность. Человек имеет разные субличности. В разные моменты времени он преследует разные цели. Можно это назвать контекстом, например: работа, учёба, дом, отдых. В разные моменты времени у него будут «активны» разные онтологии, разное географическое положение, расписание и разные параметры по умолчанию. Пример: У меня есть субличность «программист в Rambler», которая включается в отпределённое время и находится в отпределённом географическом пространстве. На работе у меня не Linux, а FreeBSD. А в выходные я как работник умираю (на самом деле нет).

отступление

На самом деле при проектировании информационной системы, которая отвечает на запросы пользователей (то есть именно пользователи являются инициаторами информационного обмена), факт существования субличностей можно опустить, поскольку человек сам знает что и когда ему искать. Но если говорить не об исходящей информации, а о входящей, то это всё меняет. Ведь входящая информация должна обязательно попадать в контекст, иначе это информационный шум. Для этого люди и заводят рабочие почты и телефоны. Цели и контексты могут добавляться, исчезать и менять свои статусы. Например, субличность «студент МГТУ» можно удалить после получения диплома. Целе-ориентированная работа с входящей информацией — это другой проект, о котором я расскажу в следующий раз. Но эти проекты разделяются лишь условно, ведь они составляют единое целое.

Механизм обратной связи

В задаче-ориентированном поиске выдачей ответов за запросы всё не ограничивается. Нужно вернуться и переспросить, мол, вы спрашивали как сделать то-то и то-то, что из этого вышло?
Как минимум, во всех узлах можно сделать параметр «популярность», по которому можно сортировать. И отражаться будет в нём то, по каким ссылкам переходят с этого запроса чаще.
Как максимум, помимо параметров, описывающих узел, можно ввести параметры результативности, которые считаются на основании обратной связи от пользователей, получивших благо. Соответственно, эти параметры зависят от специфики области. Желательно, чтобы они были простого типа и имели конкретные показатели — цифры, по которым можно сортировать. Если это невозможно, то получатся обычные отзывы, тоже лучше чем ничего.

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

Пример. Есть блага с информацией/услугами/товарами, служащие цели «похудение». Тогда объективные показатели будут: вес до и после, самочувствие, здоровье, работоспособность. А решившие похудеть смогут составить свою оптимизируемую функцию, например для кого-то здесь самое важное — работоспособность, а кому-то нужно срочно, а кому-то — дёшево. #

Здесь прослеживается механизм монетизации всей этой информационной системы. Алгоритм:

  1. Бизнес выкладывает в систему информацию о предоставляемых им благах.
  2. Эти блага люди находят и покупают.
  3. Бизнес сообщает о покупке и платит процент за приведённого клиента.
  4. После этого клиент (пользователь информационного пространства) может оставить обратную связь.

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

План

  1. Машинная подготовка данных и прототип
  2. Создание структуры:
    ось онтологии
      + ось вопросов
         + ось ответов = узлы
    
  3. Заполнение благами
  4. Создание поискового движка
  5. Обеспечение динамической структуризации
  6. Обеспечение динамического заполнения благами
  7. Создание механизмов обратной связи
  8. Монетизация
  9. Создание модели пользователя
  10. Дальнейшее развитие

Более развёрнутый план здесь →

Почему это нужно и как эта система встроится в настоящее и будущее →

results matching ""

    No results matching ""