Google AI Blog: 2008

Translation is Risky Business

Tuesday, December 30, 2008

Posted by Shankar Kumar and Wolfgang MachereyAt Google, we like search. So it's no surprise that we treat language translation as a search problem. We build statistical models of how one language maps to another (the translation model) and models of what the target language is supposed to look like (the language model) and then we search for the best translation according to those models (combined into one big log linear model for those of you taking notes).
But, just as putting all of your money in the investment with the highest historical return is not always the best idea, choosing the translation with the highest probability is not always the best idea either - especially when you have a relatively flat distribution among the top candidates. Instead, we can use the Minimum Bayes Risk (MBR) criterion. Essentially, we look at a sample of the best candidate translations (the so called n-best list) and choose the safest one, the one most likely to do the least amount of damage (where 'damage' is defined by our measurement of translation quality). You might want to view this as choosing a translation that is a lot like the other good translations instead of choosing that strange one that had the good model score.
If this is our 'diversification' strategy, how can we make things even safer? Exactly the same way as we do for investments, we diversify even more. That is, we look at more of the candidate translations to make the MBR decision. A lot more. And the way to do that is to build a lattice of translations during the search and then we do our MBR search over the lattice. Instead of 100 or 1000 best translations that we would use for the n-best approach, lattices give us access to a number that rivals the number of particles in the visible universe (really, it's huge).
Interested? You can read all about it here.

plop: Probabilistic Learning of Programs

Monday, November 10, 2008

Posted by Moshe LooksCross-posted with Open Source at Google blog
Traditional machine learning systems work with relatively flat, uniform data representations, such as feature vectors, time-series, and probabilistic context-free grammars. However, reality often presents us with data which are best understood in terms of relations, types, hierarchies, and complex functional forms. The best representational scheme we computer scientists have for coping with this sort of complexity is computer programs. Yet there are comparatively few machine learning methods that operate directly on programmatic representations, due to the extreme combinatorial explosions involved and the semantic complexities of programs.

The plop project is part a new approach to learning programs being developed at Google and elsewhere that takes on the challenges of learning programs through a unified approach based on reducing programs to a hierarchical normal form, building sequences of specialized representations for programs as search progresses, maintaining alternative representations, and managing uncertainty probabilistically by applying estimation-of-distribution algorithms over program spaces, and exploiting probabilistic background knowledge.

For more information on this approach to learning programs, see my doctoral dissertation. For more on the overall philosophy and where things are going, see the plop wiki on Google Code.

New Technology Roundtable Series

Friday, October 3, 2008

Posted by Alfred Spector, VP of Research and Special InitiativesGoogle Technology Roundtable SeriesLarge-Scale Search System Infrastructure and Search QualityJeff DeanAmit SinghalMap ReduceJerry ZhaoMatt AusternThe Intelligent CloudApplications of Human Language TechnologyFranz Josef Och

Doubling Up

Monday, September 29, 2008

Posted by Franz Josef Ochtranslate.google.comCatalanFilipinoHebrewIndonesianLatvianLithuanianSerbianSlovakSlovenianUkrainianVietnamese

Remembering Randy Pausch

Saturday, July 26, 2008

Posted by Kevin McCurley, Research TeamAchieving your Childhood DreamsI've seen Randy repeatedly go to bat for what is right. As a leader, he consistently evoked incredible enthusiasm and optimism for the subjects he embraces. Randy had a very human passion about people and not just who they are, but their potential, despite any flaws or obstacles in their way. His contributions will be remembered for generations to come. - Rich GossweilerRandy was one of the most vibrant, passionate people I've ever known. His passion was inspirational not only to his family and colleagues, but also, because of his courageous presentations beginning with his well-known Last Lecture, he has influenced millions more. - Alfred Spector

Machine Learning Meeting

Tuesday, May 20, 2008

Posted by Phil Long

Machine Learning is a branch of Artificial Intelligence in which, naturally enough, the aim is to get computers to learn: things like improving performance over time, and recognizing general tendencies among a number of specific cases. We have many ways to exploit Machine Learning programs, and a lot of data to give them. Machine Learning helps us to estimate what content users like most, what content is even legitimate, and how to match ads to content. It also plays key roles in products such as Google Translate and 1-800-GOOG-411.

Last week, Google held a Machine Learning Summit in New York, gathering together engineers from around the world, including participants from Beijing, Zurich, Boston, Haifa, and Mountain View. The program included invited talks by CJ Lin and Peng Xu, and many shorter presentations by Googlers on topics including broadly applicable Machine Learning software, especially challenging applications, and some mathematical analysis.

Can You Publish at Google?

Tuesday, May 6, 2008

Posted by Rich Gossweiler

As part of the interview process at Google we try to describe what it is like to do research here. A common question I get is "How hard is it to publish at Google?" I want to dispel the myth that it is hard. It is easy to publish, easy to put code into open source, easy to give talks, etc. But it is also easy for great research to become great engineering, and that is an incredible lure. Great barriers of despair exist between research and development at many companies; researchers can find it hard to have impact beyond demos, papers, or patents.

Here at Google it is not uncommon for researchers to work on products (and is modus operandi for me); you can come up with something interesting, experiment to convince yourself and others that it is worthwhile, and then work as part of the team to build it and help create world-changing products. But are you willing to do that? That decision is the hard part, not publishing a paper.

I think from a Google standpoint, we need to make sure these barriers don't form, that making products, experimenting and having a venue for trying bold new approaches continues to be part of the culture .

VisualRank

Thursday, May 1, 2008

Posted by Shumeet Baluja and Yushi JingPageRank for Product Image Searchcoverage"Why did we choose to use products for our test case?""Where are we going from here?""Is it live?"click here to help speed up the processjust follow the link

Research in the Cloud: Providing Cutting Edge Computational Resources to Scientists

Wednesday, April 23, 2008

Posted by Christophe Bisciglia, Senior Software Engineer, and Alfred Spector, Vice President of ResearchAcademic Cloud Computing InitiativeCluE initiativesolicitationNSF site

Deploying Goog411

Friday, March 28, 2008

Posted by Francoise Beaufaysour ICASSP paperfeedback

This year's scalability conference

Monday, February 11, 2008

Posted by Andrew Schwerin, Software Engineer

Systems, environments and languages for building, deploying and debugging complex datacenter-scale apps, or for allowing teams of collaborating engineers to work together on such apps more effectively

Unique challenges of scaling services for mobile devices

Location-aware scaling techniques

Experiences designing scalable apps involving mobile devices

Blog