본문 바로가기

Programming!

로컬 RAG 에서 요금제 추천 결과.

요금제 Spec 데이터를 임베딩 해두고, 이제 유저에게 어떻게 요금제를 추천하지?를 고민하다가..

 

 처음에는 고객의 데이터 사용 패턴을 입력받고, 임베딩된 요금제 데이터에서 필터링한 정보와 함께 한번에 큰~~~프롬프트를 구성해 결과를 도출하는 방식으로 접근했다. 기본적인 뼈대는 정말 잘 작동했는데....

 

하지만 결과적으로 이 방식은 생각보다 훨씬 까다로웠다.

 

 특정 요금제에 맞춘 프롬프트를 정교하게 작성하면 그에 맞는 사용 패턴 입력에는 정확한 결과가 나왔지만, 사용 패턴이 조금만 달라져도 갑자기 전혀 관련 없는 요금제를 추천하는 문제가 발생했다.

 

또한, 프롬프트 내에 시간, 분, 초와 같은 단위들이 많이 포함되다 보니 어느 순간부터는 AI가 이러한 시간 단위들을 제대로 구분하지 못하는 현상도 나타났다.

 

프롬프트를 단순화하면 몇몇 요금제는 다시 잘 작동하기도 했지만, 결국 프롬프트와 사용자 질의의 정교함에 따라 결과가 너무 달라지는 문제가 있었다.

 

즉, 정확한 답을 내기위해 어설픈 큰 프롬프트 문구는 전혀 엉뚱한 대답을 하게하는 결과를 낸다.
그래서 프롬프트 관련 도서를 구입하기에 이르렀다. ㅎㅎ

그리고...
AI 모델에 모든 판단을 맡기는 것은 좋은 접근법이 아니라는 나름의 훌룡한 교훈을 얻었다. 흑. oTL.

 

 

여튼 조금 접근 방식을 완전히 바꿔서 접근해 보았다.

 

먼저 사용자 패턴을 분석해 한 달 동안 예상되는 데이터 사용량(GB)을 AI 모델에게 예측하게 하고, 이 용량을 기준으로 임베딩된 데이터의 메타데이터로 필터링한 후, 다시 AI 모델을 통과시키는 방식으로 전환했다.

 

놀랍게도 이 방식은 훨씬 좋은 결과를 보여주었다! 우오~

 

뭐 현재는 사용량 기준 하나만으로 테스트를 해봤지만, 앞으로 약정 기간, 남은 약정 기간, 기기 가격 등의 요소들을 추가한다면 더욱 세분화된 맞춤형 추천이 가능할 것 같다.

물론 이런 큰 작업은 실제 운영 환경에 적용하는 것을 전제로 진행해야 할 것 같다. 그리고, 작업을 하더라도 정말 정말 예상보다 많은 시간이 필요할 것 같다.

 

프롬프트의 영역은 인풋이 명확하더라도.. 아웃풋이 늘 같지는 않더라...코딩 보다 어려웠다. (응??? ㅋㅋㅋㅋㅋ)

 

 

결론 :

1. 임베딩 데이터를 잘 만들자! 특히 메타데이터를 잘 만들어 두면 아주 좋다.!!!

   필터링이 쉬워지고 결과적으로 유사도를 더욱 높게 줄 수 있게 된다.

2. 모든걸 AI 모델에게 넘겨서 답을 요구하지 말자!( 복잡한 결과를 한번에 얻어내려고 하지 않아도 된다. )

3. 결과적으로 AI 도 그냥 사람처럼 대하자. 슈퍼 천재 두기는 아직 아니다.