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

• 대규모 언어 모델(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, 배관 등)을 프로토타이핑하고 신속하게 반복하는 데 유용함
  2. 다음으로 시스템을 계측하고 데이터를 수집하여 올바른 기반을 만들 것
  • 데이터 유형과 규모에 따라 플랫폼 및/또는 데이터 엔지니어가 필요할 수 있음
  • 또한 문제를 디버깅하기 위해 이 데이터를 쿼리하고 분석하는 시스템이 있어야 함
  3. 다음으로 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년차 이후에 도움이 되기를 바람
  • 이 흥미로운 새로운 기술을 함께 발전시켜 나가길 기대함