신뢰할 수 있는 AI 앱을 설계하기 위한 LLM 개발원칙

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2024-07-28
2024-07-27
409

LLM(대규모 언어 모델)은 엄청난 잠재력을 가지고 있지만 신뢰할 수 있는 프로덕션 등급 애플리케이션을 개발하는 것은 여전히 어려운 일이다. LLM 기술이 본격적으로 등장한게 길어야 2년이니 어찌보면 당연하다고 할 수 있다. 게다가 너무 많은 모델들, 툴셋, 프레임워크 들이 개발되고 있어서 따라잡기에도 급급하다.

> LLM 네이티브 앱은 10% 정도가 모델작업이고 90%는 실험적인 데이터 기반 엔지니어링 작업이다.

LLM 앱 개발의 현실을 한 문장으로 표현하자면 그렇다. LLM 앱을 개발하하다 보면 테스트 -> 피드백 -> 테스트 -> 수정의 반복적인 작업이라는 것을 알 수 있다.

### LLM Triangle 원칙
LLM Triangle 원칙은 LLM 네티이브 앱을 구축하기 위한 가이드라인을 담고 있다. 이 원칙은 견고한 프레임워크를 제공하여 개발자가 견고하고 신뢰할 수 있는 LLM 네이티브 애플리케이션을 구축 할 수 있도록 방향을 제시한다.
![LLM Triangle 01](https://docs.google.com/drawings/d/e/2PACX-1vRP-NxiOk8Zq9FTYM8XyObvjd00uzL2uIfg8um5R4ozxlnD4x6NnbVJud8l1aNrG7fHFpwhd8oj7t6R/pub?w=1410&h=1000)

### 핵심 정점
LLM Triangle 원칙은 LLM 앱을 설계하고 구축하는데 도움이 되는 4가지 프로그램 원칙을 소개한다.

첫 번째 원칙은 표준운영절차(SOP)이다. SOP는 위 이미지의 "모델", "엔지니어링 기술", "문맥적 데이터"를 가이드한다. SOP 관점에서 이 3가지의 핵심 원칙을 지킬 경우 **고성능 LLM** 앱 개발을 보장한다.

## 표준운영절차(SOP)
표준운영절차(Standard Operationg Procedure)는 산업계에 잘 알려진 용어다. 이 절차는 대규모 조직에서 근로자가 일상적인 작업을 수행하면서도 매 배포마다 고품질과 (이전과)유사한 결과를 유지할 수 있도록 돕기 위한 지침들을 담고 있다. 자세한 지침을 작성하여 경험이 부족하거나 기술이 부족한 근로자를 전문가로 전환할 수 있도록 돕는 것이 핵심이다.

LLM Triangle 원칙은 SOP의 패러다임을 빌려서 **모델을 미숙련 근로자로 간주** 하도록 권장한다. 전문가가 작업을 수행하는 방법을 모델에 가르침으로써 더 높은 품질의 결과를 보장하도록 하는 것이다.

그렇다면 LLM에서 SOP를 효과적으로 구현하는데 도움이 되는 기술이 무엇인지를 파악해야 한다.

#### 인지 모델링
SOP를 수행하려면 가장 성과가 좋은 직원(도메인 전문가)를 데려와서 그들이 동일한 결과를 얻도록 그들이 하는 모든 일을 기록(측정)하고 생각하고 일하는 방식을 모델링 해야 한다.

이러한 과정을 마치면 경험이 부족하거나 기술이 부족한 근로자가 모두 뛰어난 성과를 낼 수 있는 자세한 지침을 받게 된다.

LLM 역시 인간과 마찬가지로 작업을 단순화하고 분할하여서 작업의 인지적 부하를 줄이는 것이 필수적이다.(LLM을 인간과 유사한 어떤 객체라고 보는 것이 흥미롭다). 길고 복잡한 절차보다 간단한 단계별 지침을 따르도록 하는 것이 더 간단하다.

이 과정에서 우리는 숨겨진 "암묵적 인지에 의한 점프"를 식별한다. 사람은 자신이 학습해서 이미 알고 있는 것은 건너 뛰는 경향이 있다. 이러한 경향은 무의식적으로 일어나는데, 특히 다른 사람에게 학습정보를 전달하는 경우 최종 결과에 상당한 영향을 미친다. 훌륭한 선수인데, 좋은 코치는 아닌 경우 이런 암묵적인지에 의한 점프 때문인 경우가 많다.

![암묵적 인지 점프](https://docs.google.com/drawings/d/e/2PACX-1vRWwrNmaTFTtlfm1sU7Z06URg_v-7gbXdYl7iywpyNC41PLfluO4G_ZAncDvu0V0MVwavOfjSo0KPvn/pub?w=831&h=276)

> 암묵적인지란 사람이 무의식적으로 또는 자신이 하고 있다는 것을 모른 채 하는 모든 일과 학습이다. 암묵적 인지의 한 예는 사람이 자전거를 배울 때이다. 처음에는 자전거를 타는데 필요한 기술을 배우고 있다는 것을 인지한다. 하지만 자전거 타는데 익숙해지면, 자전거를 타기 위해 수행하는 행동에 대해 생각할 필요가 없다.

예를 들어, SQL 분석가를 모델링하고 싶다고 가정해보자. 그들과 인터뷰를 가지고 아래와 같은 질문을 던져보자.
1. 비즈니스 문제를 분석해 달라는 요청을 받으면 어떻게 하나요 ?
2. 귀하의 솔류션이 요청에 부합하는지 어떻게 확인하나요 ?
3. <인터뷰 대상자에게 우리가 이해하는 과정을 반영>
4. 이 과정이 귀하의 프로세스를 정확히 반영하고 있습니다. <피드백 -> 수정>
5. 등

##### SQL 분석가의 인식 모델
![SQL 분석가의 인식모델](https://docs.google.com/drawings/d/e/2PACX-1vRS6TVvUFjTNLCnAaGvG8W3T833fpbAUID5_d244kmDXwFNTVXm2fsg6L3UY8oH8eOMrz96GzgjxHp0/pub?w=930&h=623)
암묵적인지 과정은 여러 가지 모양과 형태를 취한다. 전형적인 예는 "도메인에서 사용하는 정의(혹은 용어)"다. 예를 들어 "베스트셀러"는 도메인 전문가에게는 당연한 용어겠지만 다른 사람들에게는 그렇지 않을 수 있다. 따라서
1. 베스트셀러 작가를
2. 해당 월에 가장 많은 책을 판매한 작가
로 다시 써야 한다. 이렇게 해서 우리는 초보자라고 하더라도 전문 분석가를 따라할 수 있는 SOP 레시피를 갖게 됐다.

이러한 프로세스는 복잡해 질 수 있는데 그래프로 시각화하면 이해하는데 도움이 될 수 있다. 특히 프로세스가 미묘하고 많은 단계, 조건, 분기를 포함할 때 유용하다.

![](https://docs.google.com/drawings/d/e/2PACX-1vQjREEMWPsq38yEDPf9y9W4ita2WPq9abyZFIuV7KcHPm9Ub7ZJ98ok9aaQKYK8U734bQTA8JfO7efi/pub?w=760&h=668)

최종 솔류션은 SOP에 정의된 단계를 모방해야 한다. 여기에서는 구현은 하지 않을 것이다. 나중에 솔류션 전체에서 하나 이상의 단계/체인으로 구현할 수 있을 것이다.

코드를 작성하기 전에 프로세스를 모델링하는 것이 좋다. 그리고 구현하는 동안 새로운 통찰력, 이해 수준이 높아짐에 따라서 프로세스를 변경 할 수 있을 것이다.

이제 문제에 대한 비즈니스 이해를 뒷받침하는 잘 정의된 SOP를 만드는 것이 중요하다는 것을 알았다. 이제 다양한 엔지니어링 기법을 사용하여 SOP를 효과적으로 구현하는 방법을 알아보겠다.

### 엔지니어링 기술
SOP를 실질적으로 구현하기 위해서는 엔지니어링이 필요하다. 일부 엔지니어링은 **프롬프트 계층**에서만 구현되지만 많은 기술들이 효과적으로 적용되기 위해서는 소프트웨어 계층 혹은 두 계층을 결합해야 한다.

![엔지니어링 기술 레이어](https://docs.google.com/drawings/d/e/2PACX-1vQ6zp6ymFdD-EczvGpmBgRTL3bRE9cY5QxA36BAxTCTEgoKDYiPDWsDwefJjKur8v4D1GSAyMZXTbQ1/pub?w=662&h=495)

#### LLM 네이티브 아키텍처
LLM 네이티브 아키텍처는 앱이 결과를 도축하기 위해 거치는 에이전트 흐름을 설명한다.

흐름의 각 단계는 작업을 달성하기 위해서 실행해야 하는 독립형 실행 프로세스이다. 일부 단계는 단순한 결정적 코드가 수행되고 일부 단계에서는 LLM 에이전트를 사용한다.

이를 위해서 우리가 작성한 표준 운영 절차를 어떻게 적용해야 할지 되돌아봐야 한다.

1. 각 SOP 단계에 어떤 에이전트를 붙여야 하는가 ? 에이전트 수행을 위해서 각 단계를 나눠야 할지
2. 어떤 SOP 단계를 단독으로 실행 해야 하는가 ? (하지만 이전 단계의 정보가 필요 할 수도 있다.)
3. 결정론적 코드에서 어떤 SOP 단계를 수행 할 수 있는가

![LLM Native Architecture](https://docs.google.com/drawings/d/e/2PACX-1vTBl3KM0dhF_WLwmsL_NUa1F9VA66oi8PpOmYal5a_5gPLfrLOAuC05fPLdpa9pRVWcqdZGtqgub4VI/pub?w=945&h=681)

* 입력 및 출력
* 품질 보증: 응답을 **충분히 좋은 것**으로 만드는 것은 무엇인가 ? 흐름에 인간의 개입이 필요한 단계가 있는가.
* 자율적 수준: 결과의 품질에 대해서 얼마나 많은 제어가 필요한가. 
* 트리거: 다음 단계는 무엇인가? 다음 단계를 실행하는 것은 무엇인가 ?
* 비기능적: 대기시간은 얼마인가 ? 여기에 모니터링이 필요한가 ?
* 장애 조치: 어떤 종류의 장애가 있는가 ? 장애에 어떻게 대응해야 하는가 ?
* 상태관리: 상태관리 매커니즘이 필요한가 ? 어떻게 상태를 저장하고 검색하는가(인덱스 키를 정의해야 하나?)? 저장소가 필요한가 ? 상태는 어떤 목적으로 사용하는가 ?(캐시, 로깅 등?)

#### 에이전트란 무엇인가 ?
LLM 에이전트는 LLM을 호출하는 LLM 네이티브 아키텍처의 독립적인 실행 구성요소이다.

LLM 에이전트의 대표적인 예는 컨텍스트를 포함하는 프롬프트로 LLM을 실행하는 것이다. 에이전트들은 모두 다를 수 있다. 일부는 툴을 사용하고 일부는 그렇지 않을 수 있다. 일부는 흐름에서 한번 사용될 수 있고, 재귀적으로 여러번 사용되면서 입력과 출력을 전달할 수 있다.

#### 도구를 갖춘 에이전트
일부 LLM 에이전트는 계산이나 웹 검색같은 작업을 위해서 미리 정의된 기능인 "도구"를 사용 할 수 있다. 에이전트는 도구와 입력을 설정하는 지침을 전달하고 애플리케이션은 이를 실행하고 결과를 에이전트에게 반환한다.

이 개념을 이해하기 위해서 도구 호출을 하는 간단한 프롬프트 구현을 살펴보자. 이는 도구를 호출하도록 훈련되지 않은 모델에서도 작동 할 수 있다.

```
당신은 아래 툴들을 사용 할 수 있는 조수 입니다. 
 - calculate(expression: str)  -> 수학적 표현식을 계산합니다. 
 - search(query: str) -> str -  인벤토리에서 아이템을 계산합니다. 입력이 주어지면

입력이 주어지면 YAML 형식으로 key와 함께 응답합니다: "func"(str) 과 "arguments"(map) 혹은 "message"(str).주이진 입력
```

도구를 갖춘 에이전트(도구를 가지고 있으므로 자율적인 에이전트다)와 결과를 통해 작업을 수행할 수 있는 에이전트를 구별하는 것이 중요하다.

> 자율적 에이전트는 작업을 완료하는 방법을 생성할 수 있는 능력을 가진 에이전트다.

자율 에이전트는 자신이 행동을 해야 하는지, 어떤 행동을 해야 하는지 결정할 권리가 주어진다. 비 자율 에이전트는 우리의 요청(예: 분류)를 처리하고 이 프로세스를 기반으로 결정적 코드가 수행한다. 모델은 그것에 대한 제어권이 전혀 없다.

![LLM 에이전트](https://docs.google.com/drawings/d/e/2PACX-1vSIq6-g1HC7cpptArRIpgG-hjuqGSkz2i01Vb3Ys3WBrqajlM07HdStNPdqlVyIZnRRbDMR6BhIlhgu/pub?w=1162&h=950)

작업계획에서 에이전트의 자율성을 높이면, 그들의 의사결정 능력을 이용 할 수 있지만 잠재적으로 출력 품질에 대한 통제력이 감소할 수 있다. LLM의 능력에 맡기기 때문에 편리하고 스마트하게 보일 수 있지만 품질에 대한 통제력을 잃는 대가를 치를 수 있다.

| 자율 에이전트         | 정교한 흐름 관리        |
| --------------- | ---------------- |
| ? 자유로운 사용      | ? 지속가능한 품질      |
| ? 빠른 빌드(비용 감소) | ? 예측 가능한 프로세스   |
| ? 디버깅의 어려움     | ? 높은 디버깅 수준     |
| ? 품질관리의 어려움    | ? 수작업 필요(비용 증가) |
완전 자율 에이전트의 유혹에 주의해야 한다. 아키텍처가 매력적이고 단순해 보일 수 있으며, PoC 단계에서는 잘 작동하는 것 처럼 보일 수 있지만 "실제 프로덕션 환경에서는" 그렇지 않을 확률이 매우 높다. 자율 에이전트는 디버깅 하기 어렵고 예측 할 수 없다. 프로덕션 환경에서는 완전 자율 에이전트를 사용할 수 없다.

왜냐하면 지금의 모델은 명확한 지침이 없이는 복잡한 프로세스를 계획하는데 그다지 능숙하지 않으며, 일반적인 필수 단계를 건너뛰기 때문이다. 왜를 들어 "위키피디아 작상자"사용 사례에서 그들은 체계적인 프로세스를 건너뛰고 그냥 쓰기 시작 할 건데, 원하는 결과를 얻기 힘들 것이다.

에이전트에게 모든 것을 맡기는 대신에, SOP의 영역에 그들의 작업을 분산시키도록 하자. 이렇게 하면 두 개의 세계를 통합해서 더 높은 품질의 결과를 얻을 수 있다.

**AlphaCodium**은 훌륭한 사례다. 이들은 구조화된 흐름과 다양한 에이전트(코드를 작성하고 테스트하는 에이전트를 포함)를 결합하여 CodeContest에서 GPT-4의 정확도(pass@5)를 19%에서 44%로 높였다.

## 모델
우리가 선택하는 모델은 프로젝트 성공의 중요한 요소이다. GPT-4나 Claude Opus는 더 나은 결과를 낼 수 있지만 더 많은 비용이 들 수 있으며, 작은 모델은 덜 똑똑하지만 예산을 절약할 수 있다. 모델을 선택할 때 우리는 달성해야 하는 목표와 제약사항을 파악해서 어떤 종류의 모델을 사용해야 할지 결정해야 한다.

> 모든 LLM이 동등하게 만들어진 것은 아니다. 모델을 미션에 맞춰보세요.

진실은 항상 가장 큰 모델이 필요한 것은 아니라는 것이다. 이는 작업에 따라서 달라진다. 적절한 모델을 찾기 위해서는 실험적 프로세스가 있어야 하며 솔류션의 여러 변형을 시도해야 한다.

**경험이 부족한 근로자**도 필요하다는 것을 생각하면 문제 해결에 도움이 된다. 높은 학력을 가진 매우 똑똑한 근로자는 어떤 업무도 쉽게 해낼 수 있을 것이지만, 요구 하는 이상으로 뛰어날 수 있으며, 이 때는 **더 저렴한** 지원자를 고용하는 것이 훨씬 더 비용 효율적일 것이다. 그리고 실제 세상은 이렇게 돌아간다.

즉 모델을 고려할 때, 우리는 비용, 기능, 품질의 측면에서 트레이드오프하여 솔루션을 정의하고 비교해야 한다. 
1. 작업 복잡성: 요약등의 간단한 작업은 작은 모델로 완료할 수 있지만 추론에는 일반적으로 더 큰 모델이 필요하다.
2. 추론 인프라: 클라우드에서 실행해야 할지, 엣지에서 실행해야 할지 선택한다. 
3. 가격 정책: 허용 할 수 있는 가격 수준을 고려한다. 비즈니스에 주는 영향을 고려했을 때, 비용 효율적인지 검토 한다.
4. 지연 시간: 모델이 커질수록 지연 시간도 늘어난다.
5. 레이블이 지정된 데이터: 즉시 사용 할 수 있는 예제나 관련 데이터들이 있는지

많은 경우 "사내 전문성"을 갖추기 전에는 경험이 풍부한 근로자에게(프리랜서, 컨설턴트 등) 비용을 지불하는 것이 도움이 된다. LLM도 마찬가지다.

레이블이 지정된 데이터가 없는 경우, 더 강력한 모델로 시작하여 데이터를 수집한 다음, 몇 가지 샷이나 미세 조정을 통해 모델을 강화하는데 활용한다.

#### 모델 미세 조정
모델을 미세 조정하기 전에 고려해야 할 몇 가지 측면이 있다.
* 개인정보 보호: 데이터에는 모델에서 제외해야 하는 개인 정보가 포함될 수 있다. 규제, 법적 책임을 피하기 위해 데이터를 익명화해야 한다.
* 법률, 규정 준수 및 데이터 관리: 모델을 학습할 때 몇 가지 법적 문제가 발생할 수 있다. 예를 들어 OpenAI 이용 약관 정책은 OpenAI가 생성된 응답을 사용하지 않고 모델을 학습하는 것을 금지한다. 또한 사용자가 회사에 정보를 제거하도록 요구할 수 있는 GDPR 법률을 준수여부 등 모델 학습에 따른 법적 문제를 야기 할 수 있다.
* 업데이트 지연: 모델의 학습 주기에 따른 지연이 발생 할 수 있다. 새 정보를 임베드하는 방식은 즉각적인 정보를 제공하는 반면, 모델을 학습하는 것은 시간이 걸리는 긴 프로세스다. 이로 인해 모델이 학습하는 빈도가 줄어들고 이는 최신 정보에 대한 접근을 어렵게 만든다.
* 개발 및 운영: 재현 가능, 확장 가능하고 모니터링 되는 미세 조정 파이프라인을 구현하고 결과를 지속적으로 관리하고 평가하는 복잡한 프로세스가 필요하다. 
* 비용: 미세 조정에는 학습을 위한 GPU 집약작업이 필요하다. 여기에는 많은 비용이 들어간다.

LLM이 **맥락 내 학습자**로 행동할 수 있는 능력, 그리고 LLM이 더 큰 context window를 지원한다는 사실은 많은 경우 미세조정이 없이도 뛰어난 결과를 제공할 수 있다는 의미다. 미세 조정의 복잡성으로 인해 마지막 수단으로 사용하거나 완전히 건너뛰는 것이 좋다.

반대로 특정작업(예: 구조화된 JSON 출력)도는 도메인별 언어에 대한 미세 조정 모델은 매우 효과적일 수 있다. 작은 크기의 도메인 전용 모델은 효과적일 수 있으며, 대규모 LLM 보다 저렴할 수 있다.

### 문맥 데이터
**LLM은 맥락 내 학습자이다.** 즉, LLM 에이전트는 작업별 정보를 제공함으로써, 특별한 훈련이나 미세 조정 없이도 과제를 수행 할 수 있다. 이를 통해서 새로운 지식이나 기술을 쉽게 "가르칠" 수 있다. **맥락적 데이터 원칙** 관점에서 우리는 사용 가능한 데이터를 구성하고 모델링하고 프롬프트 내에서 구성하는 방법을 목표로 해야 한다.

컨텍스트를 구성하기 위해서 보통 LLM에 보내는 프롬프트에 컨텍스트를 포함시킨다. 사용 할 수 있는 컨텍스트에는 두 가지 종류가 있다.

**내장된 컨텍스트** - 프롬프트의 일부로 제공되는 내장된 정보 조각

```
Your are the helpful assistant of <name>, a <role> at <company>
```

**첨부된 컨텍스트** - 프롬프트의 시작 혹은 끝에 붙는 정보 조각 목록

```
Summarize the provided emails while keeping a friendly tone.
---
  
<email_0>  
<email_1>
```

컨텍스트는 일반적으로 "프롬프트 템플릿"(예: jinja2, mustache 또는 단순 네이티브 포맷팅 문법 문자열)을 사용하여 구현한다. 이런 방식으로 프롬프트의 본질을 유지하면서 우아하게 구성 할 수 있다.

```
# 첨부 컨텍스트가 포함된 임베디드 컨텍스트
prompt = f"""  
You are the helpful assistant of {name}. {name} is a {role} at {company}.  
  
Help me write a {tone} response to the attached email.  
Always sign your email with:  
{signature}  
  
---  
  
{email}  
"""

```

#### Few-shot 러닝
Few-shot 러닝은 광범위한 미세 조정 없이도 "예를 들어" LLM을 가르치는 방법이다. 프롬프트에 몇 가지 대표적인 예를 제공하여 모델에게 원하는 형식, 스타일, 작업을 이해시킬 수 있다.

예를 들어, LLM이 이메일 응답을 생성하기를 원한다면, 프롬프트에 잘 쓰여진 응답의 몇 가지 예를 포함할 수 있다. 이렇게 하면 모델이 선호하는 구조와 톤을 학습하는데 도움이 된다.

애플리케이션이 커짐에 따라 각 입력에 대해 가장 관련성 있는 예제를 프로그래밍 방식으로 선택하는 "동적 few-shot"을 구현하는 것을 고려 할 수 있다. 구현 복잡성이 증가하지만 모델이 각 사례에 가장 적합한 지침을 받도록 하여 비용이 많이 드는 미세조정 없이 작업 성능을 개선 할 수 있다.

#### RAG
RAG(검색증강생성)응 응답을 생성하기 전에 관련 문서를 검색해서 추가 컨텍스트를 모델에 제공하는 기술이다. LLM에 답변을 생성하는데 도움이 되는 참조 자료를 제공하는 것과 같다. 이렇게 하면 모델을 다시 학습할 필요 없이 응답을 최신상태로 유지 할 수 있다.

예를 들어 고객 지원 챗볼 애플리케이션에서 RAG는 헬프데스크 위키페이지의 내용을 조회해서 LLM을 통해서 응답을 할 수 있다.

이 접근 방식은 LLM이 최신의 상태를 유지하고 검색된 사실을 근거로 응답하면서 환각을 크게 줄일 수 있다. RAG는 전체 모델을 재교육하지 않고도 업데이트되는 정보와 전문 도메인 정보가 필요한 작업에 특히 유용하다.

RAG를 구현하는 동안 고려해야 할 핵심 요소는 아래와 같다.
* 검색 메커니즘: RAG는 일반적으로 벡터 유사성 검색을 사용해서 문서를 검색하지만 키워드 기반 검색 (BM-25 등)과 같은 간단한 방법을 사용하는 것이 더 좋을 수 있다.
* 색인화된 데이터 구조: 사전 처리 없이 전체 문서를 색인하면 검색 프로세스의 효과가 제한될 수 있다. 때로는 문서에 기반한 질문과 답변 목록을 준비하는 등의 단계를 추가해야 할 수 있다.
* 메타데이터: 메타 데이터를 저장하면 정보를 보다 효율적으로 참고하고 필터링 할 수 있다. 예를 들어 위키 페이지에 "제품 종류, 저자, 페이지 생성일" 등의 정보를 추가하면, 필터링을 통해서 검색 프로세스를 간소화하고 검색범위를 명확히 하여 품질을 높일 수 있다.

#### 관련 컨텍스트 제공
에이전트와 관련된 컨텍스트 정보는 다양 할 수 있다. 이런 컨텍스트 정보는 유익할 수 있지만 미숙련 노동자인 LLM에 너무 많은 정보를 제공하면, 오히려 응답 품질이 떨어질 수 있다. 이론적으로 모델에 관련 없는 정보들을 학습하게 하면 혼란과 환각으로 이어질 수 있다.

프롬프트를 압축하고 LLM 에이전트에 "관련 정보"만 제공하는 것이 중요하다. 이렇게 하면 토큰의 크기를 줄일 수 있으며, 품질이 향상되고, 대기 시간이 최적화 되며 비용이 절감된다.

### 정리
LLM Triangle 원칙은 고품질 LLM 네이티브 애플리케이션을 개발하는데 구조화된 접근 방식을 제공하여 LLM의 잠재력과 실제 구현 간의 격차를 해소한다. 개발자는 잘 정의된 SOP에 따라서 모델, 엔지니어링 기술, 문맥적 데이터에 집중하여 보다 안정적이고 효과적인 LLM 기반 솔류션을 만들 수 있다.

1. 명확한 SOP로 시작한다: 전문가의 인지 과정을 모델링하여 LLM 지원에 대한 단계별 가이드를 만든다.
2. 올바른 모델의 선택: 기능과 비용의 균현을 맞춘다. 세부적으로 조정된 모델로 전환하기 전에 큰 모델부터 시작하는 것을 고려한다.
3. 엔지니어링 기법 활용: LLM 네이티브 아키텍처를 구현하고 에이전트를 전략적으로 사용하여 성능을 최적화하고 제어를 유지한다. 다양한 프롬프트 기법을 실험하여 사례에 가장 효과적인 프롬프트를 찾는다.
4. 관련성 있는 맥락제공: 관련성 없는 정보로 모델을 압도하지 않도록 주의하여서 RAG를 구성한다.
5. 반복과 실험: 올바른 솔루션을 찾으려면 작업을 테스트하고 수정하고 개발하는 사이클을 반복해야 한다.

## 참고
 * [The LLM Triangle Principles to Architect Reliable AI Apps](https://medium.com/towards-data-science/the-llm-triangle-principles-to-architect-reliable-ai-apps-d3753dd8542e)

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories