NL-227, Large Language Monkeys: Scaling Inference Compute with Repeated Sampling, Preprint 2024

◼ Comment

  • 사실 결론은 되게 간단함.
  • Scaling Inference라고 부르는거 같은데,, 보통 LLM이 좋고 나쁨을 비교할때 테스트입력에 대해 한번 돌려서 나온 결과를 비교한다.
  • 근데 같은 자원이라고 봤을때, 큰 모델 한번 돌리기보다 작은 모델 여러번 돌려서 나온 결과를 조합하는게 더 좋다는 것이다
  • 여기서는 데이터셋 도메인이 수학과 코드로 문제를 푸는 테스크에서 실험을 했다
  • 작은 모델로 여러번 응답을 생성해서, 자동 검증기나 오라클 검증기를 통해 응답의 정답유무를 판단하여 커버리지를 계산한다
    • 예로, 10개 응답뽑아서 10개안에 정답이 있느냐?를 본 것이다
    • 이렇게하면 1개 응답에서는 정답이 없던 경우도 10개로 확장하면 정답인 응답이 뽑힌다는 것이다
  • (실사용을 생각하면) 근데 실제 정답을 모르는 경우 10개 응답을 어떻게 조합하냐?
    • 뭐 가장 간단한 방법으론 다수결이 있을테고
    • 여기서는 오픈된 보상모델(ArmoRM-Llama3-8B-v0.1)을 가져와서 결합했다
    • 다수결과 보상모델을 활용해서 결합하니 성능이 향상되긴하는데 한계가 있다고 한다.
    • 왜냐면 10개 응답중 1개만 정답일 경우, 다수결에 의해 이 정답이 뽑힐 확률은 적을수 밖에..
    • 보상모델또한 성능 한계가 있어서 완벽히 신뢰하기도 어렵기도함
  • 어쨌든 FLOPS나 api cost을 고려했을때 작은 모델 여러번 돌리기가 나름 효과적일 수 있다는 것
  • 정답이 있거나 문제해결의 경우에는 이 방법을 고려해볼 수 있다
  • 물론 그냥 일상대화나 설명이 필요한 응답?(예. 네이버와 카카오의 차이를 알려줘) 식의 질의에 대해서는 이 방법을 적용하기는 어려워 보임
  • 이 논문에서는 같은 모델을 temperature을 통해 다양성을 확보했는데.. 
    • 이는 사실 앙상블의 개념으로 보임
    • 따라서 모델을 여러 개둬서 앙상블할 수도 있지 않을까 싶기도 하고
    • 프롬프트 엔지니어링을 통해 앙상블 할 수도 있지 않을까 싶기도 하고
    • 실용적으로는 다양하게 확장이 가능할거 같다.

Abstract

  • 언어 모델을 훈련시키기 위해 사용되는 연산량을 늘리는 것은 그 성능을 크게 향상시켰습니다. 
  • 하지만 추론 과정에서는 문제를 풀기 위한 연산량을 단 한 번의 시도로 제한하는 경우가 많습니다. 
  • 여기서는 생성된 샘플 수를 늘림으로써 추론에 사용되는 연산량을 확장하는 방법을 탐구합니다. 
  • 여러 작업과 모델에서 우리는 네 가지 자릿수에 걸쳐 샘플 수가 증가할수록 문제를 해결하는 시도의 비율(커버리지)이 증가한다는 것을 관찰했습니다. 
  • 코딩이나 형식 증명과 같은 모든 답변을 자동으로 검증할 수 있는 도메인에서는 이러한 커버리지 증가가 성능 향상으로 직접 이어집니다.
  • 예를 들어, 반복 샘플링을 SWE-bench Lite에 적용한 결과, DeepSeek-Coder-V2-Instruct 모델이 1개의 샘플로 15.9%의 문제를 해결하는 데서 250개의 샘플로 56%를 해결하는 성과를 보였으며, 더 강력한 최신 모델을 사용한 단일 시도의 최고 성능인 43%를 능가했습니다. 
  • 또한 현재 API 가격을 기준으로 보면, 더 저렴한 DeepSeek 모델을 5개의 샘플로 증폭하는 것이 GPT-4o나 Claude 3.5 Sonnet에서 1개의 샘플을 사용하는 것보다 더 비용 효율적이며 더 많은 문제를 해결할 수 있습니다. 
  • 흥미롭게도, 커버리지와 샘플 수 간의 관계는 종종 로그 선형이며 지수적으로 확장되는 추론 시간 스케일링 법칙이 존재할 가능성을 시사합니다. 
  • 마지막으로, 자동 검증기가 없는 도메인에서는 여러 샘플 중에서 올바른 답을 식별하는 것이 중요한 연구 방향으로 남아 있음을 확인했습니다. 
  • GSM8K와 MATH의 수학 문제를 해결할 때, Llama-3 모델의 커버리지는 10,000개의 샘플로 95% 이상까지 증가했으나, 샘플 모음에서 올바른 답을 고르는 일반적인 방법(다수결 투표 또는 보상 모델)은 몇 백 개의 샘플을 넘어서는 시점에서 성능이 정체되며 샘플 예산과 함께 충분히 확장되지 못하는 모습을 보였습니다.

1 Introduction

  • 대형 언어 모델(LLMs)의 코딩, 수학, 기타 추론 작업 해결 능력은 지난 몇 년 동안 크게 향상되었습니다 [46, 11]. 
  • 모델 훈련을 확장하는 것이 이러한 성과의 지속적인 원동력이 되었습니다. 
  • 더 큰 모델, 더 큰 사전 훈련 데이터셋, 그리고 인간 선호도 레이블 수집을 통한 더욱 광범위한 후속 훈련에 대한 투자가 매우 유능한 범용 시스템을 개발하는 데 기여했습니다 [2, 3, 4, 51].
  • 반면, 추론에 사용되는 연산량을 확장하는 데는 상대적으로 제한된 투자가 이루어졌습니다. 
  • 더 큰 모델은 작은 모델보다 더 많은 추론 연산을 필요로 하며, chain-of-thought와 같은 프롬프트 기법은 더 긴(따라서 계산 비용이 더 많이 드는) 출력으로 답변의 품질을 향상시킬 수 있습니다 [61]. 
  • 그러나 LLM과 상호작용할 때, 사용자와 개발자는 문제를 해결할 때 모델이 단 한 번만 시도하도록 제한하는 경우가 많습니다. 
  • 이 연구에서는 반복 샘플링을 대안적 축으로 제안하여 추론 연산을 확장하고 LLM의 추론 성능을 개선하는 방법을 탐구합니다.
  • 반복 샘플링의 효과는 두 가지 핵심 속성에 의해 결정됩니다:
    • 1. 커버리지(Coverage): 
      • 샘플 수가 증가함에 따라 생성된 샘플 중 하나를 사용하여 해결할 수 있는 문제의 비율은 얼마나 되는가?
    • 2. 정확도(Precision): 
      • 생성된 샘플 모음에서 최종 답을 선택해야 하는 상황에서, 올바른 샘플을 식별할 수 있는가?
    • 다양하게 응답을 많이 생성하여 질문에 해결하는 응답을 찾아내는 방식? 어떻게 정답이라고 판단할것인가.. 이러면 얼마나 못해결하던걸 해결하는가.. 을 확인하는 듯
    • 전에 내가 쓴 논문 paraphrasing가 나름 비슷한 결인거 같긴 한데..
  • 무제한 시도로 모델이 모든 시퀀스에 0초과의 확률을 할당한다면, 완벽한 커버리지를 달성할 수 있습니다. 
    • 그러나 반복 샘플링은 제한된 예산 내에서 커버리지를 개선할 수 있을 때에만 실용적입니다. 
    • 또한 샘플들 간의 선택 능력이 없다면, 반복 샘플링의 응용은 제한적입니다. 
    • 기존 연구들은 이러한 두 방향에서 고무적인 증거를 제공하며, 수학, 코딩, 퍼즐 해결 등의 분야에서 반복 샘플링이 성능을 향상시킨 사례를 보여줍니다 [60, 47, 23]. 
    • 특히, 최첨단 시스템인 AlphaCode [40]는 경쟁 프로그래밍에서 문제당 백만 개의 샘플을 사용함으로써 성능이 계속 향상된다는 사실을 발견했습니다.
    • 백만개 응답을 생성한다는것인가??
  • 이번 연구에서는 다양한 작업, 모델, 샘플 예산에 걸쳐 커버리지를 개선하는 데 있어 반복 샘플링이 효과적인 방법론임을 입증합니다. 
    • 예를 들어, Gemma-2B [52]를 사용해 CodeContests [40] 프로그래밍 문제를 해결할 때, 한 번의 시도로는 0.02%의 커버리지를 보였으나 10,000번의 시도로 커버리지를 7.1%로 300배 이상 증가시켰습니다. 
    • 흥미롭게도 log(커버리지)와 샘플 수 간의 관계는 종종 대략적인 멱법칙을 따릅니다. (3.1에서 나옴)
    • Llama-3 [3]와 Gemma 모델을 사용할 때, 여러 자릿수에 걸쳐 샘플 수가 증가함에 따라 커버리지가 거의 로그 선형적으로 증가하는 것을 관찰했습니다.
  • 모델의 모든 솔루션을 증명 검사기나 유닛 테스트와 같이 자동으로 검증할 수 있는 환경에서는 이러한 커버리지 증가는 직접적인 성능 향상으로 이어집니다. 
  • 반복 샘플링을 경쟁 프로그래밍이나 Lean 증명 작성에 적용할 때, Llama-3-8B-Instruct와 같은 모델은 GPT-4o [2]와 같은 훨씬 더 강력한 모델의 단일 시도 성능을 능가할 수 있습니다. (신기한데?, 앙상블 느낌)
  • 이처럼 약한 모델을 증폭시키는 능력은 실제 GitHub 이슈를 다루는 SWE-bench Lite 데이터셋에서도 적용되며, 여기서 현재 단일 시도 최고 성능은 GPT-4o와 Claude 3.5 Sonnet 모델의 혼합으로 달성한 43%입니다 [1]. 
  • DeepSeek-Coder-V2-Instruct [20]는 단일 시도로 이 벤치마크에서 15.9%를 달성하지만, 시도 횟수를 250으로 늘리면 해결된 문제의 비율이 56%로 증가하여 단일 시도 최고 성능을 13% 능가합니다. (신기한듯, 작은모델 여러번 돌리는게 더 효과적일지도. 물론 여러개 응답에서 어떻게 정답을 골라내는건 다른문제?)
  • 모델 품질을 향상시키는 것 외에도, 반복 샘플링은 대형 언어 모델(LLM)의 추론 비용을 최소화할 수 있는 새로운 메커니즘을 제공합니다. 
    • 동일한 추론 FLOP(Floating Point Operations) 수를 유지하는 경우, 일부 데이터셋(MATH 등)에서는 작은 모델과 더 많은 시도를 통해 커버리지가 최대화되지만, 다른 데이터셋(CodeContests 등)에서는 더 큰 모델을 사용하는 것이 더 나은 결과를 보였습니다. (항상 작은모델 여러번 돌리는게 좋은건 아니다)
    • 또한 SWE-bench Lite 문제를 해결하는 맥락에서 DeepSeek-Coder-V2-Instruct, GPT-4o, 그리고 Claude Sonnet 3.5 간의 API 가격을 비교했습니다. 
    • 에이전트 프레임워크(Moatless Tools [67])를 일정하게 유지한 상태에서, 더 약하고 저렴한 DeepSeek 모델에서 다섯 번의 샘플링을 하는 것이 Claude나 GPT에서 한 번 시도하는 것보다 더 많은 문제를 해결하며, 비용은 3배 이상 저렴했습니다.
  • 마지막으로, 수학 문제에서 기존 도구로는 답을 자동으로 검증할 수 없는 경우, 커버리지와 최종 답을 결정하는 일반적인 방법들의 성능 사이에 큰 차이가 있음을 확인했습니다. 
    • Llama-3-8B-Instruct를 사용해 MATH [26] 문제를 해결할 때, 100개의 샘플로 79.8%의 커버리지를 보였고, 10,000개의 샘플로 95.3%까지 증가했습니다. 
    • 그러나 다수결 투표나 보상 모델을 사용하는 방법들은 낮은 샘플 예산에서 성능이 정체되었으며, 동일한 범위에서 38.7%에서 39.8%로만 증가했습니다. 
    • 이러한 결과는 신뢰할 수 있는 검증기를 구축하는 것이 여전히 해결되지 않은 문제임을 강조합니다. (역시 이 문제가 핵심일지도.. 수많은 응답중 무엇이 정답인지 검증을 어케하냐..? 커버리지는 증가하나 정확도는 어떻게?)
  • 요약하면, 우리의 주요 관찰 결과는 다음과 같습니다:
    • 1. 우리는 반복 샘플링을 통해 추론 연산을 확장함으로써 다양한 작업, 모델, 샘플 예산에서 커버리지가 크게 향상된다는 것을 입증했습니다. 이를 통해 더 많은 샘플을 사용해 약한 모델을 증폭시켜 더 강력한 모델의 단일 시도 성능을 능가할 수 있으며, 경우에 따라 비용 효율적일 수 있습니다. 특히 DeepSeek-Coder-V2-Instruct에서 250번 샘플링하여 SWE-bench Lite 문제의 56%를 해결할 수 있었으며, 이는 단일 시도로 달성된 최고 성과인 43%를 능가합니다.
    • 2. 커버리지와 샘플 수 간의 관계가 종종 지수적으로 확장되는 멱법칙으로 모델링될 수 있음을 보여주며, 이는 추론 시간 연산량에 대한 일종의 스케일링 법칙을 시사합니다.
    • 3. 자동 검증기가 없는 도메인에서는 다수결 투표나 보상 모델 점수와 같은 일반적인 검증 방법이 약 100개의 샘플 이후로는 성능이 정체된다는 것을 보여주었습니다. 이로 인해 이러한 방법으로 달성할 수 있는 성능과 커버리지 상한선 사이의 격차가 점점 커지는 현상이 발생합니다.

2 Scaling Repeated Sampling 

  • 우리는 후보 솔루션이 정답 또는 오답으로 평가될 수 있는 통과-실패(pass-fail) 작업에 중점을 둡니다. 
  • 이러한 작업에서 주요 관심 지표는 성공률(success rate)로, 이는 해결할 수 있는 문제의 비율을 나타냅니다. 
  • 반복 샘플링을 사용하는 경우, 모델이 문제를 해결하는 과정에서 여러 후보 솔루션을 생성할 수 있는 설정을 고려합니다. 
  • 따라서 성공률은 많은 문제에 대해 올바른 샘플을 생성하는 능력(즉, 커버리지)과 이러한 올바른 샘플을 식별하는 능력(즉, 정확도)에 의해 영향을 받습니다.
  • 정확도 문제의 난이도는 샘플 검증 도구의 가용성에 따라 달라집니다. 
  • Lean에서 형식적 진술을 증명할 때, 증명 검사기는 후보 솔루션이 올바른지 여부를 빠르게 확인할 수 있습니다. 
    • 유닛 테스트도 코딩 작업에 대한 후보 솔루션을 검증하는 데 사용할 수 있습니다. 
    • 이러한 경우, 정확도는 자동으로 처리되며, 커버리지를 향상시키는 것은 곧바로 성공률을 높이는 것으로 이어집니다. 
  • 반면에 GSM8K와 MATH의 수학 문제를 해결할 때는 솔루션을 검증할 수 있는 도구가 제한적이기 때문에, 여러 (종종 상충되는) 샘플 중에서 단일 최종 답을 결정해야 하는 추가적인 검증 방법이 필요합니다.
  • 즉 코드관련 테스크에서는 응답으로 생성된게 코드가 돌아가는지를 바로 판단할 수 있으니, 이런 경우는 사실 커버리지 상승이 정확도 상승으로 이뤄지는 것
  • 그런데 수학문제 같은 경우는, 응답으로 생성된게 각각 정답인지 아닌지를 모르니까.. 최종 답을 결정해야하는 방법이 필요 (가장 심플한건 과반수투표일듯)
  • 다음의 다섯 가지 작업을 고려합니다:
    • 1. GSM8K: 초등학교 수준의 수학 문제를 포함한 데이터셋입니다 [18]. GSM8K 테스트 세트에서 무작위로 선택한 128개의 문제로 평가를 진행합니다.
    • 2. MATH: GSM8K보다 난이도가 높은 수학 문제들을 포함한 또 다른 데이터셋입니다 [13]. 이 데이터셋의 테스트 세트에서 무작위로 선택한 128개의 문제로 평가를 수행합니다.
    • 3. MiniF2F-MATH: 증명 검증 언어로 형식화된 수학 문제 데이터셋입니다 [65]. 우리는 Lean4를 언어로 사용하며, MATH 데이터셋에서 형식화된 130개의 테스트 세트 문제를 평가합니다.
    • 4. CodeContests: 경쟁 프로그래밍 문제들로 구성된 데이터셋 [40]. 각 문제는 텍스트 설명과 함께 입력-출력 테스트 케이스 세트(모델에는 숨겨져 있음)를 포함하며, 이를 사용해 후보 솔루션의 정확성을 검증할 수 있습니다. 모델이 Python3을 사용하여 솔루션을 작성하도록 강제합니다.
    • 5. SWE-bench Lite: 실제 Github 이슈들로 구성된 데이터셋으로, 각 문제는 설명과 코드 저장소의 스냅샷을 포함합니다 [32]. 문제를 해결하기 위해 모델은 코드베이스의 파일을 편집해야 하며, 우리가 사용하는 SWE-bench의 Lite 하위집합에서는 단일 파일만 수정하면 됩니다. 후보 솔루션은 저장소의 유닛 테스트 스위트를 사용하여 자동으로 검증할 수 있습니다.
  • 이 작업들 중에서 MiniF2F-MATH, CodeContests, 그리고 SWE-bench Lite는 각각 Lean4 증명 검사기, 테스트 케이스, 유닛 테스트 스위트와 같은 자동 검증기를 가지고 있습니다. 
    • 자동검증기는 코드작업같이 그냥 생성된 샘플을 프로그램넣어서 정답인지 파악하는거 같음 (즉 답자체는 여러개가 가능)
    • 우리는 반복 샘플링이 모델 커버리지를 어떻게 향상시키는지 먼저 조사합니다. 
    • 자동 검증기가 있는 작업에서는 커버리지의 향상이 성공률의 증가와 직접적으로 연결되며, 일반적인 경우 커버리지는 성공률의 상한선을 제공합니다. 
    • 코딩 작업에서는 커버리지를 commonly-used pass@k 메트릭으로 정의하며, 여기서 \(k\)는 문제당 샘플의 수를 나타냅니다. 
    • 단순히 k개의 샘플에서 얼마나 정답이냐?를 보는 듯. 
    • 우리는 CodeContests와 SWE-bench Lite를 평가할 때 이 메트릭을 직접 사용합니다. 
    • MiniF2F의 경우, Lean4 증명 검사기에 의해 "pass" 여부가 결정된다는 점에서 유사한 메트릭을 사용합니다. 
  • GSM8K와 MATH에서는 커버리지가 모든 샘플 중 올바른 최종 답을 출력하는 샘플이 있는지 확인하는 오라클 검증기에 해당합니다.
    • 오라클 검증기는 생성된 샘플에서 답을 찾아내는 역할? 파싱과 같은 작업인거 같은데.. (답은 한개로 정해진거)
    • 커버리지를 계산할 때 변동성을 줄이기 위해 Chen et al. [15]의 편향되지 않은 추정 공식을 사용합니다. 
    • 각 실험에서 먼저 각 문제 인덱스 \(i\)에 대해 \(N\)개의 샘플을 생성한 후, 올바른 샘플의 수 \(C_i\)를 계산합니다. 
    • 그런 다음 각 관심 \(k \leq N\)에서 pass@k 점수를 다음과 같이 계산합니다:
    • 여기서는 검증기가 없으므로, 먼저 샘플들이 올바른지 검증하는 과정이 추가되는거 같고..
    • pass@k도 총 N개 샘플에서 k개 고를때 모두 오답만 고르는 경우를 뺀거
    • k개 샘플 고를때 한개라도 정답일 샘플이 포함되는 경우가 pass@k 인듯
    • 즉 이 값이 클수록 적은 샘플로도 문제를 맞출 가능성이 높아짐을 의미 (정확한 정답을 찾아내는 개념)
    • 우리는 Chen et al. [15]에서 제안한 수치적으로 안정된 공식 구현을 사용합니다. 
  • 데이터와 코드 https://scalingintelligence.stanford.edu/pubs/large_language_monkeys/에서 확인할 수 있습니다.

2.1 Repeated Sampling is Effective Across Tasks

  • 여기서 우리는 반복 샘플링이 여러 과제와 다양한 샘플 예산에 걸쳐 커버리지를 향상시킨다는 것을 입증합니다. 
  • Llama-3-8B-Instruct와 Llama-3-70B-Instruct를 사용해 CodeContests, MiniF2F, GSM8K, MATH 과제에서 문제당 독립적인 10,000개의 샘플을 생성합니다. 
  • SWE-bench Lite의 경우, 과제에서 요구되는 컨텍스트 길이가 Llama-3 모델의 한계를 초과하므로 DeepSeek-Coder-V2-Instruct를 사용합니다. 
    • SWE-bench 문제를 해결할 때는 모델이 코드베이스를 탐색하고 수정할 수 있는 도구를 제공하는 소프트웨어 프레임워크가 필요하며, 본 연구에서는 Moatless Tools라는 오픈 소스 라이브러리를 사용합니다. 
    • SWE-bench 문제를 해결하는 것은 LLM과 Moatless Tools 간의 다중 회전 대화가 포함된 과정을 의미합니다. 
  • 이 벤치마크에서 한 번의 샘플 또는 시도는 이러한 다중 회전 과정 전체를 나타냅니다. 
  • 비용을 최소화하기 위해 각 문제당 시도 횟수를 독립적으로 250회로 제한합니다.
  • 결과는 그림 2에 보고됩니다. 
  • 또한 각 과제에서 GPT-4o의 단일 시도 성능과 SWE-bench Lite의 단일 시도 SOTA(최고 성능) 결과인 CodeStory Aide(GPT-4o와 Claude 3.5 Sonnet을 사용한 결과)도 포함했습니다. 
  • 다섯 가지 과제 모두에서 샘플 예산이 증가함에 따라 커버리지가 점진적으로 향상된다는 것을 확인했습니다. 
  • LLM에게 단일 시도 기회만 제공되었을 때는 GPT-4o가 모든 과제에서 Llama와 DeepSeek 모델을 능가했지만, 샘플 수가 증가함에 따라 세 가지 약한 모델 모두 GPT-4o의 단일 시도 성능을 초과했습니다. 
  • SWE-bench Lite의 경우, 56%의 문제를 해결하여 단일 시도의 SOTA인 43%를 초과했습니다.

2.2 Repeated Sampling is Effective Across Model Sizes and Families

  • 2.1 절의 결과는 반복 샘플링이 커버리지를 향상시킨다는 것을 나타냅니다. 
  • 그러나 우리는 이 경향을 8B 이상의 매개변수를 가진 세 개의 최신 지침 조정 모델에 대해서만 보여주었습니다. 
  • 이제 이러한 경향이 다른 모델 크기, 계열 및 후속 훈련 수준에서도 유지된다는 것을 보여줍니다. 
  • 평가를 더 넓은 모델 세트를 포함하도록 확장합니다.
    • Llama 3: Llama-3-8B, Llama-3-8B-Instruct, Llama-3-70B-Instruct. 
    • Gemma: Gemma-2B, Gemma-7B [52].
    • Pythia: Pythia-70M through Pythia-12B (eight models in total) [9].
  • 우리는 추론 비용을 최소화하기 위해 MATH와 CodeContests 데이터셋으로 평가를 제한하고, 결과를 그림 3에 보고합니다. 
  • 테스트한 거의 모든 모델에서 커버리가 증가하며, 특히 작은 모델들이 반복 샘플링을 적용했을 때 커버리지가 급격히 증가하는 모습을 보입니다. 
  • CodeContests에서 Gemma-2B의 커버리는 0.02%의 pass@1에서 7.1%의 pass@10k로 300배 이상 증가합니다. 
  • 마찬가지로, Pythia-160M을 사용해 MATH 문제를 해결할 때, 커버리는 0.27%의 pass@1에서 57%의 pass@10k로 증가합니다.
  • 모델 간에 커버리가 증가하는 이러한 패턴의 예외는 CodeContests에서 평가된 Pythia 계열 모델입니다. 
    • 모든 Pythia 모델은 이 데이터셋에서 10,000개의 샘플 예산을 사용해도 커버리가 0을 기록했습니다. 
    • 우리는 Pythia가 Llama와 Gemma보다 코딩에 특화된 데이터로 훈련되지 않았기 때문에 이러한 결과가 나타났다고 추측합니다.

2.3 Repeated Sampling Can Help Balance Performance and Cost

  • 섹션 2.1과 2.2의 결과에서 얻을 수 있는 한 가지 중요한 점은, 반복 샘플링을 통해 더 약한 모델의 능력을 증폭시켜 더 강력한 모델의 단일 샘플보다 더 나은 성능을 발휘할 수 있다는 것입니다. 
  • 여기서 우리는 이러한 증폭이 더 강력하고 비용이 많이 드는 모델을 사용하는 것보다 더 비용 효율적일 수 있음을 보여주며, 성능과 비용을 공동으로 최적화하려는 실무자들에게 새로운 자유도를 제공합니다.
  • 먼저 FLOPs(부동소수점 연산)를 비용 척도로 고려하고, 섹션 2.1의 Llama-3 결과를 검토합니다. 
  • 우리는 Figure 2의 결과를 다시 플로팅하여, 이제 샘플 예산 대신 총 추론 FLOPs의 함수로 커버리지를 시각화합니다. 
  • Llama-3 모델은 대부분의 파라미터가 행렬 곱셈에 사용되는 밀집 변환기이므로, 우리는 추론 FLOPs를 다음 공식을 사용하여 근사합니다:
    • FLOPs per token ≈ 2 ∗ (num parameters + 2 ∗ num layers ∗ token dim ∗ context length) 
    • total inference FLOPs ≈ num prompt tokens ∗ FLOPs per token + num decoded tokens ∗ FLOPs per token ∗ num completions 
  • 우리는 Figure 4에서 MiniF2F, CodeContests, MATH, GSM8K에 대한 재조정된 결과를 제시합니다. 
  • 흥미롭게도, 커버리지를 극대화하는 모델은 계산 예산과 작업에 따라 달라집니다. 
  • MiniF2F, GSM8K 및 MATH에서는 FLOP 예산이 고정되었을 때, Llama-3-8B-Instruct 모델이 더 크고 비용이 많이 드는 70B 모델보다 항상 더 높은 커버리지를 얻습니다. 
  • 그러나 CodeContests에서는 70B 모델이 거의 항상 비용 효율성이 더 높습니다. 
  • FLOPs만을 고려하는 것은 시스템 효율성의 다른 측면을 무시하는 다소 조잡한 비용 척도일 수 있음을 주목합니다 [21]. 
  • 특히 반복 샘플링은 단일 시도 추론 작업량에 비해 시스템 처리량을 향상시키는 대형 배치 사이즈와 전문화된 최적화를 활용할 수 있습니다 [34, 6, 66]. 
  • 이에 대해서는 섹션 5에서 더 자세히 다룹니다.
  • 우리는 또한 현재 API 가격을 사용하여 SWE-bench Lite 문제를 해결할 때 반복 샘플링의 비용을 달러 기준으로 분석합니다. 
  • 에이전트 프레임워크(Moatless Tools)를 일정하게 유지하면서, Claude 3.5 Sonnet과 GPT-4o를 사용해 각 문제에 대해 단일 시도를 하는 것과 DeepSeek-Coder-V2-Instruct를 사용해 반복 샘플링을 하는 것을 고려합니다. 
  • Table 1에서 각 접근 방식의 문제당 평균 비용과 문제 해결율을 보고합니다. 
  • DeepSeek 모델은 GPT 및 Claude 모델보다 성능이 약하지만, 비용은 10배 이상 저렴합니다. 
  • 이 경우, 반복 샘플링은 성능이 뛰어난 모델에 대해 프리미엄을 지불하는 것보다 저렴한 대안을 제공하면서 더 나은 문제 해결률을 달성합니다.
  • FLOPS로 연산량을 고정하거나 같은 api 비용으로 고정하는 식으로 간단히 동일선상에서 비교하면 (물론 이 방법이 정확하게 동일비교는 아니긴하다)
    • 작은모델이 큰모델보다 반복적인 샘플리으로 오히려 더 효과적이고 저렴할 수 있다는 것
    • 테스크에 따라 모델에 따라.. 어떻게 최적화하는지에 따라 달라질게 많은 결과이긴한데 어쨌거나 repeated sampling이 꽤 괜찮은 접근법일 수도??

3 Characterizing the Benefits of Repeated Sampling 

  • LLM(대규모 언어 모델)의 손실과 학습 계산량 간의 관계는 학습 스케일링 법칙으로 잘 설명되어 왔습니다 [27, 36, 28]. 
  • 이 법칙들은 여러 차례에 걸쳐 경험적으로 입증되었으며, 학습에 대한 큰 투자가 보답을 얻을 것이라는 점에서 모델 개발자들에게 신뢰를 줍니다. 
  • 이러한 학습 스케일링 법칙에서 영감을 받아, 여기서는 커버리지와 샘플 예산(즉, 추론 계산량) 간의 관계를 더 잘 설명하려고 하며, 두 가지 흥미로운 관찰을 제시합니다:
    • 1. 커버리지와 샘플 수 간의 관계는 종종 지수화된 멱법칙으로 모델링할 수 있습니다.
    • 2. 주어진 작업에서 동일한 계열의 서로 다른 모델들의 커버리지 곡선은 유사한 기울기를 가지지만 수평으로 다른 오프셋을 가진 S-곡선을 닮았습니다.

3.1 Scaling Laws for Repeated Sampling 

  • 여기서 우리는 커버리지와 샘플 수 간의 관계에 대한 명시적 모델을 개발합니다. 
  • GPT-4 기술 보고서 [45]에서는 모델의 코딩 문제에 대한 평균 로그 통과율과 학습 계산량 간의 관계가 멱법칙으로 잘 모델링될 수 있다고 발견했습니다. 
  • 우리는 동일한 함수 유형을 채택하여, 이제 커버리지 \(c\)의 로그를 샘플 수 \(k\)의 함수로 모델링합니다:
    • 여기서 \(a, b \in R\)는 모델 파라미터입니다. 
  • 커버리지를 직접 예측하기 위해 양쪽을 지수화하여 최종 모델을 다음과 같이 도출합니다:
    • 샘플수 k가 증가할수록 커버리지 c가 증가함
  • Figure 5에서 맞춰진 커버리지 곡선의 예를 제공하며, 추가적인 곡선은 부록 C.2에서 확인할 수 있습니다. 
  • 이러한 법칙들은 학습 스케일링 법칙만큼 정확하지는 않지만(MiniF2F-MATH에서 특히 두드러집니다), 추론 스케일링의 이점을 특성화할 수 있다는 고무적인 초기 증거를 제공합니다.

3.2 Similarities in Coverage Curves Across Models

  • 흥미롭게도, 동일한 작업에서 같은 계열의 서로 다른 모델들의 커버리지 곡선(로그 축의 x-축을 사용)을 비교할 때(Figure 3 참조), S-곡선의 기울기는 동일하지만 고유한 수평 이동이 있음을 알 수 있습니다. 
  • 이를 더 조사하기 위해, Figure 6에서 동일한 계열의 서로 다른 모델들의 커버리지 곡선을 겹쳐서 표시합니다. 
  • 우리는 기준 커버리지 값 \(c\)를 선택하고, 모든 곡선이 점 (1, \(c\))을 통과하도록 곡선을 왼쪽으로 이동시킵니다(로그 공간에서). 
  • 이는 \( \log(\text{pass@k}^{-1}(c)) \)만큼 왼쪽으로 이동시키는 것을 의미하며, 여기서 \( \text{pass@k}^{-1}(c) \)는 \( \text{pass@k} = c \)인 가장 가까운 자연수 \(k\)를 나타냅니다. 
  • 우리는 모든 모델에서 \( \text{pass@1} \) 점수의 최대값을 \(c\)로 선택합니다. 
  • 이러한 유사성은 동일 계열의 모델들 간에, 커버리지를 \(c\)에서 \(c'\)로 개선하기 위해 필요한 로그 샘플 예산의 증가(또는 샘플 예산의 곱셈적 증가)가 대체로 일정하다는 것을 보여줍니다.
  • 같은 계열의 모델의 곡선은 비슷한 경향을 띈다

4 Harnessing Repeated Sampling Requires Precision

  • 지금까지 우리는 모델 커버리지를 측정하고, 올바른 모델 샘플을 항상 식별할 수 있는 최상의 시나리오에서 반복 샘플링의 이점을 설명하는 데 초점을 맞췄습니다. 
  • 이제 우리는 상호 보완적인 문제인 precision로 전환합니다. 
  • 즉, 주어진 모델 샘플 컬렉션에서 올바른 샘플을 식별할 수 있는지에 대한 문제입니다. 
  • 섹션 4.1에서는 GSM8K와 MATH에서 두 가지 일반적인 검증 방법(다수결 투표와 보상 모델 점수화)을 평가합니다. 
  • 또한, 섹션 4.2에서는 올바른 소프트웨어 프로그램을 식별하기 위해 유닛 테스트에 의존할 때 발생할 수 있는 잠재적인 문제점들에 대해 논의합니다.
  • 섹션3은 커버리지 관점에서 했던 실험들이고 섹션4는 precision, 정확도 관점에서 실험한듯

4.1 Common Verification Methods Don’t Always Scale with the Sample Budget

  • 우리가 평가한 다섯 가지 작업 중에서, GSM8K와 MATH만이 해답을 자동으로 검증하는 도구가 부족합니다. 
  • 여기서 우리는 최종 답안을 결정하기 위한 두 가지 일반적인 접근법을 평가합니다: 
    • 샘플 간의 다수결 투표 계산과 보상 모델을 사용하여 각 샘플에 점수를 부여하는 방법입니다. 
  • 이 기술들을, 섹션 2에서 Llama-3-8B-Instruct 및 Llama-3-70B-Instruct로 생성한 10,000개의 샘플에서 올바른 해답을 식별하는 능력에 대해 테스트합니다. 
  • 우리는 다음 세 가지 방법을 벤치마크합니다:
  • 1. Majority Vote: 가장 많이 나온 최종 답을 선택합니다 [60].
  • 2. Reward Model + Best-of-N: 보상 모델 [17]을 사용해 각 솔루션에 점수를 매기고, 가장 높은 점수를 받은 샘플의 답을 선택합니다.
  • 3. Reward Model + Majority Vote: 보상 모델 점수로 각 샘플에 가중치를 두어 다수결 투표를 계산합니다.
  • 우리는 보상 모델로 ArmoRM-Llama3-8B-v0.1 [57]을 사용했으며, 이 모델은 현재 공개된 가중치 모델 중 RewardBench 리더보드에서 가장 높은 추론 점수를 기록하고 있습니다 [38]. 
    • 실제로는 이 보상 모델을 만드는것도 일일듯. 또한 FLOPS에도 이 비용도 포함해야하지 않을까?
  • Figure 7에서 샘플 수를 늘릴 때의 결과를 보고합니다. 
    • 세 가지 방법 모두 처음에는 샘플 수가 증가함에 따라 성공률이 증가하지만, 100개 샘플 정도에서 성공률이 정체됩니다. 
    • 반면, 커버리지는 샘플 수가 증가할수록 계속 증가하여 95%를 초과합니다.
    • 단순히 보상모델만 쓰는건 별로인듯
    • 어쨌거나, 샘플수가 많아질수록 정확도도 우상향하긴함
    • 여기서 비교모델들은 없나?
  • 다수결 투표의 경우, 성공률의 정체는 쉽게 설명할 수 있습니다. 
    • 실제로 정답을 맞추는 경우 소수의 문제이기 때문...
    • 샘플 수가 증가함에 따라 각 답에 할당된 투표 비율이 안정되기 때문에 성공률이 정체됩니다. 
    • GSM8K 및 MATH 문제 중 일부는 올바른 해답이 1% 이하의 확률로 샘플링되기 때문에(참조: Figure 8), 올바른 해답이 소수의 샘플에만 포함됩니다. 
    • 샘플 수가 증가함에 따라 희귀한 올바른 해답이 더 많은 문제에서 등장하여 커버리지는 증가하지만, 다수결 투표로는 성공률이 증가하지 않습니다. 
    • 반복 샘플링의 완전한 이점을 누리려면, 샘플 식별 방법이 이러한 "건초 더미 속 바늘" 문제를 해결하고 희귀한 올바른 샘플을 식별할 수 있어야 합니다.
  • 보상 모델의 성능이 저조한 상황에서, 후보 솔루션을 검증하는 것이 얼마나 어려운지 궁금해할 수 있습니다. 
    • GSM8K 및 MATH의 경우, 최종 답안만을 사용해 정확성을 평가하며, 중간 추론 과정은 제외됩니다. 
  • 만약 모델이 중간에 말이 되지 않는 추론을 생성하고 최종적으로 올바른 답을 추측했다면, 검증은 문제를 처음부터 푸는 것만큼 어려울 수 있습니다. 
    • 이 질문을 조사하기 위해, 우리는 **Llama-3-8B-Instruct**로 생성된 올바른 GSM8K 문제 해답에서 105개의 추론 과정을 수동으로 평가하고, 그 결과를 Table 2에 보고합니다. 
    • 그 결과, 정확한 해답이 드물게 생성되는 문제에서도, 우리가 평가한 추론 과정의 90% 이상이 신뢰할 만한 것으로 나타났습니다. 
    • 이러한 올바른 추론 단계는 검증자가 올바른 샘플을 식별할 수 있는 신호를 제공한다는 것을 시사합니다.
    • 많은 샘플을 생성한것중 적은 샘플만 정답을 맞춘 케이스를 확인해봐도, 모델은 대체적으로 유효한 논리적 추론을 따른다고 함. 즉 이유없이 맞추는건 아니다
  • 흥미롭게도, 이 과정에서 우리는 하나의 GSM8K 문제에서 **잘못된 정답**이 포함된 것을 발견했습니다(부록 E 참조). 
    • 이 잘못된 GSM8K 문제는 Llama-3-70B-Instruct가 10,000번의 시도에서 "올바른" 샘플을 생성하지 못한 유일한 문제이기도 합니다.

4.2 Verifiers and Software Tasks: Two Cautionary Tales

  • 소프트웨어 개발 작업은 사용 가능한 검증 도구에 대한 중간 입장을 차지할 수 있습니다. 
  • 한편으로, 코드를 실행하고 테스트할 수 있는 능력은 비구조적 언어 작업에서 가능한 것보다 더 높은 수준의 자동 검증을 허용합니다. 
  • 그러나 유닛 테스트와 같은 도구는 코드의 검증을 블랙박스 방식으로 접근하며, 증명 검사기(proof checkers)와 같은 방법만큼 포괄적이지는 않습니다. 
  • 이러한 검증 과정의 불완전함은 반복 샘플링을 적용할 때 고려해야 할 중요한 오탐(false positives) 및 누락(false negatives)으로 이어질 수 있습니다. 
  • 아래에서는 섹션 2.1의 결과를 생성하는 과정에서 우리가 발견한 소프트웨어 검증기 불완전성의 두 가지 예를 제공합니다.
  • 아래는 자동 검증기의 단점을 보여주는 섹션

4.2.1 Flaky Tests in SWE-bench Lite 

  • SWE-bench Lite의 결과를 생성하는 과정에서, 11.3%의 문제에서 동일한 후보 솔루션을 실행할 때 일관된 결과를 생성하지 않는 **플래키 테스트(flaky tests)**를 발견했습니다. 
  • 이러한 플래키 테스트는 때때로 데이터셋의 정답 해답조차도 잘못된 것으로 분류합니다. 
  • 또한, 일부 문제에 대한 테스트 스위트는 후보 솔루션에 따라 비결정적일 수 있습니다. 
  • 예를 들어, 두 개의 SWE-bench Lite 문제는 Python 집합(set)을 조작하는 것과 관련이 있으며, 집합은 본래 순서가 없는 데이터 구조입니다. 
  • 이 문제의 정답 솔루션은 집합 내 항목의 순서를 명시적으로 정렬하며 테스트 스위트를 신뢰성 있게 통과합니다. 
  • 그러나 일부 모델 생성 후보 솔루션은 이러한 정렬을 강제하지 않으며, 따라서 일부 "행운"이 따른 실행에서는 테스트를 통과하고 다른 경우에는 통과하지 못합니다.
  • 부록 B에서는 우리가 플래키 테스트를 발견한 모든 문제 ID를 나열합니다. 
  • 또한 문제를 제거한 SWE-bench Lite 결과를 Figure 2에서 보고하며, 전체 데이터셋에 대한 평가와 유사한 결과를 발견했습니다.

4.2.2 False Negatives in CodeContests 

  • CodeContests 데이터셋의 각 문제는 솔루션의 정확성을 평가하기 위해 사용되는 입력-출력 테스트 케이스 세트를 제공합니다. 
  • 이러한 테스트 케이스는 APPS와 같은 이전의 코딩 벤치마크보다 더 포괄적이며, 모든 테스트 케이스를 통과하지만 문제를 완전히 해결하지 못하는 잘못된 양성(false positive) 솔루션의 빈도를 줄입니다. 
  • 그러나 CodeContests 테스트 스위트의 구성으로 인해 올바르지만 테스트에 실패하는 잘못된 음성(false negative) 솔루션이 발생할 수 있습니다.
  • 일부 CodeContests 문제의 문제 설명은 주어진 테스트 입력에 대해 여러 개의 서로 다른 올바른 출력을 허용합니다. 
    • 그러나 해당 테스트 케이스는 이러한 시나리오를 처리하지 않고 특정한 올바른 출력을 요구합니다. 
  • 또한 많은 CodeContests 테스트 케이스는 원래 테스트 케이스를 변형하여 프로그래밍 방식으로 생성된 것입니다. 
    • 일부 변형된 입력은 문제의 입력 사양을 위반합니다(예: 문제 설명에서 양의 정수를 약속하는데 변형된 입력이 0인 경우). 
    • 이러한 형식이 잘못된 테스트 케이스는 서로 다른 올바른 솔루션 간에 일관되지 않은 동작을 초래할 수 있습니다.
    • CodeContests 테스트셋이 완벽하지 않기도함

5 Discussion and Limitations

  • 이 연구에서는 모델 성능을 향상시키기 위해 추론 시간에 컴퓨팅을 확장하는 축으로 반복 샘플링을 탐구합니다. 
  • 다양한 모델과 작업에서 반복 샘플링은 생성된 샘플을 사용하여 해결된 문제의 비율(즉, 커버리지)을 크게 향상시킬 수 있습니다. 
  • 정답 솔루션을 식별할 수 있는 경우(자동 검증 도구나 기타 검증 알고리즘을 사용하여), 반복 샘플링은 추론 중 모델의 능력을 증폭시킬 수 있습니다. 
    • 이러한 증폭은 약한 모델과 많은 샘플의 조합이 더 강력하고 비싼 모델의 적은 시도보다 더 성능이 뛰어나고 비용 효율적이게 만들 수 있습니다.
  • Improving Repeated Sampling:
    • 우리의 실험에서는 모든 문제에 대한 시도가 동일한 프롬프트와 하이퍼파라미터를 사용하여 독립적으로 생성되는 간단한 버전의 반복 샘플링만을 탐구합니다. 
    • 이 설정은 성능 향상을 위해 정제될 수 있다고 믿으며, 특히 다음 방향에서 개선할 수 있습니다:
  • 1. 솔루션 다양성: 
    • 현재 우리는 샘플 간 다양성을 생성하기 위한 유일한 메커니즘으로 긍정적인 샘플링 온도에 의존하고 있습니다. 
    • temperature말고도 다양하게 다양한 응답을 생성하도록 컨트롤 해볼 수 있음
    • 사실 앙상블 느낌이라.. 그냥 모델을 여러개 활용해도 되지 않을까?
    • 이 토큰 수준의 샘플링을 다른 고차원적 접근 방식과 결합하면 다양성을 더욱 증가시킬 수 있습니다. 
    • 예를 들어, AlphaCode는 서로 다른 메타데이터 태그로 샘플을 조건화합니다.
  • 2. 다단계 상호작용: 
    • CodeContests 및 MiniF2F 문제를 해결할 때 자동 검증 도구가 사용 가능하지만, 우리는 모델이 이를 반복할 수 없는 단일 턴 설정만 사용합니다. 
    • 이러한 도구로부터 실행 피드백을 모델에 제공하면 솔루션 품질이 향상될 수 있습니다. 
    • 각 시도가 더 비싸지지만 성공 가능성도 더 높아질 수 있으므로 다단계 상호작용과 관련된 트레이드오프에 관심이 있습니다.
  • 3. 이전 시도에서 학습:
    • 현재 우리의 실험은 시도를 완전히 분리합니다. 
    • 검증 도구가 제공하는 피드백이 기존 샘플에 접근할 수 있다면, 미래의 시도를 생성할 때 유용할 수 있습니다.
    • 이전 샘플을 반영해서 다음 샘플을 생성할 수 있다면??

6 Related Work

  • Scaling Inference Compute: 
    • 추론 중 추가 계산을 수행하는 방법은 딥러닝의 여러 분야에서 성공을 거두었습니다. 다양한 게임 환경에서 최첨단 방법들은 수많은 가능한 미래 게임 상태를 조사한 후 이동 결정을 내리기 위해 추론 시간 검색을 활용합니다【12, 49, 10】. 유사한 트리 기반 방법은 LLM과 결합할 때도 효과적일 수 있으며, 모델이 더 나은 계획을 세우고 다양한 접근 방식을 탐색할 수 있도록 합니다【63, 8, 53, 54】. LLM의 추론 컴퓨팅을 증가시키는 또 다른 축은 모델이 솔루션에 도달하기 전에 문제에 대해 토큰을 사용하여 심사숙고하는 것입니다【62, 61, 64】. 또한 여러 모델을 추론 시간에 앙상블하여 각 모델의 강점을 결합할 수 있습니다【58, 14, 44, 56, 31】. 또 다른 접근 방식은 LLM이 자신의 응답을 비판하고 다듬는 것입니다【42, 7】.
  • Repeated Sampling: 
    • 이전 연구에서는 반복 샘플링이 여러 분야에서 LLM의 능력을 향상시킬 수 있음을 입증했습니다. 가장 효과적인 사용 사례 중 하나는 코딩 분야로【47, 15, 37】, 여기서 성능은 백만 샘플까지 확장될 수 있으며, 검증 도구(예: 유닛 테스트)가 종종 모든 후보 솔루션을 자동으로 점수화하는 데 사용됩니다. 최근 Greenblatt는 ARC 챌린지의 퍼즐을 해결할 때 반복 샘플링이 효과적임을 보여주며, 샘플 수가 증가함에 따라 로그-선형 스케일링을 관찰했습니다【23, 16】. 채팅 애플리케이션에서는 반복 샘플링을 최상의 N개 순위와 보상 모델과 결합하면 단일 응답을 탐색하는 것보다 더 나은 성능을 보일 수 있습니다【30】. 자동 검증 도구가 없는 분야에서는 기존 연구가 최종 답변을 결정하기 위해 다수결 투표【60】, LLM을 프롬프트하는 것【19】, 또는 모델 기반 검증기를 훈련하는 것【18, 41, 29, 59, 35】이 단일 샘플을 가져가는 것에 비해 추론 작업의 성능을 향상시킬 수 있음을 보여줍니다. Nguyen et al.는 길이가 특정 임계값을 초과하는 답변에 대해 다수결 투표를 수행하는 것이 모든 답변에 대한 투표보다 더 나은 성능을 보일 수 있음을 발견했습니다【43】. 우리의 연구와 동시에 Song et al.은 사용 가능한 최상의 샘플을 사용하는 것이 채팅, 수학 및 코드 작업에서 LLM 성능을 향상시킬 수 있음을 발견했습니다. 최대 128개의 샘플을 사용하여 성능을 높일 수 있었습니다【50】. 또한 Hassid et al.는 코딩 작업을 해결할 때 더 큰 모델에서 적은 샘플을 추출하기보다 더 작은 모델에서 더 많은 샘플을 추출하는 것이 더 효과적일 수 있음을 발견했습니다【24】.
  • Scaling Laws:
    • 확장이 모델 성능에 미치는 영향을 특성화하면 자원을 어떻게 할당할지에 대한 보다 정보에 기반한 결정을 내릴 수 있습니다. LLM 훈련을 위한 확장 법칙은 손실과 훈련 컴퓨팅 양 사이의 거듭 제곱 관계를 찾아내며, 고정된 컴퓨팅 예산을 고려할 때 최적의 모델 및 데이터셋 크기에 대한 추정치를 제공합니다【27, 36, 28】. Jones는 보드 게임 Hex의 맥락에서 확장 법칙을 발견하여 성능이 모델 크기와 문제의 난이도에 따라 예측 가능하게 확장됨을 관찰했습니다【33】. 흥미롭게도, 그들은 트리 검색을 수행할 때 사용한 테스트 시간 컴퓨팅의 양에 따라서도 성능이 확장된다는 것을 보여주었습니다. 최근 Shao et al.은 LLM을 외부 검색 데이터셋으로 보강할 때 확장 법칙을 관찰했으며, 검색 작업에서의 성능이 검색 코퍼스의 크기에 따라 부드럽게 확장됨을 발견했습니다【48】.

Reference

댓글

댓글 쓰기