As some of you know, I was one of the organizers of the Workshop on Parallel Text at ACL 2005. http://www.statmt.org/wpt05/
It turned out quite well I think, and among the better aspects were two very exceptional invited talks, one by Mike Maxwell (LDC) on building resources for languages that have little or no existing resources, and the other was by Franz Och (Google) regarding statistical machine translation. A few notes on Franz's talk, which was entitled : Statistical Machine Translation: The Fabulous Present and Future The title is meant to be a bit ironic I think, in that discussions of MT are often very gloomy and pessimistic. Franz though, was quite optimistic, so in that sense the title was accurate. The underlying message of his talk seemed quite clear - Google uses massive amounts of parallelism (a cluster of 1000 computers), massive amounts of parallel text (billions of words) and relatively simple methods, and gets very nice quality translation automatically. Now, it's important to understand that this is not the method of translation that you see when you use Google's web based translation - that's quite a bit simpler, and not all that good. :) Now, there are less than 100 languages where you have millions of words of parallel text, and even fewer with billions of words of parallel text. There are approximately 6,000 languages in the world, so you can see that these massive methods only work for a few language pairs (English-French, Engish-Chinese, etc.) but of course those are the most widely used pairs so it clearly has significant impact. Franz also gave some glimpses into Google infrastructure as used for research, and it's quite impressive. As mentioned they have a cluster of 1000 component class machines they can use for their MT research. The use of these machines is managed by a resource called MapReduce, which is a Google internal tool that lets you use massive parallelism without having to get bogged down in all the details of which processors are up, how to manage the load, etc. etc. While you can't download your own copy of MapReduce, you can read about it in some detail here: http://labs.google.com/papers/mapreduce.html Also of considerable importantance is the Google File System (GFS) since all of this data and the resulting probability models takes terabytes of data. http://labs.google.com/papers/gfs.html On a related note is a paper the describes the Google Cluster Architecture as used for handling web search. Note that this is not the same as the cluster used for MT, but I hadn't seen this paper before so I wanted to mention it as well: http://labs.google.com/papers/googlecluster.html Of course the rather interesting (and for some disturbing) question that this talk raises is - how does a smaller lab (like UMD, for instance, which is not even really a lab) compete with someone like Google, which has essentially infinite resources, and with someone like Franz who has entire groups of engineers working on these clusters, file systems, etc. And of course the answer is that you can not possibly compete, there is no way in heaven or on earth than UMD can do statistical MT for English and French better than Google. It won't happen, no matter how smart we are. But, fortunately we aren't working on Statistical MT for high density languages. :) This is not to say that UMD is in a bad situation really - I would be surprised if CMU or MIT could really compete with Google in this arena - for as wealthy as those institutions are compared to UMD, they do not have any where the resources of a place like Google. So, the question is what do we do? Well, there are a few things - at UMD I believe one of our contributions so to speak is making tools and ideas available via open source code. That's something that Google does not do, and is not likely to do in general. So we have an advantage. :) But, I think this is an issue that we need to think about a little as we move forward and select problems to work on. Franz, to his credit, did raise this issue, and suggested that Google would be willing to help smaller labs in some way, and I think that reflects a sincere sentiment at Google that I have heard others mention as well. One of the interesting issues that came up in his talk was the use of highly precise probabilities in their models. In general they have found that using four digits off precision is more than enough for certain aspects of their translation models (in particular the alignment models). So, he pointed out that when reporting results it really is quite specious and indeed misleading to use 12 digits of precision or whatever (for accuracy) since there is no way the models are that precise. To that I say Bravo! It has been my contention for some time that two digits of precision for most applications (.64 versus .64321129) is totally sufficient, and indeed makes papers and tables easier to read and clearer visually. Another interesting point was that they found that their translation results improved when the considered English words to be limited to 4 characters - that is "important" would become "impo", and so forth. Note that the foreign language words are expressed in their full form, but the English words are limited to 4 characters. When they do this, their results are better than if the English words are also in their full or stemmed form! This is pretty amazing, although one might think of it as being a form of smoothing, which is important in probability models in general. Anyway, the use of limited precision and 4 character English words is what I mean by simple methods. That, combined with billions of words or parallel text seems to lead to nice machine translation. If you happened to also be at this talk, I'd be most interested in your thoughts as well. I think it was one of the more interesting events at ACL 2005 overall. Thanks, Ted -- Ted Pedersen http://www.d.umn.edu/~tpederse Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/nlpatumd/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
