https://platform.openai.com/docs/guides/function-calling
유형
선택형 서비스
-
ChatGPT가 등장하기 이전에 대부분의 서비스가 선택형, 현재 ChatGPT 기반의 서비스도 다양(Writone(선택형+오케스트레이션), 스피치 등)
-
유저의 입력, 클릭을 기반으로 소통(Graphical User Interface)
-
사용자의 자유도 제한
-
제품 팀의 입장에서는 사용자의 행동 패턴을 예측하기 쉬움
대화형 서비스
-
ChatGPT의 등장 이후 급격히 확산
-
유저와 서비스가 "대화"를 통해 상호 작용
-
서비스를 이용 과정에서 많은 제한이 사라짐.
-
사용자의 행동 패턴을 예측하기 어려윰
-
마이크로소프트에서는 "Copilot"이라는 이름으로 홍보
임베디드형 서비스
-
유저와 직접적 소통보다는 유저의 행동을 지켜보다가 등장(트리거) - 맞춤추천 서비스
-
주로 에디터에서 활용
-
자동 완성을 제공하는 형태
세대
ChatGPT API 기초(파라미터)
랜덤성 조절
- temperature
- top_p
-
temperature를 주로 쓰고 둘 다 쓰는건 권장X
-
창작성이 들어가야되지 않는이상 API가 거의 동일한 대답을 하도록 하기위해 temperature를 0으로 설정
-
창작 관련은 최대
temperature=0.8권장
요청 관련
- n : 한번에 여러가지 대답 생성(잘 사용하지 않음)
- stream : 스트리밍방식으로 소통
생성물의 길이에 관여
- stop : chatGPT가 생성하는 방식 자체가 한 글자를 생성하고 그것을 포함해서 이전 문장들을 본 다음에 다음 글자들을 생성하는것인데. 다음 글자를 생성했는데 만약 stop파라미터에 있는 글자과 동일한 글자라고 생각하면 생성 멈춤
예) stop = [","]- max_tokens : 최대 길이 제한
잘 사용하진 않지만 고급 파마리터인것들
- Presence_penalty - 내용 중복 조절
- frequency_penalty - 내용 중복 조절
- logit_bias - 특정 단어가 무조건 등장하게 조정할 때(토큰값 넣어야되서 한국어는 어려움)
- user - openAPI가 어뷰저를 식별할 수 있도록 도와주는건데 안줘도됨
1세대: 기본적인 ChatGPT API 사용
-
ChatGPT가 처음 등장했을 때 대부분의 챗봇이 1세대
-
빠르게 만들어보기 쉬움
-
단순히 ChatGPT API를 중개하는 역할
-
빠르게 등장했다가 빠르게 사라짐
2세대: prompt 오케스트레이션
-
기존 챗봇 빌더들의 작동 방식과 유사(Intent 기반)
-
유저의 입력을 받고, 의도를 파악한 다음, 미리 정의한 시나리오대로 실행
-
기획 단계에서 고민의 시간이 필요
-
시나리오 기반으로 여러개의 Prompt를 작성
-
Prompt Chaining 사용
ex)유저가 여행 계획을 요청할 경우, 계획을 생성하고 표 형태로 정리 -
다수의 프롬프트를 관리해야하기 때문에 복잡함
-
2세대부터 프레임워크 있으면 훨씬 편리함
3세대: 외부 데이터 연결
-
프롬프트에 데이터를 포함시켜 풍부한 답변 생성
-
다양한 API, Database 연동하여 사용
-
서비스로 만들기 가장 적합한 구조
-
3세대부터는 Copilot 이라고 불릴 자격이있다.
외부데이터
- User Data
- APIs: Web Search, Weather, Booking, ...
- Vector DataBase: Documents
- Plugins: ChatGPT Plugins
4세대: 에이전트 사용
Agent 개념
-
주어진 목표와 환경에서 어떤 행동을 취할지 생각하고, 행동을 취하면 결과값이 나온다.
그 결과값을 보고 다시 자기가 어떤 행동을 할지 계획하고
그 계획을 다시 실천으로 옮기고 그 실천으로 옮긴 것에 결과값을 보고 또 기획하고...
이런 루프가 반복되면서 자신에게 주어진 목표를 해결해 나가는 것
-
Lanfchain에서는 툴이라고 부르고, Semantic Kernel에서는 스킬이라고 부르는 것들을 기반으로 액션을 취함
Agent 종류
-
Conversational: 사용가능한 스킬셋(툴)을 기반으로 1~2턴 이내에 빠르게 해결
-
Planning: 목표가 주어졌을 때 스킬셋(툴) 기반으로 해결 과정을 설계하고 하나씩 수행
-
Multi Agent: 목표가 주어졌을 때, 정체성을 가진 여러 에이전트들이 협력
Agent 특징
-
LLM이 사용자 메세지에 대한 답을 주기 위해 스스로 해결 방식을 고민
-
시나리오 방식에서 벗어날 수 있음(최소한의 Intent 분기는 필요함)
- Agent의 권한 관리가 중요함
-
실험 단계, GPT-4로 인한 제약들
- 비싼가격
- 사용량 제한
- 느린 속도
-
디버깅이 까다로움. Wandb같은 Tracing 라이브러리를 사용을 권장
그럼 Agent는 언제 사용하면 좋을까?
- 시나리오 기반 제품을 만들기엔 너무 경우의 수가 많을 경우
- 하지만 문제 해결을 위한 툴은 준비가 잘 되어 있어야 한다.- 비용에 대한 걱정이 별로 없는 경우
- 나중에라도 고객들에게 비싼 가격을 받을 수 있다면
- 한번 실행으로 여러번 사용가능할 경우
- 대기 시간이 길어도 사용자가 이해할 수 있는 경우
- 실시간 채팅 상황이 아니면 보통 괜찮음
분류별 Use Case
선택형+오케스트레이션
-
처음으로 시작하기 가장 쉬운 구조
-
ChatGPT로 문서를 생성하거나, 요약하거는 과정을 할때 사용
-
예) Writone
대화형+오케스트레이션
-
제품을 대화형으로 확장
-
챗봇이 없던 기업이 코파일럿을 만들어가는 사례
-
컨설팅 수요가 가장 많음
-
예) Docubot(dosu-beta)
선택형+에이전트
-
주로 시간이 오래 걸리지만 어려운 작업들을 대상으로 함.
- 예) 웹서치를 호팜한 리포트 생성
-
Planning Agent
- 목표가 주어졌을 때 스킬셋(툴) 기반으로 해결 과정을 설계하고 하나씩 수행
-
Multi Agent
- 목표가 주어졌을 때, 정체성을 가진 여러 에이전트들이 협력
-
예) https://github.com/assafelovic/gpt-researcher/blob/master/README.md
대화형+에이전트
-
대화형+오케스트레이션의 다음 단계
-
복잡하고 어려운 목표보다는 간단하지만 경우의 수가 많을 경우 사용
-
멀티모달 환경(이미지, 오디오 등)에서 활약할 수 있음
-
GPT-4 Image API가 출시되면 서서히 등장할 것으로 예상
-
예)
https://github.com/chenfei-wu/TaskMatrix
https://github.com/microsoft/JARVIS#server
