Принципы работы ИПС

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

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

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

4. Хранение словаря – первое приближение • Массив записей фиксированной длины - 28 байт/терм=14Мб Позволяет осуществлять быстрый бинарный поиск в словаре 20 байт 4 байта каждый

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

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

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

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

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

10. Упражнение • Оцените использование пространства (и экономию, в сравнении с 9,5Мб) с блочной группировкой, для размеров блока k = 4,8 и 16

11. Отражение на поиске • Двоичный поиск до блоков из 4-х термов • Затем линейный поиск сквозь термы в блоке • Вместо нахождения 2-х указателей ранее, теперь находим 0/1/2/3 – в среднем, 1.5

12. Экстремальное сжатие • Использование совершенного хэширования для хранения термов «в пределах» их указателей • нехорошо для словарей, которые меняются • Разделения словаря на страницы • используется двоичное дерево на первые термы страниц; • платим за поиск на диске, чтобы захватить каждую страницу; • если мы платим за 1 поиск диска в любом случае, чтобы добраться до постингов, «только» еще один на терм

13. Оптимизация запросов • Пусть есть запрос, который является “AND”-объединением tтермов. • Идея: для каждого из tтермов получаем его терм-документарную инциденцию из постингов, затем объединяем с помощью AND вместе. • Обработка в порядке увеличивающейся частоты. • начинаем с наименьшего множества, затем продолжаем сужать поиск далее Вот почему мы храним частоту в словаре

14. Упражнения по обработке запросов • Если дан запрос friends ANDromansAND (NOTcountrymen), как мы можем использовать частоту countrymen? • Как мы можем произвести «AND»-объединение 2-х записей постингов без подробного построения 0/1 терм-документарного вектора инциденции?

15. Оптимизация общих запросов • Например,(madding OR crowd) AND (ignoble OR strife) • Получаем частоты для всех термов • Определяем размер каждого OR, суммируя их частоты • Обрабатываем в порядке увеличения размеров OR

16. Упражнение • Предложите порядок обработки запроса для (tangerine OR trees) AND (marmalade OR skies) AND (kaleidoscope OR eyes)

17. Ускорение слияний постингов • Вставка указателей перехода • Скажем, наш текущий список документов – кандидатов для AND-запроса – 8, 13, 21. - (имея плотную совокупность AND) • Мы хотим осуществить объединение со следующей записью постингов: 2,4,6,8,10,12,14,16,18,20,22 • Линейный поиск – медленный.

18. Ускорение слияний постингов • Добавим к постингам указатели с пропуском нескольких элементов (в момент индексирования) 2,4,6,8,10,12,14,16,18,20,22,24…. • В момент запроса • По мере того как идем по списку – можем перейти вперед, не сравнивая каждый элемент • Размер перехода – рекомендован около ~

19. Расширения запроса или индекса • Напоминание из лекции1 • словарь эквивалентных термов • звуковой индекс для омонимов • Как мы это используем? • можем «расширить» запрос, чтобы включить - эквивалентности • запрос car types -> car types automobile tires • можем расширить индекс • индексированные документы, содержащие слово автомобиль, индексируется также как документ, содержащий слово автомашина

20. Расширение запроса • Обычно делается расширение запроса - не нарушается индекс - замедляется обработка запросов - документы часто содержат эквивалентности - можем получить больше ненужной информации - puma -> jaguar - тщательно контролируемые множества слов-синонимов

21. Шаблонные запросы • 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$

22. Обработка шаблонов • Запрос mon* сейчас может быть обработан как - $m AND mo AND on • Но так мы получим соответствие c moon • Нужно осуществить пост-фильтрацию этих результатов согласно запросу • Упражнение: проработайте детали

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

24. Поиск фраз • Ищем “быть лил не быть”. Теперь недостаточно хранить только записи <терм: документы> • Вместо хранения для каждого терма записи: • <количество документов, содержащих терм: • документ1: позиция1, позиция2….; • документ2: позиция1, позиция2….; • и т.д.>

25. Пример позиционного индекса Какой из этих документов может содержать «быть или не быть» ? <быть: 993427; 1:7,18,33,72,86,231; 2:3,149; 4:17;191;291;431;434; 5:363,366,….> Можем сжать позиционные значения/смещения, как мы делали с документами на последней лекции.

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

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

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

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

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

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

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

33. Ресурсы для сегодняшней лекции • Managing Gigabytes, Глава 4. • Modern Information Retrieval, Глава 3. • Princeton Wordnet http://www.cogski.princeton.edu/~wn/