들어가며
안녕하세요! 저는 데이터를 파악하고, 파악한 데이터를 AI 서비스에 녹여들 수 있도록 만들고, 최종적으로 AI 서비스가 돌아갈 수 있게 하는 일을 하고 있습니다. 흔히 데이터 사이언티스트라고도 하지만, 저는 데이터 분석가라는 말을 더 좋아합니다 :)
그래서 이번 주제는 LLM 기반의 ‘서비스’를 하기 위해서 데이터를 어떻게 만들 수 있을까하고 고민했을 때 제가 생각해본 아이디어를 소개하고, 아이디어 기반으로 간단하게 만들어본 서비스 데모를 소개하는 것입니다. 다소 긴 글이 될 수 있을 것 같지만, 그래도 고민한 내용을 차근 차근 공유해보겠습니다! 이 글이 정답인 건 아닙니다! ‘이렇게도 해봤구나~’하고 읽어주시면 될 것 같아요😊
🧐 제가 생각하는 ‘서비스’의 가장 중요한 점은 “쉽고, 간편해야 함”입니다.
여러분은 ChatGPT를 처음 접했을 때 어떤 생각이 드셨나요?
저는 처음에는 ‘간단하게 질문했는데도 답을 잘 해주네?’라고 생각했고, 쓰다보니 ‘생각보다 답변 퀄리티가 별로네?’라는 생각이 들었고, “프롬프트 엔지니어링”이라는 개념을 익히고 나서 부터는 “답변 하나 얻는 데 이렇게나 다 떠먹여줘야 한다고?!” 라는 생각이 들었습니다.
RAG 기술로 DB에서 자연어로 쿼리문을 만들어 데이터를 불러온다고 생각해봅시다. 많은 기업의 데이터는 대부분 숫자, 즉 정형화 되어 있습니다. 저는 최근에 보험사에서 프로젝트를 진행했었는데, 고객이 보장분석을 하게 되면 아래와 같은 데이터가 쌓이게 됩니다.
일반사망보험금 1억
재해사망보험금 3억
일반암진단보험금 5천만원
….
그럼 이 데이터를 기반으로 “일반사망 보장금액이 부족한 사람은 몇 명인지 알려줘” 라고 질의를 한다고 가정해볼게요. ‘부족’의 기준을 명확히 언급하지 않았기 때문에, 생각했던 답이 나올 수도 있고, 안 나올 수도 있을 겁니다. 그래서 실제로는 “일반사망 보장금액이 3억보다 적은 사람은 몇 명인지 알려줘” 라고 질문하는 게 더 나을 수 있겠죠.
하지만 이 서비스의 사용자는 RAG를 잘 아는 사람이 아니고, 보험설계사일 가능성이 높습니다. 초보 보험설계사라면, ‘부족’의 기준이 어느정도인지 모를 가능성이 높고, 숙련된 보험설계사라면 이쯤이면 ‘부족하다’라는 기준이 마음 속으로 있을 겁니다. 그러니 두 케이스에 속한 설계사 모두 정확한 기준(3억보다 적은)을 언급하기 보다는, ‘부족한 사람’을 쳤을 때도 정확한 결과가 나오는 걸 원하지 않을까? 싶었습니다.
요약하자면, 굳이 정확하게 입력하지 않아도(프롬프트 엔지니어링 하지 않아도) 알아서 답을 내주길 원한다는 것이 포인트인 거죠!
💡 그렇다면 정형데이터를 설명하는 데이터를 만들면 어떨까요?
예를 들어 #일반사망보험금부족 이라는 해시태그를 달아둔다거나, “일반사망보험금이 부족한 고객입니다” 라는 식으로 줄글을 써둔다거나, 데이터를 설명하는 텍스트 데이터를 만드는 거죠!
그리고 나서, 벡터 유사도 기반이든, 키워드 기준의 검색을 한다면, “일반사망 보장금액이 부족한 사람”이라는 질문에 조금 더 일관되고, 정확한 답변을 얻을 수 있지 않을까? 하고 생각해본게 제 아이디어의 러프한 버전입니다 ㅎㅎ
그래서 아이디어를 조금 더 구체적인 프로세스로 만들어본다면,
비즈니스로직 정의(ex. 보험금 규모에 대한 로직(충분/보통/부족))
정형데이터에 로직을 태워 정형데이터를 설명하는 텍스트데이터 구축
LLM 서비스에 활용
🤖 이 아이디어로, 내가 원하는 대로 보험 가입 플랜을 만들어주는 서비스를 만들어 봤어요!
보험약관이 엄청 어려운 건, 다들 아실겁니다 ㅎㅎ 거기다, 보험 하나 가입하려면 엄청 특약 조합을 다 따져야 하고, 가입금액도 가능한 범위가 있고, 보장기간도 특정 범위 내에서 선택해야 하고.. 참 복잡한 세계입니 다. 그래서 지금은 데모단계여서, 보완해야 할 점이 한 두가지가 아닙니다 ㅎㅎ..
개발 프로세스는 아래와 같습니다!
STEP 1. 기존 상품 가입 이력 데이터에 설명하는 데이터 구축
상품 가입 이력도 보장분석데이터 처럼 어떤 특약을 들었는지, 특약 별 가입금액은 얼마고, 보장 기간, 납입기간은 얼마고, 보험료는 얼마인지 전부 숫자 데이터로 적혀있어요. 그래서 상품 가입 이력을 설명하는 데이터를 붙여주는 작업을 진행했습니다😃
예를 들면, 어떤 보장 위주로 설계 되었는지 로직을 짜서 적용을 시켜줬어요. ex #암진단위주의가입설계
STEP 2. 프롬프트 엔지니어링
설명하는 데이터의 레벨과 요청문의 레벨을 맞추는 작업
목표로 하는 설계안을 만들기 위해 필요 한 구체적인 정보를 얻어내는 작업
설계안을 설명하는 글을 생성하기 위한 프롬프트
STEP 3. 서비스 로직 개발
목표로 하는 설계안을 만들기 위해 수정이 들어가야 하기 때문에, 그 부분은 로직을 따로 개발했습니다 (데모에서는, 요구사항과 유사한 이력 검색, 보험구성 수정, 가입금액 수정 부분이 가능합니다!)
STEP 4. Streamlit 기반으로 데모 개발
기본적으로 streamlit의 chat_message 기반으로 구현했고, llm 활용 시 응답 시간 때문에 spinner(빙글빙글 돌아가는 로딩 UI)도 같이 사용해줬어요!
# spinner 사용 예시
with st.spinner('요구사항에 맞는 설계안을 만드는 중이에요! 잠시만 기다려주세요!'):
#### STEP 2-1. 파악한 내용 기반 설계안 가져오기 #####
### 방안) 키워드 포함여부 개수로 가져오기
available = demo.retrieve_plan(meta_history = st.session_state.meta_history,
plan_history = st.session_state.plan_history
)
response = "요청하신 내용에 딱 맞는 가입설계안을 만들어봤어요!<br/>"
#### STEP 2-2. 가입설계 조정해서 가져오기 ####
if not available : # 딱 맞는 플랜이 없을 경우
print(f'##### INFO 딱 맞는 플랜이 없어 유사한 플랜을 찾았습니다.')
print(f'##### INFO 보완해야할 키워드는 다음과 같습니다. :\n[요청정보]\n{'\n'.join(['- ' + i for i in demo.base_plan['NewNeed_INS'].values[0]])}')
print(f'\n[상품정보]\n{'\n'.join(['- ' + i for i in demo.base_plan['NewNeed_PLAN'].values[0]])}')
demo.modify_plan(meta_history=st.session_state.meta_history)
## 키워드에 따른 로직, 변수 설정이 무엇인지 확인
## 로직수행 후 result_plan 설정
...💡 인사이트 공유
모든 AI의 시작은 데이터입니다!
저는 이번에 RAG에서 R 부분을 유사도 기반으로 찾지 않고 쿼리 기반으로 명확하게 가져올 수 있게 진행했는데, 유사도 기반의 검색을 하는 RAG의 경우 데이터 구축이 정말 정말 정말 x 1000000 중요합니다. 그냥 단순히 만들어져있는 데이터 로더, 검색 툴로 RAG를 진행했을 때, 원하는 성능이 나오지 않으셨다면 “데이터가 컴퓨터가 이해하기에 적절한 형태로 되어 있는가?”를 고민해보세요!
그리고 데모를 만들면서도, 데이터가 안 맞아서 데이터 재수정 작업에 엄청 시간이 많이 들었답니다.. AI의 시작은 품질 높은 데이터라는 것, 여실히 느끼고 있습니다 ㅎㅎ..랭스미스를 꼭 써보세요!
랭체인의 경우, 체인이 엮였을 때 어떤 결과값이 전달됐는지 확인하는 작업이 생각보다 많이 중요한데, 랭스미스를 연동하시면 그 과정을 확인하실 수 있어요! 프롬프트가 적절했는지, 토큰이 어느정도 쓰였는지 전부 추적할 수 있어서 너무 좋았습니다.데이터 분석가라면 이해하는 고충, ‘분류체계 설계’ 도 이젠 LLM이?
데이터를 입맛대로 사용하기 위해서 보통 분류를 하곤 하는데, 실제로 프로젝트에 들어가게 되면 이 분류 체계를 만드는 데 시간이 상당히 오래 걸립니다. 이 분류체계를 굳이 직접 만들지 않고도, 활용하게 된다면 프로젝트에 소요되는 시간이 상당히 줄어들지 않을까 하는 기대를 해보고 있습니다 ㅎㅎ
🧐 회고
대화형 서비스는 결국 어떤 시나리오가 있을까를 고민하게 되는 것 같아요. 거의 모든 시나리오를 커버하는 서비스를 만들기 위해서는 그만큼 데이터를 잘 설계해야 겠다는 생각을 또 한 번 느끼게 되었습니다. 지금도 데이터는 완성되지 않았 기 때문에…
최근에 랭그래프라고, 에이전트를 연결해서 RAG의 한계점을 어느정도 극복할 수 있게 만들어주는 툴이 나왔는데, 아직 못 써봤다는 아쉬움… 여유가 된다면 공부해서 사례글로 남겨보고 싶네요 ^^
🔗참고 URL
Streamlit chat_message 활용법
https://docs.streamlit.io/develop/tutorials/llms/build-conversational-apps
#11기 랭체인