Re: 영어 지원은 계획 없으신가요?

[Brian Jongseong Park]

안녕하세요? 관심과 좋은 말씀 감사드립니다.

Hangulize는 원 언어의 철자에서 발음을 예측하는 알고리즘을 써서 한글로 변환합니다. 이게 가능하려면 철자와 발음 대응이 어느정도 규칙적이어야 하는데 영어는 그렇지 않습니다. 잘 알려진 예로 철자 ough는 though '도', through '스루', rough '러프', cough '코프', thought '소트', bough '바우'에서 각각 다른 발음을 쓰며 전반적으로 철자를 통해 발음을 예측하기가 무척 어렵습니다.

자동적인 한글 표기 변환의 수요로 따지면 외국어 가운데서 영어가 가장 필요하다는 것이 극명하고 저도 언젠가는 지원하고 싶습니다. 그러려면 여러 규칙을 나열한 알고리즘만으로는 턱없이 부족하고 단어마다 발음을 기록한 사전이 필요합니다. 즉 지금의 Hangulize와는 다른 접근법이 필요하기 때문에 저로서도 언제 이게 가능할지 말씀드리기 어렵습니다.

앱 개발에서 필요하신 것이 정확히 무엇인가요? 혹시 한글로 변환해야 하는 영어가 한정되어 있다면 미리 영어와 한글을 대응시킨 사전을 통해 구현이 가능할지도 모릅니다.

2016-03-09 3:06 GMT+01:00 전무익 <mui...@gmail.com>:

안녕하세요~ 안드로이드 앱 개발자 입니다.

앱 개발에 필요한 영어를 입력하면 한글발음으로 변환하는 라이브러리를 찾고 있었는데요.

Hangulize가 딱 제가 원하는 라이브러리인데요. 너무 아쉽게 영어가 지원안되네요ㅠ

영어는 당연히 지원해야할 것 같은데 왜 지원안하는지 알 수 있을까요?

혹시 영어 지원하실 계획 있으신가요?

--
이 메일은 Google 그룹스 'Hangulize' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 hangulize+...@googlegroups.com에 이메일을 보내세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

[Heungsub Lee]

영어 전사의 입력으로 로마자가 아닌 음성기호를 직접 받으면 어떨까요?

2016년 3월 10일 (목) 오후 10:39, Brian Jongseong Park <ice...@gmail.com>님이 작성:

[Brian Jongseong Park]

예, 그러면 어느정도 구현이 가능할 텐데 문제는 어떤 음성기호를 쓸지 기준을 통일해야 되고 일반인들이 음성기호를 입력하기가 어렵다는 점입니다.

사전에 나오는 어휘로 제한한다면 발음 기호가 있는 기존 라이브러리를 활용할 수도 있겠는데요 아쉽게도 CMU Pronouncing Dictionary는 미국 영어 발음 정보만 있어서 외래어 표기법을 적용한 한글 표기로는 부적절합니다. 예를 들어 logic '로직'과 father '파더'의 첫 모음을 똑같이 표시합니다.

[Heungsub Lee]

음성기호 입력이 어려운 점은 사전 등을 동원해서 해결할 수 있을 것 같습니다.

저는 IPA 밖에 몰라서 어떤 음성기호 표기법이 적합할 지는 잘 모르겠네요. 한 번 표기법 별로 적합성을 따져볼 수 있을지요.

또 표기법 간 상호 변환이 가능한지 궁금합니다. 가능하다면 전사 룰에만 표기법을 통일시키고, 유저의 입력은 표기법에 구애 받지 않게 만들 수도 있겠습니다.

이흥섭 드림

2016년 3월 11일 (금) 오전 1:27, Brian Jongseong Park <ice...@gmail.com>님이 작성:

[전무익]

안녕하세요~ 답변이 늦어 죄송합니다.

앱에 필요한 기능은 안드로이드에서 영어로 된 앱을 한글로 검색할 수 있도록 자동 인덱싱에 사용하려고 합니다.

말씀해주신대로 영어는 너무 불규칙적이어서 규칙 알고리즘으로 구현이 불가능할 것으로 생각됩니다.

그래서 다른 방법을 찾던 중 구글지도에서 머신러닝을 이용하여 해결한 것을 발견했습니다.

http://googlekoreablog.blogspot.kr/2010/12/blog-post_4432.html

머신러닝을 이용한 방법인데요. 사람과 비슷하게 수많은 데이터를 학습시켜 읽게 만드는 것 입니다.

다음은 제가 최근에 머신러닝으로 만들어 본 머신 데모입니다.

https://transliterator.herokuapp.com

아직은 변환 결과가 어설픈 경우가 있는데 학습 데이터를 더욱 늘려 개선될 것으로 생각됩니다.

그래도 학습하지 않은 것을 제대로 읽는 경우도 꽤 있어 신기하긴 하네요.

혹시 (영어, 한글 표기) 학습 데이터를 수집할 의견 있다면 환영합니다~!!

2016년 3월 10일 목요일 오후 10시 39분 7초 UTC+9, iceager 님의 말:

[Heungsub Lee]

오 정말 멋지네요. 역시 딥러닝…

얼마나 많이 학습했는지도 알 수 있으면 들어가는 재미가 있을 것 같습니다

이흥섭 드림

2016년 5월 7일 (토) 오후 12:36, 전무익 <mui...@gmail.com>님이 작성:

[Brian Jongseong Park]

데모 정말 감사합니다.

저도 2011년에 구글의 홍선기씨와 연락해서 구글 지도에서 사용하는 외국어 지명의 한글 표기에 대해 의견을 드린 적이 있습니다. 되도록이면 외래어 표기법에 따라 표기해달라고 부탁드렸고 잘못된 표기 여러 개를 지적했는데 별로 고쳐진 것 같지는 않습니다. 지금 확인해보니 그때 지적한 '주부티', '이디오피아', '모리타니아', '벨로루시', '몽고' 등 대부분의 표기가 아직도 남아있습니다(표준 표기는 각각 '지부티', '에티오피아', '모리타니', '벨라루스', '몽골'입니다).

어쨌든 저도 적어도 그때부터 결국은 머신러닝을 통한 문제 해결이 필요하다고 생각해왔습니다. 그런데 저는 영어 철자에서 곧바로 한글 표기를 도출하는 것보다는 일정한 중간 단계를 거치는 것을 목표로 하고 있습니다.

그 이유는 몇가지가 있는데 첫째로는 제가 개인적으로 영어 철자에서 한글 표기 뿐만이 아니라 영어 발음 기호, 또는 일본어의 가타가나 같은 다른 문자 체계로 전사하는 것도 가능하게 하고 싶어서입니다. 또 한글 표기만 고려한다 하더라도 우선 영어의 발음을 고려하고 이에 따라 표기를 정하는 외래어 표기법의 원칙이므로 발음을 나타내는 중간 단계를 거치는 것이 실제 외래어 표기 결정 과정에 더 근접합니다. 또 의외로 외래어 표기법이 명확히 정해지지 않은 부분이 많은데 영어 철자에 해당하는 영어 발음을 알아내는 단계와 그 발음을 어떻게 한글로 표기할지 결정하는 단계를 분리하면 외래어 표기 지침이 보완됨에 따라 추후 수정이 용이해집니다.

구체적인 예로 설명하겠습니다. 예를 들어 Albert라는 이름이 있으면 그 발음 및 한글 표기에 필요한 모든 정보를 담은 표현식 ˈălb⁰ĕrt라는 형태로 저장하는 것입니다(예로 든 것이고 실제 표현식을 어떻게 할지는 좀더 연구해볼 생각입니다). 이 ˈălb⁰ĕrt라는 표현식에서 Hangulize에서 쓰는 것 같은 규칙적인 변환 알고리즘을 통해 한글 표기인 '앨버트'를 도출할 수도 있고 다른 알고리즘을 적용하면 영어 발음 기호인 [ˈælb.ət](영국식), [ˈælb.(ə)rt](미국식)도 도출할 수 있습니다. 잘하면 일본어 가타가나 표기인 アルバート '아루바토'도 도출 가능할 것입니다.

어쨌든 이것은 장기적인 구상이고 어떻게 하면 이런 표현식을 잘 쓸 수 있을지 아직 연구 중인데 준비하신 데모를 보니 일단은 중간 단계를 거치지 않고 영어 철자에서 바로 한글 표기를 도출하도록 학습시키는 것도 좋은 방법 같습니다.

아직 학습 데이터에 미흡한 점이 보입니다. 일단 외래어 표기 용례집에서 영어가 아닌 외래어도 영어로 간주한 것이 보입니다. Michael은 '미카엘'로 변환하던데 '미카엘'은 히브리어/고대 그리스어/라틴어 발음에 따른 표기이고 영어에 따른 표기는 '마이클'입니다. '니켈'은 영어 nickel이 아니라 독일어 Nickel에 따른 표기로 영어 발음에 따라 적으면 '니클'입니다. '비타민'도 Vitamin의 독일어 발음을 따른 표기로 영어 발음은 영국식 '비터민', 미국식 '바이터민'입니다. 음악 용어인 opera '오페라'와 piano '피아노'는 영어가 아닌 이탈리아어 발음을 따른 것이고 radio '라디오', uranium '우라늄' 같이 특히 과학 용어 가운데 영어 발음이 아닌 독일어나 이탈리아어, 국제 라틴어 발음을 따른 외래어가 많은데 영어에서 쓰는 형태가 철자가 같다고 해서 영어 표기를 학습시킬 때 포함시킬 수는 없습니다. 실제 영어 발음에 외래어 표기법을 적용한 표기는 '오퍼라', '피애노', '레이디오', '유레이니엄' 등이니까요.

또 영어에서 온 외래어도 들어온지 오래된 것 가운데는 외래어 표기 규정에 어긋나지만 관용을 인정한 표기가 많습니다. gum '껌', coffee '커피', set '세트', out '아웃', big '빅' 등은 규정을 적용하면 각각 '검', '코피', '셋', '아우트', '비그'이어야 하지만 관용 표기로 인정한 것입니다. 이런 것은 사전에는 포함하되 학습 데이터에서 제외시키거나 포함시키더라도 예외적인 표기라는 것을 인지해서 따로 처리할 수 있게 해야 하겠습니다.

한편 Birmingham은 영국 지명으로는 '버밍엄', 미국 지명으로는 '버밍햄'인데 '버밍헴'으로 쓴 오타도 있습니다.

혹시 학습 데이터로 쓴 것을 정리해서 보내주실 수 있으면 확인해드릴 수 있고 추가 데이터도 제공해드리겠습니다.

영어는 철자와 발음의 관계가 너무 까다로운 경우고 프랑스어와 독일어에 적용하면 더 좋은 결과가 나올 수 있을 것 같습니다. 좋으시다면 프랑스어와 독일어 쪽으로도 협력하는 것이 어떨지요?

[Brian Jongseong Park]

아, 이제야 GitHub 페이지를 발견했습니다...

소스 파일 가운데 cities.txt를 보면 세계 여러 도시의 영어 이름과 한국어 이름을 짝지었습니다. 하지만 영어권 도시가 아닌 것들은 보통 영어 발음을 따른 것이 아니기 때문에 영어의 전사가 목적이면 학습 데이터에 포함시킬 수 없습니다.

예를 들어 Shanghai를 '상하이'로 적은 것은 중국어 표기법을 따른 것이고 Stuttgart를 '슈투트가르트'(cities.txt에는 '슈트트가르트'로 오기되었습니다)로 적은 것은 독일어 표기법을 따른 것, Kumamoto를 '구마모토'로 적은 것은 일본어 표기법을 따른 것입니다. 영어 발음에 따라 적는다면 각각 '샹하이', '스툿가트', '쿠마모토' 정도가 됩니다.

이쯤에서 짐작하셨겠지만 변환기의 목적이 무엇인지를 분명히 정할 필요가 있습니다. 만약 Shanghai를 입력시키면 원하는 것이 이를 영어 단어로 보고 영어 발음에 따라 한글로 표기하는 것인지 아니면 이것을 한국어로 번역하는 것인지 분명히 알아야 합니다. 전자라면 '샹하이', 후자라면 '상하이'를 출력해야 합니다. 하지만 후자를 택한다면 변환기는 영어 뿐만이 아니라 다국어 변환기가 되어야 합니다. 거기다가 Richard라는 이름이 있으면 영어로는 '리처드', 프랑스어로는 '리샤르', 독일어로는 '리하르트'이니 원어에 따라 표기가 달라지는데 이를 어떻게 정하느냐는 문제도 생깁니다.

그러니 가장 좋은 방법은 영어 발음을 기준으로 한글 표기를 하는 것으로 목적을 한정하되 널리 쓰이는 한국어 번역명이 있으면 함께 보여주는 것입니다.

즉 Shanghai를 입력하면 메인 창에는 영어 발음에 따라 표기한 '샹하이'를 보여주고 옆에는 번역 API를 쓰던지 해서 Shanghai를 한국어로 번역한 '상하이'를 나란히 보여주는 것입니다.

이 방법을 쓰면 관용으로 굳어진 불규칙 외래어 표기의 문제도 함께 처리할 수 있습니다. 예를 들어 다음과 같이 쓰는 것입니다.

Shanghai 변환 결과: '샹하이', 번역: '상하이'

Hamburg 변환 결과: '햄버그', 번역: '함부르크'

gum 변환 결과: '검', 번역: '껌'

net 변환 결과: '넷', 번역: '네트'

coffee 변환 결과: '코피', 번역: '커피'

참고로 소스 파일에 비표준 표기도 많이 보입니다. Las Vegas는 '라스베가스'가 아니라 '라스베이거스', Saipan은 '싸이판'이 아니라 '사이판', Phuket은 '푸켓'이 아니라 '푸껫'이 표준 표기입니다.

시간이 되면 규칙적으로 영어 표기법을 적용한 외래어 용례만 추린 파일을 준비해보겠습니다.

[전무익]

아직 데모지만 면밀히 봐주셔서 감사합니다.

말씀해주신데로 데이터가 미흡한 점이 많이 있습니다. 따라서 변환 결과 품질도 아직 낮은 상태입니다. 양질의 데이터를 수집하기 쉽지 않더군요. 같은 알파벳 단어라도 국가별로 여러 표기가 있기도 하고, 수집한 곳에 따라 다른 표기 그리고 띄어쓰기도 제각각이어서 정리가 필요합니다. 제가 정확히 모르는 부분이 많아 주로 검색해보며 조금씩 정리하고 있는데 꽤 오래 걸리네요. 최근에 조금 수정한 것을 github에 업데이트 했습니다. https://github.com/muik/transliteration/tree/master/data/source

처음 목적은 표준 표기를 학습한대로 영어를 표기할 수 있게 하는 것인데요. 만들어보니 알려주신대로 나라별 표기법에 따라 다른 애매한 부분은 정리해야할 것 같습니다.

목적을 다시 정해보면 실용적으로 쓰일 수 있는 영어-한글 표기 변환기 입니다. 제가 생각해 본 기준 두가지가 있는데요.

1. 해당 국가별 표기법은 그대로 따르기

각 국가별 단어는 어느정도 규칙이 있다고 생각합니다. 사람도 지난 경험으로 Kumamoto나 Stuttgart, Shanghai를 처음 보더라도 유추해서 읽을 수 있는 것 처럼이요.

Kumamoto의 알파벳을 보고 구로 시작해서 머신은 더 정확하게 읽을 수 있지 않을까 가정하고 있습니다^^;;

2. 국가별로 구분하기

Richard와 같이 국가별로 다르게 표기할 경우 우선 영어권으로 한정합니다. 학습데이터를 잘 걸러내면 될 것 같습니다.

그리고 영어권이 어느정도 좋은 성능을 낸다면 프랑스나 독일 버전으로 추가로 협력 개발하면 좋을 것 같습니다.

한글 표기로 실제 쓰이는 목적을 생각했을 때 발음과 번역에 대해서는요. 한글 표기에는 발음기호를 정확히 따르지 않는 경우가 많은 것 같은데요. 발음기호를 따른 한글 표기하면 어색한 경우가 많지 않을까 생각됩니다. 번역 기능은 향후 추가 기능으로 좋을 것 같습니다.

영어 표기법 적용한 외래어 파일 준비해주시면 적용해보겠습니다~!

의견 주셔서 감사합니다.

2016년 5월 11일 수요일 오전 1시 1분 9초 UTC+9, iceager 님의 말:

[Brian Jongseong Park]

처음부터 모든 것을 다 할 수는 없습니다. 원어에 상관없이 로마자를 입력하면 거기에 대응하는 한글 표기를 출력하는 프로그램을 원하시는 것 같은데 예를 들어 London을 입력하면 '런던', Seoul을 입력하면 '서울', Tokyo를 입력하면 '도쿄', Berlin을 입력하면 '베를린', Shanghai를 입력하면 '상하이'를 출력하는 것은 정말로 방대한 데이터 없이는 머신러닝으로는 구현이 불가능합니다. 로마자 문자열을 보고 먼저 language recognition을 통해 원어가 무엇인지 파악한 후 해당 언어에 알맞은 표기 규칙을 적용해야 하는 것이니 영어의 한글 표기 뿐만이 아니라 로마자로 쓴 한국어, 로마자로 쓴 일본어, 독일어, 로마자로 쓴 중국어를 한글로 표기하는 모듈이 모두 필요한 것입니다.

이것은 마치 자동번역기를 만들면서 원어를 구분 없이 영어를 한국어로 번역한 문장, 독일어를 한국어로 번역한 문장, 프랑스어를 한국어로 번역한 문장 등을 구분 없이 모두 학습 데이터에 포함시키고 훈련시켜 모든 언어를 한국어로 번역할 수 있도록 하겠다는 것과 같습니다.

더구나 이것은 로마자 형태가 한글 표기에 쓰인 형태와 같다는 가정 아래서만 구현이 가능합니다. 예를 들어 뮌헨의 영어 이름인 Munich이나 모스크바의 영어 이름인 Moscow를 입력하면 어떻게 해야 할까요? Munich, Moscow란 영어 이름에서 '뮌헨', '모스크바'란 표기를 도출할 방법은 없습니다. 영어의 Munich, Moscow를 한국어로 번역하면 '뮌헨', '모스크바'라는 정보는 일일이 사전을 참조해야지 머신러닝을 통해 짐작할 방법이 없습니다.

일반인이 흔히 생각하기 쉬운 것 가운데 하나가 로마자로 적은 외국어는 다 영어이고 한자어나 일본어 외의 외래어는 모두 영어에서 왔다고 생각하는 것입니다. 절대 그렇지 않습니다. 프랑스어에서 온  '뷔페', '발레', '크레용', 독일어에서 온 '알레르기', '깁스', '헤게모니' 등 수없이 많고 말씀드린 것처럼 '니켈'는 영어 nickel이 아니라 독일어 Nickel의 표기이고 '오페라'는 영어 opera가 아니라 이탈리아어의 opera, '모자이크'는 영어의 mosaic이 아니라 프랑스어의 mosaïque의 표기입니다. 영어 발음대로 표기한다면 각각 '니클', '오퍼라', '모제이익'입니다. 영어 발음에 따라 적으면 어색한 이유는 우리에게 친숙한 외래어 가운데 상당수가 영어가 아닌 다른 언어를 기준으로 한 형태이기 때문입니다.

이게 제대로 이해해야 할 정말 중요한 점인데 이것을 간과하면 우리가 보통 영어를 한글로 옮겨 적는 방식이 바로 영어를 한글로 표기하는 것이라고 완전히 오해할 수가 있습니다. 예를 들어 영어로 restaurant라고 쓴 것을 보고 한글로 '레스토랑'이라고 옮겨 적는다면 이것은 영어 restaurant를 영어 발음에 따라 한글로 표기한 것이 아니라 이에 대응되는 외래어 '레스토랑'으로 번역한 것입니다. 영어의 restaurant과 한국어의 '레스토랑'은 둘 다 프랑스어의 restaurant에서 온 외래어이며 '레스토랑'은 프랑스어 발음을 따른 표기입입니다. restaurant을 '레스토랑'으로 적는 것은 영어를 한글로 표기하면서 발음 기호를 따르지 않고 대충 적은 결과가 아니라 어원이 같은 외래어로 번역하는 것입니다. 이런 번역을 머신러닝으로 구현하려는 것은 무리입니다. 자동번역기도 개별 단어를 어떻게 번역해야 하는지는 사전에 의지합니다.

외래어마다 국어에 들어온 경로와 시기에 따라 형태가 크게 차이가 나니 폭넓게 적용되는 규칙을 찾기는 힘듭니다. 같은 cut도 영화 용어로는 '컷', 미용이나 스포츠 용어로는 '커트'로 쓰는 것이 외래어입니다.

중구난방인 외래어 표기를 통일하기 위해 각 언어를 한글로 표기하는 규칙을 마련한 것이 외래어 표기법이지만 이미 굳어진 관용 표기는 규칙에 맞지 않더라도 인정했기 때문에 외래어 표기 용례집은 이런 예외로 가득합니다. 그래서 관용으로 인정되어 사전에 실린 외래어 표기 형태를 따르는 것이 목적이면 머신러닝이 필요한 것이 아니라 사전을 그냥 사용하면 그만입니다. 학습이 필요 없습니다.

머신러닝이 필요한 경우는 사전에 실리지 않은 외래어를 한글로 표기해야 할 때입니다. 이럴 때는 외래어 표기법을 규칙적으로 따라야 합니다. 불규칙 표기는 수가 한정된 유한 집합이지만 규칙 표기는 아직 사전에 실리지 않은 모든 외래어 표기가 포함된 무한 집합입니다. 머신러닝을 적용할 대상은 후자입니다.

영어 문법의 예로 설명을 드리겠습니다. 영어에는 go-went-gone, see-saw-seen, think-thought-thought, sing-sang-sung 등 현재형, 과거형, 과거분사형의 관계가 불규칙한 동사가 수백 개 있습니다. 그러나 이 제한된 목록해 들지 않은 동사는 모두 ask-asked-asked, count-counted-counted, fill-filled-filled 등으로 규칙적으로 변화합니다. 그러니 본 적이 없는 새로운 동사의 과거형이나 과거분사형을 만들 때는 현재형에 -ed를 붙이면 그만입니다(이 규칙을 알아내려고 머신러닝까지 필요한 것은 아니지만 어쨌든 예로 듭니다).

그런데 불규칙 동사 수백 개를 모두 학습 자료에 포함시키고 *kee라는 본 적이 없는 새로운 동사를 활용시키라 하면 see-saw-seen에서 유추해서 *kee-kaw-keen으로 활용할지 모릅니다. *kee-keed-keed가 실제 원어민이 쓸 규칙 활용인데도 말입니다.

그래서 불규칙 표기는 사전에는 포함시키지만 학습 자료에서는 제외시키고 외래어 표기법을 적용한 규칙 표기만을 학습 자료에 포함시켜야 한다고 말씀드리는 것입니다.

그런 의미에서 학습 자료와 사전 자료는 분리시켜야 할 것 같습니다. 이런 방법은 어떨까요? New York '뉴욕', Shakespeare '셰익스피어' 등은 불규칙이지만 관용으로 인정된 표준 표기이니 사전에 저장하여 사용자가 New York, Shakespeare를 그대로 입력하면 '뉴욕', '셰익스피어'로 표기하는 한편 학습 자료로 쓸 때에는 규칙을 따른 '뉴요크', '셰이크스피어'로 써서 -ork는 보통 '오크'로 적는다, 이중모음 뒤의 k는 '크'로 적는다 등의 규칙을 학습하는데 방해가 되지 않도록 하는 것입니다.

또 한글 표기를 여럿 제시하는 것은 구현이 가능할까요? 예를 들어 live는 경우에 따라 '라이브'가 될 수도 있고 '리브'가 될 수도 있으니 둘 다 출력하는 것입니다. 자동번역기에서 번역된 낱말을 클릭하면 다른 번역 예도 보여주는 것처럼요. 어차피 학습 자료를 만들려면 영어에서 live와 같이 같은 철자가 여러 발음이 나는 경우를 모두 입력해야 하긴 합니다.

[전무익]

그렇군요. 자세한 설명 잘 봤습니다. 좀 많이 간단하게 생각했던 것 같습니다. 데이터가 방대히 많지 않으면 불규칙을 해결하긴 쉽지 않겠군요.

학습 자료와 사전 자료를 분리시키면 좋을 것 같은데, 한가지 생기는 문제가 있을 것 같습니다.

불규칙 단어로 생기는 변형어가 있기 때문입니다. 예를 들어 Zoo York이라는 브랜드명이 있는데 뉴욕과 비슷하게 주욕이라고 표기해야 자연스러운 것 같기 때문입니다.

머신러닝 학습에 불규칙에 규칙이 함께 있더라도 입력어가 불규칙과 많이 비슷하지 않으면 규칙 데이터가 많으므로 규칙을 따를 것으로 예상합니다.

현재 구현으로는 여러개 제시는 불가능합니다. 다른 학습모델을 적용하면 확률적으로 가능한 제시 높은 순으로 출력하는게 가능할 것 같은데요. 아직 머신러닝 기초단계라 쉽진 않을 것 같네요^^; 그러면 간단하게 경우에 따라 분류하여 학습기를 여러개로 구분하면 어떨까 합니다. 그리고 여러곳에서 변환결과를 모아 제시하면 될 것 같습니다. 하지만 문제가 입력이 모두 경우가 동일하지 않으므로 경우가 해당하지 않을 경우에 엉터리 결과가 나올 수 있겠네요.

2016년 5월 11일 수요일 오전 6시 21분 39초 UTC+9, iceager 님의 말: