개요
GitHub Models는 개발자가 LLM(대규모 언어 모델)을 비교하고, 프롬프트를 개선하며, GitHub 플랫폼 내에서 데이터 기반 의사 결정을 내릴 수 있도록 간단한 평가 워크플로를 제공합니다. GitHub Models를 사용하면 구조화된 평가 도구를 통해 성능, 정확도, 비용을 분석하여 새로운 기능을 실험하거나 모델 변경 내용의 유효성을 검사할 수 있습니다.
팁
gh models eval
명령을 사용하여 명령줄에서 직접 평가를 실행할 수 있습니다. UI와 동일한 평가자를 사용합니다. 즉, 문자열 일치, 유사성, 사용자 지정 LLM-as-a-judge 평가자 등이 있어서 로컬이나 CI에서 .prompt.yml
파일을 테스트할 수 있습니다.
GitHub Models의 사용 사례
모델 동작은 프롬프트, 입력, 구성에 따라 크게 달라질 수 있습니다. GitHub Models를 사용하면 다음과 같은 사례를 수행할 수 있습니다.
- 실제 사용 사례에서 여러 LLM을 테스트하고 비교합니다.
- 프롬프트 구문, 온도, 기타 매개 변수를 최적화합니다.
- 구조화되고 반복 가능한 메트릭을 사용하여 모델 출력을 평가합니다.
- AI 개발을 개발 워크플로에 통합합니다.
예제 시나리오
지원 티켓을 통해 제출된 고객 피드백을 요약하는 기능을 빌드하는 시나리오를 고려해 보세요. 이러한 요약은 내부 보고서 및 티켓을 생성하는 데 사용되므로 출력은 명확하고, 관련성이 높으며, 간결해야 합니다.
수행하려는 작업:
- 다양한 모델과 프롬프트 구성을 실험합니다.
- 품질, 일관성, 효율성을 기준으로 최상의 구성을 평가합니다.
- 다시 사용 및 공동 작업을 위해 구성을 리포지토리에 저장합니다.
플레이그라운드에서 프롬프트 테스트하기
GitHub Models에서 프롬프트를 만들고 관리하는 방법을 숙지하려면 플레이그라운드에서 프롬프트 테스트를 참조하세요.
플레이그라운드를 사용하면 모델을 나란히 비교하고, 매개 변수를 조정하고, 프롬프트 변형을 테스트할 수 있습니다.
이 단계에서는 고객 지원 피드백을 위한 요약을 생성하도록 모델을 구성합니다. 시스템 프롬프트를 정의하고, 샘플 입력으로 테스트하고, 세부적으로 조정하여 출력이 간결하고 관련성이 있는지 확인합니다.
시스템 프롬프트 정의
현재 목표에 맞게 모델의 동작을 정의합니다. 이 경우 목표는 고객 피드백을 요약하는 것입니다. Parameters에 다음 시스템 프롬프트를 입력합니다.
You are a helpful assistant that summarizes support ticket responses into concise summaries.
나머지 설정은 기본값 그대로 둡니다.
사용자 프롬프트 작성
이제 모델이 설정되었으므로 Prompt 대화 상자에 다음과 같은 고객 피드백을 입력하세요.
The app crashes every time I try to upload a PDF from my phone. It works on desktop but not on mobile.
모델은 다음과 같은 응답을 생성할 수 있습니다.
The user experiences consistent app crashes when attempting to upload a PDF from their phone. Uploading PDFs works normally on desktop. They request an investigation into the issue.
입력 변수 정의
이 시점에서 구성은 명확하고 간결한 요약을 생성합니다. Parameters 설정 하단에서 Create prompt.yml file을 클릭하여 Prompt 보기를 엽니다. 시스템 프롬프트가 자동으로 미리 채워집니다.
User prompt 필드에 다음 프롬프트를 입력합니다.
Summarize the following: {{input}}
{{input}}
변수는 매번 프롬프트를 수정하지 않고도 다양한 입력(고객 피드백)을 테스트할 수 있는 자리 표시자 역할을 합니다. 추가한 각 테스트 입력은 비교 작업을 진행할 때 {{input}}
을 대체합니다.
테스트 입력 추가
프롬프트 보기의 맨 위에서 Compare를 선택하여 Comparisons 보기를 전환합니다. 이 보기를 사용하면 여러 프롬프트 또는 모델에서 구조화된 비교를 실행하고 Evaluator를 적용하여 성능을 측정할 수 있습니다.
비교 보기에서 표의 각 행은 특정 입력과 예상 출력이 있는 단일 테스트 사례를 나타냅니다. 각 열은 다양한 모델 또는 프롬프트 스타일이 Evaluator를 사용하여 수행하는 방식을 비교하기 위해 다른 프롬프트 구성을 제공합니다.
Add rows를 클릭하여 테스트 데이터를 입력하세요. 입력은 실제 지원 메시지를 시뮬레이션하고 예상 출력은 모델이 반환해야 하는 이상적인 요약을 나타냅니다. 아래 표에서는 평가를 위한 샘플 테스트 입력과 그에 상응하는 예상 출력을 제공합니다.
행 | 입력 | 예상 출력 |
---|---|---|
1 | 휴대폰에서 PDF를 업로드하려고 할 때마다 앱이 충돌합니다. 데스크톱에서는 문제 없이 작동하지만 모바일에서는 작동하지 않습니다. | 사용자가 모바일 앱에서 PDF를 업로드할 때마다 충돌이 발생하며, 데스크톱에서는 문제 없이 작동한다고 보고합니다. |
2 | 이틀 전에 고객지원팀에 연락했는데 아직 답변을 받지 못했습니다. 계정 복구가 시급합니다. | 사용자가 지원팀의 응답을 기다리고 있으며, 계정 복구를 긴급히 요청하고 있습니다. |
3 | 다크 모드를 추가해 주세요. 밤에 사용하기 너무 힘들고, 오래 사용하면 눈이 아픕니다. | 사용자가 야간 사용 시 눈의 피로로 인해 다크 모드 기능 추가를 요청합니다. |
모델 매개 변수 조정
표의 오른쪽에서 를 클릭하여 새 프롬프트 구성을 추가합니다.
새 프롬프트 구성 내에서 사용 가능한 매개 변수 설정을 통해 모델을 업데이트하고 해당 동작을 세밀하게 조정할 수 있습니다. 이러한 설정은 길이, 임의성, 반복을 포함하여 모델이 텍스트를 생성하는 방법을 제어합니다.
모델 구성
Model 드롭다운에서 PHI-4를 선택하여 비교를 위한 고유한 구성을 만듭니다.
다음 매개 변수를 조정하여 모델의 출력에 영향을 줄 수 있습니다.
- Max Tokens: 모델이 반환할 수 있는 최대 토큰 수를 설정합니다. 값이 클수록 출력이 더 길어질 수 있습니다.
- Temperature: 응답의 임의성을 제어합니다. 낮은 값(0.2–0.4)은 보다 집중적이고 결정적인 출력을 생성합니다. 높은 값(0.8–1.0)은 더 다양한 변형과 창의성을 유도합니다.
- Top P: 가장 가능성이 큰 다음 단어의 풀에서 선택하여 출력의 다양성을 제어합니다. 값이 낮을수록 온도를 낮추는 것과 유사하게 변동성이 줄어듭니다.
- Presence Penalty: 모델이 새로운 주제를 도입하지 못하도록 합니다. 값이 높을수록 더 강력한 페널티가 적용됩니다. 값 0은 일반적인 요약 작업에 적합합니다.
- Frequency Penalty: 단어의 반복 사용 가능성을 줄입니다. 값이 높을수록 더 강력한 페널티가 적용됩니다. 0~0.5 사이의 값을 사용하면 요약을 더 명확하고 중복성이 없이 깔끔하게 유지할 수 있습니다.
- Stop: 생성 시, 모델의 응답을 차단하는 하나 이상의 문자열을 지정합니다. 지나치게 긴 출력을 방지하고 특정 서식을 적용할 수 있습니다.
아래 표에서는 모델 비교 중에 간결한 요약을 생성하기 위한 매개 변수 구성을 제공합니다.
매개 변수 | 값 | 이유 |
---|---|---|
Max Tokens | 128 | 응답을 짧고 주제에 맞게 유지 |
온도 | 0.3 | 결정적이고 집중적인 출력 보장 |
Top P | 1.0 | 전체 어휘를 허용하되 선택 안내 허용 |
Presence Penalty | 0 | 페널티 없음 - 요약에 주제 변형 필요 없음 |
Frequency Penalty | 0.3 | 요약에서 반복되는 구문 줄여줌 |
중지 | (선택 사항) | 키워드 또는 기호 뒤의 출력을 종료하려는 경우 사용 |
매개 변수를 적용한 후, 추가 열을 생성하여 더 많은 모델이나 프롬프트 구성을 나란히 비교할 수 있습니다.
출력 평가
프롬프트가 구성되면 실제 데이터와 반복 가능한 메트릭을 사용하여 모델 출력을 비교하는 구조화된 평가를 실행합니다.
모델 평가는 다양한 모델과 프롬프트 구성이 실제 입력에서 어떻게 수행되는지 이해하는 데 도움이 됩니다. 프롬프트 보기에서는 여러 모델에 Evaluator를 나란히 적용하고 유사성, 관련성, 근거성 등의 메트릭을 검토할 수 있습니다.
사용할 수 있는 Evaluator는 다음과 같습니다.
- 유사성: 모델 출력이 예상 또는 참조 응답과 얼마나 유사한지 측정합니다. 이는 모델이 알려진 결과에 맞춰 일관되고 정확한 응답을 반환하는지 확인하려는 경우에 유용합니다. 점수 범위는 0에서 1까지입니다. 값이 높을수록 더 높은 유사성을 나타냅니다.
- 관련성: 응답이 주어진 질문을 얼마나 효과적으로 해결하는지를 나타냅니다. 주어진 정보만을 기반으로 응답의 정확도, 완전성, 직접적인 관련성을 평가합니다. 점수 범위는 0에서 1까지입니다. 값이 높을수록 입력의 의도와 더 잘 맞습니다.
- 근거성: 응답이 주어진 컨텍스트에 얼마나 충실한지 평가합니다. 해당 컨텍스트에 기반한 관련성, 정확도, 완전성을 평가합니다. 응답이 관련 없는 정보나 잘못된 정보를 추가하지 않고 질문을 얼마나 완벽하게 다루고 있는지 평가합니다. 점수 범위는 0에서 1까지입니다. 값이 높을수록 높은 정확도를 나타냅니다.
- 사용자 지정 프롬프트: 하나의 LLM에 대한 고유한 평가 조건을 정의하여 다른 LLM의 출력을 평가할 수 있습니다. 이렇게 하면 고유한 지침에 따라 모델 출력의 점수를 매길 수 있습니다. 통과/실패 또는 점수 매기기 평가 중에서 선택할 수 있으며, 표준 메트릭으로는 부족한 테스트 요구 사항을 다룰 때 적합합니다.
평가 준비가 완료되면 Run을 클릭하여 모든 프롬프트 구성을 기준으로 출력을 생성하고 비교하세요. 실행이 완료되면 GitHub Models는 각 프롬프트 구성의 출력 결과와 함께 평가 점수를 보여 줍니다.
테스트 사례: PDF 업로드 크래시
입력: The app crashes every time I try to upload a PDF from my phone. It works on desktop but not on mobile.
다음 표에는 각 모델의 출력 결과 및 평가 점수가 표시됩니다.
모델 | 출력 |
---|---|
GPT-4.1 | 사용자가 모바일에서 PDF를 업로드할 때 앱이 충돌하며, 데스크톱에서 정상적으로 작동한다고 보고합니다. |
DeepSeek-R1 | |
Phi-4 | 데스크톱 버전에서는 정상적으로 작동하지만 모바일 디바이스에서 PDF를 업로드하려고 하면 앱의 작동이 중단됩니다. |
모델 | 유사성 | 정확도 | 근거성 | 입력 토큰 | 출력 토큰 | 대기 시간 |
---|---|---|---|---|---|---|
GPT-4.1 | 100% | 50% | 100% | 61 | 20 | 918ms |
DeepSeek-R1 | 50% | 50% | 75% | 52 | 128 | 2285ms |
Phi-4 | 75% | 100% | 100% | 61 | 66 | 1117ms |
평가자 점수를 사용하여 표면적인 표현 이외의 응답을 평가하고 비교합니다.
유사성
각 모델의 출력이 예상 요약과 얼마나 가깝게 일치하는지 평가합니다. 아래 표에서는 각 모델의 관련성 점수를 보여 줍니다.
모델 | 유사성 점수 |
---|---|
GPT-4.1 | 100% |
DeepSeek-R1 | 50% |
Phi-4 | 75% |
모든 모델에 입력의 주요 콘텐츠가 포함되어 있지만, 자세한 내부 해설로 인해 DeepSeek-R1의 유사성 점수는 예상되는 간결한 요약 형식에서 벗어나 상당히 낮습니다. 반면 GPT-4.1의 응답은 참조 출력의 구문 및 구조와 일치합니다.
정확도
각 모델이 입력의 핵심 의도를 얼마나 잘 포착하는지 평가합니다. 아래 표에서는 각 모델의 관련성 점수를 보여 줍니다.
모델 | 관련성 점수 |
---|---|
GPT-4.1 | 50% |
DeepSeek-R1 | 50% |
Phi-4 | 100% |
세 가지 모델 모두 모바일에서 PDF를 업로드 중에 앱이 충돌하는 주요 문제를 인식했습니다. Phi-4는 사용자의 관점을 보다 완벽하게 반영하여 더 높은 관련성 점수를 받았습니다. DeepSeek-R1은 원래 입력에 언급되지 않은 추측적인 기술적 원인을 도입하여 점수를 잃었습니다.
근거성
지원되지 않는 정보를 활용하지 않고 각 모델의 출력이 입력에 충실하게 일치하는지 여부를 평가합니다. 아래 표에서는 각 모델의 관련성 점수를 보여 줍니다.
모델 | 근거성 점수 |
---|---|
GPT-4.1 | 100% |
DeepSeek-R1 | 75% |
Phi-4 | 100% |
DeepSeek-R1은 내부 해설을 덧붙이긴 했지만, 사실과 다른 내용은 포함하지 않았습니다. 최종 요약 문장은 원래 입력 내용을 정확하게 반영하고 있습니다.
테스트 사례: 다크 모드 요청
입력: Please add dark mode. It's very hard to use at night. My eyes hurt after prolonged use.
다음 표에는 각 모델의 출력 결과 및 평가 점수가 표시됩니다.
모델 | 출력 |
---|---|
GPT-4.1 | 사용자가 밤에 앱을 사용할 때 불편함과 눈의 피로로 인해 다크 모드 기능을 추가로 요청하였습니다. |
DeepSeek-R1 | |
Phi-4 | 고객이 밤에 제품을 사용할 때 눈의 피로를 줄이기 위해 다크 모드 기능을 추가로 요청하고 있습니다. |
모델 | 유사성 | 정확도 | 근거성 | 입력 토큰 | 출력 토큰 | 대기 시간 |
---|---|---|---|---|---|---|
GPT-4.1 | 100% | 75% | 100% | 57 | 18 | 1286ms |
DeepSeek-R1 | 50% | 0% | 25% | 49 | 128 | 1946ms |
Phi-4 | 100% | 75% | 100% | 58 | 20 | 899ms |
유사성
각 모델의 출력이 예상 요약과 얼마나 가깝게 일치하는지 평가합니다. 아래 표에서는 각 모델의 관련성 점수를 보여 줍니다.
모델 | 유사성 점수 |
---|---|
GPT-4.1 | 100% |
DeepSeek-R1 | 50% |
Phi-4 | 100% |
모든 모델에 입력의 주요 콘텐츠가 포함되어 있지만, 자세한 내부 해설로 인해 DeepSeek-R1의 유사성 점수는 다시 한번 상당히 낮습니다.
정확도
각 모델이 입력의 핵심 의도를 얼마나 잘 포착하는지 평가합니다. 아래 표에서는 각 모델의 관련성 점수를 보여 줍니다.
모델 | 관련성 점수 |
---|---|
GPT-4.1 | 75% |
DeepSeek-R1 | 0% |
Phi-4 | 75% |
GPT-4.1과 Phi-4는 모두 사용자 요청의 주요 의도를 꿰뚫었습니다. 즉, 밤에 눈의 피로를 줄이고 유용성을 개선하기 위해 다크 모드의 필요성을 잘 반영했습니다. DeepSeek-R1은 실제 출력에 방해가 되는 자세한 내부 해설로 인해 관련성에서 0%를 기록했습니다.
근거성
지원되지 않는 정보를 활용하지 않고 각 모델의 출력이 입력에 충실하게 일치하는지 여부를 평가합니다. 아래 표에서는 각 모델의 관련성 점수를 보여 줍니다.
모델 | 근거성 점수 |
---|---|
GPT-4.1 | 100% |
DeepSeek-R1 | 25% |
Phi-4 | 100% |
DeepSeek-R1은 원래 입력에 없는 추측적 추론을 포함하는 장황한 <think>
블록으로 인해 더 낮은 점수를 받았습니다.
구성 저장
평가를 완료한 후 마지막 단계는 특정 사용 사례에 가장 적합한 모델을 선택하는 것입니다. 위의 예제에서 Phi-4 및 GPT-4.1은 모든 평가자에서 강력하고 일관된 결과를 제공했습니다. DeepSeek-R1은 장황한 추론과 덜 집중된 출력으로 인해 더 낮은 점수를 받았습니다.
원하는 모델과 프롬프트 구성을 선택한 후, 프롬프트 파일에 설명이 포함된 이름을 추가한 다음, Commit changes를 클릭합니다. 그러면 모델, 프롬프트, 매개 변수 설정, 관련 데이터 세트가 리포지토리에서 재사용 가능한 구성 파일로 저장됩니다.
프롬프트 구성을 커밋하면 모델 설정에서 쉽게 재사용, 협업, 반복할 수 있습니다. 따라서 시간이 지남에 따라 평가를 더 쉽게 다시 실행하고 프롬프트 구성의 성능을 추적할 수 있습니다.