밀린 포스트들을 하나씩 정리해봐야겠다. 최근 LLM관련 이것저것 공부하고 있는데, 그 중에서 LLM App Architecutre 관련한 아티클이 있어서 스터디겸 번역해서 소개해보려고함.

제 글은 어디까진 참고용으로.. 혹시라도 이글을 참고하신다면 원문을 보는걸 추천드립니다.

모든 그림과 내용은 아래 링크의 글을 참조함
출처 : https://a16z.com/2023/06/20/emerging-architectures-for-llm-applications/

Intro

• 최근 LLM은 소프트웨어를 구축하기 위한 강력한 새로운 기본 요소로 주목 받고 있으나, 일반 컴퓨팅 자원과는 매우 다르게 작동하기 때문에 어떻게 사용해야 하는지 항상 명확하지 않음.

• 이 글에서는 급속히 등장하는 LLM 앱 스택을 위한 참조 아키텍처를 공유하고 있음.

• AI 스타트업과 세련된 기술 회사에서 사용되는 가장 일반적인 시스템, 도구 및 디자인 패턴을 보여줌.

Stack

• 각각의 요소, 주요 오퍼링, 플레이어에 대한 레퍼런스는 원문 참조
• 본문에서 다루는 스택은 in-context 학습을 기반으로 하며, 대다수의 개발자가 시작할 때 사용하는 디자인 패턴 (foundation models)

Design pattern : In-context learning

in-context 학습

LLM을 그대로 사용하고, 영리한 프롬프팅 및 개인 문맥(contextual) 데이터에 따라 행동을 제어하는 것

나이브하게 컨텍스트를 전부 붙이고 질문을 던지는 경우(e.g 법률 상담 챗봇), scalability가 매우 떨어짐.

• context window의 한계에 접근 하는 경우 성능(추론 시간 및 정확도) 대폭 저하
• 모든 문서를 각 LLM 프롬프트와 함께 보내는 대신, 가장 관련성 있는 문서 몇 개만 전송.
• 가장 관련성 있는 문서는 LLMs의 도움으로 결정.

High Level Workflow

1. 데이터 전처리 / 임베딩

• 나중에 검색할 개인 데이터(예: 법적 문서)를 저장.
• 일반적으로 문서는 청크로 나누어지고, 임베딩 모델을 통과한 후, 벡터 데이터베이스에 저장.

2. 프롬프트 구성 / 검색

• 사용자가 쿼리(이 경우 법적 질문)를 제출하면, 응용 프로그램은 언어 모델에 제출할 프롬프트의 시리즈를 구성함.
• 컴파일된 프롬프트는 일반적으로 아래 항목들을 결합함.
  - 개발자가 하드코딩한 프롬프트 템플릿
  - 유효한 출력 예제(few-shot)
  - 외부 API에서 검색된 필요한 정보, 및 벡터 데이터베이스에서 검색된 관련 문서

3. 프롬프트 실행 / 추론

• 프롬프트가 컴파일되면, 사전 훈련된 LLM에 추론을 위해 제출됨
• 일부 개발자들은 이 단계에서 로깅, 캐싱 및 검증과 같은 운영 시스템도 추가함

장점

• 복잡해보이지만, LLM 자체를 훈련하거나 fine tuning 하는 것보다 쉬움
• fine-tuning을 통해 LLM이 그것을 기억하기 전에 특정 정보가 훈련 세트에서 적어도 약 10번 발생해야 하는 상대적으로 작은 데이터셋에 대해서는 세부 조정보다 성능이 뛰어남
• 거의 실시간으로 새로운 데이터를 포함할 수 있음
• in-context 학습을 수행하기 위해 ML 엔지니어의 전문 팀이 필요하지 않음
• 자체 인프라를 호스팅하거나 OpenAI에서 비싼 전용 인스턴스를 구입할 필요도 없음

Data Preprocessing/Embedding

Contextual Data

• LLM 앱의 컨텍스트 데이터에는 텍스트 문서, PDF, 그리고 CSV나 SQL 테이블과 같은 구조화된 형식까지 포함됨
• 이 데이터를 위한 데이터 로딩과 변환 솔루션은 다양함
• 대부분은 Databricks나 Airflow와 같은 전통적인 ETL 도구를 사용
• LangChain(Unconstructued) 및 LlamaIndex(Llama Hub)와 같은 오케스트레이션 프레임워크에 내장된 문서 로더도 사용

Embedding

• 대부분 OpenAI API, 특히 text-embedding-ada-002 모델을 사용함.
• 사용하기 쉽고(특히 이미 다른 OpenAI API를 사용 중인 경우), 합리적으로 좋은 결과를 제공하며, 점점 저렴해지고 있음.
• 몇몇 대기업들은 또한 Cohere를 탐구하고 있으며, 이는 제품 노력을 임베딩에 좁게 집중하고 특정 시나리오에서 더 나은 성능을 제공함.
• 오픈소스를 선호하는 개발자들은 Hugging Face의 Sentence Transformers 라이브러리리 사용함.
  다양한 유형의 임베딩을 다양한 사용 사례에 맞게 제작하는 것도 가능함.

Vector DB

• 시스템 관점에서 전처리 파이프라인의 가장 중요한 부분은 벡터 데이터베이스
• 효율적으로 수십억 개의 임베딩(즉, 벡터)을 저장, 비교, 검색하는 책임이 있음.
• 시장에서 가장 일반적으로 보게 되는 선택은 Pinecone;완전히 클라우드에서 호스팅되기 때문에 시작하기 쉬움;대기업들이 제품화에 필요로 하는 많은 기능들(예: 대용량에서 좋은 성능, SSO, 및 업타임 SLA)을 가지고 있음
• 그러나, 매우 다양한 벡터 데이터베이스가 있음
• 오픈소스 시스템 Weaviate, Vespa, Qdrant
• 로컬 벡터 관리 라이브러리 Chroma와 Faiss
• 전반적으로 대부분의 오픈 소스 벡터 데이터베이스 회사들은 클라우드향
  -대부분의 모델에 대해 사용 가능한 컨텍스트 창이 커짐에 따라 임베딩과 벡터 데이터베이스가 어떻게 진화할 것인지에 대한 논의
• 컨텍스트 데이터를 직접 프롬프트에 넣을 수 있기 때문에 임베딩이 덜 중요해진다는 의견 존재
• 전문가들은 보통 반대 의견 :  임베딩 파이프라인이 시간이 지남에 따라 더 중요해질 수 있다는 것
  큰 context window는 강력한 도구이지만,  상당한 계산 비용을 수반함

Prompt Construction/Retrieval

LLM에 대한 프롬프트 전략과 contextual data의 통합

• 점점 더 복잡해지고 있으며 제품 차별화의 중요한 요인
• 대부분의 개발자들은 직접적인 지시사항(제로-샷 프롬프트) 또는 가능한 일부 예제 출력(퓨-샷 프롬프트)을 포함한 간단한 프롬프트로 새 프로젝트 시작함
• 이러한 프롬프트는 종종 좋은 결과를 가져다 주지만, 제품 배포에 필요한 정확성 수준에는 미치지 못합니다

Orchestration Framework

• 모델 응답을 믿을만한 소스(source of truth)에 기반하게 하고, 모델이 훈련되지 않은 외부 문맥을 제공하기 위해 설계됨
• 프롬프트 엔지니어링
• LangChain, LlamaIndex
  - 외부 API와의 인터페이스(어떤 API 호출이 필요한지 결정하는 것 포함), 벡터 데이터베이스로부터의 문맥적 데이터 검색, 여러 LLM 호출에 걸친 메모리 유지 등 많은 세부 사항을 추상화함.
  - 일반적인 애플리케이션에 대한 템플릿을 제공함.
  - 출력 = '언어 모델에 제출할 프롬프트 또는 일련의 프롬프트'
  - DIY 접근법은 시간이 지남에 따라 감소할 것으로 예상됨
  - ChatGPT? : 프롬프트 구성에 대한 간단한 대안이 될 수도 있음.

Prompt Execution/Inference

LLM

• gpt-4 또는 gpt-4-32k 모델로 새로운 LLM 앱을 시작
• 파인 튜닝이나 자체 호스팅이 거의 필요하지 않음

고려 사항

• gpt-3.5-turbo로 전환: GPT-4보다 약 50배 저렴하고 훨씬 빠름.
• 많은 앱들이 GPT-4 수준의 정확도를 필요로 하지 않지만, 낮은 지연 시간의 추론과 free plan 지원이 필요함
• 다른 상업적인 제공 업체 실험 : Claude는 빠른 /추론, GPT-3.5 수준의 정확도, 대규모 고객을 위한 더 많은 맞춤화 옵션, 그리고 최대 100k의 문맥 창을 제공
• 입력의 길이나 늘어남에 따른 정확도 저하 식별
• 일부 요청을 오픈 소스 모델로 분류:  검색이나 채팅과 같은 대규모 B2C 사용 사례에서 매우 효과적일 수 있음
• 보통 오픈 소스 기본 모델의 파인튜닝과 함께 진행되어야함. Databricks, Anyscale, Mosaic, Modal, RunPod 등
• 독점적 모델과 격차는 좁혀지고 있음;Meta LLaMa

LLMOps

• 본문에서 인터뷰한 대부분의 개발자들은 아직 LLM용 운영 도구에 대해 깊이 있게 연구하지 않았음
• Redis 기반의 캐싱은 흔히 사용됨
• Weights & Biases, MLFlow, PromptLayer, Helicone
  - LLM 출력을 로깅, 추적 및 평가
  - 프롬프트 구축
  - 파이프라인 튜닝
  - 모델 선택 개선
  - LLM 출력을 검증
  - 프롬프트 인젝션 공격 탐지
  - 운영 도구 대부분은 LLM 호출을 위해 자체 Python 클라이언트의 사용을 권장함

App Hosting

• LLM 앱에서 모델을 제외한 정적 부분의 호스팅, 가장 일반적인 해결책은 클라우드
• Steamship : LLM 앱을 위한 종단간 호스팅을 제공, 오케스트레이션(LangChain), 멀티 테넌트 데이터 - 컨텍스트, 비동기 작업, 벡터 저장 및 키 관리를 포함
• Anyscale,Modal : 모델과 Python 코드를 한 곳에서 호스팅할 수 있게 해줌

What about agents?

위 아키텍처에서 가장 중요한 누락된 구성 요소는 AI 에이전트 프레임워크

• AutoGPT :  "GPT-4를 완전히 자동화하기 위한 실험적인 오픈 소스 시도"
• 인 컨텍스트 학습 패턴 : hallucination, 데이터 신선도 문제를 해결하여 콘텐츠 생성 작업을 더 잘 지원하는데 효과적
• 반면에 에이전트는 AI 앱에 근본적으로 새로운 기능 세트를 제공함: 복잡한 문제를 해결하고, 외부 세계에 행동하며, 배포 후 경험에서 학습함
  - 고급 추론/계획, 도구 사용, 메모리 / 재귀 / 자기 반성의 조합을 통해 이를 수행
  - 에이전트는 LLM 앱 아키텍처의 중심 부분이 될 잠재력이 있음
  - LangChain과 같은 기존 프레임워크들은 이미 일부 에이전트 개념을 포함하고 있음