Принципы работы ИПС Тема 2. Использование обратных индексов

Сегодняшние темы Хранение инвертированных индексов –Сжатие словарей в памяти Обработка булевских запросов - Оптимизация обработки термов - Кодирование списков перехода Шаблонные запросы Запросы-фразы и позиционные запросы Оценка систем представления информации

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

Хранение словаря – первое приближение Массив записей фиксированной длины - 28 байт/терм=14Мб ТермыЧастота Указатель на элемент обратного индекса а999,712 aardvak71 ….. zzzzz99 20 байт4 байта каждый Позволяет осуществлять быстрый бинарный поиск в словаре

Упражнение Действительно ли хорошая идея – бинарный поиск? Какова лучшая альтернатива?

Термы фиксированной длины приводят к потерям Большая часть байтов в столбце термов теряется без пользы – мы выделяем 20 байт даже на однобуквенный терм –все еще нельзя обработать supercalifragilisticexpialidocius Среднее слово в английском языке ~ 8 символов –среднее слово в письменном английском языке ~4,5 символа: короткие слова доминируют по использованию Хранение словаря как строки символов: –предполагается экономия до 60% пространства словаря

Сжатие списка термов ЧастотаУказатели на постинги Указатель на терм системасистематизироватьсистематикасистематический Общая длина строки = 500КВ*8=4Мб Указатели разрешают 4М позиций: LOG 2 4М=22Бита=3Байта Бинарный поиск для нахожнения указателей

Общее пространство для сжатого списка 4 Байта на терм для частоты 4 Байта на терм для указателя на постинги 3 Байта на указатель терма В среднем, 8 байт на терм в строке термов 500 К термов => 9,5 Мб Сейчас в среднем 11 байт/терм, а не 20

Блочная группировка Хранение указателей на каждый k-й блок строки термов Необходимо хранить длины термов (1 доп. байт) ЧастотаУказатели на постинги Указатель на терм система17систематизировать11систематика15систематический10с Теряем 4 байта на длинах термов Экономим 9 байт на 3-х указателях

Упражнение Оцените использование пространства (и экономию, в сравнении с 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 ) TermFreq eyes Kaleidoscope Marmalade Skies Tangerine Trees

Ускорение слияний постингов Вставка указателей перехода Скажем, наш текущий список документов – кандидатов для AND-запроса – 8, 13, (имея плотную совокупность 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 Нужно осуществить пост-фильтрацию этих результатов согласно запросу Упражнение: проработайте детали

Дальнейшие улучшения шаблонов Сокращаем расходы на указатели, используя блоки Шаблонные запросы предполагают незначительное содержание биграмм –храним постинги на диске Упражнение: дан триграммный индекс. Как вы обработаете произвольный шаблонный запрос?

Поиск фраз Ищем быть лил не быть. Теперь недостаточно хранить только записи Вместо хранения для каждого терма записи: –

Пример позиционного индекса Можем сжать позиционные значения/смещения, как мы делали с документами на последней лекции. Какой из этих документов может содержать «быть или не быть» ?

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

Оценка информационно-поисковых систем (ИПС) Какие есть характеристики для оценки производительности ИПС? - скорость индексирования - величина отношения «индекс/общее число документов» - скорость обработки запроса - «значимость/качество» результатов

Стандартные оценки качества ИПС TREC – национальный институт стандартов и тестирования (NIST) Reuters и другие совокупности тестов Определены «задачи поиска/извлечения» - иногда как запросы Оценки людей-экспертов, определяющих для каждого запроса и для каждого документа, «относящийся» или «не относящийся».

Точность и общий выбор Точность: доля полученных документов, «относящихся» к запросу в числе извлеченных, Общий выбор: доля «относящихся» документов, которые были получены, в общем числе «относящихся» документов, Обе характеристики могут быть измерены как функции количества полученных документов

Компромиссы Можем получить высокий общий выбор (но низкую точность), получив все документы для всех запросов! Общий выбор – неубывающая функция от количества полученных документов - но точность обычно убывает (в хорошей системе)

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

Краткий обзор предстоящих тем Построение индексов Общий анализ связности в WEB Определение весов для термов и векторные пространства запросов Кластеризация документов Рекомендуемые системы и совместная фильтрация Классификация документов Анализ ссылок в гипертексте Суммирование Исследование гипертекста Обширные производственные вопросы и реальный мир

Ресурсы для сегодняшней лекции Managing Gigabytes, Глава 4. Modern Information Retrieval, Глава 3. Princeton Wordnet