같은 프롬프트를 두 번 돌리면 결과가 달라지는 이유

모델에 똑같은 프롬프트를 두 번 보내면 흔히 두 가지 다른 답이 나옵니다. 같은 입력이 어김없이 같은 출력을 내는 평범한 소프트웨어에 익숙한 사람에게는 이것이 오작동처럼 느껴집니다. 하지만 아닙니다. 변동은 이 모델들이 텍스트를 생성하는 방식이 설계로 갖춘 기능이며, 대개는 유용한 일을 하고 있습니다. 다만 그것은 테스트, 신뢰성, 그리고 예측 가능하게 동작해야 하는 모든 기능에 실제 영향을 미칩니다 — 그러니 목표는 그것에 놀라는 것이 아니라, 어디서 비롯되며 필요할 때 얼마나 낮출 수 있는지를 이해하는 것입니다.

이 글은 출력이 왜 변동하는지, 어떤 노브가 그것을 제어하는지, 왜 그 노브조차 완벽한 반복성을 사 주지 못하는지, 그리고 변동과 싸우는 대신 그것을 감안해 어떻게 설계할지를 설명합니다.

생성은 일련의 선택이다

모델은 한 번에 한 토큰씩 텍스트를 만들어 냅니다. 각 단계에서 단 하나의 미리 정해진 다음 토큰을 고르지 않습니다. 대신 분포 — 가능한 여러 다음 토큰에 걸친 확률들의 집합 — 를 계산합니다. 한 토큰은 매우 확률이 높을 수 있고, 몇몇은 적당히 높으며, 긴 꼬리는 확률이 낮습니다. 그런 다음 모델은 이 분포에서 샘플링합니다. 가중 무작위 추출을 하는데, 더 확률 높은 토큰이 뽑힐 가능성이 크지만 덜 확률적인 토큰도 여전히 기회가 있습니다.

그 샘플링 단계가 변동의 뿌리입니다. 각 토큰이 고정된 선택이 아니라 한 번의 추출이기에, 두 번의 실행이 갈라질 수 있고, 단 하나의 토큰에서 갈라지는 순간 그 뒤의 모든 것은 다른 이력을 조건으로 삼으므로 출력이 완전히 가지를 칠 수 있습니다. 문장 앞쪽의 다른 단어 하나가 다른 문장으로, 그것이 다른 문단으로 이어집니다. 초반의 작은 무작위성이 후반의 큰 차이로 불어납니다.

무작위성이 결함이 아니라 기능인 이유

매 단계마다 항상 단 하나의 가장 확률 높은 토큰을 골라 매번 같은 출력을 내는 것도 기술적으로는 가능합니다. 모델은 보통 이를 기본값으로 삼지 않는데, 그럴 만한 이유가 있습니다. 항상 가장 확률 높은 길을 택하는 텍스트는 밋밋하고, 반복적이며, 묘하게 생기 없는 경향이 있습니다. 그 약간의 무작위성이야말로 모델이 표현을 다르게 하고, 덜 뻔하지만 더 나은 이어짐을 찾고, 반복 루프에 빠지지 않게 해 줍니다.

창의적이고 대화적인 작업에서는 이 변동이 바로 원하는 것입니다. 태그라인 세 개를 청하고 같은 것이 세 번 나오면 짜증날 겁니다. 무작위성은 모델이 가장 높게 점수 매긴 하나를 기계적으로 돌려주는 대신, 좋은 답들의 공간을 탐색하는 것입니다. 그러니 변동은 모델이 못 미더운 것이 아니라, 모델이 흥미로울 여지를 받은 것입니다. 문제는 오직 내 특정 작업이 그 여지를 원하느냐입니다.

그것을 제어하는 노브

무작위성의 양은 조절할 수 있으며, 가장 흔히는 흔히 *온도(temperature)*라 불리는 설정을 통합니다. 직관은 단순합니다. 온도는 모델이 상위 선택지를 얼마나 선호할지 대 베팅을 얼마나 펼칠지를 제어합니다. 낮은 온도는 분포를 가장 확률 높은 토큰 쪽으로 날카롭게 만들어, 출력을 더 집중되고 더 예측 가능하며 더 반복적으로 만듭니다. 높은 온도는 분포를 평평하게 만들어, 덜 확률적인 토큰에 더 많은 기회를 주고, 출력을 더 다양하고 더 의외이며 더 헤맬 만하게 만듭니다.

온도를 끝까지 낮추면 모델은 항상 상위 선택지를 고르는 쪽으로 강하게 기울며, 이는 실행 간 출력을 훨씬 일관되게 만듭니다. 올리면 더 많은 다양성을 부릅니다. 이 하나의 노브가 작업을 알맞은 자리에 놓게 해 줍니다. 매번 같은 구조화된 답이 필요하면 낮게, 폭과 창의성을 원하면 높게요. 변동에 대해 내가 가진 실용적 제어의 대부분이 여기에 있습니다.

낮은 온도조차 완벽히 반복되지 않는 이유

사람들을 헷갈리게 하는 미묘함이 여기 있습니다. 무작위성을 최소로 낮춰도 실행 간에 여전히 가끔 차이를 볼 수 있습니다. 샘플링 무작위성을 줄이면 변동의 가장 큰 원천은 제거되지만, 모든 원천이 반드시 제거되는 것은 아닙니다.

두 가지가 약간의 예측 불가능성을 살려 둡니다. 첫째, 두 후보 토큰이 확률에서 극도로 가까울 때, 연산의 미세한 차이가 선택을 이쪽이나 저쪽으로 기울일 수 있고, 그 갈림길에서 출력이 갈라집니다. 둘째, 큰 모델을 돌리는 시스템은 복잡하며, 연산이 스케줄되고 결합되는 방식을 통해 그 자체의 미세한 비결정성을 들여올 수 있습니다. 둘 다 보통 외부에서 제어할 수 있는 것이 아닙니다. 정직한 틀은, 무작위성을 낮추면 출력이 훨씬 더 일관되고 대개 충분히 일관되게 된다는 것입니다 — 하지만 어떤 모델 호출이든 비트 단위로 보장된 반복 함수로 다루는 것은 실수입니다. "매우 일관됨"을 계획하되, "완벽히 결정적"을 계획하지 마세요.

이것이 테스트와 신뢰성에 뜻하는 바

변동은 모델을 평가하는 방식을 바꾸며, 그것을 무시하면 잘못된 결론에 이릅니다. 프롬프트를 한 번 테스트해 잘 됐다면, 그것이 될 수 있다는 것을 알게 된 것이지 매번 될 것이다를 안 것이 아닙니다. 한 번의 좋은 실행은 가능한 실행들의 분포에서 뽑은 한 표본입니다. 동작을 제대로 이해하려면 같은 입력을 여러 번 돌리고 출력의 퍼짐을 보세요. 보이는 변동은 정보입니다. 들쭉날쭉한 답을 내는 프롬프트는 취약하고, 실행 간에 안정적인 답을 내는 프롬프트는 견고합니다.

이는 디버깅도 다시 틀 짓습니다. 어떤 기능이 가끔 오작동할 때, 원인은 마음대로 재현할 수 있는 고정된 버그가 아니라 샘플링이 가끔 택하는 낮은 확률의 가지일 수 있습니다. 그것을 결정적인 것처럼 쫓으면 답답하고, 분포의 꼬리로 인식하면 진짜 해법 — 더 명확한 프롬프트, 더 낮은 온도, 또는 나쁜 가지가 나올 때 잡아내는 가드레일 — 으로 향하게 됩니다.

변동과 싸우는 대신 변동을 위해 설계하기

성숙한 접근은 설정과 설계를 작업에 맞추는 것입니다. 일관되고 구조화된 결과가 필요한 무엇이든 — 분류, 데이터 추출, 고정 형식 — 무작위성을 낮추고, 출력을 맹목적으로 믿는 대신 그 형태를 검증하세요. 폭이 이로운 무엇이든 — 초안 작성, 브레인스토밍, 대화 — 더 많은 변동을 허용하고 다양성을 핵심으로 받아들이세요.

정확성이 중요한 곳에서는 한 번의 호출이 맞기를 기대지 마세요. 그 주위에 검사를 두세요. 출력이 요건을 충족하는지 검증하고, 충족하지 못하면 재시도하거나 대체하세요. 그리고 프롬프트가 출시할 만큼 좋은지 판단할 때는, 운 좋은 한 결과가 아니라 여러 실행으로 판단하세요. 변동은 이 매체의 속성입니다. 버티는 시스템은 그것에 놀라는 대신 그것을 염두에 두고 설계된 시스템입니다.

정리

같은 프롬프트의 두 실행이 다른 까닭은, 생성이 각 토큰을 고정된 답으로 고르는 대신 확률 분포에서 샘플링하고, 초반의 작은 차이가 불어나기 때문입니다. 그 무작위성은 의도적입니다 — 출력을 덜 밋밋하게, 창의적 작업에 더 유용하게 만들죠. 온도는 그것을 올리고 내리는 노브이지만, 가장 낮춰도 비트 단위의 완벽한 반복성은 보장되지 않습니다. 그러니 여러 실행으로 테스트하고, 일관성이 필요하면 무작위성을 낮추고, 중요한 출력은 한 번의 호출을 믿는 대신 검증하며, 변동에 맞서지 말고 변동을 위해 기능을 설계하세요. 이 동작은 없애야 할 버그가 아니라, 관리해야 할 속성입니다.