도구 금지 퍼즐평가, 조건 고정이 먼저

압축을 0.1 bpp까지 강하게 적용하면, 이미지 분할 성능 mIoU가 44.5에서 30.5로 떨어질 수 있다. 같은 이미지라도 전처리 조건 하나로 모델의 시각 판단이 달라질 수 있다는 뜻이다. 퍼즐추론 평가는 여기에 변수가 더 붙는다. “도구 없이 풀어라(확대 금지, 코드 금지)” 같은 제약을 문장으로만 적어두면, 결과는 그럴듯해도 재현이 어려워진다.

세 줄 요약

핵심 이슈: 사다리타기(라인 트레이싱) 같은 절차적 시각 퍼즐을 “도구/코드 없이” 풀게 하는 평가는, 성능 주장이라기보다 평가 제약을 어떻게 정의하고 로그로 남기느냐의 문제다.
왜 중요하나: 전처리(리사이즈·압축)만 바뀌어도 성능이 mIoU 44.5→30.5처럼 크게 흔들릴 수 있다. 퍼즐 평가에서 확대/크롭/도구 호출 같은 조건을 통제하지 않으면 비교가 어려워진다.
독자가 할 일: “도구 금지”를 문장으로만 선언하지 않는다. API의 tools 파라미터(빈 목록), 전체 프롬프트, 실행 로그를 함께 버전관리해 같은 조건으로 재실행 가능한 실험 묶음으로 만든다.

현황

“도구 없이 푼다”는 표현에는 두 요소가 섞여 있다. 하나는 모델 능력(추론이 되나)이다. 다른 하나는 평가 조건(도구·코드·확대 같은 보조수단을 막는다)이다. 후자는 자연어로 써 붙이는 순간 흔들리기 쉽다. 평가자가 어떤 뷰어를 썼는지, 이미지를 어떤 크기로 보여줬는지, 런타임에서 도구가 실제로 차단됐는지가 빠지기 때문이다.

업계 문서에서 반복되는 요지는 “도구”가 프롬프트 바깥에서 주입될 수 있다는 점이다. Anthropic 문서는 API 호출에서 tools 파라미터를 주면, 도구 정의와 구성, 시스템 프롬프트를 합쳐 ‘특수한 시스템 프롬프트’를 구성한다고 설명한다. 따라서 “도구 쓰지 마”를 유저 메시지에 적는 것과, 런타임에서 tools를 비워 도구 경로를 제거하는 것은 같은 조건이 아니다.

또 다른 축은 “이미지 조건”이다. 전처리 변화가 성능을 바꾼다는 점은 논문에서 수치로 보고된다. 예컨대 이미지 압축을 강하게 적용하면 분할 mIoU가 44.5에서 30.5로 낮아졌다는 결과가 있다. 주관 평가에서도 리사이즈-압축 프레임워크 선호도를 win rate로 두고, 95% 이항 비율 신뢰구간을 함께 제시하는 식으로 조건 차이를 측정한다(표본 n = 47). 퍼즐추론(라인 트레이싱)도 픽셀 기반 입력을 쓰므로, “확대 금지”를 통제하지 않으면 전처리·표시 조건이 개입할 여지가 생긴다.

분석

사다리타기류 퍼즐이 평가에 쓰이기 쉬운 이유는 정답 형식이 비교적 명확하기 때문이다. 시작점-도착점의 “쌍 매핑”을 답으로 강제하면 자동 채점이 가능하다. 문제는 그 다음이다. 이 과제는 ‘추론’이라기보다 ‘절차 수행’에 가깝다. 모델이 텍스트로 단계별 이동을 출력하면, 평가는 종종 “정답만” 뽑아 점수화하려고 한다. 이때 도구 금지, 확대 금지, 크롭 금지 같은 제약이 느슨하면 같은 과제라도 난이도가 달라진다.

한계도 뚜렷하다. 첫째, “도구”의 경계가 구현마다 다르다. 어떤 환경은 도구 호출을 막는다. 어떤 환경은 도구 정의가 시스템 프롬프트에 섞여 들어간다. 어떤 환경은 UI에서 사용자가 확대·스크롤을 할 수 있다. 둘째, 전처리와 표시 조건은 결과를 크게 흔들 수 있다. 압축만으로도 mIoU가 44.5→30.5로 변할 수 있다면, 라인 두께가 얇은 사다리타기는 리사이즈/압축/샤프닝에 더 민감할 수 있다. 그래서 “도구 없이도 잘 푼다”는 주장보다, 조건을 고정한 평가 프로토콜을 먼저 잡아야 한다.

실전 적용

프로토콜은 문장으로 적는 규칙이 아니라, 실행 가능한 설정 묶음이어야 한다. OpenAI 개발자 커뮤니티 글의 취지처럼, 프롬프트는 메시지뿐 아니라 도구 정의와 모델 설정까지 포함하는 “재사용 가능한 구성”으로 다뤄질 수 있다. 퍼즐추론 평가도 같은 방식으로 묶는다. (1) 입력 이미지(원본/리사이즈/압축 여부), (2) 표시/조작 제한(확대·크롭 금지 같은 UI 규칙), (3) 모델 호출 설정(tools 허용 여부 포함), (4) 채점 스크립트(정답 매핑 비교)를 한 저장소에서 버전관리하고, 실행 로그까지 남긴다.

예: 라인 트레이싱 퍼즐의 정답을 “A→3, B→1…”처럼 고정 포맷으로만 받게 한다. 모델에는 “이동 과정을 쓰지 말고 최종 매핑만 출력”을 요구해 채점 변동을 줄인다. 그리고 런타임에서 tools를 빈 목록으로 두어 도구 경로를 차단했는지, 그 설정이 시스템 프롬프트 구성에 어떻게 반영됐는지(도구 정의가 주입되지 않았는지) 로그로 남긴다. 이미지는 원본 파일 해시와 함께, 리사이즈/압축 파라미터를 실험 조건으로 명시한다. 조건별 점수도 분리해 기록한다.

오늘 바로 할 일:

tools가 주입되는 런타임이면 허용 도구 목록을 빈 값으로 고정하고, 호출 설정을 실행 로그에 저장한다.
문제 이미지에 대해 전처리(리사이즈·압축) 조건을 실험 변수로 분리하고, 조건별 점수를 따로 기록한다.
모델 출력 포맷을 “최종 매핑만”으로 강제해 자동 채점이 흔들리지 않게 만든다.

FAQ

Q1. “도구 사용 금지”를 가장 재현성 있게 쓰는 방법은 뭔가요?
A1. 유저 메시지에 금지 문구만 쓰지 않습니다. API/런타임에서 tools(또는 허용 도구 목록) 설정을 비활성화(빈 목록) 하고, 그 설정값과 전체 프롬프트(도구 정의가 포함될 수 있음)를 재실행 가능한 형태로 버전관리하는 편이 낫습니다.

Q2. 확대(zoom) 금지 같은 UI 제약도 ‘도구 금지’로 봐야 하나요?
A2. 같은 범주로 묶지 않고, 별도 평가 조건으로 분리해 기록하는 편이 안전합니다. 도구 호출은 런타임 설정으로 통제할 수 있습니다. 반면 확대/크롭 같은 UI 조작은 뷰어와 작업 흐름에 따라 달라질 수 있어 조건이 섞이기 쉽습니다.

Q3. 전처리 조건을 보고서에 어떻게 써야 설득력이 생기나요?
A3. 전처리 강도에 따라 성능이 달라질 수 있으니, 조건을 숨기지 않고 조건별 결과를 분리해 제시하는 편이 낫습니다. 관련 연구에서는 압축 강도에 따라 mIoU가 44.5에서 30.5로 변하는 식으로 수치를 보고하거나, 주관 평가에서는 win rate와 95% 신뢰구간, 표본 수(n = 47) 를 함께 제시합니다.

결론

사다리타기 같은 절차적 시각 퍼즐은 “정답이 명확해 자동 채점이 가능하다”는 장점이 있다. 다만 이런 과제에서는 조건 통제가 점수와 직결된다. 도구 금지는 문구가 아니라 설정이다. 재현성은 인상평이 아니라 로그로 확인한다. 다음 단계는 tools 설정, 프롬프트, 전처리 조건, 실행 로그를 한 묶음으로 정리해 공개 가능한 평가 패키지로 만드는 일이다.

Aionda

도구 금지 퍼즐평가, 조건 고정이 먼저

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기