거대 언어 모델 앱들을 위한 아키텍처의 탄생
학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 번역 과정에서 의미 전달이 애매한 일부 문장은 삭제했습니다. 이번 글은 안드레센 호로위츠 웹사이트에 올라온 글을 정리한 것 입니다.
대규모 언어 모델은 소프트웨어 구축에 있어 강력하고 새로운 기본 요소다. 하지만 매우 새로운데다 일반적인 컴퓨팅 리소스와는 매우 다르게 작동하기 때문에 사용 방법이 항상 명확한 것은 아니다.
이번 글에서는 새롭게 떠오르는 LLM 앱 스택에 대한 레퍼런스 아키텍처를 공유한다. AI 스타트업과 첨단 기술 회사에서 사용하는 가장 일반적인 시스템, 도구 및 디자인 패턴들을 보여준다.이 스택은 아직 초기 단계이며 기반 기술이 발전함에 따라 크게 달라질 수 있지만, 현재 LLM을 사용하는 개발자에게 유용한 참고 자료가 되기를 바란다.
스택
현재 LLM 앱 스택은 다음과 같다.
처음부터 모델을 학습하거나, 오픈 소스 모델을 미세 조정하거나, 호스팅되는 API를 사용하는 등 LLM 으로 구축하는 방법들은 여러가지다. 여기서 보여주는 스택은 인 컨텍스트(in-context : 맥락 내) 학습을 기반으로 하며, 이는 개발자들 대부분이 시작하는 디자인 패턴이다.(현재는 기초 모델들(foundation models)을 통해서만 가능). 다음 섹션은 이 패턴에 대해 간략하게 설명한다. 숙련된 LLM 개발자는 이 부분은 건너뛸 수 있다.
디자인 패턴: 인컨텍스트 학습
인컨텍스트 학습은 바로 사용할 수 있는(즉, 미세 조정 없이) LLM을 사용한 다음, 프라이빗 '컨텍스트' 데이터에 대한 솜씨 좋은 프롬프트와 컨디셔닝(conditioning )을 통해 동작을 제어하는 것이 핵심이다.
예를 들어 일련의 법률 문서에 대한 질문에 답변하는 챗봇을 구축한다고 가정해 보자. 순진한 접근 방식으로는 모든 문서를 ChatGPT 또는 GPT-4 프롬프트에 붙여넣은 다음 마지막에 해당 문서에 대한 질문을 할 수 있다. 이 방법은 아주 작은 데이터셋에는 효과적일 수 있지만 확장성이 떨어진다. GPT-4 모델은 입력 텍스트를 최대 50페이지까지만 처리할 수 있으며, 컨텍스트 윈도(context window)라고 하는 이 한계에 가까워질수록 성능(추론 시간 및 정확도로 측정)이 급격히 저하된다.
인컨텍스트 학습은 각 LLM 프롬프트와 함께 모든 문서를 보내는 대신 가장 관련성이 높은 소수 문서만 보내는 영리한 기법으로 이런 문제를 해결한다.
인 컨텍스트 학습 워크플로우는 크게 3단계로 나눌 수 잇다.
데이터 전처리/임베딩: 이 단계에서는 나중에 검색할 수 있도록 프라이빗 데이터(이번 사례에선 법률 문서)를 저장한다. 일반적으로 문서는 덩어리(Chunk)들로 분할돼 임베딩 모델을 통과한 다음 벡터 데이터베이스라는 특수 데이터베이스에 저장된다.
신속한 구축/검색: 사용자가 쿼리(이 경우 법률 관련 질문)를 던지면 애플리케이션은 언어 모델에 제출할 일련의 프롬프트를 구성한다. 컴파일된 프롬프트는 일반적으로 개발자가 하드코딩한 프롬프트 템플릿, 유효한 출력들 사례, 외부 API에서 검색된 필요한 정보, 벡터 데이터베이스에서 검색된 관련 문서 집합을 결합한다.
프롬프트 실행/추론: 프롬프트가 컴파일되면 독점 모델 API와 오픈 소스 또는 자체 학습된 모델을 모두 포함해 추론을 위해 사전 학습된 LLM에 제출된다. 일부 개발자는 이 단계에서 로깅, 캐싱 및 유효성 검사와 같은 운영 시스템을 추가하기도 한다.
이는 많은 작업이 필요해 보이지만, 일반적으로 LLM 자체를 훈련하거나 미세 조정하는 것보다는 쉽다. 인컨텍스트 학습을 수행하기 위해 ML 엔지니어로 구성된 전문 팀이 필요한 것은 아니다. 자체 인프라를 호스팅하거나 OpenAI에서 값비싼 전용 인스턴스를 구매할 필요도 없다. 이 패턴은 대부분 스타트업들과 대기업들이 이미 해결 방법을 알고 있는 데이터 엔지니어링 문제로 AI 문제를 효과적으로 축소한다. 미세 조정보다 성능이 뛰어난 경향이 있으며, 거의 실시간으로 새로운 데이터를 통합할 수 있다.
인컨텍스트 학습과 관련해 가장 큰 질문들 중 하나는 다음과 같다: 기본 모델을 변경해 컨텍스트 윈도를 늘리면 어떻게 될까? 이는 실제로 가능하며, 현재 활발히 연구되고 있는 분야다. 그러나 여기에는 여러 단점이 있는데, 주로 추론에 드는 비용과 시간이 프롬프트 길이에 따라 4제곱으로 증가한다는 점이다. 오늘날에는 선형 스케일링(이론적으로 가장 좋은 결과)조차도 많은 애플리케이션에서 비용이 엄청나게 많이 든다. 1만 페이지가 넘는 단일 GPT-4 쿼리는 현재 API 요금으로 수백 달러 비용이 든다. 따라서 확장된 컨텍스트 윈도 기반으로 스택을 대대적으로 변경하지는 않을 것으로 예상되지만, 이에 대해서는 본문에서 자세히 설명한다.
LLM 앱 컨텍스트 데이터에는 텍스트 문서, PDF, 심지어 CSV 또는 SQL 테이블과 같은 구조화된 형식도 포함된다. 이들데이터에 대한 데이터 로딩 및 변환 솔루션은 개발자마다 매우 다양하다. 대부분은 Databricks나 Airflow와 같은 전통적인 ETL 도구를 사용한다. 일부는 LangChain(Unstructured 제공) 및 LlamaIndex(Llama Hub 제공)와 같은 오케스트레이션 프레임워크에 내장된 문서 로더를 사용하기도 한다. 하지만 이 스택은 상대적으로 개발이 덜 돼 있다. 그런 만큼, LLM 앱을 위해 특별히 설계된 데이터 복제 솔루션에 대한 기회가 있다고 생각한다.
임베딩의 경우, 대부분 개발자는 오픈AI API, 특히 텍스트 임베딩-ada-002 모델( text-embedding-ada-002)을 사용한다. 오픈AI API는 사용하기 쉽고(특히 이미 다른 OpenAI API를 사용하고 있는 경우), 상당히 좋은 결과를 제공하며, 점점 더 저렴해지고 있다. 일부 대기업은 임베딩에 더 초점을 맞추고 특정 시나리오에서 더 나은 성능을 제공하는 Cohere를 검토하고 있다. 오픈소스를 선호하는 개발자들은 Hugging Face의 Sentence Transformers 라이브러리가 표준으로 통한다. 다양한 사용 사례에 맞는 다양한 유형의 임베딩을 만들 수도 있으며, 이는 현재 틈새 시장이지만 유망한 연구 분야다.
시스템 관점에서 볼 때 전처리 파이프라인에서 가장 중요한 부분은 벡터 데이터베이스이다. 벡터 데이터베이스는 최대 수십억 개 임베딩(즉, 벡터)을 효율적으로 저장, 비교, 검색하는 역할을 담당한다. 시장에서 가장 흔히 볼 수 있는 것은 Pinecone이다. 클라우드에서 호스팅되므로 쉽게 시작할 수 있고 대기업이 프로덕션 환경에서 필요로 하는 많은 기능(예: 우수한 대규모 성능, SSO 및 가동 시간 SLA)을 갖추고 있기 때문에 기본으로 쓰인다.
하지만 다양한 벡터 데이터베이스를 사용할 수 있다. Weaviate, Vespa, Qdrant 같은 오픈 소스 시스템: 일반적으로 단일 노드 성능이 뛰어나고 특정 애플리케이션에 맞게 조정할 수 있으므로 맞춤형 플랫폼을 구축하는 것을 선호하는 숙련된 AI 팀들이 선호한다.
Chroma 및 Faiss 같은 로컬 벡터 관리 라이브러리(Local vector management libraries): 개발자 경험이 풍부하고 소규모 앱과 개발 실험을 위해 쉽게 스핀업할 수 있다. 하지만 대규모로 전체 데이터베이스를 대체할 수는 없다.
pgvector와 같은 OLTP 확장 프로그램: 단일 클라우드 공급업체로부터 대부분 데이터 인프라를 구매하는 기업 등에는 벡터 지원을 위한 좋은 솔루션이다. 장기적으로 벡터 워크로드와 스칼라 워크로드를 긴밀하게 결합하는 것이 합당한지는 불확실하다.
대부분 오픈 소스 벡터 데이터베이스 회사들이 클라우드 제품을 개발하고 있다. 우리 연구에 따르면 클라우드에서 가능한 사용 사례 광범위한 설계 공간에 걸쳐 강력한 성능을 달성하는 것은 매우 어려운 문제다. 따라서 단기간에 옵션들이 크게 바뀌지는 않겠지만 장기적으로는 변화할 가능성이 높다. 핵심적인 질문은 벡터 데이터베이스가 OLTP 및 OLAP와 비슷해져 한두 개 인기 있는 시스템으로 통합될지 여부다.
해결되지 않은 또 하나의 질문은 대부분의 모델에서 사용 가능한 컨텍스트 윈도가 커짐에 따라 임베딩과 벡터 데이터베이스가 어떻게 발전할 것인가 하는 것이다. 컨텍스트 데이터를 프롬프트에 바로 넣을 수 있기 때문에 임베딩 관련성이 낮아질 것이라고 말하고 싶을 수도 있다. 그러나 이 주제에 대한 전문가들 피드백에 보면 임베딩 파이프라인은 시간이 지남에 따라 더 중요해질 수 있다는 의견도 있다. 큰 컨텍스트 윈도는 강력한 도구지만 상당한 계산 비용이 수반된다. 따라서 이를 효율적으로 사용하는 것이 우선 순위가 될 수 있다. 모델 관련성을 위해 직접 학습된 다양한 유형 임베딩 모델들과 이를 활성화하고 활용하도록 설계된 벡터 데이터베이스가 대중화되기 시작할 것이다.
LLM에 지시를 하고 컨텍스트 데이터를 통합하는 전략은 점점 더 복잡해지고 있으며, 제품 차별화에 원천으로서 그 중요성이 점점 더 커지고 있다. 대부분의 개발자는 새로운 프로젝트를 시작할 때 직접 지시(제로 샷 프롬프트, zero-shot prompting)나 일부 예제 출력(few-shot prompting)으로 구성된 간단한 프롬프트를 실험하는 것으로 시작한다. 이들 프롬프트는 종종 좋은 결과를 제공하지만 프로덕션 배포에 필요한 정확도 수준에는 미치지 못한다.
다음 단계의 프롬프트 주짓수는 모델 응답 근거를 신뢰할 수 있는 소스에 두고 모델에 학습되지 않은 외부 컨텍스트를 제공하도록 설계돼 있다. 프롬프트 엔지니어링 가이드에는 생각의 연쇄, 자기 일관성, 생성된 지식, 생각의 나무, 방향성 자극 등 12가지 이상 고급 프롬프트 전략이 있다. 이들 전략은 문서 질문 답변, 챗봇 등과 같은 다양한 LLM 사용 사례를 지원하기 위해 함께 사용할 수도 있다.
바로 이 부분에서 LangChain이나 LlamaIndex와 같은 오케스트레이션 프레임워크가 빛을 발한다. 이들 프레임워크는 프롬프트 체인, 외부 API와 인터페이스(API 호출이 필요한 시기 결정 포함), 벡터 데이터베이스에서 컨텍스트 데이터 검색, 여러 LLM 호출에 걸친 메모리 유지 등 많은 세부 사항을 추상화한다. 또 위에서 언급한 많은 일반적인 애플리케이션들에 대한 템플릿도 제공한다. 이들 프레임워크의 출력은 언어 모델에 제출하라는 프롬프트 또는 일련의 프롬프트다. 이러한 프레임워크는 앱을 시작하려는 애호가와 스타트업 사이에서 널리 사용되며, 그 선두주자는 LangChain이다.
LangChain은 아직 비교적 새로운 프로젝트(현재 버전 0.0.201)이지만, 이미 이 프레임워크로 구축된 앱이 프로덕션 환경으로 이동하는 것을 보고 있다. 일부 개발자, 특히 LLM 얼리 어답터들은 추가적인 종속성을 없애기 위해 프로덕션에서 최초 Python으로 전환하는 것을 선호한다. 하지만 대부분 사용 사례에선 기존 웹 앱 스택과 비슷한 방식으로 시간이 지남에 따라 이러한 DIY 접근 방식이 감소할 것으로 예상된다.
눈썰미가 좋은 독자라면 오케스트레이션 상자에 이상한 항목이 있다는 것을 눈치챌 것이다.: ChatGPT다. ChatGPT는 개발자 도구가 아닌 앱이다. 하지만 API로도 액세스할 수 있다. 그리고 자세히 살펴보면 맞춤형 프롬프트의 필요성을 추상화하고, 상태를 유지하며, 플러그인, API 또는 기타 소스를 통해 컨텍스트 데이터를 검색하는 등 다른 오케스트레이션 프레임워크와 동일한 기능을 일부 수행한다. 여기에 나열된 다른 도구들의 직접적인 경쟁자는 아니지만 ChatGPT는 대체 솔루션으로 간주될 수 있으며, 결국에는 프롬프트 구성에 대한 실행 가능하고 간단한 대안이 될 수 있다.
오늘날 OpenAI는 언어 모델들 중 선두주자이다. 우리와 대화를 나눈 거의 모든 개발자들이OpenAI API를 사용해 새로운 LLM 앱을 시작하는데, 보통 gpt-4 또는 gpt-4-32k 모델을 사용한다. 이것은 앱 성능에 있어 최고 수준 시나리오를 제공하며, 광범위한 입력 도메인에서 작동하고 일반적으로 미세 조정이나 자체 호스팅이 필요하지 않다는 점에서 사용하기 쉽다.
프로젝트가 프로덕션에 들어가 확장되기 시작하면 보다 다양한 옵션들이 필요하다. 일반적인 옵션은 다음과 같다.
gpt-3.5 터보(gpt-3.5-turbo)로 전환: GPT-4보다 최대 50배 저렴하고 훨씬 빠르다. 많은 앱들이 GPT-4 수준 정확도는 필요하지 않지만, 무료 사용자를 위한 짧은 지연 시간을 가진 추론과 비용 효율적인 지원이 필요하다.
다른 독점 공급업체(특히 Anthropic의 Claude 모델)들로 실험해 보라: Claude는 빠른 추론, GPT-3.5 수준 정확도, 대규모 고객을 위한 더 많은 사용자 지정 옵션, 최대 10만 개 컨텍스트 윈도를 제공합니다(입력 길이에 따라 정확도가 저하되는 것으로 확인됨).
오픈 소스 모델에 대한 일부 요청 심사: 쿼리 복잡성 편차가 크고 무료 사용자에게 저렴하게 서비스를 제공해야 하는 검색이나 채팅과 같은 대규모 B2C 사용 사례들에서 특히 효과적일 수 있다.
이는 일반적으로 오픈 소스 기본 모델들을 미세 조정하는 것과 함께 사용할 때 가장 효과적이다. 이번 글에서는 이들 도구 스택에 대해 자세히 다루지는 않지만, 점점 더 많은 엔지니어링 팀에서 데이터브릭스, 애니스케일, 모자이크, 모달 및 런팟과 같은 플랫폼을 사용하고 있다.
오픈 소스 모델에는 Hugging Face 및 Replicate의 간단한 API 인터페이스, 주요 클라우드 제공업체들이 제공하는 로우(raw) 컴퓨팅 리소스, 보다 전문적인 클라우드 제품 등 다양한 추론 옵션들을 사용할 수 있다.
현재 오픈 소스 모델은 독점적인 제품들을 뒤쫓고 있지만, 그 격차는 점점 좁혀지고 있다. Meta의 LLaMa 모델은 오픈 소스 정확도에 대한 새로운 기준을 세웠고 다양한 변형 모델들이 쏟아져 나오고 있다. LLaMa가 연구용으로만 라이선스가 부여된 이후, 여러 새로운 제공업체들이 대안적인 기본 모델(예: Together, Mosaic, Falcon, Mistral)들을 훈련하는 데 뛰어들었다. Meta는 LLaMa 2의 진정한 오픈 소스 릴리스에 대해서도 논의하고 있다.
오픈 소스 LLM이 GPT-3.5에 필적하는 정확도 수준에 도달하면(도달하지 않더라도), 미세 조정된 모델의 대규모 실험, 공유, 생산화(productionizing ) 등 텍스트 쪽에서 스테이블 디퓨전과 같은 순간을 맞이할 것으로 예상된다. Replicate 같은 호스팅 회사는 이미 소프트웨어 개발자들이 이들 모델을 더 쉽게 사용할 수 있도록 도구들을 추가하고 있다. 개발자들 사이에서 보다 작고 세밀하게 조정된 모델이 좁은 사용 사례에서 우수한 정확도에 도달할 수 있다는 믿음이 점점 커지고 있다.
우리와 대화를 나눈 대부분의 개발자들은 아직 LLM을 위한 운영 도구에 대해 깊이 있게 다루지 않았다. 캐싱은 애플리케이션 응답 시간과 비용을 개선하기 때문에 보통 Redis를 기반으로 하는 것이 비교적 일반적이다. 기존 머신 러닝에서 포팅된 Weights & Biases, MLflow 또는 LLM을 위해 특별히 제작된 PromptLayer, Helicone과 같은 도구들도 꽤 널리 사용되고 있다. 이들 도구는 일반적으로 신속한 구축, 파이프라인 튜닝 또는 모델 선택을 개선하는 목적으로 LLM 출력을 기록, 추적 및 평가할 수 있다. LLM 출력을 검증하거나(예: 가드레일) 신속한 인젝션 공격(예: 리버프)을 탐지하기 위해 개발 중인 새로운 도구들도 많이 있다. 이들 운영 도구들 대부분은 자체 Python 클라이언트를 사용해 LLM을 호출하도록 권장하므로 시간이 지남에 따라 이들 솔루션이 어떻게 공존하는지 지켜보는 것도 흥미로울 것이다.
마지막으로, LLM 앱의 정적 부분(즉, 모델 이외 모든 것)도 어딘가에서 호스팅해야 한다. 지금까지 살펴본 가장 일반적인 솔루션은 Vercel이나 주요 클라우드 제공업체와 같은 표준 옵션들이다. 하지만 두 가지 새로운 카테고리가 등장하고 있다. Steamship과 같은 스타트업은 오케스트레이션(LangChain), 멀티테넌트 데이터 컨텍스트, 비동기 작업, 벡터 스토리지, 키 관리 등 LLM 앱을 위한 엔드투엔드 호스팅을 제공한다. Anyscale 및 Modal과 같은 회사는 개발자가 모델과 Python 코드를 한 곳에서 호스팅할 수 있도록 지원한다.
에이전트는 어떤가?
이 레퍼런스 아키텍처에서 빠진 가장 중요한 구성 요소는 AI 에이전트 프레임워크다. "GPT-4를 완전히 자율적으로 만들기 위한 실험적인 오픈소스 시도"로 설명되는 AutoGPT는 올봄 역사상 가장 빠르게 성장한 Github 리포지토리가 됐고 요즘 거의 모든 AI 프로젝트나 스타트업들이 어떤 형태로든 에이전트를 포함하고 있다.
우리와 대화를 나눈 개발자들 대부분은 에이전트 잠재력에 대해 매우 기대하고 있다. 이 글에서 설명하는 인컨텍스트 학습 패턴은 콘텐츠 생성 작업을 보다 잘 지원하기 위해 환각과 데이터 최신성 문제를 해결하는 데 효과적이다. 반면 에이전트는 복잡한 문제를 해결하고, 외부 세계에서 행동하며, 배포 후 경험을 통해 학습하는 등 AI 앱에 근본적으로 새로운 기능을 제공한다. 에이전트는 고급 추론/계획, 도구 사용, 기억/재귀/자기 성찰을 조합해 이를 수행한다.
따라서 에이전트는 LLM 앱 아키텍처에서중심이 될 수 있는 잠재력이 있다.(또는 재귀적 자기 개선을 믿는다면 전체 스택을 대신할 수도 있다.). 그리고 LangChain과 같은 기존 프레임워크에는 이미 일부 에이전트 개념이 통합돼 있다. 단 한 가지 문제가 있다. 에이전트가 아직 실제로 작동하지 않는다는 점이다. 현재 대부분의 에이전트 프레임워크는 개념 증명 단계에 있으며, 놀라운 데모는 가능하지만 아직 안정적이고 재현 가능한 작업 완수는 불가능하다. 우리는 앞으로 에이전트 프레임워크가 어떻게 발전해 나갈지 계속 지켜보고 있습니다.
미래 전망
사전 학습된 AI 모델은 인터넷 이후 소프트웨어의 가장 중요한 아키텍처 변화를 보여준다. 이를 통해 개인 개발자는 대규모 팀이 수개월에 걸쳐 구축하는 지도형 머신 러닝 프로젝트를 능가하는 놀라운 AI 앱을 단 며칠 만에 구축할 수 있다. 여기서 소개한 도구와 패턴들은 LLM 통합의 최종 상태가 아니라 시작점일 뿐이다. 모델 트레이닝으로의 전환 등 주요 변경 사항이 발생하면 이를 업데이트하고 적절한 경우 새로운 레퍼런스 아키텍처를 선보일 예정이다.
.
