LLM Application

대규모 언어 모델은 소프트웨어 빌드를 위한 강력한 새로운 기본 요소입니다. 그러나 그것들은 매우 새롭고 일반적인 컴퓨팅 리소스와 매우 다르게 작동하기 때문에 그것들을 사용하는 방법이 항상 명확하지는 않습니다.

 

LLM을 사용하여 빌드하는 방법에는 처음부터 모델 학습, 오픈 소스 모델 미세 조정 또는 호스팅된 API 사용 등 다양한 방법이 있습니다. 여기서 보여드리는 스택은 컨텍스트 내 학습을 기반으로 하며, 이는 대부분의 개발자가 시작하는 디자인 패턴입니다(현재는 기본 모델에서만 가능).

 

컨텍스트 내 학습의 핵심 아이디어는 LLM을 기성품으로 사용한 다음(즉, 미세 조정 없이) 개인 "컨텍스트" 데이터에 대한 영리한 프롬프트 및 컨디셔닝을 통해 동작을 제어하는 것입니다.

 

예를 들어 법률 문서 집합에 대한 질문에 답하기 위해 챗봇을 구축한다고 가정해 보겠습니다. 순진한 접근 방식을 취하면 모든 문서를 ChatGPT 또는 GPT-4 프롬프트에 붙여넣은 다음 마지막에 이에 대해 질문할 수 있습니다.

 

이는 매우 작은 데이터 세트에 대해 작동할 수 있지만 확장되지는 않습니다. 가장 큰 GPT-4 모델은  수십페이지의 입력 텍스트만 처리할 수 있으며 컨텍스트 창이라고 하는 이 제한에 접근하면 성능(추론 시간 및 정확도로 측정)이 심하게 저하됩니다.

 

컨텍스트 내 학습은 영리한 트릭으로이 문제를 해결합니다 : 각 LLM 프롬프트와 함께 모든 문서를 보내는 대신 가장 관련성이 높은 문서 중 소수만 보냅니다.

 

데이터 전처리/임베딩: 이 단계에는 나중에 검색할 개인 데이터(이 예에서는 법률 문서)를 저장하는 작업이 포함됩니다. 일반적으로 문서는 청크로 나뉘어 임베딩 모델을 통과한 다음 벡터 데이터베이스라는 특수 데이터베이스에 저장됩니다.

프롬프트 생성/검색: 사용자가 쿼리(이 경우 법적 질문)를 제출하면 애플리케이션은 언어 모델에 제출할 일련의 프롬프트를 구성합니다. 컴파일된 프롬프트는 일반적으로 개발자가 하드 코딩한 프롬프트 템플릿을 결합합니다.

few-shot 예제라고 하는 유효한 출력의 예; 외부 API에서 검색된 모든 필수 정보 및 벡터 데이터베이스로부터 검색된 관련 문서들의 세트를 포함한다.프롬프트 실행/추론: 프롬프트가 컴파일되면 독점 모델 API와 오픈 소스 또는 자체 학습 모델을 포함하여 추론을 위해 사전 훈련된 LLM에 제출됩니다.
일부 개발자는 이 단계에서 로깅, 캐싱 및 유효성 검사와 같은 운영 체제도 추가합니다.

 

이것은 많은 작업처럼 보이지만 일반적으로 LLM 자체를 훈련하거나 미세 조정하는 것보다 쉽습니다.

컨텍스트 내 학습을 수행하기 위해 전문 ML 엔지니어 팀이 필요하지 않습니다. 또한 자체 인프라를 호스팅하거나 OpenAI에서 값비싼 전용 인스턴스를 구입할 필요가 없습니다.

 

이 패턴은 AI 문제를 대부분의 신생 기업과 대기업이 이미 해결 방법을 알고 있는 데이터 엔지니어링 문제로 효과적으로 축소합니다. 또한 LLM이 미세 조정을 통해 특정 정보를 기억하기 전에 훈련 세트에서 최소 ~ 10 번 발생해야하기 때문에 상대적으로 작은 데이터 세트에 대한 미세 조정을 능가하는 경향이 있으며 거의 실시간으로 새로운 데이터를 통합 할 수 있습니다.

 

컨텍스트 내 학습과 관련된 가장 큰 질문 중 하나는 컨텍스트 창을 늘리기 위해 기본 모델을 변경하면 어떻게 됩니까? 이것은 실제로 가능하며 활발한 연구 분야입니다

그러나 여기에는 여러 가지 절충안이 따르는데, 주로 추론 비용과 시간이 프롬프트의 길이에 따라 4차적으로 확장된다는 것입니다. 오늘날에는 선형 스케일링(최상의 이론적 결과)조차도 많은 응용 분야에서 비용이 많이 듭니다. 10,000페이지가 넘는 단일 GPT-4 쿼리는 현재 API 요금으로 수백 달러의 비용이 듭니다. 

 

LLM 앱의 컨텍스트 데이터에는 텍스트 문서, PDF 및 CSV 또는 SQL 테이블과 같은 구조화된 형식이 포함됩니다. 이 데이터에 대한 데이터 로딩 및 변환 솔루션은 우리가 이야기한 개발자마다 크게 다릅니다. 대부분 Databricks 또는 Airflow와 같은 기존 ETL 도구를 사용합니다.

 

일부는 LangChain(Unstructured 제공) 및 LlamaIndex(Llama Hub 제공)와 같은 오케스트레이션 프레임워크에 내장된 문서 로더를 사용하기도 합니다. 우리는 이 스택이 상대적으로 덜 개발되어 있다고 생각하며, LLM 앱을 위해 특별히 제작된 데이터 복제 솔루션에 대한 기회가 있습니다.

 

임베딩의 경우 대부분의 개발자는 OpenAI API, 특히 text-embedding-ada-002 모델과 함께 사용합니다.

 

사용하기 쉽고(특히 이미 다른 OpenAI API를 이미 사용하고 있는 경우) 합리적으로 좋은 결과를 제공하며 점점 더 저렴해지고 있습니다. 일부 대기업은 임베딩에 더 좁게 제품 노력을 집중하고 특정 시나리오에서 더 나은 성능을 제공하는 Cohere를 모색하고 있습니다.

 

오픈 소스를 선호하는 개발자에게는 Hugging Face의 Sentence Transformers 라이브러리가 표준입니다. 다양한 사용 사례에 맞는 다양한 유형의 임베딩을 만들 수도 있습니다. 이것은 오늘날 틈새 관행이지만 유망한 연구 분야입니다.

 

시스템 관점에서 전처리 파이프라인의 가장 중요한 부분은 벡터 데이터베이스입니다. 최대 수십억 개의 임베딩(즉, 벡터)을 효율적으로 저장, 비교 및 검색하는 역할을 합니다. 우리가 시장에서 본 가장 일반적인 선택은 Pinecone입니다. 완전히 클라우드에서 호스팅되어 쉽게 시작할 수 있고 대기업이 프로덕션에 필요한 많은 기능(예: 우수한 대규모 성능, SSO 및 가동 시간 SLA)을 갖추고 있기 때문에 기본값입니다.

 

Weaviate, Vesa 및 Qdrant와 같은 오픈 소스 시스템: 일반적으로 뛰어난 단일 노드 성능을 제공하고 특정 애플리케이션에 맞게 조정할 수 있으므로 맞춤형 플랫폼 구축을 선호하는 숙련된 AI 팀에게 인기가 있습니다.

Chroma 및 Faiss와 같은 로컬 벡터 관리 라이브러리: 뛰어난 개발자 경험을 제공하며 소규모 앱 및 개발 실험을 위해 쉽게 스핀업할 수 있습니다. 대규모로 전체 데이터베이스를 대체할 필요는 없습니다.

pgvector와 같은 OLTP 확장: 데이터베이스 형태의 모든 허점을 보고 Postgres를 삽입하려는 개발자 또는 단일 클라우드 공급자로부터 대부분의 데이터 인프라를 구입하는 기업에게 이 솔루션은 벡터 지원을 위한 좋은 솔루션입니다. 장기적으로 벡터 워크로드와 스칼라 워크로드를 긴밀하게 결합하는 것이 합리적인지 여부는 명확하지 않습니다.

 

 

앞으로 대부분의 오픈 소스 벡터 데이터베이스 회사는 클라우드 제품을 개발하고 있습니다. 우리의 연구에 따르면 가능한 사용 사례의 광범위한 설계 공간에서 클라우드에서 강력한 성능을 달성하는 것은 매우 어려운 문제입니다.

 

따라서 옵션 세트는 단기적으로는 크게 변경되지 않을 수 있지만 장기적으로는 변경될 가능성이 높습니다. 핵심 질문은 벡터 데이터베이스가 OLTP 및 OLAP와 유사하여 하나 또는 두 개의 인기 있는 시스템을 중심으로 통합되는지 여부입니다.

 

또 다른 열린 질문은 대부분의 모델에서 사용 가능한 컨텍스트 창이 증가함에 따라 임베딩 및 벡터 데이터베이스가 어떻게 발전할 것인가 하는 것입니다.

 

임베딩의 관련성이 낮아질 것이라고 말하고 싶은 것은 컨텍스트 데이터를 프롬프트에 직접 놓을 수 있기 때문입니다. 그러나 이 주제에 대한 전문가의 피드백은 임베딩 파이프라인이 시간이 지남에 따라 더 중요해질 수 있다는 반대를 시사합니다 .

 

큰 컨텍스트 창은 강력한 도구이지만 상당한 계산 비용도 수반합니다. 따라서 그것들을 효율적으로 사용하는 것이 우선 순위가 됩니다. 다양한 유형의 임베딩 모델이 대중화되고, 모델 관련성에 대해 직접 훈련되고, 이를 가능하게 하고 활용하도록 설계된 벡터 데이터베이LLM을 촉진하고 컨텍스트 데이터를 통합하기 위한 전략은 점점 더 복잡해지고 있으며 제품 차별화의 원천으로서 점점 더 중요해지고 있습니다.

 

대부분의 개발자는 직접 명령(제로 샷 프롬프트) 또는 몇 가지 예제 출력(몇 샷 프롬프트)으로 구성된 간단한 프롬프트를 실험하여 새 프로젝트를 시작합니다. 이러한 프롬프트는 종종 좋은 결과를 제공하지만 프로덕션 배포에 필요한 정확도 수준에는 미치지 못합니다.

 

주짓수를 자극하는 다음 단계는 일부 진실 소스에서 모델 응답을 접지하고 모델이 훈련되지 않은 외부 컨텍스트를 제공하도록 설계되었습니다. 프롬프트 엔지니어링 가이드는 생각의 사슬, 자기 일관성, 생성 된 지식, 생각의 나무, 방향 자극 및 기타 여러 가지를 포함하여 12 개 이상의 고급 프롬프트 전략을 분류합니다. 이러한 전략은 문서 질문 답변, 챗봇 등과 같은 다양한 LLM 사용 사례를 지원하기 위해 함께 사용할 수도 있습니다.

 

LangChain 및 LlamaIndex와 같은 오케스트레이션 프레임워크가 빛을 발하는 곳입니다. 그들은 프롬프트 체인의 많은 세부 사항을 추상화합니다. 외부 API와의 인터페이스(API 호출이 필요한 시점 결정 포함) 벡터 데이터베이스로부터 문맥 데이터를 검색하는 단계; 여러 LLM 호출에서 메모리를 유지합니다. 또한 위에서 언급한 많은 일반적인 응용 프로그램에 대한 템플릿을 제공합니다.

 

출력은 언어 모델에 제출하기 위한 프롬프트 또는 일련의 프롬프트입니다. 이러한 프레임워크는 앱을 시작하려는 애호가와 신생 기업 사이에서 널리 사용되며 LangChain이 선두 주자입니다.

 

LangChain은 아직 비교적 새로운 프로젝트(현재 버전 0.0.201)이지만 이미 이를 사용하여 빌드된 앱이 프로덕션으로 이동하는 것을 보기 시작했습니다. 일부 개발자, 특히 LLM의 얼리 어답터는 추가된 종속성을 제거하기 위해 프로덕션에서 원시 Python으로 전환하는 것을 선호합니다. 그러나 이 DIY 접근 방식은 기존 웹 앱 스택과 유사한 방식으로 대부분의 사용 사례에서 시간이 지남에 따라 감소할 것으로 예상합니다.

 

예리한 눈을 가진 독자는 오케스트레이션 상자에 겉보기에 이상한 항목인 ChatGPT를 발견할 것입니다. 일반적인 화신에서 ChatGPT는 개발자 도구가 아니라 앱입니다. 그러나 API로도 액세스할 수 있습니다. 그리고 눈을 가늘게 뜨면 다른 오케스트레이션 프레임워크와 동일한 기능 중 일부를 수행합니다. 상태 유지; 플러그인, API 또는 기타 소스를 통해 컨텍스트 데이터를 검색합니다.

 

여기에 나열된 다른 도구에 대한 직접적인 경쟁자는 아니지만 ChatGPT는 대체 솔루션으로 간주될 수 있으며 결국 신속한 구성에 대한 실행 가능하고 간단한 대안이 될 수 있습니다.

 

오늘날 OpenAI는 언어 모델의 선두 주자입니다. 우리가 이야기한 거의 모든 개발자는 일반적으로 gpt-4 또는 gpt-4-32k 모델과 함께 OpenAI API를 사용하여 새로운 LLM 앱을 시작합니다 . 이는 앱 성능에 대한 최상의 시나리오를 제공하며 광범위한 입력 도메인에서 작동하며 일반적으로 미세 조정 또는 자체 호스팅이 필요하지 않다는 점에서 사용하기 쉽습니다.

프로젝트가 프로덕션에 들어가고 확장되기 시작하면 더 광범위한 옵션이 작동합니다. 우리가 들었던 일반적인 것들 중 일부는 다음과 같습니다.

 

gpt-3.5-turbo로 전환: GPT-50보다 ~4배 저렴하고 훨씬 빠릅니다.
많은 앱에는 GPT-4 수준의 정확도가 필요하지 않지만 무료 사용자를 위한 짧은 대기 시간 추론과 비용 효율적인 지원이 필요합니다.
다른 독점 공급업체(특히 Anthropic의 Claude 모델)와의 실험: Claude는 빠른 추론, GPT-3.5 수준의 정확도, 대규모 고객을 위한 더 많은 사용자 정의 옵션 및 최대 100k 컨텍스트 창을 제공합니다(입력 길이에 따라 정확도가 저하되는 것으로 나타났지만).오픈 소스 모델에 대한 일부 요청 심사: 이는 쿼리 복잡성에 큰 차이가 있고 무료 사용자에게 저렴하게 서비스를 제공해야 하는 검색 또는 채팅과 같은 대용량 B2C 사용 사례에서 특히 효과적일 수 있습니다.
이는 일반적으로 오픈 소스 기본 모델을 미세 조정하는 것과 함께 가장 적합합니다. 이 글에서는 이 툴링 스택에 대해 자세히 다루지는 않지만, 점점 더 많은 엔지니어링 팀에서 Databricks, Anyscale, Mosaic, Modal, RunPod와 같은 플랫폼을 사용하고 있습니다.

 

Hugging Face 및 Replicate의 간단한 API 인터페이스를 포함하여 오픈 소스 모델에 다양한 추론 옵션을 사용할 수 있습니다.

 

주요 클라우드 공급자의 원시 컴퓨팅 리소스; 위에 나열된 것과 같은 더 많은 독단적 인 클라우드 제품.오픈 소스 모델은 현재 독점 제품을 뒤쫓고 있지만 격차가 좁혀지기 시작했습니다. Meta의 LLaMa 모델은 오픈 소스 정확도에 대한 새로운 기준을 세웠고 다양한 변형을 시작했습니다.

 

LLaMa는 연구용으로만 라이선스가 부여되었기 때문에 많은 새로운 제공업체가 대체 기본 모델(예: Together, Mosaic, Falcon, Mistral)을 교육하기 위해 개입했습니다. Meta는 또한 LLaMa 2의 진정한 오픈 소스 릴리스에 대해 논의하고 있습니다.

 

오픈 소스 LLM이 GPT-3.5에 필적하는 정확도 수준에 도달하면 미세 조정된 모델의 대규모 실험, 공유 및 생산을 포함하여 텍스트에 대한 안정적인 확산과 같은 순간을 볼 수 있을 것으로 기대합니다. Replicate와 같은 호스팅 회사는 이미 소프트웨어 개발자가 이러한 모델을 더 쉽게 사용할 수 있도록 도구를 추가하고 있습니다. 개발자들 사이에서는 더 작고 미세 조정된 모델이 좁은 사용 사례에서 최첨단 정확도에 도달할 수 있다는 믿음이 커지고 있습니다.

 

우리가 이야기한 대부분의 개발자들은 아직 LLM을 위한 운영 툴링에 대해 깊이 있게 다루지 않았습니다 . 캐싱은 일반적으로 Redis를 기반으로 하는 비교적 일반적인데, 이는 캐싱이 애플리케이션 응답 시간과 비용을 개선하기 때문입니다.

 

Weights & Biases 및 MLflow (기존 기계 학습에서 이식 됨) 또는 PromptLayer 및 Helicone (LLM 용으로 특별히 제작 됨)과 같은 도구도 상당히 널리 사용됩니다. 일반적으로 신속한 구성을 개선하고, 파이프라인을 조정하거나, 모델을 선택하기 위해 LLM 출력을 기록, 추적 및 평가할 수 있습니다. 또한 LLM 출력(예: 가드레일)을 검증하거나 즉각적인 주입 공격(예: Rebuff)을 감지하기 위해 여러 가지 새로운 도구가 개발되고 있습니다. 이러한 운영 도구의 대부분은 자체 Python 클라이언트를 사용하여 LLM 호출을 수행하도록 권장하므로 시간이 지남에 따라 이러한 솔루션이 어떻게 공존하는지 보는 것은 흥미로울 것입니다.

 

마지막으로, LLM 앱의 정적 부분(즉, 모델 이외의 모든 부분)도 어딘가에 호스팅되어야 합니다 . 지금까지 본 가장 일반적인 솔루션은 Vercel 또는 주요 클라우드 제공 업체와 같은 표준 옵션입니다. 그러나 두 가지 새로운 범주가 등장하고 있습니다. Steamship과 같은 스타트업은 오케스트레이션(LangChain), 멀티 테넌트 데이터 컨텍스트, 비동기 작업, 벡터 스토리지 및 키 관리를 포함하여 LLM 앱을 위한 엔드 투 엔드 호스팅을 제공합니다. 또한 Anyscale 및 Modal과 같은 회사는 개발자가 모델과 Python 코드를 한 곳에서 호스팅할 수 있도록 합니다.