#Temperature는 창의력 스위치가 아니라 확률분포의 평활 계수다

← 전체 목차 · 이전: Prompt는 써놓고 끝나지 않는다 · 다음: 파인튜닝은 도대체 무엇을 조정하는가

프롬프트 한 글자도, 모델도 바꾼 적이 없는데 어떤 날은 답이 반듯하고 어떤 날은 산으로 간다. "Temperature = 창의력 다이얼, 0이면 엄격, 1이면 자유분방"이라는 답은 표층이다. 이 표층 답변으로는 같은 입력이 왜 양극단을 오가는지, 왜 온도를 0으로 낮춰도 여전히 틀린 답이 나오는지 설명하지 못한다.

Temperature를 스위치로 보면 "왜 낮춰도 틀리는가"를 설명할 수 없다. 계수로 봐야 설명이 열린다.

#핵심 답변: Softmax 이후, 샘플링 이전에 끼어드는 변수

• 모델은 다음 token 후보마다 확률을 계산한다(Softmax 출력).
• Temperature는 이 확률을 뽑기 직전에 다시 조정한다. 모델 파라미터도, 추론 로직도 건드리지 않는다.
• 낮추면 1등 후보의 상대적 가중치가 커지고 나머지는 눌린다. 높이면 후보 간 확률 차이가 펴진다.

logit → (÷ Temperature) → Softmax → 확률분포 → 샘플링
                ↑
      여기서만 개입한다. 그 앞(추론)도, 그 뒤(디코딩 로직)도 아니다.

#함정 1: Temperature=0 은 "완전 재현"을 보장하지 않는다

• 일부 모델은 0으로 두어도 부동소수점 연산 순서, 배치 처리 중 병렬 스케줄링 등 비결정 요인이 남아있다.
• "무작위성을 낮추는 것"과 "완전히 고정되는 것"은 다른 명제다.

온도=0 설정
   → 무작위로 느껴지는 정도는 줄어든다
   → 그러나 동일 입력 다회 실행 시 미세한 출력 차이가 여전히 발생할 수 있다
   → 캐시 키, 회귀 테스트 단언(assert)을 "완전 동일"로 설계하면 깨진다

#함정 2: 전사 공통 온도값 하나로 통일한다

같은 값을 코드 해석, 지식베이스 문답, 브레인스토밍, 카피라이팅에 그대로 복붙하면 용도별 요구가 정반대인데 하나의 값으로 누른 셈이 된다.

#함정 3: Temperature와 Top-P를 동시에 크게 흔든다

두 파라미터 모두 후보 집합에 관여하지만 역할이 다르다.

Temperature → 확률분포의 "굴곡"을 조정한다 (진폭)
Top-P       → 후보로 남길 "범위"를 자른다 (경계)

둘을 동시에 크게 바꾸면
   → 어느 쪽 때문에 결과가 바뀌었는지 귀인 불가능
   → 디버깅이 곧 도박이 된다

순서: 먼저 Temperature로 기본 무작위 정도를 정하고, 꼬리 후보를 걸러낼 필요가 있을 때만 Top-P를 얹는다. 동시에 둘 다 크게 건드리지 않는다.

#함정 4: 낮은 온도가 환각을 없애준다는 착각

Temperature는 뽑는 방식을 조정할 뿐 모델이 아는 것을 바꾸지 못한다.

온도를 최저로 내려도
  → 모델 내부 지식이 틀렸으면
  → "확정적으로, 그러나 틀리게" 답한다
  → 오히려 같은 오답이 안정적으로 재현되어 "믿을 만해 보이는 착시"까지 더한다

환각은 샘플링 문제가 아니라 지식·검증 문제다. 외부 지식베이스(RAG)와 사실 검증 계층으로만 해결된다.

#핵심 통찰

1. Temperature는 개폐 스위치가 아니라 연속 계수다 — "0=엄격, 1=자유"라는 이분법은 함정 2(업무별 일괄 적용)의 원인이다. 실제로는 0~1 사이 연속 구간에서 확률분포의 뾰족함/평탄함을 조절하는 파라미터이며, 업무 목표에 맞춰 구간을 고르는 것이 정답이다.
2. 개입 지점이 "샘플링 단계"라는 사실 하나가 나머지 세 함정을 전부 설명한다 — 추론(모델이 무엇을 아는지)과 무관하므로 환각을 못 고치고, 결정적 로직이 아니므로 재현을 100% 보장 못 하며, Top-P와 마찬가지로 후보 집합에 관여하므로 동시에 흔들면 서로의 효과가 뒤섞인다.
3. 무작위성 감소와 결정성 보장은 서로 다른 등급의 주장이다 — "온도가 낮다"는 확률적 진술이고 "결과가 같다"는 보장적 진술이다. 프로덕션에서 이 둘을 같은 것으로 취급하면 캐시 적중률 설계, 회귀 테스트 단언 방식이 전부 잘못된 전제 위에 서게 된다.
4. 파라미터가 업무 단위가 아니라 요청 단위로 흔들리면 그 자체가 장애다 — 요청마다 온도를 0과 1 사이에서 오가게 하면 출력의 스타일·포맷·논리가 동시에 요동쳐 하류 파싱과 사용자 체감이 함께 무너진다. 온도는 배포 형태로는 "설정값"이어야지 "매 호출 즉흥 값"이면 안 된다.
5. Temperature와 Top-P는 진폭과 경계라는 서로 다른 축이다 — 같은 축이 아니므로 동시에 크게 바꾸면 실험이 2차원에서 벌어지고, 결과 차이를 1차원 원인으로 되돌릴 수 없다. 조정에는 반드시 순서(먼저 진폭, 그다음 경계)가 있어야 한다.
6. "확정적"과 "정확함"은 서로 다른 축이다 — 온도를 낮추는 것은 출력의 분산을 줄이는 조작이지 모델 지식의 오류를 고치는 조작이 아니다. 오히려 확정적으로 재현되는 오답은 사람이 더 쉽게 신뢰하게 만드는 역효과까지 낸다.
7. 파라미터를 안다는 것과 파라미터의 경계를 안다는 것은 다른 능력이다 — "0~1 사이 값"이라는 사실은 누구나 안다. 구간별 배치, 협업 순서, 재현 불가 조건, 환각과의 무관함까지 말할 수 있어야 실제 운영 경험이 있다는 신호가 된다.

#엔지니어링 실전 Tips

• 온도는 값이 아니라 등급으로 관리할 것: 요청마다 정밀 소수점을 튜닝하지 말고 강확정성/중간발산/고창의 3단계로 먼저 분류하고, 단계 안에서만 미세조정한다.
• temperature=0을 캐시 키나 회귀 단언의 전제로 쓰지 말 것: 요청·응답 로그를 남기고, 회귀 테스트는 "문자열 완전 일치"가 아니라 "구조·핵심 필드 일치"로 단언할 것.
• 파라미터 변경 순서를 지킬 것: 먼저 Temperature만 바꿔 기본 무작위 정도를 확정하고, 꼬리 후보 제거가 필요할 때만 Top-P를 추가한다. 동시 변경은 원인 규명을 불가능하게 만든다.
• 환각이 보이면 온도가 아니라 지식·검증 계층을 먼저 의심할 것: 낮은 온도에서도 환각이 나온다면 RAG 검색 품질, 사실 검증기, 출력 근거 표기를 점검할 차례이지 온도를 더 내릴 차례가 아니다.
• 운영 중 큰 폭의 동적 온도 변경을 금지할 것: 요청별로 온도를 크게 오가게 하면 출력 스타일·포맷·로직이 동시에 튀어 하류 시스템까지 흔들린다. 변경은 설정 배포 + 그레이 릴리스 + 롤백 경로를 갖출 것.
• 로그에 사용된 Temperature/Top-P 값을 남길 것: 복기할 때 파라미터 문제인지 모델 문제인지를 가르는 유일한 근거다.