1년 동안 LLM과 함께 구축하며 배운 점

(eugeneyan.com)

75P by xguru 5달전 | favorite | 댓글 9개

대규모 언어 모델(LLM)을 사용한 개발이 흥미로운 시기임
- 지난 1년 동안 LLM이 실제 애플리케이션에 "충분히 좋은" 수준이 되었으며, 매년 더 좋아지고 저렴해지고 있음
- 소셜 미디어의 데모와 함께, 2025년까지 AI에 약 2000억 달러가 투자될 것으로 추정됨
- 업체들의 API로 인해 LLM이 더 접근하기 쉬워져, ML 엔지니어와 과학자뿐만 아니라 모두가 제품에 인텔리젠스를 구축할 수 있게 됨
AI로 구축하는 진입 장벽은 낮아졌지만, 데모 이상으로 효과적인 제품과 시스템을 만드는 것은 여전히 어려움
우리는 지난 1년 동안 구축해 왔으며, 그 과정에서 많은 어려움을 발견했음
- 우리의 실수를 피하고 더 빠르게 반복할 수 있도록 우리가 배운 내용을 공유하고자 함
이 글은 세 부분으로 구성됨:
1. Tactical(전술적): 프롬프팅, RAG, 워크플로우 엔지니어링, 평가 및 모니터링을 위한 몇 가지 실천 사항
  - LLM으로 구축하는 실무자나 주말 프로젝트를 진행하는 사람들을 위해 작성됨
2. Operational(운영적): 제품 출시의 조직적, 일상적 관심사와 효과적인 팀 구축 방법
  - 지속 가능하고 안정적으로 배포하려는 제품/기술 리더를 위한 내용
3. Strategic(전략적): "PMF 전에 GPU 없음", "모델이 아닌 시스템에 집중" 등의 의견을 담은 장기적이고 큰 그림 관점과 반복하는 방법
  - 창업자와 경영진을 염두에 두고 작성됨
이 가이드는 LLM을 사용하여 성공적인 제품을 구축하기 위한 실용적인 안내서가 되는 것을 목표로 함
- 우리 자신의 경험에서 비롯되었으며 업계 전반의 사례를 제시함

[전술: LLM 사용의 핵심]

이 섹션에서는 새로 등장하는 LLM 스택의 핵심 구성 요소에 대한 모범 사례를 공유함
- 품질과 신뢰성을 높이기 위한 프롬프팅 팁, 출력을 평가하기 위한 전략, 그라운딩을 개선하기 위한 검색 증강 생성 아이디어 등이 포함됨
- 또한 휴먼 인 더 루프 워크플로우를 설계하는 방법도 탐구할 예정임

전술 1. 프롬프팅

새로운 애플리케이션을 개발할 때는 프롬프팅으로 시작할 것을 권장함
- 프롬프팅의 중요성을 과소평가하거나 과대평가하기 쉬움
- 올바른 프롬프팅 기술을 제대로 사용하면 매우 멀리 갈 수 있기 때문에 과소평가되는 경향이 있음
- 프롬프트 기반 애플리케이션도 제대로 작동하려면 프롬프트 주변에 상당한 엔지니어링이 필요하기 때문에 과대평가되는 경향이 있음

기본 프롬프팅 기술을 최대한 활용하는 데 집중

다양한 모델과 작업에서 성능 향상에 지속적으로 도움이 되는 몇 가지 프롬프팅 기술이 있음
- N-shot 프롬프트 + 문맥 내 학습, 사고의 연쇄(Chain-of-Thought), 관련 리소스 제공 등임
N-shot 프롬프트와 문맥 내 학습
- N-shot 프롬프트를 통한 문맥 내 학습의 아이디어는 LLM에게 작업을 시연하고 출력을 기대에 맞추는 몇 가지 예시를 제공하는 것임
- N이 너무 낮으면 모델이 해당 특정 예시에 과도하게 고정되어 일반화 능력이 저하될 수 있음
- 경험적으로 N ≥ 5를 목표로 하고, 수십 개까지 사용하는 것을 두려워하지 말 것
- 예시는 예상되는 입력 분포를 대표해야 함
- 전체 입출력 쌍을 제공할 필요는 없으며, 많은 경우 원하는 출력의 예시로 충분함
- 도구 사용을 지원하는 LLM을 사용하는 경우, N-shot 예시에서도 에이전트가 사용하기를 원하는 도구를 사용해야 함
사고의 연쇄(Chain-of-Thought, CoT) 프롬프팅
- CoT 프롬프팅에서는 LLM이 최종 답변을 반환하기 전에 사고 과정을 설명하도록 장려함
- LLM에게 메모리에서 모든 것을 수행할 필요가 없도록 스케치패드를 제공하는 것으로 생각할 수 있음
- 원래 접근 방식은 단순히 "단계별로 생각해 보자"라는 문구를 지침의 일부로 추가하는 것이었지만, CoT를 더 구체적으로 만드는 것이 도움이 된다는 것을 발견함
- 1~2문장으로 구체성을 추가하면 환각 발생률이 상당히 감소하는 경우가 많음
- 최근에는 이 기술이 믿는 만큼 강력한지에 대해 의문이 제기되고 있음
- 또한 CoT가 사용될 때 추론 중에 정확히 어떤 일이 일어나는지에 대해 상당한 논쟁이 있음
- 그럼에도 불구하고 가능한 경우 실험해 볼 만한 기술임
관련 리소스 제공
- 관련 리소스를 제공하는 것은 모델의 지식 기반을 확장하고, 환각을 줄이며, 사용자의 신뢰를 높이는 강력한 메커니즘임
- 검색 증강 생성(Retrieval Augmented Generation, RAG)을 통해 수행되는 경우가 많음
- 모델에 응답에 직접 활용할 수 있는 텍스트 스니펫을 제공하는 것은 필수적인 기술임
- 관련 리소스를 제공할 때는 단순히 포함하는 것으로는 충분하지 않음
  - 모델에게 리소스 사용을 우선시하고, 직접 참조하며, 때로는 리소스가 충분하지 않을 때 언급하도록 지시하는 것을 잊지 말아야 함
- 이러한 것들은 에이전트 응답을 리소스 코퍼스에 "Ground"하는 데 도움이 됨

입력과 출력 구조화

구조화된 입력과 출력은 모델이 입력을 더 잘 이해하고 다운스트림 시스템과 안정적으로 통합할 수 있는 출력을 반환하는 데 도움이 됨
- 입력에 직렬화 형식을 추가하면 컨텍스트의 토큰 간 관계, 특정 토큰에 대한 추가 메타데이터(유형 등) 또는 요청을 모델 학습 데이터의 유사한 예시와 관련시키는 데 도움이 될 수 있음
- 예를 들어, 인터넷에서 SQL 작성에 대한 많은 질문은 SQL 스키마를 지정하는 것으로 시작함
  - 따라서 Text-to-SQL에 대한 효과적인 프롬프팅에는 구조화된 스키마 정의가 포함되어야 함
구조화된 출력은 유사한 목적을 수행하지만, 시스템의 다운스트림 구성 요소로의 통합을 단순화함
- Instructor와 Outlines는 구조화된 출력에 잘 작동함
  - (LLM API SDK를 가져오는 경우 Instructor를 사용하고, 자체 호스팅 모델에 Huggingface를 가져오는 경우 Outlines를 사용)
- 구조화된 입력은 작업을 명확하게 표현하고 학습 데이터의 형식과 유사하므로 더 나은 출력 가능성을 높임
구조화된 입력을 사용할 때는 각 LLM 제품군마다 선호하는 방식이 있다는 점에 유의해야 함
- Claude는 <xml>을 선호하는 반면 GPT는 Markdown과 JSON을 선호함
- XML을 사용하면 <response> 태그를 제공하여 Claude의 응답을 미리 채울 수도 있음

작고 한 가지 일을 잘하는 프롬프트를 만들 것

소프트웨어에서 흔한 안티 패턴/코드 스멜은 모든 것을 수행하는 단일 클래스나 함수인 "God Object"임
- 이는 프롬프트에도 동일하게 적용됨
프롬프트는 일반적으로 간단하게 시작함
- 몇 문장의 지침, 몇 가지 예시로 시작할 수 있음
- 그러나 성능을 개선하고 더 많은 edge case를 처리하려고 하면서 복잡성이 증가함
  - 더 많은 지침, 다단계 추론, 수십 개의 예시 등이 추가됨
- 결국 처음에는 단순했던 프롬프트가 2,000 토큰의 프랑켄슈타인이 되어버림
  - 게다가 더 일반적이고 직관적인 입력에 대한 성능은 오히려 저하됨
  - GoDaddy는 이 문제를 LLM 구축에서 얻은 교훈 중 1위로 꼽음
시스템과 코드를 단순하게 유지하려고 노력하는 것처럼, 프롬프트도 마찬가지여야 함
- 회의 녹취록 요약기에 대해 단일 만능 프롬프트를 사용하는 대신, 다음과 같은 단계로 나눌 수 있음
  - 주요 결정 사항, 조치 항목 및 담당자를 구조화된 형식으로 추출
  - 추출된 세부 정보를 원본 녹취록과 비교하여 일관성 확인
  - 구조화된 세부 정보에서 간결한 요약 생성
결과적으로 단일 프롬프트를 여러 개의 단순하고 집중적이며 이해하기 쉬운 프롬프트로 분할함
- 이렇게 분할하면 이제 각 프롬프트를 개별적으로 반복하고 평가할 수 있음

컨텍스트 토큰 만들기

에이전트에 실제로 전송해야 하는 컨텍스트의 양에 대한 가정을 재고하고 도전해야 함
- 미켈란젤로처럼 컨텍스트 조각상을 만들어 가는 것이 아니라, 불필요한 재료를 깎아내어 조각상을 드러내야 함
- RAG는 잠재적으로 관련된 대리석 블록을 모두 모으는 데 널리 사용되는 방법이지만, 필요한 것을 추출하기 위해 무엇을 하고 있는가?
모델에 전송되는 최종 프롬프트를 가져와 모든 컨텍스트 구성, 메타 프롬프팅, RAG 결과와 함께 빈 페이지에 배치하고 읽어보는 것이 컨텍스트를 재고하는 데 도움이 된다는 것을 발견함
- 이 방법을 사용하여 중복, 자가 모순적인 언어 및 형식이 잘못된 부분을 발견할 수 있음
다른 핵심 최적화는 컨텍스트의 구조임
- Bag-of-docs 표현은 인간에게 도움이 되지 않으므로 에이전트에게 좋다고 가정하지 말아야 함
- 컨텍스트의 각 부분 간의 관계를 강조하고 추출을 가능한 한 단순하게 만들 수 있도록 컨텍스트를 구성하는 방법을 신중하게 고려해야 함

전술 2. 정보 검색 / RAG

프롬프팅 외에도 LLM을 조정하는 또 다른 효과적인 방법은 프롬프트의 일부로 지식을 제공하는 것임
- 이는 제공된 컨텍스트에 LLM을 ground시키며, 이는 문맥 내 학습에 사용됨
- 이를 검색 증강 생성(Retrieval-Augmented Generation, RAG)이라고 함
- 실무자들은 RAG가 지식을 제공하고 출력을 개선하는 데 효과적이며, 미세 조정에 비해 훨씬 적은 노력과 비용이 든다는 것을 발견함
- RAG는 검색된 문서의 관련성, 밀도 및 세부 정보만큼만 좋음

RAG 출력의 품질은 검색된 문서의 품질에 따라 달라지며, 몇 가지 요소를 고려할 수 있음

첫 번째이자 가장 명백한 척도는 "관련성"
- 이는 일반적으로 평균 역순위(Mean Reciprocal Rank, MRR) 또는 정규화된 할인 누적 이득(Normalized Discounted Cumulative Gain, NDCG)과 같은 순위 지표로 정량화됨
- MRR은 시스템이 순위 목록에서 첫 번째 관련 결과를 얼마나 잘 배치하는지 평가하는 반면, NDCG는 모든 결과의 관련성과 위치를 고려함
- 이들은 관련 문서를 더 높이, 관련 없는 문서를 더 낮게 순위를 매기는 시스템의 성능을 측정함
- 예를 들어, 영화 리뷰 요약을 생성하기 위해 사용자 요약을 검색하는 경우, 특정 영화에 대한 리뷰를 더 높이 순위를 매기고 다른 영화에 대한 리뷰는 제외하는 것이 좋음
- 전통적인 추천 시스템과 마찬가지로 검색된 항목의 순위는 LLM이 다운스트림 작업을 수행하는 방식에 상당한 영향을 미침
- 영향을 측정하려면 검색된 항목을 섞은 상태에서 RAG 기반 작업을 실행해 보고, RAG 출력이 어떻게 수행되는지 확인할 것
두번째로 "정보 밀도"
- 두 문서가 동일하게 관련된 경우, 더 간결하고 관련 없는 세부 정보가 적은 문서를 선호해야 함
- 영화 예로 돌아가면, 영화 대본과 모든 사용자 리뷰를 광범위한 의미에서 관련이 있다고 간주할 수 있음
- 그럼에도 불구하고 높은 평가를 받은 리뷰와 편집 리뷰는 정보 밀도가 더 높을 가능성이 있음
마지막으로, 문서에 제공된 "세부 정보 수준"을 고려할 것
- 자연어에서 SQL 쿼리를 생성하기 위한 RAG 시스템을 구축한다고 상상해 보자
  - 열 이름이 있는 테이블 스키마를 컨텍스트로 제공하는 것만으로도 충분할 수 있음
  - 그러나 열 설명과 일부 대표 값을 포함하면 어떨까?
- 추가 세부 정보는 LLM이 테이블의 의미를 더 잘 이해하고 더 정확한 SQL을 생성하는 데 도움이 될 수 있음

키워드 검색을 잊지 말고, 기준선과 하이브리드 검색에 사용할 것

Embedding 기반 RAG 데모가 널리 퍼져 있기 때문에 정보 검색 분야의 수십 년 간의 연구와 솔루션을 잊거나 간과하기 쉬움
- 그럼에도 불구하고 임베딩은 의심할 여지 없이 강력한 도구이지만, 만능은 아님
키워드 기반 검색의 장점
- 첫째, 임베딩은 높은 수준의 의미론적 유사성을 포착하는 데 탁월하지만, 사용자가 이름(예: Ilya), 두문자어(예: RAG) 또는 ID(예: claude-3-sonnet)를 검색할 때와 같이 더 구체적이고 키워드 기반의 쿼리에는 어려움을 겪을 수 있음
  - BM25와 같은 키워드 기반 검색은 이를 위해 명시적으로 설계됨
  - 사용자들은 키워드 기반 검색을 오랫동안 사용해 왔기 때문에 당연한 것으로 여기고 있을 것이며, 검색하고자 하는 문서가 반환되지 않으면 좌절감을 느낄 수 있음
- 둘째, 키워드 검색으로 문서가 검색된 이유를 이해하는 것이 더 직관적임
  - 쿼리와 일치하는 키워드를 확인할 수 있기 때문
  - 반면에 임베딩 기반 검색은 해석 가능성이 낮음
- 셋째, 수십 년 동안 최적화되고 실전에서 검증된 Lucene이나 OpenSearch와 같은 시스템 덕분에 키워드 검색이 일반적으로 더 계산적으로 효율적임
대부분의 경우 하이브리드 접근 방식이 가장 효과적
- 명백한 일치 항목에는 키워드 매칭을 사용하고, 동의어, 상위어, 철자 오류 및 멀티모달(예: 이미지와 텍스트)에는 임베딩을 사용
- Shortwave는 쿼리 재작성, 키워드 + 임베딩 검색, 랭킹 등 자신들의 RAG 파이프라인을 어떻게 구축했는지 공유한바 있음

새로운 지식에 대해서는 파인튜닝보다 RAG를 선호

RAG와 파인튜닝 모두 새로운 정보를 LLM에 통합하고 특정 작업에 대한 성능을 향상시키는 데 사용될 수 있음
- 그렇다면 어떤 것을 먼저 시도해야 할까?
RAG의 장점
- 최근 연구에 따르면 RAG가 더 우수할 수 있음
- 한 연구에서는 RAG와 비지도 미세 조정(지속적 사전 학습이라고도 함)을 MMLU와 시사 문제의 하위 집합에서 평가하여 비교함
  - RAG가 학습 중에 접한 지식과 완전히 새로운 지식 모두에 대해 미세 조정보다 지속적으로 더 우수한 성능을 보였음
- 다른 논문에서는 농업 데이터 세트에 대해 RAG와 지도 미세 조정을 비교함
  - 마찬가지로 RAG의 성능 향상이 미세 조정보다 컸으며, 특히 GPT-4에서 두드러짐(논문의 표 20 참조)
- 성능 향상 외에도 RAG는 여러 실용적인 장점이 있음
  - 첫째, 지속적인 사전 학습이나 미세 조정에 비해 검색 인덱스를 최신 상태로 유지하는 것이 더 쉽고 저렴함
  - 둘째, 검색 인덱스에 유해하거나 편향된 내용이 포함된 문제가 있는 문서가 있는 경우 문제가 있는 문서를 쉽게 삭제하거나 수정할 수 있음
- 또한 RAG의 R은 문서를 검색하는 방법에 대해 더 세분화된 제어를 제공함
  - 예를 들어 여러 조직을 위해 RAG 시스템을 호스팅하는 경우, 검색 인덱스를 분할하여 각 조직이 자체 인덱스의 문서만 검색할 수 있도록 할 수 있음
  - 이렇게 하면 한 조직의 정보를 실수로 다른 조직에 노출하는 일이 없도록 할 수 있음

장문 컨텍스트 모델이 RAG를 쓸모없게 만들지는 않을 것임

Gemini 1.5가 최대 1,000만 토큰 크기의 컨텍스트 윈도우를 제공함에 따라 일부에서는 RAG의 미래에 의문을 제기하기 시작함
- 1,000만 토큰의 컨텍스트 윈도우는 기존 RAG 프레임워크 대부분을 불필요하게 만듦
  - 데이터를 컨텍스트에 넣고 평소처럼 모델과 대화하기만 하면 됨
- 이는 대부분의 엔지니어링 노력이 RAG에 투입되는 스타트업, 에이전트, langchain 프로젝트에 어떤 영향을 줄지 상상해 보라
  - 한 문장으로 요약하면 1,000만 컨텍스트가 RAG를 죽인다는 것
RAG의 지속적 필요성
- 장문 컨텍스트가 여러 문서 분석이나 PDF와의 채팅 등의 사용 사례에 게임 체인저가 될 것이라는 점은 사실이지만, RAG의 종말에 대한 소문은 크게 과장됨
  - 첫째, 1,000만 토큰의 컨텍스트 윈도우가 있더라도 모델에 입력할 정보를 선택하는 방법이 여전히 필요함
  - 둘째, 좁은 바늘구멍 평가를 넘어서 모델이 그렇게 큰 컨텍스트에 대해 효과적으로 추론할 수 있다는 설득력 있는 데이터는 아직 보지 못함
  - 따라서 좋은 검색(및 랭킹) 없이는 주의를 분산시키는 정보로 모델을 압도하거나 심지어 완전히 무관한 정보로 컨텍스트 윈도우를 채울 위험이 있음
마지막으로 비용 문제가 있음
- Transformer의 추론 비용은 컨텍스트 길이에 따라 제곱(또는 공간과 시간 모두에서 선형)으로 증가함
- 조직의 전체 Google Drive 내용을 읽을 수 있는 모델이 존재한다고 해서 각 질문에 답하기 전에 그렇게 하는 것이 좋은 생각은 아님
- RAM 사용 방식에 대한 비유를 고려해 보자
  - 수십 테라바이트에 달하는 RAM이 있는 컴퓨팅 인스턴스가 존재하지만, 여전히 디스크에서 읽고 쓰고 있음
따라서 아직 RAG를 쓰레기통에 버리지 말 것
- 이 패턴은 컨텍스트 윈도우의 크기가 커질수록 여전히 유용할 것임

전술 3. 워크플로우 튜닝 및 최적화

LLM에 프롬프트를 주는 것은 시작에 불과함
- LLM을 최대한 활용하려면 단일 프롬프트를 넘어 워크플로우를 수용해야 함
- 예를 들어, 복잡한 단일 작업을 여러 개의 더 간단한 작업으로 어떻게 분할할 수 있을까?
- 미세 조정이나 캐싱이 성능 향상과 지연/비용 감소에 도움이 되는 시점은 언제일까?
이 섹션에서는 검증된 전략과 실제 사례를 공유하여 LLM 워크플로우를 최적화하고 구축하는 데 도움을 줌

단계별, 다중 턴 "Flow"는 큰 성능 향상을 제공할 수 있음

하나의 큰 프롬프트를 여러 개의 작은 프롬프트로 분해함으로써 더 나은 결과를 얻을 수 있다는 것을 이미 알고 있음
- AlphaCodium이 그 예시임
  - 단일 프롬프트에서 다단계 워크플로우로 전환함으로써 CodeContests에서 GPT-4 정확도(pass@5)를 19%에서 44%로 높임
- 워크플로우에는 다음이 포함됨
  - 문제에 대한 숙고
  - 공개 테스트에 대한 추론
  - 가능한 솔루션 생성
  - 가능한 솔루션 순위 매기기
  - 합성 테스트 생성
  - 공개 및 합성 테스트에 대한 솔루션 반복
명확한 목표를 가진 작은 작업은 최상의 에이전트 또는 흐름 프롬프트를 만듦
- 모든 에이전트 프롬프트가 구조화된 출력을 요청할 필요는 없지만, 구조화된 출력은 에이전트의 환경과의 상호 작용을 조정하는 시스템과의 인터페이스에 큰 도움이 됨
시도해 볼 만한 것들
- 가능한 한 엄격하게 지정된 명시적 계획 단계
  - 미리 정의된 계획 중에서 선택하는 것을 고려할 것
- 원래 사용자 프롬프트를 에이전트 프롬프트로 다시 작성
  - 이 과정에서 정보 손실이 발생하므로 주의할 것
- 선형 체인, DAG 및 상태 머신으로서의 에이전트 동작
  - 다양한 종속성과 논리 관계는 서로 다른 규모에 더 적합하거나 덜 적합할 수 있음
  - 다양한 작업 아키텍처에서 성능 최적화를 이끌어낼 수 있을까?
- 계획 검증
  - 계획에는 최종 결과물이 잘 작동하도록 다른 에이전트의 응답을 평가하는 방법에 대한 지침을 포함할 수 있음
- 고정된 업스트림 상태로 프롬프트 엔지니어링
  - 에이전트 프롬프트가 이전에 발생할 수 있는 다양한 변형에 대해 평가되는지 확인할 것

현재로서는 결정론적 워크플로우에 우선순위를 둘 것

AI 에이전트는 사용자 요청과 환경에 동적으로 반응할 수 있지만, 이들의 비결정론적 특성은 배포에 어려움을 줌
- 에이전트가 수행하는 각 단계는 실패할 가능성이 있으며, 오류에서 복구할 가능성은 낮음
- 따라서 에이전트가 다단계 작업을 성공적으로 완료할 가능성은 단계 수가 증가함에 따라 기하급수적으로 감소함
- 그 결과 에이전트를 구축하는 팀은 신뢰할 수 있는 에이전트를 배포하는 데 어려움을 겪음
유망한 접근 방식은 결정론적 계획을 생성하고 이를 구조화되고 재현 가능한 방식으로 실행하는 에이전트 시스템을 갖는 것임
- 첫 번째 단계에서는 상위 수준의 목표나 프롬프트가 주어지면 에이전트가 계획을 생성함
- 그런 다음 계획이 결정론적으로 실행됨
- 이를 통해 각 단계를 보다 예측 가능하고 신뢰할 수 있게 만들 수 있음
- 장점
  - 생성된 계획은 에이전트에 프롬프트를 제공하거나 미세 조정하기 위한 few-shot 샘플로 사용될 수 있음
  - 결정론적 실행은 시스템을 더 신뢰할 수 있게 만들어 테스트와 디버깅이 더 쉬워짐. 또한 실패는 계획의 특정 단계로 추적될 수 있음
  - 생성된 계획은 방향성 비순환 그래프(DAG)로 표현될 수 있으며, 정적 프롬프트에 비해 이해하고 새로운 상황에 적응하기 쉬움
가장 성공적인 에이전트 구축자는 주니어 엔지니어를 관리하는 데 강력한 경험을 가진 사람일 수 있음
- 계획 생성 과정은 주니어를 지시하고 관리하는 방식과 유사하기 때문
- 주니어에게 모호하고 개방적인 방향 대신 명확한 목표와 구체적인 계획을 제공하는 것처럼, 에이전트에게도 동일하게 해야 함
결국 신뢰할 수 있고 작동하는 에이전트의 핵심은
- 보다 구조화되고 결정론적인 접근 방식을 채택하고,
- 프롬프트를 개선하고 모델을 미세 조정하기 위한 데이터를 수집하는 데서 발견될 가능성이 높음
이것 없이는 때때로 매우 잘 작동할 수 있지만 평균적으로 사용자를 실망시켜 유지력이 낮아지는 에이전트를 구축하게 될 것임

온도 매개변수 이상의 다양한 출력 얻기

LLM의 출력에 다양성이 필요한 작업이 있다고 가정해 보자
- 사용자가 이전에 구매한 제품 목록을 고려하여 카탈로그에서 구매할 제품을 제안하는 LLM 파이프라인을 작성하고 있을 수 있음
- 프롬프트를 여러 번 실행할 때 결과 추천이 너무 유사하다는 것을 알 수 있음
- 따라서 LLM 요청의 Temperature(온도) 매개변수를 높일 수 있음
온도 매개변수를 높이면 LLM 응답이 더 다양해짐
- 샘플링 시 다음 토큰의 확률 분포가 더 평평해져 일반적으로 선택될 가능성이 낮은 토큰이 더 자주 선택됨
그러나 온도를 높일 때 출력 다양성과 관련된 일부 실패 모드가 발생할 수 있음
- 예를 들어 카탈로그의 일부 제품이 적합할 수 있지만 LLM에 의해 출력되지 않을 수 있음
- LLM이 학습 시 배운 내용을 기반으로 프롬프트를 따를 가능성이 높은 경우 동일한 소수의 제품이 출력에서 과대 대표될 수 있음
- 온도가 너무 높으면 존재하지 않는 제품(또는 무의미한 내용)을 참조하는 출력이 생성될 수 있음
온도를 높인다고 해서 LLM이 예상하는 확률 분포(예: 균일 무작위)에서 출력을 샘플링한다는 보장은 없음
그럼에도 불구하고 출력 다양성을 높이기 위한 다른 트릭이 있음
- 가장 간단한 방법은 프롬프트 내 요소를 조정하는 것
  - 예를 들어 프롬프트 템플릿에 과거 구매 내역과 같은 항목 목록이 포함된 경우, 이러한 항목을 프롬프트에 삽입할 때마다 순서를 섞으면 상당한 차이를 만들 수 있음
- 또한 최근 출력의 짧은 목록을 유지하면 중복을 방지하는 데 도움이 됨
  - 추천 제품 예시에서 LLM에 이 최근 목록에서 항목 제안을 피하도록 지시하거나, 최근 제안과 유사한 출력을 거부하고 재샘플링함으로써 응답을 더욱 다양화할 수 있음
- 또 다른 효과적인 전략은 프롬프트에 사용되는 표현을 다양화하는 것
  - 예를 들어 "사용자가 정기적으로 사용하는 것을 좋아할 항목 선택" 또는 "사용자가 친구에게 추천할 가능성이 높은 제품 선택"과 같은 문구를 통합하면 초점을 이동시켜 추천 제품의 다양성에 영향을 줄 수 있음

캐싱은 과소평가되고 있음

캐싱은 동일한 입력에 대한 응답을 재계산할 필요성을 제거함으로써 비용을 절감하고 생성 지연 시간을 제거함
- 또한 응답이 이전에 가드레일링되었다면, 이러한 검증된 응답을 제공하여 유해하거나 부적절한 콘텐츠를 제공할 위험을 줄일 수 있음
캐싱에 대한 간단한 접근 방식은 새로운 기사나 제품 리뷰를 요약하는 경우와 같이 처리 중인 항목에 대해 고유한 ID를 사용하는 것임
- 요청이 들어오면 캐시에 이미 요약이 존재하는지 확인할 수 있음
  - 그렇다면 즉시 반환할 수 있고, 그렇지 않다면 생성, 가드레일링 및 제공한 다음 향후 요청을 위해 캐시에 저장할 수 있음
좀 더 개방형인 쿼리의 경우 개방형 입력에 대해서도 캐싱을 활용하는 검색 분야의 기술을 차용할 수 있음
- 자동 완성 및 맞춤법 수정과 같은 기능은 사용자 입력을 정규화하여 캐시 적중률을 높이는 데 도움이 됨

finetune(파인 튜닝)이 필요한 시점

가장 영리하게 설계된 프롬프트조차도 부족한 일부 작업이 있을 수 있음
- 예를 들어 상당한 프롬프트 엔지니어링 이후에도 시스템이 여전히 신뢰할 수 있고 고품질의 출력을 반환하는 데서 멀어질 수 있음
- 이 경우 특정 작업을 위해 모델을 파인튜닝해야 할 수 있음
성공적인 파인 튜닝 사례
- Honeycomb의 Natural Language Query Assistant
  - 처음에는 "프로그래밍 매뉴얼"이 문맥 내 학습을 위한 n-shot 예제와 함께 프롬프트에 제공됨
  - 이것이 제대로 작동했지만, 모델을 파인 튜닝하면 도메인 특정 언어의 구문과 규칙에 대한 더 나은 출력을 얻을 수 있음
- Rechat의 Lucy
  - LLM은 프론트엔드가 올바르게 렌더링하기 위해 구조화된 데이터와 비구조화된 데이터를 결합한 매우 특정한 형식으로 응답을 생성해야 함
  - 파인 튜닝은 일관되게 작동하도록 하는 데 필수적임
파인튜닝이 효과적일 수 있지만 상당한 비용이 수반됨
- 파인 튜닝 데이터에 주석을 달고, 모델을 파인 튜닝 및 평가한 다음, 결국 자체 호스팅해야 함
- 따라서 더 높은 초기 비용이 그만한 가치가 있는지 고려해야 함
프롬프팅으로 90%까지 도달할 수 있다면 파인 튜닝에 투자할 가치가 없을 수 있음
- 그러나 파인 튜닝하기로 결정한다면 인간이 주석을 단 데이터 수집 비용을 줄이기 위해 합성 데이터에 대해 생성 및 파인 튜닝하거나 오픈 소스 데이터를 부트스트랩할 수 있음

전술 4. 평가 및 모니터링

LLM 평가는 지뢰밭이 될 수 있음
- LLM의 입력과 출력은 임의의 텍스트이며, 설정하는 작업도 다양함
- 그럼에도 불구하고 엄격하고 신중한 평가는 중요함
  - OpenAI의 기술 리더들이 평가에 참여하고 개별 평가에 대해 피드백을 제공하는 것이 우연이 아님
LLM 애플리케이션 평가에는 다양한 정의와 축소가 필요함
- 단순히 단위 테스트이거나, 관찰 가능성과 더 유사하거나, 단순히 데이터 과학일 수 있음
- 우리는 이러한 모든 관점이 유용하다는 것을 발견함
이번 섹션에서는 평가 및 모니터링 파이프라인 구축에서 중요한 사항에 대해 배운 교훈을 제공함

실제 입출력 샘플에서 몇 가지 assertion 기반 단위 테스트 생성

프로덕션에서 입력과 출력의 샘플로 구성된 단위 테스트(즉, assertion)를 만들고, 최소 3가지 기준에 따라 출력에 대한 기대치를 설정
- 3가지 기준이 임의적으로 보일 수 있지만, 시작하기에 실용적인 수임
  - 더 적으면 작업이 충분히 정의되지 않았거나 범용 챗봇과 같이 너무 개방적일 수 있음
- 이러한 단위 테스트 또는 assertion은 프롬프트 편집, RAG를 통한 새 컨텍스트 추가 또는 기타 수정과 같은 파이프라인의 변경 사항에 의해 트리거되어야 함
모든 응답에 포함하거나 제외할 구문이나 아이디어를 지정하는 assertion부터 시작하는 것을 고려
- 또한 단어, 항목 또는 문장 수가 범위 내에 있는지 확인하는 검사를 고려
- 다른 종류의 생성의 경우 assertion이 다르게 보일 수 있음
  - 예를 들어 코드 생성을 평가하기 위한 강력한 방법인 실행 평가에서는 생성된 코드를 실행하고 런타임 상태가 사용자 요청에 충분한지 확인
예를 들어 사용자가 foo라는 새 함수를 요청하면 에이전트의 생성 코드를 실행한 후 foo를 호출할 수 있어야 함
실행 평가의 한 가지 과제는 에이전트 코드가 종종 대상 코드와 약간 다른 형태로 런타임을 남긴다는 것
- 어떤 타당한 답변이라도 만족시킬 수 있는 가장 약한 가정으로 assertion을 "완화"하는 것이 효과적일 수 있음
고객을 위해 의도한 대로 제품을 사용하는 것(즉, "도그푸딩")은 실제 데이터에서의 장애 모드에 대한 통찰력을 제공할 수 있음
- 이 접근 방식은 잠재적 약점을 식별하는 데 도움이 될 뿐만 아니라 평가로 변환할 수 있는 유용한 프로덕션 샘플 소스도 제공함

LLM-as-Judge는 (어느 정도) 작동할 수 있지만 만능은 아님

LLM-as-Judge는 강력한 LLM을 사용하여 다른 LLM의 출력을 평가하는 방식으로, 일부 사람들에게는 회의적으로 받아들여짐
그럼에도 불구하고 잘 구현되면 LLM-as-Judge는 인간의 판단과 상당한 상관관계를 달성하고, 적어도 새로운 프롬프트나 기술이 어떻게 수행될 수 있는지에 대한 사전 정보를 구축하는 데 도움이 될 수 있음
- 특히 쌍별 비교(예: 대조군 vs 처리군)를 할 때 LLM-as-Judge는 일반적으로 방향을 올바르게 잡지만 승/패의 크기는 노이즈가 있을 수 있음
LLM-as-Judge를 최대한 활용하기 위한 제안
- 쌍별 비교 사용
  - LLM에게 단일 출력을 Likert 척도로 평가하도록 요청하는 대신 두 가지 옵션을 제시하고 더 나은 것을 선택하도록 요청
  - 이는 더 안정적인 결과로 이어지는 경향이 있음
- 위치 편향 제어
  - 제시된 옵션의 순서가 LLM의 결정을 편향시킬 수 있음
  - 이를 완화하려면 각 쌍별 비교를 두 번 수행하고 각 시간에 쌍의 순서를 바꿈
  - 스와핑 후에는 올바른 옵션에 승리를 귀속시켜야 함
- 동점 허용
  - 경우에 따라 두 옵션이 똑같이 좋을 수 있음
  - 따라서 LLM이 임의로 승자를 선택할 필요가 없도록 동점을 선언하도록 허용
- Chain-of-Thought 사용
  - 최종 선호도를 제시하기 전에 LLM에게 그 결정을 설명하도록 요청하면 평가 신뢰성이 향상될 수 있음
  - 보너스로, 이를 통해 더 약하지만 빠른 LLM을 사용하면서도 유사한 결과를 얻을 수 있음
  - 파이프라인의 이 부분이 자주 배치 모드에 있기 때문에 CoT로 인한 추가 지연은 문제가 되지 않음
- 응답 길이 제어
  - LLM은 더 긴 응답으로 치우치는 경향이 있음
  - 이를 완화하려면 응답 쌍의 길이가 비슷한지 확인
LLM-as-Judge의 특히 강력한 적용은 새로운 프롬프트 전략을 회귀에 대해 확인하는 것
- 프로덕션 결과 모음을 추적한 경우 때로는 새로운 프롬프트 전략으로 해당 프로덕션 예제를 다시 실행하고 LLM-as-Judge를 사용하여 새 전략이 어디에서 어려움을 겪을 수 있는지 신속하게 평가할 수 있음
LLM-as-Judge의 간단하지만 효과적인 접근 방식의 예시
- 단순히 LLM 응답, 판사의 비평(즉, CoT) 및 최종 결과를 기록
- 그런 다음 이해관계자와 검토하여 개선 영역을 식별
- 3번의 반복을 통해 인간과 LLM의 일치도는 68%에서 94%로 향상됨
그러나 LLM-as-Judge는 만능이 아님
- 가장 강력한 모델조차도 신뢰할 수 있게 평가하지 못하는 미묘한 언어적 측면이 있음
또한 기존의 분류기와 보상 모델이 LLM-as-Judge보다 더 높은 정확도를 달성할 수 있으며 비용과 지연 시간이 더 적다는 것을 발견함
- 코드 생성의 경우 LLM-as-Judge는 실행 평가와 같은 보다 직접적인 평가 전략보다 약할 수 있음

생성 결과 평가를 위한 "인턴 테스트"

생성 결과를 평가할 때 다음과 같은 "인턴 테스트"를 사용하는 것이 좋음
- 컨텍스트를 포함하여 언어 모델에 대한 정확한 입력을 가져와 관련 전공의 평균적인 대학생에게 과제로 제시한다면 그들이 성공할 수 있을까?
- 얼마나 걸릴까?
답변이 아니오인 경우
- LLM에 필요한 지식이 부족하기 때문이라면 컨텍스트를 풍부하게 만드는 방법을 고려
- 컨텍스트를 개선해도 해결할 수 없다면 현대 LLM에는 너무 어려운 작업일 수 있음
답변이 예이지만 시간이 걸리는 경우
- 작업의 복잡성을 줄이려고 시도해볼 수 있음
  - 분해 가능한가?
  - 작업의 어떤 측면을 더 템플릿화할 수 있는가?
답변이 예이고 빠르게 할 수 있는 경우
- 데이터를 파고들 때
  - 모델이 잘못하고 있는 것은 무엇인가?
  - 실패의 패턴을 찾을 수 있는가?
- 모델에게 응답 전이나 후에 스스로 설명하도록 요청해보기

특정 평가에 지나치게 중점을 두면 전반적인 성능이 저하될 수 있음

"측정 지표가 목표가 되면 더 이상 좋은 측정 지표가 아니게 된다." - Goodhart의 법칙

이에 대한 예시로 Needle-in-a-Haystack(NIAH) 평가가 있음
- 원래 평가는 컨텍스트 크기가 커짐에 따라 모델 리콜을 정량화하고 바늘 위치에 따라 리콜이 어떻게 영향을 받는지 확인하는 데 도움이 됨
- 그러나 너무 지나치게 강조되어 Gemini 1.5 보고서의 Figure 1로 소개됨
- 이 평가에는 폴 그레이엄의 에세이를 반복하는 긴 문서에 특정 구문("The special magic {city} number is: {number}")을 삽입한 다음 모델에 매직 넘버를 상기시키는 작업이 포함됨
일부 모델은 거의 완벽한 리콜을 달성하지만 NIAH가 실제 애플리케이션에 필요한 추론 및 리콜 능력을 진정으로 반영하는지는 의문
보다 실용적인 시나리오 고려
- 1시간 분량의 회의 녹취록이 주어지면 LLM이 주요 결정과 다음 단계를 요약하고 각 항목을 관련 담당자에게 올바르게 귀속시킬 수 있는가?
- 이 작업은 단순한 암기를 넘어 복잡한 토론을 파악하고 관련 정보를 식별하며 요약을 종합하는 능력도 고려하므로 더 현실적임
실용적인 NIAH 평가의 예시
- 의사-환자 화상 통화 녹취록을 사용하여 LLM에 환자의 약물에 대해 질문
- 에스프레소에 담근 대추, 레몬, 염소 치즈 등 피자 토핑에 필요한 무작위 재료에 대한 구문을 삽입하는 등 보다 도전적인 NIAH도 포함
- 약물 작업에서 리콜은 약 80%, 피자 작업에서는 30%였음
NIAH 평가를 지나치게 강조하면 추출 및 요약 작업의 성능이 낮아질 수 있음
- 이러한 LLM은 모든 문장에 주의를 기울이도록 미세 조정되어 있기 때문에 관련 없는 세부 정보와 주의 산만 요소를 중요한 것으로 취급하기 시작할 수 있음
- 그러면 최종 출력에 포함될 수 있음(포함되지 말아야 할 때도!)
이는 다른 평가 및 사용 사례에도 적용될 수 있음
- 예를 들어 요약
  - 사실적 일관성을 강조하면 덜 구체적이고(따라서 사실과 일치하지 않을 가능성이 낮음) 관련성이 떨어질 수 있는 요약이 생성될 수 있음
  - 반대로 글쓰기 스타일과 웅변을 강조하면 사실적 불일치를 초래할 수 있는 더 화려한 마케팅 유형의 언어가 생성될 수 있음

주석 달기를 이진 작업 또는 쌍대(pairwise) 비교로 단순화

모델 출력에 대해 개방형 피드백을 제공하거나 Likert 척도로 평가하는 것은 인지적으로 까다로움
- 그 결과 수집된 데이터는 인간 평가자 간의 변동성으로 인해 더 노이즈가 많아지고 따라서 덜 유용해짐
보다 효과적인 접근 방식은 작업을 단순화하고 주석 작성자의 인지적 부담을 줄이는 것
- 잘 작동하는 두 가지 작업은 이진 분류와 쌍대 비교
이진 분류에서 주석 작성자는 모델의 출력에 대해 간단한 예/아니오 판단을 내리도록 요청받음
- 생성된 요약이 소스 문서와 사실적으로 일치하는지, 제안된 응답이 관련이 있는지, 유해성이 포함되어 있는지 등을 물을 수 있음
- Likert 척도에 비해 이진 결정은 더 정확하고, 평가자 간 일관성이 더 높으며, 처리량이 더 높음
- Doordash가 일련의 예/아니오 질문을 통해 메뉴 항목에 태그를 붙이기 위해 레이블링 대기열을 설정한 방식
쌍대 비교(Pairewise Comparison)에서 주석 작성자는 한 쌍의 모델 응답을 받고 어떤 것이 더 나은지 물음
- 인간이 A 또는 B에 개별적으로 점수를 매기는 것보다 "A가 B보다 낫다"라고 말하는 것이 더 쉽기 때문에 이는 더 빠르고 신뢰할 수 있는 주석으로 이어짐(Likert 척도보다)
Llama2 밋업에서 Llama2 논문의 저자 중 한 명인 Thomas Scialom은 쌍대 비교가 작성된 응답과 같은 지도 학습 미세 조정 데이터를 수집하는 것보다 더 빠르고 저렴하다는 것을 확인함
- 전자의 비용은 단위당 $3.5이고 후자의 비용은 단위당 $25

(참조가 필요 없는, Reference-free) 평가와 가드레일은 상호 교환적으로 사용될 수 있음

가드레일은 부적절하거나 유해한 콘텐츠를 잡는 데 도움이 되는 반면, 평가는 모델 출력의 품질과 정확성을 측정하는 데 도움이 됨
- 참조가 필요 없는 평가의 경우 동전의 양면으로 볼 수 있음
  - 참조가 필요 없는 평가는 인간이 작성한 답변과 같은 "golden" reference에 의존하지 않고 입력 프롬프트와 모델의 응답만으로 출력 품질을 평가할 수 있는 평가임
참조가 필요 없는 평가 예시 : 요약 평가
- 요약의 사실적 일관성과 관련성을 평가하기 위해 입력 문서만 고려하면 됨
- 요약이 이러한 지표에서 점수가 낮으면 사용자에게 표시하지 않도록 선택할 수 있어 평가를 가드레일로 효과적으로 사용할 수 있음
참조가 필요 없는 "번역" 평가 :
- 인간이 번역한 참조 없이도 번역의 품질을 평가할 수 있어 다시 가드레일로 사용할 수 있음

LLM은 그러면 안 될 때도 출력을 반환함

LLM 작업 시 주요 과제는 LLM이 그러면 안 될 때도 종종 출력을 생성한다는 것
- 이는 무해하지만 무의미한 응답이나 유해성 또는 위험한 내용과 같은 더 심각한 결함으로 이어질 수 있음
- 예를 들어 문서에서 특정 속성이나 메타데이터를 추출하라는 요청을 받으면 LLM은 해당 값이 실제로 존재하지 않을 때도 자신 있게 값을 반환할 수 있음
- 또는 컨텍스트에 영어 이외의 문서를 제공했기 때문에 모델이 영어 이외의 언어로 응답할 수도 있음
LLM에 "해당 없음" 또는 "알 수 없음" 응답을 반환하도록 프롬프트를 제공할 수 있지만 완벽하지는 않음
- 로그 확률을 사용할 수 있는 경우에도 출력 품질의 좋지 않은 지표임
  - 로그 확률은 출력에 토큰이 나타날 가능성을 나타내지만 생성된 텍스트의 정확성을 반영하지는 않음
- 오히려 쿼리에 응답하고 일관된 응답을 생성하도록 훈련된 명령어 튜닝 모델의 경우 로그 확률이 잘 보정되지 않을 수 있음
  - 따라서 높은 로그 확률은 출력이 유창하고 일관성이 있음을 나타낼 수 있지만 정확하거나 관련이 있다는 의미는 아님
주의 깊은 프롬프트 엔지니어링은 어느 정도 도움이 될 수 있지만, 원치 않는 출력을 감지하고 필터링/재생성하는 강력한 가드레일로 보완해야 함
- 예를 들어 OpenAI는 혐오 발언, 자해 또는 성적 출력과 같은 안전하지 않은 응답을 식별할 수 있는 콘텐츠 조정 API를 제공함
- 마찬가지로 개인 식별 정보(PII)를 감지하기 위한 수많은 패키지가 있음
가드레일의 한 가지 이점은 사용 사례에 대해 크게 무관하며 따라서 특정 언어로 된 모든 출력에 광범위하게 적용될 수 있다는 것
- 또한 정밀한 검색을 통해 관련 문서가 없으면 시스템이 결정적으로 "모르겠습니다"라고 응답할 수 있음
LLM은 출력이 예상될 때 출력을 생성하지 못할 수 있음
- API 제공업체의 긴 지연 시간과 같은 간단한 문제부터 콘텐츠 조정 필터에 의해 출력이 차단되는 것과 같은 더 복잡한 문제에 이르기까지 다양한 이유로 발생할 수 있음
따라서 디버깅 및 모니터링을 위해 입력과 (잠재적으로 출력 부족을) 일관되게 기록하는 것이 중요함

환각(Hallucination)은 끈질긴 문제임

콘텐츠 안전성이나 PII 결함은 많은 주의를 받아 거의 발생하지 않는 반면, 사실적 불일치는 끈질기게 지속되며 감지하기가 더 어려움
- 더 흔하게 발생하며 기준 발생률은 5~10%이고, LLM 제공업체로부터 배운 바에 따르면 요약과 같은 간단한 작업에서도 2% 미만으로 낮추는 것이 어려울 수 있음
이를 해결하기 위해 프롬프트 엔지니어링(생성 업스트림)과 사실적 불일치 가드레일(생성 다운스트림)을 결합할 수 있음
- 프롬프트 엔지니어링의 경우 CoT와 같은 기술은 LLM이 최종 출력을 반환하기 전에 추론을 설명하도록 함으로써 환각을 줄이는 데 도움이 됨
- 그런 다음 사실적 불일치 가드레일을 적용하여 요약의 사실성을 평가하고 환각을 필터링하거나 재생성할 수 있음
경우에 따라 환각은 결정론적으로 감지될 수 있음
- RAG 검색의 리소스를 사용할 때 출력이 구조화되어 있고 리소스가 무엇인지 식별한다면 입력 컨텍스트에서 소싱되었는지 수동으로 확인할 수 있어야 함

[운영: 일상(Day-to-Day) 및 조직 문제 ]

운영 1. 데이터

재료의 품질이 요리의 맛을 결정하듯이 입력 데이터의 품질은 기계 학습 시스템의 성능을 제약함
또한 출력 데이터는 제품이 작동하는지 여부를 알 수 있는 유일한 방법임
모든 저자는 데이터 분포(모드, 엣지 케이스, 모델의 한계)를 더 잘 이해하기 위해 매주 몇 시간 동안 입력과 출력을 면밀히 살펴봄

개발-프로덕션 편향 확인

전통적인 기계 학습 파이프라인에서 오류의 일반적인 원인은 훈련-서비스 편향임
- 이는 훈련에 사용되는 데이터가 모델이 프로덕션에서 접하는 데이터와 다를 때 발생함
훈련이나 미세 조정 없이 LLM을 사용할 수 있으므로 훈련 세트는 없지만 개발-프로덕션 데이터 편향이라는 유사한 문제가 발생함
- 기본적으로 개발 중에 시스템을 테스트하는 데이터는 시스템이 프로덕션에서 직면할 데이터를 반영해야 함
  - 그렇지 않으면 프로덕션 정확도가 저하될 수 있음
LLM 개발-프로덕션 편향은 구조적 편향과 내용 기반 편향의 두 가지 유형으로 분류될 수 있음
- 구조적 편향에는 목록형 값을 가진 JSON 딕셔너리와 JSON 목록 간의 차이, 일관되지 않은 케이싱, 오타나 문장 조각과 같은 오류 등 형식 불일치와 같은 문제가 포함됨
  - 이러한 오류는 다양한 LLM이 특정 데이터 형식으로 훈련되고 프롬프트가 사소한 변경에 매우 민감할 수 있기 때문에 예측할 수 없는 모델 성능으로 이어질 수 있음
- 내용 기반 또는 "의미론적" 편향은 데이터의 의미나 맥락의 차이를 나타냄
전통적인 ML과 마찬가지로 LLM 입출력 쌍 간의 편향을 주기적으로 측정하는 것이 유용함
- 입력 및 출력 길이 또는 특정 형식 요구 사항(예: JSON 또는 XML)과 같은 단순 메트릭은 변경 사항을 추적하는 간단한 방법임
보다 "고급" 편향 감지를 위해 입출력 쌍의 임베딩을 클러스터링하여 사용자가 이전에 모델에 노출되지 않은 영역을 탐색하고 있음을 나타낼 수 있는 사용자가 논의하는 주제의 변화와 같은 의미론적 편향을 감지하는 것을 고려할 것
프롬프트 엔지니어링과 같은 변경 사항을 테스트할 때는 홀드아웃 데이터 세트가 최신 상태이고 가장 최근 유형의 사용자 상호 작용을 반영하는지 확인
- 예를 들어 프로덕션 입력에서 오타가 흔하다면 홀드아웃 데이터에도 있어야 함
단순히 숫자로 편향을 측정하는 것 이상으로 출력에 대해 정성적 평가를 수행하는 것이 유익함
- 모델의 출력을 정기적으로 검토하는 것(속어로 "바이브 체크"라고 알려진 관행)은 결과가 기대에 부합하고 사용자 요구에 계속 관련성이 있는지 확인해줌
편향 확인에 비결정론을 통합하는 것도 유용함
- 테스트 데이터 세트의 각 입력에 대해 파이프라인을 여러 번 실행하고 모든 출력을 분석함으로써 가끔만 발생할 수 있는 이상 현상을 포착할 가능성이 높아짐

매일 LLM 입출력 샘플 확인하기

LLM은 역동적이고 끊임없이 진화하고 있음
- 인상적인 제로샷 능력과 종종 기분 좋은 출력에도 불구하고 LLM의 실패 모드는 매우 예측할 수 없음
맞춤 작업의 경우 LLM의 성능에 대한 직관적인 이해를 개발하기 위해 데이터 샘플을 정기적으로 검토하는 것이 필수적임
- 프로덕션의 입출력 쌍은 LLM 애플리케이션의 "실제 사물, 실제 장소"(genchi genbutsu)이며 대체할 수 없음
최근 연구에 따르면 개발자가 더 많은 데이터와 상호 작용할수록 "좋은" 출력과 "나쁜" 출력에 대한 인식이 변한다고 강조함(즉, 기준 편향)
- 개발자는 LLM 출력을 평가하기 위한 일부 기준을 사전에 제시할 수 있지만, 이러한 사전 정의된 기준은 종종 불완전함
예를 들어 개발 과정에서 좋은 응답 확률을 높이고 나쁜 응답 확률을 낮추기 위해 프롬프트를 업데이트할 수 있음
- 이러한 평가, 재평가 및 기준 업데이트의 반복 프로세스는 출력을 직접 관찰하지 않고는 LLM 동작이나 인간의 선호도를 예측하기 어렵기 때문에 필요함
이를 효과적으로 관리하기 위해 LLM 입력과 출력을 기록해야 함
- 매일 이러한 로그 샘플을 검사하면 새로운 패턴이나 실패 모드를 신속하게 식별하고 적응할 수 있음
- 새로운 문제를 발견하면 즉시 그것에 대한 assertion 또는 eval을 작성할 수 있음
마찬가지로 실패 모드 정의에 대한 모든 업데이트는 평가 기준에 반영되어야 함
- 이러한 "바이브 체크"는 잘못된 출력의 신호이며, 코드와 assertion은 이를 운영함
마지막으로 이러한 태도는 Socialized되어야 함
- 예를 들어 온콜 로테이션에 입력 및 출력 검토 또는 주석 달기를 추가하는 것

운영 2. 모델과 함께 일하기

LLM API를 사용하면 소수의 제공업체의 지능에 의존할 수 있음
- 이는 좋은 점이지만 이러한 종속성은 성능, 지연 시간, 처리량 및 비용 측면에서 절충점을 수반함
또한 지난 1년 동안 거의 매월 더 새롭고 더 나은 모델이 출시됨에 따라 오래된 모델을 폐기하고 새로운 모델로 마이그레이션할 때 제품을 업데이트할 준비가 되어 있어야 함
- 이 섹션에서는 완전히 제어할 수 없는 기술, 즉 모델을 자체 호스팅하고 관리할 수 없는 기술을 사용할 때 얻은 교훈을 공유함
실제 사용 사례 대부분의 경우 LLM의 출력은 일종의 기계 판독 가능 형식을 통해 다운스트림 애플리케이션에서 소비될 것임
- 예를 들어 부동산 CRM인 ReChat은 프론트엔드에서 위젯을 렌더링하기 위해 구조화된 응답이 필요함
- 유사하게 제품 전략 아이디어 생성 도구인 Boba는 제목, 요약, 타당성 점수 및 시간 범위 필드가 있는 구조화된 출력이 필요함
- 마지막으로 LinkedIn은 LLM을 제한하여 YAML을 생성하는 방법을 공유했는데, 이는 사용할 기술을 결정하고 기술을 호출하는 매개변수를 제공하는 데 사용됨
이 애플리케이션 패턴은 Postel의 법칙의 극단적인 버전임
- 수락하는 것(임의의 자연어)에 자유롭고 보내는 것(유형화된 기계 판독 가능 개체)에 보수적이어야 함
- 따라서 이것이 매우 내구성이 있을 것으로 기대함
현재 Instructor와 Outlines는 LLM에서 구조화된 출력을 이끌어내기 위한 사실상의 표준임
- LLM API(예: Anthropic, OpenAI)를 사용하는 경우 Instructor를 사용하고, 자체 호스팅 모델(예: Huggingface)을 사용하는 경우 Outlines를 사용할 것

모델 간 프롬프트 마이그레이션은 고통스러운 일임

때로는 주의 깊게 만든 프롬프트가 한 모델에서는 훌륭하게 작동하지만 다른 모델에서는 제대로 작동하지 않을 수 있음
- 이는 다양한 모델 제공업체 간에 전환할 때뿐만 아니라 동일한 모델의 버전 간에 업그레이드할 때도 발생할 수 있음
예를 들어 Voiceflow는 gpt-3.5-turbo-0301에서 gpt-3.5-turbo-1106으로 마이그레이션하면 의도 분류 작업에서 10%의 성능 저하가 발생한다는 것을 발견함
- (다행히도 그들은 평가를 가지고 있었음!)
유사하게 GoDaddy는 1106 버전으로 업그레이드하면 gpt-3.5-turbo와 gpt-4 사이의 성능 격차가 좁혀지는 긍정적인 방향의 추세를 관찰함
- (또는 당신이 반쯤 찬 유리잔을 보는 사람이라면 새로운 업그레이드로 gpt-4의 리드가 줄어든 것에 실망할 수도 있음)
따라서 모델 간에 프롬프트를 마이그레이션해야 하는 경우 단순히 API 엔드포인트를 교체하는 것보다 더 많은 시간이 걸릴 것으로 예상해야 함
- 동일한 프롬프트를 연결하면 유사하거나 더 나은 결과로 이어질 것이라고 가정하지 말 것
또한 신뢰할 수 있고 자동화된 평가는 마이그레이션 전후의 작업 성능을 측정하는 데 도움이 되며 수동 검증에 필요한 노력을 줄여줌

모델 버전 관리 및 고정

모든 기계 학습 파이프라인에서 "무엇이든 변경하면 모든 것이 변경됨"
- 이는 우리 자신이 훈련하지 않고 우리 모르게 변경될 수 있는 대규모 언어 모델(LLM)과 같은 구성 요소에 의존할 때 특히 관련이 있음
다행히도 많은 모델 제공업체는 특정 모델 버전(예: gpt-4-turbo-1106)을 "고정"할 수 있는 옵션을 제공함
- 이를 통해 모델 가중치의 특정 버전을 사용하여 변경되지 않도록 할 수 있음
프로덕션에서 모델 버전을 고정하면 모델 동작의 예기치 않은 변경을 방지할 수 있음
- 이는 모델이 교체될 때 발생할 수 있는 지나치게 장황한 출력이나 기타 예상치 못한 실패 모드와 같은 문제에 대한 고객 불만을 피하는 데 도움이 될 수 있음
또한 프로덕션 설정을 미러링하지만 최신 모델 버전을 사용하는 "섀도우 파이프라인"을 유지하는 것을 고려해 볼 것
- 이를 통해 새로운 릴리스로 안전한 실험과 테스트를 수행할 수 있음
이러한 새로운 모델에서 출력의 안정성과 품질을 검증한 후에는 프로덕션 환경에서 모델 버전을 자신 있게 업데이트할 수 있음

작업을 완료할 수 있는 가장 작은 모델 선택하기

새로운 애플리케이션에서 작업할 때 사용 가능한 가장 크고 강력한 모델을 사용하고 싶은 유혹이 있음
- 그러나 일단 작업이 기술적으로 가능하다는 것이 확인되면 더 작은 모델로 유사한 결과를 얻을 수 있는지 실험해 볼 가치가 있음
작은 모델의 장점은 지연 시간과 비용이 낮다는 것
- 더 약할 수 있지만 Chain-of-Thought, n-shot 프롬프트, 문맥 내 학습과 같은 기술은 작은 모델이 자신의 역량 이상으로 성장하는 데 도움이 될 수 있음
LLM API 이상으로 특정 작업에 대한 미세 조정도 성능 향상에 도움이 될 수 있음
종합하면 작은 모델을 사용하여 신중하게 설계된 워크플로우는 더 빠르고 저렴하면서도 단일 대형 모델의 출력 품질과 일치하거나 심지어 능가할 수 있음
- 예를 들어 이 트윗은 Haiku + 10-shot 프롬프트가 제로샷 Opus와 GPT-4를 능가하는 방법에 대한 일화를 공유함
장기적으로 출력 품질, 지연 시간 및 비용의 최적 균형으로 작은 모델을 사용한 흐름 엔지니어링의 더 많은 사례가 나타날 것으로 예상됨
또 다른 예로 겸손한 분류 작업을 들 수 있음
- DistilBERT(6,700만 개 매개변수)와 같은 경량 모델은 놀라울 정도로 강력한 기준선임
- 4억 개 매개변수의 DistilBART는 또 다른 훌륭한 옵션
  - 오픈 소스 데이터에서 미세 조정되면 지연 시간과 비용의 5% 미만으로 대부분의 LLM을 능가하는 0.84의 ROC-AUC로 환각을 식별할 수 있음
요점은 작은 모델을 간과하지 말아야 한다는 것
- 모든 문제에 거대한 모델을 적용하기는 쉽지만 약간의 창의성과 실험으로 우리는 종종 더 효율적인 솔루션을 찾을 수 있음

운영 3. 제품

새로운 기술은 새로운 가능성을 제공하지만 훌륭한 제품을 만드는 원칙은 영원함
- 따라서 처음으로 새로운 문제를 해결하더라도 제품 설계에 대해 바퀴를 다시 발명할 필요는 없음
견고한 제품 기본에 LLM 애플리케이션 개발을 기반으로 함으로써 얻을 수 있는 것이 많음
- 이를 통해 우리가 서비스하는 사람들에게 실제 가치를 제공할 수 있음

초기부터 디자인을 involve하기

디자이너를 두면 제품을 어떻게 구축하고 사용자에게 제시할 수 있는지 이해하고 깊이 생각하게 됨
- 때로는 디자이너를 사물을 예쁘게 만드는 사람으로 고정 관념을 가지기도 함
- 그러나 사용자 인터페이스뿐만 아니라 기존 규칙과 패러다임을 깨더라도 사용자 경험을 어떻게 개선할 수 있는지 재고함
디자이너는 사용자의 요구 사항을 다양한 형태로 재구성하는 데 특히 재능이 있음
- 이러한 형태 중 일부는 다른 형태보다 해결하기가 더 쉬우므로 AI 솔루션에 더 많거나 적은 기회를 제공할 수 있음
다른 많은 제품과 마찬가지로 AI 제품 구축은 제품을 구동하는 기술이 아니라 수행할 작업을 중심으로 이루어져야 함
다음과 같은 질문을 스스로에게 묻는 데 초점을 맞출 것
- "사용자가 이 제품에 요청하는 작업은 무엇인가? 그 작업이 챗봇이 잘할 만한 일인가? 자동 완성은 어떤가? 어쩌면 다른 것일 수도 있다!"
기존 설계 패턴과 그것이 수행할 작업과 어떤 관련이 있는지 고려할 것
- 이것들은 디자이너가 팀의 역량에 더하는 귀중한 자산임

휴먼 인 더 루프를 위한 UX 설계

품질 좋은 주석을 얻는 한 가지 방법은 사용자 경험(UX)에 Human-in-the-Loop(HITL)를 통합하는 것
- 사용자가 쉽게 피드백과 수정 사항을 제공할 수 있도록 하면 즉각적인 출력을 개선하고 모델 개선에 유용한 데이터를 수집할 수 있음
사용자가 제품을 업로드하고 분류하는 전자상거래 플랫폼을 상상해 보자
- UX를 설계하는 방법에는 여러 가지가 있음
  1. 사용자가 수동으로 올바른 제품 범주를 선택하고, LLM이 주기적으로 새 제품을 확인하고 백엔드에서 잘못된 분류를 수정
  2. 사용자는 범주를 전혀 선택하지 않고, LLM이 주기적으로 백엔드에서 제품을 분류(잠재적 오류 포함)
  3. LLM이 실시간으로 제품 범주를 제안하고, 사용자가 필요에 따라 검증 및 업데이트 가능
세 가지 접근 방식 모두 LLM을 포함하지만 매우 다른 UX를 제공함
- 첫 번째 접근 방식은 초기 부담을 사용자에게 지우고 LLM이 사후 처리 검사 역할을 함
- 두 번째 접근 방식은 사용자의 노력이 전혀 필요하지 않지만 투명성이나 제어권을 제공하지 않음
- 세 번째 접근 방식이 적절한 균형을 유지함
  - LLM이 사전에 범주를 제안함으로써 사용자의 인지 부하를 줄이고 제품을 분류하기 위해 우리의 분류법을 배울 필요가 없음
  - 동시에 사용자가 제안을 검토하고 편집할 수 있도록 함으로써 제품 분류 방식에 대한 최종 결정권을 사용자의 손에 단단히 쥐어줌
- 보너스로 세 번째 접근 방식은 모델 개선을 위한 자연스러운 피드백 루프를 만듦
  - 좋은 제안은 수락되고(긍정 레이블) 나쁜 제안은 업데이트됨(부정 후 긍정 레이블)
제안, 사용자 검증 및 데이터 수집의 이 패턴은 여러 애플리케이션에서 일반적으로 볼 수 있음
- 코딩 어시스턴트: 사용자가 제안을 수락(강한 긍정), 수락 및 조정(긍정) 또는 무시(부정)할 수 있음
- Midjourney: 사용자가 이미지를 업스케일하고 다운로드(강한 긍정)하거나, 이미지를 변경(긍정)하거나, 새로운 이미지 세트를 생성(부정)할 수 있음
- 챗봇: 사용자가 응답에 대해 좋아요(긍정) 또는 싫어요(부정)를 제공하거나, 응답이 정말 나쁜 경우 응답을 다시 생성(강한 부정)하도록 선택할 수 있음
피드백은 명시적이거나 암시적일 수 있음
- 명시적 피드백은 사용자가 제품의 요청에 응답하여 제공하는 정보
- 암시적 피드백은 사용자가 의도적으로 피드백을 제공할 필요 없이 사용자 상호 작용에서 배우는 정보
코딩 어시스턴트와 Midjourney는 암시적 피드백의 예이고 좋아요와 싫어요는 명시적 피드백
- 코딩 어시스턴트와 Midjourney처럼 UX를 잘 설계하면 제품과 모델을 개선하기 위한 많은 암시적 피드백을 수집할 수 있음

무자비하게 요구사항 계층(Hierarchy)의 우선순위 지정하기

데모를 프로덕션에 배치하는 것에 대해 생각할 때, 다음에 대한 요구 사항을 고려해야 함
- 신뢰성: 99.9% 가동 시간, 구조화된 출력 준수
- 무해성: 공격적이거나 NSFW 또는 기타 유해한 콘텐츠를 생성하지 않음
- 사실적 일관성: 제공된 맥락에 충실하고 사실을 왜곡하지 않음
- 유용성: 사용자의 요구와 요청에 관련됨
- 확장성: 지연 시간 SLA, 지원되는 처리량
- 비용: 예산이 무제한이 아니기 때문
- 기타: 보안, 개인 정보 보호, 공정성, GDPR, DMA 등
이러한 모든 요구 사항을 한 번에 해결하려고 하면 아무것도 출시할 수 없음
- 따라서 우선순위를 정해야 함. 무자비하게.
이는 제품이 작동하지 않거나 실행 가능하지 않을 수 있는 타협할 수 없는 사항(예: 신뢰성, 무해성)이 무엇인지 명확히 하는 것을 의미함
- MVP(Minimum Lovable Product) 제품을 식별하는 것이 중요함
첫 번째 버전이 완벽하지 않을 것이라는 점을 받아들이고 출시하고 반복해야 함

사용 사례에 따른 위험 감수 수준 조정

언어 모델과 애플리케이션의 검토 수준을 결정할 때는 사용 사례와 대상을 고려해야 함
- 의료 또는 금융 조언을 제공하는 고객 대면 챗봇의 경우 안전성과 정확성에 대해 매우 높은 기준이 필요함
  - 실수나 잘못된 출력은 실제 피해를 일으키고 신뢰를 잃을 수 있음
- 그러나 추천 시스템과 같은 덜 중요한 애플리케이션이나 콘텐츠 분류 또는 요약과 같은 내부 대면 애플리케이션의 경우 지나치게 엄격한 요구 사항은 많은 가치를 추가하지 않고 진전을 늦출 뿐임
이는 많은 회사가 외부 애플리케이션에 비해 내부 LLM 애플리케이션으로 더 빠르게 움직이고 있다는 최근 a16z 보고서와 일치함
- 내부 생산성을 위해 AI를 실험함으로써 조직은 더 통제된 환경에서 위험을 관리하는 방법을 배우면서 가치를 포착하기 시작할 수 있음
- 그런 다음 자신감이 생기면 고객 대면 사용 사례로 확장할 수 있음

운영 4. 팀과 역할(Roles)

어떤 직무도 정의하기 쉽지 않지만, 이 새로운 영역에서 업무에 대한 직무 기술서를 작성하는 것은 다른 것보다 더 어려움
- 교차하는 직책에 대한 벤 다이어그램이나 직무 기술에 대한 제안은 생략하겠음
- 그러나 새로운 역할인 AI 엔지니어의 존재를 인정하고 그 역할에 대해 논의할 것임
중요한 것은 나머지 팀과 책임이 어떻게 할당되어야 하는지에 대해 논의할 것임

도구가 아닌 프로세스에 집중

LLM과 같은 새로운 패러다임에 직면했을 때 소프트웨어 엔지니어는 도구를 선호하는 경향이 있음
- 그 결과 도구가 해결하려고 했던 문제와 프로세스를 간과하게 됨
- 이렇게 하면서 많은 엔지니어는 우발적 복잡성을 가정하게 되는데, 이는 팀의 장기적인 생산성에 부정적인 결과를 초래함
예를 들어 이 글은 특정 도구가 대규모 언어 모델에 대한 프롬프트를 자동으로 생성할 수 있는 방법에 대해 설명함
- 문제 해결 방법론이나 프로세스를 먼저 이해하지 않고 이러한 도구를 사용하는 엔지니어는 결국 불필요한 기술 부채를 떠안게 된다고 주장함(IMHO 정당하게)
우발적 복잡성 외에도 도구는 종종 불충분하게 지정됨
- 예를 들어 유해성, 간결성, 어조 등에 대한 일반 평가기와 함께 "LLM 평가 도구 상자"를 제공하는 LLM 평가 도구 산업이 성장하고 있음
- 많은 팀이 자신의 도메인의 특정 실패 모드에 대해 비판적으로 생각하지 않고 이러한 도구를 채택하는 것을 봄
이와 대조적으로 EvalGen은 사용자를 기준 지정, 데이터 레이블링, 평가 확인 등 각 단계에 깊이 참여시켜 도메인별 평가를 생성하는 프로세스를 사용자에게 가르치는 데 중점을 둠
- 소프트웨어는 사용자를 다음과 같은 워크플로우로 안내함
EvalGen이 안내하는 LLM 평가 제작의 모범 사례
1. 도메인별 테스트 정의(프롬프트에서 자동으로 부트스트랩됨)
  - 코드 또는 LLM-as-a-Judge로 어설션으로 정의됨
2. 테스트가 지정된 기준을 포착하는지 사용자가 확인할 수 있도록 테스트를 인간의 판단과 일치시키는 것의 중요성
3. 시스템(프롬프트 등)이 변경됨에 따라 테스트 반복
EvalGen은 개발자에게 평가 구축 프로세스에 대한 멘탈 모델을 제공하지만 특정 도구에 고정하지는 않음
- AI 엔지니어에게 이러한 맥락을 제공한 후에는 종종 더 간단한 도구를 선택하거나 자체 도구를 구축하기로 결정한다는 것을 발견함
프롬프트 작성 및 평가 이외에 LLM의 구성 요소가 너무 많아 여기에 모두 나열할 수 없음
- 그러나 AI 엔지니어가 도구를 채택하기 전에 프로세스를 이해하려고 노력하는 것이 중요함

항상 실험하기

ML 제품은 실험과 깊이 연관되어 있음
- A/B 테스트, 무작위 대조 시험뿐만 아니라 시스템의 가능한 가장 작은 구성 요소를 수정하고 오프라인 평가를 수행하는 빈번한 시도를 의미함
- 모두가 평가에 열광하는 이유는 실제로 신뢰성과 자신감에 관한 것이 아니라 실험을 가능하게 하는 것임!
  - 평가가 더 좋을수록 실험을 더 빨리 반복할 수 있고, 따라서 시스템의 최상의 버전으로 더 빨리 수렴할 수 있음
실험이 매우 저렴해졌기 때문에 동일한 문제를 해결하기 위해 다양한 접근 방식을 시도하는 것이 일반적임
- 데이터 수집 및 모델 훈련의 높은 비용은 최소화됨
  - 프롬프트 엔지니어링 비용은 인간의 시간보다 조금 더 들음
- 모든 사람이 프롬프트 엔지니어링의 기본을 배울 수 있도록 팀을 배치할 것
  - 이는 모든 사람이 실험하도록 장려하고 조직 전체에서 다양한 아이디어로 이어짐
탐색을 위해서만 실험하지 말고 활용을 위해서도 실험을 사용할 것!
- 새로운 작업의 작동 버전이 있는가?
  - 팀의 다른 사람이 다른 방식으로 접근하는 것을 고려해 볼 것
- 더 빠를 수 있는 다른 방법으로 해보기
- Chain-of-Thought나 Few-Shot과 같은 프롬프트 기술을 조사하여 품질을 높일 것
- 도구가 실험을 방해하지 않도록 할 것
  - 그렇다면 재구축하거나 개선할 수 있는 것을 구매할 것
제품/프로젝트 기획 중에는 평가 구축 및 여러 실험 수행을 위한 시간을 따로 할애할 것
- 엔지니어링 제품에 대한 제품 사양을 생각해 보고, 여기에 평가에 대한 명확한 기준을 추가할 것
로드맵 작성 시 실험에 필요한 시간을 과소평가하지 말 것
- 프로덕션 승인을 받기 전에 여러 번의 개발 및 평가 반복을 예상할 것

모든 사람이 새로운 AI 기술을 사용할 수 있도록 권한 부여

생성형 AI의 채택이 증가함에 따라 전문가뿐만 아니라 전체 팀이 이 새로운 기술을 이해하고 사용할 수 있다고 느끼기를 원함
- LLM이 어떻게 작동하는지(예: 지연 시간, 실패 모드, UX)에 대한 직관을 개발하는 더 좋은 방법은 없음
- LLM은 비교적 접근하기 쉬움
  - 파이프라인의 성능을 향상시키기 위해 코딩 방법을 알 필요가 없으며, 모든 사람이 프롬프트 엔지니어링 및 평가를 통해 기여할 수 있음
이 중 큰 부분은 교육임
- n-shot 프롬프팅 및 CoT와 같은 기술이 모델을 원하는 출력 방향으로 조건화하는 데 도움이 되는 프롬프트 엔지니어링의 기초부터 시작할 수 있음
지식을 가진 사람들은 LLM이 본질적으로 자기회귀적이라는 점과 같은 보다 기술적인 측면에 대해서도 교육할 수 있음
- 즉, 입력 토큰은 병렬로 처리되지만 출력 토큰은 순차적으로 생성됨
- 따라서 지연 시간은 입력 길이보다 출력 길이의 함수임
  - 이는 UX를 설계하고 성능 기대치를 설정할 때 주요 고려 사항임
실험과 탐색을 위한 실습 기회를 제공할 수도 있음
- 해커톤은 어떨까?
  - 전체 팀이 며칠 동안 추측성 프로젝트를 해킹하는 데 시간을 보내는 것이 비싸 보일 수 있지만, 그 결과는 당신을 놀라게 할 수 있음
- 해커톤을 통해 3년 로드맵을 1년 안에 거의 완료한 팀이 있음
  - 또 다른 팀은 해커톤을 통해 LLM 덕분에 이제 가능해진 패러다임을 전환하는 UX로 이어졌으며, 이제 올해와 그 이후의 우선 순위가 되었음

"AI 엔지니어링이 모든 것"이라는 함정에 빠지지 말 것

새로운 직책이 생겨날 때 이러한 역할과 관련된 능력을 과대평가하는 경향이 초기에 있음
- 이는 종종 이러한 직업의 실제 범위가 명확해짐에 따라 고통스러운 수정으로 이어짐
- 이 분야의 신참자와 채용 관리자는 과장된 주장을 하거나 과도한 기대를 할 수 있음
지난 10년 동안의 주목할 만한 예는 다음과 같음
- 데이터 과학자: "모든 소프트웨어 엔지니어보다 통계학을 더 잘하고 모든 통계학자보다 소프트웨어 엔지니어링을 더 잘하는 사람"
- 머신러닝 엔지니어(MLE): 머신러닝에 대한 소프트웨어 엔지니어링 중심의 관점
처음에는 많은 사람들이 데이터 기반 프로젝트에는 데이터 과학자만으로 충분하다고 가정함
- 그러나 데이터 과학자는 데이터 제품을 효과적으로 개발하고 배포하기 위해 소프트웨어 및 데이터 엔지니어와 협력해야 한다는 것이 분명해짐
이 오해는 AI 엔지니어라는 새로운 역할에서도 다시 나타났으며, 일부 팀은 AI 엔지니어가 필요한 전부라고 믿음
- 실제로 머신러닝 또는 AI 제품을 구축하려면 광범위한 전문 역할이 필요함
우리는 12개 이상의 회사와 AI 제품에 대해 상담했으며, 그들이 "AI 엔지니어링이 필요한 전부"라는 믿음의 함정에 빠지는 것을 일관되게 관찰함
- 그 결과 제품 구축에 필요한 중요한 측면을 간과하면서 제품이 데모 이상으로 확장하는 데 어려움을 겪는 경우가 많음
예를 들어 평가 및 측정은 Vibe 체크 이상으로 제품을 확장하는 데 중요함
- 효과적인 평가를 위한 기술은 전통적으로 머신러닝 엔지니어에게서 볼 수 있는 강점 중 일부와 일치함
  - AI 엔지니어로만 구성된 팀은 이러한 기술이 부족할 가능성이 높음
공동 저자인 Hamel Husain은 데이터 편향 감지 및 도메인 특정 평가 설계와 관련된 최근 작업에서 이러한 기술의 중요성을 설명함
AI 제품 구축 여정에서 필요한 역할 유형 및 시기
1. 먼저 제품 구축에 집중할 것
- AI 엔지니어가 포함될 수 있지만 반드시 필요한 것은 아님
- AI 엔지니어는 제품(UX, 배관 등)을 프로토타이핑하고 신속하게 반복하는 데 유용함
1. 다음으로 시스템을 계측하고 데이터를 수집하여 올바른 기반을 만들 것
- 데이터 유형과 규모에 따라 플랫폼 및/또는 데이터 엔지니어가 필요할 수 있음
- 또한 문제를 디버깅하기 위해 이 데이터를 쿼리하고 분석하는 시스템이 있어야 함
1. 다음으로 AI 시스템을 최적화할 것
- 이는 반드시 모델 훈련을 포함하지는 않음
- 기본 사항에는 지표 설계, 평가 시스템 구축, 실험 실행, RAG 검색 최적화, 확률적 시스템 디버깅 등의 단계가 포함됨
- MLE는 이 분야에 매우 능숙함(물론 AI 엔지니어도 습득할 수 있음)
- 선행 단계를 완료하지 않은 경우 MLE를 고용하는 것은 보통 타당하지 않음
이 외에도 항상 도메인 전문가가 필요함
- 작은 회사에서는 이상적으로 창업팀이 이 역할을 해야 하며, 큰 회사에서는 제품 관리자가 이 역할을 할 수 있음
역할의 진행 및 타이밍을 인식하는 것이 중요함
- 잘못된 시기에 사람들을 고용하거나(예: MLE를 너무 일찍 고용) 잘못된 순서로 구축하는 것은 시간과 비용 낭비이며 이직을 야기함
또한 1-2단계에서 MLE와 정기적으로 체크인(그러나 정규직으로 고용하지는 않음)하면 회사가 올바른 기반을 구축하는 데 도움이 됨

[전략: LLM을 활용한 구축에서 뒤처지지 않는 방법]

성공적인 제품 개발을 위해서는 무작정 프로토타입을 만들거나 최신 모델이나 트렌드를 따라가기보다는 신중한 기획과 우선순위 설정이 필요함
AI 제품 개발 시 직접 개발할 것인지 구매할 것인지 등의 주요 트레이드오프를 검토해야 함
초기 LLM 애플리케이션 개발을 위한 "플레이북"을 제시함

전략 1: PMF 전에는 GPU 없음

훌륭한 제품이 되려면 단순히 다른 사람의 API를 얇게 포장하는 것 이상이 되어야 함
하지만 반대 방향의 실수는 더 큰 비용을 초래할 수 있음
- 지난 해에는 명확한 제품 비전이나 목표 시장 없이 모델 학습과 커스터마이징에 막대한 벤처 자본이 쓰여졌음
- 한 회사는 무려 60억 달러의 시리즈 A 투자를 받기도 함
이 섹션에서는 즉시 자체 모델 학습을 시작하는 것이 왜 실수인지 설명하고, 자체 호스팅의 역할을 고려해 볼 것임

처음부터 (거의) 다시 트레이닝 하는 것은 의미 없음

대부분의 조직에게 처음부터 LLM을 프리트레이닝하는 것은 제품 개발에서 벗어난 비현실적인 일임
- 머신러닝 인프라의 개발과 유지에는 많은 자원이 소요됨
  - 데이터 수집, 모델 학습과 평가, 배포 등이 포함됨
- 제품-시장 적합성을 검증하는 단계라면 이러한 노력은 핵심 제품 개발에서 자원을 분산시킴
- 컴퓨팅 자원, 데이터, 기술적 역량이 있다 해도 프리트레인된 LLM은 몇 달 안에 구식이 될 수 있음
BloombergGPT의 사례
- 금융 업무에 특화된 LLM인 BloombergGPT는 363B 토큰으로 프리트레이닝되었음
- AI 엔지니어링 4명, ML 제품 및 연구 5명 등 9명의 전임 직원들의 엄청난 노력이 투입됨
- 그럼에도 1년 내에 해당 업무에서 gpt-3.5-turbo와 gpt-4에 뒤쳐졌음
이런 사례들은 대부분의 실제 애플리케이션에서 LLM을 처음부터 프리트레이닝하는 것이 자원의 최선의 활용법이 아님을 시사함
- 대신 팀은 특정 요구사항에 맞춰 사용 가능한 가장 강력한 오픈소스 모델을 파인튜닝하는 것이 더 나음
물론 예외는 있음
- Replit의 코드 모델은 코드 생성과 이해에 특화되어 프리트레이닝된 훌륭한 사례임
- 프리트레이닝으로 CodeLlama7b 등 더 큰 모델보다 우수한 성능을 보였음
- 그러나 더 강력한 모델들이 출시됨에 따라 효용성 유지를 위해서는 지속적인 투자가 필요했음

필요하다고 확인되기 전까지는 파인튜닝 금지

대부분의 조직에서 파인튜닝은 전략적 사고보다는 FOMO(Fear Of Missing Out, 놓칠 것에 대한 두려움)에 의해 주도됨
- 조직은 "단순한 래퍼"라는 비난을 피하기 위해 너무 일찍 파인튜닝에 투자함
- 실제로 파인튜닝은 다른 접근 방식으로는 충분하지 않다는 것을 확신시켜주는 많은 사례를 수집한 후에야 배포해야 할 중장비와 같음
1년 전 많은 팀이 파인튜닝에 대해 기대감을 표했지만, 몇 안 되는 팀만이 제품-시장 적합성을 발견했고 대부분은 결정을 후회함
- 파인튜닝을 할 거라면 기본 모델이 개선됨에 따라 반복해서 수행할 준비가 되어 있어야 함
  - 아래의 "모델은 제품이 아님"과 "LLMOps 구축"을 참조
파인튜닝이 실제로 올바른 선택일 수 있는 경우
- 기존 모델 학습에 사용된 대부분의 개방형 웹 규모 데이터셋에서 사용할 수 없는 데이터가 필요한 경우
- 기존 모델로는 충분하지 않다는 것을 보여주는 MVP를 이미 구축한 경우
- 그러나 주의해야 함: 훌륭한 학습 데이터를 모델 구축자가 쉽게 얻을 수 없다면 당신은 어디서 얻을 것인가?
LLM 기반 애플리케이션은 과학 박람회 프로젝트가 아님
- 전략적 목표와 경쟁 차별화에 대한 기여도에 상응하는 투자가 이루어져야 함

추론 API로 시작하되, 셀프호스팅을 두려워하지 말 것

LLM API를 사용하면 스타트업이 처음부터 자체 모델을 학습시키지 않고도 언어 모델링 기능을 쉽게 채택하고 통합할 수 있음
- Anthropic, OpenAI 등의 제공업체는 몇 줄의 코드만으로 제품에 인텔리전스를 부여할 수 있는 일반 API를 제공함
- 이러한 서비스를 사용하면 노력을 줄이고 고객을 위한 가치 창출에 집중할 수 있어 아이디어를 검증하고 제품-시장 적합성을 더 빨리 반복할 수 있음
그러나 데이터베이스와 마찬가지로 관리형 서비스는 규모와 요구사항이 증가함에 따라 모든 사용 사례에 적합하지 않음
- 실제로 자체 호스팅은 의료 및 금융과 같은 규제 산업 또는 계약상 의무나 기밀 유지 요건에 의해 요구되는 대로 기밀/개인 데이터를 네트워크 외부로 보내지 않고 모델을 사용하는 유일한 방법일 수 있음
또한 자체 호스팅은 추론 제공업체가 부과하는 속도 제한, 모델 사용 중단, 사용 제한 등의 제약을 우회함
- 자체 호스팅은 모델에 대한 완전한 제어 권한을 제공하여 차별화되고 고품질의 시스템을 더 쉽게 구축할 수 있게 함
마지막으로 자체 호스팅, 특히 파인튜닝은 대규모로 비용을 절감할 수 있음
- 예를 들어 Buzzfeed는 오픈소스 LLM을 파인튜닝하여 비용을 80% 절감한 사례를 공유했음

전략 2: 더 나은 것을 향해 반복하기

장기적으로 경쟁 우위를 유지하려면 모델을 넘어서 제품을 차별화할 수 있는 요소를 고려해야 함
실행 속도가 중요하지만 그것이 유일한 장점이 되어서는 안 됨

모델은 제품이 아님, 그 모델을 둘러싼 시스템이 제품임

모델을 구축하지 않는 팀에게 혁신의 빠른 속도는 축복임
- 컨텍스트 크기, 추론 능력, 가격 대비 가치 등의 향상을 추구하며 최신 모델로 마이그레이션하여 더 나은 제품을 만들 수 있기 때문
- 이러한 진보는 예측 가능할 만큼 흥미로움
- 종합하면 모델은 시스템에서 가장 지속성이 낮은 구성 요소일 가능성이 높음
대신 지속적인 가치를 제공할 수 있는 부분에 노력을 집중해야 함
- Evals: 모델 전반에 걸쳐 작업 성능을 안정적으로 측정하기 위함
- Guardrails: 모델에 상관없이 원치 않는 출력을 방지하기 위함
- Caching: 모델을 완전히 피함으로써 지연 시간과 비용을 줄이기 위함
- Data flywheel: 위의 모든 것의 반복적 개선을 추진하기 위함
- 이러한 구성 요소는 원시 모델 기능보다 더 두꺼운 제품 품질의 해자를 만듦
그러나 애플리케이션 계층에서 구축하는 것이 위험이 없다는 의미는 아님
- OpenAI나 다른 모델 제공업체가 실행 가능한 엔터프라이즈 소프트웨어를 제공하려면 가위로 잘라내야 할 부분에 가위질하지 말 것
예를 들어 일부 팀은 독점 모델에서 구조화된 출력을 검증하기 위한 맞춤형 도구를 구축하는 데 투자했음
- 여기에 최소한의 투자는 중요하지만 깊이 투자하는 것은 시간을 잘 활용하는 것이 아님
- OpenAI는 함수 호출을 요청할 때 유효한 함수 호출을 받을 수 있도록 해야 함. 모든 고객이 원하기 때문
- 여기에 "전략적 미루기"를 적용하고, 절대적으로 필요한 것을 구축하고, 제공업체의 기능 확장을 기다릴 것

작게 시작해서 신뢰를 얻기

모든 사람을 위한 모든 것이 되려고 하는 제품을 만드는 것은 평범함의 레시피임
설득력 있는 제품을 만들기 위해 기업은 사용자가 계속 돌아오게 하는 끈적거리는 경험을 구축하는 데 전문화해야 함
사용자가 묻는 모든 질문에 답하는 것을 목표로 하는 일반적인 RAG 시스템을 고려해 보자
- 전문화가 부족하다는 것은 시스템이 최신 정보에 우선순위를 두거나, 도메인 특화 형식을 구문 분석하거나, 특정 작업의 뉘앙스를 이해할 수 없다는 것을 의미함
- 그 결과 사용자는 얕고 신뢰할 수 없는 경험을 하게 되어 요구사항을 충족시키지 못하고 이탈하게 됨
이를 해결하기 위해 특정 도메인과 사용 사례에 집중해야 함
- 넓이보다는 깊이를 더해 범위를 좁혀야 함
- 이렇게 하면 사용자에게 공감을 주는 도메인 특화 도구를 만들 수 있음
전문화를 통해 시스템의 기능과 한계를 솔직하게 알릴 수 있음
- 시스템이 할 수 있는 것과 할 수 없는 것에 대해 투명하게 공개하는 것은 자기 인식을 보여주고, 사용자가 어디에 가장 많은 가치를 더할 수 있는지 이해하는 데 도움이 되며, 결과적으로 출력에 대한 신뢰와 확신을 구축함

LLMOps를 만들되, 적절한 이유를 가질 것 : 빠른 반복

DevOps는 근본적으로 재현 가능한 워크플로우나 왼쪽 이동 또는 두 개의 피자 팀에 권한을 부여하는 것이 아님. YAML 파일을 작성하는 것은 더더욱 아님
DevOps는 작업과 그 결과 사이의 피드백 주기를 단축하여 오류 대신 개선 사항이 축적되도록 하는 것임
- 그 뿌리는 린 스타트업 운동을 통해 린 제조와 토요타 생산 시스템으로 거슬러 올라가며, 싱글 미닛 다이 교환과 카이젠을 강조함
MLOps는 DevOps의 형태를 ML에 적용했음
- 재현 가능한 실험과 모델 구축자가 배포할 수 있도록 권한을 부여하는 올인원 도구 제품군이 있음. YAML 파일도 많음
그러나 업계로서 MLOps는 DevOps의 기능을 채택하지 않았음. 모델과 프로덕션에서의 추론 및 상호 작용 사이의 피드백 갭을 줄이지 않았음
다행히도 LLMOps 분야는 프롬프트 관리와 같은 사소한 문제에서 벗어나 반복을 방해하는 어려운 문제인 프로덕션 모니터링과 평가로 연결되는 지속적인 개선으로 방향을 전환했음
이미 채팅 및 코딩 모델에 대한 중립적이고 크라우드소싱된 평가를 위한 대화형 아레나가 있음. 집단적이고 반복적인 개선의 외부 루프임
- LangSmith, Log10, LangFuse, W&B Weave, HoneyHive 등의 도구는 프로덕션에서 시스템 결과에 대한 데이터를 수집하고 정리할 뿐만 아니라 개발과 깊이 통합하여 해당 시스템을 개선하는 데 활용할 것을 약속함. 이러한 도구를 수용하거나 자체적으로 구축하라

구매할 수 있는 LLM 기능을 만들지 말 것

대부분의 성공적인 비즈니스는 LLM 비즈니스가 아님. 동시에 대부분의 비즈니스에는 LLM으로 개선할 기회가 있음
이 두 가지 관찰은 종종 리더를 오도하여 비용은 늘리고 품질은 떨어뜨리면서 LLM으로 시스템을 성급하게 개조하고 인조의 허영심 강한 "AI" 기능으로 출시하게 만듦. 지금은 두려워하는 반짝이 아이콘이 완성됨
더 나은 방법이 있음: 제품 목표에 진정으로 부합하고 핵심 운영을 강화하는 LLM 애플리케이션에 집중할 것
팀의 시간을 낭비하는 몇 가지 잘못된 시도를 고려해 보자
- 비즈니스를 위한 맞춤형 text-to-SQL 기능 구축
- 문서와 대화할 수 있는 챗봇 구축
- 회사 지식 베이스를 고객 지원 챗봇과 통합
위의 사항들이 LLM 애플리케이션의 헬로 월드이지만 제품 회사가 직접 구축하는 것은 이치에 맞지 않음
- 이는 많은 비즈니스에 공통된 일반적인 문제로 유망한 데모와 신뢰할 수 있는 구성 요소 사이의 격차가 크며 소프트웨어 회사의 관례적 영역임
- 현재 Y Combinator 배치에서 대규모로 해결하고 있는 일반적인 문제에 귀중한 R&D 자원을 투자하는 것은 낭비임
이것이 진부한 비즈니스 조언처럼 들린다면 현재 과대 광고 물결의 들뜬 흥분 속에서 "LLM"이라는 것을 최첨단의 차별화된 것으로 오해하기 쉽고 이미 낡아빠진 애플리케이션을 놓치기 쉽기 때문임

AI를 루프안에 넣고, 사람을 중심에 둘 것

현재 LLM 기반 애플리케이션은 취약함. 엄청난 양의 안전 조치와 방어적 엔지니어링이 필요하지만 여전히 예측하기 어려움. 게다가 엄격하게 범위가 지정되면 이러한 애플리케이션은 엄청나게 유용할 수 있음. 이는 LLM이 사용자 워크플로를 가속화하는 훌륭한 도구가 된다는 것을 의미함
LLM 기반 애플리케이션이 워크플로를 완전히 대체하거나 직무 기능을 대신하는 것을 상상하고 싶을 수 있지만, 오늘날 가장 효과적인 패러다임은 인간-컴퓨터 켄타우로스(Centaur chess)임
- 유능한 인간이 자신의 빠른 활용을 위해 조정된 LLM 기능과 결합하면 작업을 수행하는 생산성과 행복감이 크게 향상될 수 있음
- LLM의 대표적인 애플리케이션 중 하나인 GitHub CoPilot은 이러한 워크플로의 힘을 입증했음
  - "전반적으로 개발자들은 GitHub Copilot과 GitHub Copilot Chat을 사용할 때 코딩이 더 쉽고, 오류가 적으며, 가독성이 높고, 재사용성이 높으며, 간결하고, 유지 관리가 용이하며, 탄력적이라고 느꼈다고 말했습니다." - Mario Rodriguez, GitHub
오랫동안 ML 작업을 해온 사람들은 "human-in-the-loop"라는 아이디어에 빠르게 도달할 수 있지만 그렇게 서두르지 말 것
- HITL 머신러닝은 ML 모델이 예측대로 동작하도록 보장하는 인간 전문가에 기반한 패러다임임
- 여기서 제안하는 것은 관련되기는 하지만 더 미묘한 것임. LLM 기반 시스템은 오늘날 대부분의 워크플로의 주요 동력이 되어서는 안 되며, 단순히 자원이 되어야 함
인간을 중심에 두고 LLM이 어떻게 워크플로를 지원할 수 있는지 묻는 것은 제품 및 설계 결정에 상당히 다른 영향을 미침
- 궁극적으로 LLM에 모든 책임을 신속하게 아웃소싱하려는 경쟁업체와는 다른 제품, 즉 더 나은 제품, 더 유용하고 덜 위험한 제품을 만들게 될 것임

전략 3. 프롬프팅, Eval, 데이터 수집으로 시작하기

이전 섹션에서는 기술과 조언의 화력을 쏟아부었음. 받아들이기에 많은 양임. 유용한 조언의 최소 집합을 고려해 보자.
- 팀이 LLM 제품을 만들고 싶다면 어디서부터 시작해야 할까?
지난 1년 동안 성공적인 LLM 애플리케이션은 일관된 궤적을 따른다는 것을 확신할 만큼 충분히 봐왔음. 이 섹션에서는 이 기본적인 "시작하기" 플레이북을 살펴볼 것임
핵심 아이디어는 간단하게 시작하고 필요에 따라 복잡성을 추가하는 것임
- Rule of Thumb : 각 수준의 정교함은 일반적으로 이전 단계보다 최소한 한 자릿수 이상의 노력이 필요하다는 것임. 이를 염두에 두고...

프롬프트 엔지니어링이 1순위

프롬프트 엔지니어링부터 시작할 것
- 이전에 전술 섹션에서 논의한 모든 기술을 사용할 것
- Chain-of-thought, n-shot 예제, 구조화된 입출력은 거의 항상 좋은 아이디어임
- 약한 모델에서 성능을 짜내기 전에 가장 성능이 높은 모델로 프로토타입을 만들 것
프롬프트 엔지니어링으로 원하는 성능 수준을 달성할 수 없는 경우에만 파인튜닝을 고려해야 함
- 독점 모델 사용을 차단하고 자체 호스팅을 요구하는 비기능적 요구사항(예: 데이터 프라이버시, 완전한 제어, 비용)이 있는 경우 더 자주 발생할 것임
- 동일한 프라이버시 요구사항이 파인튜닝을 위해 사용자 데이터 사용을 차단하지 않도록 주의할 것

평가를 만들고 데이터 플라이휠 시작하기

막 시작하는 팀도 평가(evals)가 필요함. 그렇지 않으면 프롬프트 엔지니어링이 충분한지 또는 파인튜닝된 모델이 기본 모델을 대체할 준비가 되었는지 알 수 없음
효과적인 평가는 작업에 특화되어 있으며 의도한 사용 사례를 반영함
- 권장하는 첫 번째 수준의 평가는 단위 테스트임
- 이러한 간단한 어설션은 알려졌거나 가설로 설정된 실패 모드를 감지하고 초기 설계 결정을 내리는 데 도움이 됨
- 분류, 요약 등을 위한 다른 작업별 평가도 참조할 것
단위 테스트와 모델 기반 평가는 유용하지만 인간 평가의 필요성을 대체하지는 않음
- 사람들이 모델/제품을 사용하고 피드백을 제공하도록 할 것
- 이는 실제 성능과 결함률을 측정하는 동시에 향후 모델을 파인튜닝하는 데 사용할 수 있는 고품질의 주석 데이터를 수집한다는 이중 목적을 수행함
- 이는 시간이 지남에 따라 복리로 작용하는 긍정적인 피드백 루프 또는 데이터 플라이휠을 만듦
  - 모델 성능을 평가하거나 결함을 찾기 위한 인간 평가
  - 주석 데이터를 사용하여 모델을 파인튜닝하거나 프롬프트를 업데이트
  - 반복
예를 들어 LLM 생성 요약의 결함을 감사할 때 각 문장에 사실적 불일치, 무관함 또는 스타일 불량을 식별하는 세분화된 피드백 레이블을 지정할 수 있음
- 그런 다음 이러한 사실적 불일치 주석을 사용하여 환각 분류기를 학습시키거나 관련성 주석을 사용하여 관련성 보상 모델을 학습시킬 수 있음
LinkedIn은 환각, 책임감 있는 AI 위반, 일관성 등을 추정하기 위해 모델 기반 평가자를 사용한 성공 사례를 공유했음
시간이 지남에 따라 가치가 증대되는 자산을 창출함으로써, 평가(evals) 구축을 단순한 운영 비용에서 전략적 투자로 전환하고, 그 과정에서 데이터 플라이휠을 구축

전략 4. 저비용 인지의 고차원적 추세 (The high-level trend of low-cost cognition)

1971년 Xerox PARC의 연구원들은 우리가 현재 살고 있는 네트워크로 연결된 개인용 컴퓨터의 세계를 예측했음
- 그들은 이를 가능하게 한 기술(이더넷, 그래픽 렌더링, 마우스, 윈도우 등)의 발명에 중추적인 역할을 함으로써 그 미래를 탄생시키는 데 기여했음
그들은 또한 간단한 연습을 했음
- 매우 유용하지만(예: 비디오 디스플레이) 아직 경제적이지 않은(비디오 디스플레이를 구동하기에 충분한 RAM이 수천 달러) 애플리케이션을 살펴봄
- 그런 다음 해당 기술의 역사적 가격 추세(무어의 법칙과 유사)를 살펴보고 그 기술이 언제 경제적이 될지 예측함
LLM 기술에 대해서도 같은 작업을 할 수 있음. 비록 달러당 트랜지스터 수만큼 깔끔한 것은 아니지만
- 오랫동안 사용된 인기 있는 벤치마크(예: Massively-Multitask Language Understanding 데이터셋)와 일관된 입력 접근 방식(5-shot 프롬프팅)을 선택
- 그런 다음 시간이 지남에 따라 이 벤치마크에서 다양한 성능 수준을 가진 언어 모델을 실행하는 비용을 비교
고정 비용에 대해 능력이 빠르게 증가하고 있음. 고정된 능력 수준에 대해 비용이 빠르게 감소하고 있음
- OpenAI의 davinci 모델이 API로 출시된 이후 4년 동안, 100만 토큰(이 문서의 약 100개 사본) 규모에서 그 작업에 상응하는 성능을 가진 모델을 실행하는 비용은 $20에서 10센트 미만으로 떨어졌음. 반감기는 불과 6개월임
- 유사하게 2024년 5월 기준 API 제공업체를 통하거나 자체적으로 Meta의 LLaMA 3 8B를 실행하는 비용은 토큰 100만 개당 20센트에 불과하며 ChatGPT를 가능하게 한 모델인 OpenAI의 text-davinci-003과 유사한 성능을 보임
- 해당 모델은 2023년 11월 말 출시 당시에도 토큰 100만 개당 약 $20의 비용이 들었음. 불과 18개월 만에 두 자릿수 차이가 남. 무어의 법칙이 예측하는 단순한 두 배 증가와 동일한 기간임
이제 매우 유용하지만(Park et al과 같은 생성적 비디오 게임 캐릭터 구동) 아직 경제적이지 않은(시간당 비용이 $625로 추정됨) LLM 애플리케이션을 고려해 보자
- 해당 논문이 2023년 8월에 발표된 이후 비용은 시간당 약 $62.50로 한 자릿수 정도 떨어졌음
- 9개월 후에는 시간당 $6.25로 떨어질 것으로 예상할 수 있음
한편 팩맨이 1980년에 출시되었을 때 오늘날의 $1로 몇 분 또는 몇 십 분 동안 플레이할 수 있는 크레딧을 살 수 있었음. 시간당 6게임 또는 시간당 $6라고 부름
- 이 냅킨 계산은 매력적인 LLM 강화 게임 경험이 2025년 경에는 경제적이 될 것임을 시사함
이러한 추세는 새로운 것이며 불과 몇 년 되지 않았음. 그러나 앞으로 몇 년 동안 이 과정이 느려질 것이라고 기대할 만한 이유는 거의 없음
- 매개변수당 ~20 토큰의 "Chinchilla 비율"을 넘어 스케일링하는 것과 같은 알고리즘과 데이터셋의 낮게 매달린 과일을 사용하더라도, 데이터 센터 내부와 실리콘 계층에서의 더 깊은 혁신과 투자는 그 격차를 메울 것임
그리고 이것이 아마도 가장 중요한 전략적 사실일 것임
- 오늘날 완전히 실현 불가능한 플로어 데모나 연구 논문이 몇 년 후에는 프리미엄 기능이 되고 그 직후에는 상품이 될 것임
- 이를 염두에 두고 시스템과 조직을 구축해야 함

[0에서 1로 가는 데모는 이제 충분함. 이제는 1에서 N으로 가는 제품을 만들 때]

LLM 데모를 만드는 것은 정말 재미있음. 몇 줄의 코드, 벡터 데이터베이스, 신중하게 작성된 프롬프트로 "마법" 을 만들어냄
지난 1년 동안 이 마법은 인터넷, 스마트폰, 심지어 인쇄술과 비교되었음
안타깝게도 실제 소프트웨어 출시 작업을 해본 사람이라면 누구나 알고 있듯이, 통제된 환경에서 작동하는 데모와 대규모로 안정적으로 작동하는 제품 사이에는 엄청난 차이가 있음
상상하고 데모를 만드는 것은 쉽지만 제품으로 만드는 것은 매우 어려운 문제들이 많음
- 예를 들어 자율 주행: 자동차가 한 블록을 자율 주행하는 것은 쉽게 시연할 수 있지만, 이를 제품으로 만드는 데는 10년이 걸림 - Andrej Karpathy
자율 주행차를 예로 들어보자
- 1988년 신경망으로 운전되는 첫 번째 자동차가 등장했음
- 25년 후 Andrej Karpathy는 Waymo에서 첫 번째 데모 라이드를 했음
- 그로부터 10년 후 회사는 무인 운전 허가를 받았음
- 프로토타입에서 상용 제품으로 가기까지 35년 동안 엄격한 엔지니어링, 테스트, 개선, 규제 탐색이 이루어졌음
산업계와 학계 전반에 걸쳐 지난 1년 동안의 기복을 관찰했음 : LLM 애플리케이션의 1년차 (Year 1 of N for LLM applications)
- 평가, 프롬프트 엔지니어링, 가드레일과 같은 전술부터 운영 기술, 팀 구축, 내부적으로 구축할 기능 선택과 같은 전략적 관점에 이르기까지 우리가 배운 교훈이 2년차 이후에 도움이 되기를 바람
- 이 흥미로운 새로운 기술을 함께 발전시켜 나가길 기대함