LLM을 이용한 생성 문장 검수

규칙 검사로 답할 수 없던 질문

무작위로 조합한 영어 문장이 일부러 엉뚱하게 만든 것으로 읽히는지, 그냥 틀린 영어로 읽히는지 구분해야 했습니다. 관사와 문법처럼 답이 정해진 문제는 코드로 검사했지만, 문장이 의도대로 읽히는지는 직접 읽어야 판단할 수 있었습니다. 작가 5종·충돌 유형 5종·발화 형식 6종을 조합하면 확인할 경우가 150개라 사람이 매번 모두 읽기 어려웠습니다.

평가 범위와 기준

• LLM 평가는 개발 과정에서만 사용했습니다. 실제 게임의 문장 생성, 점수 계산, 무작위 선택과 등급 판정에는 연결하지 않았습니다.
• 8가지 기준을 1~5점으로 평가하게 하고, 판정과 실패 이유는 미리 정한 값만 쓰도록 응답 형식을 JSON으로 고정했습니다.
• 문장만 보여 주는 평가와 문장이 만들어진 조건까지 보여 주는 평가를 나눴습니다. 전자는 독자가 받을 인상을, 후자는 문제가 생긴 원인을 확인했습니다.
• seed를 고정해 같은 조건에서는 같은 표본이 나오게 했습니다. 조합별로 표본을 뽑고, 평가에 사용한 입력은 회차별로 따로 보관했습니다.
• 두 평가가 다르면 장점은 더 낮게, 위험은 더 높게 잡았습니다. 한 명이라도 결함을 지적하면 검토 대상으로 남겼습니다.

모델이 찾은 결함은 코드 규칙으로 남겼습니다

검수는 네 차례 진행했습니다. 먼저 20개 문장으로 평가 기준을 시험했고, 150개 조합 가운데 표본을 만들 수 있었던 144개를 평가했습니다. 이어 25개를 다시 평가하고, 서로 결과를 공유하지 않는 두 모델에 30건을 평가하게 했습니다. 표본을 만들지 못한 조합은 6개였습니다.

144개 조합을 평가하는 과정에서 주어와 동사가 맞지 않는 문장을 찾았습니다. 모델이 제안한 문장으로 한 번만 고치는 대신, 오류를 일으키는 복수 명사를 해당 위치에서 제외했습니다. 이어 그 자리에 올 수 있는 모든 명사를 검사하도록 코드를 바꿨습니다. 무작위 문장 120개만 확인하던 기존 검사도 수정하고, 일부러 오류를 넣은 5가지 경우로 제대로 잡아내는지 확인했습니다.

모델 평가가 놓친 오류도 있었습니다. 본문만 평가했기 때문에 제목에 관사가 빠진 문제는 잡지 못했습니다. 제목 1,000개를 따로 확인해 잘못된 문장 비율을 9.6%에서 0%로 낮췄습니다.