실제 애플리케이션을 위한 프롬프트를 작성할 때 간결성과 효과의 균형을 맞추는 것이 중요한 절충안으로 떠오릅니다. 모든 요소가 동일한 경우 간결한 프롬프트가 긴 프롬프트보다 빠르고 저렴하며 유지보수가 쉽습니다. 이는 지연 시간과 토큰 제한이 중요한 웹 환경에서 특히 중요합니다. 하지만 프롬프트가 너무 간단하면 모델에 고품질 결과를 생성하는 데 필요한 컨텍스트, 요청 사항 또는 예가 부족할 수 있습니다.
평가 기반 개발 (EDD)을 사용하면 이러한 절충을 체계적으로 모니터링하고 최적화할 수 있습니다. EDD는 작고 확실한 단계로 출력을 개선하고, 회귀를 포착하고, 시간이 지남에 따라 모델 동작을 사용자 및 제품 기대치에 맞추는 반복 가능하고 테스트 가능한 프로세스를 제공합니다.
AI의 불확실성에 맞게 조정된 테스트 기반 개발 (TDD)이라고 생각하면 됩니다. 결정론적 단위 테스트와 달리 AI 평가는 하드 코딩할 수 없습니다. 형식이 올바른 출력과 실패한 출력 모두 예상치 못한 형태를 취할 수 있기 때문입니다.
EDD는 검색 노력도 지원합니다. 테스트를 작성하면 기능의 동작을 명확히 하는 데 도움이 되는 것처럼 평가 기준을 정의하고 모델 출력을 검토하면 명확성이 부족한 부분을 파악하고 개방형 또는 익숙하지 않은 작업에 점진적으로 세부정보와 구조를 추가할 수 있습니다.
문제 정의
입력 유형, 출력 형식, 추가 제약 조건을 포함하여 API 계약과 같이 문제를 프레임화할 수 있습니다. 예를 들면 다음과 같습니다.
- 입력 유형: 블로그 게시물 초안
- 출력 형식: 게시물 제목 3개가 포함된 JSON 배열
- 제약 조건: 128자(영문 기준) 미만, 친근한 어조 사용
그런 다음 입력 예시를 수집합니다. 데이터 다양성을 보장하기 위해 이상적인 예와 실제의 지저분한 입력을 모두 포함합니다. 이모티콘이 포함된 게시물, 중첩된 구조, 많은 코드 스니펫과 같은 변형과 극단적인 사례를 생각해 보세요.
기준 초기화
첫 번째 프롬프트를 작성합니다. 제로샷으로 시작하여 다음을 포함할 수 있습니다.
- 명확한 요청 사항
- 출력 형식
- 입력 변수의 자리표시자
평가하고 최적화할 때 복잡성을 높이고 다른 구성요소 및 고급 프롬프트 기술을 사용합니다. 먼저 최적화 노력을 올바른 방향으로 이끌 평가 시스템을 설정해야 합니다.
평가 시스템 만들기
TDD에서는 요구사항을 파악한 후 테스트 작성을 시작합니다. 생성형 AI에는 테스트할 명확한 출력이 없으므로 평가 루프를 만드는 데 더 많은 노력을 기울여야 합니다.
효과적으로 평가하려면 여러 측정 도구가 필요할 수 있습니다.
평가 측정항목 정의
평가 측정항목은 결정적일 수 있습니다. 예를 들어 모델이 유효한 JSON을 반환하는지 또는 올바른 수의 항목을 출력하는지 확인할 수 있습니다.
하지만 명확성, 유용성, 어조, 창의성과 같은 주관적 또는 정성적 측정항목을 식별하고 개선하는 데 많은 시간을 할애해야 합니다. 처음에는 광범위한 목표로 시작하지만 곧 더 미묘한 문제에 직면할 수 있습니다.
예를 들어 제목 생성기에서 특정 문구 또는 패턴을 과도하게 사용하여 반복적이고 기계적인 결과가 나올 수 있습니다. 이 경우 변형을 장려하고 과도하게 사용된 구조나 키워드를 방지하기 위해 새로운 측정항목을 정의합니다. 시간이 지나면 핵심 측정항목이 안정화되고 개선사항을 추적할 수 있습니다.
이 프로세스에서는 애플리케이션 도메인에서 양호한 상태가 어떤 것인지 이해하고 미묘한 장애 모드를 포착할 수 있는 전문가의 도움이 필요합니다. 예를 들어 글쓰기 도우미를 개발하는 경우 콘텐츠 제작자 또는 편집자와 협력하여 평가가 그들의 세계관과 일치하도록 하세요.
심사위원 선택
평가 기준에 따라 평가자가 달라집니다.
- 코드 기반 검사는 결정론적 또는 규칙 기반 출력에 적합합니다. 예를 들어 제목에서 피하고 싶은 단어를 검색하거나, 글자 수를 확인하거나, JSON 구조의 유효성을 검사할 수 있습니다. 이는 빠르고 반복 가능하며 버튼이나 양식 입력란과 같은 고정 출력 UI 요소에 적합합니다.
- 사람의 의견은 어조, 명확성, 유용성 등 더 주관적인 품질을 평가하는 데 필수적입니다. 특히 초기에는 모델 출력을 직접 검토 (또는 도메인 전문가와 함께)하면 빠르게 반복할 수 있습니다. 하지만 이 방법은 확장성이 좋지 않습니다. 애플리케이션을 실행한 후 별점과 같은 인앱 신호를 수집할 수도 있지만 이러한 신호는 노이즈가 많고 정확한 최적화에 필요한 미묘한 차이가 부족한 경향이 있습니다.
- LLM-as-judge는 다른 AI 모델을 사용하여 출력을 평가하거나 비판함으로써 주관적인 기준을 평가하는 확장 가능한 방법을 제공합니다. 인적 검토보다 빠르지만 함정이 있습니다. 순진한 구현에서는 모델의 편향과 지식 격차를 영속화하고 강화할 수도 있습니다.
양보다 질을 우선시하세요. 클래식 머신러닝 및 예측 AI에서는 데이터 주석을 크라우드소싱하는 것이 일반적입니다. 생성형 AI의 경우 크라우드소싱 주석자는 도메인 컨텍스트가 부족한 경우가 많습니다. 규모보다 고품질의 풍부한 맥락 평가가 더 중요합니다.
평가 및 최적화
프롬프트를 더 빠르게 테스트하고 조정할수록 사용자 기대치에 부합하는 결과를 더 빨리 얻을 수 있습니다. 지속적으로 최적화하는 습관을 들여야 합니다. 개선을 시도하고, 평가하고, 다른 방법을 시도합니다.
프로덕션 환경에서 사용자 및 AI 시스템의 동작을 계속 관찰하고 평가합니다. 그런 다음 이 데이터를 분석하고 최적화 단계로 변환합니다.
평가 파이프라인 자동화
최적화 노력의 마찰을 줄이려면 평가를 자동화하고, 변경사항을 추적하고, 개발을 프로덕션에 연결하는 운영 인프라가 필요합니다. 이를 일반적으로 LLMOps라고 합니다. 자동화를 지원하는 플랫폼이 있지만 서드 파티 솔루션을 사용하기 전에 이상적인 워크플로를 설계해야 합니다.
고려해야 할 주요 구성요소는 다음과 같습니다.
- 버전 관리: 프롬프트, 평가 측정항목, 테스트 입력을 버전 관리에 저장합니다. 재현 가능성과 명확한 변경 내역을 보장하기 위해 코드로 취급합니다.
- 자동화된 일괄 평가: 워크플로 (예: GitHub Actions)를 사용하여 각 프롬프트 업데이트에 대한 평가를 실행하고 비교 보고서를 생성합니다.
- 프롬프트용 CI/CD: 결정론적 테스트, LLM-as-judge 점수, 가드레일과 같은 자동화된 검사로 배포를 관리하고 품질이 저하되면 병합을 차단합니다.
- 프로덕션 로깅 및 관측 가능성: 입력, 출력, 오류, 지연 시간, 토큰 사용량을 캡처합니다. 드리프트, 예기치 않은 패턴 또는 실패 급증을 모니터링합니다.
- 피드백 수집: 사용자 신호 (좋아요, 다시 쓰기, 포기)를 수집하고 반복되는 문제를 새로운 테스트 사례로 전환합니다.
- 실험 추적: 프롬프트 버전, 모델 구성, 평가 결과를 추적합니다.
타겟팅된 작은 변경사항으로 반복
프롬프트 개선은 일반적으로 프롬프트의 언어를 개선하는 것으로 시작됩니다. 여기에는 요청 사항을 더 구체적으로 작성하거나, 의도를 명확히 하거나, 모호한 부분을 삭제하는 것이 포함될 수 있습니다.
과적합이 발생하지 않도록 주의하세요. 모델 문제를 패치하기 위해 지나치게 좁은 규칙을 추가하는 것이 일반적인 실수입니다. 예를 들어 제목 생성기에서 The Definitive Guide로 시작하는 제목을 계속 생성하는 경우 이 문구를 명시적으로 금지하고 싶을 수 있습니다. 대신 문제를 추상화하고 상위 수준의 안내를 조정하세요. 이는 독창성, 다양성 또는 특정 편집 스타일을 강조한다는 의미이므로 모델이 단일 예외가 아닌 기본 설정을 학습합니다.
또 다른 방법은 더 많은 프롬프트 기법을 실험하고 이러한 노력을 결합하는 것입니다. 기법을 선택할 때는 이 작업이 유추 (퓨샷)를 통해 해결하는 것이 가장 적합한지, 단계별 추론 (사고의 연쇄)을 통해 해결하는 것이 가장 적합한지, 아니면 반복적인 개선 (자기 성찰)을 통해 해결하는 것이 가장 적합한지 자문해 보세요.
시스템이 프로덕션으로 전환될 때 EDD 플라이휠이 느려져서는 안 됩니다. 오히려 가속화해야 합니다. 시스템에서 사용자 입력을 처리하고 로깅하는 경우 이러한 입력이 가장 가치 있는 통찰력의 소스가 됩니다. 평가 모음에 반복 패턴을 추가하고 지속적으로 최적화의 다음 단계를 파악하고 구현합니다.
핵심 내용
평가 기반 프롬프트 개발을 통해 AI의 불확실성을 체계적으로 탐색할 수 있습니다. 문제를 명확하게 정의하고, 맞춤 평가 시스템을 구축하고, 작고 타겟팅된 개선사항을 반복하면 모델 출력을 꾸준히 개선하는 피드백 루프를 만들 수 있습니다.
리소스
LLM을 심판으로 구현하려는 경우 다음 권장사항을 참고하세요.
- LLM 기능과 요약 비교
- Hamel Husain의 LLM을 심판으로 사용하기 가이드를 읽어보세요.
- A Survey on LLM-as-a-Judge 논문을 읽어보세요.
프롬프트를 더 개선하고 싶다면 컨텍스트 인식 개발에 대해 자세히 알아보세요. 머신러닝 엔지니어가 이 작업을 수행하는 것이 가장 좋습니다.
이해도 확인
평가 기반 개발의 기본 목표는 무엇인가요?
클라이언트 측 시스템을 평가할 때 더 큰 모델을 사용하는 이유는 무엇인가요?
평가에 LLM-as-a-judge를 사용할 때 발생할 수 있는 잠재적인 문제점은 무엇인가요?
권장되는 자동 평가 파이프라인에 포함되는 구성요소는 무엇인가요?
평가 시스템의 심사위원을 선택할 때 사람의 피드백을 사용하는 데 있어 주요 제한사항은 무엇인가요?