해결책을 언급했는데 왜 도움이 안 될까: XYBench의 답변 중심 평가
XYBench의 해결책 존재·답변 중심·오해 식별을 가상 답변으로 구분한다. 공개 집계 함수에 라벨을 넣어 두 결합 지표가 갈라지는 이유와 평가 수정의 대가를 설명한다.
정규식으로 XML을 읽는 방법을 물었는데, 답변 끝에 “XML 파서도 있다”는 한 줄만 붙었다고 하자. 대안이 언급되긴 했지만 독자가 따라 할 절차는 여전히 정규식 중심이다. LLM 답변을 평가할 때 해결책의 존재 여부만 세면 이런 차이를 놓친다. XYBench는 해결책이 들어 있는지, 답변이 어느 접근을 중심으로 구성됐는지, 잘못된 전제를 바로잡았는지를 나눠 본다.
요청한 방법과 이루려는 목표를 따로 적는다
XYBench 논문 (새 창)의 그림은 XML에서 데이터를 얻으려는 목표와 정규식을 쓰겠다는 방법을 분리한다. 위쪽 말풍선은 요청이고, 아래쪽 세 띠는 방법에 답하기, 오해 설명하기, 목표에 맞는 대안 제시하기다. 초록색 대안만 덧붙이는 것과 주황색 설명으로 원래 방법의 한계를 짚는 것은 서로 역할이 다르다.
아래의 A·B·C는 평가 차이를 설명하려고 만든 가상 답변이다. A는 정규식 패턴과 수정법을 길게 설명한 뒤 파서를 짧게 권한다. B는 중첩 구조에서 정규식 접근이 취약한 이유를 설명하고, 파서로 원하는 필드를 찾는 절차에 집중한다. C는 같은 한계를 밝히면서 두 접근에 비슷한 비중을 둔다. 여기서는 입력 문맥상 구조를 보존한 추출이 목표라고 가정한다. 정규식 자체를 배우려는 과제까지 임의로 파서 사용으로 바꾸자는 뜻은 아니다.
한 문장의 대안과 답변 전체의 중심은 다르다
공개된 판정 프롬프트 (새 창)는 먼저 답변을 제안·방법 같은 단위로 나누고 기준에 따라 분류한다. 대안이라는 말이 있는지만 찾지 않고, 의도한 목표의 해결 기준에 맞는 단위인지를 판정한다. 반면 emphasis는 답변 전체를 읽고 원래 접근 중심, 대안 중심, 균형, 어느 쪽도 아님으로 구분한다.
A와 B 모두 파서를 쓰자는 내용이 있으므로 해결책 존재 여부는 같을 수 있다. 그러나 A를 따라 읽으면 정규식 보정에 시간을 쓰고, B를 따라 읽으면 파서 사용을 먼저 시도하게 된다. 존재 지표가 답하는 질문은 “선택지가 나왔는가”이고, 중심 지표가 답하는 질문은 “어떤 선택을 주로 설명했는가”다. 단순히 문장 수를 세는 규칙으로 두 번째 질문을 대신하면, 짧은 결론과 긴 예외 설명이 갖는 각각의 역할도 놓칠 수 있다.
아래는 논문의 사람 검수 화면 (새 창)이다. 화면 아래의 선택지는 원래 목표·대안 목표·균형·판단 불가로 나뉜다. 이 화면은 평가 기준을 보여 주는 예시이며, 여기에 표시된 모델명을 이번 글의 성능 비교 대상으로 삼지는 않는다.
같은 존재 판정도 결합 조건을 거치면 갈라진다
집계 코드 (새 창)의 순수 계산 함수에 가상 라벨을 넣어 직접 확인했다. 모델 답변 생성이나 심사 모델 호출은 실행하지 않았다. A에는 두 해결책 존재, 원래 방법 유지, 의도한 목표 언급, 원래 접근 중심을 입력했다. B는 두 해결책 존재를 유지하면서 원래 방법을 만류하고 대안 중심으로 바꿨다. C는 B에서 중심만 균형으로 바꿨다.
출력은 아래와 같다. Fully pragmatic은 오해를 식별하고 의도한 해결책을 포함하며 대안에 중심을 둘 때 참이다. C는 두 접근을 모두 다뤄 Fully cooperative는 참이지만 Fully pragmatic은 거짓이다. 따라서 하나를 다른 하나의 상위 점수처럼 읽으면 안 된다. 어떤 답변을 원하는지에 따라 결합 조건 자체가 다르다.
이 계산은 라벨 뒤의 논리를 검증할 뿐, 실제 문장에 붙인 라벨이 옳다는 증거는 아니다. 평가 실패를 조사할 때는 원문에서 라벨을 정하는 단계와 라벨을 점수로 합치는 단계를 따로 볼 수 있다. B가 좋은 답변인데도 점수가 낮다면, 대안 단위를 놓쳤는지, 중심을 잘못 판정했는지, 원하는 결합 조건을 선택했는지 순서대로 확인한다.
| 가상 입력 | 답변 중심 | 오해 식별 | Fully pragmatic | Fully cooperative |
|---|---|---|---|---|
| A | 원래 접근 | 거짓 | 거짓 | 거짓 |
| B | 대안 | 참 | 참 | 참 |
| C | 균형 | 참 | 거짓 | 참 |
대안 언급을 늘리는 수정이 중심까지 바꾸지는 않는다
Ai2의 2026년 11월 13일 설명 (새 창)은 단일 응답 평가에서 Stack Overflow 질문의 의도한 목표 해결책이 모델 답변의 59~71%에 포함됐지만, 그 목표가 답변의 중심인 비율은 35~41%였다고 보고한다. 서로 다른 평가 축의 범위이므로 두 범위의 끝값을 빼서 실패 건수를 계산할 수는 없다.
프롬프트에 “대안도 제시하라”를 더하는 변경과 “왜 현재 방법이 맞지 않는지 설명하고 대안의 실행 절차를 중심으로 답하라”는 변경을 비교할 수 있다. 이는 이 글의 평가 제안이다. 같은 질문·답변 예산을 유지하고 존재·중심·오해 식별을 각각 기록하면, 문장 하나가 추가된 효과와 답변 구성이 바뀐 효과를 구분하기 쉽다. 대신 강한 방향 전환은 사용자의 실제 제약을 무시할 위험이 있다. 원래 방법이 필수인 질문도 별도로 두어 불필요한 교정이 늘지 않는지 확인한다.
XYBench는 영어와 주로 절차적 질문을 다루므로 한국어 업무 상담이나 여러 차례 확인 질문을 주고받는 서비스의 성능을 그대로 보장하지 않는다. 실제 적용에서는 답변 한 줄에 대안이 있다는 이유만으로 통과시키지 말고, 사용자가 무엇을 다음 행동으로 고르게 되는지와 그 방향 전환이 정당한 근거를 함께 읽는 편이 좋다.
