AI 기능 개발 플레이북

이 플레이북은 대규모 언어 모델(LLM), 프롬프트, 데이터, 평가 및 시스템 아키텍처와 관련된 주요 측면을 설명합니다.

AI 기능 개발 및 운영 고려 사항의 플레이북 역할을 합니다.

프롬프트 엔지니어링 이해하기

개요는 이 동영상을 참조하세요.

가장 중요한 내용:

  • 프롬프트 정의:
    • 작업을 해결하기 위해 언어 모델에 전달되는 지시 사항
    • 사용자 인터페이스에서 AI 기능의 핵심을 형성
  • 프롬프트 품질의 중요성:
    • 언어 모델의 응답 품질에 큰 영향을 미침
    • 최적의 결과를 위해 프롬프트를 반복하는 것이 중요함
  • 프롬프트를 작성할 때 고려해야 할 사항:
    • 모델에게 수행하라고 요청하는 작업을 이해
    • 어떤 종류의 응답을 기대하는지 알고 있어야 함
    • 프롬프트 테스트를 위한 데이터셋 준비
    • 구체적으로 작성 - AI가 이해할 수 있도록 많은 세부사항과 맥락 제공
    • 잠재적인 질문과 원하는 답변의 예시 제공
  • 프롬프트의 보편성:
    • 프롬프트는 서로 다른 언어 모델에서 보편적이지 않음
    • 모델을 변경할 때 프롬프트를 조정해야 함
    • 특정 팁은 언어 모델 제공자의 문서를 참조
    • 완전히 전환하기 전에 새로운 모델 테스트
  • 프롬프트 작업을 위한 도구:
    • Anthropic Console: 프롬프트를 작성하고 테스트하는 플랫폼
    • Generator Prompt: 작업 설명을 기반으로 제작된 프롬프트를 생성하는 도구
  • 프롬프트 구조:
    • 일반적인 작업 설명이 포함됨
    • 입력 텍스트에 대한 자리 표시자가 포함됨
    • 특정 지침과 제안된 출력 형식이 포함될 수 있음
    • 이해력 및 데이터 추출을 위해 XML 태그로 입력을 감싸는 것이 좋음
  • 시스템 프롬프트:
    • AI의 일반적인 톤과 역할 설정
    • 모델의 성능을 개선할 수 있음
    • 일반적으로 프롬프트의 시작 부분에 배치
    • 언어 모델에 대한 역할 설정
  • 모범 사례:
    • 과제를 이해하는 데 시간을 투자
    • 프롬프트 생성 도구를 시작점으로 사용
    • 결과 개선을 위해 프롬프트를 테스트하고 반복
    • AI가 이해할 수 있도록 올바른 영어 문법과 구문 사용
    • 불확실성을 허용 - AI가 확실하지 않을 경우 “모르겠습니다”라고 말하도록 지시
    • 긍정적인 표현 사용 - AI가 하지 말아야 할 것이 아니라 수행해야 할 일을 말하도록 하세요.

효과적인 프롬프트 작성을 위한 모범 사례

효과적인 프롬프트 작성에 대한 이 동영상을 참조하세요.

이 동영상의 주요 내용은 다음과 같습니다:

  • 보편적인 “좋은” 프롬프트는 없음:
    • 프롬프트의 효과는 특정 작업에 따라 달라짐
    • 프롬프트 작성에는 모든 상황에 맞는 접근 방식이 없음
  • 효과적인 프롬프트의 특성:
    • 작업과 기대 결과에 대해 명확하고 설명적이어야 함
    • 직설적이고 자세해야 함
    • 원하는 출력에 대해 구체적이어야 함
  • 고려해야 할 주요 요소:
    • 작업, 청중 및 최종 목표 이해
    • 이러한 요소를 프롬프트에서 명확하게 설명
  • 프롬프트 성능 개선 전략:
    • 일련의 단계로 지침 추가
    • 관련 예시 포함
    • 모델에게 단계별로 생각하도록 요청(사고의 연쇄)
    • 답변을 제공하기 전에 추론 요청
    • 입력 안내 - 사용자의 입력이 시작되고 끝나는 지점을 명확히 표시하기 위해 구분 기호 사용
  • 모델 선호도에 적응:
    • 모델의 선호 데이터 구조에 맞게 프롬프트 조정
    • 예를 들어, Anthropic 모델은 XML 태그와 잘 작동함
  • 시스템 프롬프트의 중요성:
    • 언어 모델의 역할 설정
    • 상호 작용의 시작 부분에 배치
    • 도구나 긴 문맥에 대한 인식을 포함할 수 있음
  • 반복은 필수적:
    • 프롬프트 작업에서 가장 중요한 부분으로 강조됨
    • 지속적인 개선은 더 나은 결과로 이어짐
    • 품질 관리를 구축 - RSpec 또는 Rake 작업을 사용하여 프롬프트 테스트를 자동화하여 차이를 포착
  • 전통적인 코드 사용:
    • 작업이 LLM 호출 외부에서 효율적으로 수행될 수 있는 경우, 더 신뢰할 수 있고 결정론적인 출력을 위해 코드 사용

프롬프트에 대한 워크플로우 조정 및 최적화

Langsmith 및 Anthropic Workbench와 CEF를 사용하는 LLM을 위한 프롬프트 튜닝

Anthropic 콘솔을 사용한 프롬프트 반복

개요는 이 비디오를 참고하세요.

Langsmith를 사용한 프롬프트 반복

개요는 이 비디오를 참고하세요.

Langsmith를 사용한 프롬프트 튜닝을 위한 데이터셋 사용

개요는 이 비디오를 참고하세요.

Langsmith에서 자동화된 평가 사용

개요는 이 비디오를 참고하세요.

Langsmith에서 쌍 실험 사용

개요는 이 비디오를 참고하세요.

ELI5 문서 보기.

Langsmith 사용 시기와 ELI5 사용 시기

개요는 이 비디오를 참고하세요.

ELI5 (Eval like I’m 5) 프로젝트의 주요 사항
  1. 초기 개발
    • 프롬프트 반복을 위해 순수 Langsmith로 시작
    • 설정이 더 쉽고 빠름
    • 초기 단계에서 비용 효율적
  2. ELI5로 전환할 시기
    • 기능에 더 많은 투자를 할 때
    • 더 큰 데이터셋을 사용할 때
    • 반복적이고 장기적인 사용을 위해
  3. ELI5 설정 고려 사항
    • 초기 시간 투자 필요
    • 특정 기능에 맞춰 평가 조정 필요
    • 입력 데이터 설정 필요 (예: 채팅 기능을 위한 로컬 GDK)
  4. 도전 과제
    • 다양한 사용자 간 일관된 데이터 보장
    • 데이터 공유를 위한 좌석 및 가져오기와 같은 옵션 탐색
  5. 현재 ELI5 기능
    • 코드에 대한 채팅 질문 지원
    • 문서 관련 쿼리 처리
    • 코드 제안에 대한 평가 포함
  6. ELI5의 장점
    • 로컬 GDK에서 평가 실행 가능
    • Langsmith UI에서 결과 확인 가능
    • 더 큰 데이터셋 사용 가능
  7. 유연성
    • 특정 사용 사례에 맞춰 사용자 정의 필요
    • 모든 것에 맞는 솔루션이 아님
  8. 문서
    • ELI5에는 방대한 문서가 제공됨
  9. 채택
    • 코드 제안 및 팀 생성 등을 포함하여 일부 팀에서 이미 사용 중

평가 및 모니터링

평가를 위한 데이터셋 구축

데이터셋이 필요한 이유는 무엇인가요?

데이터셋은 예상 출력과 함께 입력이 있는 간단한 형태입니다.

이제 채팅 애플리케이션과 같은 경우에는 정의된 예상 출력을 갖는 것이 불가능하므로 데이터셋이 여전히 매우 유용하지만 평가 기법은 달라질 것입니다. 지금은 우리가 모두 코드 테스트 아이디어에 어느 정도 편안해졌으므로, 예상 출력이 있는 데이터셋으로 작업하여 간단하게 유지하겠습니다.

애플리케이션을 만들기로 결정하면 그것이 어떻게 깨질 수 있는지, 그리고 어떻게 성공해야 하는지를 고려하는 것이 중요합니다.

그러한 잠재적인 입력과 예상 출력을 수집하여 우리 애플리케이션을 통과할 수 있는 데이터셋에 담는 것은 초기 및 후기 개발 모두에 매우 유용합니다.

애플리케이션을 개발한 후에는 다양한 입력에 대해 예상대로 작동하는지 확인하는 것이 중요합니다. 가능한 한 넓은 범위의 프롬프트를 갖는 것이 바람직합니다.

프롬프트 변경, 도구 선택 또는 새 모델 선택 시 변경 사항이 얼마나 성공적인지를 비교할 수 있는 데이터셋이 필요합니다. 이 데이터셋은 예상 출력과 쌍을 이루는 많은 수의 입력을 포함해야 합니다.

데이터세트를 만들 때 고려해야 할 주요 사항

LLM(대형 언어 모델) 위에 애플리케이션을 처음 만들 때 평가를 하고 싶을 것입니다. 첫 번째 질문은 데이터세트에 얼마나 많은 레코드가 있어야 하는지입니다. 이 질문은 곧 명확해질 이유로 조금 이르다고 할 수 있습니다.

먼저, 얼마나 많은 데이터가 필요한지를 생각하기 전에, 우리의 데이터가 앱이 해결해야 할 문제를 얼마나 잘 대표해야 하는지와 그 데이터를 어디서 얻을 수 있을지를 생각해봅시다.

GitLab에서 이 부분을 지속적으로 반복하고 있는 예를 들어 보겠습니다. 우리의 코드 완성 기능 평가를 고려해 봅시다. 평가에 사용되는 데이터세트는 GitLab 코드베이스에서 가져온 함수들로 구성되어 있으며, 이는 반으로 나뉩니다. 첫 번째 절반은 프롬프트(입력)이고, 두 번째 절반은 모델이 생성하는 것과 비교할 부분(예상 출력)입니다.

우리는 GitLab 코드로부터 만들어진 데이터세트로 코드 완료 애플리케이션을 평가하고 있으며, 이는 많은 Ruby, Go, Python 및 여러 다른 언어들로 구성되어 있습니다. 우리의 많은 고객이 Java로 코드를 작성한다는 점을 기억합시다. 이 시점에서 우리가 질문할 가치가 있는 것은, 우리의 데이터세트를 대표성이 있다고 설명할 수 있을까요? 솔직히 말해, 처음에는 아닐 것입니다. 우리는 처음에 최선의 결과를 얻기 위해 최선을 다해야 한다는 사실을 받아들여야 하며, 평가 기준과 우리 애플리케이션 간의 일치를 개선하려는 노력이 데이터세트를 생성하거나 개선할 때 집중해야 할 가장 중요한 사항입니다. 이 데이터세트 생성/개선 노력의 일환으로 우리는 다양한 유형의 프롬프트를 유지하고자 합니다. 앞서 언급한 코드 완료 예제를 따라, 우리는 아마도 더 많은 Java 프롬프트를 갖고 싶겠지만, 단순히 leet-code 스타일의 인터뷰 질문만 원하는 것은 아닙니다. 우리는 또한 엔터프라이즈 백엔드 애플리케이션, 안드로이드 애플리케이션, gradle 플러그인 등에서 사용할 수 있는 예제와 기본적인 인터뷰 질문 및 Java가 사용되는 더 다양한 장소의 예제도 원합니다.

대표적인 데이터를 생각해봤으니, 이제 얼마나 많은 데이터 포인트가 필요한지 생각해봅시다. 평가에서 우리는 애플리케이션이 얼마나 잘 수행되고 있는지 평가하려고 합니다. 공정하지 않을 수 있는 동전을 던지는 상황을 상상할 수 있다면, 10번 던진다고 해서 많은 신뢰를 주지 못할 것이며, 10,000번 던진다면 아마 그렇게 될 것입니다. 마찬가지로 10,000번 동전을 던지는 데 시간이 걸리는 것처럼, 10,000개의 프롬프트를 실행하는 것도 대략 100개 정도 실행하는 것보다 오래 걸릴 것입니다. 개발 초기 단계에서는 반복 속도와 정확성의 균형을 유지하고자 하며, 이를 위해 70~120개의 프롬프트를 권장하지만, 반복 시간을 해치지 않고 더 추가할 수 있다면 이는 강력히 권장됩니다. 내부 베타로 넘어가고 GA(General Availability)로 가기 위해 이동할수록 수천 개의 프롬프트를 사용하는 평가를 수행할 것을 권장합니다.

출력, 기준 진리 또는 예상 답변이란 무엇인가?

출력: 선택한 LLM에 메시지를 전송한 결과입니다. “은하수를 여행하는 히치하이커를 위한 안내서에서 삶의 의미인 숫자는 무엇인가요?”라는 질문을 한다면 출력은 “은하수를 여행하는 히치하이커를 위한 안내서에서 삶의 의미를 나타내는 숫자는 42입니다.”와 같은 형태일 수 있습니다.

기준 진리 또는 예상 결과: 실제 상황에서 우리가 진실이라고 아는 예제입니다. 우리가 주택 가격을 예측하려고 하고, 부동산 목록 사이트에서 가져온 여러 검증 데이터가 있다고 상상해봅시다. 이 데이터는 집에 대한 정보와 집의 가격을 포함합니다. 이 데이터를 기준 진리라고 할 수 있습니다.

CEF 대시보드 사용 및 문제 해결

CEF에 대한 자동화된 평가 파이프라인 사용

Docker 컨테이너에서 promptlib 사용에 대한 개요는 이 비디오를 참조하세요.

지속적인 모니터링 및 프롬프트 튜닝에 대한 지침 적용

Gen AI 기능을 위한 A/B 테스트 전략

추가 리소스

보다 포괄적인 프롬프트 엔지니어링 가이드는 다음을 참조하세요: