웹 내에서 구현할 챗봇의 특징은 생각보다 간단하다.
1. 실시간성을 지원하지 않아도 된다.
챗봇 서버는 클라이언트에서 요청이 들어오면 이에 대한 적절한 응답을 Model 서버에서 받고 다시 Client server로 넘겨주는 1대1대화가 될 것이다. 사용자의 요청이 들어오면 응답이 나가는 구조이므로 실시간성을 지원하지 않아도 된다.
2. 채팅 내역을 저장하자.
좀 더 사용자 친화적인 서비스를 기획하기 위해서 채팅 내역을 저장하기로 결정했다. DB는 MySQL을 사용한다. 다만 로그인된 계정에 한해서 대화 내역을 30일간 저장하는 것으로 기준을 잡았다. 기준의 근거는 명확하지 않다. 실제 서비스가 된다면 개선되야겠지...
로그인되지 않은 사용자도 챗봇을 사용할 수 있지만, 이 때, 채팅 내역은 저장되지 않는다.
3. api 명세는 다음과 같다.
>>> 유저 gusdnd852 : 모레 부산 날씨 어때
https://123.456.789.000:1234/request_chat/gusdnd852/모레 부산 날씨 어때
→ {
'input': [모레, 부산, 날씨, 어때],
'intent': 'weather',
'entity': [S-DATE, S-LOCATION, O, O]
'state': 'SUCCESS',
'answer': '부산의 날씨 정보를 전해드릴게요. 😉
모레 부산지역은 오전에는 섭씨 19도이며, 아마 하늘이 맑을 것 같아요. 오후에도 섭씨 26도이며, 아마 하늘이 맑을 것 같아요.'
}클라이언트가 입력한 말은 api에 실려 Model Server에 request 될 것이고 Model Server에서 다음과 같이 분석되어 다시 Application Server로 응답을 줄 것이다. 따라서 아래와 같은 정보를 MySQL 테이블에 저장할 것이다.
| chat_id(PK) | chat_id |
| origin | 모레 부산 날씨 어때 |
| user_key(FK) | user_key(gusdnd852) |
| input | 모레, 부산, 날씨, 어때 |
| intent | weather |
| entity | S-DATE, S-LOCATION, O, O |
| state | 0(success) |
| answer | 부산의 날씨 정보를 전해드릴게요. 😉 모레 부산지역은 오전에는 섭씨 19도이며, 아마 하늘이 맑을 것 같아요. 오후에도 섭씨 26도이며, 아마 하늘이 맑을 것 같아요.' |
| time | YYYY-MM-DD hh:mm:ss |
input, entity 데이터는 사용할 구석이 없으니 일단 역정규화한 형태로 남겨두자.
정리해 보자.
시스템 아키텍처와 프로세스는 다음과 같다.
댓글