오픽 답변의 약점 태그를 Jev로 판정하기까지
평가에서 Gemini에 9 대 7로 진 Jev를 판정기로 고르고, 질문을 다시 써서 정답률을 70%에서 93~97%로 올린 일. 그리고 받아쓰기가 지어낸 답을 Jev가 못 잡는 이유.
오픽 모의고사 앱에도 Jev를 붙였다. 앞의 두 편에서 Jev가 LLM과 어떻게 다른지, 세계일주 사이트에서 사진과 검색에 어떻게 썼는지를 썼는데, 이번에는 판정할 대상이 사람이 말한 영어다. 정확히는 사람이 말한 것을 Gemini가 받아쓴 글이다.
강의보다 데이터를 먼저
시작은 약점 맞춤 강의였다. 시험이 끝나면 문항별 피드백에서 약점을 골라 3분짜리 짧은 강의를 추천해 주는 프리미엄 기능을 생각했다. 그런데 지금 서버에 남는 건 시험 한 번의 평균 점수뿐이었다. 문항별 상세 피드백은 사용자 기기에만 있어서, 사람들이 어떤 약점을 많이 갖고 있는지 셀 수가 없었다.
그래서 순서를 바꾸기로 했다. 강의를 먼저 만드는 게 아니라 데이터부터 모은다. 실전 답변이 분석될 때마다 약점 태그를 판정해서 한 줄씩 저장하고, 강의는 그게 쌓인 뒤에 만든다. 사용자 화면은 하나도 바뀌지 않는 작업이다.
태그는 판정하는 주체에 따라 나눴다. 단어 수, 말하는 속도, 문장 수, 연결어 종류처럼 셀 수 있는 것은 코드가 센다. 앞 편에 쓴 대로 Jev는 계산기가 아니다. 발음처럼 들어야 아는 것은 Gemini가 채점하면서 함께 낸다. 남은 것이 "과거 일을 현재 시제로 말했나", "질문에 답하지 않았나"처럼 글을 읽고 판단해야 하는 태그 21개다. 이걸 무엇으로 판정할지가 문제였다.
평가에서는 Gemini가 이겼다
후보는 둘이었다. 이미 채점에 쓰고 있는 Gemini와 Jev. 합성 답변 30개에 사람이 정답 태그를 붙여 두고, 두 판정기에 똑같이 물어 비교했다. 결과는 Gemini가 더 맞은 경우 9번, Jev가 더 맞은 경우 7번, 같은 경우 6번이었다. 미리 정해 둔 기준대로라면 Gemini였고, 실제로 그렇게 정해서 판정기 코드를 Gemini 쪽으로 머지했다.
그런데 같은 평가에 다른 숫자도 있었다. 한 번 판정하는 데 Gemini는 1.4초, Jev는 0.19초가 걸렸다. 비용은 Gemini가 한 번에 0.000453달러였고, Jev는 입력 100만 토큰에 0.042달러라 답변 하나에 0.00005달러 안팎이다. 10분의 1쯤이다. 또 판정을 Gemini로 하면 채점 호출과 같은 Vertex 용량을 나눠 써서, 둘 중 하나가 429를 받을 수 있었다.
이 숫자를 보고 뒤집었다. "훨씬 빠르고 싸다, 최적화할 방법을 찾아라." 머지한 Gemini 판정기는 평가용으로만 남기고, 운영 판정기는 Jev로 정했다.
질문을 다시 쓰자 70%가 93~97%가 됐다
최적화는 작업 세션이 했다. 약한 태그마다 질문 후보를 몇 개씩 만들어 같은 요청에 나란히 넣고, 어느 쪽이 정답 라벨과 잘 맞는지 비교해서 골랐다. 가장 크게 달라진 건 3인칭 단수 -s가 빠졌는지 보는 태그였다.
합성 라벨로 측정. 바꾸기 전 질문 Do most third-person singular present-tense verbs lack the -s ending? → 바꾼 뒤 Does it contain mistakes like "he go", "she like" or "my brother work"…?
처음 질문은 "3인칭 단수 현재형 동사가 대체로 -s 없이 쓰였나"였다. 경향을 묻는 질문이다. 바꾼 질문은 "he go, she like, my brother work 같은 실수가 있나"다. 판단할 범위를 실수 하나로 좁히고 예시를 붙였다. 복수형이 빠졌는지 보는 태그도 같은 식으로 바꾸자, 심어 둔 실수를 하나도 못 잡던 것이 2개 중 2개를 잡았다.
반대로 뒤집어서 묻는 게 나은 태그도 있었다. "첫머리에서 질문에 답하지 않았나" 대신 "첫머리에서 질문에 바로 답하나"를 묻고 확률을 1에서 뺐다. 정답률이 81%에서 90%가 됐다. 부정형 질문은 Jev가 약하다고 TypeSafe 문서가 적어 둔 "간접적인 지시" 쪽에 걸리는 것 같다.
판정선은 세계일주 사이트처럼 태그마다 따로 잡았다. 0.5로 일괄해서 자르면 안 맞았다. 다만 정답률만 보고 고르면 함정이 있었다. 약점은 대부분의 답변에 없어서, 아무것도 못 잡아도 정답률이 90%대로 나온다. 그래서 재현율을 같이 보고, 정답률이 가장 높은 구간의 가운데를 판정선으로 잡았다. 구간의 맨 아래를 잡으면 0.05 같은 값이 나와서 모든 답변이 예가 된다.
요청 모양도 실험했다. 질문마다 붙인 예/아니오 설명(criteria)을 빼면 입력이 1,137토큰에서 719토큰으로 37% 줄었지만 정답률이 91%에서 84%로 떨어져서 그대로 뒀다.
10월 4일 새벽 운영에 켰다. 한 답변의 태그 21개를 한 요청에 묻는다. state에는 받아쓴 답변과 문항 문장만 넣고, 이름이나 이메일 같은 식별자는 보내지 않는다. 모델은 jev-latest 대신 jev-1.13.0으로 버전을 고정했다. 태그별 판정선이 1.13.0의 출력에 맞춰져 있어서, 별칭이 가리키는 모델이 바뀌면 판정선이 조용히 어긋난다. 새 모델이 나왔는지는 매주 월요일 아침 루틴이 확인하게 해 뒀다.
받아쓰기가 지어낸 답은 못 잡는다
같은 날 오후, 채점 개편 출시를 앞두고 다른 문제가 나왔다. 받아쓰기를 맡은 Gemini가 질문과 상관없는 말을 한 녹음을, 질문에 맞는 답처럼 지어내서 받아쓰는 경우가 있었다. 채점은 그 받아쓰기를 보고 매겨지니, 출시를 막을 수도 있는 문제로 올라갔다.
그래서 물었다. "지금 JEV 모델로 보완가능한건 없나?" Jev에는 이미 "질문에 답하지 않았나"를 보는 태그가 있었다. 그걸로 걸러 낼 수 있을지 조사 세션이 시험용 입력 815건으로 확인했다. 비용은 0.016달러쯤 들었다.
받아쓰기가 정확할 때는 잘 잡았다. 녹음 원문 대본을 그대로 넣으면 주제 밖 답 33개 중 32개를 잡았고, 주제에 맞는 답 17개와 정상 답변 118개에서는 하나도 잘못 잡지 않았다. 그런데 받아쓰기가 지어낸 12건은 하나도 못 잡았다. 확률이 0.03~0.06으로, 오히려 확실히 답했다고 봤다.
01오디오에는 질문과 상관없는 말이 들어 있다.
글이 이미 질문에 맞게 바뀌어 있으니, 글만 보는 Jev가 보기에는 질문에 답한 글이다. 앞 편에서 Jev가 사진을 보지 않고 사진 앱의 설명을 읽는다고 썼는데, 여기서도 똑같다. 오디오를 듣지 못하는 판정기는 받아쓰기 단계에서 생긴 거짓을 잡을 수 없다. 결국 고친 곳은 Gemini 받아쓰기 프롬프트 쪽이었다.
받아쓰기가 정상일 때 쓸모가 있느냐 하면 그것도 애매했다. 같은 받아쓰기에서 Gemini의 과제 판정과 95~96% 같았고, Gemini가 놓친 주제 이탈을 Jev가 새로 잡은 경우는 0건이었다. 채점 보조로 덧붙여서 얻는 게 거의 없었다.
끊긴 짧은 문장으로 말하는지 보는 태그도 같이 확인했는데, 이 태그는 받아쓰기의 마침표를 따라갔다. 같은 답변에서 마침표만 빼도 118개 중 3개, 쉼표를 마침표로 바꾸면 6개의 판정이 뒤집혔다. 사람이 문장을 어디서 끊었는지는 오디오에 있는데, Jev가 보는 건 받아쓰기가 찍은 마침표다.
그래서 Jev는 지금처럼 약점 태그를 모으는 데에만 두고, 등급에 들어가는 요소는 Gemini 채점 안에서만 판단하기로 했다. 같은 받아쓰기에 늘 같은 답을 낸다는 점은 장점으로 남았다.
운영에서 실제로 얼마나 맞는지는 아직 모른다
지금까지의 숫자는 전부 합성 답변과 시험용 녹음에서 나왔다. 사람이 정답을 붙인 라벨은 학습용과 검증용을 합쳐 60개뿐이다. 운영에서는 사용자 몇 명의 답변 수십 개가 쌓였는데, 그 판정이 실제로 맞는지는 아무도 확인하지 않았다. 쌓인 답변 일부를 뽑아 사람이 직접 라벨을 붙여 보면 알 수 있을 것 같다.
9 대 7을 뒤집은 판단이 맞았는지는, 질문을 고친 Jev와 Gemini를 그 라벨로 다시 맞붙여 보면 알 수 있을 것 같다. 강의는 그 데이터가 쌓이고 나서 만든다.
끝