18 December 2007

Particle filtering versus beam search

I had a very interesting discussion at NIPS with Vikash Mansingka about beam search and particle filtering. Much of what is below is a result of this conversation and he deserves much credit.

In a very real sense, particle filtering can be seen (for many models) as a sort of stochastic beam search. Just to set the stage, let's talk about generic beam search:

1. Initialize a min-queue "beam" to contain a single initial hypothesis.
2. While beam contains non-complete hypothesis:
A. Take h, the lowest scoring hypothesis from the beam
B. For each h' in the neighborhood of h
I. Add h' to the beam, with some score
C. If the beam exceeds a certain capacity, drop high-scoring elements
3. Return the lowest scoring hypothesis from beam
The key variant in beam search algorithms is the score function that's used. The most naive is just path cost---how much did we have to pay to get to the current hypothesis? The "A*" way is to use path cost + admissible heuristic cost, where the admissible heuristic is an underestimate of the amount of cost remaining to complete.

There are (of course) other variants: sometimes we expand the whole beam in one step; sometimes we use multiple beams; etc. We'll come back to these shortly.

Particle filtering (using as similar terminology to the beam search as possible), on the other hand, looks something like:
1. Initialize a max-queue "beam" to contain a single initial hypothesis.
2. While beam contains non-complete hypothesis:
A. Take h, the highest scoring hypothesis from the beam
B. Sample h' from the neighborhood of h
I. Add h' to the beam, with some score
C. If the beam exceeds a certain capacity, randomly drop elements
D. If the "effective sample size" of the beam is too low, resample elements
3. Return the highest scoring hypothesis from beam
To map beam search to particle filtering, use negative log probabilities for scores. (This turns max search into min search.)

In a sense, the major thing that differs between PF and BS is that in PF everything happens randomly -- we're always sampling from a proposal distribution, rather than greedily taking the "best" hypotheses at each step.

There are, however, some minor issues: what proposal distribution is used in step 2B in PF and what does resampling do.

In general, the proposal distribution should be the true posterior probability, but this is pretty much always intractable (otherwise we wouldn't be using approximations at all). The most common thing to do is to use a transition probability, which corresponds exactly to using a path cost in beam search. However, just as we know that using a heuristic can help in beam search, this suggest that using a proposal distribution in PF that contains something like a future cost heuristic is going to be helpful. I'm sure this has been done, but I don't think it's nearly as common as it perhaps should be, given how helpful it is in BS.

What 2D in PF does is to measure whether the samples that we have in the beam have fallen out of the true posterior---in other words, are we "off the mark." There's a straightforward way to compute this (see the wikipedia page linked above). If we are off the mark, we resample all the elements in our beam, essentially trying to get back on the right path. My experience with PF is that this is pretty essential to getting things to work, but as far as I know there's no analogue in BS land.

It may be that these two things (resampling and heuristic) are two different ways of solving the same problem and that doing both is not so helpful. But I tend to doubt it.

One other thing that I've never seen done in PF is to maintain multiple beams. Admittedly this makes the resampling step harder (maybe...I haven't worked through it), but it may be helpful. One thing, for instance, that we found in the PF for the coalescent was that the PF tends to like to merge clusters early with no regard for how hard life is going to be later. We use resampling to try to fix this, but another way would be to use multiple beams. This is commonly done in, eg., machine translation, where a single beam doesn't do well, so we maintain one beam for each number of foreign (or English) words covered.

So what's the point? I think that by recognizing the similarity between BS and PF, we can see ways to potentially improve both. For instance, the following seem promising:
  1. Use resampling techniques in beam search
  2. Use multiple beams in particle filtering
  3. Use A*-style heuristics in the proposal distribution for particle filtering
An alternative suggestion would be for NLPers to pay more attention to particle filtering. It's a nice, clean probabilistic analogue to a technique that we love (or at least are forced to use).

5 comments:

Kevin Duh said...

Nice post, Hal! There's definitely a connection here worth exploring.

Question: I don't really understand what you mean by multiple beams and why PF doesn't usually have it. I thought in PF we sample from each particle individually, which leads to the ability to estimate distributions with multiple modes--doesn't that correspond to multiple beams?

Mark Johnson said...

IMHO the main advantage of particle filtering is that it works in situations where it's possible to sample but it's not possible to find the n-best, so beam search would be intractable.

Lots of Bayes net and MRF problems are like this, and one of the wonderful things about sampling is that it is tractable even if you can't compute the argmax or the partition function.

I keep my hand on my wallet when people ask me to accept random lower probability solutions in place of higher probability ones for no real reason. So I suspect that beam search will be better if it is tractable, all else equal.

Vikash Mansinghka said...

Shameless plug: Along with Keith Bonawitz, Dan Roy, and Josh Tenenbaum, I am finishing up a tech report on this basic connection. (Many very helpful insights, along with the whole multiple beam thing, were provided by Hal at NIPS, and his AISTATS paper last year was definitely influential.) We'll include more details, and are applying the technique to several classic inference problems (MRFs; Bayes Nets; and simple nonparametric models, like our AClass paper at AISTATS last year).

Now, a few comments:

- In the analogy I see, 'path length so far' is analogous to particle weight, and 'cost to go' is analogous to proposal probability (though proposal probability needn't be an underestimate of the true conditional posterior, just an approximation). Beaming is analogous to resampling.

- I can A* search with beam but no heuristic, heuristic but no beam, neither, or both. Similarly, I can SMC with resampling but crappy (e.g. uniform) proposals, good proposals (e.g. expensively computed via lookahead, so they're close to exact conditional posteriors) but no resampling, or both. Specifically: Exact optimization involves extending all partial paths (no beaming) - though considering extensions in order of length+estimated-cost-to-go lets you avoid some, losing nothing if your estimation is a lower bound, saving time the tighter it is. Similarly, exact filtering involves summing over all latent state trajectories (no resampling), though a good proposal - and consideration of states in decreasing order of weight*proposal probability - might allow you to get most of the mass quickly. Sampling instead of summing adds variance (making inference approximate) but lets you dodge exponential time/space. Beaming for optimization guarantees poly time/space, and improves bounded time performance, at the cost of error (with or w/o heuristic, though they can interact to make error worse). Similarly, resampling adds bias (and could interact with bad proposals, leading to degeneration), but attempts to reduce expansion of low probability paths, in some cases improving solution quality for bounded time/space.

- The analogy between beaming and resampling is a bit subtle. In A* search, you can compare partial paths of different depths. This might interact badly with beaming (hence the idea of multiple beams). In an SMC algorithm for e.g. tracking, you can extend particles at different rates (ie incorporate different numbers of datapoints or timepoints into particles) - but when you resample, you can only resample particles that have the same datapoints incorporated. This is because SMC (really, recursive unnormalized importance sampling) depends on resampling as bootstrap, which is only valid if all the particles are drawn from the same distribution (ie share the same unknown normalizing constant Z). However, multiple beams (each consisting of partial paths of the same depth) and multiple resampling (bagging particles according to how many datapoints from some ordered list they've incorporated, and only resampling among particles with the same number) both should go through fine. Ultimately this is because determining how much credit to assign to a partial solution is both harder and easier when you sample. It's harder in that you need a sense of the probability mass left to go, easier in that you don't need strict underestimates for future credit. Furthermore, in A*+beam, k-best really means 'k-best but distinct', since the determinism of A* means two partial paths with the same edge sequence will extend the same under the algorithm (so there is no point representing them twice in the beam). This is not the case for SMC - two particles that are the same up to time t might extend very differently.

- It would be very interesting to see how to recover A* as a zero temperature limit of an appropriately designed SMC algorithm. Developing this case (along with other classic, clever A*ish ideas like dependency directed backjumping) and supporting resampling for different length partial paths (or particles with different Zs), even approximately, seems like an important avenue for future work.

Re Mark: I don't think I agree. First off, in inference (including learning), I care about finding typical posterior solutions (or solutions from regions of high mass). Optimization (as opposed to
sampling + averaging) can lead to all kinds of weird atypicalities, including overfitting in the learning setting (no model averaging). Second, even in
decisionmaking (e.g. based on expected utility), it often turns out that "noisy optimization" (e.g. sample from an 'annealed' expected utility surface over actions) is better than choosing the MEU action - this guards against model error/builds in exploration. Even if one
really wants to optimize, pretending to try to sample (at least for awhile) often helps avoid local minima - compare/contrast MCMC, MCMC+annealing, and hillclimbing as pure optimization methods.

I'd be very interested to hear about situations where pure optimization (both in terms of the problem setup, and in terms of the local decisions made by an algorithm) are clearly better. I'm also
very interested in comments from readers about problems they'd like to see the approach applied to (or more generally what kinds of experiments would help illustrate the tradeoffs discussed in this post). NLP examples would be especially welcome.

hal said...

kevin -- i don't think PF has an equivalent to multiple beams... this would, in PF, amount to having multiple sets of particles, each covering a different number of data points, which is not often done.

mark -- i would argue that there are very few problems for which we can actually find a true n-best... even parsing, which is technically polynomial, is usually done with huge amounts of pruning and thresholding.

the issue of taking lower probability scores is a compelling one... anyone who knows me knows that i pretty much feel the same way. i think there are a few answers to this. (a) if you believe jenny, chris and andrew's results (i'm not expressing a personal opinion one way or the other), then you would believe that in a pipelined system you're better off sampling than finding a k-best output. (b) even if we're doing something like beamed A* with an admissible heuristic, then we're still crossing our fingers that our heuristic is "good enough" -- adding a bit of randomness might not hurt (and could possibly help). (c) we may still be able to borrow some useful things from the PF literature, like resampling, and adapt it to beam search.

vikash -- very nice comment ;)

Russian Translator and Russian Interpreter said...

Hello,
would you be interested in posting a short post about my translation service? How much would you charge for that? Here is my site if you want to take a look at it: http://www.russian-english-translator.com
Thank you,
Tim