당근 ML 밋업 1회 - 'LLM을 프로덕션에 적용하며 배운 것들' 정리

LLM을 프로덕션에 적용하며 배운 것들

발표자: 박민우

 

https://youtu.be/NzxlIGPbICY?si=duX-VBdytjN14H8j

 

 

TL;DR

---

 

사람은 물론이고 기존에 딥러닝이 하던 일도 LLM으로 대체할 수 있다.

• LLM 호출비용이 비싸다는 의견이 있지만, GPT-4가 아니라 Gemini Pro 1.0 기준으로 100만 게시글 처리에 $100 정도.
• 원하는 task + 적절한 모델 선택할 수 있다면 합리적인 비용으로도 감당할 수 있다.

API 호출 비용도 내려가는 중. 당분간은 이런 추세가 이어지지 않을까 예상함.

LLM 활용사례

중고거래: LLM 기반 추천 / 광고

물건을 파는 플랫폼이지만, 사용자가 직접 게시글 작성.. 정형화된 데이터가 거의 없음.

• 사용자의 입력값으로부터 정형화 데이터를 LLM으로 추출 -> 추천이나 광고 집행하는 기능 실험중.
• 게시글에서 브랜드, 타입, 중요 키워드 등을 추출해서
  • 동일한 제품 / 상품 등 추천하거나 광고 노출하는 식

동네생활: LLM 기반 장소 연결, 태그 추천

지역에 있는 가게정보 업로드할 때 '링크 걸어주는 기능'이 있지만, 사용률이 높지 않음.

• LLM으로 게시글에서 가게 이름과 같은 정보 추출 -> 정보 찾아서 링크 추가해주는 기능. '언급된 장소' 기능.
• 가게정보 모아서 볼 수 있는 형태.

해시태그 기능이 최근에 추가됐는데, 아직 사용자들이 잘 쓰지 않고 있음. 기존 글에도 해시태그는 없는 상태.

• LLM으로 '해시태그 추천' 기능을 제공.
• 기존 글에도 해시태그 걸어서 탐색할 수 있는 형태.

모임 추천

모임이 추구하는 성별, 연령대, 주제와 같은 정보도 정형화되어 있지 않음.

• LLM으로 정형화
• 관심있을 것 같은 사람에게 추천하는 큐레이션

부동산: 매물정보 자동입력

부동산 정보는 미리 정보를 적어두고 복사 붙여넣기로 등록하는 경우가 많음.

• 예전에는 Form을 입력하도록 강제했는데, 게시 안 하는 경우가 많았음.
• 붙여넣으면, LLM이 알아서 form 넣어주는 식으로 사용.

실시간 LLM 파이프라인.

많은 팀에서 LLM을 사용하고 싶어한다.

• 게시글이 작성될 때마다 필요한 task를 수행하는 LLM을 호출하고, 수행결과를 저장하는 파이프라인이 필요함.
• kafka로 이벤트 들어오면 처리 -> kafka로 다시 흘려보내거나 BigQuery에 저장하는 형태로 구성.

설정파일만 변경하면 new pipeline task를 추가할 수 있는 형태로 사용중.

활용하면서 느꼈던 몇 가지 팁

Prompt 중요하다

prompt 작성이 성능에 가장 큰 영향을 준다고 생각함.

• Gemini에서 long context 중간에 키워드를 숨겨놓고, Prompt로 찾아오는 실험 수행했을 때
• tokenizer와 Prompt 변경만으로 recall 비율을 20%에서 100%까지 올렸다는 사례도 있음.

모델에게 어떻게 요청하는가 -> 성능에 영향을 미친다.

• 줄바꿈 하나, 띄어쓰기 하나로도 결과가 바뀌기는 하는데... 이건 의미적으로는 차이 없는 거라서, 모델이 발전하면서 점차 개선될 거라 생각함.

반복실험 / 평가가 핵심이다

자연어로 prompt 만들어서 하는 거라, 한 번에 좋은 결과를 얻기는 불가능하다.

• 성능을 개선하려면 측정 가능해야 하고, 계속 실험하면서 측정값을 목표치까지 도달하게 만드는 게 중요함.

평가 데이터셋 만들기

• 중요한 edge case 포함하고, 보완한다

자동화된 배치 평가 파이프라인

• task-specific Metric
• response format에 문제는 없는지 (Error rate 등)
• 쉽지 않을 경우, GPT-4 같은 고성능 모델에게 평가 prompt 맡기고 scoring 요청하는 형태로도 많이 쓴다.
• 도메인 전문가 평가가 제일 중요하다. 서비스를 잘 아는 사람의 평가를 토대로 iteration하는 것 추천.

간단하게 그려본 파이프라인

• LLM feature 추가할 때, 소량의 데이터로 먼저 배치 테스트 (100 ~ 1000여 개)
• Production 배포 이후에도 inference, 모니터링, sampling 분석이 필요했다
  • 샘플링해서 꾸준히 봐야 하는 이유: sample 단위에서는 보지 못했던 에러들이 발생하기 때문.

좋은 Prompt 노하우는 회사 내에 체계화한다

Prompt 만들면서 생기는 노하우를 회사 차원에서 관리하는 것.

• 구글의 경우 좋은 Prompt 작성에 필요한 component들을 정리해서 공개해뒀음
• 이게 다 들어가야 한다기보다는, 중요한 것들은 무엇인지 확인하는 용도.

Structure 예시

• Role, Goal 명시
• 작업에 필요한 Context 제공
• 어떤 작업을 할 것인지 instruction 명시
• Tone / Format 명시.
• input 넣고, 출력을 명시하는 힌트 (prefill response)

어떤 구조가 잘 동작하는지 발전시키는 것.

구분자로 구조를 명확하게 나눈다.

LLM에게 prompt 넘길 때 구분자 명확하게 명시한다. 당근에서는 XML 스타일로 활용 중.

요구사항은 구체화한다.

세부사항을 명확하고, 구체적으로 지시할수록 좋다. 예컨대 개인정보를 제거해달라고 할 때

• 개인정보에 포함되는 데이터는 무엇이 있는지
• 어떤 식으로 제거할 것인지
• 개인정보가 아닐 경우 어떻게 처리할 것인지

명시할수록 좋다.

특히 반복평가 프로세스가 잘 되어 있을수록, 요구사항을 구체화하기 쉬워진다.

LLM에 예시 보여주기

Few-shot으로 많이 알려진 방법론. 써보니까 굉장히 강력한 방법론이다.

• 단, 예시를 너무 많이 주면 성능이 떨어지는 경향이 있었다.
  • 입력데이터가 예시와 비슷하면 예시로 입력한 값 그대로 리턴한다던지.
  • 잘 모르겠는 입력이 들어오면 예시값을 그대로 응답한다던지.
• formatting 관련한 예시의 경우 1개만 줬을 때 성능이 좋고, 더 많은 예시를 준다고 성능이 나아지지는 않는다.

형식이나 지시사항을 이해할 수 있는 1~2개의 예시만 사용하고 있음.

Chain of Thought

Prompt에서 단계별로 사고 과정을 작성하는 예시를 넣어서 전달하면, 더 좋은 결과를 얻을 수 있다.

• COT로 '틀린 예시'도 같이 주면서 생각할 범위를 넓히면 성능이 올라간다는 예시도 있고
• Let's think step by step 만 해도 성능이 올라갔다는 연구도 유명하고
• Rephrase and Respond: 사용자 입력값을 그대로 처리하지 말고, rephase 후 응답하도록 하면 성능이 나아진다는 연구도 있었다
• take a step back: 응답하기 전에 'step back question'을 스스로 만들고, reasoning한 이후 답하면 성능이 좋아진다

예시

• 판단하는 이유를 먼저 스스로 설명하게 했을 때 성능이 나았다
• 게시글 분류 문제에서도 '바로 분류' 하기보다는 '요약 -> 분류' 형태로 작업을 수행했을 때 결과가 좋았다

주어진 input이 길 때 효과가 더 좋았다.

• 가게 이름을 추출하는 task 수행 시 -> 가게 리뷰일 때만 수행하도록 만들고 싶을 때
  • 리뷰인지 아닌지 판단하게 하고
  • 리뷰일 때만 가게 이름을 추출하도록 prompt를 만들면 Error rate가 줄어들었다.

Pseudo-Code로 지시하기

줄글로 복잡하게 설명해야 하는 로직이라면, 간략한 코드 형태로 지시할 경우 더 잘하기도 한다.

지시사항 / 사용자 입력의 순서도 성능에 영향을 준다

• context 길이가 길면, 지시사항이 앞쪽에 있을 경우 잊혀지는 경향이 있다.
• 뒤에 두는 게 유리하다.

field 이름도 성능에 영향을 준다

prompt 똑같고 output 필드명만 바꿨는데도 응답값에 차이가 난다.

• keyword: 단어 하나만 짚어서 응답하는 경향
• keywords: 여러 키워드 복수 응답
• query: 단어보다는 phrase로 응답하는 경향

지시사항을 구체적으로 하고, 적절한 필드를 쓰는 게 좋다

잘 모르면 지어낸다. 예외처리 방식을 명시한다

출력 형식 제어하기

structured response 만들어주는 기능이 있다면 사용하는 걸 권장.

• 필드값 형식이 원하는 형태에서 벗어나는 경우도 있다. 검증하고 후처리하는 로직을 파이프라인에 추가해야 함.

적절한 모델 선택도 중요한 요소. 파이프라인이 잘 되어 있다면, 비교 선택하기 편해진다.

LLM API의 Failover / EOF 대비하기

생각보다 LLM API 장애가 종종 난다. 대응해야 함.

• 모델 서빙하거나, 유실된 데이터 채우는 것도.

업데이트가 잦고, 모델 수명주기가 짧다.

• 버전업 대비 빠르게 해두는 게 좋다.
• alias 쓸 경우, 모르는 새 모델이 변경되는 경우가 생긴다. production에서는 반드시 모델 지정해야 한다.

사용량 체크

API 사용량 제한이 있다.

• 다양한 파이프라인에서 하나의 계정을 쓸 경우... 사용량 초과 시 모든 파이프라인 장애로 이어질 수 있다.
• 서비스계정 분리하고, 그게 어렵다면 파이프라인별로 자체 limit을 세팅해준다. ratelimit으로 장애나지 않도록 주의.

LLM이 중요한 게 아니라 서비스 성공이 중요하다

배포 이후, '서비스의 성공' 관련한 지표 계속 확인한다.

• 테스트 때 못 봤던 에러 모니터링... 평가 데이터에 추가해서 반복 개선한다.