Тема2 - Кафедра анализа данных и исследования операций
реклама
Принципы работы ИПС Тема 2. Использование обратных индексов Сегодняшние темы • Хранение инвертированных индексов – Сжатие словарей в памяти • Обработка булевских запросов - Оптимизация обработки термов - Кодирование списков перехода • Шаблонные запросы • Запросы-фразы и позиционные запросы • Оценка систем представления информации Хранение инвертированных индексов • На последней лекции рассмотрено: сжатие обратного индекса кодированием промежутков • Сейчас: хранение словаря – словарь в основной памяти, обратный индекс на диске • Компромисс между степенью сжатия и скоростью обработки запроса – каскадное семейство технических приемов Хранение словаря – первое приближение • Массив записей фиксированной длины - 28 байт/терм=14Мб Позволяет осуществлять быстрый бинарный поиск в словаре Термы Частота а 999,712 aardvak 71 ….. ….. zzzzz 99 20 байт Указатель на элемент обратного индекса 4 байта каждый Упражнение • Действительно ли хорошая идея – бинарный поиск? • Какова лучшая альтернатива? Термы фиксированной длины приводят к потерям • Большая часть байтов в столбце термов теряется без пользы – мы выделяем 20 байт даже на однобуквенный терм – все еще нельзя обработать supercalifragilisticexpialidocius • Среднее слово в английском языке ~ 8 символов – среднее слово в письменном английском языке ~4,5 символа: короткие слова доминируют по использованию • Хранение словаря как строки символов: – предполагается экономия до 60% пространства словаря Сжатие списка термов системасистематизироватьсистематикасистематический Частота Указатели на постинги Указатель на терм Общая длина строки = 500КВ*8=4Мб 33 29 44 Указатели разрешают 4М позиций: LOG24М=22Бита=3Байта 126 Бинарный поиск для нахожнения указателей Общее пространство для сжатого списка • • • • • 4 Байта на терм для частоты 4 Байта на терм для указателя на постинги 3 Байта на указатель терма В среднем, 8 байт на терм в строке термов 500 К термов => 9,5 Мб Сейчас в среднем 11 байт/терм, а не 20 Блочная группировка • Хранение указателей на каждый k-й блок строки термов • Необходимо хранить длины термов (1 доп. байт) 8система17систематизировать11систематика15систематический10с Частота Указатели на постинги Указатель на терм 33 29 44 126 7 Экономим 9 байт на 3-х указателях Теряем 4 байта на длинах термов Упражнение • Оцените использование пространства (и экономию, в сравнении с 9,5Мб) с блочной группировкой, для размеров блока k = 4,8 и 16 Отражение на поиске • Двоичный поиск до блоков из 4-х термов • Затем линейный поиск сквозь термы в блоке • Вместо нахождения 2-х указателей ранее, теперь находим 0/1/2/3 – в среднем, 1.5 Экстремальное сжатие • Использование совершенного хэширования для хранения термов «в пределах» их указателей – нехорошо для словарей, которые меняются • Разделения словаря на страницы – используется двоичное дерево на первые термы страниц; – платим за поиск на диске, чтобы захватить каждую страницу; – если мы платим за 1 поиск диска в любом случае, чтобы добраться до постингов, «только» еще один на терм Оптимизация запросов • Пусть есть запрос, который является “AND”объединением t термов. • Идея: для каждого из t термов получаем его термдокументарную инциденцию из постингов, затем объединяем с помощью AND вместе. • Обработка в порядке увеличивающейся частоты. – начинаем с наименьшего множества, затем продолжаем сужать поиск далее Вот почему мы храним частоту в словаре Упражнения по обработке запросов • Если дан запрос friends AND romans AND (NOT countrymen), как мы можем использовать частоту countrymen? • Как мы можем произвести «AND»-объединение 2-х записей постингов без подробного построения 0/1 терм-документарного вектора инциденции? Оптимизация общих запросов • Например,(madding OR crowd) AND (ignoble OR strife) • Получаем частоты для всех термов • Определяем размер каждого OR, суммируя их частоты • Обрабатываем в порядке увеличения размеров OR Упражнение • Предложите порядок обработки запроса для (tangerine OR trees) AND (marmalade OR skies) AND (kaleidoscope OR eyes) Term Freq eyes 213312 Kaleidoscope 87009 Marmalade 107913 Skies 271658 Tangerine 46653 Trees 316812 Ускорение слияний постингов • Вставка указателей перехода • Скажем, наш текущий список документов – кандидатов для AND-запроса – 8, 13, 21. - (имея плотную совокупность AND) • Мы хотим осуществить объединение со следующей записью постингов: 2,4,6,8,10,12,14,16,18,20,22 • Линейный поиск – медленный. Ускорение слияний постингов • Добавим к постингам указатели с пропуском нескольких элементов (в момент индексирования) 2,4,6,8,10,12,14,16,18,20,22,24…. • В момент запроса • По мере того как идем по списку – можем перейти вперед, не сравнивая каждый элемент • Размер перехода – рекомендован около ~ размер _ списка Расширения запроса или индекса • Напоминание из лекции 1 – словарь эквивалентных термов – звуковой индекс для омонимов • Как мы это используем? – можем «расширить» запрос, чтобы включить эквивалентности - • запрос car types -> car types automobile tires – можем расширить индекс • индексированные документы, содержащие слово автомобиль, индексируется также как документ, содержащий слово автомашина Расширение запроса • Обычно делается расширение запроса - не нарушается индекс - замедляется обработка запросов - документы часто содержат эквивалентности - можем получить больше ненужной информации - puma -> jaguar - тщательно контролируемые множества словсинонимов Шаблонные запросы • mon*: найти все документы, содержащие любое слово, начинающееся с “mon”. • Решение: индексируем все k-граммы, возникающие в любом документе (любая последовательность к символов) • Например, для текста “April is the cruelest month” мы получим 2-граммы (биграммы, пары букв) - $ - специальный символ-граница слова $a,ap,pr,pi,il,l$,$I,is,s$,$t,th,he,e$,$c,cr,ru,ue,el,le,es,st,t $,$m,mo,on,nt,th,h$ Обработка шаблонов • Запрос mon* сейчас может быть обработан как - $m AND mo AND on • Но так мы получим соответствие c moon • Нужно осуществить пост-фильтрацию этих результатов согласно запросу • Упражнение: проработайте детали Дальнейшие улучшения шаблонов • Сокращаем расходы на указатели, используя блоки • Шаблонные запросы предполагают незначительное содержание биграмм – храним постинги на диске • Упражнение: дан триграммный индекс. Как вы обработаете произвольный шаблонный запрос? Поиск фраз • Ищем “быть лил не быть”. Теперь недостаточно хранить только записи <терм: документы> • Вместо хранения для каждого терма записи: – – – – <количество документов, содержащих документ1: позиция1, позиция2….; документ2: позиция1, позиция2….; и т.д.> терм: Пример позиционного индекса <быть: 993427; 1:7,18,33,72,86,231; 2:3,149; 4:17;191;291;431;434; 5:363,366,….> Какой из этих документов может содержать «быть или не быть» ? Можем сжать позиционные значения/смещения, как мы делали с документами на последней лекции. Обработка запроса-фразы • Извлекаем записи инвертированного индекса для каждого различающегося терма: быть, или, не • Объединяем их «документ:позиция» - списки, чтобы пронумеровать все позиции, где «быть или не быть» начинается. Оценка информационно-поисковых систем (ИПС) • Какие есть характеристики для оценки производительности ИПС? - скорость индексирования - величина отношения «индекс/общее число документов» - скорость обработки запроса - «значимость/качество» результатов Стандартные оценки качества ИПС • TREC – национальный институт стандартов и тестирования (NIST) • Reuters и другие совокупности тестов • Определены «задачи поиска/извлечения» - иногда как запросы • Оценки людей-экспертов, определяющих для каждого запроса и для каждого документа, «относящийся» или «не относящийся». Точность и общий выбор • Точность: доля полученных документов, «относящихся» к запросу в числе извлеченных, • Общий выбор: доля «относящихся» документов, которые были получены, в общем числе «относящихся» документов, • Обе характеристики могут быть измерены как функции количества полученных документов Компромиссы • Можем получить высокий общий выбор (но низкую точность), получив все документы для всех запросов! • Общий выбор – неубывающая функция от количества полученных документов - но точность обычно убывает (в хорошей системе) Сложности в точности и общем выборе • Должны быть усреднены в обширных совокупностях документов и запросов • Требуют человеческого участия • Сильно зависят от авторства/множества документов Краткий обзор предстоящих тем • Построение индексов • Общий анализ связности в WEB • Определение весов для термов и векторные пространства запросов • Кластеризация документов • Рекомендуемые системы и совместная фильтрация • Классификация документов • Анализ ссылок в гипертексте • Суммирование • Исследование гипертекста • Обширные производственные вопросы и реальный мир Ресурсы для сегодняшней лекции • Managing Gigabytes, Глава 4. • Modern Information Retrieval, Глава 3. • Princeton Wordnet http://www.cogski.princeton.edu/~wn/
