데이터 이야기 #9: LLMOps 엔지니어

초거대 언어 모델(LLM: Large Language Model)을 사용하는 애플리케이션의 개발 및 배포 과정에서 발생하는 문제들은 ML 모델의 개발과 배포 과정에서 생기는 문제들과 마찬가지로 매우 다양하다. 처음 한 번은 LLM 기반 서비스를 만들하고 배포할 수 있지만, 그 후 LLM이 업그레이드되거나 새로운 LLM을 써보려고 한다면 어떤 최적화 및 검증 프로세스를 갖고 있느냐가 굉장히 중요해진다. 여기서 차별화된 경쟁력이 나오며, 이를 LLMOps 엔지니어가 담당하게 된다.

LLMOps는 LLM을 활용하는 다양한 서비스 개발과 운영에 필요한데 보통 RAG(Retrieval Augmented Genenration)라는 모양을 갖는 것이 현재로는 일반적이며 도메인과 관련된 지식을 벡터DB로 별도로 저장하고 이를 최종 프롬프트 생성에 사용하게 된다. 몇 가지 예를 들어보면 다음과 같다.

1. 대화형 AI 서비스: 챗봇 및 가상 비서 등등

2. 콘텐츠 생성 및 편집: 작문, 자동 번역, 뉴스 기사 생성 등등

3. 교육 및 학습: 개인화된 학습 보조 도구, 자동 채점 및 피드백 시스템, 언어학습 등등

4. 비즈니스 인텔리전스: 데이터 분석 및 보고서 생성, 시장 트렌드 분석 등등

5. 의료 및 헬스케어: 의료 기록 분석 및 요약, 보험사 청구서 자동 작성, 질병 진단 보조 등등

6. 법률 및 규제: 법률 문서 분석 및 요약, 계약서 검토 자동화 등등

7. 소프트웨어 개발: 코드 자동 생성 및 최적화, 버그 검출 및 수정 제안, 개발 문서 자동화

8. 창작 및 엔터테인먼트: 음악 작곡, 게임 시나리오 및 캐릭터 생성 등등

9. ...

LLMOps는 위와 같은 서비스를 만듬에 있어 LLM 관련 최적화와 운영, 관리를 책임지는 직군이다. 이 직무는 머신러닝 모델의 생애주기를 관리하는 MLOps와 아주 유사하지만, 머신 러닝 모델을 직접 만들고 그것의 생애를 관리하는 것이 아니라 누군가 만든 LLM(ChatGPT, Claude, Gemini 등등)을 가져다 쓰면서 프롬프트 관리와 RAG와 같은 서비스라면 벡터 DB 등 다른 시스템이 존재하게 되는데 이를 전체적으로 최적화하고 평가하고 배포 후에 비용 등을 관리하면서 운영한다는 점이 다르다.

아직은 LLMOps팀이 전체 프로세스에 걸쳐 사용할 수 있는 하나의 플랫폼은 존재하지 않다고 보여지고 (그런 방향성을 갖고 있는 툴들은 존재) 다양한 툴을 섞어 사용해야 한다.

• RAG 빌딩 툴: LangChain과 Llama Index가 가장 대표적인데 이 둘의 성격이 많이 다르긴 하지만 LangChain은 너무 복잡한 느낌이 있어서 개인적으로는 Llama Index를 선호한다. 써본 적은 없지만 PromptFlow도 괜찮다는 이야기를 많이 들었다.

• 벡터 DB: Pinecone, ElasticSearch, Weaviate, VESPA, FAISS, GCP Vertex 등등 아주 많다. 개인적으로는 벡터 임베딩을 통한 검색 뿐만 아니라 키워드 기반 검색도 같이 사용하는 것이 더 효율적이라 생각하기에 이 두 가지를 잘 지원해주는 VESPA가 개인적으로는 가장 마음에 든다

• 프롬프트 실험 및 관리: 많이 사용해본 툴이 없긴 하지만 Vellum, Baserun이 가장 많이 쓰이는 것으로 보인다. LangChain은 이 부분을 어느 정도 커버하긴 한다.

• 성능 평가 툴: LLM 기반의 앱의 성능을 평가할 수 있는 테스트셋이 필요하고 이를 버저닝하고 관리할 수 있는 툴이 필요하다. RAG라면 사용되는 벡터DB로부터 사용자 질의와 관련된 정보를 검색해야 하는데 결과 품질을 평가할 수 있는 테스트셋도 필요하다. Ragas, Haystack, Truelens 등이 있고 LangChain도 이 기능을 일부 지원한다

업무에 대해 더 이야기해보자면 보통 LLMOps팀은 개발자와 도메인 전문가 두 직군의 사람이 협업을 하는 형태로 일을 하게 된다.

• 도메인 전문가 (프롬프트 엔지니어): 프롬프트를 바꿔가며 최적화를 수행하는 역할하는데 결국은 테스트 데이터를 만들어 벡터 DB 등의 검색 품질을 평가하고 최종적으로 RAG 시스템의 품질을 평가해야 한다. 이 과정에서 개발자와 밀접한 협업을 하게 된다.

• 개발자 (RAG 시스템 개발자): 벡터 DB을 주기적으로 빌딩하고 검색을 수행하며 LLM을 API로 통해 관리(실패시 재시도하거나 다른 LLM 시도, 비용 관리 등등 운영적인 부분이 중요)하며 전체적인 아키덱처를 잡되 프롬프트와 관련된 부분이나 검색 최적화와 관계된 부분에 있어서 앞서 도메인 전문가와 긴밀하게 일을 하게 된다.

개발자 같은 경우 다양한 파이프라인을 만들어야 하는데 하나는 벡터 DB 등의 데이터베이스를 빌딩하는데 필요한 데이터 소스를 긁어오는 ETL 파이프라인과 이렇게 쌓인 데이터들로부터 최종 데이터를 만들고 이를 벡터 DB 등으로 로딩하는 ELT와 Reverse ETL 파이프라인등을 만들어야 하는데 여기서 바로 데이터 엔지니어링 스킬이 필요하다. 다른 파이프라인은 사용자 질의로부터 시작해서 최종적으로 사용자에게 응답을 리턴하는 런타임 파이프라인이며 여기에는 벡터 DB 질의와 LLM 질의 등이 포함되며 비용과 응답 시간 등등 관리해야할 항목이 많다.

LLMOps팀의 개발은 여러 사이클을 반복하는 형태로 이뤄지게 되는데 보통 아래와 같은 스텝을 필요로 한다.

1. LLM 서비스 기획

2. 개발

   1. 프롬프트 시스템 개발 (도메인 전문가)

   2. RAG 파이프라인 개발 (개발자). 여기에는 앞에 이야기한 데이터 파이프라인의 개발도 포함된다.

3. 평가: 오프라인 테스트셋으로 검색과 최종 결과물 평가 두 종류를 가질 수 있다면 최적이다

4. 스테이징 시스템 배포 후 다시 평가

   1. 이 때는 온라인 테스트도 수행

   2. 전체적인 응답속도 평가도 중요

5. 만족할 만한 결과가 나올 때까지 2-4를 반복한다.

6. 최종 배포 후 모니터링 (이때 비용 모니터링도 중요)

LLMOps팀이 궁극적으로 목표로 삼아야 하는 시스템은 도메인 전문가가 개발자와 아주 밀접한 의사소통 없이 셀프 서비스 형태로 원하는 LLM 기반 서비스를 만들 수 있는 No Code 혹은 Low Code 프레임웍을 만드는 것이다. 아직은 이 방향으로 뚜렷한 위너는 안 보이는데 곧 나오지 않을까 싶다. 혹시라도 알고 있는 서비스나 툴이 있다면 댓글 부탁!

다음 글에서는 데이터 웨어하우스에 관해서 프로덕션 데이터베이스와 비교해가며 더 설명해보고자 한다.