Slide 1

Slide 1 text

고군분투 LLM 프로덕트 적용기 : Blind Prompting 부터 Agent까지 Hoon Heo @Liner

Slide 2

Slide 2 text

)PPO)FP ḿ-JOFS5FDIOJDBM-FBE ᧸஠஠য়࠳ۨੋ.BDIJOF-FBSOJOH&OHJOFFS *OUFSFTUT /BUVSBM-BOHVBHF1SPDFTTJOH 3FDPNNFOEFS4ZTUFN .-0QT

Slide 3

Slide 3 text

2022년 11월 ChatGPT 출시

Slide 4

Slide 4 text

2023년 1월 LINER AI on Google 출시

Slide 5

Slide 5 text

2023년 3월 ChatGPT API 출시

Slide 6

Slide 6 text

2023년 4월 Liner Chat 출시

Slide 7

Slide 7 text

2023년 8월 Liner Workspace 출시

Slide 8

Slide 8 text

ChatGPT가 태어난지 딱 1년이 된 지금!

Slide 9

Slide 9 text

여러분들과 Liner의 지난 1년 간의 회고를 나눌 수 있게 되어 기쁩니다 🥳

Slide 10

Slide 10 text

이런 저런 재밌는 배움 함께 나누어 봐요

Slide 11

Slide 11 text

Prompting

Slide 12

Slide 12 text

LLM을 활용해 PoC를 수행하는 가장 쉬운 방식은 기획안에 맞게 단순한 “프롬프트 엔지니어링”을 하는 것

Slide 13

Slide 13 text

실제로 팀내 프롬프트 엔지니어링 역량이 올라가는 것만으로 기획안에 맞는 제품을 제공할 확률이 높아질 수 있음

Slide 14

Slide 14 text

자세한 내용은 OpenAI Prompt Engineering Guide와 같은 자료를 참조하면 좋으며, 모델마다 활용 테크닉이 조금씩 다를지 언정 크게 다르지는 않다고 보고 있음

Slide 15

Slide 15 text

But,

Slide 16

Slide 16 text

반복되는 프롬프트 엔지니어링은 엔지니어들에게 여러 의문을 낳게 함

Slide 17

Slide 17 text

“지금 고친 프롬프트가 실제로 더 나은 프롬프트인가?” “프롬프트 수정으로 일반화 된 성능 개선이 이루어지고 있는가?” “이제 막 발견한 오류 케이스에 대한 단순 대응은 아닌가?” …

Slide 18

Slide 18 text

We might be doing...

Slide 19

Slide 19 text

Blind Prompting

Slide 20

Slide 20 text

"Blind Prompting" is a term I am using to describe the method of creating prompts with a crude trial-and-error approach paired with minimal or no testing and a very surface level knowledge of prompting. Prompt Engineering vs. Blind Prompting

Slide 21

Slide 21 text

매번 그렇게 우리는 근본으로 돌아가게 됩니다

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

그렇게 유닛 테스트를 위한 테스트 케이스를 작성하기 시작

Slide 25

Slide 25 text

테스트 케이스라고 해봤자 거창한건 아니고, 테스트셋과 실행을 위한 테스트 코드

Slide 26

Slide 26 text

이 작은 추가 덕에 수정이 가해졌을 때, 스코어를 통해 개선 여부 파악이 가능해짐

Slide 27

Slide 27 text

OpenAI API is not Deterministic

Slide 28

Slide 28 text

많은 분들이 아시다시피 OpenAI API는 Deterministic 하지 않음 이는 동일한 입력에 매번 다른 값이 반환될 수 있다는 것

Slide 29

Slide 29 text

이번 OpenAI DevDay에서 해당 문제를 완화하기 위해 Seed 파라미터를 내놓았지만 여전히 완전히 해결된 상황은 아님

Slide 30

Slide 30 text

따라서 매번 같은 결과가 나오지 않을 수 있음을 염두에 두고 측정을 진행해야 함

Slide 31

Slide 31 text

컴포넌트 검증을 위한 테스트 케이스가 많아지고, 시행 횟수를 높일수록 일반화 된 성능 경향을 발견할 수 있게 될 것

Slide 32

Slide 32 text

RAG

Slide 33

Slide 33 text

liner는 이전부터 추천 시스템을 빌딩하며 여러 벡터 서치 엔진을 경험해보았음

Slide 34

Slide 34 text

Annoy FAISS ScaNN Milvus Pinecone …

Slide 35

Slide 35 text

그렇게 결국 정착한 곳은...

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

갖추고 있는 임베딩 모델의 성능에 따라 다르지만, Ada와 같은 범용 임베딩 모델을 사용하는 경우 벡터 서치에서 생각하는 것만큼의 성능을 기대하기는 어려움

Slide 38

Slide 38 text

결국 Term-matching search와 Vector search를 함께 활용하는 Hybrid search로 눈을 돌리게 됨 (Function score로 스코어 조합해 활용)

Slide 39

Slide 39 text

실제로 Function score가 어떤 분포로 형성되고, 어떤 조각들이 답변에 활용되고 있는지 보기 위해 Retrieval 관련 요청과 결과를 로깅하여 Grafana를 통해 시각화하여 관리

Slide 40

Slide 40 text

Key Management

Slide 41

Slide 41 text

과거(라고 하기에는 웃기지만) OpenAI API Rate limit이 굉장히 빡빡하던 시기가 있었음

Slide 42

Slide 42 text

Rate limit 증량도 굉장히 깐깐하고 느리게 처리해주어, 많은 기업들이 여러 키를 활용해 Rolling 방식으로 대응

Slide 43

Slide 43 text

이는 필연적으로 시스템 복잡도를 증가시키는 결과를 낳게 됨

Slide 44

Slide 44 text

이상적인 구조는 단일 키로 Rate limit을 관리하는 것이고, DevDay 이후 기본 Rate limit이 올라갔을 뿐 아니라 증량 요청 처리가 상대적으로 수월해짐

Slide 45

Slide 45 text

Model Management

Slide 46

Slide 46 text

DevDay 이후, OpenAI가 DDoS 공격을 받았다는 사실을 들으신 적이 있을 것

Slide 47

Slide 47 text

실제로 지난 주 2시간 가량의 API Outage가 발생하였고, 이는 OpenAI API 의존도가 큰 경우 서비스가 함께 다운될 수 있다는 치명적인 약점을 드러내기도 함

Slide 48

Slide 48 text

그리고...

Slide 49

Slide 49 text

굉장히 뜨거웠던 지난 주말

Slide 50

Slide 50 text

(비개발 직군)

Slide 51

Slide 51 text

(개발 직군)

Slide 52

Slide 52 text

따라서 이상적으로는 여러 파운데이션 모델을 활용할 수 있도록 Fall-back 로직을 설계해두어야 함

Slide 53

Slide 53 text

반복적으로 행이 걸리거나, Retry 횟수가 지나치게 올라가는 경우 Fall-back 로직이 활성화 되어 다른 모델로 돌릴 수 있도록 설계

Slide 54

Slide 54 text

이같은 Fall-back 로직은 비용과 성능에 영향을 줄 수 밖에 없기 때문에 설계를 하는 과정에서 이같은 고려가 필수적으로 포함되어야 함

Slide 55

Slide 55 text

From old Karter To young Karter...

Slide 56

Slide 56 text

Start from GPT-4

Slide 57

Slide 57 text

Andrej Karpathy’s Recommendation: “Use GPT-4”

Slide 58

Slide 58 text

Agent는 높은 Reasoning 역량을 요구하므로, GPT-4로 전체 로직을 최초 구현하는 것이 좋음

Slide 59

Slide 59 text

이후 비용, 속도 최적화 위해 LLaMA 2, PaLM 2 등의 파운데이션 모델로 Reasoning 역량 크게 필요하지 않은 컴포넌트부터 일부 변경

Slide 60

Slide 60 text

Generative UX

Slide 61

Slide 61 text

Blank Page Syndrome

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

“어떤 요청을 처리해줄 수 있지?” “어디까지 알고 있지?” “어떻게 물어봐야 하지?” …

Slide 64

Slide 64 text

맥락과 의도의 중요성 (from. Linus Lee)

Slide 65

Slide 65 text

활성화 버튼 최초 모습

Slide 66

Slide 66 text

활성화 버튼 최초 모습

Slide 67

Slide 67 text

기능 이해도 부족 “바로 효용을 제공할 수 있는 기능으로 변경”

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

명확한 UX 제공을 통해 지표 개선

Slide 71

Slide 71 text

Evaluation from the very start

Slide 72

Slide 72 text

간단한 유닛 테스트라도 반드시 검증하면서 진행해나가는 것이 중요

Slide 73

Slide 73 text

특정 태스크 벤치마크 데이터셋 활용해 역량 근사할 수 있음 (e.g. HotpotQA for 검색)

Slide 74

Slide 74 text

테스트셋 구축하게 되면 Blind Prompting에서 벗어날 수 있게 됨

Slide 75

Slide 75 text

Pain point 해소해주는 LLMOps 제품 많이 나오고 있으므로 살펴보는 시도도 필요

Slide 76

Slide 76 text