테오(TEO) 개발 일지. 생성형 AI 커스텀하기

*이 콘텐츠는 LLM을 활용한 상용 프로덕션 제작 중 겪은 어려움들을 풀어서 쓴 글입니다. 기술 관점보다는 에피소드 위주로 기술했습니다.

TEO 소개

TEO는 스펙터의 데이터를 활용해 사람을 예측하는 기술의 첫 상용화 버전입니다.

스펙터의 데이터는 사람의 “일하는 자아”를 다각도/심층적으로 설명하는 72만여 개의 원천 데이터를 기반으로, 통계 분석 데이터와 행동주의 심리학/ 인적자본 경영론의 최신 연구 결과들을 참고한 라벨링 데이터로 이루어져요.

데이터와 기술의 제품화를 결정하면서 첫 타겟 시장을 스펙터의 고향과도 같은 ‘HR' 도메인, 그중에서도 ‘채용’으로 정했습니다. 드디어 본격적으로 TEO가 태어날 준비를 마친 것이었어요.

EP 1. LLM 커스텀하기
TEO의 똑똑함은 어디에서 오는가.

어떤 LLM (Large Language Model : 대표적으로 Chat GPT가 있습니다.)을 쓸지 결정하기 전에, 어떤 방식으로 활용할지 열띤 논의를 했습니다. 스펙터의 데이터를 모두 학습시킬지(파인 튜닝), 대화 시 필요한 데이터셋을 추가로 검색시킬지 (RAG, Retrieval-Augmented Generation:검색증강생성)에 대한 논의가 이루어졌어요.

빠르게 프롬프트 최적화로 결론이 났는데요. 이유는 2가지입니다.

• 학습보다 양질의 데이터

• 데이터 통제의 난이도

학습보다 양질의 데이터

TEO의 답변 정확도는 학습보다 주어지는 데이터의 질과 양에 더 크게 좌우됐습니다.

파인 튜닝을 위해 투입하는 시간과 비용 대비, 결과물의 질이 크게 차이 나지 않는 것은 물론, 학습 데이터의 비중과 빈도(Epoch)를 세밀하게 조절하지 못했을 때 과대적합(Overfitting) 등의 이슈로 오히려 답변 퀄리티가 낮아질 위험마저 있었습니다.

따라서 데이터를 다각화하는 분석 테크닉과, 그 결과물인 데이터를 저장하고 필요한 데이터만 신속하게 통신시킬 수 있는 데이터 파이프라인 구축에 더욱 신경을 썼습니다.

이제 테오는 대화가 발생할 때마다 관련성이 높은 새롭고 제한된 데이터셋을 제공받고, 이에 따라 정확한 답변을 안정적으로 제공할 수 있게 됩니다.

데이터 통제의 난이도

TEO에게는 중요한 원칙이 있습니다.

첫 번째, ‘A’에 관해 물어봤는데 ‘B’에 대한 답을 절대로 하면 안 됩니다. 많은 AI는 “알고 있는 정보를 말하지 마!” 같은 명령에 취약한 편이에요. 그러니 답변에 활용해서는 안 되는 정보가 있다면, 애초에 제공하지 않는 쪽이 안전합니다.

두 번째, ‘A’에 관해 물어봤는데 정보가 없다고 해서 지어내서 아는 척을 하면 절대로 안 됩니다. 많은 생성형 AI 모델의 고질적인 문제로 환각(Hallucination) 현상이 있습니다. 답변에 필요한 정보가 없는 질문을 받은 AI가 환각, 즉 부적절하거나 거짓인 답변을 지어내는 것인데요. TEO는 없는 정보를 절대로 아는 척하면 안 된다는 원칙을 적용합니다.

이 2가지 문제를 해결하기 위해 TEO에게 제공하는 데이터와 답변을 확실하게 제어하는 방식으로 프롬프트를 튜닝 전략을 짜기 시작했습니다.

EP 2. 프롬프트 고도화하기
큰일 났다. TEO가 너무 비싸다.

셀 수 없는 테스트와, 수정과, 우여곡절과, 통곡을 거쳐, 드디어 목표하는 안전성과 정확도에 도달하는 TEO 프롬프트 구성이 끝났습니다. 이제 테스트 서버에 배포하고 기능 관련 오류가 없는지 QA를 진행했습니다.

TEO의 예상 고객층 페르소나와 일치하는 내부 구성원들이 대거 참여했고, 일시적으로 TEO 사용량이 급증했습니다. 그리고 그날 저녁, 저희는 어마무시하게 추가 과금된 비용 그래프를 확인하게 됩니다.

1. 사전에 예상 비용 산정 안 했나?

당연히 했습니다. 이번에 활용하기로 한 모델은 gpt-4o 입니다. 최신성, 속도, 맥락 이해력, 답변 내용과 형태의 만족도, LLM에서는 아직 소수 언어인 한글 이해력을 고려한 선택이었는데요. 문제는 공급사 홈페이지에 공개 비용 산정 기준이 모호하다는 것이었습니다. (검색해 보니 해외 포럼에서도 자주 제기되는 이슈였습니다. 사전 체크하지 못한 부분이 정말 아쉽네요.)

2. 예상 비용과 얼마나 차이 났나?

딱 100배 차이 났습니다. 하하하 (실성) 😅😱

3. 원인은 파악했나?

네, 분명히 파악했습니다.

사전에 산정한 대화 당 예상 비용은 최초 1회 문답에서의 데이터 입력 비용 + 2회 차부터 질문과 답변할 때마다 딱 그 글자 수(토큰) 만큼의 비용이 추가 발생하는 구조로 이해하고 산정한 액수였습니다.

문제는 2회차 이후 발생하는 질문과 답변은 단건으로 계산되는 것이 아니라 누적되어 계산된다는 거였죠. 무슨 말이냐면, 저희가 최초 이해했던 요금 산정 방식은 아래와 같습니다.

최초 이해한 요금 산정 방식

Ca= A1 + R1 + A2 + R2 + A3 + R3 + …. (An + Rn)

*A: 질문 글자 수에 따른 비용
*R: 답변 글자 수에 따른 비용
*A1이 최초 데이터셋을 가지고 있기 때문에 평균 단건 글자 수 대비 약 50배의 크기를 가짐

하지만 실제로는 이랬죠.

실제 산정 방식

Cr=A1 + (A1+R1) + (A1+R1+A2) + (A1+R1+A2+R2) + … (An+Rn+An-1+Rn-1+An-2+Rn-2…)

*A: 질문 글자 수에 따른 비용
*R: 답변 글자 수에 따른 비용
*A1이 최초 데이터셋을 가지고 있기 때문에 평균 단건 글자 수 대비 약 50배의 크기를 가짐

4. 어떻게 해결했나?

가장 유효한 방법은 프롬프트 문법을 수정하는 것이었습니다. 비용이 최초 1회가 아니라 후속 질문과 답변이 발생할 때마다 100% 추가되기 때문에, 프롬프트 자체의 볼륨을 줄였습니다. A1의 내용은 데이터와 세세한 답변 규칙으로 이루어져 있는데, XML문법을 전반적으로 도입해 재구성했고, 약 30% 절감의 효과가 있었습니다. (문법 특성상 정확도가 높아진 것은 덤입니다.)

이외에도 폭발적인 비용 증가를 방지하기 위한 안전장치로 1개의 대화방 전체 글자 수와, 문답 건당 글자 수에 상한을 설정했습니다.

최근에는 대체 혹은 병용할 sLLM (소형 언어 모델)을 탐색하고 성능을 테스트하고 있습니다. 대표적으로 최근 출시된 GTP 4o mini가 있는데, 비용 측면에서 현재 사용 중인 4o모델 대비 1/30 수준이라는 메리트가 있습니다. (다만 아쉽게도 같은 프롬프트를 적용했을 때 테오의 성능 차이가 심하게 느껴졌어요. 그래서 4o mini의 성능 차이를 상쇄할 수 있는 프롬프팅 전략이나, 다른 기술적인 아이디어를 고민하고 있습니다.)

마치며

사실 테스트나 내부 PoC, 그리고 평가 단계에서 크고 작은 많은 일들이 있었습니다.

그 중 처음 LLM을 활용할 때 마주할 수 있는 보편적인 문제 위주로 경험을 공유하면 좋을 것 같아 사례를 선정해 보았어요. 조금 더 세세한 이야기들은 추후 기회가 된다면 더 해보고 싶군요.

확실한 건, LLM은 21세기 들어 가장 획기적이고 혁신적인 기술 중 하나이지만, 특정 도메인이나 서비스에 적용했을 때 확연하게 차별성을 가지려면 양질의 데이터가 필요하다는 점입니다.

스펙터가 보유한 72만여 개의 양질의 데이터를 가지고 TEO가 해낼 많은 일들을 기대해 주세요.