Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hoon Heo
November 24, 2023

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

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

Hoon Heo

November 24, 2023
Tweet

More Decks by Hoon Heo

Other Decks in Programming

Transcript

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

    View full-size slide

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

    View full-size slide

  3. 2022년 11월 ChatGPT 출시

    View full-size slide

  4. 2023년 1월 LINER AI on Google 출시

    View full-size slide

  5. 2023년 3월 ChatGPT API 출시

    View full-size slide

  6. 2023년 4월 Liner Chat 출시

    View full-size slide

  7. 2023년 8월 Liner Workspace 출시

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. We might be doing...

    View full-size slide

  17. Blind
    Prompting

    View full-size slide

  18. "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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. OpenAI API is not
    Deterministic

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. Annoy
    FAISS
    ScaNN
    Milvus
    Pinecone

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  34. Key
    Management

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  39. Model
    Management

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  42. 그리고...

    View full-size slide

  43. 굉장히 뜨거웠던 지난 주말

    View full-size slide

  44. (비개발 직군)

    View full-size slide

  45. (개발 직군)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  49. From old Karter
    To young Karter...

    View full-size slide

  50. Start from GPT-4

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  54. Generative UX

    View full-size slide

  55. Blank Page Syndrome

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  58. 활성화 버튼 최초 모습

    View full-size slide

  59. 활성화 버튼 최초 모습

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  62. Evaluation from the very start

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide