- Apache Tika, implemented in Java, using its LanguageIdentification class
language-detection, a project on Google code, also implemented in Java
For the test corpus I used a the corpus described here, created by the author of
language-detection. It contains 1000 texts from each of 21 languages, randomly sampled from the Europarl corpus.
It's not a perfect test (no test ever is!): the content is already very clean plain text; there are no domain, language, encoding hints to apply (which you'd normally have with HTML content loaded over HTTP); it "only" covers 21 languages (versus at least 76 that CLD can detect).
language-detectioncover all 21 languages, but Tika is missing Bulgarian (
bg), Czech (
cs), Lithuanian (
lt) and Latvian (
lv), so I only tested on the remaining subset of 17 languages that all three detectors support. This works out to 17,000 texts totalling 2.8 MB.
Many of the texts are very short, making the test challenging: the shortest is 25 bytes, and 290 (1.7%) of the 17000 are 30 bytes or less.
In addition to the challenges of the corpora, the differences in the detectors make the comparison somewhat apples to oranges. For example, CLD detects at least 76 languages, while
language-detectiondetects 53 and Tika detects 27, so this biases against CLD, and
language-detectionto a lesser extent, since their classification task is harder relative to Tika's.
For CLD, I disabled its option to abstain (
removeWeakMatches), so that it always guesses at the language even when confidence is low, to match the other two detectors. I also turned off the
pickSummaryLanguage, as this was also hurting accuracy; now CLD simply picks the highest scoring match as the detected language.
language-detection, I ran with the default
ALPHAof 0.5, and set the random seed to 0.
Here are the raw results:
CLD results (total 98.82% = 16800 / 17000):
Tika results (total 97.12% = 16510 / 17000):
Language-detectionresults (total 99.22% = 16868 / 17000):
Some quick analysis:
- The language-detection library gets the best accuracy, at 99.22%,
followed by CLD, at 98.82%, followed by Tika at 97.12%.
Net/net these accuracies are very good, especially considering how
short some of the tests are!
- The difficult languages are Danish (confused with Norwegian),
Slovene (confused with Croatian) and Dutch (for Tika and
language-detection). Tika in particular has trouble with Spanish (confuses it with Galician). These confusions are to be expected: the languages are very similar.
language-detectionwas wrong, Tika was also wrong 37% of the time and CLD was also wrong 23% of the time. These numbers are quite low! It tells us that the errors are somewhat orthogonal, i.e. the libraries tend to get different test cases wrong. For example, it's not the case that they are all always wrong on the short texts.
This means the libraries are using different overall signals to achieve their classification (for example, perhaps they were trained on different training texts). This is encouraging since it means, in theory, one could build a language detection library combining the signals of all of these libraries and achieve better overall accuracy.
You could also make a simple majority-rules voting system across these (and other) libraries. I tried exactly that approach: if any language receives 2 or more votes from the three detectors, select that as the detected language; otherwise, go with
language-detectionchoice. This gives the best accuracy of all: total 99.59% (= 16930 / 17000)!
Finally, I also separately tested the run time for each package. Each time is the best of 10 runs through the full corpus:
|CLD||171 msec||16.331 MB/sec|
|2367 msec||1.180 MB/sec|
|Tika||42219 msec||0.066 MB/sec|
CLD is incredibly fast!
language-detectionis an order of magnitude slower, and Tika is another order of magnitude slower (not sure why).
I used the 09-13-2011 release of
language-detection, the current trunk (svn revision 1187915) of Apache Tika, and the current trunk (hg revision b0adee43f3b1) of CLD. All sources for the performance tests are available from here.
Great information, especially the performance part! Thanks Mike!ReplyDelete
wow! CLD is ultra-fast.ReplyDelete
I'm gonna test it.
Why not developing a library just for python ?ReplyDelete
Here's a "pure Python" language detector: https://github.com/saffsd/langid.py
Its accuracy is very good; see: http://blog.mikemccandless.com/2011/10/language-detection-with-googles-compact.html?showComment=1319806660503#c569166902196965255
Tanks for the reply on langid.pyReplyDelete
Have you tested it's performance on small chunks of text, or just plain words?
I've made a few tests and the accuracy is not that great actually, do you have any idea if the module is based only on large texts or .. ?
And about the CLD, i have tried to install it on Windows XP SP2 and the "build.win.cmd" gives me some errors, egg:
Could Not Find C:\chromium-compact-language-detector\libcld.lib
'cl.exe' is not recognized as an internal or external command, operable program or batch file.
'lib.exe' is not recognized as an internal or external command, operable program or batch file.
Can you help me on this problem ?
I don't know much about langid.py (maybe try contacting its author?). It did test very well for me on the Europarl corpus though...
On your compilation errors, you need to have Visual Studio installed, and the tools have to be on your "path". Visual Studio includes a .bat file to setup your path... to verify it's working, just type "cl.exe" at the command prompt and confirm the executable is found.
I just spotted this post of yours now. Thanks for sharing this detailed comparison. Your presentation of results is very clear and concise.
@Cosmin I am the author of langid.py. I am working on a large-scale comparison of different langid tools, on a variety of datasets with different characteristics. Language identification of very short text segments is being discussed quite alot due to the popularity of services like Twitter, so I will be including tests aimed specifically at investigating performance over Twitter data. Preliminary results indicate that for most tools, performance is quite far below the long-text levels.
Thanks for sharing this! I'm just curious to know if there is the possibility in CLD to re-train the language models/tables?
I imagine the Chromium team knows how to generate the tables from training data... but I sure don't know how! It's a great question.
Maybe try emailing the chromium-dev group? (http://groups.google.com/a/chromium.org/group/chromium-dev/topics )
Very useful for me.
Thanks a lot!!!
I tested the Google stuff, and confusion between Afrikaans and Dutch was very bad indeed.ReplyDelete
Language profile seem to have been made from Wikipedia, which is by design full of non-native content and proper names. Maybe that is bad training material. Results from training the Frysian profile from the Frysian wiki supports this idea. The Dutch Wikipedia is not very big, a better corpus might help.
Ik can find no info at all on how to train new languages to TIKA. Is there any?
I think Google's CLD was trained on a wider corpus than Wikipedia.
I don't know much about how Tika's language detection is trained ... if you work it out please submit a patch describing it! But I think Tika really should just use one of the existing language detectors ...
Great comparison, Mike. I used your results to compare the accuracy of my own language identification web service API (WhatLanguage.net). I also added langid.py in the mix, another popular library. You can find an accuracy comparison between WhatLanguage.net, CLD, Tika, language-detection and langid at http://www.whatlanguage.net/en/api/accuracy_language_detectionReplyDelete
Those are impressive results! Do you describe your approach / share the source code anywhere?
Could you please tell me which one is the best for short texts? I had a problem with language-detection for shorter messages. I heard about Twitter’s machine language detection algorithm and they say it is way accurate for the short texts.
Waiting for your suggestions (of course reply)
I'm really not sure; best is to go test yourself, and then report back! But in general short text is harder ...
Hi Mike ,Delete
I am glad you replied. I tested for two modules.
1)language-detection 2)langid-java (https://github.com/carrotsearch/langid-java)
For short texts and single words, langid gives the better accuracy than language detection.
langid- java was accurate for more than 80% of test cases, whereas language-detection
was somewhere between 60-65%. ( don't know the reason though!!!)
For large texts and sentences, language-detection is slightly better.
GCLD was implemented in C++, i prefer java because of my project. Apache Tika
was good but was bit slower as compared to language-detection and langid-java.
Thanks for sharing!Delete
That's interesting that langid is so much better for short texts; what was Tika's accuracy?
Actually most of the my shorts texts contains single words.I didnt have enough time to implement Tika, though i read some blogs and papers, they all clearly suggests Tika is magnitude slower and bit inaccurate.Delete
But again for long texts , i feel language-detection is little better. Atlast I selected language-detection for project, because of its overall performance and accuracy!!!!
Anyone know where I can find a detailed explanation of how the library works. I mean, for example, the criteria used to choose the best language, which hash function used to store n-gram, etc. It would be helpful ..ReplyDelete
Try reading the pages at CLD2's wiki? https://code.google.com/p/cld2/w/list
Thank you very much Michael, I'll check it.ReplyDelete
I am trying to compile CLD2 in Visual Studio 2013. I am actually trying to create a .NET Wrapper for the library so I have added all the source files inside my CLR project.ReplyDelete
Now whenever I compile I get these linking errors.
error LNK2005: "struct CLD2::CLD2TableSummary const CLD2::kCjkDeltaBi_obj" (?kCjkDeltaBi_obj@CLD2@@3UCLD2TableSummary@1@B) already defined in cld_generated_cjk_delta_bi_32.obj
These all seems to be related as I can see a relation between the 'generated' files.
Problem is I have a lot of these and I am not sure which ones I should exclude and which I should keep and use in my code.
Here is a list all the generated files that came with the CLD2 code.
The naming convention of these suggests that I should only be using one of each group. At least that how I think I should use it as I am not really an expert in encoding nor in how CLD2 works. And I could not find any references online explaining how to configure it.
I tried eliminating the linking errors by keeping only one of each generated group:
for example: from `cld_generated_cjk_delta_bi_4` and `cld_generated_cjk_delta_bi_32` I kept the 32 version. And so on for the rest of the files.
Now this made CLD compile yet when I tried testing it with languages I noticed that the scores were way way off and it was behaving inexplicably bad.
I am not trying to support all languages I only need to support latin languages along with hebrew, arabic, japanese and chinese.
Can someone please explain how to configure CLD2 to compile and work correctly.
Hi, I suggest you first work with the CLD2 team (https://code.google.com/p/cld2/ ) to figure out how to compile the libraries on windows?Delete
This is great stuff!, I want to totally adopt the voting approach to boost the accuracy of my application, however I can't find the maven package for the CLD/CLD2. Anyone knows where it is ?ReplyDelete
I think you need to build CLD2 from sources yourself? See https://github.com/CLD2Owners/cld2Delete
btw, here are results of evaluation of language detection with fastText: http://alexott.blogspot.de/2017/10/evaluating-fasttexts-models-for.htmlReplyDelete