- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
У меня такой вопрос.
Каким образом можно производить поиск документа по ключевой фразе?
Производить поиск документов удовлетворяющих каждому слову из поискового запроса, а потом полученные списки сливать и сортировать ?
Мне очень нравился вариант, когда сначала выводятся документы, в которых встречается каждое слово из поискового запроса, потом те, в которых не хватает одного (нестрогое соответствие), двух и т.д. Внутри каждый «блок» отсортирован по релевантсности.
Например:
поисковый: 2582547, запрос: 5121905
Приходится сливать массивы размер которых 2582547*sizeof(описание документа)+ 5121905* sizeof(описание документа)
При этом, пусть, в самом простом случае описание, документа будет содержать релевантность, и код документа и содержать скажем 8 байт. То получается примерно 58Mb :)
Зная что Яндекс и Гугл не показывают далее сотой страницы, могу предположить, что есть какой-то хитры способ хранения и обработки позволяющий заранее отсекать низкорелевантные документы.
Приходится сливать массивы размер которых 2582547*sizeof(описание документа)+ 5121905* sizeof(описание документа)
1. Описание документа на данном этапе это его идентификатор: число размером в 4 байта.
2. Массивы предварительно упорядочены по идентификаторам документов, поэтому просматриваются последовательно и один раз
3. Желателен "субиндекс" внутри массивов (блочная орагнизация, self-indexing - называют это по разному) - он позволяет "перепрыгивать" через отрезки массивов.
4. Основное итерирование должно идти по более короткому массиву, тогда большие куски можно будет "перепрыгивать, не читая" ("zig-zag joins" - что такое было на предпоследнем sigir, но саму статью не читал, так что может она и не про это :))
3. Частоты 2 миллиона (или 5 миллионов) это типичные стоп-слова в типичном индексе на несколько миллионов документов.
4. Тем не менее для частотных "тяжелых" сочетаний полезно делать предвычисленный фразовый индекс. Так работал infoseek. У Макса Губина статья на последнем RCDL про то, как эффективно паковать фразовый индекс.
Как видите, не так страшен черт.
А вообще есть куча статей на эту тему, может я чего и не знаю...
1. Описание документа на данном этапе это его идентификатор: число размером в 4 байта.
2. Массивы предварительно упорядочены по идентификаторам документов, поэтому просматриваются последовательно и один раз
Что-то я не совсем понимаю, если массив упорядочен по идентификаторам документов, а результат необходимо отсортировать по релевантности, то нам все равно придется сливать их вместе целиком. После чего как-то узнавать релевантность и сортировать.
4. Основное итерирование должно идти по более короткому массиву, тогда большие куски можно будет "перепрыгивать, не читая" ("zig-zag joins" - что такое было на предпоследнем sigir, но саму статью не читал, так что может она и не про это :))
Это, я так понимаю, только для логики "И", и не подходит, если нам надо найти документ содержащий хотя-бы одно поисковое слово из фразы.
Что-то я не совсем понимаю, если массив упорядочен по идентификаторам документов, а результат необходимо отсортировать по релевантности, то нам все равно придется сливать их вместе целиком. После чего как-то узнавать релевантность и сортировать.
Ранжирование и фильтрация - разные процессы. Отфильтрованный массив - маленький.
Это, я так понимаю, только для логики "И", и не подходит, если нам надо найти документ содержащий хотя-бы одно поисковое слово из фразы.
Запросов с логикой ИЛИ - доли процента.
Ранжирование и фильтрация - разные процессы. Отфильтрованный массив - маленький.
А можно в этом месте по подробнее?? Что такое фильтрация и как она призводится ?
Что такое фильтрация и как она призводится ?
Слово "А" встречается в 1 миллионе документов. Слово "Б" в другом миллионе.
Фраза "А и Б" встречается в 1 тысяче.
Ранжировать и сортировать надо не два миллиона документов, а только 1 тысячу.
"оставить 1 тысячу" = "отфильтровать"
Слово "А" встречается в 1 миллионе документов. Слово "Б" в другом миллионе.
Спасибо, я понял. Этот вариант мне не подходит, хотелось бы сначала выводить результаты по "И", в потом по "ИЛИ" (с подписью "нестрого соответсвие").
И еще один вопрос, что принято делать с  , &lt, >, », «, & и подобными словами ?
mikek, может, я, конечно, глупость скажу, но что мешает искать по базе параллельно - и для "И", и для "ИЛИ", потом выбросить дубликаты и прицепить второй список в хвост первому?
mikek, может, я, конечно, глупость скажу, но что мешает искать по базе параллельно - и для "И", и для "ИЛИ", потом выбросить дубликаты и прицепить второй список в хвост первому?
Написать можно как угодно, вопрос в производительности.
хотелось бы сначала выводить результаты по "И", в потом по "ИЛИ"
Вопрос в том сколько их. Если "найдена" тысяча, и вы делаете сервис для людей, а не для автомата, то по ИЛИ искать не нужно.
Как что? Преобразовывать конечно.
Вопрос в том сколько их. Если "найдена" тысяча, и вы делаете сервис для людей, а не для автомата, то по ИЛИ искать не нужно.
А если запрос таков: "а не пойти ли намс погулять."
а, не, ли - стоп слова, остается "пойти намс погулять"
слово "намс" - не найдено, хотелось бы вывести то что найдено по запросу "пойти погулять" (с припиской, что слово "намс" не найдено вообще, и результат не совсем соответсвует запросу.)
Вижу следующее решение - искать по ИЛИ, потом релевантность (число от 1 до 65535) считать, как количество_найденых_слов<<16+релевантность
Таким образом будут выведены сначала результаты в которых содержаться все слова из запроса, потом в котором не хватает одного, потом двух и т.п.