What We’ve Learned From A Year of Building with LLMs

 

https://applied-llms.org/#prompt-engineering-comes-first

Applied LLMs - What We’ve Learned From A Year of Building with LLMs

 

 

이 글에서는 저자가 지난 1년 동안 LLM 어플리케이션을 구축해 왔고, 그 과정에서의 실수나 배운 내용들에 대해서 공유하는 내용인 글임.

 

저자는 이 가이드를 통해 LLM을 사용하여 성공적인 제품을 구축하기 위한 실용적인 안내서가 되길 바래서 씀.

 

현재의 LLM 어플리케이션:

• 지난 1년 동안 LLM이 실제 애플리케이션에 "충분히 좋은" 수준이 되었으며, 매년 더 좋아지고 저렴해지고 있다고 함.
• 소셜 미디어의 데모와 함께, 2025년까지 AI에 약 2000억 달러가 투자될 것으로 추정됨
• 업체들의 API로 인해 LLM이 더 접근하기 쉬워져, ML 엔지니어와 과학자뿐만 아니라 모두가 제품에 인텔리젠스를 구축할 수 있게 됨
• AI로 구축하는 진입 장벽은 낮아졌지만, 데모 이상으로 효과적인 제품과 시스템을 만드는 것은 여전히 어려운 과제라고 함.

이 글은 세 부분으로 구성됨:

• Tactical(전술적): 프롬프팅, RAG, 워크플로우 엔지니어링, 평가 및 모니터링을 위한 몇 가지 실천 사항
  • LLM으로 구축하는 실무자를 위한 글
• Operational(운영적): 제품 출시의 조직적, 일상적 관심사와 효과적인 팀 구축 방법
  • 지속 가능하고 안정적으로 배포하려는 제품/기술 리더를 위한 내용
• Strategic(전략적): "PMF 전에 GPU 없음", "모델이 아닌 시스템에 집중" 등의 의견을 담은 장기적이고 큰 그림 관점과 반복하는 방법
  • 창업자와 경영진을 염두에 두고 작성됨

 

 

1. Tactical

새로 등장하는 LLM 스택의 핵심 구성 요소에 대한 모범 사례를 공유함

• 품질과 신뢰성을 높이기 위한 프롬프팅 팁
• 출력을 평가하기 위한 전략
• 그라운딩을 개선하기 위한 검색 증강 생성 아이디어 등이 포함됨
• 휴먼 인 더 루프 워크플로우를 설계하는 방법도 탐구할 예정임

 

1.1 Prompting

새로운 애플리케이션을 개발할 때는 프롬프팅으로 시작할 것을 권장한다.

• 프롬프팅의 중요성을 과소평가/과대평가하지 말라는 내용임. 프롬포트 만으로 많은 걸 할 수 있지만 모든 걸 할 수는 없다.
• 올바른 프롬프팅 기술을 제대로 사용하면 매우 멀리 갈 수 있기 때문에 과소평가되는 경향이 있음
• 프롬프트 기반 애플리케이션도 제대로 작동하려면 프롬프트 주변에 상당한 엔지니어링이 필요하기 때문에 과대평가되는 경향이 있음

 

다양한 모델과 작업에서 성능 향상에 지속적으로 도움이 되는 몇 가지 프롬프팅 기술이 있지만 기본 프롬프팅 기술을 최대한 활용하는 데 집중하라고 함.

• N-Shot 프롬포트 기법
• 사고의 연쇄 (Chain-of Thought, COT)

 

N-shot 프롬프트와 문맥 내 학습:

• N-shot 프롬프트를 통한 문맥 내 학습의 아이디어는 LLM에게 작업을 시연하고 출력을 기대에 맞추는 몇 가지 예시를 제공하는 것임
• N이 너무 낮으면 모델이 해당 특정 예시에 과도하게 고정되어 일반화 능력이 저하될 수 있음
• 경험적으로 N ≥ 5를 목표로 하고, 수십 개까지 사용하는 것을 두려워하지 말 것
• 전체 입출력 쌍을 제공할 필요는 없으며, 많은 경우 원하는 출력의 예시로 충분함
• 도구 사용을 지원하는 LLM을 사용하는 경우, N-shot 예시에서도 에이전트가 사용하기를 원하는 도구를 사용해야 함

 

사고의 연쇄(Chain-of-Thought, CoT) 프롬프팅:

• CoT 프롬프팅에서는 LLM이 최종 답변을 반환하기 전에 사고 과정을 설명하도록 장려함
• LLM에게 메모리에서 모든 것을 수행할 필요가 없도록 종이를 제공하는 것으로 생각할 수 있음
• 원래 접근 방식은 단순히 "단계별로 생각해 보자"라는 문구를 지침의 일부로 추가하는 것이었지만, CoT를 더 구체적으로 만드는 것이 도움이 된다는 것을 발견함
• 1~2문장으로 구체성을 추가하면 환각 발생률이 상당히 감소하는 경우가 많음
• 최근에는 이 기술이 믿는 만큼 강력한지에 대해 의문이 제기되고 있지만 그래도 괜찮은 기술이라고 생각한다고 함.

 

RAG 기법과 같은 관련 리소스 제공:

• 모델의 지식 기반을 확장하고, 환각을 줄이며, 사용자의 신뢰를 높이는 강력한 메커니즘임
• 관련 리소스를 제공할 때는 단순히 포함하는 것으로는 충분하지 않음. 모델에게 리소스 사용을 우선시하고, 직접 참조하며, 때로는 리소스가 충분하지 않을 때 언급하도록 지시하는 것을 잊지 말아야 한다고 함.
• 이러한 것들은 에이전트 응답을 리소스 집합에 근거해서 말하게 만들 수 있다.

 

구조화된 입력과 출력은 모델이 입력을 더 잘 이해하고 다운스트림 시스템과 안정적으로 통합할 수 있는 출력을 반환하는 데 도움이 됨

• 구조화된 입력을 사용할 때는 각 LLM 제품군마다 선호하는 방식이 있다는 점에 유의해야 함.
  • Claude는 을 선호하는 반면 GPT는 Markdown과 JSON을 선호함

 

작고 한 가지 일을 잘하는 프롬프트를 만드는 것이 좋다고 함.

• 소프트웨어에서 흔한 안티 패턴/코드 스멜은 모든 것을 수행하는 단일 클래스나 함수인 "God Object"임. 이게 Prompt 에서도 동일하다고 생각함.
• 프롬포트를 몇 문장과 몇 개의 예시로 간단하게 시작한다고 하더라도 엣지 케이스를 추가하다 보면 엄청 커짐. 그러면서 직관적인 입력에 대한 성능은 떨어지기 시작할 수 있음.
• 시스템과 코드를 단순하게 유지하려고 노력하는 것처럼, 프롬프트도 마찬가지여야 함
• 다음은 단일 만능 프롬포트가 아닌 간단한 프롬포트의 조합으로 회의 녹취 요약기 기능을 하는 프롬포트들임:
  • 주요 결정 사항, 조치 항목 및 담당자를 구조화된 형식으로 추출
  • 추출된 세부 정보를 원본 녹취록과 비교하여 일관성 확인
  • 구조화된 세부 정보에서 간결한 요약 생성
• 이렇게 분할하면 이제 각 프롬프트를 개별적으로 반복하고 평가할 수도 있음.

 

LLM 에게 전송되는 Context 잘 만들기:

• RAG 와 같은 기법을 사용해서 Context 를 구축할 때 불필요한 내용을 모두 깍아내는 것이 중요하다. 필요한 맥락만 전달하도록 해야함.
• Context 간의 내용에 대해서도 구조화를 잘 하는 것이 중요하다. 단순히 Bag of Docs (문서의 단순한 나열) 은 도움이 되지 않는다.
• 최종적으로 LLM 에게 던져지는 프롬포트를 보고 중복되는 표현, 모순적인 표현이 있는지 검토해보는게 좋음.

 

 

1.2 정보 검색 / RAG

프롬프팅 외에도 LLM을 조정하는 또 다른 효과적인 방법은 프롬프트의 일부로 지식을 제공하는 것임:

• 이는 제공된 컨텍스트를 LLM 이 배워서 답변을 만들도록 만듣나.
• 실무자들은 RAG가 지식을 제공하고 출력을 개선하는 데 효과적이며, Fine-tuning 에 비해 훨씬 적은 노력과 비용이 든다는 것을 발견함

 

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

• 첫 번째이자 가장 명백한 척도는 "관련성":
  • 이는 일반적으로 평균 역순위(Mean Reciprocal Rank, MRR) 또는 정규화된 할인 누적 이득(Normalized Discounted Cumulative Gain, NDCG)과 같은 순위 지표로 정량화됨
  • 평균 역순위(MRR): 시스템이 첫 번째 관련 결과를 순위 목록에서 얼마나 잘 배치하는지를 평가한다. 첫 번째로 관련 있는 문서를 얼마나 잘 찾아내는지에 초점을 맞추는 지표임 (검색된 항목의 순위는 LLM이 이후 작업을 수행하는 방식에 큰 영향을 미친다고 함)
  • 정규화된 할인 누적 이득(NDCG): 모든 결과의 관련성과 위치를 고려한다. 즉, 검색된 모든 문서의 관련성을 종합적으로 평가하는 지표임.
• 두 번째는 정보 밀도 (Information Density):
  • 두 문서가 동일하게 관련이 있고, 정보 밀도가 동일한 경우에는 간결하고, 세부 정보가 없는 쪽이 더 낫다고 함.
  • 같은 종류의 데이터라면 높은 평가를 받은 리뷰와 편집이 된 리뷰 (추가적으로 수정을 가한 리뷰) 가 더 나을 수 있음.
• 마지막으로, 문서에 제공된 "세부 정보 수준"을 고려할 것:
  • 자연어에서 SQL 쿼리를 생성하기 위한 RAG 시스템을 구축한다고 상상해 보자
  • 열 이름이 있는 테이블 스키마를 컨텍스트로 제공하는 것만으로도 충분할 수 있음. 그러나 열 설명과 일부 대표 값을 포함하면 더 좋다.
  • 추가 세부 정보는 LLM이 테이블의 의미를 더 잘 이해하고 더 정확한 SQL을 생성하는 데 도움이 될 수 있음

 

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

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

 

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

• RAG와 파인튜닝 모두 새로운 정보를 LLM에 통합하고 특정 작업에 대한 성능을 향상시키는 데 사용될 수 있음:
• RAG의 와 Fine-tuning 의 비교:
  • 이 둘을 롤이라는 게임에서 비교를 해보자면, Fine-tuning 은 캐릭터를 선택해서 레벨을 올리는 개념이라면, RAG 는 캐릭터에 아이템을 사주는 느낌이다.
  • Fine-tuning 을 통해 특정 테스크 강화, 도메인 전문성을 얻을 수 있으나, 비용이 들어가고 정적이라는 단점이 있다.
  • RAG 는 유연하고 새로운 정보를 기반으로 LLM 에게 대답하게 만들기 더 쉽다. 어플리케이션 구조가 좀 더 복잡할 수 있고, 엔지니어링 비용이 더 들어갈 수 있다.
  • 최근 연구에 따르면 같은 작업과 데이터에 대해서는 RAG 가 더 우수할 수 있다고 함.
  • 유지보수 측면에서 유해한 답변 제거 측면에서는 RAG 의 검색 인덱스 관리가 더 유용할 수 있다고 함.

 

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

• Gemini 1.5가 최대 1,000만 토큰 크기의 컨텍스트 윈도우를 제공함에 따라 일부에서는 RAG의 미래에 의문을 제기하기 시작함.
• 모든 데이터를 컨텍스트에 넣고 평소처럼 모델과 대화하기만 하면 되니까.
• 하지만 여전히 RAG 는 필요할 것. 왜냐하면 불필요한 컨택스트의 제공은 답변 퀄리티를 낮출거니까.
• 큰 컨택스트에 대해서 LLM 이 답변을 더 잘하는 지에 대해서는 검증이 필요하긴 함.
• 그리고 큰 컨택스트 비용은 더 많은 비용을 유발할거임.

 

 

1.3 워크플로우 튜닝 및 최적화

LLM에 프롬프트를 주는 것은 시작에 불과함:

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

 

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

• 하나의 큰 프롬프트를 여러 개의 작은 프롬프트로 분해함으로써 더 나은 결과를 얻을 수 있다는 것을 이미 알고 있음
  • AlphaCodium이 그 예시임
    • 단일 프롬프트에서 다단계 워크플로우로 전환함으로써 CodeContests에서 GPT-4 정확도(pass@5)를 19%에서 44%로 높임
• 워크플로우에는 다음이 포함됨;
  • Reflecting on the problem
  • Reasoning on the public tests
  • Generating possible solutions
  • Ranking possible solutions
  • Generating synthetic tests
  • Iterating on the solutions on public and synthetic tests.
• 명확한 목표를 가진 작은 작업은 최상의 에이전트 또는 흐름 프롬프트를 만듦
• 시도해 볼 만한 것들:
  • 작업을 시작하기 전에 명확하고 구체적인 계획 단계를 설정하는 것. 이는 작업의 모든 단계와 목표를 명확히 정의하여 혼란을 줄이고 효율성을 높이는 데 도움이 됨.
  • 원래 사용자가 입력한 프롬프트를 에이전트가 이해하기 쉬운 형태로 다시 작성하는 것도 좋다. 이 과정에서 정보가 일부 손실될 수 있으므로 주의가 필요함.
  • 에이전트의 동작을 선형 체인, 방향성 비순환 그래프(DAG), 상태 기계와 같은 다양한 구조로 설계하는 것. 작업의 규모와 복잡성에 따라 적합한 구조를 선택하여 성능을 최적화할 수 있음.
  • 계획 단계에서 다른 에이전트의 응답을 평가하는 방법에 대한 지침을 포함하는 것. 이를 통해 전체적인 작업이 잘 조화롭게 이루어지도록 할 수 있음.
  • 이전 단계에서 결정된 고정된 상태를 기준으로 삼아, 다양한 상황에서 에이전트가 어떻게 반응할지를 평가하는 과정을 설계하는 것.

 

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

• 비결정론적인 워크플로우는 실패할 때 어떻게 핸들링 할 지 결정하기 어렵기 때문에 신뢰할 수 없기 떄문이라고 함.
• 유망한 접근 방식은 결정론적 계획을 생성하고 이를 구조화되고 재현 가능한 방식으로 실행하는 에이전트 시스템을 갖는 것임
  • 첫 번째 단계에서는 상위 수준의 목표나 프롬프트가 주어지면 에이전트가 계획을 생성함
  • 그런 다음 계획이 결정론적으로 실행됨
  • 이를 통해 각 단계를 보다 예측 가능하고 신뢰할 수 있게 만들 수 있음
  • 장점:
    • 생성된 계획은 에이전트에 프롬프트를 제공하거나 미세 조정하기 위한 few-shot 샘플로 사용될 수 있음
    • 결정론적 실행은 시스템을 더 신뢰할 수 있게 만들어 테스트와 디버깅이 더 쉬워짐. 또한 실패는 계획의 특정 단계로 추적될 수 있음
    • 생성된 계획은 방향성 비순환 그래프(DAG)로 표현될 수 있으며, 정적 프롬프트에 비해 이해하고 새로운 상황에 적응하기 쉬움

 

Temperature 매개변수 이상의 다양한 출력 얻기:

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

 

캐싱은 과소평가되고 있음:

• 캐싱은 동일한 입력에 대한 응답을 재계산할 필요성을 제거함으로써 비용을 절감하고 생성 지연 시간을 제거함
• 캐시에 저장된 응답을 즉시 제공할 수 있어 응답 시간을 줄일 수 있음.
• 검토된 응답을 제공함으로써 안전성을 높일 수 있음. + 유해하거나 부적절한 콘텐츠 제공을 피할 수도 있음.

 

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

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

만약 금융 정보 기반으로 블룸버그와 같은 뉴스를 생성해주는 LLM 이라면 언제 파인튜닝을 해야할까?

• 특정 도메인 특화 언어가 필요할 떄
• 특정 도메인 영역내의 해석 능력과 추론 능력을 가지고 싶을 떄
• 일관성 있는 문체나 톤이 필요할 떄

 

 

1.4 평가 및 모니터링

LLM이 생성하는 출력이 개방형(open-ended)이고, 그들이 수행하는 작업이 다양하기 때문에, 이를 평가하는 것은 매우 복잡하지만 그래도 해야한다.

 

LLM 평가에는 여러 가지 접근법이 있으며, 각기 다른 관점에서 평가하는 것이 유용하다:

• 단위 테스트(unit testing)처럼 개별 기능을 테스트하거나
• 관찰 가능성(observability)을 통해 시스템의 동작을 모니터링하거나
• 데이터 과학(data science) 기법을 사용하여 성능을 분석하는 것. (ROUGE 나 BLEU 같은 것)

 

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

• 프로덕션에서 입력과 출력의 샘플로 구성된 단위 테스트(즉, assertion)를 만들고, 최소 3가지 기준에 따라 출력에 대한 기대치를 설정
  • 3가지 기준이 임의적으로 보일 수 있지만, 시작하기에 실용적인 수임
    • 더 적으면 작업이 충분히 정의되지 않았거나 범용 챗봇과 같이 너무 개방적일 수 있음
  • 이러한 단위 테스트 또는 assertion은 프롬프트 편집, RAG를 통한 새 컨텍스트 추가 또는 기타 수정과 같은 파이프라인의 변경 사항에 의해 트리거되어야 함
• 모든 응답에 포함하거나 제외할 구문이나 아이디어를 지정하는 assertion부터 시작하는 것을 고려
  • 또한 단어, 항목 또는 문장 수가 범위 내에 있는지 확인하는 검사를 고려
• 예를 들면, 사용자가 foo라는 새 함수를 요청하면 에이전트의 생성 코드를 실행한 후 foo를 호출할 수 있어야 한다던지 하는 것도 테스트가 될 수 있음.
• Dogfooding 처럼 실제 고객처럼 제품을 사용해보는 방법도 중요할 수 있음. 이런 방법은 실제 데이터에서 발생할 수 있는 오류 모드를 식별할 수 있습니다.

 

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

• LLM-as-Judge는 강력한 LLM을 사용하여 다른 LLM의 출력을 평가하는 방식으로, 일부 사람들에게는 회의적으로 받아들여짐
• 그럼에도 불구하고 잘 구현되면 LLM-as-Judge는 인간의 판단과 상당한 상관관계를 달성하고, 적어도 새로운 프롬프트나 기술이 어떻게 수행될 수 있는지에 대한 사전 정보를 구축하는 데 도움이 될 수 있음
• LLM-as-Judge를 최대한 활용하기 위한 제안:
  • 쌍별 비교 사용
    • LLM에게 단일 출력을 Likert 척도로 평가하도록 요청하는 대신 두 가지 옵션을 제시하고 더 나은 것을 선택하도록 요청
    • 이는 더 안정적인 결과로 이어지는 경향이 있음
  • 위치 편향 제어
    • 제시된 옵션의 순서가 LLM의 결정을 편향시킬 수 있음
    • 이를 완화하려면 각 쌍별 비교를 두 번 수행하고 각 시간에 쌍의 순서를 바꿈
    • 스와핑 후에는 올바른 옵션에 승리를 귀속시켜야 함
  • 동점 허용
    • 경우에 따라 두 옵션이 똑같이 좋을 수 있음
    • 따라서 LLM이 임의로 승자를 선택할 필요가 없도록 동점을 선언하도록 허용
  • Chain-of-Thought 사용
    • 최종 선호도를 제시하기 전에 LLM에게 그 결정을 설명하도록 요청하면 평가 신뢰성이 향상될 수 있음
    • 보너스로, 이를 통해 더 약하지만 빠른 LLM을 사용하면서도 유사한 결과를 얻을 수 있음
    • 파이프라인의 이 부분이 자주 배치 모드에 있기 때문에 CoT로 인한 추가 지연은 문제가 되지 않음
  • 응답 길이 제어:
    • LLM은 더 긴 응답으로 치우치는 경향이 있음
    • 이를 완화하려면 응답 쌍의 길이가 비슷한지 확인
• 그러나 LLM-as-Judge는 만능이 아님
  • 가장 강력한 모델조차도 신뢰할 수 있게 평가하지 못하는 미묘한 언어적 측면이 있음
  • 전통적인 SVM(Support Vector Machine)이나 로지스틱 회귀 모델이 높은 정확도를 가지고 분류를 더 잘할 수 있음.

 

LLM-as-Judge의 응용:

• 새로운 프롬프트 전략 평가:
  • 새로운 프롬프트 전략이 기존 전략에 비해 얼마나 효과적인지 평가할 때 사용할 수 있음. 기존의 프로덕션 결과를 새로운 전략으로 재실행하여 빠르게 평가할 수 있는 것.
  • 이를 위해서는 Production 에서 받았던 질문들 같은 건 보관해놔야겠네. 새로운 프롬포트로 테스트를 해볼거니까.

 

LLM-as-Judge의 간단하지만 효과적인 접근 방식의 예시

• 1. 모델의 성능을 평가하고 개선점을 찾아내기 위해 데이터베이스에 LLM-as-Judge 가 생성한 비평, LLM 이 생성한 응답, 최종 테스트 결과 등을 저장한다.
• 2. 이해관계자와 이를 검토한다.
• 3. 반복적으로 개선한다. 3번 정도. (68%의 테스트를 94%로 향상 시킨 사례가 있다고 함.)

 

생성 결과 평가를 위한 "인턴 테스트 (Intern Test)":

• LLM 이 생성한 답변과 입력 (컨택스트 포함) 을 보고 이걸 대학생들도 똑같이 입력을 주었을 떄 그들도 할 수 있을까? 그들은 얼마나 걸릴까를 생각해보도록 하면서 해당 과제를 LLM 도 할 수 있을 것인지 평가해보고, 대학생들이 오래걸린다면 이걸 좀 더 간단하게 만드는 방법을 생각해보고, 대학생들이 쉽게 한다면 이제 LLM 의 개선점들을 생각해보는 것.
• 예시로 보면 다음과 같음:
  • 대학생들이 못함. 컨택스트가 부족해서. -> 컨택스트를 풍부하게 만들어보자.
  • 대학생들이 못함. 너무 어려운 과제라서.-> 한계를 인정하자.
  • 대학생들이 할 수 있는데 너무 오래걸림 -> 복잡한 과제를 단순하게 만들려면 어떻게 해야할까?
  • 대학생들도 쉽게 하는 건데 왜 틀리지 -> LLM 이 어디서 잘못하는지 디버깅. 데이터도 좀 살펴보고

 

특정 평가 지표에 지나치게 집중하면, 모델의 전반적인 성능이 저하될 수 있다고 함:

• 이건 Goodhart 법칙으로 측정이 목표가 되면, 좋은 측정이 아니게 된다
• 예시: NIAH 평가는 긴 문서 내에서 특정 문구를 기억해내는 모델의 능력을 평가하는 방법임. 예를 들어서 "The special magic {city} number is: {number}"와 같은 문구를 긴 문서 속에 삽입하고, 모델이 이 문구를 회상할 수 있는지 평가하는 거임. 그러니까 모델의 "기억력(Recall)" 을 평가하는 것.
• 하지만 NIAH 평가에 지나치게 집중한 결과, 실제로 모델이 필요한 추론 능력이 떨어지늩 문제가 발생한다고 함. 그래서 모델이 필요한 작업에서 좋은 성능을 내지 못할 수 있다고 한다.
• 이런 평가 보다는 실제로 기능 위주의 평가가 더 유용하다고 함. 예를 들면 한 시간짜리 회의록을 요약하고 주요 결정을 식별하며, 각 항목을 관련 인물에게 정확히 귀속시키는 작업 같은 것.
• 그러니까 실제 응용 프로그램에서 필요한 능력을 평가하는 것이 중요함.
• 그리고 한 가지 평가에만 집중하면, 모델이 특정 작업에 지나치게 최적화되어 다른 중요한 작업에서 성능이 저하될 수 있다고 한다.

 

Reference-free 평가를 Guardrails 에 사용할 수도 있음:

• Reference-free 평가란 모델의 출력을 평가할 때 인간이 작성한 정답을 사용하지 않는 평가 방법으로, 입력 프롬프트와 모델의 응답만을 기준으로 출력의 품질을 평가하는 방법임.
• Guardrails 은 모부적절하거나 유해한 콘텐츠를 차단하는 데 사용됨.
• Reference-free 평가는 평가와 가드레일로 모두 사용할 수 있음. 입력 프롬프트와 모델의 응답만을 기준으로 평가하기 때문에, 평가 과정에서 출력의 품질이 낮다고 판단되면 이를 사용자에게 보여주지 않음으로써 가드레일의 역할을 할 수 있는 것.

 

LLM은 출력을 하지 않아야 할 때도 출력을 반환함:

• LLM 작업 시 주요 과제는 LLM이 그러면 안 될 때도 종종 출력을 생성한다는 것:
  • 이는 무해하지만 무의미한 응답이나 유해성 또는 위험한 내용과 같은 더 심각한 결함으로 이어질 수 있음
  • 예를 들어 문서에서 특정 속성이나 메타데이터를 추출하라는 요청을 받으면 LLM은 해당 값이 실제로 존재하지 않을 때도 자신 있게 값을 반환할 수 있음.
  • 또는 컨텍스트에 영어 이외의 문서를 제공했기 때문에 모델이 영어 이외의 언어로 응답할 수도 있음
• LLM에 "해당 없음" 또는 "알 수 없음" 응답을 반환하도록 프롬프트를 제공할 수 있지만 완벽하지는 않음
• 로그 확률 (토큰이 출력될 확률) 로 일관된 출력을 내도록 할 수 있지만, 이는 반드시 정확하거나 관련성이 높은 출력을 보장하지는 않음.
• 주의 깊은 프롬프트 엔지니어링은 어느 정도 도움이 될 수 있지만, 원치 않는 출력을 감지하고 필터링/재생성하는 강력한 가드레일로 보완해야 함
• 가드레일의 한 가지 이점은 사용 사례에 대해 크게 무관하며 따라서 특정 언어로 된 모든 출력에 광범위하게 적용될 수 있다는 것
  • 또한 정밀한 검색을 통해 관련 문서가 없으면 시스템이 결정적으로 "모르겠습니다"라고 응답할 수 있음
  • 개인 식별 정보를 감지하는 다양한 패키지를 사용해서 가드레일로 사용할 수 있ㅇ므.
  • 가드레일은 여러가지 방식으로도 사용될 수 있음. OpenAI 는 콘텐츠 Moderation API 로 실시간으로 검사하고 있음. Rule-based Filtering 같은 걸로도 가드레일을 만들 수도 있을듯.
• 반대로 LLM이 출력해야 할 때 출력을 생성하지 못하는 경우도 발생할 수 있음. 이는 API 제공자의 지연 시간 문제나 콘텐츠 모더레이션 필터에 의해 출력이 차단되는 등의 다양한 이유로 발생할 수 있음.
  • 따라서 디버깅 및 모니터링을 위해 입력과 (잠재적으로 출력 부족을) 일관되게 기록하는 것이 중요함

 

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

• 이를 해결하기 위해 프롬프트 엔지니어링(생성 업스트림)과 사실적 불일치 가드레일(생성 다운스트림)을 결합할 수 있음
  • 프롬프트 엔지니어링의 경우 CoT와 같은 기술은 LLM이 최종 출력을 반환하기 전에 추론을 설명하도록 함으로써 환각을 줄이는 데 도움이 됨
  • 그런 다음 사실적 불일치 가드레일을 적용하여 요약의 사실성을 평가하고 환각을 필터링하거나 재생성할 수 있음

 

 

2. 운영: 일상(Day-to-Day) 및 조직 문제

2.1 데이터

재료의 품질이 요리의 맛을 결정하듯이 입력 데이터의 품질은 기계 학습 시스템의 성능을 제약함.

 

또한 출력 데이터는 제품이 작동하는지 여부를 알 수 있는 유일한 방법임

 

모든 저자는 데이터 분포(모드, 엣지 케이스, 모델의 한계)를 더 잘 이해하기 위해 매주 몇 시간 동안 입력과 출력을 면밀히 살펴봄

 

개발-프로덕션 편향 확인:

• 전통적인 기계 학습 파이프라인에서 오류의 일반적인 원인은 훈련-서비스 편향임
  • 이는 훈련에 사용되는 데이터가 모델이 프로덕션에서 접하는 데이터와 다를 때 발생함
• 훈련이나 미세 조정 없이 LLM을 사용할 수 있으므로 훈련 세트는 없지만 개발-프로덕션 데이터 편향이라는 유사한 문제가 발생함
  • 기본적으로 개발 중에 시스템을 테스트하는 데이터는 시스템이 프로덕션에서 직면할 데이터를 반영해야 함
  • 그렇지 않으면 프로덕션 정확도가 저하될 수 있음
• LLM 개발-프로덕션 편향은 구조적 편향과 내용 기반 편향의 두 가지 유형으로 분류될 수 있음
  • 구조적 편향(Structural Skew):
    • 데이터 형식의 불일치에서 발생할 수 있음. 예를 들어, 개발 중에는 JSON 딕셔너리를 사용하지만, 프로덕션에서는 JSON 리스트를 사용한다면, 이런 형식 차이가 문제를 일으킬 수 있다.
    • 예시로는 대소문자 불일치, 오타, 문장 단편 등이 있음다. LLM은 데이터 형식에 매우 민감하므로 이러한 작은 차이도 성능에 큰 영향을 미칠 수 있다.
  • 내용 기반 편향(Content-Based or Semantic Skew):
    • 데이터의 의미나 맥락의 차이에서 발생하는 거임. 개발 중에는 특정 주제의 데이터를 사용했지만, 프로덕션에서는 다른 주제를 다루는 데이터가 입력될 수 있음.
    • 예시로는 개발 중에는 일반적인 문서를 사용했지만, 프로덕션에서는 기술 문서나 특정 산업 분야의 데이터를 다루게 될 경우.

 

편향 관리 방법:

• 정기적 편향 측정:
  • LLM의 입력 및 출력 쌍 간의 편향을 정기적으로 측정하는 것. 입력과 출력의 길이, 특정 형식(JSON, XML 등)을 기준으로 변화를 추적하는 것.
  • 예시로는 개발과 프로덕션 단계의 입력 길이와 형식을 비교해서 차이를 발견하는 것임.
• 고급 편향 탐지:
  • 입력 및 출력 쌍의 임베딩을 클러스터링하여 의미론적 편향(semantic drift)을 탐지하는 것.
  • 사용자가 다루는 주제가 변화할 때 이를 감지할 수 있다.
• 현재 사용자 상호작용 반영:
  • 최신 사용자 상호작용을 반영한 홀드아웃 데이터셋을 수집하여 테스트 하는 것.
    • 홀드아웃 데이터 셋은 모델의 성능을 평가하기 위해 학습에 사용하지 않는 데이터 셋을 말함.
• 정성적 평가:
  • 모델의 출력을 정성적으로 평가하여 기대에 부합하는지 확인합니다. 이를 “vibe checks”라고도 한다. 이를 “vibe checks”라고도 함.
    • 정성적 평가란 인간의 주관적인 판단과 분석을 사용하는 걸 말한다.

 

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

• LLM은 시간이 지나면서 성능이 변할 수 있음. 다양한 입력에 대해, 프롬포트 변화에 대해 예측하지 못한 방식으로 반응할 수 있음.
• 입력과 출력을 기록하고, 매일 샘플을 검토하여 새로운 패턴이나 실패 모드를 신속히 식별하는 것이 좋음.
• 프로덕션 환경의 데이터로 평가하는 것이 좋음.
• 매일 샘플을 검토하여 모델의 출력이 기대에 부합하는지 확인하는 게 좋음.
• 입력과 출력을 검토하는 과정을 팀 내에서 공유하고, 이를 업무의 일부로 포함시키는 게 좋다고 함. 사소한 일로 보이지만, 꼭 필요한 과정 중하나로가 하는듯.

 

 

2.2 모델과 함께 일하기

LLM API 를 이용해서 개발하는 것에 대한 Trade off:

• 장점:
  • LLM API를 사용하면 강력한 인공지능 기능을 빠르게 활용할 수 있음.
  • 복잡한 모델을 직접 개발하고 관리할 필요 없이 제공자의 인프라를 통해 쉽게 접근할 수 있다.
• trade-offs:
  • 성능: 외부 API를 사용함으로써 제공자의 서버 성능에 의존하게 됨.
  • 지연 시간: 요청을 보내고 응답을 받는 데 시간이 걸리며, 이는 모델이 제공하는 서비스의 반응 속도에 영향을 미칠 수 있음.
  • 처리량: 한 번에 처리할 수 있는 요청 수가 제한될 수 있다.
  • 비용: API 사용에는 비용이 발생하며, 사용량이 많아질수록 비용이 증가함.
  • 마이그레이션: 새로운 모델이 출시됨에 따라, 성능 향상과 더 나은 기능을 위해 제품을 업데이트하는 것이 필요함.

 

프롬프트를 모델 간에 마이그레이션하는 어려움:

• 하나의 모델에서 잘 작동하는 Prompt 를 다른 모델에 마이그레이션 하는 건 어려울 수 있다고 함.
• 그래서 신뢰할 수 있는 자동화된 평가 도구를 통해 마이그레이션 전후의 작업 성능을 측정하면, 수작업 검증에 필요한 노력을 줄일 수 있다고 함.

 

모델 버전 고정 및 핀닝:

• LLM 과 머신러닝은 특정한 버전으로 고정해서 제공해줌. 모델이라는게 약간만 변경되도 성능이 바뀔 수 있기 때문에 이렇게 고정적인 버전을 제공해준다. 예를 들면 gpt-4-turbo-1106 이런 것을 생각해보면 됨.
• 새로운 모델로의 마이그레이션을 위해서 섀도우 파이프라인(Shadow Pipeline) 을 유지하는 게 좋다:
  • 새로운 모델 릴리스와 안전한 실험 및 테스트를 수행하여, 새로운 모델의 안정성과 출력 품질을 검증하기 위해서임.

 

가장 크고 강력한 모델을 사용하는 것이 유혹적이긴 하지만, 작업이 기술적으로 가능하다는 것이 입증되면 더 작은 모델이 유사한 결과를 낼 수 있는지 실험해보는 것이 좋음:

• 작은 모델의 장점:
  • 낮은 지연 시간
  • 낮은 비용
• 작은 모델의 성능 향상 기법:
  • Chain-of-thought (사고의 연쇄): 단계별로 사고 과정을 설명함으로써 모델의 이해를 돕는 것.
  • N-shot 프롬프트: 여러 예시를 제공하여 모델이 더 정확하게 작업을 수행하도록 유도하는 것.
  • In-context 학습: 주어진 문맥 내에서 학습을 수행하여 성능을 향상시키는 것.
• 작은 모델의 실용적 예시:
  • DistilBERT: 6700만 개의 파라미터를 가진 DistilBERT는 간단한 분류 작업에서 강력한 성능을 발휘한다.
  • DistilBART: 4억 개의 파라미터를 가진 DistilBART는 오픈 소스 데이터로 파인튜닝된 경우, 환각(hallucinations)을 ROC-AUC 0.84의 정확도로 식별할 수 있다. 이는 대부분의 LLM보다 우수한 성능을 나타내며, 지연 시간과 비용은 5% 이하로 유지됨.

 

 

2.3 제품 (Product)

새로운 기술은 새로운 가능성을 제공하지만 훌륭한 제품을 만드는 원칙은 영원함

 

견고한 제품 기본 원칙에 LLM 애플리케이션 개발을 기반으로 함으로써 얻을 수 있는 것이 많음

 

초기 디자인의 중요성:

• 디자인을 초기 단계부터 고민해서 사용자 경험을 재고하고 개선할 수 있는 방법을 고민하는 것.
• AI 제품을 만들 때 기술 자체보다는 사용자가 필요로 하는 작업에 중심을 두어야 한다는 걸 잊지마라.
• 원칙은 "사용자가 이 제품을 통해 해결하고자 하는 작업은 무엇인가?"라는 질문을 지속적으로 던지는 것이다.

 

Human-in-the-Loop 디자인:

• 사용자의 피드백을 수집해서 모델의 성능을 개선시키는 방법을 포함시키는 걸 말한다.
• 이를 위한 UX 디자인은 여러가지가 있다. 예시로 살펴보자:
  • 예시: 사용자가 제품을 업로드하고 분류하는 전자상거래 플랫폼
  • 1. 사용자가 수동으로 올바른 제품 범주를 선택하고, LLM이 주기적으로 새 제품을 확인하고 백엔드에서 잘못된 분류를 수정
  • 2. 사용자는 범주를 전혀 선택하지 않고, LLM이 주기적으로 백엔드에서 제품을 분류(잠재적 오류 포함)
  • 3. LLM이 실시간으로 제품 범주를 제안하고, 사용자가 필요에 따라 검증 및 업데이트 가능
  • 세 가지 접근 방식의 비교:
    • 첫 번째 접근 방식은 초기 부담을 사용자에게 지우고 LLM이 사후 처리 검사 역할을 함
    • 두 번째 접근 방식은 사용자의 노력이 전혀 필요하지 않지만 투명성이나 제어권을 제공하지 않음
    • 세 번째 접근 방식이 적절한 균형을 유지함
      • LLM이 사전에 범주를 제안함으로써 사용자의 인지 부하를 줄이고 제품을 분류하기 위해 우리의 분류법을 배울 필요가 없음
      • 동시에 사용자가 제안을 검토하고 편집할 수 있도록 함으로써 제품 분류 방식에 대한 최종 결정권을 사용자의 손에 단단히 쥐어줌
      • 보너스로 세 번째 접근 방식은 모델 개선을 위한 자연스러운 피드백 루프를 만듦

 

LLM 제품을 프로덕션에 적용할 때의 가이드:

• 신뢰성 (Reliability):
  • 시스템이 99.9%의 가동 시간을 유지하고 구조화된 출력을 준수해야 한다.
• 무해성 (Harmlessness):
  • 공격적이거나 NSFW(업무에 부적합한) 또는 기타 유해한 콘텐츠를 생성하지 않아야 함.
• 사실적 일관성 (Factual Consistency):
  • 제공된 문맥에 충실하고, 정보를 창작하지 않아야 함.
• 유용성 (Usefulness):
  • 사용자의 필요와 요청에 적절하게 관련되어야 함.
• 확장성 (Scalability):
  • 지연 시간 서비스 수준 협약(SLA)와 지원되는 처리량을 충족해야 함.
• 비용 (Cost):
  • 무제한 예산이 아니므로 비용 효율성을 고려해야 함.
• 보안:
  • 보안, 프라이버시, 공정성, GDPR(일반 데이터 보호 규정), DMA(디지털 시장법) 등을 고려해야 함.

 

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

• 유스 케이스에 따라서 위험 수준을 생각해보고 우선 순위에 대해 생각해봐야함.
• LLM 을 의료 어플리케이션에 적용할 때는 보다 엄격한 높은 기준을 달성해야하지만, 추천 시스템의 경우에는 지나치게 엄격한 요구사항을 줄 필요는 없다.

 

 

2.4 Team & Roles

LLM(대형 언어 모델)과 같은 새로운 패러다임에 직면했을 때, 소프트웨어 엔지니어는 도구에 의존하는 경향이 있다고 함:

 

그러나 도구에 집중하면 그 도구가 해결하려는 문제와 프로세스를 간과하게 되며, 이는 팀의 장기적인 생산성에 부정적인 영향을 미칠 수 있다고 한다.

 

프로세스 중심의 사고:

• 문제를 해결하기 위해 사용되는 방법론이나 프로세스를 이해하는 것이 더 중요하다.
• 도구 자체에만 의존하면 불필요한 복잡성을 초래할 수 있다.
• 문제 해결 방법을 이해하고, 도구가 그 방법을 어떻게 지원하는지 이해하는 것이 필요하다.

 

도구의 한계:

• 도구는 종종 구체적인 요구 사항을 충분히 반영하지 못할 수 있다고 한다. 예를 들어, 일반적인 LLM 평가 도구는 toxicity, conciseness, tone 등과 같은 일반적인 평가 기준을 제공한다. 그러나 이런 도구들은 특정 도메인 영역에서 충분히 실패할 수 있다고 함.
• 의료 분야에서는 정확한 용어 사용과 환자 안전에 관한 특별한 요구 사항이 있음. 법률 문서에서는 특정한 법률 용어와 구조가 중요하기도 함. 일반적인 평가 도구는 이러한 요구 사항을 충족시키지 못한다.

 

EvalGen의 접근 방식을 권장:

• EvalGen은 사용자가 도메인별 평가를 만들 수 있도록 각 단계를 깊이 있게 안내한다. 이는 사용자에게 기준을 지정하고, 데이터를 레이블링하고, 평가를 확인하는 과정을 포함시켜서, 사용자가 문제 해결 과정을 이해하고 적극적으로 참여하도록 유도하는 것.

 

실험의 중요성:

• 결정론적인 원칙 같은 것들이 아직은 ML 쪽이 부족하기 때문에 실험이 중요하다고 함.
• 실헝 비용도 점점 저렴해져서 하기 좋다고도 말하고.

 

 

3. Strategy: Building with LLMs without Getting Out-Maneuvered

전략 1: GPU 사용 전에 제품-시장 적합성(PMF)을 우선하라

• 제품이 성공하려면 다른 사람의 API를 단순히 감싸는 것 이상의 가치를 제공해야 한다. 그러나 반대로, 명확한 제품 비전이나 목표 시장 없이 자체 모델을 훈련하고 맞춤화하는 데 초점을 맞추는 것은 더 큰 비용을 초래할 수 있다.

 

사전 훈련(Pretraining)을 처음부터 시작하는 것은 거의 의미가 없다:

• 데이터 수집, 모델 훈련 및 평가, 배포 등 머신러닝 인프라를 개발하고 유지하는 데 많은 자원이 필요하니까.
• 사전 훈련된 LLM은 몇 달 만에 구식이 될 수 있음. BloombergGPT는 금융 작업을 위해 특별히 훈련된 모델이지만, 출시 후 1년 이내에 gpt-3.5-turbo와 gpt-4에 의해 능가되었음.
• 대부분의 실용적인 응용 프로그램에서는 처음부터 사전 훈련을 하기보다는, 특정 요구에 맞게 강력한 오픈 소스 모델을 미세 조정(finetuning)하는 것이 더 나은 선택임.

 

필요한지 입증될 때까지 미세 조정을 하지 마라:

• 많은 조직이 "단순한 래퍼"에 그치지 않기 위해 너무 일찍 미세 조정에 투자한다. 파인 튜닝이 필요할 때 해야함.

 

추론 API와 자체 호스팅:

• LLM API를 사용하면 스타트업이 자체 모델을 처음부터 훈련하지 않고도 언어 모델링 기능을 통합하기가 매우 쉬워졌음.
• 그러나 모든 사용 사례에 관리 서비스가 적합한 것은 아니며, 규모와 요구 사항이 증가함에 따라 자체 호스팅이 필요할 수 있다.
  • 의료 및 금융과 같은 규제 산업에서는 네트워크 외부로 기밀/개인 데이터를 보내지 않아야 하므로 자체 호스팅이 필요할 수 있음.
  • 추론 제공자의 제한(예: 속도 제한, 모델 폐기, 사용 제한)을 피할 수 있습니다.

 

모델이 아닌 시스템이 제품이다:

• 모델 자체는 시스템 내에서 가장 내구성이 낮은 구성 요소이므로, 지속적인 가치를 제공하는 요소인 평가(Evals), 안전 장치(Guardrails), 캐싱(Caching), 데이터 플라이휠(Data flywheel)에 집중해야 합니다
  • Evals(평가): 다양한 모델에서 작업 성능을 신뢰할 수 있게 측정합니다.
  • Guardrails(안전 장치): 모델에 상관없이 원치 않는 출력을 방지합니다.
  • Caching(캐싱): 모델을 거치지 않고 지연 시간과 비용을 줄입니다.
  • Data flywheel(데이터 플라이휠): 위의 모든 요소의 반복적인 개선을 촉진합니다.

 

작게 시작하기:

• 범용적인 시스템을 만들어서 사용자 경험을 어중간하게 주는 것보다는 특정 도메인이나 사용 사례에 집중해서 계속해서 들어오게 만들 수 있는 강력한 경험을 구축하는 것이 중요하다.

 

LLMOps 구축: 빠른 반복을 위한 이유

• DevOps와 MLOps의 본질은 반복적인 작업을 자동화 해서, 피드백 주기를 단축하여 개선이 누적되도록 하는 것임.
• LLMOps 도 이를 적용할 수 있다.

 

LLM 기능 구축 대신 구매하라:

• 대부분의 성공적인 비즈니스는 LLM(대형 언어 모델) 자체가 중심은 아니지만 LLM 을 통해 개선될 수 있는 기회를 가지고 있다.
• LLM 을 적극적으로 이용해서 자신의 회사 내에 일반적인 문제를 해결하기 보다는 회사가 해결하려는 문제에 집중하고, 이러한 솔루션은 구매해서 사용하는게 더 나을 수 있다고 함.

 

AI를 루프에 넣고 인간을 중심에 두기:

• 작업의 효율화에 AI 가 있지만, 실제적으로 주체는 인간이 될 수 있도록 하는것.
• 분명 LLM은 사용자 워크플로를 가속화하는 훌륭한 도구임. (인간-컴퓨터 켄타우로스(Centaur chess))
• LLM 을 적용할 수 있는 가장 효과적인 패러다임은 인간-컴퓨터 협업임. GitHub CoPilot 이 보여준 것처럼.

 

LLM 제품을 구축하려면 이것부터 해라:

• 프롬프트(Prompting): 프롬포트를 사용해서 LLM 이 작업을 할 수 있을지 판단하는 것.
• 평가(Evals): 다양한 모델과 작업에 대한 성능을 측정하는 것.
• 데이터 수집(Data Collection): LLM을 개선하기 위해 필요한 데이터를 수집하는 것.

 

프롬프트 엔지니어링을 먼저 시작하라:

• LLM(대형 언어 모델) 제품을 구축할 때는 프롬프트 엔지니어링부터 시작해야 한다.
• 프롬프트 엔지니어링만으로 원하는 성능 수준을 달성할 수 없을 때만 미세 조정을 고려하자.

 

평가와 데이터 플라이휠 구축하기:

• 평가를 통해 프롬프트 엔지니어링의 효과를 확인할 수 있어야 함.
• 파인 튜닝을 할 경우에도 파인 튜닝 모델이 더 뛰어난지 확인할 수 있어야 함.
• 평가의 유형으로는 테스트 케이스 같은 것들이나, 인간 평가가 있음.

 

저비용 인지의 고수준 트렌드

• 갈수록 비용은 점점 저렴해지고 성능이 뛰어나는 모델이 만들어질거임.
• 이전 역사에서 Xerox PARC 연구자들이 RAM 가격이 비살 때 RAM 가격이 떨어지면서 비디오 디스플레이 같은 기술들이 가능해질거라고 생각했던 것처럼. (무어의 법칙 이용) LLM 도 유사하게 예측할 수 있지 않을까 생각한다고 함.

Conclusion

References:

• https://applied-llms.org/
• https://news.hada.io/topic?id=15268&fbclid=IwZXh0bgNhZW0CMTEAAR3rEJaAuSvRdqfYjhVsjf9aFS8QkTZt7Yr5fTj3akeAvAWA6oLsZfEdLnA_aem_AZAqNvr8DSoXsIg2d91PwtLtcZl1GORg7UlXiAFjgcz7iw3Xsx7m77BE-u97HO8_UxvpbRnCKo2YT8OZs7Nph8sj