형태소 분석 결과가 기대와 다를 때 — 디버깅 체크리스트

분명 맞는 문장인데 형태소 분석 결과가 어색하게 나오나요? "왜 이렇게 쪼개지지?" 싶을 때 순서대로 짚어볼 디버깅 체크리스트입니다.

증상

• 어절이 엉뚱하게 분절되거나, 품사 태그가 기대와 다릅니다.
• 띄어쓰기·붙여쓰기가 원하는 대로 처리되지 않습니다.
• 같은 단어가 문맥에 따라 다르게 분석됩니다(중의성).

원인

바른은 분절 → 품사 태깅 → 후처리 단계를 거칩니다. 결과가 어색할 때는 보통 다음 중 하나가 작용한 거예요.

해결 — 체크리스트

1. out_of_vocab부터 보세요. IN_BUILTIN_DICT·IN_URIMALSAEM 등 사전 출처면 정상 단어로 인식된 것이고, OUT_OF_VOCAB이면 미등록단어가 원인입니다. 후자라면 사용자 사전 등록을 고려하세요(NA·UNK 문서 참고).

2. probability(확신도)를 확인하세요. 형태소마다 softmax 확신도가 붙습니다. 값이 낮은 형태소는 모델이 자신 없어 한 부분이니, 거기서부터 의심하세요.

3. 띄어쓰기 옵션을 점검하세요. auto_spacing(띄어쓰기 보정), auto_jointing(붙여쓰기 보정)이 켜져 있으면 원문 어절 경계가 바뀝니다. 원문 그대로 분석하려면 이 옵션들을 끄고 비교해보세요.

   복사

   {
     "document": { "content": "아름다운강산", "language": "ko_KR" },
     "auto_spacing": true
   }
   

   refined(수정된 결과)와 modified(붙여쓰기로 원문을 수정해 인식) 표시를 함께 보면 어떤 보정이 일어났는지 알 수 있어요.

4. 중의성을 의심하세요. 같은 표기가 문맥에 따라 다른 품사로 분석되는 건 정상입니다. 바른은 문맥을 보고 가장 그럴듯한 분석을 고릅니다. 의도와 다르면 사용자 사전으로 특정 해석을 유도할 수 있어요.

5. 위치가 어긋나 보이면 인코딩을 확인하세요. 형태소 위치(begin_offset/length)는 요청한 encoding_type(UTF8/UTF16/UTF32)에 따라 값이 달라집니다. 클라이언트 인코딩과 맞췄는지 보세요.

예방·팁

• 분석 결과를 디버깅할 때는 out_of_vocab, probability, refined/modified를 함께 보면 원인을 빠르게 좁힐 수 있습니다.
• 도메인 용어가 자주 어긋난다면 사용자 사전을 보강하는 것이 가장 근본적인 해법입니다.

자주 묻는 질문

Q. 결과가 기대와 다를 때 가장 먼저 무엇을 보나요?

형태소의 out_of_vocab와 probability를 보세요. OUT_OF_VOCAB이면 미등록단어가 원인이고, probability가 낮으면 모델이 확신하지 못한 부분입니다. 둘이 디버깅의 출발점입니다.

Q. 같은 단어가 문맥마다 다르게 분석돼요.

중의성 때문입니다. 바른은 문맥을 보고 가장 그럴듯한 품사를 고르므로 정상 동작입니다. 특정 해석을 고정하고 싶으면 사용자 사전으로 유도할 수 있습니다.

Q. auto_spacing을 끄면 어떻게 되나요?

띄어쓰기 보정을 하지 않고 원문 어절 경계를 그대로 둡니다. 보정 전후 결과를 비교하려면 옵션을 끄고 다시 분석해 refined·modified 표시 유무를 확인하세요.

Q. 품사 태그가 어색해요. 모델이 틀린 건가요?

먼저 형태소의 probability(확신도)를 보세요. 값이 낮은 형태소는 모델이 자신 없어 한 부분이니 거기서부터 의심하면 돼요. out_of_vocab가 OUT_OF_VOCAB이면 미등록단어가 원인이라 사용자 사전 등록이 근본 해법이고, 정상 출처인데 어색하다면 중의성일 수 있습니다.

Q. 형태소 위치(offset)가 어긋나 보여요.

형태소 위치(begin_offset/length)는 요청한 encoding_type(UTF8/UTF16/UTF32)에 따라 값이 달라집니다. 클라이언트가 쓰는 인코딩과 요청의 encoding_type을 맞췄는지 확인하세요. 원문 순서·위치를 그대로 유지하려면 AnalyzeSyntaxList를 쓰는 것이 유리합니다.