반응형

음성인식 API는 어떻게 사용하는가?  SKTelecom NUGU


 

요약 

설명 

createSpeechRecognizer() 

초기화 

인식시 생성 

destroy() 

객체 소명 

인식기 소멸 

startListening()

인식 시작 


- 서버 접속 수행 후 마이크에서 음성입력을 받아 인식 수행

- 음성입력이 끝나면 자동으로 인식이 종료되고 createSpeechRecognizer() 실행 시  설정한 listener를 통해 인식 결과 또는 오료 결과를 반환 한다.


stopListening()

인식 종료 


- 음성인식을 종료

- 호출시점까지 입력된 음성으로 인식을 수행하고, createSpeechRecognizer() 실행시 설정한 listener로 인식 결과 또는 오류 결과를 반환 


onResults()

음성인식 완료 시 호출 


- 음성인식이 완료되면 호출

- 음성인식 결과는 SpeechRecognizer의 getSpeechRecognitionResults() 함수를 사용하여 읽어 올 수 있다. 



반응형
반응형
초보자를 위한 RNNs과 LSTM 가이드



이 포스팅은 RNNs(Recurrent Neural Networks), 특히 RNNs의 한 종류인 LSTM(Long Short-Term Memory)을 설명하는 포스팅입니다.

RNNs은 글, 유전자, 손글씨, 음성 신호, 센서가 감지한 데이타, 주가 등 배열(sequence, 또는 시계열 데이터)의 형태를 갖는 데이터에서 패턴을 인식하는 인공 신경망 입니다.

RNNs은 궁극의 인공 신경망 구조라고 주장하는 사람들이 있을 정도로 강력합니다. RNNs은 배열 형태가 아닌 데이터에도 적용할 수 있습니다. 예를 들어 이미지에 작은 이미지 패치(필터)를 순차적으로 적용하면 배열 데이터를 다루듯 RNNs을 적용할 수 있습니다.

RNNs은 배열에 등장했던 패턴을 ‘기억’할 수 있는 능력이 있습니다. 이 부분은 사람의 기억과 기억력에 비유하면 아주 간결하게 설명할 수 있어서 종종 RNNs을 사람의 뇌처럼 취급합니다.






반응형
반응형
‘리캡차’가 사라진다  reCAPTCHA: Tough on Bots, Easy on Humans

출처 ㅣ http://www.bloter.net/archives/273960



‘캡차'(CAPTCHA, Completely Automated Public Turing test to tell Computers and Humans Apart)는 사람과 컴퓨터를 판별해주는 보안 과정이다. 회원 가입이나 비밀번호 찾기를 할 때 종종 볼 수 있다. 기껏해야 10초 남짓이지만, 귀찮다. 구글이 이런 귀찮음을 덜어주기 위한 새로운 서비스를 내놓는다.


구글이보이지 않는 리캡차를 선보인다고 3월10일(현지시각) <아스테크니카>가 보도했다. 이전에 사람이 직접 글자를 입력하고 클릭으로 로봇이 아님을 직접 밝혀야 했다면, 이제 의심 가는 기계나 컴퓨터에만 보인다. 즉, 사람이라고 판단되면 보안 과정 없이 넘어간다.


캡차는 2000년, 카네기멜론 연구원들이 모여 만들었다. 2007년 ‘리캡차'(reCAPTCHA)로 이름이 바뀌면서 기술이 업그레이드됐고, 2009년 구글에 인수됐다. 당시 리캡차는 컴퓨터가 인식하지 못하는 고문서의 단어들과 인식 가능한 단어를 조합해 보여줬다. 사람들이 단어를 입력하는 10초 남짓 시간을 되도록 유용한 일에 쓰자는 뜻에서 고안됐다. 이런 식으로 리캡차는 디지털 작업과 보안을 동시에 성취했다.


하지만 시간이 흐르면서 이를 뛰어넘는 해킹 기술이 등장했다. 그러한 동향에 맞춰 2014년에 새로운 기술의 ‘노캡차 리캡차’가 재탄생했는데, 바로 지금 우리가 사용하는 버전이다. ‘나는 로봇이 아니다(I am not a Robot)’나 해당하는 블록 찾기와 같이 클릭을 통해 사용자가 사람인지 컴퓨터인지를 구분한다.


캡차, 리캡차, 노캡차 리캡차 비교 (기사)


문자를 넣는 방식에서 클릭하는 방식으로 이미 과정이 많이 생략되고 간단해졌지만, 구글은 거기서 멈추지 않았다. 이제는 사람들이 굳이 어떤 행동을 하지 않아도 보안 과정을 통과할 수 있게 만들어 사용자 환경을 개선했다.

보이지 않는 리캡차는 사용자들의 브라우징 습관을 이용한다. 사용자가 로그인한 뒤 하는 행동들을 파악해 이 시스템이 좀 더 정교할 수 있게끔 한다. 소개 영상에서는 ‘이 혁신을 가능하게 하는 건, 새롭게 등장한 위협에 대응하기 위해 기계학습과 진보된 위협 분석의 조합하는 것’이라 말하고 있지만, 자세한 원리는 찾기 힘들다. <아스테크니카>는 또다시 기술이 파악돼 새로운 위협에 노출되는 것을 의식한 구글이 자세한 설명을 공개하지는 않을 것 같다고 설명했다.

보이지 않는 리캡차는 무료로 사용할 수 있다. 현재는 기존 노캡차 리캡차와 보이지 않는 리캡차 중 하나를 선택해 사용할 수 있도록 제공되고 있다.



.







반응형
반응형

바풀, 세계 최초 ‘자동답변’ 에듀테크 기술 개발 2016-09-26


http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=014&aid=0003711273


에듀테크 시대 새로운 공부문화를 창조하는 ㈜바풀은 전 세계 최초로 사진 속 수학문제를 인식해 같은 문제와 유사 문제를 찾아 풀이와 답변을 제공하는 ‘자동답변’ 기술을 개발했다고 26일 밝혔다. 


㈜바풀은 바로풀기 서비스를 통해 모르는 문제가 생기면 스마트폰으로 사진을 찍어 질문하고 답변 받는 무료 공부 Q&A서비스를 운영 중이다. 이번에 개발한 ‘자동답변’ 에듀테크 기술은 지난 6년 간 바로풀기 서비스를 통해 구축한 400만 개 가운데 답변이 달린 100만 개의 DB를 검토하여 똑같은 질문을 찾아서 풀이와 답변을 보여주는 기술이다. 

똑같은 질문이 없을 경우, 수학문제의 수식과 텍스트(한국·영어)를 인식해서 유사한 질문의 답변을 제공하는 방식으로 문제풀이를 도와준다. 

세계 최초로 개발한 ‘자동답변’ 기술은 세 가지 기술이 융합되어 얻어진 결과다. 

먼저 ‘사진 후처리 기술’은 사용자가 촬영한 수학 문제로부터 각종 노이즈를 제거하고, 회전각과 비틀림 각을 보정해 문제 사진이 수평이 되도록 만든다.

이렇게 보정된 사진은 20여 단계로 구성된 독자적인 OCR(OpticalCharacter Reader/Recognition, 광학적 문자 판독) 기술을 통해 사진 속의 텍스트와 수식을 분리하고 이를 메타 정보로 기록한다. 

마지막으로 6년간의 서비스에서 얻어진 각 학년별 수학 단원 및 개념 맵을 활용함으로써 DB로부터 해당 문제의 답변, 그리고 사용자에게 도움이 될 수 있는 유사 문제를 제공한다. 

지금까지의 OCR기술은 한글보다 상대적으로 쉬운 언어인 영문 환경에 한해서만 그 기능을 수행할 수 있었고, 수학 문제에서는 수식으로만 이루어진 간단한 계산문제에 대해서만 풀이를 제공하는 수준이었으나, ㈜바풀은 세계 최초로 한글과 수식이 혼합된 환경에서도 그 둘을 각각 분리하여 사진 형태의 문제를 분석해 3초 정도의 시간이면 답변을 찾아준다. 

㈜바풀의 ‘자동 답변’기술을 통해 얻어진 학생의 정보는 KnowledgeTracing이 가능하며, 학생의 학습이력 관리 및 수준에 맞는 맞춤 강의와 선생님을 추천할 수 있다. 또한, 문제를 바탕으로 메타 콘셉트 데이터를 구축해서 문제 하나가 갖고 있는 여러 개념들을 묶어주고 분류할 수 있게 되어 학생들에게 유용한 정보를 제공할 수 있게 된다. 

바풀 김영재 CTO는 “바풀의 ‘자동답변’ 신기술을 통해 많은 학생들이 수학을 포기하지 않고 공부에 대한 재미를 느꼈으면 좋겠다”며 “㈜바풀은 교육과 IT를 접목한 에듀테크 신기술로 모든 학생들이 동등한 교육환경 속에서 양질의 교육을 경험할 수 있도록 노력하겠다”고 전했다. 

반응형
반응형
구글, 기업용 영상회의 서비스 ‘미트’ 출시













.



반응형
반응형

편리한 주문 시스템, O2O서비스 / YTN 사이언스


챗봇으로 만든 대화형 커머스 '톡 주문'  http://blog.lgcns.com/1142



What is O2O?






반응형
반응형

넷플릭스 사전엔 버퍼링이란 없다


"넷플릭스는 (모뎀 시절)다이얼톤 처럼 버퍼링을 유물로 만들겠다."


헤이스팅스 CEO "모든 기기서 바로 볼 수 있도록 하겠다"


리드 헤이스팅스 넷플릭스 최고경영자(CEO)는 27일(현지시간) 스페인 바르셀로나에서 열린 MWC(Mobile World Congress)에서 기조연설을 하며 넷플릭스의 목표는 모든 기기에서 바로 동영상을 시청할 수 있는 것이라고 밝혔다.

헤이스팅스는 이날 기조연설에서 모뎀으로 통신에 연결하던 시절에 울렸던 다이얼톤을 언급하며 버퍼링을 줄이기 위해 네트워크 서버나 코덱, 콘텐츠 전달 메커니즘에 투자하고 있다고 강조했다. 

넷플릭스는 DVD 대여 서비스로 시작해 2007년 동영상 스트리밍 서비스업체로 변신했다. 지난해 글로벌 서비스를 시작하며 190개 나라에서 서비스하고 있다. 전세계 9천300만명이 넷플릭스 가입자이며, 이들 중 대부분이 스마트폰으로 넷플릭스를 이용하고 있다. 미디어기업 CEO가 MWC에서 처음으로 기조연설을 하는 이유이기도 하다.


헤이스팅스는 "많은 회사가 동영상 스트리밍 서비스를 제공하고 있지만, 속도는 느려지고 있다"며

 "넷플릭스는 코덱에 투자해 300Mbps(초당 메가비트) 속도를 제공하고 있다"고 설명했다.

그는 통신사업자와 협력을 통해 속도를 높여 더 효율적으로 운영하길 희망한다며, 200Mbps 속도에 도달하기 위해 노력하고 있다고 말했다.

콘텐츠 확장성에 대해서도 언급했다. 헤이스팅스는 "1억명에 달하는 글로벌 가입자가 있기 때문에 플랫폼이 더 커질 수 있다"며 "서비스 초반에는 대부분 헐리우드 콘텐츠뿐이었다"며 "지금은 터키나 일본, 한국 등과 작업하고 있다"고 말했다.

아마존과 애플 등과의 경쟁에 대한 질문에 헤이스팅스는 "그 기업들은 소비자가 원하는 서비스를 제공하려고 노력하는 회사"라고 말하며 "앞으로 인터넷을 통해 모든 동영상이 제공될 예정이며, 넷플릭스는 그 중 하나다"라고 대답했다.



원문보기: 

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20170228074134

반응형
반응형

구글이 제시한 '관리자의 자격'



2002년 무렵 구글에는 관리자가 없었다. 당시의 구글은 개발자에 의한, 개발자를 위한, 개발자의 회사였다. 그들은 철저히 개발자 중심 문화를 가지고 있었기 때문에 관리자가 필요없다고 생각했을 것이다. 코드를 생산하는 개발자 중심 문화에서 관리자는 잘하면 필요악, 그렇지 않으면 개발자에게 기생하는 부차적 존재로 취급되었을 것이다.

개발자 중심의 문화는 구글만의 이야기가 아니다. 2002년에 국한되는 이야기도 아니다. 지금도 미국에서는 코딩 실력이 좋은 개발자가 관리자가 되기를 거부하거나 마음속으로 관리자의 업무를 불필요하게 생각하는 일이 드물지 않다. 지위가 올라가도 코드를 생산하지 않으면 부차적 존재라는 자괴심을 느낄 수밖에 없는 문화다. 그렇기 때문에 좋은 관리자들은 기술로부터 멀어지지 않기 위해서 부단한 노력을 기울인다. 최근 칼럼에서 언급한 개발자 무정부주의(developer anarchy)는 이런 개발자 중심 철학과 문화의 연장선에 놓여있다.

관리자의 필요성을 인정하지 않은 구글은 2008년에 한 걸음 더 나아가서 관리자 무용론을 실제로 증명하기 위한 연구를 진행했다. 그걸 증명까지 해야할까 싶지만, 아벨 아브람이 최근 인포큐에 기고한 글에 의하면 구글의 연구는 기대했던 것과 반대의 결론을 도출했다고 한다. 관리자가 쓸모없는 존재가 아니라 팀의 생산성을 담보하기 위한 중요한 요소라는 뜻밖의(!) 결과가 나온 것이다. 

[아벨 아브람 기고 원문 바로가기]


팀에 마이너스가 되는 엉터리 관리자가 많은 것은 사실이지만 팀의 생산성을 높이는데 결정적인 역할을 수행하는 좋은 관리자가 존재하는 것도 사실이다. 이것은 우리의 상식이나 경험에 비추어봐도 이해하기 어려운 일이 아니다. 

그럼 팀에 도움이 되는 좋은 관리자는 어떤 사람인가? 


* 구글의 연구팀은 좋은 관리자가 가져야 하는 8가지 덕목을 다음과 같이 정리했다.

1. 좋은 코치(coaches)다.


2. 팀에게 권한을 양도하며 마이크로매니지를 하지 않는다.


3. 팀원의 성공에 관심을 표명하며 개인적 삶에도 관심을 기울인다.


4. 생산적이며 결과를 중심으로 사고한다.


5. 훌륭한 커뮤니케이션 능력을 가지고 있다.


6. 팀원들이 경력을 키워나가도록 도움을 준다.


7. 팀을 위한 명확한 비전을 가지고 있다.


8. 팀에게 조언을 해주기에 충분한 기술적인 능력을 갖추고 있다.


좋은 코치는 스스로 뛰는 사람이 아니라, 선수가 원하는 포지션에서 마음껏 뛰게 해주는 사람이다. 기술 관리자(technical manager) 중에는 자신의 기술적 역량과 판단을 팀원의 것보다 우위에 놓고 시시콜콜하게 명령을 내리는 사람이 있다. 이런 태도는 다음 항목인 마이크로매니지와 연결된다. 팀원이 아니라 자신의 기술력에 의존하기 때문에 팀원을 스스로 생각하는 창의적인 개발자가 아니라 자신의 명령을 오차없이 수행하는 병사로 취급한다. 이런 관리자 아래에서 일하는 개발자가 건강한 동기부여를 가질 리 없다.


■ 진정한 개발자 세계에서 관리자는 '상관'이 아니다

사소한 부분을 일일이 간섭하고 통제하는 마이크로매니지는 관리자의 그릇과 연결된 문제다. 넷플릭스는 이걸 “통제(control)가 아니라 문맥(context)"이라고 표현했다. 좋은 관리자는 팀원을 통제하는 것이 아니라 팀원에게 필요한 일의 전후맥락을 설명한 후, 믿고 맡긴다. 사소한 통제에 집착하는 관리자는 문맥을 제시할 능력이 없기 때문에 그렇게 하는 것이며, 따라서 관리자로서의 역량이 부족한 것이다. 관리자의 마이크로매니지는 개발자의 생산성을 저해하는 치명적인 독이다.

팀원의 개인적 삶에 관심을 갖는 것은 관리자 자신의 취향과 스타일에 달려있는 문제다. 하지만 팀원의 성공에 관심을 갖는 것은 좋은 관리자가 갖춰야 하는 필수 덕목이다. 최근에 나는 회사에서 자신의 팀원과 '경쟁'하는 관리자를 발견하고 전후맥락을 살핀 다음 인사조치를 단행한 경험이 있다. 자기가 가진 권력적 우위를 이용해서 팀원의 아이디어를 자신의 아이디어로 둔갑시키는 관리자를 발견한 것이다. 이건 관리자가 가질 수 있는 모습 중에서 최악이다. 좋은 관리자는 팀원을 이용해서 자기를 돋보이게 만드는 것이 아니라 진심으로 팀원의 성공을 위해서 봉사해야 한다.

결과를 중심으로 사고하는 것도 반드시 필요하다. 개인적인 호불호, 지연이나 학연, 아부, 허황된 장담, 소문, 감정에 휘둘리는 관리자는 관리자로서의 자격이 없다. 누가 좋은 품질의 코드를 생산하는가, 얼마나 빠르고 정확하게 일을 마치는가, 어려운 문제를 해결하기 위한 좋은 아이디어를 제안하는가, 다른 사람과 잘 협업하는가, 스스로 할 일을 찾아서 적극적으로 행동하는가, 의사소통을 잘 해서 자기가 하는 일을 투명하게 만드는가. 이런 구체적인 결과만으로 판단을 해야한다. 출퇴근 시간, 휴가, 재택근무, 병가 같은 근태 역시 결과 중심의 사고에 영향을 주지 않아야 옳다.

관리자가 좋은 커뮤니케이션 능력을 가져야 한다는 것은 상식이다. 다만 여기에서 말하는 커뮤니케이션은 말을 뉴스앵커처럼 또박또박 유려하게 하라는 뜻이 아니다. 투명하고 솔직해야 한다는 뜻이다. 공감(empathy)하고 공명(resonance)해야 한다는 뜻이다. 아무리 역량이 뛰어나고 성실한 관리자라고 해도 타인의 이야기에 공감할 줄 모르면 팀원에게 고통을 준다. 공감. 8개의 항목 중에서 이게 제일 중요하다. 팀원의 입장과 처지를 자기 것처럼 이해하고, 고민하고, 아파하고, 억울해하고, 분노하고, 노력하고, 기뻐하는 것. 관리자가 가져야 하는 덕목 중에서 제일 중요한 것은 공감능력이다. 이게 핵심이며 여기에 비하면 다른 능력은 모두 부차적이다.

명확한 비전과 기술적 능력은 관리자 자신의 역량 문제다. 있으면 좋고, 없으면 아쉽지만 그렇다고 해서 관리자로서의 결정적인 결격사유는 아니다. 비전은 더 위에 있는 디렉터나 CTO에게 빌릴 수 있고, 기술적 능력이 부족하면 팀원들에게 빌릴 수 있기 때문이다(비전을 남에게 빌릴 수 없는 CTO나 임원급 간부는 면도날처럼 날카로운 비전을 스스로 가지고 있어야 한다. 이 주제는 나중에 다루겠다).

이상 구글 연구진의 발표내용을 중심으로 관리자의 자격을 살펴보았다. 불만을 품은 직원은 회사를 떠나는 것이 아니라 관리자를 떠난다는 말이 있다. 관리자의 역할이 그만큼 중요하다는 뜻이다. 진정한 개발자 세계에서 관리자는 '상관'이 아니다. 수행하는 일의 기능(function)이 서로 다를 뿐이다. 관리자는 개발자가 개발에 집중할 수 있도록 옆에서 봉사하는 사람이지 개발자를 상대로 명령하거나 독단적으로 판단하는 권력을 가진 사람이 아니다. 좋은 관리자는 이런 사실을 이미 잘 알고 있다. 행여 관리자라는 타이틀을 봉사가 아니라 권력으로 착각하는 사람이 있으면 이 글을 읽고 생각을 바꾸기 바란다. 관리자의 자격은 그 착각이 없는 사람으로 국한되기 때문이다.



원문보기: 

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170227091914



.

반응형

+ Recent posts