- LLM으로 쿨한 것을 만드는 것은 쉽지만, 프로덕션 수준으로 만드는 것은 매우 어려움
- LLM 어플리케이션을 제품화 하기 위해 풀어야 하는 주요 과제들, 여러 태스크를 제어흐름내에 통합하는 방법 및 도구의 사용방법, 유망한 사례들을 살펴보는 글
Part I. 프롬프트 엔지니어링을 프로덕션화 하는것의 과제들
- 자연어의 모호성
- 프롬프트 평가
- 프롬프트 버저닝
- 프롬프트 최적화
- 비용과 대기시간
- 비용
- 대기시간(Latency)
- LLM에 대한 비용+대기시간 분석의 불가능성
- 프롬프팅 vs. 파인튜닝 vs. 대체제들
- 프롬프트 튜닝
- 증류(Distillation)을 통한 파인튜닝
- 임베딩 + 벡터 데이터베이스
- 하위/상위 호환
Part 2. 작업 구성 가능성(composability)
- 여러개의 태스크로 구성된 어플리케이션들
- 에이전트, 도구 그리고 제어 흐름
- 툴 vs. 플러그인
- 제어 흐름: 순차적, 병렬적, if, for 루프
- LLM 에이전트의 제어흐름
- 에이전트 테스팅 하기
Part 3. 유망한 사용 사례
- AI 비서
- 챗봇
- 프로그래밍 과 게임
- 학습
- Talk-to-your-data
- LLM이 나를 위해 데이터 분석을 해줄수 있을까 ?
- 검색과 추천
- 판매
- SEO
결론
- 아직 LLM 어플리케이션의 초기 단계에 있음. 모든 것이 빠르게 진화중
- 최근에 LLM 관련 책 제안을 봤는데, 가장 먼저 든 생각은 이들 대부분이 한달안에 구식이 될 것이라는 것
- API는 매일 변경되고 있고, 새로운 어플리케이션들이 발견되고 있음. 인프라스트럭처는 공격적으로 최적화 되는 중
- 비용 및 레이턴스 분석은 주단위로 이루어져야 하고, 새로운 용어들이 도입 되고 있음
- 이런 변경들이 모두 중요한 것은 아님
- 수많은 프롬프트 엔지니어링 논문들은 마치 딥러닝 초창기에 가중치를 초기화하는 다양한 방법을 설명하는 수천개의 논문이 있었던 것이 생각나게 함
- 프롬프트를 조정하는 트릭들은 장기적으로는 중요하지 않을 것
- LLM이 스스로 프롬프트를 작성하는데에도 꽤 능숙하다는 점을 감안하면, 프롬프트를 조정하는 사람이 정말 필요할지 누가 알까?
- 최근에 Linkedin 에서 사람들이 이 분야에 대해 최신 정보를 얻는 방법을 물어봤는데 다양한 의견이었음
- (대부분의)Hype을 무시하세요
- 요약만 읽으세요
- 모든 도구를 사용해보세요
- 당신의 전략은 뭔가요?