같은 LLM인데 API마다 답이 다르다, 모델이 바뀐 걸까?

다른 답 한 번과 반복되는 출력 변화

같은 모델 이름을 고르고 같은 질문을 보냈어도 두 API가 다른 문장을 내놓을 수 있다. 생성 과정에서 여러 응답을 뽑을 수 있기 때문에 문장 두 개가 같지 않다는 사실만으로 공급자가 모델을 바꿨다고 결론 내릴 수는 없다. 반면 여러 질문에 반복해서 받은 응답의 패턴이 달라졌다면, 단순한 한 번의 차이보다 더 구체적으로 조사할 수 있다.

아이리나 가오·퍼시 량·카를로스 게스트린의 Model Equality Testing은 기준 모델과 검사할 API에서 프롬프트·응답 쌍을 수집하고, 두 출력 분포가 같은지 통계적으로 검사하는 연구다. 분포는 어떤 응답이 얼마나 자주 나오는지를 나타낸다. 같은 뜻의 문장을 한 번씩 비교하는 평가보다, 반복 생성에서 나타나는 전체 패턴에 관심을 둔다.

기준은 공개 가중치로 실행한 모델일 수도 있고, 예전에 같은 API에서 저장한 응답일 수도 있다. 공개 가중치를 기준으로 잡으면 원본 구현과 서비스의 차이를 묻는다. 과거 API 응답을 기준으로 잡으면 같은 서비스가 시간에 따라 달라졌는지를 묻는다. 어느 기준을 택했는지에 따라 검정이 답하는 질문도 바뀐다.

차이가 검출돼도 원인은 하나로 정해지지 않는다. 양자화, 미세조정, 워터마킹, 추론 구현과 생성 설정 등이 출력에 영향을 줄 수 있다. 모델에게 자기 이름을 묻거나 응답 문체만 보고 그중 하나를 지목하는 대신, 기준과 달라진 출력이 실제로 관찰되는지를 먼저 검사하는 방식이다.

입력 자료에는 질문 번호와 그 질문의 응답이 함께 들어간다

연구진의 공개 패키지가 받는 것은 API 주소 두 개가 아니라 이미 수집한 응답 자료다. README 예제는 두 종류의 프롬프트를 0과 1이라는 번호로 나타낸다. 첫 묶음의 질문 번호가 [0, 1, 0]이면 응답 배열의 첫째·셋째 항목은 질문 0의 응답이고, 둘째 항목은 질문 1의 응답이다.

예를 들어 코드 생성 업무에 적용할 자료 모양은 다음처럼 만들 수 있다. 아래 정렬·중복 제거 질문은 구조를 보여 주기 위한 예시이며, 논문에서 실제 수집한 응답이나 실행 결과는 아니다.

두 배열의 같은 행을 무조건 일대일로 비교하는 자료가 아니다. 각 응답이 어느 질문에서 나왔는지를 ID로 보존한다. 패키지의 CompletionSample에 들어가는 m=2도 전체 응답 수가 아니라 가능한 프롬프트의 종류가 두 개라는 뜻이다. 이 세 응답짜리 구조 예시를 통계 판단에 충분한 최소 표본으로 사용해서는 안 된다.

실제 수집에서는 두 API에 같은 질문 분포와 생성 설정을 적용한다. 정렬 질문과 중복 제거 질문을 뽑는 비율이 한쪽에서만 달라지면 응답 차이에 업무 구성의 차이까지 섞인다. 한쪽에만 시스템 지시, 대화 이력, 검색한 문서가 더해진 경우도 비교 조건이 달라진다. API 이전 전후를 비교한다면 질문 본문과 이런 설정을 응답과 함께 보관해야 어떤 변경을 검사했는지 남는다.

README는 응답 문자열을 Unicode 코드 포인트로 바꾸고 두 묶음을 같은 최대 길이에 맞춘 뒤 검정 객체를 만드는 예를 제공한다. 문자로 비교하면 서로 다른 토크나이저가 매긴 번호를 같은 단어처럼 취급하는 문제를 피할 수 있다. 대신 자를 길이와 패딩을 양쪽에 동일하게 적용해야 하며, 짧게 잘라 버린 뒤쪽의 차이는 그 검사에서 볼 수 없다.

p값은 모델의 정체나 품질 점수가 아니다

검정은 응답 사이의 차이를 MMD라는 통계량으로 요약한다. 논문의 Hamming 커널은 같은 위치의 토큰 또는 문자를 비교하는 특징을 사용한다. 정답을 맞혔는지 채점하는 함수가 아니므로, 표현과 출력 형식의 변화도 검정에 영향을 줄 수 있다.

패키지의 run_two_sample_test는 p값과 검정 통계량을 반환한다. README가 사용하는 순열 방식은 수집한 두 묶음을 합친 뒤 기준·비교 표지를 여러 번 섞어서, 두 분포가 같을 때 통계량이 얼마나 달라질 수 있는지를 추정한다. 실제로 관측한 통계량 이상이 얼마나 자주 나오는지가 p값 계산에 쓰인다. 논문 부록 A.2에 이 절차가 제시돼 있다.

설명을 위해 유의수준을 0.05로 정했고 p값이 0.02가 나왔다고 가정하면, 그 검사에서는 같은 분포라는 가설을 기각한다. 이는 “같은 모델일 확률이 2%” 또는 “성능이 98% 나빠졌다”는 뜻이 아니다. 비교한 프롬프트와 수집 조건에서 관찰된 차이가 동일 분포 가정 아래 얼마나 드문지에 대한 결과다.

p값이 기준보다 크면 이번 자료로 차이를 검출하지 못한 것이다. 응답이 적으면 드물게 나타나는 변화를 표본에 담지 못할 수 있다. Hamming MMD의 특징으로 구별되지 않는 분포 차이도 있어, 표본을 늘리는 것만으로 모든 종류의 변화를 찾을 수 있는 것은 아니다. 이 두 한계 때문에 미검출 결과와 실제 과제의 성공 여부를 함께 살핀다.

‘평균 10개’는 프롬프트 하나당 표본 수다

ICLR 2025 발표 자료의 77.4%는 양자화·워터마킹 등 여러 변형에 대한 검출력 중앙값이다. 25개 프롬프트로 정의한 언어모델링 과제에서 프롬프트당 평균 10개의 표본을 사용하는 조건이다. 총 10번 호출만으로 숨은 모델을 77.4% 정확도로 식별했다는 결과가 아니다.

논문 §4.1의 이 조건에서 표본 수 N은 각 분포에서 250개다. 기준과 비교 양쪽의 자료가 필요하므로, 응답을 아무것도 저장해 두지 않았다면 기준 자료를 모으는 일도 생긴다. 프롬프트당 평균이라는 말은 모든 질문을 정확히 열 번씩 호출했다는 고정된 수집 절차와도 다르다.

검출력은 실제 차이가 있는 조건에서 검정이 그 차이를 찾아내는 비율이다. 이 실험은 여러 모델·프롬프트 분포·변형을 대상으로 검정을 반복해 추정했다. 새로운 고객 응대나 한국어 요약 업무에서도 같은 비율이 나온다는 보장은 아니다. 논문에서도 fp32와 fp16 사이의 변화를 잡는 검출력은 일부 다른 변형보다 낮았고, 토큰 대신 문자 공간에서 비교하면 양자화·워터마킹 검출이 더 어려워졌다.

31개 엔드포인트 감사에는 두 기준 모델이 쓰였다

이 연구는 2024년 10월 처음 공개돼 2025년 4월 수정된 논문이다. 실제 상용 API 감사는 2024년 여름의 9개 공급자, Llama 네 모델을 제공한 31개 엔드포인트를 대상으로 했다. 그중 11개에서 기준과 다른 출력 분포를 발견했다는 것이 대표 결과다.

이 감사는 원본 fp32 구현 하나만을 정답으로 두지 않았다. fp32 또는 fp16의 출력 분포와 같을 수 있다는 가설을 두고 각각 비교했다. 둘 중 하나와만 다르다고 충분한 것이 아니라 두 기준 모두와 차이가 있어야 기각하는 구조다. 서비스가 널리 쓰이는 정밀도 중 하나를 사용한다는 이유만으로 탈락시키지 않기 위한 비교다.

과제에는 Wikipedia 이어쓰기와, 작은 모델을 대상으로 한 HumanEval 코드 생성·UltraChat 지시 응답이 포함됐다. 각 과제의 반복 검사와 과제들을 합칠 때의 다중 비교 보정도 사용했다. 따라서 README의 단일 두 표본 예제에서 p값 하나를 얻는 것과 논문의 31개 엔드포인트 감사 전체를 재현하는 것은 같은 작업이 아니다.

11개는 업체 수가 아니라 엔드포인트 수다. 출력 분포의 차이를 검출했을 뿐 각 서비스가 어떤 내부 변경을 했는지 모두 확정한 결과도 아니다. API 이전을 검토하는 오늘의 구매자가 얻을 것은 2024년 업체 순위가 아니라, 기준·과제·설정을 명시하고 반복 응답을 비교하는 방법이다.

서로 다르게 틀리면 분포는 달라도 정답률은 비슷하다

논문이 제공하는 가장 실용적인 사례는 코드 생성에서 나온다. 연구진은 HumanEval 과제의 정확도 차이와 Hamming MMD를 비교했고, 분포 차이가 커도 정확도 차이는 작은 경우를 발견했다. 두 쪽 모두 정확도가 10% 미만인 비교들이 여기에 포함됐다.

§5의 구체적인 예는 당시 Perplexity가 제공한 Llama-3.1 8B와 nf4 정밀도 버전이다. 전자는 잘못된 코드 조각을 내고, 후자는 의미 없는 문자열을 반복하는 식으로 실패했다. 출력은 크게 다르지만 둘 다 코드 문제를 풀지 못하는 경우가 많아 정확도 차이는 작았다. 서로 다른 방식으로 틀리는 두 출력을 분포 검정은 구별할 수 있지만, 그 사실 자체가 더 나은 API를 골라 주지는 않는다.

HumanEval의 평가 방식은 생성한 코드를 과제의 테스트로 실행해 기능적 정답 여부를 검사한다. 문장이 자연스러운지보다 함수가 요구한 결과를 내는지를 보는 것이다. 이 오래된 벤치마크의 점수를 그대로 현재 업무 전체의 성능으로 옮기기보다, 자기 코드 작업에도 같은 요구사항과 테스트를 양쪽에 적용하는 방식이 필요하다.

코드 생성 API를 바꿀 때 남길 결과

예를 들어 “정수 목록을 오름차순으로 반환하되 입력 목록은 바꾸지 않는 함수”를 만드는 작업이라면, 함수 요구사항과 테스트를 먼저 고정할 수 있다. 아래는 이 평가 방식을 업무에 적용한 예시이며 논문의 실험 결과가 아니다.

두 API에 같은 요청과 설정을 사용하고 반복 응답을 보관한다. 각 응답에 같은 테스트를 적용해 성공 여부와 실패한 조건을 기록한다. 문장 설명이나 변수 이름은 달라도 모든 조건을 충족할 수 있고, 겉보기 코드가 비슷해도 한쪽이 원래 목록을 바꿔 버릴 수 있다. 이 차이는 문자열 분포만으로 판단할 수 없는 업무 요구사항이다.

결과에는 분포 검정의 표본 수·p값과 함께 과제별 성공 수·전체 응답 수, 실제 실패 사례를 남긴다. 양쪽을 다른 테스트로 채점하거나 성공한 응답만 골라 비교하면 API의 선택 근거가 달라진다. 코드 실행을 동반하는 평가는 운영 데이터와 분리된 기존 평가 환경에서 수행하고, 실행 실패 기록을 답변의 기능 오류와 함께 추적한다.

응답이 많아지면 Google LLM Comparator처럼 나란히 비교한 결과를 과제별로 나누고 개별 응답으로 내려가는 도구가 도움이 된다. 전체 평균이 비슷해도 빈 입력이나 중복 처리에서 한쪽 실패가 몰리는지 찾아볼 수 있다. Comparator는 이런 비교 결과의 분석을 돕는 도구이며, 동일성 검정이나 코드 테스트를 자동으로 대신하는 것은 아니다.

분포 변화가 검출되고 요구사항 실패도 늘었다면 이전을 보류할 구체적인 실패가 생긴다. 분포만 달라지고 같은 과제를 계속 충족한다면, 그 검정 결과만으로 품질 하락을 선언할 수 없다. 반대로 분포 차이를 검출하지 못해도 중요한 테스트가 실패했다면 해당 실패를 해결하기 전에는 그 업무에 사용할 근거가 부족하다.