Korea-Question

이어드림 4기 2차 모의 경진 대회입니다.

1. Repo 소개

1. 소개

• LLM을 활용하여 Mulitple - Choice Question (다지선다문제)를 해결하는 대회입니다.

2. 데이터

• Input : 문제 (Question). 선택지 (Multiple - Choice)
• Output : 문제별 정답 선택지 (0 ~ 3)

3. 주의 사항

• Participant Rules
  • 외부 데이터 사용 가능
• Submission Rules
  • 제출 횟수 제한 - 팀별 하루 5회
  • Submission.csv 파일 제출 -> 리더보드

4. 평가 지표

• 평가 지표 : Accuracy
• 전체 질문 중 정답을 맞힌 질문의 비율 (만점 1.0)

2. Git 리포지토리 관리 규칙

1. 브랜치 전략

• 메인 브랜치 보호: main 브랜치는 항상 배포 가능한 상태로 유지합니다. 직접 이 브랜치에 커밋하지 않으며, Pull Request(Pull Request)를 통해서만 병합합니다.
• 브랜치 네이밍 규칙:
  • 기능 개발: 사용자명/feature/기능-이름
  • 버그 수정: 사용자명/bugfix/버그-설명
  • 핫픽스: 사용자명/hotfix/핫픽스-설명
• 브랜치 병합: 기능이 완료되면 feature 브랜치를 develop 브랜치로 병합하고, 최종적으로 main 브랜치에 병합합니다.

2. 커밋 메시지 작성 규칙

• 커밋 메시지 구조: 다음과 같은 구조로 커밋 메시지를 작성합니다.
• 커밋 메시지 유형:
• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 스타일 변경 (코드 의미에 변화 없음)
• refactor: 리팩토링 (기능 추가나 버그 수정 없음)
• test: 테스트 코드 추가 또는 수정
• chore: 기타 변경사항 (빌드 프로세스 수정, 패키지 관리 등)
• 커밋 단위: 커밋은 가능한 작은 단위로 나눠서, 하나의 커밋이 하나의 논리적 작업을 표현하도록 합니다.

3. Pull Request(Pull Request) 관리

• Pull Request 템플릿 사용: Pull Request 시 작성할 템플릿을 사용하여, 변경 사항, 관련 이슈, 테스트 결과 등을 명확히 설명합니다.
• 코드 리뷰: 모든 Pull Request는 최소 1명의 팀원으로부터 코드 리뷰를 받아야 합니다. 코드 리뷰를 통해 코드 품질을 유지하고, 잠재적인 버그를 발견합니다.
• CI/CD 통합: Pull Request가 자동화된 테스트를 통과한 후에만 develop 또는 main 브랜치에 병합합니다.