AI가 티켓 분류는 잘하지만 총합계 계산은 틀리는 경우

_이 글은 Kaggle Benchmarking Challenge에 제출하는 내용입니다.

AI 모델은 수백 개의 지원 티켓을 분류하고, 카테고리로 정리하며, 요약본을 생성할 수 있습니다. 하지만 그 요약본의 숫자들이 실제로 방금 나열한 기록과 일치할까요?

이 질문이 저로 하여금 Cross-View Conservation이라는 벤치마크를 구축하게 했고, 이 벤치마크는 모델이 작업량이 증가함에 따라 동일한 답변의 두 가지 표현(representation)을 일관되게 유지할 수 있는지 테스트합니다.

가장 흥미로운 발견은 개별 항목을 정확히 처리하는 것이 최종 요약본의 합계까지 보장하지 않는다는 것이었습니다.

제가 벤치마크한 내용

Cross-View Conservation은 세 가지 작업량 크기(workload sizes): 100, 400, 800개 티켓에 대해 결정론적으로 생성된 합성 지원 티켓을 평가합니다. 각 크기마다 세 개의 고정 데이터 시드(data seeds)를 사용하여 모델당 총 아홉 가지 사례가 주어집니다.

각 티켓은 지역(region), 고객 등급(customer tier), 서비스(service), 심각도(severity), 상태(status)와 같은 필드를 포함합니다. 모델은 다음 순서로 적용되는 명시적인 분류 규칙을 받습니다:

1. status=closed인 경우, 해당 티켓을 CLOSED로 할당합니다.
2. 그렇지 않은 경우, 고객 등급이 enterprise이고 심각도가 최소 3 이상이거나, 서비스가 security이고 심각도가 최소 4 이상인 경우에 ESCALATE로 할당합니다.
3. 그 외의 경우, 고객 등급이 business이고 심각도가 최소 2 이상이거나, 지역이 EU이고 심각도가 최소 2 이상인 경우에 NORMAL로 할당합니다.
4. 나머지 모든 티켓은 QUEUE로 이동합니다.

예를 들어, 이 합성 티켓은 첫 번째 규칙이 우선하기 때문에 CLOSED에 속합니다:

TCK-0001 | region=APAC | tier=enterprise | service=search | severity=5 | status=closed

각 모델은 동일한 분류의 두 가지 뷰(view)를 반환해야 합니다:

• View A: 상세 분할 (Detailed partitions). ESCALATE, NORMAL, QUEUE, CLOSED 아래에 티켓 ID 목록을 나열합니다.
• View B: 집계 요약 (Aggregate summary). 각 카테고리의 티켓 수와 총 심각도를 보고하고, 전체 티켓 수도 함께 보고합니다.

모델은 숨겨진 참조 레이블을 받지 못합니다. 모델은 기록들을 분류하고 자체적으로 요약문을 생성해야 합니다.

심각도 총합계는 각 카테고리의 티켓 심각도 값을 더하는 것을 필요로 합니다. 800개의 티켓이라면, 이는 잠재적으로 수백 번의 덧셈을 의미합니다. 프롬프트에는 계산기, 코드 실행 또는 외부 도구가 제공되지 않습니다. 따라서 이 벤치마크는 규칙 적용, ID 추적, 긴 덧셈, 그리고 답변의 두 가지 표현 간의 일관성을 테스트합니다.

저의 주요 지표는 **정확한 자체 일관성(exact self-consistency)**입니다. 평가자는 모델이 제시한 목록으로부터 카운트와 심각도 합계를 재계산하여 보고된 요약문과 비교합니다. 필요한 총합계에서 단 하나의 단위라도 불일치하면 해당 케이스는 실패합니다.

자체 일관성은 정확성(correctness)과 같지 않습니다. 요약문은 잘못 분류된 목록과 일치할 수 있습니다. 이것이 제가 아이템 커버리지, 중복 할당, 결정론적 참조 대비 분류 정확도, 카운트 일치, 그리고 심각도 총합계 일치를 추적하는 이유입니다.

저는 이러한 실패 모드들을 하나의 정확도 점수 안에 숨기는 대신 분리하여 보고 싶었습니다.

테스트된 모델들

Anthropic, OpenAI, Google에 걸쳐 여섯 개의 모델을 선택하여 제공업체와 다양한 모델 오퍼링 전반의 동작을 비교했습니다. 이 라인업에는 두 가지 Gemini Flash 버전이 포함되어 있어 동일한 태스크 설계 하에서 그 결과를 특히 흥미롭게 비교할 수 있습니다.

현재 Kaggle 리더보드는 다음과 같은 결과를 보여줍니다:

공식 결과와 제가 이전에 진행한 검증 사이에는 중요한 구분이 있습니다. 그 별도의 검증 실행에서는 다섯 개의 Claude Opus 5 케이스가 완료되고 통과했지만, 네 번의 호출은 제공업체 할당량(provider quota)에 의해 차단되었습니다. 이러한 검증 결과는 공식 Kaggle 점수가 아닙니다.

평가 설정

모든 사례는 llm.prompt(prompt)를 사용하여 새로운 대화에서 실행되었습니다. 저는 외부 도구를 제공하지 않았고, 명시적인 추론 재정의(reasoning override)를 설정하거나, 사용자 지정 출력 토큰 제한을 지정하거나, 모델 생성 시드(model-generation seed)를 설정하지 않았습니다. 제공업체 및 모델 기본값이 적용되었습니다. 데이터 시드는 고정되었습니다.

이것은 추론 노력이나 토큰 효율성에 대한 통제된 비교가 아니라, 사용 가능한 기본 설정 하에서의 종단 간(end-to-end) 비교입니다. 모델들은 서로 다른 수의 출력 토큰을 사용할 수 있습니다.

현재 리더보드에는 GPT-6 Luna가 표시되어 있지만, 이전 검증 로그에서는 openai/gpt-5.6-luna로 식별되었습니다. 저는 그 검증 결과를 논할 때 두 레이블이 상호 교환 가능하다고 가정하기보다는 기록된 식별자를 유지합니다.

발견 사항

1. 정확한 분류가 정확한 집계(aggregation)를 보장하지 않음

티켓 100개 검증 사례 중 하나에서, openai/gpt-5.6-luna로 기록된 모델은 100개의 티켓을 모두 올바르게 분류했지만, 보고된 QUEUE 심각도(severity) 총합계는 24만큼 오차가 있었습니다.

개별 분류는 해당 사례에서 정확했지만, 집계 요약은 여전히 기록과 모순되었습니다.

분류 전용 벤치마크만으로는 레이블이 올바르다고 표시하고 이러한 불일치를 완전히 놓칠 수 있습니다.

2. 일치하는 개수(Matching counts)도 부정확한 심각도 총합계를 숨길 수 있음

Gemini 3.7 Flash는 검증 과정에서 또 다른 흥미로운 패턴을 보여주었습니다.

티켓 400개의 경우, 세 가지 시드 모두에서 400개의 티켓을 모두 올바르게 분류했고 카테고리 개수도 일치했습니다. 그러나 심각도 총합계는 모든 사례에서 틀렸으며, 절대 오차 범위는 1부터 19까지였습니다.

이것들이 반드시 큰 수치적 오류인 것은 아닙니다. 하지만 정확히 일치하는 평가(exact-match evaluation)는 의도적으로 엄격합니다: 작은 불일치라도 요약이 상세 결과와 더 이상 정확하게 일치하지 않음을 의미합니다.

800개의 티켓에서도 카테고리별 개수는 마찬가지로 오차가 발생했습니다. 관찰된 검증 사례에서 QUEUE의 개수는 4개에서 8개 사이의 오차를 보였습니다.

저장된 10월 10일 공식 Kaggle 실행 결과도 이러한 패턴과 일치합니다. 세 가지 800개 티켓 Gemini 3.7 Flash 사례 모두 정확한 총합계 일관성 검증에 실패했습니다.

각 워크로드 크기별로 세 가지 사례만으로는 보편적인 스케일링 법칙을 확립하기에는 부족합니다. 이 패턴이 얼마나 안정적인지 판단하려면 더 많은 반복 평가가 필요합니다.

3. 중복 할당은 파티션 자체를 무효화할 수 있습니다

800개 티켓 검증 실행에서, GPT-5.4 mini는 800개 티켓 ID 중 710개를 한 번 이상 반복하여 나열했으며, 이는 800개 티켓에 대해 총 1,857개의 ID 목록을 생성했습니다. 가장 자주 반복된 ID는 네 번 나타났습니다.

이 출력은 파티션(partition)이 아니었습니다. 유효한 파티션은 각 입력 티켓이 네 가지 카테고리 전체에 걸쳐 정확히 한 번만 나타나야 합니다.

이는 그 외에는 유효한 목록의 요약 계산을 잘못하는 것과는 다릅니다. 또한 이 사례는 헤드라인 점수와 함께 중복 및 커버리지 진단이 왜 중요한지를 보여줍니다.

4. 거부 응답은 오답과 다릅니다

더 큰 워크로드 검증 사례 두 건에서, 모델 openai/gpt-5.6-luna는 요청된 분류와 요약 생성을 거부했습니다. 한 응답에서는 다음과 같이 언급되었습니다:

모든 800개 티켓에 대해 누락이나 오분류의 위험 없이 정확한 분류와 요약을 신뢰성 있게 생성할 수 없습니다.

거부 응답은 자신감 있게 잘못된 총계를 반환하는 것과는 다릅니다. 둘 다 작업 완료 여부에 영향을 미치지만, 서로 다른 행동을 보여줍니다. 이것이 제가 모든 0점 점수를 동일한 종류의 실패로 취급하기보다 개별 출력과 실행 커버리지를 검토하는 이유입니다.

5. 관련 벤치마크는 다른 질문을 합니다

제가 찾은 가장 유사한 관련 작업은 Count It or Compute It: When a Tool Returns Rows, the Models That Count Them Right Spend the Tokens입니다.

해당 벤치마크는 모델이 도구(tool)를 통해 반환된 행(row)의 개수를 세는지 테스트하며, 일치하는 ID를 반환하는 접근 방식과 개수(count)를 직접 제공하는 접근 방식을 비교합니다. 보고된 결과들은 해당 특정 설정에서 출력 토큰 사용량과 카운팅 정확도 사이의 관계에 대해 논의합니다.

Cross-View Conservation은 다른 질문을 던집니다. 이는 배치(batch)가 커짐에 따라 모델 자체 티켓 분할 및 그 분할 요약이 일치하는지를 테스트합니다. 이 모델은 외부 도구로부터 목록을 받고 이를 세도록 요청받는 대신, 두 가지 뷰(view)를 모두 생성합니다.

두 벤치마크는 상호 보완적입니다. 하나는 카운팅 도구가 반환한 행을 연구하고, 다른 하나는 모델이 생성한 답변의 두 표현 간의 일관성을 연구합니다. 제 결과들은 모델 내부의 숨겨진 추론 과정에서 무슨 일이 일어났는지 확립하지 못하며, 더 많은 토큰을 사용하는 것이 반드시 문제를 해결한다는 것을 보여주지도 않습니다.

다음에 측정할 것들

이것은 초기 벤치마크이며, 모델 품질에 대한 결정적인 순위가 아닙니다. 모델당 9가지 케이스, 가변적인 출력, 제공업체 할당량(quota), 그리고 제공업체의 기본 설정 차이점들이 결론을 내릴 수 있는 범위를 제한합니다.

저는 세 가지 후속 실험을 우선순위에 둘 것입니다:

1. 반복 횟수 증가. 더 많은 시드(seed)를 사용하고, 완료된 케이스, 실패한 케이스, 차단된 케이스를 별도로 보고하며, 모든 모델에 대해 명시적인 분모(denominator)를 제시합니다.
2. 작업 부하 난이도 독립적으로 변화. 카테고리 균형, 티켓 모호성, 심각도 분포 등을 개별적으로 변경하여 실패와 관련된 조건을 식별합니다.
3. 생성 전략 비교. 모델에게 먼저 상세 목록을 생성하도록 요청한 다음 별도의 단계에서 요약을 계산하는 것이 두 뷰를 함께 생성하는 것과 비교하여 일관성을 개선하는지 테스트합니다.

또한 출력 토큰 사용량을 실패 진단(failure diagnostics)과 함께 보고할 것입니다. 이는 더 많은 토큰이 반드시 더 나은 추론을 의미한다고 가정하지 않으면서, 출력 길이, 일관성, 비용, 그리고 작업 부하 크기 사이의 관계를 특성화하는 데 도움이 될 수 있습니다.

가장 유용한 다음 단계는 단순히 모델을 더 많이 추가하는 것이 아닙니다. 어떤 실패 모드가 반복되는지, 어떤 조건에서 발생하는지, 그리고 다른 생성 전략이 이를 줄일 수 있는지 이해하는 것입니다.

나의 벤치마크

작업을 탐색하고, 결과를 검사하며, Kaggle에서 모델들을 비교해 보세요:

Cross-View Conservation: AI 모델의 답변은 대규모에서도 여전히 합이 맞을까?

아이디어는 간단합니다. 답변이 그저 그럴듯해 보이는 것만으로는 부족해야 합니다. 상세한 기록과 해당 기록의 요약본을 포함할 때, 두 가지 시점(view)은 일치해야 합니다.

Cross-View Conservation은 이러한 기대를 측정 가능한 테스트로 전환하여, 작업량이 증가함에 따라 어떤 일이 발생하는지 조사합니다.