AI 협업 개발

LLM 출력 분산: 단일 타겟 재시도가 효과적일 때

동일한 입력에 대해 LLM 출력의 45%가 변경되었습니다. 이러한 편차를 재시도 예산을 소모하지 않고 품질을 복구하는 원샷 재시도로 전환하는 방법을 소개합니다.

이 글은 영어 원문을 AI 모델이 번역한 것입니다. 표현이 원문과 다를 수 있습니다. 영어 원문 보기

이미 유효한 답변을 반환한 LLM 호출을 재시도하는 것은 낭비처럼 들립니다. 대부분의 경우 실제로 그렇습니다. 하지만 저희는 프로덕션 번역 파이프라인에서 생각을 바꾸게 만드는 한 가지를 측정했습니다. 동일한 모델, 동일한 프롬프트, 동일한 입력으로 55개의 승인된 출력을 다시 생성했을 때 그중 25개가 다르게 나왔습니다. 이는 이미 확정된 것으로 보이는 답변에 대한 45%의 변동률입니다. 이 글은 그 변동성이 자원이 되는 특수한 경우, 즉 실제 품질을 회복하는 일회성 조건부 재시도와, 이를 활성화하기 전에 반드시 고려하여 설계해야 하는 두 가지 실패 모드(결과 덮어쓰기 및 예산 소진)에 관한 것입니다.

측정 결과: 동일한 입력에 대해 출력의 45%가 변경됨

해당 파이프라인은 다국어 용어집을 채우는 역할을 합니다. 배치 생성기가 두 LLM에 의료 미용 용어의 번역을 요청하고, 합의 단계에서 이를 비교하며, 역번역 검사를 통해 의미를 확인합니다. 모든 게이트를 통과한 출력은 확정된 항목으로 저장됩니다.

감사 중에 확정된 55개의 중국어 항목을 삭제하고 완전히 동일한 생성을 다시 실행했습니다. 프롬프트 변경, 모델 변경, temperature 변경은 없었습니다. 두 번째 실행은 첫 번째 실행과 30개 항목에서만 일치했습니다. 나머지 25개는 다른 표면 형태로 나왔습니다.

그 차이는 무작위 노이즈가 아니었습니다. 세 그룹으로 나뉘었습니다.

  • 서식 변화: 정규화기라면 동일하게 처리할 capitalization, 공백, 동의어 수준의 교체.
  • 실제 개선: 첫 번째 실행에서 영어 브랜드 이름을 그대로 둔 반면, 두 번째 실행에서는 장치에 대해 현지 시장에서 통용되는 이름을 생성했습니다.
  • 실제 퇴보: 두 번째 실행에서는 올바른 현지 이름을 버리고 영어 브랜드 이름으로 되돌아갔습니다.

두 번째와 세 번째 그룹이 흥미로운 그룹입니다. 이들은 서로 반대 방향을 가리키는 동일한 현상입니다. 모델은 롱테일 브랜드 용어에 대한 현지 시장 이름을 안정적으로 알지 못합니다. 양쪽에 유의미한 확률로, 때로는 그 이름을 생성하고 때로는 생성하지 않습니다. 해당 분포에서 추출한 단일 샘플은 모델의 최상의 답변이 아닙니다. 그것은 단지 하나의 추출일 뿐입니다.

생성을 분포로부터의 추출로 보게 되면, 재시도에 대한 질문의 형태가 바뀝니다. 질문은 더 이상 "모델을 신뢰해야 하는가"가 아니라 "어떤 출력에 대해 두 번째 추출이 첫 번째를 능가할 가능성이 있으며, 이를 어떻게 저렴하게 인식할 수 있는가?"가 됩니다.

확인할 수 있는 속성 위반 시에만 재시도

모든 것을 재시도하는 것은 거의 이득 없이 비용을 두 배로 만듭니다. 30개의 안정적인 항목에 대해 두 번째 추첨은 동일한 것을 반환하고, 변동하는 항목에 대해서는 어떤 추첨이 더 나았는지 알 방법이 없습니다. 맹목적인 재시도는 분산을 이탈로 전환합니다.

해결책은 다음과 같은 속성을 찾는 것입니다.

  1. 다른 LLM 호출 없이 결정론적으로 확인할 수 있을 것.
  2. "두 번째 추첨이 더 나을 가능성이 높다"는 것과 강한 상관관계가 있을 것.
  3. 모든 출력에 대해 테스트하기에 충분히 저렴할 것.

우리의 경우 그 속성은 문자 체계 불일치였습니다. 중국어 용어집 항목은 일반적으로 한자(Han characters)를 포함해야 합니다. 중국의 미용 시장은 수입 브랜드 기기에도 현지 이름을 만들기 때문에, 라틴 문자로만 된(Latin-only) 문자열을 가진 중국어 슬롯은 보통 "모델이 이번 추첨에서 현지 이름을 검색하지 못했다"가 아니라 "현지 이름이 존재하지 않는다"는 것을 의미합니다. 순수 함수로 이를 테스트할 수 있습니다. 즉, 코드 포인트를 반복하고 한자와 라틴 문자의 수를 세는 것이며, 네트워크는 관여하지 않습니다.

그래서 재시도 게이트는 다음과 같이 되었습니다. 전체 검증 체인을 통과한 후, 중국어 슬롯에 대해 수락된 출력이 라틴 문자로만 되어 있다면, 해당 슬롯 하나를 한 번 다시 생성하되, "기존에 확립된 현지 시장의 한자 이름이 있다면 그것을 선호하고, 없는 브랜드의 경우 원래 이름을 유지하세요."라는 지침 하나를 추가합니다.

여기서 두 가지 세부 사항이 중요합니다. 첫째, 재시도는 원래 시도와 동일한 생성, 합의, 검증 파이프라인을 재사용합니다. 검증을 건너뛰는 재시도는 재시도가 아니라 우회입니다. 둘째, 추가된 지침은 기본 프롬프트를 대체하는 것이 아니라 그 뒤에 추가되므로, 재시도는 첫 번째 추첨과 정확히 한 가지 면에서만 다릅니다. 델타(차이)의 원인을 파악할 수 있기를 원하기 때문입니다.

실제 데이터에 대한 결과는 다음과 같습니다. 처음에는 가공되지 않은 영어 브랜드 이름으로 반환되었던 필러 브랜드 슬롯이 재시도 시 올바른 한자 시장 이름으로 반환되었습니다. 재시도 후에도 라틴 문자로 남은 슬롯들은 압도적으로 기존 현지 이름이 없는 소규모 브랜드들이었는데, 이는 바로 남겨두고 싶었던 집단입니다. 실행 후, 새로 채워진 중국어 슬롯의 약 11%가 라틴 문자로만 남았으며, 이들은 조용히 통과하는 대신 검토 플래그를 갖게 됩니다.

통과한 결과를 실패로 덮어쓰지 마세요

모든 재시도 설계의 첫 번째 실패 모드는 덮어쓰기(clobbering)입니다. 원래 출력은 모든 게이트를 통과했습니다. 재시도는 통과하지 못할 수 있습니다. 재시도 결과를 무조건적으로 쓰면 통과한 항목이 거부로 대체될 수 있으며, 채워졌던 슬롯이 비게 됩니다. 그것은 재시도하지 않는 것보다 확실히 더 나쁩니다.

우리가 결국 맺게 된 계약:

snapshot = copy(result)          // everything the pipeline may mutate
reset(result)                    // back to undecided state
regenerate with reinforced prompt
run consensus + verification     // same gates as the original
adopt only if:
    verdict == pass
    AND output now satisfies the property (contains Han)
    AND output does not collide with an existing confirmed entry
otherwise:
    restore(snapshot)            // the passing original wins

각 조건은 그만한 이유가 있습니다. pass 확인은 유효성 검사 권한을 원래 있어야 할 곳에 유지합니다. property 확인은 라틴 문자를 다시 반환한 재시도를 거부합니다. 이를 채택하면 아무것도 해결하지 못한 채 예산을 소모하기 때문입니다. 새로운 한자(Han) 이름이 다른 개념의 확정된 번역과 중복될 수 있으므로 collision 확인은 중요합니다. 이를 채택하면 나중에 파이프라인의 중복 게이트에 걸려 전체 슬롯을 다운시키게 됩니다. 채택 전에 확인하면 충돌하는 재시도는 유효한 항목을 파괴하는 대신 조용히 원본을 복원합니다.

스냅샷은 출력 텍스트뿐만 아니라 파이프라인이 변경하는 모든 필드를 포함해야 합니다. 우리의 스냅샷은 판정(verdict), 역번역(back-translation), 유사도 거리(similarity distance)를 포함한 7개의 필드를 가집니다. 하나라도 누락되면 복원된 항목은 두 실행의 키메라(chimera)가 됩니다.

유효한 출력 속성 확인 (순수 함수) 재시도 1회 (동일 게이트) 원본 유지 재시도 채택 위반 유지 확실히 더 나음 복원

숨겨진 비용: 재시도 예산과 영구적 소진

두 번째 실패 모드는 더 미묘하며 첫 구현에서 거의 출시될 뻔했습니다. 배치 파이프라인은 보통 슬롯당 시도 횟수에 상한을 둡니다. 저희 시스템은 세 번을 허용합니다. 즉, 세 번의 판정이 실패하면 해당 슬롯은 모집단에서 영구적으로 제외되어, 잘못된 입력이 매일 밤 LLM 비용을 소모하는 것을 방지합니다.

시도 횟수 카운터는 감사 로그(audit-log) 행에서 파생됩니다. 저희의 첫 설계에서는 재시도를 별도의 행으로 기록했는데, 이는 매일 밤 한 번의 추가 시도로 읽힙니다. 매일 밤 재시도되는 슬롯은 이틀 만에 세 번의 시도 상한에 도달하여 채우기 모집단에서 영원히 제외될 것입니다. 더 많은 슬롯을 채우기 위한 기능이 조용히 슬롯을 삭제하고 있었을 것입니다.

해결책은 재시도가 예산에 보이지 않게 만드는 것이었습니다. 재시도는 별도의 감사 행을 작성하지 않습니다. 대신, 마지막 행의 요약 필드에 마커를 추가하고 원래 출력을 함께 기록합니다. 이 하나의 마커는 두 가지 역할을 합니다.

  • 예산 중립성: 시도 횟수 계산에서는 이전과 동일하게 매일 밤 하나의 행만 보게 됩니다.
  • 일회성 강제: 재시도하기 전에 파이프라인은 해당 슬롯의 최신 행을 읽습니다. 마커가 있다는 것은 이 슬롯이 현재 판정 주기에서 이미 재시도되었음을 의미하므로 건너뜁니다.

저희는 일회성 규칙의 범위를 영구적이 아닌 판정 주기로 한정했습니다. 만약 나중에 검토자가 항목을 거부하여 슬롯이 모집단에 다시 진입하면, 새로운 시도 횟수와 함께 새로운 재시도 기회를 얻게 됩니다. 영구적인 일회성 규칙은 몇 년 전에 판정받은 슬롯이 다시는 혜택을 볼 수 없다는 의미이며, 이는 누구에게도 도움이 되지 않습니다.

이 섹션에서 한 가지를 기억해야 한다면 이것입니다. 배치 시스템에 재시도를 추가하기 전에, 시도 횟수나 비용 회계를 사용하는 모든 소비자를 찾아내어 각각에게 여러분의 재시도가 어떻게 보이는지 확인하십시오. 재시도는 예산, 중복 제거 확인, 소진 조건, 모니터링과 상호작용합니다. 이러한 소비자 중 누구도 여러분이 명시적으로 그렇게 만들지 않는 한, 추가 호출이 '단순한 재시도'였다는 사실을 알지 못합니다.

이 패턴이 적용되는 경우와 적용되지 않는 경우

이 패턴은 저렴하고 결정적인 속성 검사를 사용하는 모든 생성 작업으로 일반화됩니다.

  • 파싱해야 하는 구조화된 출력(JSON 스키마, 날짜 형식): 파싱 실패가 속성입니다.
  • 대상 스크립트로 작성되어야 하는 번역: 여기서처럼 문자 체계 검사가 속성입니다.
  • 컴파일되어야 하는 코드 생성: 컴파일러가 속성 검사입니다.
  • 제약이 있는 재작성(길이 제한, 금지어): 스캐너가 속성 검사입니다.

결정적인 테스트 없이 품질이 정도의 문제일 때는 적용되지 않습니다. 순수 함수로 "위반 여부"를 결정할 수 없다면, 비용이 다른 별개의 도구인 LLM이 LLM을 판단하는 방식으로 돌아가게 됩니다. 또한 분산이 낮을 때도 그 가치를 잃습니다. 저희는 롱테일 용어에서 45%를 보았지만, 잘 알려진 용어에서는 동일한 파이프라인이 거의 결정적이어서 거기서의 재시도는 순전한 낭비입니다. 재시도를 통해 새로운 것을 찾을 수 있다고 가정하기 전에, 삭제 후 재생성된 샘플에서 분산을 측정하십시오.

한 가지 더 솔직한 한계는 한 번의 재시도가 분포를 두 번 샘플링한다는 것입니다. 저희의 워크로드에서는 속성 검사가 어떤 슬롯이 두 번째 추첨을 할 가치가 있는지 정확히 알려주었기 때문에, 복구 가능한 대부분의 사례를 복구할 수 있었습니다. 만약 복구 가능한 집합에 다섯 번의 추첨이 필요하다면 경제성이 달라지며, 더 열심히 샘플링하는 대신 프롬프트를 수정해야 할 것입니다.

FAQ

재시도 시 temperature를 높이거나 다른 모델을 사용하지 않는 이유는 무엇인가요? 한 번에 두 개의 변수를 변경하면 결과를 특정 요인에 귀속시킬 수 없습니다. 저희의 재시도는 알려진 실패를 대상으로 하는 추가된 지침이라는 단 한 가지만을 변경하므로, 개선이 이루어졌을 때 그 원인을 파악하고 유지할 수 있습니다. 모델을 교체하면 재시도 결과물이 원본과 동일한 검증을 거친다는 보장이 깨집니다.

속성이 유지될 때까지 재시도하지 않고 한 번만 재시도하는 이유는 무엇인가요? "확립된 현지 이름이 없음"은 합당한 최종 상태이기 때문입니다. 인지도가 낮은 브랜드의 경우 정답은 라틴어 이름이며, 루프는 영원히 반복되거나 "한 번 시도 후 검토 플래그 지정"보다 추론하기 더 어려운 별도의 중지 조건이 필요하게 됩니다.

LLM에서 45%의 편차는 정상적인가요? 이는 해당 작업이 모델 지식의 경계에 얼마나 가까운지에 따라 크게 달라집니다. 잘 알려진 용어들은 여러 실행에서 안정적이었으며, 편차는 모델이 정말로 불확실한 롱테일 항목에 집중되었습니다. 이러한 집중 현상이야말로 타겟 재시도가 효과적인 이유입니다. 속성 확인을 통해 불확실한 부분을 찾아내기 때문입니다.

이것이 사람의 검토를 대체하나요? 아니요. 검토 대기열을 줄여줍니다. 재시도 후에도 위반 상태로 남아있는 결과물에는 플래그가 지정되며, 이 플래그에는 원본 결과물이 포함되어 있어 검토자가 두 가지 결과물을 모두 볼 수 있습니다. 이 패턴은 "모든 것을 검토"하는 데서 "기계가 한 번의 추가 시도로 수정하지 못한 것을 검토"하는 것으로 작업의 초점을 이동시킵니다.

관련 글