이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- temperature와 sampling은 모델 출력에 어떤 영향을 주는가?
- 업무 자동화에서는 왜 일관성이 창의성보다 중요할 때가 많은가?
- 같은 입력에 같은 답을 기대해야 하는 기능은 어떻게 설계해야 하는가?
개요
LLM 출력은 확률적이다. 모델은 다음 token 후보의 확률 분포에서 출력을 선택한다. temperature와 top-p 같은 설정은 이 선택의 다양성을 조절한다.
백엔드 개발자에게 중요한 것은 이 설정이 제품의 일관성과 테스트 가능성에 영향을 준다는 점이다.
핵심 원리
temperature가 낮으면 높은 확률의 token을 더 선호해 일관성이 높아진다. temperature가 높으면 다양한 표현이 나올 가능성이 커진다.
기능별 권장 성향:
- 분류: 낮은 temperature
- 정보 추출: 낮은 temperature
- JSON 생성: 낮은 temperature와 schema
- 고객 답변 초안: 중간 정도
- 브레인스토밍: 높은 다양성 허용
결정성의 한계
temperature를 낮게 둬도 완전한 동일 출력을 보장한다고 보면 안 된다. provider 구현, 모델 업데이트, 부동소수점 연산, tie-breaking, backend serving 최적화가 영향을 줄 수 있다.
따라서 중요한 기능은 다음을 함께 쓴다.
- structured output
- schema validation
- eval regression
- model version 기록
- prompt version 기록
- post-processing rule
코드로 이해하기
기능별 model profile에 sampling 정책을 넣는다.
model_profiles:
strict_classifier:
model: gpt-4.1-mini
temperature: 0.0
max_output_tokens: 200
creative_draft:
model: gpt-4.1
temperature: 0.7
max_output_tokens: 1200서비스 코드에는 provider model 이름보다 profile을 넘기는 편이 관리하기 쉽다.
백엔드 설계 판단
- 모델 결과가 후속 DB 변경에 쓰이면 낮은 다양성과 검증을 선택한다.
- 사용자가 직접 편집할 초안이면 어느 정도 다양성을 허용할 수 있다.
- 같은 요청의 캐시가 필요한 기능은 sampling과 prompt version을 고정한다.
- 모델 버전 변경은 sampling 설정과 무관하게 eval 대상이다.
장애 상황과 대응
증상:
- 같은 입력의 분류 결과가 흔들린다.
- JSON 필드가 가끔 빠진다.
- 답변 말투가 배포 후 바뀌었다.
- 캐시 hit가 줄고 사용자 불만이 생겼다.
대응:
- temperature와 model profile 변경을 확인한다.
- prompt version을 rollback한다.
- schema validation 실패율을 본다.
- eval dataset에서 흔들리는 case를 추가한다.
실전 팁
- 업무 자동화는 창의성보다 안정성이 중요하다.
- temperature를 낮춰도 validation을 생략하지 않는다.
- model profile 변경은 코드 변경처럼 리뷰한다.
- 답변 말투도 제품 품질이면 eval 기준에 포함한다.
위험 신호!
- 분류 기능에 높은 temperature를 쓴다.
- model profile 변경 이력이 없다.
- 같은 입력 결과가 달라져도 trace로 비교할 수 없다.
- 모델 변경 후 eval을 돌리지 않는다.
확인 질문
확인 질문
- temperature가 높은 설정은 어떤 기능에 적합한가?
- 브레인스토밍, 초안 생성, 창작처럼 다양성이 유용한 기능에 적합하다.
- 업무 자동화에서 낮은 temperature만으로 충분하지 않은 이유는 무엇인가?
- 출력 변동과 schema 실패 가능성이 남아 있으므로 validation과 eval이 필요하기 때문이다.