Text Retrieval in Peer to Peer Systems David Karger MIT

Text Retrievalin Peer to Peer Systems

David Karger

MIT

Information Retrievalbefore P2P

The traditional approach

Information Retrieval

Most of our information base is text academic journals books and encyclopedias news feeds world wide web pages email

How do we find what we need?

neat

messy

The Classic IR Model

User has information need User formulates textual query System processes corpus of documents System extracts relevant documents User refines query Metrics:

recall: % of relevant documents retrieved precision: % of retrieved docs with relevance

Precision-Recall Tradeoff

Recall 100%

Precision

100%

Fetch Nothing

Fetch Everything

CIA

Web Search

Library

Specific Retrieval Algorithms

Define relevance Build a model of documents, meanings Ignore computational cost

Implement efficiently Preprocessing

Tb corpora call for big-iron machines (or simulations) Interaction:

after 1/2 second, user notices delay after 10 seconds, user gives up (historical perspective; changed by web)

Boolean Keyword Search

Q: “Do harsh winters affect steel production?” Query: steel AND winter

Output: “Last WINTER, overproduction of STEEL led to...” “STEEL automobiles resist WINTER weather poorly.” “Boston must STEEL itself for another bad WINTER” “the Pittsburgh STEELers started WINTER training...”

Not Output: “Cold weather caused increased metal prices as orders for

radiators and automobiles picked up...”

Implementing Boolean Search Typical: OR of ANDS,

handle each OR separately, aggregate For ANDs, inverted index:

Per term, list of documents containing that term intersect lists for query terms

Basically a database join

Intersection Algorithms (as in DB) Method 1: direct list merge

Linear work in summed size of lists Method 2: examine candidates

Start with shortest term list For each list entry, check for other search terms Linear in smallest list Good if at least one rare term, but

requires forward index (list of terms in each document) no gain if all search terms common (“flying fish”)

Problems with Boolean Approach Synonymy

several words for same thing if author used different one, query won’t match

Polysemy one word can mean many things (“bank”) query matches wrong meanings

Harsh cutoffs (1 wrong keyword kills) user can’t type descriptive paragraph...

Terms have uniform influence repeated occurrence same as single occurrence common terms treated same as rare ones

Fixing Problems

Synonymy thesaurus can add equivalent terms to query increases recall, but lowers precision expensive to construct (semantics---manual)

Polysemy use more query terms to disambiguate user might not know more terms increases precision, but lowers recall

Harsh cutoffs quorum system (maximize # matching terms)

Uniformity?

Vector Space Model

Document is a vector with a coordinate/term 0-1 for presence/absence of term (quorum) real valued to represent term “importance”

term frequency in document increases value term frequency in corpus decreases value

Dot product with query measures similarity Best known implementation: inverted index

for each query term, list documents containing it accumulate dot products

Vector Space Advantages

Smoother than Boolean search Provides ranking rather than sharp cut-off

Tends to allow/encourage queries with many nonzero terms Easy to “expand query” with synonyms Hopefully polysemes will “interfere constructively” May even add relevant documents to query

100s or 1000s of terms

P2PIR

Simulating big iron

Web Search Info From Google Web queries

Almost all queries 2 terms only “Boolean vector space” model (tiny recall OK) Zipf distribution, so caching queries helps some

Corpus 3B pages, 10K average size, 30TB total Inverted index: roughly the same size Fits in a “moderate” P2P system of 30K nodes But must be partitioned. How?

Obvious: Partition Documents Node builds full inverted index for its subset Query quite tractable per node Merge results sent back from each node Used by Google (in data center) and Gnutella Drawback: query broadcast to all nodes

OK for Google data center; bad for P2P

Alternative: Partition Terms

One node owns a few terms of inverted index Term pair is “key” for distributed hash table

Talk only to nodes that own query terms They return desired inverted-index lists Results intersected at query issuer Drawback: transfer huge inverted index lists Alternative: send first term-list to second

Ships 1 (perhaps small) list instead of 2

Avoiding Communication(Om Gnawali et al. @MIT) Build inverted index on term pairs

Pre-answering all queries Partition pairs among nodes Search contacts one node Problem: pre-computation cost

Size-n document generates n2 pairs Each pair must be communicated Each pair must be stored

Good Cases

Music search “document” is song title + author n small, so n2 factor unimportant

Document windows Usually, good docs have query terms “nearby” Scan window of length 5, take pairs in window 10 pairs/window, so 10n per document So linear in corpus size as before

Bundle pairs to ship over sparse overlay

What About Vector Space?

Weighting terms is easy But cannot limit search to pair list

However, need only highest-scored documents on individual terms

So, pre-compute and store small “winner list” Vector space encourages many-term queries

Find pairs with small intersection Index triples, quadruples, etc Apply branch and bound techniques

Google Pushback

No need for P2P More precisely: “keep peers in our data center” Exploit high local communication bandwidth Economics support large server farm

More load? Buy more servers

Main bottleneck: content provider bandwidth Limits rate of crawl Google index often weeks out of date Distributed crawler won’t help

Google Pushback Pushback

P2P might help Let each node build own index Ship changes to Google

Potential applications real-time index new-relevant-content notification

Problem: SPAM Content providers will lie about index changes Use P2P system to spot-check?

Person-to-Person IR

New modalities

P2P: Systems Perspective Distributed system has more resources

Computation/Storage Reliability

Can exploit, if successfully hide Latency Bandwidth

Goal: simulate reliable big iron Solve traditional problems that need resources File storage, factoring, database queries, IR

P2P:Social Perspective Applications based on person-to-person

interactions Messaging Linking/community bulding (the web) Reputation management (Mojo Nation) File-sharing collaborations (just now)

Need not run on top of P2P network

The “Pathetic Fallacy” of P2P

Assumption that network layer should mirror social layer E.g. “peers should be node with similar interests”

Many work fine on one (big, reliable) machine Placement on P2P system is “coincidental” On other side of “one big machine” abstraction

Breaching abstraction has bad consequences Peering to “friends” unlikely to optimize efficiency,

reliability

P2P Opportunity:Leverage Involvement of People Each individual manipulates information

In much more powerful, semantic ways than machines can achieve

Record that manipulation Exploit to help others do better retrieval

Link-based Retrieval

Simultaneous work: Kleinberg at IBM Brin/Page at Stanford/Google

People find “good” web pages, link to them So, a page with large in-degree is good Refine: target of many good nodes is good

Mathematically, random walk model Page rank=stationary probability of random walk

Applications

Search Raise relevance of high page-rank pages If lazy, limit corpus to high page-rank Anchor text better description than page contents

Crawl Page rank computed before see page Prioritize high page-rank pages for crawl

People add usable info no system could find

P2P:Systems/Social Interactions Distributed system has novel properties Exploit them to enable novel capabilities E.g., anonymity

Relies on partition of control/knowledge E.g., privacy

Allow limited access to my private information Gain (false, but important) sense of safety by

keeping it on my machine

Expertise Networks

Haystack (Karger et al), Shock (Adar et al) Route questions to appropriate expert

Use text to describe knowledge Based on human entry, or indexing of human’s

personal files Might be unwilling to admit knowledge

P2P framework can protect anonymity Shock achieves by Gnutella-style query broadcast More efficient approach?

Other New Aspects

Personal information sharing Unwilling to “publish” mail, documents to world But might allow search, access in some cases Keeping data, index on own machine gives (false)

sense of security, privacy Anonymity

P2P provides strong anonymity primitives Can be exploited, e.g., for “recommending”

embarrassing content

Sample Application

Social: “Secret Web” Maintain links for use by page-rank algorithm But, links are secret from most others Need random walk through link path

Implement via recursive lookup Censorproof?, spamproof?

Semantics vs. Syntax

Clearly, using word meanings would help Some systems try to implement semantics But this is a core AI problem, unsolved Current attempts don’t scale to large corpora All current large systems are syntactic only Idea: use computational power of P2P Idea: use humans to attach semantics

Conclusion: Two Approaches to P2P Hide P2P (Partition to Partition)

Goal: illusion of single server Know how to do task on single server Devise tools to achieve same in distributed sys. Focus on surmounting drawbacks: systems

Exploit P2P (Person to Person) Determine new opportunities afforded by P2P Perhaps impossible on single server Focus on new applications: AI? HCI?