본문으로 건너뛰기

인공지능융합응용

이성현 교수님

Language Model(언어 모델) 기초​

Generative AI 연구의 두 가지 흐름​

Generative AI 연구는 크게 두 가지 방향으로 나뉜다.

  1. 활용 중심 접근: Generative AI의 내부 동작 원리보다는, 이 새로운 도구를 어떻게 자신의 과업에 효과적으로 사용할지에 초점을 맞춘다.
  2. 개발 중심 접근: Generative AI의 근본적인 메커니즘을 이해하고, OpenAI의 모델을 능가하는 새로운 모델을 개발하는 것을 목표로 한다.

이 강의에서는 두 접근법을 모두 다루며, 이번 장에서는 Large Language Model을 구축하는 방법에 대한 상위 수준의 수학적 원리를 탐구한다.

Language Model의 정의​

Language Model(언어 모델)은 이전 Token(토큰)들이 주어졌을 때, 시퀀스에서 다음 Token에 대한 확률 분포 P(yt∣y1:t−1)P(y_{t}|y_{1:t-1})를 출력하는 모든 모델을 의미한다. 과거에는 전체 시퀀스 대신 몇 개의 단어만 돌아보는 통계적 n-gram 모델이 주로 사용되었다. 여기서 Token은 단어라고 가정하고 시작한다.

Sequence Likelihood(연속 가능성)​

Language Model은 다음 단어의 Likelihood(가능성)를 출력한다. 이를 이용해 전체 시퀀스의 Likelihood를 계산할 수 있으며 , 이는 연쇄 법칙(chain rule)을 통해 개별 단어 예측 확률의 곱으로 분해된다.

P(Y)=∏i=1TP(yi∣y1:i−1)P(Y)=\prod_{i=1}^{T}P(y_{i}|y_{1:i-1})

모델 아키텍처​

Sequence-to-Sequence Models​

Language Model은 텍스트(단어 시퀀스)를 입력받아 텍스트를 출력하는 Sequence-to-Sequence(서열-대-서열) 모델로 볼 수 있다. 입출력 텍스트의 의미에 따라 번역, 요약, 감성 분석 등 다양한 작업을 수행할 수 있다. T5와 같은 모델은 하나의 모델로 여러 Text-to-Text 과업을 처리할 수 있음을 보여주었다.

Tokenization(토큰화)​

Tokenization(토큰화)은 텍스트를 Token이라는 이산적인(discrete) 항목의 시퀀스로 변환하는 과정이다. Tokenization 방식에는 단어, 문자, 그리고 그 중간 형태인 Subword(부분 단어) 단위로 분할하는 방법이 있으며, 효과적인 Tokenization은 (1)적은 수의 고유 Token과 (2)짧은 시퀀스 길이를 목표로 한다.

Vocabulary와 Embedding​

Vocabulary(어휘)는 사용 가능한 모든 Token의 목록이다. 신경망은 이산적인 Token을 직접 처리할 수 없으므로, 각 Token을 Vocabulary에 매핑된 연속적인 벡터인 Embedding(임베딩)으로 변환한다. 이 Embedding 벡터들을 변환하고 결합하여 Hidden State(은닉 상태)라는 새로운 시퀀스를 만든다.

다음 Token 예측​

모델은 최종적으로 Hidden State를 사용하여 Vocabulary에 있는 모든 Token에 대한 점수인 Logits(로짓)을 예측한다. 이 Logits에 Softmax와 같은 정규화 함수를 적용하여 다음 Token에 대한 확률 분포를 얻는다. P(yL+1=vi∣y1:L)=exp(y^L[i])∑i=1∣∣V∣∣exp(y^L[i])P(y_{L+1}=v_{i}|y_{1:L})=\frac{exp(\hat{y}_{L}[i])}{\sum_{i=1}^{||V||}exp(\hat{y}_{L}[i])}

학습 및 추론​

Training(학습)​

모델 학습은 인간이 작성한 텍스트의 Likelihood를 최대화하는 것을 목표로 한다. 계산 효율성을 위해, 이 목표는 Negative Log Likelihood(음의 로그 가능성) 손실을 최소화하는 것으로 변환된다. 로그를 취하고 합산하는 방식은 일반적인 곱셈보다 수치적으로 더 안정적이다.

Decoding(디코딩) 및 Sampling(샘플링)​

Auto-regressive Sampling(자기회귀 샘플링)은 이전에 생성된 요소들을 조건으로 순차적으로 다음 요소를 샘플링하여 텍스트를 생성하는 방식이다. 다양한 샘플링 전략이 존재한다.

  • Greedy Sampling(탐욕적 샘플링): 각 단계에서 가장 확률이 높은 Token을 선택한다.
  • Random Sampling(무작위 샘플링): 모델이 예측한 확률 분포에 따라 무작위로 Token을 선택한다. 하지만 확률이 낮은 Token들이 누적되어 선택될 가능성이 있어 생성 품질이 저하될 수 있다.
  • Temperature Sampling(온도 샘플링): Softmax 전 Logits를 특정 온도 값 K로 나누어 분포의 모양을 조절한다. 온도가 높으면(T → ∞) 분포가 균일해지고, 온도가 낮으면(T → 0) 분포가 뾰족해져 Greedy Sampling과 유사해진다.
  • Top-k Sampling(상위-k 샘플링): 확률이 가장 높은 k개의 Token 중에서만 샘플링한다.
  • Nucleus Sampling(핵 샘플링): 누적 확률이 특정 임계값 p에 도달할 때까지의 Token 집합에서 샘플링한다.
  • Frequency/Presence Penalty: 이미 등장한 Token의 빈도나 존재 여부에 따라 다음에 등장할 확률을 낮추어 반복을 줄인다.

Few-shot Prompting(퓨샷 프롬프팅)​

Prompt Engineering의 등장​

고도로 발달한 Language Model은 텍스트 입력을 받아 텍스트를 출력하는 유연한 인터페이스를 통해 다양한 작업에 적응할 수 있다. Prompt Engineering(프롬프트 엔지니어링)은 원하는 출력을 얻기 위해 이 Language Model의 입력을 신중하게 구성하는 기술이다.

Few-shot Prompting과 In-context Learning​

Few-shot Prompting은 Language Model이 특정 작업을 수행하도록 유도하기 위해 몇 개의 예시(demonstrations)를 입력으로 제공하는 방식이다. 이는 모델의 가중치를 업데이트하는 별도의 학습 과정 없이, 모델의 순방향 패스(forward-pass) 내에서 예시를 통해 빠르게 작업을 인식하고 적응하는 In-context Learning(인컨텍스트 학습)을 통해 이루어진다.

In-context Learning이 가능한 이유는 모델이 사전 학습 과정에서 이미 요약(TL;DR), 번역 등 다양한 작업의 패턴을 데이터에서 접했기 때문이다. 따라서 Few-shot 예시는 모델에게 새로운 지식을 가르친다기보다, 이미 내재된 능력을 특정 작업의 형식(template)에 맞게 활성화시키는 역할을 한다.

In-context Learning 실증 연구​

Min 등의 2022년 연구는 In-context Learning이 실제로 어떻게 작동하는지 검증했다. 연구진은 감성 분석, 상호참조 확인, 질의응답 등 다양한 분류 및 다지선다형 과제에 대해 실험했다.

실험은 세 가지 조건으로 프롬프트를 구성했다.

  1. No Demos: 예시 없음
  2. Demos w/ gold labels: 정답 레이블이 포함된 예시
  3. Demos w/ random labels: 레이블 공간 내에서 무작위로 선택된, 틀린 레이블이 포함된 예시

연구 결과 및 시사점​

  • 예시의 중요성: 예시를 제공하는 것(gold labels)은 예시가 없는 경우보다 성능을 크게 향상시켰다.
  • 정답 레이블의 역할: 놀랍게도, 정답 레이블을 무작위 레이블로 교체해도 성능 저하는 미미했다. 즉, 틀린 예시를 제공하는 것이 예시를 아예 제공하지 않는 것보다 훨씬 효과적이었다.
  • 성능에 영향을 미치는 진짜 요소: 이 결과는 In-context Learning의 성능을 결정하는 것이 예시의 입력-레이블 매핑 그 자체가 아님을 시사한다. 연구진은 다음 네 가지 요소가 중요하다고 분석했다.
    1. Input Text Distribution(입력 텍스트 분포): 예시로 제공되는 입력 텍스트가 실제 해결하려는 작업의 입력과 유사한 분포를 가질 때 성능이 크게 향상된다. 관련 없는 텍스트를 입력으로 사용하면 성능이 급격히 떨어진다.
    2. Label Space(레이블 공간): 예시에 사용된 레이블이 실제 작업의 가능한 레이블 집합(예: 'Positive', 'Negative') 내에 속하는 것이 중요하다. 레이블 공간과 무관한 임의의 단어를 레이블로 사용하면 성능이 크게 저하된다.
    3. Overall Format(전체 형식): 입력과 레이블이 쌍을 이루는 구조적 형식을 보여주는 것 자체가 모델이 작업을 이해하는 데 도움을 준다.
    4. Input-Label Mapping: 입력과 레이블의 정확한 연결 관계는 위 세 요소보다 상대적으로 덜 중요하다.

결론적으로, Language Model은 우리가 생각하는 방식과 다르게 동작할 수 있으며 , 효과적인 프롬프트 설계를 위해서는 이러한 특성을 이해하고 지속적인 평가와 실험이 필요하다.

Zero-shot Prompting(제로샷 프롬프팅)​

Zero-shot Prompting의 정의​

Zero-shot Prompting은 Few-shot Prompting과 달리, 어떠한 예시도 제공하지 않고 오직 Natural Language Instruction(자연어 지시)이나 과업 설명을 통해 Language Model이 작업을 수행하도록 하는 기법이다. 예를 들어, 번역 작업을 시킬 때 "Translate this sentence to Spanish: [sentence]"와 같이 직접적인 지시를 내리는 방식이다.

Zero-shot 능력의 발전​

초기 모델인 GPT-2(1.5B)는 지시사항을 대부분 무시하고 과업 수행에 실패하는 등 Zero-shot 능력이 매우 제한적이었다. 하지만 모델의 Scale(규모)이 커지면서 이 능력은 비선형적으로 향상되었다. 특히 특정 임계점을 넘어서면서 능력이 갑자기 나타나는 Emergent Abilities(창발적 능력) 현상이 관찰되었다.

이러한 발전은 Instruction Tuning(명령어 튜닝)을 통해 더욱 가속화되었다. Instruction Tuning은 다양한 지시사항과 그에 따른 결과로 구성된 데이터셋으로 모델을 미세조정하는 방법으로, FLAN, InstructGPT/GPT-3.5 등이 대표적인 예다. 이를 통해 모델은 보지 못한 새로운 작업에 대해서도 지시사항을 더 잘 따르게 되었다.

효과적인 Zero-shot 프롬프트 구성​

효과적인 Zero-shot 프롬프트를 작성하기 위해서는 다음과 같은 요소들을 명확히 해야 한다.

  • 명확한 과업 명세: 모델이 무엇을 해야 하는지 정확하게 정의한다. "이 텍스트를 분석해줘"와 같은 모호한 지시 대신, "이 텍스트의 주요 주제를 식별해줘"처럼 구체적으로 작성해야 한다.
  • 출력 형식 지정: 응답이 어떤 구조(예: JSON, 글머리 기호)를 가져야 하는지 명시한다.
  • 제약 조건 및 예외 처리: "카테고리는 반드시 Technology, Sports, Politics 중 하나여야 한다"와 같이 제약을 걸거나 , "정보가 없을 경우 null로 표기하라"처럼 예외 상황에 대한 처리 방법을 안내한다.

Zero-shot vs. Few-shot Prompting 비교​

Zero-shot PromptingFew-shot Prompting
예시가 필요 없음신중하게 선택된 예시가 필요함
프롬프트가 더 단순하고 짧음프롬프트가 더 복잡하고 길어짐
일반적으로 정확도가 더 낮음종종 정확도가 더 높음
프롬프트 문구에 더 민감함프롬프트 변형에 더 강건함
복잡하고 미묘한 작업보다는 간단한 작업에 적합복잡하고 미묘한 작업에 더 적합

Zero-shot Prompting은 구현이 간단하고 효율적이지만, 모델이 지시를 오해하거나(misinterpretation), 특정 도메인 지식이 부족하거나, 환각(hallucination)을 일으킬 수 있는 한계가 있다.

Chain-of-Thought Prompting(사고의 연쇄 프롬프팅)​

Chain-of-Thought (CoT)의 정의​

복잡한 추론이 필요한 과제를 해결하기 위해, Language Model이 최종 답변에 도달하기 전에 단계별 추론 과정을 먼저 생성하도록 유도하는 기법을 Chain-of-Thought (CoT) Prompting(사고의 연쇄 프롬프팅)이라고 한다. 이는 문제 해결 과정을 여러 단계로 분해하여 중간 계산이나 논리적 추론을 명시적으로 보여줌으로써, 모델의 정확도를 크게 향상시킨다.

CoT 접근 방식​

CoT를 유도하는 방법은 크게 두 가지로 나뉜다.

  1. Few-Shot CoT: 프롬프트에 추론 과정이 상세히 포함된 몇 개의 예시를 제공한다. 모델은 이 예시의 패턴을 학습하여 새로운 문제에 대해서도 유사한 추론 과정을 생성한다.

    • 예시: 수학 문제 풀이에서 "로저는 처음에 5개의 공을 가졌고, 2캔을 더 샀으므로 2∗3=62*3=6개의 공이 추가된다. 따라서 총 5+6=115+6=11개의 공을 갖게 된다"와 같이 계산 과정을 명시적으로 보여준다.

  2. Zero-Shot CoT: 예시 없이, "Let's think step by step." (단계별로 생각해보자.)와 같은 간단한 지시 문구를 프롬프트에 추가하여 모델의 내재된 추론 능력을 활성화시킨다. 대규모 Language Model은 사전 학습 과정에서 이미 추론 패턴을 내재화했기 때문에, 이러한 간단한 트리거만으로도 추론 과정을 생성할 수 있다.

고급 CoT 기법 및 발전​

CoT는 다양한 고급 기법으로 발전하고 있다.

  • Auto-CoT: 사람이 직접 고품질의 추론 예시를 만드는 수고를 덜기 위해, Zero-Shot-CoT를 이용해 자동으로 예시를 생성하고 이 중 적절한 것을 선택하여 Few-shot CoT에 활용하는 방식이다. 이는 수동으로 작성된 Few-shot CoT와 필적하는 성능을 보여준다.
  • Faithful CoT(신뢰성 있는 CoT): 생성된 추론 과정이 실제 모델의 답변 도출 과정과 일치하지 않는 문제(unfaithful)를 해결하기 위한 프레임워크다. 이는 Language Model이 자연어와 Python 코드 같은 상징적 언어가 결합된 추론 과정을 생성하면 , 외부의 결정론적 해결사(Deterministic Solver)가 이 코드를 실행하여 최종 답변을 도출하는 방식이다. 이를 통해 추론 과정과 결과 사이의 인과관계를 보장한다.
  • 기타 기법: 복잡한 문제를 하위 문제로 나누어 순차적으로 푸는 Least-to-Most Prompting, 여러 추론 경로를 동시에 탐색하는 Tree of Thoughts(ToT) 등이 있다.

고급 프롬프팅 기법: Least-to-Most와 Decomposed Prompting​

Least-to-Most Prompting(최소-최대 프롬프팅)​

Chain-of-Thought Prompting은 예시보다 더 어려운 문제에 대한 일반화 성능이 떨어지는 한계를 가진다. Least-to-Most Prompting은 이 문제를 해결하기 위한 기법으로, 두 단계로 구성된다.

  1. Decomposition(분해): 복잡한 문제를 더 쉬운 하위 문제(subproblems)의 목록으로 분해한다.
  2. Subproblem Solving(하위 문제 해결): 이전에 해결한 하위 문제의 답을 활용하여 다음 하위 문제를 순차적으로 해결한다.

예를 들어 'thinking, machine, learning'의 마지막 글자를 잇는 문제(LLC Task)에서, CoT는 한 번에 해결하려 하지만, Least-to-Most는 "think" -> "think, machine" -> "think, machine, learning" 순으로 문제를 풀어가며 이전 단계의 결과를 다음 단계 해결에 사용한다. 이 방식은 문제의 길이가 길어지는 경우에도 CoT보다 훨씬 높은 성능을 유지한다.

하지만 이 기법은 과제에 맞는 분해 방법을 프롬프트로 만드는 것이 어렵고, 특정 도메인(예: 수학)에서 만든 분해 프롬프트가 다른 도메인(예: 상식 추론)에 잘 일반화되지 않는다는 한계가 있다.

Decomposed Prompting(분해 프롬프팅)​

Decomposed Prompting은 Least-to-Most의 아이디어를 더 모듈화하여 구조화한 접근 방식이다. 이는 마치 소프트웨어 엔지니어링과 같이 문제를 해결한다.

  • Decomposer(분해기): 복잡한 작업을 해결하기 위해 필요한 간단한 하위 작업들의 순서(프로그램)를 정의한다.
  • Sub-task Handler(하위 작업 핸들러): 각 하위 작업을 전문적으로 처리하는 모듈(함수) 역할을 한다. 각 핸들러는 독립적인 few-shot 프롬프트를 가질 수 있다.

이 방식의 장점은 다음과 같다.

  • 모듈성 및 재사용성: 단어 분리, 문자 추출과 같은 하위 작업 핸들러는 여러 복잡한 작업에서 재사용될 수 있다.
  • 개발 용이성: 복잡한 작업 전체에 대한 예시를 만드는 것보다, 간단한 하위 작업에 대한 풍부한 예시를 만드는 것이 더 쉽다.
  • 유지보수성: 특정 하위 작업 핸들러의 성능을 개선하면, 다른 부분을 수정할 필요 없이 전체 시스템의 성능을 높일 수 있다.

이처럼 문제 해결을 작은 단위로 분해하고, 각 단위를 전문적으로 처리하는 모듈을 조합하는 방식은 Language Model을 통해 복잡한 문제를 더 안정적이고 확장 가능하게 해결할 수 있는 방향을 제시한다.

트리 기반 프롬프팅 (Tree-based Prompting)​

LLM의 사고 과정과 한계​

인간의 의사결정 과정은 두 가지 모드로 나뉜다.

  • System 1: 빠르고, 자동적이며, 무의식적인 사고 방식이다. Language Model(언어 모델)이 대안을 깊이 고려하지 않고 토큰 단위로 가장 확률 높은 다음 단어를 선택하는 과정은 System 1과 유사하다.
  • System 2: 느리고, 신중하며, 의식적인 사고 방식이다.

LLM이 더 복잡한 문제 해결사가 되기 위해서는 System 2와 같은 능력이 필요하다. 즉, 다양한 대안을 탐색하고, 현재 진행 상황을 평가하며, 필요시에는 이전 단계로 돌아가 다른 경로를 선택(backtracking)할 수 있어야 한다. 기존의 왼쪽에서 오른쪽으로 이어지는 단순한 언어 시퀀스 생성 방식은 이러한 복잡한 탐색에 한계가 있다.

Tree of Thoughts (ToT) 프레임워크​

이러한 한계를 극복하기 위해, 문제 해결 과정을 하나의 경로가 아닌 여러 갈래의 경로를 동시에 탐색하는 트리(tree) 구조로 모델링할 수 있다. Tree of Thoughts(ToT)는 LLM이 여러 추론 경로를 탐색하도록 하는 프레임워크로, 문제 해결을 트리 탐색(search over a tree) 과정으로 정의한다. 이 트리에서 각 노드(node)는 부분적인 해답을 나타내는 상태(state)가 된다.

ToT 프레임워크를 구현하기 위해서는 다음 네 가지 핵심 요소를 정의해야 한다.

  1. 사고 분해 (Thought Decomposition): 전체 문제를 어떻게 중간 사고(thought) 단위로 나눌 것인가?
  2. 사고 생성 (Thought Generation): 각 상태에서 다음 단계의 사고 후보들을 어떻게 생성할 것인가?
  3. 상태 평가 (State Evaluation): 생성된 각 사고(상태)의 가치를 어떻게 휴리스틱하게 평가할 것인가?
  4. 탐색 알고리즘 (Search Algorithm): 어떤 알고리즘을 사용해 트리를 탐색할 것인가?

ToT의 구성 요소​

  • 사고 분해: 좋은 사고 단위는 LLM이 다양한 샘플을 생성할 수 있을 만큼 '작아야' 하고, 동시에 문제 해결에 대한 기여도를 평가할 수 있을 만큼 '커야' 한다. 예를 들어, '24 게임'에서는 하나의 수식 라인이 사고 단위가 될 수 있다.
  • 사고 생성기: 프롬프트를 통해 현재 상태에서 가능한 다음 사고 후보들을 k개 생성한다.
  • 상태 평가기: 탐색 알고리즘이 어떤 상태를 계속 탐색할지 결정하도록 돕는 휴리스틱 평가기다. LLM 자체가 "이 상태가 최종 정답에 도달할 가능성이 있는가?" (예: 'sure/likely/impossible')를 판단하도록 하여 스스로 상태를 평가할 수 있다.
  • 탐색 알고리즘: Breadth-First Search (BFS)나 Depth-First Search (DFS) 같은 기본적인 탐색 알고리즘을 적용할 수 있다. 예를 들어, BFS는 각 단계에서 가장 유망한 b개의 상태를 유지하며 탐색하고, DFS는 가장 유망한 상태를 깊이 우선으로 탐색하다가 특정 임계값 이하의 가치를 가지면 백트래킹한다.

'24 게임'에서 ToT-BFS를 사용했을 때, 단일 경로만 탐색하는 Chain-of-Thought(4.0%)에 비해 b=5일 때 74%의 성공률을 보여, 탐색의 효과를 입증했다.

고급 트리 탐색: Planning-Guided Transformer Decoding (PG-TD)​

ToT를 넘어, 트리 탐색을 코드 생성과 같은 보다 복잡한 작업에 적용할 수 있다. 기존 코드 생성 방식은 다수의 후보 프로그램을 생성한 뒤 테스트 케이스로 필터링하는 방식이었다. 이 방식은 생성 과정에서 테스트 케이스의 정보를 활용하지 못하는 한계가 있다.

Planning-Guided Transformer Decoding(PG-TD)은 Monte Carlo Tree Search(MCTS)와 같은 계획(planning) 알고리즘을 Transformer의 디코딩 과정에 직접 통합한 것이다. MCTS는 '선택-확장-평가-역전파'의 4단계를 통해 트리 탐색을 수행하며, PG-TD는 이 과정을 토큰 생성에 적용한다.

  • 선택 (Selection): LLM이 예측한 토큰 확률과 MCTS의 탐색/활용 전략(P-UCB)을 결합하여 다음 탐색할 노드(부분 프로그램)를 선택한다.
  • 확장 (Expansion): 선택된 노드에서 LLM을 사용해 가장 가능성 있는 다음 토큰들을 제안하고 자식 노드로 추가한다.
  • 평가 (Evaluation): 새로 추가된 노드(부분 프로그램)를 기반으로 전체 프로그램을 완성(beam search)하고, 이를 테스트 케이스에서 실행하여 보상(pass rate)을 계산한다.
  • 역전파 (Backpropagation): 계산된 보상을 상위 노드들로 전파하여 각 노드의 가치를 업데이트하고, 이는 다음 선택 과정에 영향을 준다.

PG-TD는 사전 학습된 모델을 재학습 없이 다양한 목적에 맞게 조정할 수 있으며, 코드 생성 성능을 일관되게 향상시키는 효과를 보였다.

다중 에이전트 프롬프팅 (Multi-agent Prompting)​

다중 에이전트 접근법의 동기​

단일 LLM 인스턴스를 사용하는 기존 프롬프팅 기법과 달리, 다중 에이전트 프롬프팅은 여러 LLM 인스턴스가 개별적으로 제안하고 함께 토론(debate)하여 공동의 답에 도달하는 방식이다. 이는 인간이 서로 다른 방식으로 문제를 풀어보고 답이 일치하면 확신을 얻거나, 답이 다를 경우 서로의 풀이를 검토하며 일관된 답을 찾아가는 과정과 유사하다.

접근법 1: 토론 절차 모델링 (Modeling Debate Process)​

여러 에이전트가 주어진 질문에 대해 각자의 초기 답변을 생성한다. 이후, 각 에이전트는 다른 에이전트들의 답변을 참고하여 자신의 답변을 검증하고 수정하는 토론 라운드를 반복한다.

예를 들어, 보석 개수를 계산하는 수학 문제에서 한 에이전트는 잘못된 수식으로 560이라는 답을 내고, 다른 에이전트는 올바른 계산으로 595라는 답을 낸다. 다음 라운드에서 서로의 풀이를 본 후, 첫 번째 에이전트는 자신의 오류를 인지하고 두 번째 에이전트의 답인 595에 동의하게 된다.

이러한 다중 에이전트 토론은 단일 에이전트 방식보다 산술, 추론, 사실 기반 질문 등에서 더 높은 정확도를 보였다. 특히 이 방식은 Chain-of-Thought와 결합되었을 때 더 큰 성능 향상을 가져왔다.

접근법 2: 논쟁적 토론 (Argumentative Debate)​

이 방식은 "찬성 측"과 "반대 측"처럼 명확한 역할을 가진 두 에이전트가 첨예하게 대립(tit for tat)하며 논쟁하고, "판사" 역할을 하는 제3의 에이전트가 토론을 중재하고 최종 해결책을 도출하는 보다 구조화된 토론이다.

실험 결과, 에이전트들이 무조건 합의하는 것(Level 0)이나 무조건 반대하는 것(Level 3)보다, 적절한 수준의 대립(Level 2)을 유지할 때 문제 해결 능력이 가장 높았다.

접근법 3: 소통하는 에이전트 (Communicative Agents)​

다중 에이전트 개념은 단순 토론을 넘어, 특정 역할을 가진 여러 에이전트가 협력하여 복잡한 과업을 수행하는 시뮬레이션으로 확장될 수 있다. 대표적인 예가 소프트웨어 개발 과정을 모방한 ChatDev이다.

ChatDev에서는 개발 과정이 설계(Design), 코딩(Coding), 테스트(Testing) 단계로 나뉘며, 각 단계마다 CEO, CTO, 프로그래머, 리뷰어 등 전문화된 역할을 가진 에이전트들이 짝을 이뤄 대화(Chat Chain)하며 과업을 수행한다.

이러한 복잡한 상호작용을 관리하기 위해 정교한 컨텍스트 관리가 필요하다.

  • 단기 기억 (Short-term memory): 각 단계 내에서의 연속적인 대화를 유지하는 데 사용된다.
  • 장기 기억 (Long-term memory): 이전 단계에서 도출된 해결책(코드, 설계 문서 등)을 다음 단계로 전달하여 단계 간의 맥락을 유지한다.

이러한 다중 에이전트 접근법들은 단일 모델의 한계를 보완하고, 더 정확하고 신뢰성 높은 결과를 도출할 수 있는 잠재력을 보여주지만, 계산 비용이 높고 긴 토론 맥락을 처리하는 데 어려움이 있다는 한계도 존재한다.

부록: 순차적 의사결정 문제와 마르코프 결정 과정 (MDP)​

트리 탐색과 계획(planning)의 기반이 되는 이론은 순차적 의사결정 문제의 수학적 모델링이다.

마르코프 결정 과정 (Markov Decision Process, MDP)​

순차적 의사결정 문제는 여러 행동을 순차적으로 선택하는 문제다. 이 문제는 **마르코프 결정 과정(MDP)**이라는 수학적 프레임워크로 공식화할 수 있다. MDP는 불확실한 결과 하에서의 순차적 의사결정을 모델링하며, 4개의 요소로 구성된다.

  1. 상태 (State, S): 시스템이 처한 현재 상황. (예: 4x4 그리드 월드에서 에이전트의 위치)
  2. 행동 (Action, A): 각 상태에서 선택할 수 있는 행동의 집합. (예: 상, 하, 좌, 우 이동)
  3. 보상 (Reward, R): 특정 상태에서 특정 행동을 취했을 때 얻는 즉각적인 보상. (예: 목표 지점 도달 시 +1, 함정 도착 시 -1)
  4. 전이 확률 (Transition Probability, P): 특정 상태에서 행동을 취했을 때, 다음 상태로 변할 확률.

이때, '좋은' 상태는 **마르코프 속성(Markov Property)**을 만족해야 한다. 이는 미래의 상태가 과거의 이력과 무관하게 오직 현재 상태에 의해서만 결정된다는 '기억 없음' 속성이다.

몬테카를로 트리 탐색 (Monte Carlo Tree Search, MCTS)​

MDP로 정의된 문제 공간을 탐색하여 최적의 행동 순서(정책)를 찾는 것은 매우 복잡하다. MCTS는 이러한 복잡한 문제에 대한 강력한 휴리스틱 탐색 알고리즘이다. MCTS는 반복적인 시뮬레이션을 통해 각 행동의 가치를 추정하며, 네 가지 주요 단계로 구성된다.

  1. 선택 (Selection): 현재까지의 탐색 결과를 바탕으로 가장 유망한 경로(노드)를 선택한다. 이때 탐욕적으로 가장 좋은 경로만 선택하는 **활용(exploitation)**과, 아직 덜 탐색된 경로를 선택하는 탐험(exploration) 사이의 균형을 맞추기 위해 UCB(Upper Confidence Bound) 알고리즘을 사용한다.
  2. 확장 (Expansion): 선택된 노드에서 아직 탐색되지 않은 새로운 행동을 하나 선택하여 트리를 확장한다.
  3. 시뮬레이션 (Simulation): 새로 확장된 노드부터 게임이 끝날 때까지 (보통 무작위로) 행동을 수행하여 최종 보상을 얻는다.
  4. 역전파 (Backpropagation): 시뮬레이션에서 얻은 보상 정보를 경로상의 모든 부모 노드에 거꾸로 전파하여, 각 노드의 승리 횟수(W)와 방문 횟수(N)를 업데이트한다.

이 과정을 수없이 반복하면, 트리에는 각 상태에서 어떤 행동이 더 유망한지에 대한 통계가 쌓이게 되며, 이를 바탕으로 최적의 결정을 내릴 수 있다.

프롬프트 탐색의 필요성​

최적의 성능을 내는 프롬프트를 찾기 위해 인간 사용자가 수동으로 수많은 시행착오를 거치는 것은 비효율적이다. **프롬프트 탐색(Prompt search)**은 이러한 과정을 자동화하여 고품질의 지시사항(instruction)을 생성하는 알고리즘이다. 이는 LLM을 자연어 명령어로 작동하는 일종의 블랙박스 컴퓨터로 보고, 최적의 프로그램을 찾는 최적화 문제로 접근한다.

자동 프롬프트 엔지니어 (Automatic Prompt Engineer, APE)​

APE는 LLM을 활용해 프롬프트 자체를 엔지니어링하는 기법이다.

  1. 제안 (Proposal): 입출력 예시를 기반으로 LLM이 후보 프롬프트들을 생성한다.
  2. 점수 계산 (Scoring): 생성된 각 프롬프트의 품질을 점수로 평가한다. 점수 함수로는 실제 정답을 맞추는 실행 정확도나, 정답이 나올 로그 확률 등이 사용될 수 있다.
  3. 탐색 (Search): 점수가 높은 프롬프트는 유지하고, 이를 기반으로 의미적으로 유사한 새로운 변형 프롬프트를 생성(resampling)하여 탐색을 반복한다.

텍스트 그래디언트를 이용한 프롬프트 최적화 (ProTeGi)​

ProTeGi는 경사 하강법(gradient descent)의 원리를 텍스트 기반 대화에 접목한 프롬프트 최적화 기법이다.

  1. 그래디언트 생성: 현재 프롬프트가 특정 예제들에서 왜 틀렸는지 LLM이 분석하여, 그 결함에 대한 자연어 설명인 '텍스트 그래디언트(textual gradient)'를 생성한다. 예를 들어, "이 프롬프트는 함축적인 의미를 놓치고 있다"와 같은 설명이다.
  2. 프롬프트 수정: 생성된 '그래디언트'의 반대 의미 방향으로 LLM이 현재 프롬프트를 수정하여 새로운 후보군을 만든다.
  3. 빔 탐색 (Beam Search): 이 과정을 빔 탐색 알고리즘을 통해 반복한다. 각 단계에서 여러 개의 후보 프롬프트(빔)를 유지하며, 어떤 프롬프트를 계속 탐색할지 결정하는 선택(selection) 단계가 중요하다.

이 선택 단계는 '가장 좋은 팔(arm)을 최소한의 시도로 찾는' **밴딧 문제(bandit problem)**와 유사하다. ProTeGi는 UCB1과 같은 밴딧 알고리즘을 사용하여, 각 프롬프트의 잠재적 성능(신뢰 구간의 상한)을 고려하며 효율적으로 최적의 프롬프트를 탐색한다.

더 나은 프롬프트 엔지니어 (PE2)​

자동 프롬프트 엔지니어링의 성능은 그 자체를 유도하는 **메타 프롬프트(meta-prompt)**의 품질에 크게 좌우된다. Prompt Engineered a Prompt Engineer (PE2)는 LLM이 프롬프트 엔지니어링을 더 효과적으로 수행하도록 설계된 고도로 구조화된 메타 프롬프트다.

PE2는 다음과 같은 특징을 가진다.

  • 명확한 2단계 지시: (1) 프롬프트와 실패 사례를 분석하고, (2) 그 분석에 기반해 새로운 프롬프트를 제안하라는 명확한 단계를 제시한다.
  • 컨텍스트 명세: 입력과 지시사항의 구조를 명확히 정의한다.
  • 단계별 추론 템플릿: "프롬프트가 작업을 올바르게 설명하는가?", "수정이 필요한가?"와 같은 성찰 질문(reflection questions) 템플릿을 제공하여 LLM의 분석 과정을 체계적으로 유도한다.

이러한 정교한 메타 프롬프트를 통해, LLM은 더 깊이 있는 추론을 바탕으로 효과적인 프롬프트를 자동으로 생성할 수 있게 된다.

다중 응답으로부터 학습하기 (Learning from Multiple Responses)​

정답을 모를 때의 학습​

기존 모델 학습은 이미 정답을 아는 데이터셋을 기반으로 한다. 하지만 정답 추론 과정이 여러 가지이거나 정답 자체를 모를 경우, 어떻게 모델을 학습시킬 수 있을까? 해답은 여러 개의 다양한 응답을 생성하고, 그중에서 가장 가능성 있는 답을 선택하는 것이다.

자기 일관성 (Self-consistency)​

Self-consistency는 여러 개의 서로 다른 추론 경로가 동일한 최종 답변으로 귀결된다면, 그 답변이 정답일 가능성이 높다는 직관에 기반한 기법이다.

  1. 하나의 질문에 대해, LLM이 다양한 추론 과정을 포함하는 여러 개의 답변 후보를 생성한다(예: 샘플링 온도를 높여 다양성 확보).
  2. 각 후보에서 최종 답변만을 추출한다.
  3. 추출된 답변들 중 가장 많이 등장한 답변을 최종 정답으로 선택한다 (다수결 투표).

이 방식은 별도의 지도 학습 없이도 산술 추론과 같은 다양한 과제에서 기존의 단일 경로 추론(CoT)보다 월등히 높은 성능을 보였다.

검증 (Verification)​

Verification은 모델이 생성한 여러 답변 후보의 '정확성'을 판단하는 별도의 검증기(Verifier) 모델을 학습시키는 패러다임이다.

  1. 생성기(Generator) 모델이 하나의 문제에 대해 다수의 답변 후보(예: 100개)를 생성한다.
  2. 각 후보가 최종적으로 정답을 맞췄는지 여부에 따라 'correct' 또는 'incorrect'로 레이블링한다.
  3. 검증기 모델을 이 데이터셋으로 학습시켜, 새로운 문제와 답변 후보가 주어졌을 때 그것이 정답일 확률을 예측하도록 한다.
  4. 테스트 시에는 여러 후보를 생성하고 검증기가 가장 높은 점수를 준 후보를 최종 답변으로 선택한다.

검증 기법은 특히 충분히 큰 데이터셋으로 학습했을 때, 단순 파인튜닝(finetuning)보다 훨씬 뛰어난 성능을 보인다. 또한 검증기가 상위권으로 판단한 답변들 사이에서 Self-consistency(다수결 투표)를 다시 적용하면 성능을 더욱 향상시킬 수 있다.

STaR: 추론을 통한 부트스트래핑​

Self-Taught Reasoner(STaR)는 양질의 추론 데이터셋을 LLM 스스로 구축하여 학습하는 부트스트래핑(bootstrapping) 기법이다.

  1. 소수의 예시(few-shot)를 이용해 LLM이 주어진 문제에 대한 추론 과정(rationale)과 답변을 생성하도록 유도한다.
  2. 생성된 결과물 중, 최종 답변이 정답과 일치하는 경우의 추론 과정만을 필터링하여 고품질의 '추론 데이터셋'을 구축한다.
  3. 기존 LLM을 이 데이터셋으로 파인튜닝한다.
  4. 성능이 향상된 LLM을 사용하여 다시 1번 과정부터 반복한다.

이 과정은 더 나은 추론 생성이 더 좋은 학습 데이터를 만들고, 이는 다시 추론 생성 능력을 향상시키는 선순환 구조를 만들어 모델의 추론 능력을 점진적으로 강화시킨다.