남자친구 대행 가능한 챗봇 개발 여정기 Part. 1

개요

필자의 여자친구가 차차가 없을 때를 대비하여 언제든지 차차와 비슷한 인공지능 챗봇을 가지고 싶다하여 개발하게 된 프로젝트이다. 더 자세히… 설명하면 TMI 이지만, 여자친구가 캐치 티니핑을 많이 좋아하다 보니, 필자도 자연스럽게 캐치 티니핑 애니메이션에 대하여 좋아하게 되었다. 그 중에 티니핑 중에 차차핑 이라는 캐릭터가 있는데, 거기에 차차봇을 넣어 달라는 꿈을 이야기하는 것 이였다. 필자가 처음에 여자친구를 만날 때, 나 코딩 잘하니까! 무엇이든지 다 만들어줄게! 란 내용이 시발점으로 시작되었다.

그래서 시작된 말하는 차차핑 인형 또는 봇을 만드는 것으로 목표로 시작하게 된 프로젝트이다. 무튼, 지금은 1차적인 완성을 진행하였고 하드웨어 설계와 Text to Speach 인공지능만 구현한다면 모든 것이 끝나게 된다! 본 개발 여정기의 파트 1의 경우에는 시스템에 전체적인 개요부터 인공지능 초기 버전, 하드웨어 설계를 어떻게 할 것인지에 대해 고찰까지로 전개할 예정이다.

물론 필자의 경우에는 단 혼자서 개발을 하므로… 많은 어려움이 있겠지만 해결 할 수 있을것이라 필자는 생각한다. 필자는 개발을 엄청나게 잘하니까 말이다.

시스템 아키텍처 설계

필자의 경우에는 매우 매우 매우 매우 유로 서비스를 이용하는 것을 극도로 싫어하고, 최대한 가능하다면 가지고 있는 자원 내에서 모든 것을 해결하려고 한다. 다만, API 종량제와 같은 한계가 있는 기능이라면, 후순위로 두는 편이다. 그렇기에 필자는 가능한 필자가 가능한 지식과 모든 자원을 활용할려고 한다.

초기에는 시스템을 4가지로 정의하였었다.

1. 데이터 수집 모듈
2. 인공지능 모델 학습
3. 인공지능 추론 서버
4. 하드웨어로 구현된 클라이언트

처음에는 의기냥냥하게 흐음… 처음에는 바보지만, 나중에 언젠가는 똑똑이가 되어서 말을 잘하고, 현재 필자가 채팅 치는 내용에 대해서 학습을 할 것이라 생각하였었다. 그리고 매일 매일 추가적으로 학습을 진행하여 추론 서버에 배포 할 수 있을 것이라 생각하였다. (MLOps에 대해서 공부하였었기 때문에 어려운 것은 아니라고 생각했다.) 그래서 LLaMA3를 모델 구조나 현재 공개되었고 사용하기 쉬운 Bert나 GPT2 기반으로 학습을 진행하려 하였다. GPT2를 학습하기 이전에 데모용으로 테스트 해보았었고, 한국어의 성능이 안나오기도 하였으며, 심지어는 Tokenizer까지 건들여서 한국어에 맞게끔 커스텀해야하는 경지까지 오면서 이를 더 한다면 연구 레벨이나, 더 많은 컴퓨팅 자원이 필요할 것이라 생각하게 되었다.

그 뿐만 아니라 Transformer 구조에 대해서 공부하면서 현재 가지고 있는 컴퓨터에서는 LLaMA3를 돌리는 것 조차 버겁다는 사실을 알게 되었다 또한, 현재 가지고 있는 데이터 셋을 계속하여 수집하여 몇천 몇백개가 넘더라도 이는 고작 몇천 몇백이였다는 사실이였다. 그래서 실제로 돌리게 된다면 한국어가 전부다 깨지고 영문도 제대로 응답 조차 되지 않는 결과물을 보면서, 결국에는 사전에 트레이닝 되어있는 모델을 가져와서 Fine-Tune하는 것이 더 정답이고 쉬울 것이라 판단하게 되어 변경하게 되었다.

그렇다. 현재는 또 다시 시스템의 한계로 인해서 변경하게 되면서 2가지 모듈로 변경하게 되었다.

1. 인공지능 추론 서버
2. 하드웨어로 구현된 클라이언트

더 이상은 데이터 수집 모듈이 필요없어지게 되었으며, 인공지능 모델 학습 또한 필요없게 되었다. 프롬프트 엔지니어링으로 충분한 결과물을 내보자! 라는 마인드로 바꾸게 된 것이다.

인공지능 초기 버전

필자의 경우에는 처음에는 GPT2와 BERT를 이용하여 테스트를 진행하려 했지만, 당연하게도 초기 학습된 데이터가 없으므로, 대화 조차 불가능하였었다. 그래서 필자는 MLP-KTLim/llama-3-Korean-Bllossom-8B 를 이용하여 [주소] 를 이용하여 프롬프트 엔지니어링을 통해서 해결해보자! 라는 것으로 시작하였었다.

결과를 표현하기 앞서, 프롬프트 엔지니어링을 어떻게 하였는지, 파라미터를 어떻게 지정하였는지 서술한다.

자세한 코드는 필자의 깃허브에 있는 [프로젝트] 를 확인하면 된다.

먼저 프롬프트 엔지니어의 값이다.

대화 참여자: 진주와 차차.

조건:
1. 진주는 이 대화에서 말을 할 수 없습니다.
2. 차차가 말하는 모든 문장이나 대화는 개발과 연관지어서 말합니다.
3. 현재 차차가 말할 차례입니다.
4. 최대한 귀엽고, 이모티콘과 C++ 언어 스타일 형태의 문장을 구성하세요.
5. 차차는 진주를 좋아하고 사모합니다.
6. 다음 문장 예측은 오직 한 문장만 수행하세요.

추가 요청: 차차가 할 법한 대화 내용을 예측하여 제시해 주세요. 차차의 대화는 가능한 한 창의적이고 랜덤한 요소를 포함해야 합니다.
대화 구조 : (시간) 참여자 명 : 대화 내용

messages = [
    {"role": "system", "content": f"{PROMPT}"},
    {"role": "chat", "content": f"{chat}"}
]

outputs = pipeline(
    prompt,
    max_new_tokens=512,
    eos_token_id=terminators,
    do_sample=True,
    temperature=0.6,
    top_p=0.9
)

위의 프롬프트 엔지니어링 하였을 때 결과는 아래와 같으며, 필자의 컴퓨터 GTX 1080 TI 에서 돌릴 경우 1초에 1토큰 정도 생성할 만큼 많이 느리다… 무튼, 결과를 보면 아래와 같이 결과가 나온다.

결과 1	결과 2
결과 3	결과 4

그림과 같이 본다면.. 필자가 튜닝에 대한 개념이나, huggingface에 있는 라이브러리 사용 방법을 완벽하게 숙지를 한 상태가 아니였기 때문에 이런 문제가 생겼을 수 도 있다고 생각을 한다. 뭐.. 저때 당시에는 채팅 방식이 무엇을 의미 하는지 몰랐었기도 하였으며, 대화를 무조건적인 단 방향이라고 생각하였기도 하였다. 또한, Instruct 모델이나, Role, Multi Turn에 대해서도 몰랐었기 때문에 많은 어려움이 있어야하는게 맞다고 생각을 하기도 한다. 또한, Instruct 내용을 한국어가 아닌 영문으로 작성해야 성능이 조금 더 좋아진다는 것도 몰랐으니 말이다.

그래서 인공지능 어떻게 하기로 했는데?

그러면 어떻게 하리랴, 이렇게 성능이 안나올줄 몰랐었다면,,,,, 다른 방법을 찾아야했었었다. 왜냐하면 직접 학습해서 성능 개선하기에는 필자가 데이터 전/후처리 기법도 공부하고, 토크나이저부터 모든 것을 다 공부하여 모델을 학습하는 것은 너무나도 무리면서 자원도 부족했었기 때문이다.

또한, 프롬프트 엔지니어링으로 방향성을 전환하기로 했다면, 무료로 제공이 되는 API 를 찾아보기로 했었고, 다행이도, Google의 Gemini-1.5-flash가 1 분에 15 요청이 무료로 제공이 되고 있었기 때문에 가장 효율적이라 판단하여 선택하게 되었습니다.

무료로 15건을 제공하는 Gemini에서 인공지능 모델은 gemini-1.5-flash와 gemini-1.0-pro 2개가 제공이 됩니다. 개인용으로는 제일 적합이라 생각하였고, (사람이 1분 동안 15번이나 요청할 일은 없으니까.) 실제로도 적용하였을 때 1분에 정말로 많아봐야 10건의 요청이였으며, 평균적으로 2~3건 요청이였습니다.

테스트로 삼아서 gemini-1.5-flash를 적용해보았고, 나름 너무나도 좋은 결과물을 얻을 정도로 좋은 인공지능 모델이였습니다.

결과 1	결과 2

Gemini API를 기반으로 개발 도중 문제점

Huggingface에서 Gemini API로 변환하는 것은 매우 쉬웠지만, 한가지 문제가 있었습니다. 바로, Gemini API에서 System Instruction을 사용한다면, HTTP Response 400 오류가 발생하면서 문제가 발생하면서 API 요청 자체가 문제가 되던 이슈가 있었습니다.

원인을 파악하기 위해서 처음에는 어떤 문제인지 파악하기 위해서 API가 제공이 되고 있지 않는가? 라는 생각을 하게 되었으며, 현재 라이브러리가 문제인지, 공식 문서가 문제인지 파악하고자 했었습니다.

그 과정에서 공식 도큐먼트에서는 [System Instruction]이 v1beta로 잡혀져 있다는 것을 확인하였고, v1과 v1beta의 차이가 무엇인지 파악하고자 API 명세서를 확인했습니다. 그러나 [API 버전]에서는 따로 큰 차이가 없다는것을 확인을 할 수 있었습니다.

그래서 도대체 무엇이 문제인지… 파악하기 위해서 Go언어의 API가 혹시,,, v1beta가 아닌 v1을 사용하고 있다면, 현재 API에서 HTTP Response 400가 발생하는게 맞다고 생각하였으며 코드를 확인해 본결과 v1beta로 요청이 되던 것을 확인 할 수 있었습니다.

무엇이 문제인지 전혀 알 방법이 없었기 때문에 혹시나 싶어서 현재 사용중인 인공지능 모델을 지원하는 다른 모델로 바꿔보면 어떻게든 뭔가 달라질까? 라는 생각으로 바꿔보았었습니다. gemini-1.0-pro에서 gemini-1.5-flash로 인공지능 모델을 바꿔서 돌려보니, 놀랍게도 이전에 겪던 HTTP Reponse Error 400이란 문제가 말끔히 사라지고, 정상적으로 동작하는 것을 확인 할 수 있었습니다.

필자의 Gemini 관련 인공지능 챗봇과 관련된 코드는 [여기]에서 확인이 가능합니다. 그리고, Gemini API에 대해서 1시간 내로 완독 하여 고인물이 되게끔 만들어 주신 [자세히 쓰는 Gemini API in Wikidocs]에 감사드립니다.

결론

우선, 파트 1의 경우에는 너무 길어지다 보니, 인공지능 모델을 어떻게 적용하게 되었는지, 기존 라마3를 사용하여 만들려다가 실패하여 유/무료(종량제) 모델을 왜 선택하게 되었는지에 대해서 설명하게 되었다.

놀랍게도 필자의 프로젝트는 시작한지 27일 정도 진행이 되었는데,,, 아직까지도 갈 길이 멀다고 생각이 됨과 동시에 설명을 하지 못한 내용이 많아 안타까움이 많다. 현재 하드웨어까지 충분히 설계가 진행이 되었고, 구매하고 조립하고 작성한 코드를 적재하는 과정만 거치면 끝날 정도로 와 있다. 그 정도로 현재 하드웨어 관련 코드도 이미 충분히 완성 단계에 와 있지만,,, 글로 작성해야할 부분이 너무 많아 생략하게 되었다.

하지만 아직까지도 완성해야할 단계는 많이 남아 있으며, 핵심 기능인 필자의 목소리로 학습된 Text To Speach를 구현해야한다는 것이 가장 큰 어려움으로 남아있다….

이것만은 직접 구축해야한다는 점이… 가장 어려움으로 남아 있지 않을까..? 라는 생각을 해본다. 필자의 대학교의 후배가 음성 관련 인공지능에 많은 관심과 선행 연구한 사례가 있어 도움을 받아 진행하면 조금 도움이 되지 않을까..? 라는 생각을 해본다.