Overview
LLM 위에 단순히 얇은 응용 프로그램을 구축하는 것은 다음과 같은 문제가 있음
- 사용자에 대한 응답은 예측할 수 없으며 환각을 포함
- 응답은 애플리케이션의 데이터 및 사용 사례에 근거하지 않음
- 제품 주변에 방어적인 해자를 만들지 않음 →대신 독점 데이터와 지식을 사용하여 방어적인 해자를 구축
- 높은 LLM API 비용: 불필요한 호출을 줄이고 가능하면 더 저렴한 모델을 사용
- LLM은 상태가 없으며(Stateless), agency를 가지고 있지 않음. 따라서 태스크 계획과 추론 능력을 개선하기 위해 하부 LLM을 반복적으로 오케스트레이션하고 자동화할 필요가 있음
새로운 프레임워크 (e.g. LangChain)는 LLM을 중심으로 애플리케이션을 구축하는 구조화된 접근 방식을 제공함
Application은 언제 LLM을 사용해야 하는가?
- 언어 이해 및 처리를 위해 LLM 사용 (지식의 소스가 아님)
- LLM은 인터넷에서 가져온 대량의 텍스트 데이터를 pre-training함
- LLM을 단순히 지식/사실 소스(e.g. 검색 엔진)로 사용하고 싶은 유혹이 있음
- 대신 강력한 언어 이해 및 처리를 위해 LLM을 활용해야 함
- 당신의 SW 애플리케이션에 관련된 지식과 데이터만이 제공되어야 하고 당신이 제공한 데이터로부터 나온 사실/정보만을 반환해야 함
- LLM은 기본 추론에도 사용가능함
- 언어의 이해 외에도 일부 LLM은 기본 추론과 관련하여 적절한 선능을 제공함
- COT를 활용하면 LLM은 사용자의 요청을 더 작은 task로 나누어서 처리하여 정확도를 높일 수 있음
- 검토, 평가 및 피드백에 LLM 사용
- LLM은 처음부터 텍스트를 생성하는 것보다 텍스트를 검토하고 문제를 보고하는데 훨씬 더 효과적임
- 텍스트 변환, 확장, 요약에 LLM 사용
- 구조화되지 않은 텍스트를 JSON 형식으로 또는 그 반대로 변환
- 짧은 텍스트를 확장하고 긴 텍스트를 요약함
고 수준의 아키텍처 다이어그램
Orchestrator 및 Multi-tenanacy
- 다른 모듈을 연결시킴
- Multi-User들이 사용하는 웹사이트/애플리케이션을 개발한다면 multi-tenant 컴포넌트를 빌드하는 것이 중요함
- Orchestrator 역할
- 각 사용자를 위한 개인화
- 개인 정보 보호, 메모리, 컨텍스트 등이 올바른 사용자에 대해서만 검색되도록 함
LLM Provider
- 다양한 유형의 LLM이 존재하며 각각 고유한 강점/약점이 있음
- 사용할 LLM을 선택할 때 고려해야 할 사항
- LLM 추론비용/API 비용 고려사항
- 다양한 사용 사례에 대해 LLM을 달리 사용할 수 있음. (감정 분석에 Encoder 모델, 텍스트 생성/채팅에 Decoder 모델 사용)
- 시맨틱 검색 및 벡터 임베딩 생성을 위한 텍스트 임베딩 모델
- 특정 작업에서 더 나은 성능을 위해 미세 조정된 모델
- 기본적인 텍스트 조작 → smaller, faster, cheaper model
- 기본적인 추론 및 텍스트 생성 →larger, more expensive, slower model
- 챗 모드에서 assistant로서 행동하도록 fine-tuned된 Instruct-following models
- LLM provider를 통해 각 요청에 사용할 모델을 선택할 수 있음
- 한 reqeust의 출력은 텍스트 조작 또는 검토를 위해 두번째 모델로 연결될 수 있음
- LLM provider는 API 비용을 제어하고 각 요청에 가장 적합한 모델을 사용하는데 도움이 됨
- LLM provider를 구축하면 API와 모델 간의 차이점을 애플리케이션의 나머지 부분에서 추상화할 수 있음
- LLM에 대한 플러그인 접근 방식을 허용하여 새 모델을 쉽게 도입할 수 있음
Task Planner
- 사용자의 요청/목표를 얻고 모델을 사용하여 이를 하위 작업으로 나누는 것은 좋은 접근 방식임
- 각 하위 작업은 애플리케이션에 따라 더 작은 작업/목표로 더 세분화
- 접근 방식
- 사용자 목표를 파악하고 추론 기능이 우수한 LLM으로 전송
- LLM이 하위 작업으로 분류하고 JSON 목록으로 반환하도록 프롬프트
- 하위 작업을 데이터베이스에 저장
- 애플리케이션에 따라 하위 작업을 기반으로 사용자 인터페이스를 업데이트할 수 있음
- 필요에 따라 더 작은 하위 작업으로 반복함
Context Data Vector Store
- 앞에서 말했듯이 우리의 application을 위해 pre-trained LLM 지식을 사용해선 안 되며, 대신 필요한 컨텍스트 정보로 각 프롬프트를 준비해야 하며 LLM은 프롬프트에 포함된 정보에 근거한 응답을 하도록 지정해야 함
- 벡터 임베딩 및 벡터 데이터베이스를 사용하면 각 프롬프트에 대한 컨텍스트 데이터의 하위 집합을 의미론적으로 검색하여 효율성과 성능을 높이고 비용을 낮출 수 있음
- 접근 방식
- 새로운 컨텍스트 정보가 있을때마다 섹션으로 chunk하고 LLM을 사용하여 벡터 임베딩을 생성
- 임베딩을 벡터 데이터에 저장하고 각 임베딩과 함께 추가 정보를 저장함 (e.g. URL, 이미지, 원본 텍스트)
- LLM에 요청을 보내기 전에 항상 요청을 Vector Store에 쿼리로 먼저 보냄. 상위 N 개의 관련 결과를 가져와서 요청 프롬프트에 추가함. LLM이 프롬프트 정보만 사용하도록 지정하고 LLM에 프롬프트에 제출함
- 응답을 받으면 전송한 컨텍스트와 비교 → 환각이 없고 데이터에 근거하는지 확인함
- 이 작업은 반복적으로 수행할 수 있으며 벡터 데이터베이스에 대한 새 쿼리를 생성하는데 사용 →그 결과는 LLM에 대한 다음 프롬프트에 사용됨
- 추가 정보가 필요한 경우, 벡터 저장소에 대한 쿼리를 생성하도록 LLM에 요청하는 것이 가능함
Memory Vector Store
- Memory Vector Store는 Context data store와 유사
- 그러나 이전에 애플리케이션을 사용하는 동안 생성된 LLM 프롬프트 및 응답 쌍으로 채워짐
- Memory Vector Store의 목표
- LLM이 이전 상호 작용을 참조하여 사용자에게 개인화하고 올바른 방향으로 안내할 수 있도록 하는 것임
- 이 메모리는 타임스탬프, 위치 등을 사용하여 태그가 지정됨 → 필터링 또는 관련 메모리 및 이전 메모리의 페이딩(e.g. 가지치기)에 사용함
Prompt Manager
- 프롬프트는 길고 복잡함
- 가장 좋은 방법은 여러 속성을 허용하고 올바른 구조로 프롬프트를 빌드할 수 있는 프롬프트 관리자를 빌드
- LLM이 생성하는 기대 포맷을 JSON으로 지정
Response Manager
- Response Manager는 Prompt Manager와 유사하지만 대신 응답을 검증하고 확인함
- 역할
- 응답 형식을 확인하고 프롬프트의 요구사항을 준수하는지 확인 (e.g. JSON 형식 확인)
- 로드된 컨텍스트 및 메모리 데이터에 대한 응답의 유효성을 검사하여 환각이 아닌지 확인함
- 원래 프롬프트와 함께 응답을 LLM에 다시 보내고 LLM에 응답 품질이 좋은지 여부를 결정하도록 요청
- 원치 않는 컨텐츠, 부정적인 감정 등에 대한 응답을 확인
- Response Manager가 응답을 승인하지 않으면 거부 이유가 포함된 새 프롬프트를 생성하고 LLM에 제출하여 새 응답을 받을 수 있음
- 응답이 모든 기준과 안전 확인을 충족할 때까지 반복적으로 수행할 수 있음
Evaluation Module
- LLM는 사용자 프롬프트를 평가하고 미리정해진 기준에 따라 점수를 매기는데 능숙함
- LLM은 피드백을 JSON 형식으로 반환하고 평가를 데이터베이스에 저장할 수 있음.
- 이를 이용하여 새로운 기능을 구축할 수 있음
- 평가를 사용하여 컨텍스트 데이터 개선
- 평가를 사용하여 Task Planner를 업데이트함
External tool provider
- 계산기 등과 같은 외부 도구에 대한 접근을 제공하여 LLM 기능을 확장할 수있음
- 필자의 생각은 응용 프로그램 계층에서 external tool을 사용하고 LLM이 external tool을 직접 접근하는 것을 허용하지 않는 것이 낫다는 생각임
'Daily-Trend-Review' 카테고리의 다른 글
2023/07/11: GPT-4, Longnet, knowledge base (0) | 2023.07.11 |
---|---|
2023/07/10: An Infinite Memory ChatGPT? (0) | 2023.07.10 |
2023/07/06: Vector DB, Transformer, Context Window, vLLM 등 (0) | 2023.07.06 |
2023/07/01: Emerging Architectures for LLM Applications (0) | 2023.07.01 |
2023/06/22: Generative AI 등 (0) | 2023.06.22 |