Introduction

Last week, we finished up with disk based index construction and started talking about query processing algorithms.
We said there were two main methods for doing query processing: document-at-a-time, in which scores for a document are computed completely before proceeding to the next document which matches at least some of the query terms, and term-at-a-time, in which we process each term in the query in turn adding to documents scores the score of that term.
We saw how using heaps for the nearest nextDoc and for the top `k` results, can speed up the processing of document-at-a-time processing.
We saw how using the Max Score heuristic can speed up the processing of top `k` results when doing term at a time processing.
We said that term-at-time processing is generally slower by a factor of 1.5, but we might be able to perform more sequential disk reads with it, so has the potential to be faster.
We begin today with some more techniques to improve term-at-a-time processing.

Accumulator Pruning

We now look at some strategies to speed up the term-at-a-time approach.
One problem with the algorithm so far, is that it assumes we can keep `a\c\c` in memory, which, given we are assuming the posting lists are long, seems questionable.
To fix this, we assume we have an upper bound `a_max` on the elements contained in the accumulator structures.
One strategy, called QUIT, to ensure we don't go above this bound is to check after each term if we have `|a\c\c| ge a_max`. If so, we stop and return the results we have.
Another strategy called, CONTINUE, is to continue processing postings lists if we find `|a\c\c| ge a_max` after processing a term, but never to add more accumulators.
Both these strategies are due to Moffat and Zobel (1996). Notice neither actually forces an upper bound on the memory used, since we do the check after a term is completely processed.
Lester et al (2005) propose a better pruning strategy which we now consider.

More Accumulator Pruning

In our algorithm so far we process terms from least to most frequent.
Given that we only have a limited number of accumulators, this means we will tend to spend them on documents which are likely to make the top `k`.
We want to devise a rule that tells us for a given posting whether it deserves its own accumulator or not.
Suppose we have processed `i-1` query terms, and have used `a_(c\u\r\r\e\n\t)` many accumulators. We are about to start processing `t_i`.
There are three possible situations:
1. `a_(c\u\r\r\e\n\t) + N_(t_i) le a_(max)`. In this case we have enough free accumulators for all of `t_i`'s postings, so no pruning is done.
2. `a_(c\u\r\r\e\n\t) = a_(max)`. In this case the accumulator limit has already been reached. So none of `t_i`'s posting will be allowed to create accumulators.
3. `a_(c\u\r\r\e\n\t) < a_(max) < a_(c\u\r\r\e\n\t) + N_(t_i)`. In this case, we may need to do pruning.
Ideally, we would like to give the `a_(max) - a_(c\u\r\r\e\n\t)` most important postings their own accumulator, but how to find them?

Assigning Accumulators

A possible two-pass approach to this problem is to: (1) make a pass and score contributions for all of `t_i` to find a threshold `T` such that only `a_(max) - a_(c\u\r\r\e\n\t)` docs have scores over this threshold. (2) Make a second pass and give anything above `T` its own accumulator.

To do this for a long posting list might be costly, to fix this we only approximate `T` as we go and only compare our current approximation against each postings `TF` component.

rankBM25_TermAtATimeWithPruning((t[1], t[2], ..., t[n]), k, amax, u) {
    sort(t) in increasing order of N[[t[i]];
    acc := {}, acc' := {}; //initialize accumulators.
    acc[0].docid := infty // end-of-list marker
    for i := 1 to n do {
        quotaLeft := amax - length(acc) // the remaining accumulator quota
        if (N[t[i]] <= quotaLeft) { //plenty o' accumulators
            // do as we did in rankBM25_TermAtATime
            inPos := 0; //current pos in acc
            outPos := 0; // current position in acc'
            foreach document d in t[i]'s posting list do {
                while acc[inPos].docid < d do {
                    acc'[outPos++] := acc[inPos++]; 
                    //copy previous round to current for docs not containing t[i]
                }
                acc'[outPos].docId := d;
                acc'[outPos].score := log(N/N[t[i]]) * TFBM25(t[i], d);
                if(acc[inPos].docid == d) {
                    acc'[outPos].score += acc[inPos].score; 
                }
                outPos++;
            }
        } else if (quotaLeft == 0) { //no accumulators left
            for j:=1 to length(acc) do {
                 acc[j].score := acc[j].score + 
                     log(N/N[t[i]]) * TFBM25(t[i], acc[j].docid);
            }
        } else { //still have some accumulators
            for j:= 1 to k do { tfStats[j] := 0} //initialize TF stats
            T = 1; //init threshold for new accumulators
            postingsSeen := 0;
            inPos := 0; //current pos in acc
            outPos := 0; // current position in acc'
            foreach document d in t[i]'s posting list do {
                while acc[inPos].docid < d do {
                    acc'[outPos++] := acc[inPos++]; 
                    //copy previous round to current for docs not containing t[i]
                }
                if(acc[inPos].docid == d) {
                    acc'[outPos].docid = d
                    acc'[outPos++].score += acc[inPos++].score + 
                         log(N/N[t[i]]) * TFBM25(t[i], d);
                } else if (quotaLeft > 0) {
                    if (f[t[i],d] ≥ T) { // if happens, make new accumlator
                        acc'[outPos].docid = d
                        acc'[outPos++].score = log(N/N[t[i]]) * TFBM25(t[i], d);
                        quotaLeft--;
                    }
                    tfStats[f[t[i],d]]++;
                }
                postingsSeen++;
                if (postingsSeen % u == 0) {
                     q := (N[t[i]] - postingsSeen)/postingsSeen;
                     T := argmin_x{x in Nat|
                         sum_(j=1)^x(tfStats[j] * q ≥ quotaLeft}
                } 
            }
        }
        while acc[inPos] < infty do { // copy remaining acc to acc'
            acc'[outPos++] := acc[inPos++];
        }
        acc'[outPos].docid :=infty; //end-of-list-marker
        swap acc and acc'
    }
    return the top k items of acc; //select using heap
}

Notice every `u` postings we recompute our threshold. This is usually set to `128`. It affects how good our approximate value of `T` is.

Precomputing Score Contributions

For scoring algorithms that follow the bag-of-word paradigm, it is not necessary to compute the query term's score contributions at query time.
Instead, we may precompute each postings score contribution during index construction and store it in the index.
I.e., we could have postings of the form (doc_offset, score) instead of (doc_offset, tf).
This can greatly reduce CPU cost during query processing.
Of course, if you do this, it is impossible to make any changes to the scoring functions after the index has been built.
Also, it makes it harder to use common index compression techniques which work well with tf values.
The book points out that rather than use floats, one can discretize scores to alleviate to some degree the second problem.

Quiz

Which of the following is true?

In sort-based index construction, we built in-memory data structures called partitions which we periodically write to disk before merging them.
IDF in the BM25 formula is computed in the same way as when we computed IDF for TF-IDF weights in the vector space model.
Our term-at-a-time query processing algorithm only works for proximity ranking.

Light-Weight Structures

We are now going to look at lightweight structures.
We have already given an ADT for inverted indices and shown this could be used for phrase search as well as to compute simple relationships like this phrase is contained between these tags.
We now generalize this second query capability to region algebras.
Region algebras provide operators and functions for combining and manipulating text intervals in support of lightweight structure.
They represent an intermediate point between basic document retrieval and the complexity of full XML retrieval.

Concordance Lists

Region algebras typically work with sets of text intervals.
Any such interval can be expressed as a pair `[u, v]` indicating its start and end point.
We restrict our attention to sets of such intervals such that no interval in the set may have another interval from the set nested within it.
We call such a set of intervals a generalized concordance list or GC-list.
The name refers to paper-based concordances, alphabetical listings of words in a document along with the context in which they appeared.
Given two intervals `[u, v]` and `[u', v']` we write `[u, v] subset[u', v']` to indicate the first interval is a strict sub-interval of the latter.
As examples, {`[5,9]`, `[8, 12]`, `[15,20]`} is a GC-list, although `[5,9]` and `[8, 12]` overlap, but {`[1, 10]`, `[5, 9]`, `[8,12]`, `[15, 20]`} is not because `[5, 9] subset [1, 10]`.
To make a GC-list out of a list of intervals we define the function `G(S)`:
`G(S) = {a | a in S mbox( and ) \neg exists b in S mbox( such that ) b subset a }`

Properties of GC-lists

Since intervals cannot nest, no two intervals in a GC-list may start at the same position.
Similarly, no two intervals may end at the same position.
Thus, the intervals in a GC-list can be ordered by either their start or end positions.
The size of a GC-list can be bounded by taking the least start position and the biggest end position and subtracting
A posting list can be viewed as a GC-list by treating each entry as an interval of length one.
For example, the posting list for the word "first" in the Shakespeare corpus might be: "first" = `{` `[2205, 2205], [2268, 2268]` ... `[1271487, 1271487] }`
Using the above, given any term `t` we can find its GC-list.
Similarly, the results of a phrase query such as "first witch" could be viewed as a GC-list.

Operators

We next look at some common binary operators on GC-lists:
1. Contained in/Not Contained in: `A ``<|`` B` (`<|` is supposed to be a triangle. For not contained in put a line through the triangle ). `A` contained in `B` means each interval in A is a sub-interval of some interval in `B`.
2. Both of: `A Delta B` is defined to be `G(S)` where `S` consists of intervals `c` which contain an interval of `A` and an interval of `B`.
3. One of: `A nabla B` is defined to be `G(S)` where `S` consists of intervals `c` which contain an interval of `A` or an interval of `B`.
4. Before: `A ... B` is defined to be `G(S)` where `S` consists of intervals `c` which contains start points of intervals in `A` and endpoints of intervals in `B` where the interval in `A` ends before the interval in `B` begins.
In the above `c`'s come from the underlying schema independent universe, say intervals in Shakespeare.
In addition to these binary operators, we have two projection operators `pi_1(A)` and `pi_2(A)` which given a concordance list `A` return `{[u,u] | exists v mbox( with ) [u,v] in A}` and `{[v,v] | exists u mbox( with ) [u,v] in A}`
Lastly, we define `[i] = {[u, v] | v -u +1 = i}`, the GC-lists that includes all intervals of a fixed size.

Examples

`pi_1({` `[5, 9], [8, 12], [15,20]}`) = `{ [5,5]` `[8,8], [15,15]}`
[10] = `{ ...,` `[101, 110], [102, 111], ...` `}`.
Lines spoken by any witch, might be expressed as:
( "<LINE>" ... "</LINE>") <| (( "<SPEECH>" ... "</SPEECH>")
|> (( "<SPEAKER>" ... "</SPEAKER>") |> "witch"))

Implementation

The implementation of our region algebra generalizes the algorithms for phrase search, proximity ranking and Boolean Queries.
Consider the problem of evaluating `A ... B`. An interval from the resultant GC-list starts with an interval from `A` and ends with an interval from `B`.
If `[u, v]` is the first interval from `A` and `[u', v']` is the first interval from `B` with `u' > v`, then `v'` must be the end of the end of the first interval of `A ...B`.
We index into `B` to find the first interval with `u' > v`
The last interval from `A` that ends before `u'` starts the first interval of `A...B`. We index into `A` to find the last interval `[u'', v'']` where `v'' < u'`. We keep going in this fashion.
This suggests defining operators similar to the docLeft and docRight operations we had for Boolean queries.

More Implementation

The book defines four operations `tau(S, k)`, `rho(S,k)` and `tau'(S, k)`, `rho'(S,k)`.

`tau(S, k)` returns the first interval in the GC-list starting at or after the position `k`; `tau'(S, k)` returns the last interval in `S` ending at or before `k`.

`rho(S,k)` returns the first interval in `S` ending at or after the position `k`; `rho'(S,k)` returns the last interval in `S` starting at or before the position `k`.

Using either `tau` or `rho` one could enumerate forward through a GC-list starting at a given position. Similarly, using `tau'` or `rho'` one could enumerate backwards through a GC-list from aposition.

For the GC-list of a term, we can define `\tau` as (the book also shows `tau'` and `rho`, `rho'` for terms are similarly computed):

tau(t, k) :=
    if (k == infty) {
        u :=infty;
    } else if (k == -infty) {
        u := -infty;
    } else {
        u := next(t, k-1);
    }
    return [u, u]

Using `tau`, `rho`, `tau'` and `rho'` the book shows how to define each of our binary operators.

The books definition of the four binary operators

Accumulator Pruning, Concordance Lists

Outline