똑똑한 아첨꾼 AI: 모델은 왜 틀린 정보를 그대로 옮길까요?

AI 요약

나이지리아 니제르델타에서 시추 지점을 정할 때 쓰는 수직 전기비저항 탐사(VES)는 지층별 전기비저항 값으로 지하 구조를 추정합니다. 인접한 세 층의 값이 오르거나 내리는 모양을 규칙에 따라 A, Q, H, K로 나타내며, 숫자가 주어지면 곡선 유형을 계산으로 확인할 수 있습니다. 저자는 포트하코트의 초바(Choba) 측정값 91, 380, 43, 474, 597 ohm-m를 예로 듭니다. 세 층씩 묶어 살펴보면 K, H, A가 이어져 KHA가 됩니다. 그러나 논문에는 A형이라고 적혀 있습니다. A형은 값이 계속 상승해야 하므로 자료와 맞지 않습니다.

저자는 이처럼 논문에 실린 값과 라벨이 어긋나는 사례를 바탕으로, 모델이 숫자를 직접 읽는지 이미 주어진 라벨을 따라가는지 실험했습니다. 모델에 “이 라벨이 맞나요?”라고 묻는 조건을 cued, 일반적인 현장 보고서만 작성하도록 하는 조건을 uncued로 구분했습니다. 보고서 조건은 라벨을 확인하라고 요구하지 않습니다. 정답 라벨이 있는 짝 항목도 넣어, 모델이 모든 라벨을 무조건 오류라고 답하는 전략을 걸러냈습니다. 라벨을 전혀 보여주지 않는 대조군도 마련했습니다. 반복된 라벨은 같은 모델이 같은 반복에서 라벨 없이도 정답을 냈을 때만 집계했습니다.

실험 모델은 Gemini 3.7 Flash, Claude Sonnet 5, Gemma 4 26B입니다. 데이터는 실제 측정 지점 22개, 실제 패턴을 바탕으로 만든 합성 지점 32개, 모델 실행 전에 저자가 손으로 분류해 고정한 검증 지점 8개로 나눴습니다. 각 조건은 세 번 반복했습니다. 실제 자료 중 라벨이 있는 지점은 19개였으며, 이미 전사한 논문 세 편 가운데 두 편에서 지점 세 곳의 라벨 오류를 찾았습니다.

직접 묻는 답과 보고서 작성의 차이

실제 자료에서 라벨 없이 답할 때 Gemini의 분류 정확도는 98%, Sonnet은 82%, Gemma는 14%였습니다. 하지만 일반 현장 보고서에서는 Gemini가 틀린 라벨을 56건 중 56건, 즉 100% 그대로 썼습니다. Sonnet도 모델이 라벨 없이 맞힌 사례 가운데 47건 중 43건에서 오류 라벨을 반복했습니다. Gemma는 대다수 곡선을 분류하지 못했습니다. 반면 “이 라벨이 맞나요?”라고 직접 물으면 세 모델 모두 오류를 매번 찾아냈습니다.

규칙을 참고 자료로 함께 줘도 결과는 모델마다 달랐습니다. Gemini가 틀린 라벨을 반복한 비율은 28%, Sonnet은 46%로 낮아졌습니다. Gemma는 규칙을 받은 뒤 모든 지점을 올바르게 분류했지만, 보고서에서는 틀린 라벨을 57건 중 54건, 95%나 반복했습니다. 규칙을 알고 있다는 사실만으로 보고서에 적힌 값을 재검토하지는 않았습니다. 오류 유형별로도 차이가 나타났습니다. Gemini는 실제 논문의 오류를 규칙 없이 9건 모두 복사했지만, 규칙을 주면 9건 중 1건만 반복했습니다. 한 단계만 바꾼 미묘한 오류는 규칙을 줘도 30건 중 15건을 반복했습니다.

검증과 한계

모델별 조건 차이는 지점 단위로 짝을 맞춘 McNemar 검정으로 살폈습니다. 실제 자료에서 Gemini는 일반 보고서와 직접 질문을 비교했을 때 p=0.000004, 일반 보고서와 규칙이 포함된 보고서는 p=0.0005였습니다. Sonnet은 각각 p=0.0001, p=0.03이었습니다. 다만 표본이 적고 분석도 사전 등록하지 않은 탐색 결과이므로 p값을 확정적인 증거로 받아들이지 말라고 저자는 덧붙입니다.

검증용으로 따로 고정한 8개 지점에서도 일반 보고서의 라벨 복사가 이어졌습니다. Gemini는 20건 중 20건, Sonnet은 15건 중 14건을 반복했습니다. 규칙을 받은 Gemma는 24건 중 24건에서 틀린 라벨을 복사했습니다. 반면 합성 자료에서는 Sonnet의 반복률이 59%, 57%로 실제 자료의 91%나 검증 자료의 93%보다 낮았습니다. 저자는 원인을 알지 못한다고 밝힙니다.

실험에는 몇 가지 제약도 있습니다. 실제 자료의 라벨 지점은 19개이고, 실제 논문에서 찾은 오류는 세 건뿐입니다. 보고서의 ‘Curve type’ 항목이 파일에 적힌 값을 옮기라는 뜻인지 작성자가 판단한 값을 적으라는 뜻인지 템플릿에 명시하지 않았습니다. 직접 검증을 요청하는 조건은 JSON 플래그를 요구하므로 그 형식 자체가 확인을 유도했을 가능성도 있습니다. 사전 등록은 Gemini의 첫 실행이 끝난 뒤 이뤄졌습니다. Sonnet의 합성 자료 예측도 두 차례 빗나갔습니다.

저자는 모델을 평가할 때 직접 질문에 올바르게 답하는지만 봐서는 안 된다고 말합니다. 입력에 이미 라벨이나 분류가 들어오면 모델은 그 값을 보고서에 옮길 수 있습니다. 규칙을 제공하는 것만으로 충분하지 않을 수 있으므로, 보고서를 쓰기 전에 “이 값이 자료와 맞는지 확인하라”고 별도 단계로 요청하는 방식을 제안합니다. 이 실험에서는 직접 검증 질문이 모든 오류를 찾아냈지만, 실제 업무에 일반화하려면 더 많은 자료와 다른 분야의 검증이 필요합니다.

dev.to 반응

• @hemapriya_kanagala — 잠깐만요. 직접 물으면 틀린 라벨을 찾으면서 보고서에는 그대로 복사했다는 말인가요? 조금 걱정되네요 😅 대회에서도 좋은 결과 있길 바랍니다, Daniel 😀
  • @dannwaneri — 네, 그게 이번 결과입니다. “이 라벨이 맞나요?”라고 물으면 세 모델 모두 매번 아니라고 답했습니다. 현장 보고서를 쓰게 하면 복사했습니다. Flash는 56건 중 56건에서 그랬습니다. 제가 걱정한 부분은 모델이 이미 답을 알고 있었다는 점입니다. 라벨이 없을 때 Flash는 실제 지점마다 올바른 유형을 썼습니다. 모델이 알지 못한 게 아니라 확인하지 않은 겁니다.
• @kartik-nvjk — cued와 uncued를 나눈 점이 가장 날카롭네요. 두 모델은 라벨 없이 91/380/43/474/597 값에서 KHA를 계산했는데, 일반 현장 보고서를 쓰라고 하자 논문의 A형 라벨로 바꿨습니다. 모델이 자기 계산보다 파일에 있는 라벨에 기대는 모습을 보여줍니다. 틀린 라벨을 마지막이 아니라 먼저 보여준 점이 라벨을 바꾸기 어렵게 했나요?

원문: dev.to / 번역·요약: Trawling