당신은 text-to-SQL 모델에게 "회원 이름을 나열해 주세요"라고 요청합니다. 벤치마크의 골드 쿼리(gold query)는 first_name, last_name이라는 두 개의 컬럼을 반환합니다. 하지만 모델은 친절하게 결합된 전체 이름 하나를 반환합니다. 나란히 놓고 보면 모델의 답변이 논쟁의 여지 없이 더 나은 답변일 수 있습니다. 하지만 평가기(scorer)는 매번 이를 오답으로 처리하며, 이로 인해 당신의 엔진 점수는 실제 성능보다 낮게 측정됩니다.

-- gold: 두 개의 컬럼
SELECT first_name, last_name FROM member WHERE ...;

...

왜 모든 실행 정확도(execution-accuracy) 평가기가 이렇게 작동하는가

실행 정확도(Execution accuracy) — BIRD, Spider, 그리고 대부분의 프라이빗 text-to-SQL 평가(evals)의 기반이 되는 지표 — 는 두 쿼리를 모두 실행한 뒤 _위치 기반 값 튜플(positional value tuples)_을 비교합니다. BIRD의 표준 방식은 말 그대로 set(fetchall())을 비교합니다. 컬럼 이름은 의도적으로 무시되므로(별칭(alias)은 중요하지 않아야 함), 각 행의 _형태(shape)_만이 남게 됩니다. 결과가 아무리 내용상 옳더라도, 하나의 컬럼으로 된 결과는 결코 두 개의 컬럼으로 된 골드 쿼리와 일치할 수 없습니다.

이는 이미 모두가 알고 있는 '추가 컬럼(extra-columns)' 실패 사례의 거울 이미지입니다. 모델이 도움이 될 만한 추가 필드를 SELECT하면, 추가된 컬럼 때문에 튜플 일치성이 깨지는 현상 말입니다. 요청된 두 컬럼을 하나로 합치는 것은 아무도 요청하지 않은 컬럼을 추가하는 것만큼이나 치명적입니다. 평가기에는 "유사함"이라는 개념이 없습니다. 튜플이 일치하거나, 일치하지 않거나 둘 중 하나입니다.

손실은 실재하며, 측정 가능하고, 불균형합니다

우리는 프롬프트를 수정하기 전, 구조적 차이를 가진 우리의 free-lane 엔진으로 500개 질문의 BIRD-dev 실행을 분류했습니다. 결합(concatenation) 패턴은 명확했습니다:

• 238개의 손실 중 7개는 골드 쿼리가 컬럼을 분리해 두었음에도 컬럼을 결합했습니다.
• 256개의 승리 중 0개가 || 연산자를 사용했습니다. 즉, 이 연산자는 오답에서만 나타났습니다.
• 골드 쿼리 자체는 500개 질문 중 단 1개에서만 ||를 사용했습니다.

마지막 문장이 결정적인 근거입니다. 특정 구조가 손실의 3%에서 나타나고, 승리 사례에서는 전혀 나타나지 않으며, 골드 답변에서도 거의 나타나지 않는다면, 이를 지양하도록 만드는 것은 거의 순수한 이득(upside)입니다. 이 트레이드오프의 반대편에는 회귀(regress)할 만한 요소가 사실상 존재하지 않기 때문입니다.

해결책은 플래너 프롬프트(planner prompt)에 문장 하나를 추가하는 것입니다

파인튜닝(fine-tune)도, 리랭커(reranker)도 필요 없습니다. 단 하나의 투영 지시어(projection directive)면 충분합니다: 질문에서 명시적으로 하나의 결합된 문자열을 요구하지 않는 한, 요청된 각 속성을 별도의 컬럼으로 반환하라. 이를 배포하기 전, 우리는 플래그가 지정된 7개의 예측값을 수동으로 다시 분리(de-concatenated)한 뒤, 실제 SQLite 데이터베이스를 대상으로 재실행하여 결정론적 상한선(deterministic ceiling)을 확인했습니다: +3개의 질문이 오답에서 정답으로 바뀌었으며, 퇴보(regression)는 전혀 없었습니다. 실시간 재측정 결과도 이 방향성을 확인해 주었습니다: 전체 실행 과정에서의 || 결합(concatenation) 사례가 7건에서 3건으로 감소했으며, 상한선 확인을 위한 3개의 질문 중 2개가 일치하는 결과로 바뀌었습니다.

이 단일 지시어보다 더 중요한 것은 일반적인 방법론입니다. 첫째, 구조적 차이(structural differ)를 통해 손실(loss)의 덩어리를 분류하고, 둘째, 후보 해결책의 결정론적 상한선을 계산한 뒤, 그제서야 프롬프트를 수정하십시오. '느낌(vibes)'에 의존해 작성된 프롬프트 지시어는 과적합(overfit)되기 쉽지만, '7개 손실/0개 승리'와 같은 히스토그램을 바탕으로 작성된 지시어는 엔진 작업에서 얻을 수 있는 '공짜 점심(free lunch)'에 가장 가깝습니다.

규칙

모델의 역할은 답변을 예쁘게 만드는 것이 아니라, 답변의 형태(shape)를 맞추는 것입니다. 도움이 될 만한 결합(concatenation)이라 할지라도 여전히 잘못된 결과 집합(result set)입니다. 손실을 분류(bucket)하지 않는다면, 당신의 "오답" 중 일부가 사실은 모델이 당신의 정답(gold)보다 더 도움이 되려고 노력한 결과였다는 사실을 결코 알아차리지 못할 것입니다.

(이 지시어는 이제 영어로 질문할 수 있는 데이터 레이어인 nlqdb에 적용되었습니다. 이를 찾아낸 평가 하네스(eval harness) — 구조적 불일치 분류기(structural mismatch classifier), 결정론적 상한선 재점수화 도구(deterministic-ceiling re-scorer) — 는 공개된 BIRD/Spider 데이터셋과 당사의 ICP 형태 페르소나 벤치마크를 대상으로 실행되므로, 프롬프트 변경 사항은 막연한 추측이 아닌 측정된 변화량(measured delta)으로 반영됩니다.)

원문은 nlqdb.com에 게시되었습니다.