Язык запросов по неструктурированым данным

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Сейчас пытаюсь усовершенствовать поисковые алгоритмы концептуально отличающиеся от того, что предлагают гиганты вроде google или yandex.
Основной концепт заключается в том, что примитивная поисковая строка не соответствует тому обьему информации, который обрабатывает поисковая система. Обьем информации в интернете растет экспоненциально и разрыв между поисковой строкой и сотнями миллионов страниц в интернете усугубляется еще больше. Это проблема.
Как ответ этой проблеме предложено разработать простой и мощный язык поисковых запросов, так называемый язык запросов по неструктурированым данным.
Внук фасетного поиска .

Например запрос может выглядеть так:

Я ищу страницы где
есть много разных слов из категории «Позитивные отзывы», список слов будет выведен в отдельную колонку ’Позитивные отзывы’
а также
есть слово или фраза «google»

Энжин который сможет обрабатывать такие запросы я уже начал собирать.
Экспериментальный конструктор запросов есть на этой странице:

booben.com/Query

Каждый запрос состоит из нескольких частей.
Части бывают пяти типов.
1. Указываем точное вхождение фразы или слова (логика И)
2. Указываем вручную список слов (логика ИЛИ)
3. Указываем категорию слов, из нее чтото должно быть найдено.
4. Указываем категорию слов, из нее должно быть найдено максимальное количество слов
5. Указываем диапазон значений.

Что еще важно, поисковая машина не просто выдает топ страниц, она отображает данные в табличном виде. В такой системе легко построить запрос «Найти все страницы где есть картинки или видео» и поисковая машина отдаст таблицу в которой будут только картинки или видео.
__________________

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Блин, у меня сегодня увлекатийнеший день. Всю ночь роботы бубен кома старались укратить строптивую барышню севастопольского форума. Барыня отдавала страниц 300, потом ей плохело и вылетала с ошибкой 502 badgateway, ато и 500. Кстате робот был галантен, дос не применял в отсудствии прелюдий замечен не был. После разбитого гетевея засыпал на 15 минут и процесс насилия повторял опять. Короче говоря какой крымнаш такой и форум =)
Через пару дней фортеця будет взята стримы налажены =)

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

ну вот опять пенсионерка слегла ))
На сей раз с 504
booben.com/Monitoring

Через пару дней фортеця будет взята стримы налажены =)
А ты настойчив :D

Вспомнился анекдот:

Если мужчина настойчив, он обязательно добьется того, чего желает... женщина
 ©

"Солдат спит служба идет"©
Все в автономном режиме.
Если понадобится, пауки с крымнашей неделями не будут слазить ))

Добавил онлайн базу в тренды. Теперь можно отслеживать популярность тех или иных терминов в разрезе времени сразу по нескольким ресурсам.
booben.com/...оссия сша европа&s=online

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

ЗЫ а в целом, конечно, забавно смотреть, как человек изобретает information retrieval :-)

На то он и язык запросов, чтобы указывать сложный контекст.
Например «Я ищу страницы где есть позитивные отзывы, отзывов много (условие размер страницы), на странице есть онлайн плеер и описание жанра камеди».
Такой запрос вполне реально построить.

Про

information retrieval
не не слышал. Желательно ссылку на сайт где это реализовано и можно потрогать.

уу, как все запущено. lmgtfy.com/?q=information retrieval

цвет учебника — синий

Матусевич кидается базвордами, с ним часто такое бывает.

Имплементировал смарт паука. Наконец сервис стал не офлайновый, а онлайновый.
База обновляется автоматом с лагом гдето в 4 часа, пока что по одному сайту в тестовом режиме.
booben.com/...enium+1&s=online&a=search
+ В самых дорогих ресторанах не только приносят еду, но и показывают как ее готовят :)
Добавил простейшую страницу мониторинга спайдера и базы данных поисковика
booben.com/Monitoring

Посмотрим как база будет рости. По ощущениям даже если сайтов будет штук 50,
одного инмемори инстанца хватит на лет 5.

Тот же гугл давным-давно предоставляет расширенный язык запросов. Пользуйся не хочу. Проблема в «не хочу» :) - среднестатистический пользователь поиска не знает и не хочет ничего знать о каком-то специальном языке для поиска. И _никогда_ не будет напрягаться. Поэтому, лучшее, на что можно рассчитывать поисковой системе — это многословные запросы на естественном языке. Причем многословные — это до 7-8 слов (все что больше — уже почти наверняка не набирается руками, а копипастится). В общем случае 99% ваших пользователей никогда не дадут вам в одном запросе достаточно инфы, чтобы «расшифровать» контекст однозначно.

Сложно в эпоху кнопочных телефонов рассказывать про тачпад :)
У Гугла достаточно примитивный язык запросов. Чего нельзя сделать — море.
Я думаю что это нужно вынести в отдельную статью в блог.

У Гугла достаточно примитивный язык запросов. Чего нельзя сделать — море.
Да какая разница? У пользователей нет ни потребности в отдельном языке для общения с поисковиком, ни желания подобный язык осваивать. Юзеры хотят общаться с поисковиком на своем языке...

Для этого существует конструктор запросов. Который выдает ответы на естественном языке, например:

«Я ищу страницы где
есть много разных слов из категории „С# код“, список слов будет выведен в отдельную колонку ’С# код’»

Прекрасно понимаю, что никакой SQL с его SELECT * FROM * GROUP BY * ORDER BY никто учить не будет. Хотя движок поддерживает ...

Почитал Ваш блог, есть достаточно интересная инфа, кое что для себя почерпнул, спасибо.
Но вот относительно Booben.com — чё то был разочарован.
1. Очень медленно работает (но это могу понять, железо слабое и всё такое, вобщем недостаток мощных вычислительных ресурсов)
2. Попытался воспользоваться мастером запросов. забил в поиск «Алгоритмы на С#» на Habrahabr.ru. В ответ Ваш движок не нашёл ни одного документа, хотя Google нашёл их не мало. Вопрос Google VS Booben (для меня) отпал сам собой :) Покрайней мере на данной стадии реализации Вашего движка.

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

Вобщем удачи Вам.

1. Работает не медленно. Просто ассоциативный поиск требует обхода всего графа, а это миллионы микроподзапросов. Есть несколько вариантов это дело оптимизировать, но пока считаю норм.
2. Слова из двух символов не индексируются. Если написать так
booben.com/...ритмы шарп&s=habrahabr.ru
то все вроде Ок )
3. Приимущества движка описаны в статье блога Google VS Booben.

1. Мне в роли пользователя Вашего сервиса впринципе по ... про микроподзапросы и ньюансы техничесой реализации :) Если я зашёл к Вам на сервис и мне надо ждать скажем 10 секунд, а Google отдаёт тот же результат на 500 ms, то как бы попрос о том что круче сразу отпадает. Если смотреть на это как программист, то я не знаю как у Google всё там реализовано, поэтому не могу сказать чей алгоритм более эффективный
2. Вот Вы мне скажите, кто будет думать о том как там что у Вас индексируется. К Вам на сайт скажем зашла обычная домохозяйка, та ей глубоко на то как там что у Вас реализована. Она забила в строку «Как приготовить борщ по староукраинсому рецепту» :) Какие нафиг 2 слова и связные списки :)))) Ёмаё, Вы чё, серьёзно хотите писать help к Вашему посисковому движку и расказывать людям что теперь вместо того что бы ввести фразу в одном единственном поле для ввода теперь надо как то там им по особому писать поисковые запросы ? :))
3. Из 1,2 вытекает 3.

Опять же это с точки зрения Usebility. Возможно Ваш движок действительно крут и всё такое. Так если он действительно крут, сделайте так что бы я зашёл к Вам в поисковик. На обычном человеческом языке написал что ищу и он мне за время, соизмеримое с Google отдал более качественный результат. Это и есть показателем крутости Вашего решения.

Как то так.

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

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

Так а почему он C# тоже исключил ? C# здесь одно из ключевых слов. А вот «на» как бы просто предлог. И поидее после синтаксического анализа должно было бы остаться «Алгоритмы C#». Или чего то не понимаю ?

1. Чтобы ускорить движок именно по ассоциациям мне нужно просто кешировать результаты или предрасчитать ассоциации на каждое слово (что может занять несколько дней вычислительных ресурсов).
2.

«Как приготовить борщ по староукраинсому рецепту»
уже както старомодно. Гугл ориентируется по тому, что в интернете уже есть 100500 бложиков с таким заголовком. Значительно интересней как Гугл будет справлятся с запросами: «Найди мне все рестораны и гостиницы в пределах 30 км от моего города где есть сауна и бильярд». Вот это уже интересней. То что я пилю вполне сможет обрабатывать такие запросы, если составить правильно запрос.

На мой взгляд оба случая имеют место быть. Ведь к Вам на ресурс придут люди и с такими и с такими запросами и я Вам скажу первых будет больше. Т.к. это только «умники» будут искать что то вроде

«Найди мне все рестораны и гостиницы в пределах 30 км от моего города где есть сауна и бильярд»
. Остальные будеут искать что-то очень примитивное. Типа «Как приготовить Борщ». Или я что-то тоже не понимаю. Поэтому если Вы хотите превзойти Google Вам придётся реализовать оба варианта и опять же, это должно работать не медленее чем Google. Но тут понятное дело что нужны хорогшие вычислительные ресурсы. Поэтому решение должно хорошо масштабироваться.
Вы хотите превзойти Google

Превзойти не получится. Стоимость Гугла превышает 300 млрд долларов.
Я назову это так, что есть 95% задач с которыми хорошо справляется Гугл.
И 5% с которыми не очень. Вот моя задача найти эти 5% и протиснутся со своими сервисами.

Не люблю я слов типа «не получится», «не могу». Если бы я так мыслил будучи студентом, меня бы давно прогнали из Универа :) Но впринципе Ваше лично дело, как по жизни мыслить. Хотя только что пришла в голову мысль и вспомнилось, что подсознание игнорирует приставку «не» :) Т.е. когда человек говорит «не могу» на подсознательном уровне откладывется «могу» :) Но всё равно избыточное мышление, приставка «не» избыточна. Теперь по делу. Думаю если вы таки решили здаться и отдать первенсто Google, то Ваш сервис будет полезен для очень узкого круга людей и вскоре думаю про него все забудут, т.е. я бы не вложил в Вас деньги. Опять же моё скромное мнение, на каковое имею право. Но если бы Вы решили сдлетать кардинально новый поисковый движок, который впринципе не уступал бы Google, то думаю Вы бы нашли хороших инвесторов и могли бы вывести Ваш проект на хороший уровень.

Чтобы сделать поисковик лучше чем

Google
нужно сделать v-search плюс добавить новые классные обои.

Да и я Вам мкажу что часто сам искал что то вроде «Купить ’нечто’ Укриана Днепропетровск». И как правило Google с этми очень даже неплохо справлялся. И тут работало следующее правило. Вначале он находил те страницы где есть все слова, т.е. где можно купить нужный товар в Украина Днепрпетровск, потом уже просто Украина. Что было очень удобно.

какой прикольный дизайн
как добились такой медленной загрузки картинок? Дома на ADSL хоститесь?

Ноут иногда перемещается в дальнюю комнату. А там вайфай не торт.

«навiщо платити бiльше» ©
На существующем стоковом оборудовании можно собрать кластер на 1 Пета.
Если писать с умом не нужно мНоГО кРУтыХ и МОШНых сЕрвеРоВ

То что ты ищешь называется elasticsearch. Если не хватает пиши поверх. Изобретать своё круто, ток в рамках academic. Потому что любой задаче должен соответствовать real-life case, а то печально. Насчёт финсистемы — всегда надо делать збс, пользователь единственный who’s matters

Гугл не использует кодовую базу Яндекса. Яндекс не использует кодовую базу Гугла. Эластик не использует кодовую базу Яндекса и Гугла, А Люсена, Сфинкс, Ксапиан, Бубен не используют кодовую базу не из чего ранее перечисленого.
Может показаться что «взять чтото готовое» это простой подход. Возможно это так в краткосрочной перспективе и если нужно все «как у того парня».
В долгосрочной перспективе это ограничивающее не гибкое решение. Поэтому крупные проекты идут ТОЛЬКО путем создания своих велосипедов. И дальше эти велосипеды уже едут по своему уникальному пути. Например на базе эластика НЕВОЗМОЖНО принципиально построить ассоциативный поиск. Просто потому что он не сможет держать миллион микрозапросов за пару секунд и его база не имеет сжатие в 99% чтобы ее засунуть полностью в ОЗУ.

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

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

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

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

-

Искал «порнография» и оно мне ничего не нашло, кроме каких-то статей на харбе. Я разочарован, ваш сервис не имеет смысла.

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

Как формируешь список категорий и признаков? Что у внука от дедушки а что своё?

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

Я не профи в теории категорий и поиске — но это ключевое для фасетов.

Да, для фасетов ключевое. Но категорий не так много. Вот я сейчас например за пару минут создал категорию Одежда. Несколько сотен категорий должни покрыть потребности 80% пользователей. Штука это очень мощная, примеров можно приводить много. Например через категорию можно указать список улиц своего района и мониторить любую информацию с географической привязкой :) Но больше всего возможности фасетов раскрываются на всякого рода прайсах вроде авизо, сландо и др. Там это поиск тысячи параметров. Учитывая куцые возможности поиска и фильтрации на всякого рода сайтах обьявлений тема конечно перспективная.

Вот я сейчас например за пару минут создал категорию Одежда.
И как именно ты ее создал?

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

как планируете решать проблему дублей категорий и признаков?

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

а как объединять различные признаки из дублей категорий? слияние предполагается?

Дубли это нормально. Категория «Народная медицина » вполне может быть подмножеством «Медицинские термины». Слияние норм, если указать в запросе что страница принадлежит нескольки категориям.

Я о других дублях:

Народная медицина
и
Народная медЕцина

а категория уже создана и какое-то время живёт а ошибка изначально не обнаружена — как быть как сливать ?

Дубли можно вычислить не по названию, а по содержимому.
Если на 80% внутри одни и теже термины то скорей всего дубль.

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

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

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

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

booben.com/...UAH+&s=habrahabr.ru&a=add

=> Ошибка валидации поисковой строки

Да, там получается клацнули расширить фильтр. А второе условия для фильтра не указано.

Так глядишь и SPARQL какой нибудь переизобретешь.

Возможно. Тут есть тонкий момент, язык запросов в поисковике должен быть понятен даже для домохозяек. Когда-то SQL задумывался тоже как язык для домохозяек, но не сложилось. Хотя идея сама по себе оказалась очень живучая. Вообщем на кону запросы к поисковой системе
чтото вроде «Найди мне все страницы за последние три месяца в интернете, где есть видео онлайн с хорошими отзывами в жанре фентези где снимался иванов петров или сидоров». ИМХО игра стоит свечь. Кстате оцени скорость работы поисковика на базе в сотни гигабайт, она моментальная даже на сложных агригирующих запросах !
Внутри «найшвидша та найдосконалiша» субд Made in Ukraine :)

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

Кстате оцени скорость работы поисковика на базе в сотни гигабайт, она моментальная даже на сложных агригирующих запросах !
Внутри «найшвидша та найдосконалiша» субд Made in Ukraine :)
Я не в курсе что там происходит что бы оценить.

Какая такая инфраструктура. РДФ хранилища старый потертый боян.
booben.com/?q=rdf&s=habrahabr.ru

RDF это всеголишь формат, такойже как XML. Очень неээфективный формат с точки зрения быстродействия и компрессии данных, кстате.

Ну да, потом базы его импортируют во внутреннее представление.

у меня парсеры грабят корованы напрямую

Это клева, теперь осталось подождать когда твой суперязык запросов догонит по возможностям SPARQL, а даза банных — Freebase/Wikidata.

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

Кстати getprismatic такое когда то делали, но оно у них загнулось почему то и они на какую то рекламу переключились. getprismatic.com/news

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

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

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

НУ регистрация понятно нужна что бы к чему то привязать твой профайл интересов.

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

Там есть 3 Манчкинa — карточная игра, регион страны ОЗ и какой то кот. При использовании точного запроса получилась бы лента с кучей мусора из двух других интересов, а ИИ этих чуваков продвинут достаточно что бы разделить 3 этих хаба.

Ну правильно. Поэтому запрос чуть сложнее чем просто слово «Манчкин», а «Манчкин» + «Категория игр»

Можно и так, у чуваков такое тоже есть: категория игр.

Я не в курсе что там происходит что бы оценить.

Ну так на вскидку, самый простейший запрос по категории выливается в это
SELECT s.docNumber, c.Word
FROM [sql.ru] s (1.3 млн страниц * ~5 тыс слов на странице)
INNER JOIN Category (50 терминов) c ON c.Word = s.Word
Если добавить условие «должно быть найдено слов больше чем ...», то это еще плюс один вложеный селект и плюс сортировка

Топорненько. А 50 слов ты руками набивал?

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

Ошибка валидации поисковой строки

Гениальное отношение к пользователям. Логи посмотри чтоли.

У меня же не финансовая система.
Логи у меня только IISовские (стандартные).
Но и там чтото сложно читать их достаточно много.

Это обычный подход к тому что бы сделать юзерков счастливыми. Финансы тут не причем.

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

Они скорее всего хранят кучу логов, просто не привязанных к АйПи.

Підписатись на коментарі