Chanhee Lee

게임 세계관 위키 LLM 챗봇 프로젝트

진행 기간: 2024.09 ~ (진행 중)

프로젝트 소개

게임 세계관을 담은 사내 위키의 내용에 대해 질문했을 때 답변할 수 있는 챗봇 만들기

문제 상황

• 게임 개발 시, 초반에 정한 컨셉과 스토리를 기반으로 게임 스킬, 인게임 이벤트 구성, 아트 등 많은 요소들이 결정되므로, 초반부터 기존 설정과 충돌나지 않도록 설정하는 것이 중요.
• 이를 해결하기 위해 게임 세계관을 기록한 위키를 만들었으나, 내용이 점점 방대해지면서 원하는 부분을 빠르게 찾기가 어려워졌음.

프로젝트 목표

• 사내 구성원들이 게임 세계관에 대해 더 편하게 접근할 수 있도록 간단하고 직관적인 UX로 정보 제공하기.
• 이미 별도 프로젝트로 기존 챗봇이 구현된 상태였고, 이를 최대한 빠른 시일 내에 개선하는 작업이 필요함.
• 이번 프로젝트 완성 이후, 빠른 개선을 위해 모델 평가(evaluation) 과정을 도입. 효율적인 평가를 위해 모델의 정보를 기록하는 과정이 필요.

해결 과정

• LLM 파이프라인 구성:
  • 기존 코드는 커스텀 함수들을 Databricks 환경 내에서 DAG 형태로 실행하도록 구현돼 있었음. 이는 코드 구조를 복잡하게 만듬.
  • langchain API를 사용해 시스템 프롬프트, LLM 모델, 벡터 데이터베이스를 연결하는 과정을 적절히 추상화하고, 최대한 일관성 있도록 구현.
• LLM 모델/임베딩 모델/벡터 데이터베이스 교체:
  • 성능 향상을 위해 오픈 소스에서 변경.
• Chat UI 개발:
  • 기존에는 web app 형태로 구현되어 있었음. 하지만 새로운 쓰레드를 구성할 때마다 불편한 점이 있었고,
  • 사내 구성원들이 가장 편하게 접근할 수 있는 slack 챗봇으로 변경.
  • 코드 구조가 더 단순해지고 권한 관리가 더 편해지는 등 개발 측면에서의 이점도 얻을 수 있었음.
• LLM Observability 확보 (tracing):
  • 입력된 질문으로부터 답변과 그 출처가 나오기까지 graph 형태의 파이프라인을 통과하기 때문에 각 단계 별 정보를 기록하는 과정이 필요.
  • 각 단계 별로 성능을 확인하거나 디버깅을 더 효율적으로 할 수 있게 됨.
  • 이를 위한 도구는 langsmith, datadog, helicone 등의 선택지가 있으나, 파이프라인을 langchain을 통해 구현했기 때문에 observability 역시 빠르게 구현하기 위해 같은 생태계 내의 langsmith 를 선택.
• 모델 평가(evaluation) 프로세스 설정:
  • 위키 관리자와 함께 모델의 성능을 평가할 수 있는 ground truth 데이터셋을 준비했음.
  • 이 데이터셋 기반으로 offline 방식의 모델 평가 파이프라인 구축.
  • 모델의 정보를 하드코딩하지 않고 langchain 객체로부터 추출해서 일관적으로 기록될 수 있도록 구현.
  • 특히 retrieval 단계에서 모델이 찾아낸 출처가 실제로 정답인지 정량적으로 평가하는 기능을 우선적으로 구현.

기술 스택

• langchain: 질문에서 답변까지 연결하는 pipeline을 일관성 있게 구현.
• OpenAI: chat completion / 임베딩 모델
• OpenSearch: 벡터 서치 엔진
• langsmith: LLM observability 확보.
• mlflow: 모델 성능 평가(evaluation)

프로젝트 내 주요 역할

모델 성능 평가(evaluation) 프로세스 설정

우선, 평가 대상을 명확하게 하는 것이 필요했습니다. 아직 개발 초기 단계이기 때문에, 복잡한 평가 과정을 거치기보다는 빠르고 간단한 평가 프로세스를 설정하고자 했습니다. 평가 대상은 크게 모델, 데이터 두 가지 측면에서 바라볼 수 있습니다.

첫 번째로 모델 측면입니다. 모델을 변경할 때마다 성능을 평가할 필요가 있습니다. 모델의 어떤 부분이 바뀔 수 있는지 미리 모델 파라미터로 정의하고 그에 맞게 평가 기록을 남길 필요가 있습니다. 이 과정에서 설정한 모델 파라미터는 다음과 같습니다.

• 모델 graph 구조
• LLM 노드에서 사용하는 시스템 프롬프트들
• chat completion 모델 종류 (ex. gpt-4o, gpt-4o-mini)
• 임베딩 모델 종류 (ex. text-embedding-3-large)
• 벡터 데이터베이스 종류 (ex. OpenSearch)
• 벡터 인덱스 버전
• 벡터 서치 쿼리

두 번째로 데이터 측면입니다. 어떤 질문에 대해 답변을 잘 했는지 평가하는 것이 중요합니다. 실제 서비스 과정의 질문/답변을 활용할 수 있다면 좋겠지만, RLHF를 비롯한 테스트 과정을 고안하기에는 유저의 질문과 답변의 패턴을 예상하기 쉽지 않았습니다. 그래서 offline 방식으로 고정된 데이터셋을 만들어 별도로 평가하는 쪽으로 결정했습니다. 이를 위해 위키 관리자와 함께 모델의 성능을 평가할 수 있는 ground truth 데이터셋을 준비했습니다. 초반 테스트 단계에서 챗봇이 잘 답변하지 못했던 질문들을 추려서, 각 질문에 대한 모법 답안과 출처를 기록했습니다.

RAG retriever 평가 구현

평가 프로세스를 어느 정도 고정한 후에는 실제로 모델을 평가할 수 있는 코드를 구현할 차례였습니다. 출력은 크게 RAG retriever와 최종 답변 두 가지로 나누어 생각할 수 있습니다. 이 중에서 먼저 RAG retriever 평가에 집중했습니다. 이유는 두 가지입니다.

• 상대적으로 더 쉽게 정량적인 평가가 가능함.
• 최종 답변의 퀄리티에도 영향을 미치기 때문에, retriever 평가를 먼저 하는 것이 더 효율적임.

Retriever 평가를 위해 information retrieval 지표의 종류를 공부하고 다음과 같은 지표들을 측정했습니다.

• precision@k
• recall@k
• nDCG@k: retriever가 찾아낸 출처들을 중요도 순으로 출력하는 것이 바람직하기 때문에 측정 지표에 포함했으나, 문서의 랭크 정보가 아직 불확실해서 최종 적용은 하지 않음.