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

VESSL AI November에서 발표한 Liner가 1년 간 LLM을 제품에 적용하며 배운 점들 공유

Transcript

1. 고군분투 LLM 프로덕트 적용기 : Blind Prompting 부터 Agent까지 Hoon Heo @Liner
2. )PPO
   )FP
   ḿ
   -JOFS
   5FDIOJDBM
   -FBE
   ᧸
   ஠஠য়࠳ۨੋ
   .BDIJOF
   -FBSOJOH
   &OHJOFFS
   *OUFSFTUT
    /BUVSBM
   -BOHVBHF
   1SPDFTTJOH
    3FDPNNFOEFS
   4ZTUFN
    .-0QT
3. 2022년 11월 ChatGPT 출시
4. 2023년 1월 LINER AI on Google 출시
5. 2023년 3월 ChatGPT API 출시
6. 2023년 4월 Liner Chat 출시
7. 2023년 8월 Liner Workspace 출시
8. ChatGPT가 태어난지 딱 1년이 된 지금!
9. 여러분들과 Liner의 지난 1년 간의 회고를 나눌 수 있게 되어 기쁩니다 🥳
10. 이런 저런 재밌는 배움 함께 나누어 봐요
11. Prompting
12. LLM을 활용해 PoC를 수행하는 가장 쉬운 방식은 기획안에 맞게 단순한 “프롬프트 엔지니어링”을 하는 것
13. 실제로 팀내 프롬프트 엔지니어링 역량이 올라가는 것만으로 기획안에 맞는 제품을 제공할 확률이 높아질 수 있음
14. 자세한 내용은 OpenAI Prompt Engineering Guide와 같은 자료를 참조하면 좋으며, 모델마다 활용 테크닉이 조금씩 다를지 언정 크게 다르지는 않다고 보고 있음
15. But,
16. 반복되는 프롬프트 엔지니어링은 엔지니어들에게 여러 의문을 낳게 함
17. “지금 고친 프롬프트가 실제로 더 나은 프롬프트인가?” “프롬프트 수정으로 일반화 된 성능 개선이 이루어지고 있는가?” “이제 막 발견한 오류 케이스에 대한 단순 대응은 아닌가?” …
18. We might be doing...
19. Blind Prompting
20. "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
21. 매번 그렇게 우리는 근본으로 돌아가게 됩니다
24. 그렇게 유닛 테스트를 위한 테스트 케이스를 작성하기 시작
25. 테스트 케이스라고 해봤자 거창한건 아니고, 테스트셋과 실행을 위한 테스트 코드
26. 이 작은 추가 덕에 수정이 가해졌을 때, 스코어를 통해 개선 여부 파악이 가능해짐
27. OpenAI API is not Deterministic
28. 많은 분들이 아시다시피 OpenAI API는 Deterministic 하지 않음 이는 동일한 입력에 매번 다른 값이 반환될 수 있다는 것
29. 이번 OpenAI DevDay에서 해당 문제를 완화하기 위해 Seed 파라미터를 내놓았지만 여전히 완전히 해결된 상황은 아님
30. 따라서 매번 같은 결과가 나오지 않을 수 있음을 염두에 두고 측정을 진행해야 함
31. 컴포넌트 검증을 위한 테스트 케이스가 많아지고, 시행 횟수를 높일수록 일반화 된 성능 경향을 발견할 수 있게 될 것
32. RAG
33. liner는 이전부터 추천 시스템을 빌딩하며 여러 벡터 서치 엔진을 경험해보았음
34. Annoy FAISS ScaNN Milvus Pinecone …
35. 그렇게 결국 정착한 곳은...
37. 갖추고 있는 임베딩 모델의 성능에 따라 다르지만, Ada와 같은 범용 임베딩 모델을 사용하는 경우 벡터 서치에서 생각하는 것만큼의 성능을 기대하기는 어려움
38. 결국 Term-matching search와 Vector search를 함께 활용하는 Hybrid search로 눈을 돌리게 됨 (Function score로 스코어 조합해 활용)
39. 실제로 Function score가 어떤 분포로 형성되고, 어떤 조각들이 답변에 활용되고 있는지 보기 위해 Retrieval 관련 요청과 결과를 로깅하여 Grafana를 통해 시각화하여 관리
40. Key Management
41. 과거(라고 하기에는 웃기지만) OpenAI API Rate limit이 굉장히 빡빡하던 시기가 있었음
42. Rate limit 증량도 굉장히 깐깐하고 느리게 처리해주어, 많은 기업들이 여러 키를 활용해 Rolling 방식으로 대응
43. 이는 필연적으로 시스템 복잡도를 증가시키는 결과를 낳게 됨
44. 이상적인 구조는 단일 키로 Rate limit을 관리하는 것이고, DevDay 이후 기본 Rate limit이 올라갔을 뿐 아니라 증량 요청 처리가 상대적으로 수월해짐
45. Model Management
46. DevDay 이후, OpenAI가 DDoS 공격을 받았다는 사실을 들으신 적이 있을 것
47. 실제로 지난 주 2시간 가량의 API Outage가 발생하였고, 이는 OpenAI API 의존도가 큰 경우 서비스가 함께 다운될 수 있다는 치명적인 약점을 드러내기도 함
48. 그리고...
49. 굉장히 뜨거웠던 지난 주말
50. (비개발 직군)
51. (개발 직군)
52. 따라서 이상적으로는 여러 파운데이션 모델을 활용할 수 있도록 Fall-back 로직을 설계해두어야 함
53. 반복적으로 행이 걸리거나, Retry 횟수가 지나치게 올라가는 경우 Fall-back 로직이 활성화 되어 다른 모델로 돌릴 수 있도록 설계
54. 이같은 Fall-back 로직은 비용과 성능에 영향을 줄 수 밖에 없기 때문에 설계를 하는 과정에서 이같은 고려가 필수적으로 포함되어야 함
55. From old Karter To young Karter...
56. Start from GPT-4
57. Andrej Karpathy’s Recommendation: “Use GPT-4”
58. Agent는 높은 Reasoning 역량을 요구하므로, GPT-4로 전체 로직을 최초 구현하는 것이 좋음
59. 이후 비용, 속도 최적화 위해 LLaMA 2, PaLM 2 등의 파운데이션 모델로 Reasoning 역량 크게 필요하지 않은 컴포넌트부터 일부 변경
60. Generative UX
61. Blank Page Syndrome
63. “어떤 요청을 처리해줄 수 있지?” “어디까지 알고 있지?” “어떻게 물어봐야 하지?” …
64. 맥락과 의도의 중요성 (from. Linus Lee)
65. 활성화 버튼 최초 모습
66. 활성화 버튼 최초 모습
67. 기능 이해도 부족 “바로 효용을 제공할 수 있는 기능으로 변경”
70. 명확한 UX 제공을 통해 지표 개선
71. Evaluation from the very start
72. 간단한 유닛 테스트라도 반드시 검증하면서 진행해나가는 것이 중요
73. 특정 태스크 벤치마크 데이터셋 활용해 역량 근사할 수 있음 (e.g. HotpotQA for 검색)
74. 테스트셋 구축하게 되면 Blind Prompting에서 벗어날 수 있게 됨
75. Pain point 해소해주는 LLMOps 제품 많이 나오고 있으므로 살펴보는 시도도 필요
76. Thanks! huffonism@gmail.com