1 / 27

Inverted Index Construction

Inverted Index Construction. Documents to be indexed. Friends, Romans, countrymen. Tokenizer. Friends. Romans. Countrymen. Token stream. Linguistic modules. friend. roman. countryman. Modified tokens. 2. 4. friend. Indexer. 1. 2. roman. Inverted index. 16. 13. countryman.

buthainah
Télécharger la présentation

Inverted Index Construction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Inverted Index Construction Documents to be indexed. Friends, Romans, countrymen. Tokenizer Friends Romans Countrymen Token stream. Linguistic modules friend roman countryman Modified tokens. 2 4 friend Indexer 1 2 roman Inverted index. 16 13 countryman

  2. Parsing a document • What format is it in? • pdf/word/excel/html? • What language is it in? • What character set is in use? Each of these is a classification problem, that can be tackled with machine learning. But these tasks are often done heuristically …

  3. Complications: Format/language • Documents being indexed can include docs from many different languages • A single index may have to contain terms of several languages. • Sometimes a document or its components can contain multiple languages/formats • French email with a German pdf attachment. • What is a unit document? • A file? • An email? (Perhaps one of many in an mbox.) • An email with 5 attachments? • A group of files (PPT or LaTeX in HTML)

  4. Tokenization • Input: “Friends, Romans and Countrymen” • Output: Tokens • Friends • Romans • Countrymen • Each such token is now a candidate for an index entry, after further processing • But what are valid tokens to emit?

  5. What is a valid token? • Finland’s capital  Finland? Finlands? Finland’s? • Hewlett-Packard  Hewlett and Packard as two tokens? • State-of-the-artbreak up hyphenated sequence. • co-education  ? • San Francisco: one token or two? • Dr. Summer address is 35 Winter St., 23014-1234, RI, USA.

  6. Tokenization: Numbers • 3/12/91 Mar. 12, 1991 • 52 B.C. • B-52 • My PGP key is 324a3df234cb23e • 100.2.86.144 • Often, don’t index as text. • But often very useful: think about things like looking up error codes/stacktraces on the web • Often, we index “meta-data” separately • Creation date, format, etc.

  7. Tokenization: language issues • East Asian languages (e.g., Chinese and Japanese) have no spaces between words: • 莎拉波娃现在居住在美国东南部的佛罗里达。 • Not always guaranteed a unique tokenization • Semitic languages (Arabic, Hebrew) are written right to left, but certain items (e.g. numbers) written left to right • Words are separated, but letter forms within a word form complex ligatures • استقلت الجزائر في سنة 1962 بعد 132 عاما من الاحتلال الفرنسي. • ‘Algeria achieved its independence in 1962 after 132 years of French occupation.’

  8. Inverted Index Construction Documents to be indexed. Friends, Romans, countrymen. Tokenizer Friends Romans Countrymen Token stream. Linguistic modules friend roman countryman Modified tokens. 2 4 friend Indexer 1 2 roman Inverted index. 16 13 countryman

  9. Linguistic Processing • Normalization • Capitalization/Case-folding • Stop words • Stemming • Lemmatization

  10. Linguistic Processing: Normalization • Need to “normalize” terms in indexed text & in query terms into the same form • We want to match U.S.A. and USA • We most commonly define equivalence classes of terms • e.g., by deleting periods in a term • Alternative is to do asymmetric expansion: • Enter: window Search: window, windows • Enter: windows Search: Windows, windows • Enter: Windows Search: Windows

  11. Normalization: other languages • Accents: résumé vs. resume. • Most important criterion: • How are your users like to write their queries for these words? • Even in languages that standardly have accents, users often may not type them • German: Tuebingen vs. Tübingen • Should be equivalent

  12. Linguistic Processing: Case folding • Reduce all letters to lower case • exception: upper case (in mid-sentence?) • e.g., General Motors • Fed vs. fed • SAIL vs. sail • Often best to lower case everything, since users will use lowercase regardless of ‘correct’ capitalization…

  13. Linguistic Processing: Stop Words • With a stop list, you exclude from dictionary entirely the commonest words. Intuition: • They have little semantic content: the, a, and, to, be • They take a lot of space: ~30% of postings for top 30 • You will measure this! • But the trend is away from doing this: • You need them for: • Phrase queries: “King of Denmark” • Various song titles, etc.: “Let it be”, “To be or not to be” • “Relational” queries: “flights to London”

  14. Linguistic Processing: Stemming • Reduce terms to their “roots” before indexing • “Stemming” suggest crude affix chopping • language dependent • e.g., automate(s), automatic, automation all reduced to automat. • Porter’s Algorithm • Commonest algorithm for stemming English • Results suggest at least as good as other stemming options • You find the algorithm and several implementations at http://tartarus.org/~martin/PorterStemmer/

  15. Typical rules in Porter • sses ss caresses  caress • ies i butterflies  butterfli • ing meeting  meet • tional tion intentional  intention • Weight of word sensitive rules • (m>1) EMENT → • replacement → replac • cement → cement

  16. An Example of Stemming After introducing a generic search engine architecture, we examine each engine component in turn. We cover crawling, local Web page storage, indexing, and the use of link analysis for boosting search performance. after introduc a gener search enginarchitectur, we examin each engincompon in turn. we cover crawl, local web page storag, index, and the us of link analysi for boost search perform.

  17. Linguistic Processing: Lemmatization • Reduce inflectional/variant forms to base form • E.g., • am, are,is be • car, cars, car's, cars'car • the boy's cars are different colorsthe boy car be different color • Lemmatization implies doing “proper” reduction to dictionary headword form

  18. Language-specificity • Many of the above features embody transformations that are • Language-specific and • Often, application-specific • These are “plug-in” supplements to the indexing process • Both open source and commercial plug-ins available for handling these • TASK: Try to find on the web open-source tools that perform tokenization, lower-casing, stemming, and try them out.

  19. Question • How many words in average has a typical query?

  20. Phrase queries • Want to answer queries such as “stanford university” – as a phrase • Thus the sentence “I went to university at Stanford” is not a match. • The concept of phrase queries has proven easily understood by users; about 10% of web queries are phrase queries • In average a query is 2.3 words long. (Is it still the case?) • No longer suffices to store only <term : docs> entries

  21. A first attempt: Biword indexes • Index every consecutive pair of terms in the text as a phrase • For example the text “Friends, Romans, Countrymen” would generate the biwords • friends romans • romans countrymen • Each of these biwords is now a dictionary term • Two-word phrase query-processing is now immediate (it works exactly like the one term process)

  22. Longer phrase queries • stanford university palo alto can be broken into the Boolean query on biwords: stanford university AND university palo AND palo alto Without the docs, we cannot verify that the docs matching the above Boolean query do contain the phrase. Can have false positives! (Why?)

  23. Issues for biword indexes • False positives, as noted before • Index blowup due to bigger dictionary • For extended biword index, parsing longer queries into conjunctions: • E.g., the query tangerine trees and marmalade skies is parsed into • tangerine trees AND trees and marmalade AND marmalade skies • Not standard solution (for all biwords)

  24. Better solution: Positional indexes • Store, for each term, entries of the form: <number of docs containing term; doc1: position1, position2 … ; doc2: position1, position2 … ; etc.> <be: 993427; 1: 6 {7, 18, 33, 72, 86, 231}; 2: 2 {3, 149}; 4: 5 {17, 191, 291, 430, 434}; 5: 2 {363, 367}; …> Which of docs 1,2,4,5 could contain “to be or not to be”?

  25. Processing a phrase query • Merge their doc:position lists to enumerate all positions with “to be or not to be”. • to: • 2: 5{1,17,74,222,551};4: 5{8,16,190,429,433};7: 3{13,23,191}; ... • be: • 1: 2{17,19}; 4: 5{17,191,291,430,434};5: 3{14,19,101}; ... • Same general method for proximity searches

  26. Combination schemes • A positional index expands postings storage substantially (Why?) • Biword indexes and positional indexes approaches can be profitably combined • For particular phrases (“Michael Jackson”, “Britney Spears”) it is inefficient to keep on merging positional postings lists • Even more so for phrases like “The Who”

  27. Some Statistics Results 1 - 10 of about 99,000,000 for britney spears. (0.09 seconds) Results 1 - 10 of about 260,000 for emmy noether. (0.59 seconds) Results 1 - 10 of about 848,000,000 for the who. (0.09 seconds)  Results 1 - 10 of about 979,000 for wellesley college. (0.07 seconds) Results 1 - 10 of about 473,000 for worcester college. (0.55 seconds) Results 1 - 10 of about 24,300,000 for fast cars. (0.11 seconds) Results 1 - 10 of about 553,000 for slow cars. (0.23 seconds)

More Related