If you have to deal with only a single language, count yourself lucky. Finding the right strategy for handling documents written in several languages can be challenging.
단일 언어만 다룬다면, 운이 아주 좋은 경우이다. 여러 가지 언어로 작성된 document를 다루는 올바른 방법을 찾는다는 것은 쉽지 않다.
At Index Timeedit
Multilingual documents come in three main varieties:
다국어 document는 3가지 정도로 나눌 수 있다.
One predominant language per document, which may contain snippets from other languages (See One Language per Document.)
document 별로 하나의 두드러진 언어가 있고, 다른 언어가 조금 포함되어 있다. (One Language per Document 참고)
One predominant language per field, which may contain snippets from other languages (See One Language per Field.)
field 별로 하나의 두드러진 언어가 있고, 다른 언어가 조금 포함되어 있다. (One Language per Field참고)
A mixture of languages per field (See Mixed-Language Fields.)
field별로 언어가 혼합되어 있다. (Mixed-Language Fields 참고)
The goal, although not always achievable, should be to keep languages separate. Mixing languages in the same inverted index can be problematic.
항상 가능한 것은 아니지만, 목표는 언어를 개별적으로 유지하는 것이다. 동일한 inverted index에 언어가 섞여 있으면 문제가 될 수 있다.
Incorrect stemmingedit
The stemming rules for German are different from those for English, French, Swedish, and so on.Applying the same stemming rules to different languages will result in some words being stemmed correctly, some incorrectly, and some not being stemmed at all. It may even result in words from different languages with different meanings being stemmed to the same root word, conflating their meanings and producing confusing search results for the user.
독일어(German)에 대한 형태소 분석 규칙은 영어(English), 프랑스어(French), 스웨덴어(Swedish) 등의 그것과 다르다. 다른 언어에 동일한 형태소 분석 규칙을 적용하면, 어떤 단어는 올바르게 형태소 분석이 이루어지고, 어떤 것은 올바르지 않게, 어떤 것은 전혀 하지 못한다. 심지어, 다른 의미를 가진, 다른 언어의 단어가 동일한 원형으로 형태소 분석되고, 의미가 혼합되고, 사용자에게 매우 혼란스러운 검색 결과를 만들어낸다.
Applying multiple stemmers in turn to the same text is likely to result in rubbish, as the next stemmer may try to stem an already stemmed word, compounding the problem.
동일한 문장(text)에 여러 가지 형태소 분석기를 차례로 적용하면, 형편없는 결과가 나올 수 있다. 다음 형태소 분석기는 이미 형태소 분석된 단어를 다시 형태소 분석하려 한다. 문제가 복잡해진다.
Incorrect inverse document frequenciesedit
In What Is Relevance?, we explained that the more frequently a term appears in a collection of documents, the less weight that term has. For accurate relevance calculations, you need accurate term-frequency statistics.
What Is Relevance?에서, document의 집합에서 단어가 더 자주 나타날수록, 단어가 가지는 비중이 더 낮다고 설명한 바 있다. 정확한 relevance 계산을 위해, 정확한 단어 빈도 통계가 필요하다.
A short snippet of German appearing in predominantly English text would give more weight to the German words, given that they are relatively uncommon. But mix those with documents that are predominantly German, and the short German snippets now have much less weight.
주로 영어(English) 문장(text)에서 나타나는 독일어(German)의 짧은 조각들은, 비교적 드물기 때문에, 독일어 단어에 더 많은 비중을 줄 것이다. 그러나, 저들을 대부분이 독일어로 된 document와 섞으면, 짧은 독일어 조각들은 훨씬 더 적은 비중을 가진다.
At Query Timeedit
It is not sufficient just to think about your documents, though. You also need to think about how your users will query those documents. Often you will be able to identify the main language of the user either from the language of that user’s chosen interface (for example, mysite.de versus mysite.fr) or from the accept-language HTTP header from the user’s browser.
document에 대해서만 생각하는 것으로는 충분하지 않다. 사용자가 해당 document를 query하는 방법에 대해서도 생각해야 한다. 흔히 사용자가 선택한 인터페이스의 언어(예: mysite.de vs mysite.fr)나, 사용자 브라우저의 HTTP header의 accept-language로 사용자의 기본 언어를 확인할 수 있다.
User searches also come in three main varieties:
검색을 하는 사용자도 3가지 정도로 분류할 수 있다.
Users search for words in their main language.
기본 언어로 단어를 검색하는 사용자
Users search for words in a different language, but expect results in their main language.
다른 언어로 단어를 검색하지만, 기본 언어로 결과를 기대하는 사용자
Users search for words in a different language, and expect results in that language (for example, a bilingual person, or a foreign visitor in a web cafe).
다른 언어로 단어를 검색하지만, 해당 언어로 결과를 기대하는 사용자(예: 이중 언어 사용자 또는 블로그의 외국인 방문객)
Depending on the type of data that you are searching, it may be appropriate to return results in a single language (for example, a user searching for products on the Spanish version of the website) or to combine results in the identified main language of the user with results from other languages.
검색하고 있는 데이터의 형태(예: 스페인어 버전의 website에서 상품을 검색하고 있는 사용자)에 따라, 하나의 언어로 결과를 반환하거나, 사용자의 확인된 기본 언어와 다른 언어로 된 결과를 조합하는 것이 적절하다.
Usually, it makes sense to give preference to the user’s language. An English-speaking user searching the Web for "deja vu" would probably prefer to see the English Wikipedia page rather than the French Wikipedia page.
일반적으로, 사용자의 언어를 선호하는 것이 합리적이다. "deja vu" 를 인터넷에서 검색하는, 영어로 말하는 사용자는 아마도 프랑스 Wikipedia Page 보다는 영어 Wikipedia Page를 더 선호할 것이다.
Identifying Languageedit
You may already know the language of your documents. Perhaps your documents are created within your organization and translated into a list of predefined languages. Human pre-identification is probably the most reliable method of classifying language correctly.
이미 document의 언어를 알고 있을수도 있다. document는 여러분의 조직 내에서 생성되었고, 미리 정의된 언어의 목록으로 번역되었을 것이다. 사람이 미리 확인하는 것이, 올바르게 언어를 분류하는 가장 신뢰할 수 있는 방법이다.
Perhaps, though, your documents come from an external source without any language classification, or possibly with incorrect classification. In these cases, you need to use a heuristic to identify the predominant language. Fortunately, libraries are available in several languages to help with this problem.
document가, 어떠한 언어 분류 없이 외부에서 오거나, 잘못 분류된 경우에는, 주요 언어를 확인하기 위하여 몇 가지 추론을 사용해야 한다. 다행히도, 몇 개의 언어에서 이용할 수 있는, 이 문제를 도와줄 library가 있다.
Of particular note is the chromium-compact-language-detector library from Mike McCandless, which uses the open source (Apache License 2.0) Compact Language Detector (CLD) from Google. It is small, fast, and accurate, and can detect 160+ languages from as little as two sentences. It can even detect multiple languages within a single block of text. Bindings exist for several languages including Python, Perl, JavaScript, PHP, C#/.NET, and R.
바로, Mike McCandless의 chromium-compact-language-detector library이다. 이것은 open source(Apache License 2.0)인 Google의 Compact Language Detector(CLD)를 사용한다. 작고, 빠르고, 정확하며, 두 문장만 있어도, 160개 이상의 언어를 감지할 수 있다. 심지어 단일 텍스트 block에서 여러 가지 언어를 감지할 수 있다. Python, Perl, Javascript, PHP, C#/.NET, and R을 포함한 여러 가지 언어로 사용할 수 있다.
Identifying the language of the user’s search request is not quite as simple. The CLD is designed for text that is at least 200 characters in length. Shorter amounts of text, such as search keywords, produce much less accurate results. In these cases, it may be preferable to take simple heuristics into account such as the country of origin, the user’s selected language, and the HTTP accept-language headers.
사용자 검색 request의 언어를 확인하는 것은 그리 간단하지 않다. CLD는 길이가 최소 200자인 문장(text)을 요구한다. 검색어처럼 문장(text)의 양이 적을수록, 훨씬 덜 정확한 결과가 만들어진다. 이런 경우에는, 원래의 국가, 사용자가 선택한 언어, HTTP accept-language header 같은, 몇 가지 추론을 고려하는 것이 더 나은 방법일 것이다.
'2.X > 3. Dealing with Human Language' 카테고리의 다른 글
| 3-1-1. Using Language Analyzers (0) | 2017.09.24 |
|---|---|
| 3-1-2. Configuring Language Analyzers (0) | 2017.09.24 |
| 3-1-4. One Language per Document (0) | 2017.09.24 |
| 3-1-5. One Language per Field (0) | 2017.09.24 |
| 3-1-6. Mixed-Language Fields (0) | 2017.09.24 |