LLM 기반 챗봇 설계, 구조 변화

사진: Unsplash 의 Bernd 📷 Dittrich

많은 곳에서 LLM을 활용한 챗봇 서비스를 만들고 있는데, 챗봇 개발의 설계, 구조의 흐름이 어떻게 변하고 있는지 조사해 보자.

1. LLM api만을 사용

LLM api 기반 챗봇

2. prompt chaining

prompt chaining chatbot

prompt chaining을 이용

• SequentialChain, Router Chain → Langchain
• 여러 단계가 필요한 문제 해결과정을 프롬프트를 각 단계로 나누고, 체이닝 하여 해결하는 방식
• 위 구조는 하나의 LLM에게 프롬프트를 여러 단계로 나눠 추론
• 아래 구조는 하나의 제너럴 LLM이 각각 도메인 또는 역할에 맞게 파인튜닝된 LLM에게 추론하도록 하고 추론된 결과를 취합
  • https://www.aitimes.com/news/articleView.html?idxno=153902
• 아래 나오는 agent구조와 더 비슷해 보임

multi LLM

3. 외부 데이터 연결

RAG

임베딩 + 벡터 데이터 베이스

• LLM을 사용하여 임베딩을 생성한 다음, 임베딩을 기반으로 검색 및 추천시스템 등의 ML 애플리케이션을 구축
• https://news.hada.io/topic?id=11263
• 모든 DB는 머지않아 vector DB가 될 것이라 전망

Orchestration Framework

LangChain, Semantic Kernel(MS)

프레임워크들의 공통적 철학

copilot stack

• Orchestration은 Copilot의 핵심 로직
• Copilot을 개발한 모든 팀이 자체 오케스트레이션 계층을 구축했으며, 모델을 선택하고, 연관성 있는 데이터를 선택함으로써 프롬프트를 증강하는 모든 과정을 공통적으로 수행

RAG (Retrieval-Augmented generation: 검색증강생성)

RAG

https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-foundation-models-customize-rag.html

4. agent 사용

agent

• agent : 문제가 주어지면 에이전트가 알아서 자기에게 주어진 툴들을 사용해 해결방법을 계획하고, 행동하여 문제를 해결
• https://python.langchain.com/docs/how_to/#agents
• https://github.com/101dotxyz/GPTeam
• http://aidev.co.kr/chatbotdeeplearning/12619 
• 시뮬레이션 우주론?
• 아직까지는 가격, 속도, 사용량 제약
• 복잡하고 어려운 문제를 배치타임에 한번 돌려서 여러 번 서비스 가능하다면 적용해 볼만할 듯