안녕하세요! NTT 동일본의 모리타입니다.

평소에는 데이터 활용 프로젝트를 수행하면서, Kaggle Master로서 경연(Competition)에도 지속적으로 참여하고 있으며, 그 경험을 살려 사내에서 Kaggle 및 생성 AI 활용의 저변을 넓히는 활동을 하고 있습니다.

이번에는 그 활동의 일환으로, NTT 그룹 횡단의 Kaggle 이벤트를 개최했습니다.

당일에는 LT(Lightning Talk) 발표와 핸즈온(Hands-on) 형식의 오리지널 Kaggle 경연을 실시하였으며, 현장 대면으로 약 80명, 온라인 참여를 포함하면 합계 약 100명이 참가했습니다.

결과적으로, 참가자의 약 60%가 경연 미경험자였음에도 불구하고, 이벤트 만족도는 4.73 / 5, 「Kaggle의 즐거움을 느낄 수 있었습니까?」라는 설문에서도 4.71 / 5라는 매우 높은 평가를 받았습니다. Kaggle 미경험자 및 Python 초보자분들에게도 「즐거웠다」, 「장벽이 낮아졌다」라는 의견을 많이 들어, 당초의 목적을 크게 달성한 이벤트가 되었습니다.

그 목적이란, Kaggle 경험자들끼리만 경쟁하는 것이 아니라, Kaggle이나 프로그래밍에 아직 익숙하지 않은 사람들도 포함하여 데이터 분석·AI 활용의 저변을 넓히는 것입니다.

그래서 경연 자체도 「Python을 작성할 수 없는 사람도 참여할 수 있는」 설계로 했습니다. 참가자는 Kaggle Notebook 상의 프롬프트(Prompt) 문자열을 고민하는 것만으로, 동일한 모델에 대해 더 나은 지시를 내려 스코어(Score) 개선을 목표로 하는 형식입니다.

본 기사에서는 대성공으로 끝난 본 이벤트의 내용과 운영의 노하우, 당일의 모습, 반성점 등을 실체험 기반으로 자세히 소개합니다.

향후 유사한 이벤트를 개최하려는 분들을 위한 구체적인 Tips도 정리해 두었으니, 꼭 참고해 보시기 바랍니다!

사내에는 Kaggle에 관심은 있지만, 처음에 무엇을 해야 할지 모르거나 도전해 보았지만 도중에 좌절해 버리는 사람도 적지 않다고 생각합니다.

한편, 그룹 내에는 Kaggle Master나 Kaggle Expert로서 지속적으로 활동하고 있는 멤버들도 재직 중입니다.

하지만 지금까지는 그러한 초보자와 경험자가 자연스럽게 연결될 기회가 많지 않았습니다.

이에 Kaggle에 도전해 보고 싶은 초보자와 이미 Kaggle을 수행하고 있는 경험자를 서로 연결함으로써, 그룹 전체의 데이터 활용 능력·AI 활용 능력·도전 문화를 끌어올리고자 「NTT Kaggler회」라는 NTT 그룹 횡단 커뮤니티를 설립했습니다.

이번에는 그 제1회 이벤트로서 본 이벤트를 개최했습니다.

당일에는 먼저 LT 발표로, 작년까지는 초보자였지만 지금은 Kaggle에 열중하고 있는 멤버나 Kaggle Master 멤버 등 총 2명이 등단했습니다.

그 후에 전원이 오리지널 경연에 참여했습니다.

회장에서는 Kaggle 초보자분들도 많았기 때문에, 운영 멤버가 각 테이블을 순회하며 경연 참여(Join), Notebook 설정, 제출(Submit) 방법 등을 서포트했습니다.

온라인 참가자도 있었기 때문에 설명은 가능한 한 절차를 압축하여, 전원이 동일한 타이밍에 첫 제출(Submit)까지 도달할 수 있는 것을 중시했습니다.

경연 종료 후에는 프라이빗 리더보드(Private Leaderboard)를 발표하였고, 상위 입상자에게는 그 자리에서 프롬프트나 고안한 포인트 등을 공유하도록 했습니다.

이번에 준비한 경연은 일본어 사내 게시글 톤 분류입니다.

사내 채팅, Slack, Teams, 사내 게시판 등에 게시된 단문을 읽고, 그 게시글이 읽는 이에게 주는 인상을 다음 5개 클래스로 분류합니다.

Kaggle에 흥미를 갖게 만들기 위한 방안으로는 스터디, LT회, 독서회 등 다른 방법도 있습니다.

하지만 제가 Kaggle에 빠지게 된 원경험은 「리더보드(Leaderboard)를 치고 올라가는 즐거움」이었습니다.

스코어가 올라가고 순위가 움직이는 그 순간의 감각은, 이론 학습이나 LT를 듣는 것만으로는 맛볼 수 없습니다.

초학자에게도 이 체험을 하게 해주고 싶다—— 그렇게 생각했을 때, 가장 직접적인 수단은 「경연에 참여하는 것」이었습니다.

그렇다면 기존의 Kaggle 경연에 다 같이 참여하면 되지 않을까? 라고 생각하실지도 모릅니다.

하지만 실제 Kaggle 경연에는 몇 가지 장벽이 있습니다.

우선, 난이도 조절이 불가능합니다.

실제 경연은 전 세계의 Kaggler들이 진심으로 임하는 장이며, 문제 설정이나 데이터 전처리(Pre-processing)만으로도 고도의 지식이 요구됩니다.

처음 Kaggle을 접하는 사람이 갑자기 뛰어들어도 무엇부터 손을 대야 할지 몰라 좌절할 가능성이 높습니다.

또한, 운영 측에서 참가자에게 제공하는 서포트에도 제약이 있습니다.

일반적인 Kaggle 경연(Competition)에서는 참가자 간에 해법을 공유하는 프라이빗 셰어링 (Private Sharing)이 금지되어 있습니다.

즉, 회장에서 "이 부분을 이렇게 바꾸면 스코어가 올라갑니다"라고 힌트를 주거나,

막혀 있는 참가자에게 구체적인 조언을 하는 것 자체가 규칙상 어렵습니다.

초보자 대상 이벤트에서 서포트를 할 수 없다는 것은 치명적입니다.

반면, Kaggle의 커뮤니티 경연 (Community Competition) 기능을 사용하면,

오리지널 문제 설정·데이터·평가 지표를 자유롭게 설계할 수 있으며,

초보자도 즐길 수 있는 난이도로 조정할 수 있습니다.

회장에서의 서포트나 힌트 제공도 자유롭게 할 수 있습니다.

이러한 이유로, 제1회 이벤트의 형식으로 오리지널 커뮤니티 경연을 선택했습니다.

이번에 Python으로 모델을 학습하는 경연이 아니라, 프롬프트 엔지니어링 (Prompt Engineering)형 경연으로 정한 데에는 크게 두 가지 이유가 있습니다.

첫 번째는 Python 지식이 없어도 참가할 수 있다는 점입니다. 참가자가 다루는 것은 프롬프트, 즉 문자열뿐입니다. 프로그래밍 미경험자라도 라벨 정의를 상세하게 하거나, 구체적인 예시를 추가하거나, 모델에 역할을 부여하는 등의 시도를 할 수 있습니다.

두 번째는 실무에 직결되는 배움을 얻을 수 있다는 점입니다. 평소 프롬프트 엔지니어링을 체계적으로 배우지 않고 감각적으로 프롬프트를 작성하는 사람이 적지 않습니다. 또한, 프롬프트 엔지니어링을 배우더라도 그것이 얼마나 효과적인지 실감하기 어려운 면도 있습니다.

그러한 사람들에게 "프롬프트 작성 방식을 조금 바꾸는 것만으로 스코어가 이만큼 변한다"는 것을 리더보드 (Leaderboard) 상의 수치로서 정량적으로 체감할 수 있다는 점은 매우 유익합니다.

이번 경연의 데이터셋은 GPT의 API를 사용하여 사내 게시물 예문을 생성하는 방식으로 제작했습니다.

데이터 생성 코드에서는 전체 440건의 게시물을 작성하였고, 각 라벨이 균등하게 되도록 설계했습니다.

생성 흐름은 대략 다음과 같습니다.

• 라벨 정의, 생성 규칙, 업무 상황을 데이터 생성용 프롬프트에 정리
• gpt-4o-2024-08-06에 지정된 스키마에 따른 사내 게시물 예문을 생성하도록 함
• 생성 결과에 대해 중복, 너무 긴 문장, 개인정보로 보이는 문자열, 본문에 라벨명을 포함하는 문장 등을 필터링
• POLITE / NEUTRAL / CASUAL / TONE_RISK / RUDE가 동일한 수가 되도록 추출
• 각 라벨당 8개씩을 라벨이 붙은 샘플로, 나머지는 Kaggle의 테스트 데이터로 분할
• Kaggle용으로 test.csv, sample_submission.csv, solution.csv를 출력

생성 프롬프트에는 예를 들어 "정중한 말투지만 압박감이 느껴지는 게시물", "내용은 엄격하지만 톤은 평범한 게시물", "캐주얼하지만 무례하지 않은 게시물", "명확하게 공격적인 게시물" 등 분류 경계가 나타나기 쉬운 케이스도 지정했습니다. 단순히 LLM으로 문장을 대량 생성하는 것이 아니라, TONE_RISK와 RUDE, POLITE와 NEUTRAL 같은 경계를 고민할 수 있는 교재가 되도록 했습니다.

• sample_data.csv: 라벨이 붙은 샘플 40건
• test.csv: Kaggle 공개용 예측 대상 400건
• sample_submission.csv: 제출 형식 샘플
• solution.csv: Kaggle 관리용 정답 라벨

sample_data.csv는 각 라벨당 8개씩, test.csv는 각 라벨당 80개씩입니다. 평가 지표는 Accuracy입니다.

sample_data.csv에는 예를 들어 다음과 같은 데이터가 들어 있습니다.

id	post	label
tone_000397	그 수정안, 꽤 괜찮다고 생각합니다.	CASUAL
tone_000018	문의 내용은 확인했습니다.	NEUTRAL
tone_000120	자료 내용이 조금 허술해 보입니다.	TONE_RISK
tone_000060	내일까지 확인해야 하는 사항이므로, 시간 되실 때 대응해 주시면 감사하겠습니다.	POLITE
tone_000070	언제까지 기다리게 할 건가요. 적당히 좀 하세요.	RUDE

test.csv는 id와 post만을 가진 형식입니다.

id,post
tone_000234,아직 확인하지 못했다면 지금 바로 봐주세요.
tone_000310,이 자료 정말 이해하기 쉽네요!
...

제출 파일은 id,label의 2개 열로 구성됩니다.
베이스라인인 sample_submission.csv에서는 우선 모든 항목에 NEUTRAL이 들어가도록 설정되어 있습니다.

id,label
tone_000234,NEUTRAL
tone_000310,NEUTRAL
...

추론에는 Kaggle Notebook 상에서 Google Gemma 2 2B JPN IT를 사용했습니다.

베이스라인 Notebook에서는 Kaggle Input에 추가된 google/gemma-2-2b-jpn-it를 불러와 GPU T4 x2 환경에서 동작하도록 설계했습니다.

Gemma 2 2B JPN IT를 선택한 이유는 모델 크기와 성능의 균형이 적절했기 때문입니다.

2B 모델이기에 너무 무겁지 않아 Kaggle의 무료 GPU 환경에서도 현실적인 시간 내에 추론할 수 있습니다. 동시에 일본어 사내 게시물 톤 분류를 어느 정도 수행할 수 있는 성능도 갖추고 있습니다.

이보다 무거운 모델을 사용하면 성능은 올라가지만 추론 시간이 길어져, 2시간 정도의 이벤트에서는 충분한 시도 횟수를 확보하기 어려워집니다. 반대로 이보다 성능이 낮은 모델을 사용하면 분류 성능 자체가 나오지 않아, 프롬프트 (Prompt)를 개선하더라도 스코어 향상을 체감하기 어렵습니다.

베이스라인 Notebook에서는 최상단에 다음과 같은 BASE_PROMPT를 배치했습니다.

BASE_PROMPT = """<start_of_turn>user
사내 게시물의 톤을 분류해 주세요.
POLITE: 정중하고 배려가 있음.
...

이 심플한 제로샷 프롬프트 (Zero-shot Prompt)를 참가자들에게 배포하는 베이스라인으로 사용했습니다.

Notebook 측에서는 BASE_PROMPT.format(post=post)를 통해 각 게시물을 삽입하고, 생성 결과로부터 POLITE / NEUTRAL / CASUAL / TONE_RISK / RUDE 중 하나를 추출하여 submission.csv를 생성합니다.

참가자들에게는 "이 BASE_PROMPT의 삼중 인용부호 """...""" 안쪽만 편집해 주세요"라고 안내했습니다.

이어서 이번 이벤트에서 특히 효과적이었던 설계 및 운영상의 노하우를 정리합니다.

이번 경연에서는 참가자가 Python 코드를 직접 작성할 필요가 없도록 구성했습니다.

Notebook 최상단에 있는 BASE_PROMPT 문자열, 즉 삼중 인용부호 """...""" 내부의 내용만 수정하면, 나머지는 Notebook이 자동으로 추론하여 submission.csv를 생성합니다.

실제 Notebook에서도 편집해야 할 위치를 쉽게 알 수 있도록, 프롬프트 정의 셀 바로 앞에 다음과 같은 주석을 달아두었습니다.

# ============================================================
# ⚠️ 여기만 편집해 주세요: BASE_PROMPT의 내용을 구성합니다
# 아래의 LABELS나 이후의 셀은 그대로 실행하면 됩니다
...

또한, 이번 경연에서는 "프롬프트 엔지니어링 (Prompt Engineering) 능력을 겨룬다"는 점을 명확히 하기 위해 프롬프트 이외의 수정은 금지했습니다.

예를 들어, 다음과 같은 변경은 허용되지 않습니다.

• 후처리 로직을 추가하여 모델 출력을 수정하는 것
• max_new_tokens나 do_sample 등의 추론 파라미터를 변경하는 것
• parse_label()의 판정 규칙을 변경하는 것
• 모델이나 데이터 로드 부분을 변경하는 것

베이스라인 Notebook에서는 우선 베이스라인 프롬프트를 의도적으로 매우 심플하게 만들었습니다.

이는 참가자들이 "스스로 프롬프트를 개선하여 스코어를 올리는" 성공 경험을 쌓게 하는 것이 매우 중요했기 때문입니다.

처음부터 강력한 베이스라인을 제공하면, 초보자가 조금 수정하더라도 스코어가 거의 변하지 않아 "무엇을 바꿔야 할지 모르겠다"는 상태에 빠지기 쉽습니다. 따라서 베이스라인에는 의도적으로 개선 여지를 남겨두었습니다.

그와 동시에 프롬프트 정의 셀을 Notebook의 가장 상단에 배치했습니다.

참가자가 시행착오를 거칠 때마다 Notebook의 아래쪽까지 스크롤해야 한다면, 그것만으로도 경험(Experience)이 저하됩니다. 그래서 '조작하는 위치'를 최상단에 고정했습니다.

나아가, 베이스라인 프롬프트(Baseline Prompt) 바로 아래에 개선 사례를 Markdown으로 구체적으로 기재했습니다.

예를 들어, 역할 프롬프팅 (Role Prompting)의 개선 사례로는 다음과 같은 문장을 맨 앞에 추가하는 안을 제시했습니다.

당신은 일본어 직장 커뮤니케이션에 정통한,
사내 메시지 톤 분석 전문가입니다.

Few-shot의 예시로는 각 라벨(Label)의 대표 사례를 프롬프트 내에 넣는 형태를 제시했습니다.

게시물: 내일까지 확인 부탁드리는 사항이오니, 시간 되실 때 대응해 주시면 감사하겠습니다.
라벨: POLITE
게시물: 거래처로부터 회신을 기다리는 중입니다. 진전이 있으면 공유하겠습니다.
...

사전 설명에서도 역할 프롬프팅 (Role Prompting)과 Few-shot 프롬프팅 (Few-shot Prompting)을 간단히 소개했습니다. 추상적으로 "프롬프트를工夫(고안)해 주세요"라고 말하기보다, "이렇게 쓰면 된다"라는 구체적인 예시를 보여줌으로써 초보자들이 압도적으로 쉽게 시작할 수 있도록 했습니다.

Kaggle에서는 팀 머지 (Team Merge)가 가능하지만, 초반에는 의도적으로 금지했습니다.

이유는 모든 참가자가 "스스로 프롬프트를 개선하여 스코어(Score)가 올라가는" 경험을 하게 해주고 싶었기 때문입니다.

예를 들어, 베이스라인 스코어가 0.25인 상태에서 초반에 팀을 맺었다고 가정해 봅시다. 그 후 팀원이 0.50을 기록하고 본인이 0.40을 기록했다면, 본인 스스로는 0.25에서 0.40으로 크게 개선한 것입니다.

하지만 팀으로서는 0.50 제출물이 채택되기 때문에, 본인의 0.40 제출물로는 리더보드 (Leaderboard) 상의 순위가 움직이지 않습니다.

리더보드 순위가 자신의 고민과 노력에 따라 올라가는 경험이야말로 Kaggle 재미의 핵심입니다. 그 경험을 모두가 맛보게 하기 위해, 초반에는 개인으로 임하는 시간으로 정하고, 우선 자신의 프롬프트 개선으로 순위가 움직이는 감각을 익히도록 했습니다.

그 후, 어느 정도 개인적으로 시행착오를 거친 타이밍에 지식 공유나 팀 머지 (Team Merge)를 해금하는 흐름으로 구성했습니다.

다만 이 점에 대해서는, 팀 머지를 처음부터 하는 편이 북적북적하게 즐길 수 있고 참가자 간의 교류도 생기기 쉽다는 측면도 있으므로, 이벤트의 목적이나 참가자의 속성에 따라 어떤 형식이 좋을지 검토하는 것이 좋다고 생각합니다.

Kaggle 초보자를 위해 사전 메일과 행사장 안내를 통해 다음 두 가지 사항을 반복해서 공지했습니다.

• 전화번호 인증을 완료할 것
• Google Gemma의 이용 약관에 동의할 것

Kaggle Notebook에서 GPU를 사용하려면 전화번호 인증이 필요합니다. 또한, Gemma와 같은 모델을 Kaggle 상에서 이용할 경우 모델 이용 약관에 대한 동의가 필요합니다.

이 부분을 당일에 처음 안내하면, GPU를 사용할 수 없거나 모델을 불러올 수 없는 등의 트러블로 인해 핸즈온 (Hands-on) 시간이 크게 깎이게 됩니다.

당일에도 행사장에 일찍 도착한 참가자들에게는 시작 전 대기 시간을 활용해 Kaggle 전화번호 인증과 Gemma 이용 약관 동의가 완료되었는지 확인하도록 했습니다. 사전 메일을 읽었더라도 실제로 Notebook을 열기 전까지는 놓치기 쉬운 포인트이므로, 시작 전에 반복해서 안내해 두면 안심할 수 있습니다.

이번에는 사전 공지와 당일 시작 전 안내를 철저히 한 덕분에, 당일 GPU 미사용 및 이용 약관 에러는 거의 제로에 가깝게 억제할 수 있었습니다.

Kaggle Notebook에서는 Save & Run All을

한 뒤 결과 파일을 제출(Submit)하는 방법도 있습니다.

하지만 초보자 대상 이벤트에서는 조작 단계가 늘어날수록 혼란을 느낄 요소도 많아집니다.

이번에는 Notebook 우측의 Submit 버튼을 통해 일괄 실행 및 제출하는 방법만 안내했습니다. 참가자에게 보여주는 동선을 하나로 압축함으로써 질문 대응도 상당히 수월해졌습니다.

당일에는 의도적으로 세세한 설명은 생략했습니다.

예를 들어, 다음과 같은 내용은 첫 설명에서 다루지 않았습니다.

• 제출 이력 (Submit History) 확인 방법
• 생성된 CSV 확인 방법
• GPU 동시 실행 수의 상한
• Notebook 버전 관리

물론 모두 Kaggle을 깊이 있게 사용하는 데 있어 중요한 지식이지만, 처음부터 전부 설명하려고 하면 정보 과다로 인해 참가자들이 혼란에 빠질 수 있습니다.

이번에는 우선 Submit까지 진행하여 즐거움을 느끼는 것을 우선순위로 두고, 세세한 질문에는 그때마다 대응하는 방식을 취했습니다.

운영진 멤버들에게는 행사장 내부를 자유롭게 돌아다니며 참가자들을 서포트하도록 했습니다.

Kaggle Notebook 화면, GPU 설정, 모델 추가, Submit 버튼 등 초보자가 막히기 쉬운 포인트는 어느 정도 정해져 있습니다. 질문이 나오면 즉시 근처의 서포터가 대응할 수 있도록 함으로써, 전체 진행을 멈추지 않고 이어갈 수 있었습니다.

당일에는 무엇보다 참가자 전원이 즐겁게 참여하는 것을 최우선으로 했습니다.

이를 위해 참가자 간의 잡담이나 상담은 허용했습니다. 묵묵히 개인적으로 경쟁하는 것뿐만 아니라, 주변 사람과 "어떻게 작성해야 스코어가 올라갔는지", "이 라벨의 차이가 어렵다"라며 대화하며 진행할 수 있는 분위기를 중요하게 여겼습니다.

또한, 컴피티션(Competition) 서포트 멤버들에게는 곤란해하는 참가자가 있다면 힌트나 프롬프트(Prompt) 개선안을 적극적으로 전달해도 좋다는 방침을 사전에 공유해 두었습니다.

통상적인 Kaggle 컴피티션에서는 참가자 간에 해법이나 제출 내용을 공유하는 프라이빗 셰어링(Private Sharing)이 금지되어 있습니다. 하지만 이번에는 참가자들에게 Kaggle이나 프롬프트 개선의 즐거움을 체험하게 하는 것을 목적으로 한 오리지널 컴피티션입니다. 따라서, 엄격한 경기성보다는 전원이 즐겁게 1회 이상의 서브밋(Submit)을 제출하고, 스코어 개선을 체험할 수 있는 것을 우선했습니다.

컴피티션 종료 후에는 프라이빗 리더보드(Private Leaderboard)를 하위권부터 순서대로 스크롤하며 보여주며, 상위자의 이름과 스코어를 발표해 나갔습니다.

순위가 조금씩 밝혀지는 형식을 취함으로써, 마지막까지 행사장 전체가 고조되는 시간이 되었습니다.

또한, 상위 3명에게는 자신이 사용한 프롬프트나 고안한 포인트를 그 자리에서 발표하도록 했습니다. 이를 통해 단순한 순위 발표로 끝나지 않고, 참가자 전체가 지견(Knowledge)을 얻어갈 수 있는 시간이 되었습니다.

컴피티션 종료 후, 참가자 전원에게 Kaggle Discussion에 "자신의 순위와 프롬프트"를 게시하도록 했습니다.

이는 다음과 같은 두 가지 의미에서 중요하다고 생각합니다.

• 상사에게 보고할 자료로 활용할 수 있음
• 커뮤니티의 지견으로 남을 수 있음

이벤트 중에 탄생한 프롬프트가 그 자리에서 사라져 버린다면 아깝습니다. Discussion에 남겨둠으로써 나중에 참가자들끼리 다시 살펴보거나, 다음 이벤트의 교재로 재사용할 수 있습니다.

친목회는 지정석이 아닌 스탠딩 형식으로 진행했습니다.

그룹사 횡단 이벤트에서는 평소 대화할 기회가 없는 사람과 교류할 수 있다는 것 자체에 큰 가치가 있습니다. 자리를 고정하지 않음으로써 Kaggle 경험자, 초보자, 다른 회사의 참가자가 자연스럽게 섞이기 쉬워졌습니다.

명찰에는 5색 스티커를 붙여 Kaggle 랭크를 알 수 있게 했습니다.

이를 통해,

• "Kaggle을 막 시작했습니다"
• "Competitions를 자주 하고 있습니다"
• "어떤 컴피티션에 참여하고 계신가요?"

와 같은 대화가 생겨나기 쉬워졌습니다.

당일, 행사장 Wi-Fi를 통해 약 80명이 일제히 자신의 Kaggle 프로필 페이지를 경유하여 컴피티션에 Join하려고 하자, Too Many Requests 에러가 발생했습니다. Kaggle 측에서 봇(Bot)과 같은 접속으로 판단했을지도 모릅니다.

원인은 명확히 밝혀지지 않았지만, 자신의 프로필 페이지를 경유하여 컴피티션 페이지로 이동하는 동선이었던 점도 영향을 미쳤을 가능성이 있습니다. 컴피티션 페이지의 URL로 직접 접속할 수 있는 동선이었다면 문제가 발생하지 않았을 가능성도 있지만, 이 점은 미검증 상태입니다.

대처 방안으로, 테더링이 가능한 참가자에게는 스마트폰 테더링으로 전환하도록 안내했습니다. 이를 통해 Join할 수 없던 문제는 해결되었습니다.

이번 개선점으로는 테스트 데이터 400건은 조금 많았을지도 모르겠습니다.

베이스라인과 같은 짧은 프롬프트라면 문제가 되기 어렵지만, 참가자가 Few-shot 예시를 늘리거나 라벨 정의를 매우 정성스럽게 작성하면 1건당 추론(Inference) 시간이 늘어납니다. 그 결과, 프롬프트가 길어진 경우에는 1회의 Submit에 20분 정도 걸리는 케이스도 있었던 것 같습니다.

2시간의 이벤트에서는 1회의 Submit에 시간이 걸리면 시도 횟수가 줄어들게 됩니다. 프롬프트를 바꾸고, Submit하고, 스코어를 확인하고, 다시 개선하는 사이클을 여러 번 반복하게 하려면 테스트 데이터는 조금 더 적게 설정했어도 좋았을 것이라고 느꼈습니다.

또한, 계산 시간 관점에서는 사용 모델의 선정에 대해서도 조금 더 검증할 여지가 있었습니다.

이번에는 Gemma 2 2B JPN IT를 사용했습니다만, 향후 동일한 이벤트를 개최한다면 Gemma 2보다 최신이면서도 더 경량화된 모델도 후보에 넣어 비교하는 것이 좋을 것 같습니다. 예를 들어, 1B 클래스의 모델이라도 Gemma 2 2B JPN IT와 비슷한 수준으로 일본어 분류가 가능하고 추론 시간 (Inference Time)을 단축할 수 있다면, 참가자의 시도 횟수를 늘릴 수 있는 가능성이 있습니다.

반면, 모델이 너무 강력하면 단순한 프롬프트 (Prompt)만으로도 쉽게 해결되어 버려 프롬프트 개선의 재미가 반감됩니다. 반대로 너무 약하면 아무리 프롬프트를 고안해도 제대로 분류하지 못해 개선의 보람을 느낄 수 없습니다.

프롬프트 엔지니어링 (Prompt Engineering)형 경연에서는 모델 성능이 높으면 높을수록 좋은 것이 아니라, "고안하면 제대로 성능이 오르지만, 고안하지 않으면 한계가 있는" 정도의 난이도로 조정하는 것이 중요하다고 생각합니다. 이 부분은 다음 개최 시 여러 모델로 사전에 추론 시간과 베이스라인 스코어 (Baseline Score)를 비교하여 더 적절한 균형점을 찾고 싶습니다.

설문 조사 설계에도 개선의 여지가 있었습니다.

참가 후 설문에서는 "다음번에 개최를 희망하는 내용"에 대해 몇 가지 후보를 준비하여 선택식으로 답변을 받았습니다. 다만, 저희가 준비한 후보만으로는 참가자가 정말로 해보고 싶은 테마나 운영 측에서 예상하지 못했던 니즈 (Needs)를 모두 파악하지 못할 가능성이 있습니다.

다음에는 선택식 문항에 더해, "다음에 해보고 싶은 것"을 자유 기술로 작성할 수 있는 칸도 마련하고 싶습니다. 그렇게 함으로써 참가자의 온도감이나 구체적인 기대치를 더 잘 파악할 수 있게 되어, 다음 이벤트 기획에 활용하기 쉬워질 것이라고 느꼈습니다.

이벤트 후에는 참가자를 대상으로 설문 조사를 실시했습니다.

설문에는 93명이 응답해 주셨습니다.

결과적으로, 이벤트 만족도는 4.73 / 5였습니다.

또한, "Kaggle의 즐거움을 느낄 수 있었습니까?"라는 문항에 대해서도 4.71 / 5라는 결과가 나왔습니다.

초보자를 포함한 이벤트로서, Kaggle의 즐거움을 어느 정도 체험할 수 있었던 점은 좋은 점이었다고 생각합니다.

자유 기술에서도 다음과 같은 코멘트를 받았습니다.

• 학생 때부터 Kaggle을 접해보려 했지만, 결국 접하지 못한 채 직장 생활을 보내고 있었기에 이런 기회를 주셔서 진심으로 감사드립니다. 생성 AI (Generative AI) 덕분에 진입 장벽은 낮아졌다고 생각하지만, 그렇다 하더라도 초보자가 갑자기 시작하기는 어렵다고 생각하기에 이런 자리는 매우 도움이 됩니다. 다음에도 꼭 참여하고 싶습니다.
• 미니 경연의 난이도가 적당해서 누구나 참여할 수 있다는 점이 좋았습니다.
• 미니 경연의 테마가 접근하기 쉬워서, 스코어를 높이기 위한 시행착오를 즐기면서 임할 수 있었습니다. 감사합니다.
• 실전에서 경연을 해보는 것이 단순히 이론 공부를 하는 것보다 몸에 더 잘 익는다고 느꼈습니다.
• Kaggle에 도전하려는 허들이 낮아졌습니다.
• 이전에는 포기했었지만, 앞으로는 Kaggle에 참여하고 싶다는 생각이 들었습니다.
• 유행하는 생성 AI를 활용한 것이면서 초보자도 참여하기 쉬운 내용이라 매우 좋았다고 생각합니다. 정말 즐거웠습니다. 감사합니다.
• Kaggle의 하나의 허들은 첫 제출 (Submit)을 하는 것이라고 생각합니다. Kaggle 웹 페이지는 다소 독특한 면이 있는데, 그 안에서 첫 제출까지의 일련의 경험을 할 수 있는 것은 매우 좋은 핸즈온 (Hands-on)이었다고 생각합니다. 또한 간편하게 스코어가 올라가는 경험도 할 수 있어서, Kaggle의 가장 즐거운 부분을 맛볼 수 있었다고 생각합니다.

이번 이벤트에서는 약 2시간이라는 제약 속에서 경연 참여, 노트북 (Notebook) 실행, 첫 제출 (Submit), 프롬프트 개선, 리더보드 (Leaderboard) 발표까지 일련의 과정을 실시했습니다.

당일 진행을 원활하게 하기 위해서는 사전 준비에 대한 안내와 당일 지원 체계 설계가 매우 중요했습니다. 특히 Kaggle 초보자가 막히기 쉬운 포인트를 사전에 상정하고, 그 부분을 중점적으로 지원하는 체계를 만드는 것이 중요합니다.

또한, 폭넓은 참가자들에게 Kaggle의 즐거움을 체험하게 하기 위해서는 경연 내용 설계도 매우 중요합니다. 이번에 성공적이었던 포인트로는 주로 다음의 두 가지를 꼽을 수 있습니다.

• Python 지식이 없어도 참여할 수 있는 프롬프트 엔지니어링형 경연으로 구성한 것
• 베이스라인 프롬프트를 일부러 단순하게 설정하여, 초보자가 고안을 통해 스코어가 올라가는 경험을 얻을 수 있도록 한 것

Kaggle 초보자 대상의 사내 이벤트나 생성 AI 활용의 입구로서 상당히 궁합이 좋은 소재라고 느꼈습니다.

앞으로도 이번 이벤트의 내용이나 운영 방식의 노하우를 개선(Brush-up)해 나가면서, 그룹 전체의 데이터 활용 능력 및 AI 활용 능력을 끌어올리는 활동을 지속해 나가고자 합니다!