[TS] MelLearn 프로젝트 퀴즈 정확도 개선기

목차

MelLearn 퀴즈 정확도 개선 기록

📝 개요

✅ 요구사항

학습 영역 (Category)

• Vocabulary

• Grammar

• Reading

• Listening
(Speaking 영역은 퀴즈 형식이 아닌, STT를 사용해 사용자의 발음의 정확도를 측정)

학습 난이도 (Level)

• Level 1 (Beginner)

• Level 2 (Intermediate)

• Level 3 (Advanced)

따라서 4개 영역 × 3단계 레벨 = 총 12가지 유형의 퀴즈를 지원해야 한다.

모델 및 환경

• 사용 모델: GPT-3.5-turbo-0125

• GPT-4도 고려했지만, 당시 기준으로 비용이 약 10배였기 때문에 효율성과 비용 측면에서 GPT-3.5 모델을 선택하였다.

• GPT-3.5 모델을 효율적으로 사용하기 위해 프롬프트 개선 중심으로 접근하였다.

❌ 초기 퀴즈 생성 프롬프트의 문제점

너는 외국어 문제 출제 위원이야. 너는 유저가 준 인풋들을 토대로 문제집을 만들어야해. 너가 만든 문제의 선택지와 정답은 반드시 명확해야해. 

아래는 유저 input 설명이야.
level : 난이도를 나타내는 1~3까지의 숫자가 주어져. 3단계로 갈수록 전문가 수준의 문제를 출제해야해.
category : 너가 출제할 4가지 카테고리중 하나가 주어져
totalProblem : 너가 만들어야 하는 문제의 개수를 나타내.
text: 유저가 제공하는 문장들이야. 이 문장들로 문제를 출제해.

아래는 Output 설명이야.
question : 너는 문제 출제 방식으로 빈칸뚫기, 동의어 반의어를 물어보는 유형을 채택해야해. 한 문장에 두개 이상의 question을 물어볼 수 없어. 'text'에서 인용한 외국어를 제외하고는 한국어를 사용해서 질문해야해.
selection : 4가지 선택지를 제공해야해. 각 선택지에 있는 정답과 오답이 명확해야해. 선택지는 외국어로 제공되어야 해.
answer : 선택지중에 정답인 선택지를 정수로 알려줘야해.
comment : 문제가 정답인 이유를 자세하게 적어줘야해. 유저가 알아 들을 수 있도록 반드시 한국어로 설명해야해.

너는 Output을 출력할 때 JSON 형식으로 출력해야해.

위 프롬프트는 영어로 된 프롬프트를 이해하기 쉽게 한국어로 번역한 것이다. GPT-3.5의 한국어 이해도가 낮기 때문에 실제 환경에서는 영어로 구성된 프롬프트를 사용했다.

1. 모델에 역할 부여

2. User Input 설명

3. Model Ouput 설명

📌 주요 문제점

1. 난이도 구분 불명확
→ level 별 퀴즈가 뚜렷하게 달라지지 않았다.

2. 카테고리 간 구분 부족
→ Category 별 퀴즈가 뚜렷하게 달라지지 않았다. 단어 퀴즈와 읽기 퀴즈가 유사하게 생성되었다.

3. Output 포맷 일관성 부족
→ 지시문까지 영어로 생성되거나, JSON 포맷이 일관되지 않아 역직렬화가 자주 실패했다.
 

프롬프트를 개선해야된다는 것은 알겠는데, 어떻게 개선해야하지?

문제를 해결한 시점에서 1년이 지난 지금, 이 영상의 주요 내용이 여전히 프롬프트 엔지니어링의 핵심으로 다뤄진다. 총 10시간 분량의 강연이지만, LLM을 활용한 프로젝트를 진행하거나 효과적인 프롬프트 설계 방법을 배우고 싶다면 꼭 시청해보길 강력히 추천한다.

💡 Solution 1: 프롬프트 분할

🧩 문제

• 토큰 수 증가
모든 지시문을 하나의 프롬프트에 몰아넣다 보니 프롬프트 길이가 길어져 토큰 수가 증가했다. 이는 모델 호출 비용의 증가로 이어지며, 비효율적인 구조가 된다.

• 지시문 충돌
다양한 작업을 한 프롬프트에 동시에 지시하면, 서로 충돌하는 지시문이 생길 수 있다.
예를 들어 퀴즈를 출제할 때 아래와 같은 프롬프트를 사용했다고 해보자.

...

listening 영역의 퀴즈를 출제할 때는, 문장에 빈칸을 뚫어 출제해
reading 영역의 퀴즈를 출제할 때는, 문장의 의미를 물어보는 퀴즈를 출제해

다른 유형의 퀴즈 출제 지시문 나열 ...

위와 같은 프롬프트 구조는 ‘Category’에 따라 다른 퀴즈를 출제하도록 요구하는 방식이다. 프로그래밍 관점에서 보면 일종의 분기문(if-else)처럼 보이지만, 언어 모델은 전통적인 프로그래밍 언어처럼 논리적 흐름을 정확히 따르지 않기 때문에 이 방식은 잘 작동하지 않는다. 즉, 지시문이 많고 복잡할수록 모델의 혼란 가능성이 높아진다.
 

• 유지보수성 감소
모든 로직을 하나의 프롬프트에 넣으면 구조가 복잡해져, 수정이나 기능 추가 시 프롬프트 전체를 다시 분석해야 한다. 결과적으로 유지보수가 어렵고, 협업 시 의사소통 비용도 증가하게 된다.

🔨 해결

• OOP의 SRP 원칙을 기준으로 프롬프트를 나눔

SRP(Single Responsibility Principle): 하나의 모듈(또는 함수, 클래스)은 하나의 책임만 가져야 한다는 원칙이다. 변경의 이유가 하나뿐이어야 유지보수가 쉬워진다.

• 프롬프트를 일종의 코드라고 보고, 불필요한 분기문을 제거하는 방향으로 설계

너는 외국어 문제 출제 위원이야. 너는 유저가 준 인풋들을 토대로 문제집을 만들어야해. 너가 만든 문제의 선택지와 정답은 반드시 명확해야해. 

아래는 유저 input 설명이야.
level : 난이도를 나타내는 1~3까지의 숫자가 주어져. 3단계로 갈수록 전문가 수준의 문제를 출제해야해.
category : 너가 출제할 4가지 카테고리중 하나가 주어져
totalProblem : 너가 만들어야 하는 문제의 개수를 나타내.
text: 유저가 제공하는 문장들이야. 이 문장들로 문제를 출제해.

아래는 Output 설명이야.
question : 너는 문제 출제 방식으로 빈칸뚫기, 동의어 반의어를 물어보는 유형을 채택해야해. 한 문장에 두개 이상의 question을 물어볼 수 없어. 'text'에서 인용한 외국어를 제외하고는 한국어를 사용해서 질문해야해.
selection : 4가지 선택지를 제공해야해. 각 선택지에 있는 정답과 오답이 명확해야해. 선택지는 외국어로 제공되어야 해.
answer : 선택지중에 정답인 선택지를 정수로 알려줘야해.
comment : 문제가 정답인 이유를 자세하게 적어줘야해. 유저가 알아 들을 수 있도록 반드시 한국어로 설명해야해.

너는 Output을 출력할 때 JSON 형식으로 출력해야해.

# 변경 전
- prompt/
  └── prompt.txt

# 변경 후
- prompt/
  ├── listening/
  │   └── listening.txt
  ├── grammar/
  │   └── grammar.txt
  ├── reading/
  │   └── reading.txt
  └── vocabulary/
      ├── beginner.txt
      ├── intermediate.txt
      └── advanced.txt

✅ 효과

• 카테고리 간 혼동과 난이도 모호성이 크게 줄어들었다.

• 유지보수가 쉬워졌다.

💡 Solution 2: 프롬프트 엔지니어링

1. 명확하고 구체적인 지시 제공

AI에게 원하는 결과를 얻기 위해서는 지시문을 명확하고 구체적으로 작성해야 한다. 예를 들어, "블로그 글 써줘"보다는 "초보자를 위한 500자 분량의 블로그 글을 써줘"처럼 요구사항을 구체화해야 한다.

• 한 문장에 여러 개의 빈칸을 생성

• 빈칸의 대상이 단어가 아닌 명사구, 절, 문장 전체인 경우 발생

• 감탄사, 접속사, 조사 등 의미 없는 품사에 빈칸을 뚫는 사례 발생

❓ 그렇다면, 추상적인 표현을 구체화하는 반복 작업만이 전부일까?

📌 LLM의 이해를 돕는 프롬프트 작성 전략

• 마크다운 문법 사용
프롬프트 내에 # 제목, - 리스트, 1. 순서 등의 마크다운 문법을 활용하면, 모델이 구조를 파악하고 구분해서 이해하는 데 도움이 된다. 특히 지시문이 여러 개일 때는 시각적으로도 구분이 쉬워져 정확도가 크게 향상된다.

• 출력 예시 제공
모델이 어떤 형태의 응답을 만들어야 하는지 감이 오지 않을 때, 직접 예시를 보여주는 것이 가장 확실한 방법이다. 이를 Few-shot prompting이라고도 하며, 반복적인 오류를 사전에 줄이는 데 효과적이다. 이는 추상화된 표현을 구체화하는것 뿐만아니라, 형식을 일치시키는데도 탁월한 효과가 있다. 자세한건 프롬프트 엔지니어링 2번에서 이어 설명하겠다.

• Chain-of-thought prompting (Step By Step)
"하나씩 단계적으로 생각해봐"와 같은 문장을 프롬프트에 포함시키고 순차적으로 단계를 나열한다면, 모델이 사고 과정을 명시적으로 표현하게 되어 복잡한 문제를 더 잘 해결하는 경향이 있다. 이는 Chain-of-thought prompting이라 부른다.
 

2. 예시 제공 (Few-shot Prompting)

AI에게 원하는 출력 형식을 예시로 보여주면, 그 형식에 맞춰 더 정확하게 응답한다.

예시: "다음 형식으로 요약해줘: 1. 주요 내용 / 2. 결론"

• 출력 형식이 정해져 있을 때 (예: JSON, 리스트, 표 등)

• 일정한 말투나 스타일을 유지해야 할 때

• 일관된 구조가 필요한 반복 작업일 때

✅ 적용

### Output format.

{
  "answerList": [
    {
      "answerWord": "",
      "lineIndex":
    }
    // ... more answers
  ]
}

3. 반복적 개선 (Iterative Refinement)

AI의 응답을 바탕으로 프롬프트를 지속적으로 수정해 나가며, 점진적으로 원하는 결과에 가까워질 수 있다.

📌 이 방식이 중요한 이유

• LLM은 사람과 다르게 암묵적 전제나 맥락을 공유하지 않기 때문에, 원하는 결과가 나올 때까지 계속해서 그 맥락을 "주입"해야 한다.

• 잘 작동하던 프롬프트도 입력 데이터가 조금만 바뀌어도 실패할 수 있다. 따라서 다양한 케이스를 실험하며 프롬프트의 범용성과 안정성을 확보해 가야 한다.

• 한 단계의 수정을 통해 새로운 문제가 드러나는 경우도 많다. 즉, 프롬프트 설계는 디버깅과 유사한 반복적인 과정이다.

• Prompt Engineering Conference 2023에서도 이 반복적 개선의 중요성은 핵심적으로 다뤄졌다. 연사들은 공통적으로 "처음부터 완벽한 프롬프트는 없다", "실패한 응답에서 배워야 한다"는 점을 강조했다.

💡 Solution 3: 프롬프트 체이닝 (Prompt Chaining)

복잡한 작업을 해결할 때, 한 번에 모든 과정을 처리하기보다 작업을 단계별로 나누고, 각 단계의 출력을 다음 프롬프트의 입력으로 사용하는 전략이다.

• Step 1: "문장에서 핵심 단어를 추출해줘"

• Step 2: "이 단어를 활용해 퀴즈를 만들어줘"

• Chain of Thought는 하나의 프롬프트 안에서 모델이 사고 과정을 단계적으로 설명하게 유도하는 방식이다.

• Prompt Chaining은 각 작업을 개별 프롬프트로 분리하고, 프롬프트 → 응답 → 프롬프트 → 응답… 식으로 결과를 순차적으로 연결하는 방식이다.

즉, 하나는 한 번의 호출 안에서 사고의 흐름을 유도하고, 다른 하나는 여러 번의 호출로 단계를 나누어 처리한다는 점에서 차이가 있다.

✅ 적용 사례

1. 1단계 프롬프트
→ 문장에서 학습에 적합한 단어를 추출하고, 그 단어가 문장 내 어디에 위치하는지까지 확인

2. 2단계 프롬프트
→ 1단계에서 선정된 단어와 위치를 활용해 문장에 적절한 빈칸을 뚫고, 퀴즈 형태로 출력

적용 결과

• 단계를 분리하자 역할이 명확해져 정확도가 향상됨

• 각 단계의 동작을 개별적으로 검증할 수 있어 디버깅이 쉬워짐

• 복잡한 요구사항도 더 안정적으로 처리 가능

❌ 이후 롤백 적용

📊 퀴즈 정확도 테스트

• 참여자: 팀원 4명

• 진행 기간: 시험 기간을 제외한 총 4주

• 주간 풀이 문항 수: 각 팀원은 매주 4가지 유형(듣기, 어휘, 문법, 독해)별로 20문제씩 총 80문제를 풀이

• 총 문항 수: 80문제 × 4명 × 4주 = 1,280문제

테스트 결과

📈 정확도 10% → 85%까지, 주차별 개선 요약

• 1주차
초기 프롬프트는 단어 추출 기준이 불명확하고, 빈칸 위치 선정도 모델이 자의적으로 처리했다.
→ 대부분의 문제에서 부적절한 단어 선정, 문장 구조 파손, 빈칸이 어색한 위치 등 오류 다수 발생했다.

• 2주차
프롬프트를 카테고리 별로 분할하고 Few-shot Prompting을 적용해 정확도를 50%로 크게 개선했다.
대부분의 퀴즈에서 정확도와 난이도 별 모호성이 해소되었다.
→ 하지만 Vocabulary 유형에서는 난이도 별 모호성이 존재했다.

• 3주차
Vocabulary 유형을 출제하면서 난이도 모호성이 계속 발생하였다. 그래서 Vocabulary 프롬프트를 난이도에 따라 프롬프트를 3개로 분리하였다.
→ 다른 영역의 프롬프트의 지시문도 지속적으로 구체화하여 75%로 개선했다.

• 4주차
Listening 유형의 퀴즈를 출제하는 방식을 분할하여 Prompt Chaining을 도입했다. 따라서 듣기 영역의 정확도가 크게 증가했다.
→ 최종 약 85%의 정확도로 마무리했다.

❓ 85%에서 더 개선할 순 없었을까?

• LLM의 할루시네이션 현상
모델이 존재하지 않는 단어나 문장을 지어내는 현상으로, 특히 특정 패턴이 반복되거나 문맥상 불분명할 때 자주 발생했다. 이는 프롬프트 수정만으로 완전히 제어하기 어려운 LLM의 근본적인 문제이다.

• GPT-3.5의 다국어 처리 한계
GPT-3.5는 영어 기반으로 최적화되어 있어, 한국어에서 문맥 해석이 약간 비틀어지는 경우가 있었다. 외국어를 학습하지만, 퀴즈의 포맷은 한국어로 출제해야 했기 때문에 부 정확했던 15%에서 대부분이 여기에 해당됐다. e.g) 다음 문장에서 빈칸에 들어갈 단어로 가장 알맞은 것은? I usually ___ coffee in the morning. 위의 예시와 같이 한국어 지시문 + 영어 문장이 혼합된 포맷을 유지해야 했지만, GPT-3.5는 때때로 지시문을 누락하거나, 문제 구조를 의도와 다르게 재구성해버리는 경우가 많았다.
이로 인해 문제의 일관된 포맷 유지가 어려워졌고, 그 결과 응답 품질이 불안정해지는 원인이 되었다.

• 프롬프트 토큰 길이 제한
긴 문장이나 복잡한 지시가 필요한 경우, 토큰 수 제한으로 인해 프롬프트가 잘리거나 응답이 누락되는 문제가 발생했다.

✍️ 회고 및 느낀 점

• 모델의 이해도에 맞춘 구조화

• 문제를 쪼개는 체계적인 설계

• 반복적인 테스트와 정량·정성 분석