LLM Agent

LLM agent가 무엇인지 이해하기 위해, 먼저 LLM의 기본 역량을 비교

기본 LLM 은 여러 토큰을 연속으로 샘플링 하여 대화를 모사하고 더 포괄적인 답변을 제공함

그러나 대화를 계속 진행하다보면 그 단점이 나오는데, 대화를 기억하지 못함

숫자 계산도 마찬가지, 이를 해결하기 위해 외부 시스템을 통해 LLM 역량을 강화하고 이를 Anthropic 에서는 Augmented LLM 이라고 부름

수학 문제에 직면했을떄, LLM은 적절한 툴을 사용하여 결정함

agent 란

센서를 통해 환경을 인지하고 액추에이터(actuator)를 통해 그 환경에 작용한다고 볼 수 있는 모든 것을 의미한다. — Russell & Norvig, AI: A Modern Approach (2016)

Agents는 환경과 상호작용하며 일반적으로 여러 중요한 구성 요소로 이루어져 있음

Environments — 에이전트가 상호작용하는 세계
Sensors — 환경을 관측하는 데 사용
Actuators — 환경과 상호작용하기 위해 사용하는 툴
Effectors — 관측 결과를 행동으로 전환하는 “두뇌” 또는 규칙

위 프레임워크를 통해 Augmented LLM에 적합하게 만들 수도 있음

위에서 “Augmented” LLM 을 사용하면 Percepts는 text가 됨

어떤 행동을 취할지 결정하기 위해, LLM Agent에는 계획을 수립하는 능력이라는 핵심 요소가 필요함

LLM이 chain-of-thought 같은 기법을 통해 “추론”하고 “생각”할 수 있어야 함

이러한 계획(planning)을 통해, 에이전트는 상황(LLM)을 이해하고, 다음 단계를 계획하며, 툴(tool)를 사용해 행동을 취하고, 취한 행동을 메모리(memory)에 기록할 수 있음

Memory

LLM 은 예측 모델임으로 기존 대화내용을 암기하지 않음

하지만 LLM agent는 단기 기억 뿐 아니라 필요 시 수십 개의 단계까지 추적해야할 수도 있음

이는 이론적으로 LLM Agent가 수십, 심지어 수백 단계에 이르는 작업들을 기억해야 할 수 있으므로 long-term memory(장기 기억)라고 불림

위처럼 모델에 기억력을 부여하기 위해 몇 가지 방법들이 있음

Short-Term Memory

이 방법은 가장 간단한 방법으로 모델의 context window로 처리하는 방법

이 방식은 대화 이력이 LLM의 context window 안에 들어오기만 하면 잘 작동하며, 메모리를 흉내 내는 좋은 방법입니다. 하지만 실제로 대화를 기억하는 대신, 본질적으로 우리는 LLM에게 그 대화의 내용을 “알려주는” 것

Context window가 작은 모델이거나 대화 이력이 방대할 경우, 지금까지 진행된 대화를 요약하기 위해 다른 LLM을 사용할 수도 있음

대화를 지속적으로 요약함으로써, 대화의 전체 크기를 줄일 수 있습니다. 이는 토큰 수를 줄이면서도 가장 중요한 정보만 추적하도록 도와 줌

Long-term Memory

LLM Agents에서 long-term memory는 오랜 기간 동안 유지되어야 하는 에이전트의 과거 행동 공간(past action space)을 포함

각 대화를 임베딩 하여 vector database에 저장 후

입력된 프롬프트를 임베딩하고 그것을 데이터베이스에 있는 임베딩과 비교함으로써, 벡터 데이터베이스에서 가장 관련성이 높은 정보를 찾아서 사용(롱텀의 경우 이전 세션에서 수행한 답변도 기억하도록 설정도 가능)

위 방법이 RAG(Retrieval-Augmented Generation) 방식

Tools

Tools는 특정 LLM이 외부 환경(예: 데이터베이스)과 상호작용하거나, 외부 애플리케이션(예: 코드 작동을 위한)을 사용할 수 있도록 하며 두 가지 활용 사례를 가짐

정보를 얻기 위해 데이터를 가져오거나
회의실 예약 등의 행동을 수행

툴을 요청해야 되는 질문이 온 경우 code interpreter 에 쉽게 전달할 수 있게 위그림의 예시처럼 json혹은 mcp등 여러가지 방식으로 처리하며, LLM이 사용할 수 있는 간단한 (곱셈 더하기 등 ) 커스텀 함수를 생성할 수 있는데 이를 function calling 이라고 함

에이전트적 프레임워크가 정해져 있다면, Tools는 미리 정해진 순서로 사용될 수 도 있음

여기에서 LLM이 어떤 툴을 언제 사용할지 자율적으로 결정하는데 그렇게되면 아래 그림처럼 실행됨

LLM agents가 llm 호출의 연속임

즉, 중간 단계의 출력을 LLM으로 다시 전달하여 연속적으로 처리를 이어 감

툴(Tool) 사용은 LLM의 역량을 강화하고 단점을 보완하는 강력한 기법으로 최근 몇 년간 툴 사용과 관련된 연구가 급격히 늘어나고 있으며, 연구 상당 부분은 LLM에게 툴 사용을 지시하는 프롬프트를 제공하는 것뿐 아니라, 툴 사용 자체에 특화하여 모델을 학습시키는 방식을 포함함

이런 접근의 초기 기법 중 하나가 Toolformer라는 것으로, 어떤 API를 어떻게 호출할지를 결정하도록 학습된 모델로, Toolformer는 [ 과 ] 토큰을 사용하여 툴 호출의 시작과 끝을 표시합니다. 예를 들어 “What is 5 times 3?”라는 프롬프트가 주어지면, ] 토큰에 도달할 때까지 토큰을 생성

Toolformer는 모델이 학습할 수 있는 다양한 툴 사용 사례가 포함된 데이터셋을 신중히 생성함으로써 이러한 동작을 형성하도록 학습해 각 툴마다 개별적으로 생성된 few-shot prompt를 사용하여 해당 툴을 활용하는 출력을 샘플

이후 툴 사용의 정확도, 출력의 정확성, loss 감소 등을 기준으로 출력들을 필터링함

이렇게 만들어진 데이터셋은 해당 툴 사용 형식에 따르도록 LLM을 학습시키는데 사용할 수 있음

Toolformer가 발표된 이후, 수천 가지 툴을 사용할 수 있는 LLMs(ToolLLM⁴)나 가장 관련성 높은 툴을 쉽게 찾을 수 있는 LLMs(Gorilla⁵) 같은 흥미로운 기법들이 많이 나오게 됨

Model Context Protocol (MCP)

Tools는 에이전트적 프레임워크에서 매우 중요한 구성 요소이며, LLM이 세상과 상호작용하고 역량을 확장하도록 해줌. 하지만 서로 다른 API가 많을 경우, 툴 사용을 가능케 하는 것은 까다로울 수 있음

왜냐하면 모든 툴은 다음 과정을 거쳐야 하기 때문

수동으로 툴을 추적하고 LLM에 전달해야 함
수동으로 예상 JSON 스키마를 포함해 툴을 설명해야 함
API가 변경될 때마다 수동으로 업데이트 해야 함

Anthropic은 어떠한 에이전트적 프레임워크에서도 툴을 더 쉽게 구현할 수 있도록 Model Context Protocol(MCP)을 개발해 날씨 앱이다 github 같은 서비스에 대한 API 접근을 표준화함

MCP는 세 가지 컴포넌트로 이루어짐

MCP Host — 연결을 관리하는 LLM 애플리케이션(예: Cursor)
MCP Client — MCP 서버와 1:1 연결을 유지
MCP Server — LLM에게 context, tools, capabilities를 제공

예를 들어, 특정 LLM 애플리케이션이 당신의 깃허브 레포에서 최근 5개의 commit을 요약하도록 하고 싶다고 가정하면

MCP Host(클라이언트와 함께)는 먼저 MCP Server에 어떤 툴들이 사용 가능한지 확인을 요청

LLM은 해당 정보를 받아 툴을 사용할지 선택

그런 다음 Host를 통해 MCP Server에 요청을 보내고, 사용된 툴을 포함한 결과를 전달받습니다.

마지막으로 LLM은 그 결과를 받아 사용자에게 전달할 답변을 분석

MCP를 지원하는 모든 LLM 애플리케이션이 활용할 수 있는 MCP Server와 연결할 수 있으므로, 툴 개발이 훨씬 쉬워짐

예를 들어, Github와 상호작용하는 MCP Server를 만들면, MCP를 지원하는 모든 LLM 애플리케이션이 그것을 사용할 수 있음

Planning

툴 사용은 LLM이 자신의 역량을 확장하게 해줍니다. 이런 툴들은 보통 JSON 유사한 요청 형식을 통해 호출

그렇다면 에이전트적 시스템에서 LLM은 어떤 툴을 언제 사용해야 할지 어떻게 결정할지에 대해 planning이 등장하게 됨

LLM Agents에서 planning이란, 주어진 작업을 실행 가능한 단계들로 분할하는 과정을 의미

아래와 같이 계획을 통해 모델은 과거 행동을 반복적으로 확인하고, 필요하면 현재 계획을 업데이트함

Reasoning

LLM Agents에서 planning을 가능하게 하려면, 먼저 이 기법의 기본인 reasoning을 살펴봐야함

실행 가능한 단계를 계획하기 위해서는 복잡한 추론 행동이 필요하고, 따라서 LLM은 작업을 계획하는 다음 단계로 넘어가기 전에 이러한 추론을 수행할 수 있어야함

“Reasoning” LLM은 질문에 답하기 전에 “생각”하는 경향을 보이는 모델을 의미함

이런 추론 행동은 크게 두 가지 방식으로 활성화 할 수 있음

LLM을 fine-tuning
프롬프트 엔지니어링

Reasoning and Acting

LLM이 추론 행동을 할 수 있게 만드는 것은 훌륭하지만, 그것만으로 실행 가능한 단계들을 계획할 수 있게 되는 것은 아님

지금까지 살펴본 기법들은 주로 추론 행동을 보여주거나, 툴을 통해 환경과 상호작용하는 데 초점이 있었음

이 두 과정을 결합한 초기 기법 중 하나가 ReAct(Reason and Act)라고 함

ReAct는 신중한 prompt engineering을 통해 이 기능을 수행

ReAct 프롬프트에는 세 가지 단계가 설명됨

Thought - 현재 상황에 대한 추론 단계
Action - 실행해야 할 행동들(예: 툴 사용)
Observation - 행동의 결과에 대한 추론 단계

아래 프롬프트를 조면 직관적으로 적혀있음

LLM은 이 프롬프트(시스템 프롬프트로 사용할 수 있음)를 활용하여, 생각(Thought), 행동(Action), 관찰(Observation)의 사이클을 반복하는 방식으로 동작을 수행

결과를 반환하라는 행동(Action) 지시가 있을 때까지 이 과정을 계속합니다. 생각(Thought)과 관찰(Observation)을 반복함으로써, LLM은 행동을 계획하고, 결과를 관찰하며, 그에 따라 조정할 수 있음

Reflecting

ReAct를 사용하는 LLM이라 해도, 모든 작업을 완벽하게 수행하지는 못함

실패를 되돌아볼 수 있는 기능이 ReAct 에는 없는데 이걸 보완해주는게 Reflexion임

Reflexion은 언어적 강화(verbal reinforcement)를 통해 에이전트가 이전의 실패로부터 배우도록 돕는 기법

LLM에 3가지 역할을 가정함

Actor — 상태 관찰(state observations)에 기반해 행동을 선택하고 실행합니다. Chain-of-Thought나 ReAct 같은 기법을 사용할 수 있음
Evaluator — Actor가 만든 출력물을 점수화
Self-reflection — Actor가 취한 행동과 Evaluator가 생성한 점수를 돌아보며(Reflecting) 평가

메모리 모듈을 추가하여 행동(단기)과 자기반성(장기)을 추적함으로써, 에이전트가 실수로부터 학습하고 개선된 행동을 찾도록 도움

유사하면서도 우아한 기법으로 SELF-REFINE이 있는데, 이는 출력물을 다듬고 피드백을 생성하는 과정을 반복

동일한 LLM이 초기 출력, 개선된 출력, 피드백 생성까지 모두 담당

Reflexion과 SELF-REFINE 모두 이러한 자기반성적 행동은 출력물의 품질에 따라 보상이 주어지는 강화학습과 매우 유사한 모습을 보임

Multi-Agent Collaboration

지금까지 살펴본 단일 에이전트에는 몇 가지 문제가 있음

이러한 Multi-Agent 시스템은 보통 전문화된 Agents로 구성되며, 각각 고유한 툴 세트를 보유하고 supervisor가 이를 감독함

supervisor는 Agents 간의 커뮤니케이션을 관리하고, 각 전문화된 Agent에게 특정 과제를 할당

실제로, 다수의 Multi-Agent 아키텍처가 존재하며, 이들은 핵심적으로 두 가지 구성 요소를 가짐

Agent Initialization — 개별(전문화된) Agent들은 어떻게 생성되는가?
Agent Orchestration — 모든 Agent들은 어떻게 조율되는가?

Multi-Agent 컴퓨턴트 구현 예

Interactive Simulacra of Human Behavior

Generative Agents: Interactive Simulacra of Human Behavior

믿을법한 사람의 행동을 모사하는 계산 소프트웨어 에이전트를 만들었는데, 이를 Generative Agents라 부름

각 Generative Agent는 특정 프로필(profile)을 부여 받으며, 이는 고유한 행동 양식을 부여하고, 보다 흥미롭고 역동적인 행동을 유도함

각 Agent는 memory, planning, reflection 세 가지 모듈로 초기화되며, 이는 우리가 ReAct와 Reflexion에서 봤던 핵심 구성 요소들과 매우 유사함

프레임워크에서 memory 모듈은 가장 중요한 요소 중 하나입니다. 이는 지금까지의 모든 이벤트뿐 아니라, planning과 reflection 행동도 저장

주어진 다음 단계나 질문이 있을 때, 메모리에서 관련 항목을 불러온 뒤, 최신성(recency), 중요성(importance), 관련성(relevance)에 따라 점수를 매기고, 가장 높은 점수를 받은 메모리가 Agent에게 공유됨

이를통해 Agents가 자유롭게 행동하며 서로 상호작용할 수 있게됨

사람이 평가를 했고 관찰(observation), 계획(planning), 반성(reflection)이 Generative Agents의 성능에서 얼마나 중요한지를 보여줌

Reasoning LLMs

DeepSeek-R1, OpenAI o3-mini, 그리고 Google Gemini 2.0 Flash Thinking은 LLMs가 “reasoning” 프레임워크를 통해 어떻게 새로운 차원으로 확장될 수 있는지 보여주는 대표적인 예시임

일반적인 LLMs와 비교했을 때, reasoning LLMs는 주어진 질문에 답하기 전에 문제를 더 작은 단계(일반적으로 reasoning steps 또는 thought processes라고 불림)로 나누려고함

LLMs가 실제로 인간처럼 생각할 수 있는지 여부를 철학적으로 논의¹ 할 수도 있지만, 이러한 reasoning 단계는 과정을 더 작은, 구조화된 추론(inference)으로 분해함

즉, LLM이 “무엇을” 답해야 하는지를 배우는 대신, “어떻게” 답해야 하는지를 배우게됨

reasoning LLMs가 어떻게 만들어지는지 이해하기 위해, train-time compute의 확장에서 test-time compute의 확장으로 초점을 전환하는 패러다임 전환을 먼저 살펴봐야함

2024년 중반까지, 사전 학습(pre-training) 동안 LLMs의 성능을 높이기 위해, 개발자들은 다음 요소들의 크기를 자주 늘렸음

Model (# of parameters)
Dataset (# of tokens)
Compute (# of FLOPs)

이들을 합쳐 train-time compute라고 함

train-time compute에는 훈련(사전 학습)뿐만 아니라 미세 조정(fine-tuning) 동안 필요한 연산도 포함될 수 있음

이 두 과정은 LLM 성능을 향상시키는데 있어 두가지 주요 관심사 였음

Scaling Laws

모델의 규모(연산, 데이터셋 크기, 모델 크기)가 모델 성능과 어떻게 상관관계를 갖는지 연구하는 분야가 바로 다양한 scaling laws

이 관계는 일반적으로 log-log 스케일로 나타내는데(그래서 직선 형태가 됨), 이는 연산량의 큰 증가를 시각화하기 위함

가장 잘 알려진 것은 “Kaplan” 과 “Chinchilla” scaling laws입니다. 이 법칙들은 모델의 성능이 더 많은 compute, 더 많은 토큰, 그리고 더 많은 파라미터와 함께 증가한다고 대체로 말함

-> 이를 위해 세 요인 모두를 동시에 확장해야 하며, Kaplan의 Scaling Law는 고정된 compute에서 모델 크기를 키우는 것이 일반적으로 데이터를 확장하는 것보다 더 효과적이라고 말함, Chinchilla의 Scaling Law는 모델 크기와 데이터가 동등하게 중요하다고 주장

=> 2024년 compute, 데이터셋 크기, 모델 파라미터까지 꾸준히 증가했음에도, 그이득은 서서히 줄어들고 있는 중

test-time compute

train-time compute를 계속 늘리는 데 드는 비용이 높아짐에 따라, 추론 시점의 연산(test-time compute)이라는 다른 초점이 떠오르게됨

사전 학습 예산을 계속 늘리는 대신, test-time compute는 모델이 추론 시점에 “더 오래 생각”할 수 있도록 하는것

-> reasoning 모델은 체계적인 “thinking” 과정을 통해 답을 도출하기 위해 더 많은 토큰을 사용

Scaling Laws

train-time compute에 비해 test-time compute에 대한 scaling laws는 상대적으로 새로운 분야

OpenAI가 작성한 포스트에서, test-time compute도 train-time compute의 확장(scaling) 추세와 유사할 수 있다고 제안

“Scaling Scaling Laws with Board Games”⁴ 라는 흥미로운 논문에서는 AlphaZero를 다양한 연산량으로 학습해 Hex 게임을 두게 하면서, train-time compute와 test-time compute를 여러 단계로 달리하여 비교함

이에따라 test-time compute가 train-time compute처럼 확장됨에 따라, “reasoning” 모델들이 더 많은 test-time compute를 활용하는 쪽으로 패러다임 전환이 진행됨

Categories of Test-time Compute

DeepSeek R-1과 OpenAI o1 같은 reasoning 모델들의 놀라운 성공은 “더 오래 생각하기” 이상의 다양한 기법들이 있다는 것을 보여줌

Chain-of-Thought, revising answers, backtracking, sampling 등을 포함하여 매우 다양한 기법들이 있음

이중 아래 두가지를 살펴봄

Search against Verifiers (검증자를 활용한 검색): 생성을 샘플링하고, 최적의 답변을 선택
Modifying Proposal Distribution (제안 분포 수정): 학습된 “Thinking” 프로세스

Search against verifiers는 결과물(output)에 초점을 맞추는 반면, Modifying proposal distribution은 입력(input)에 초점을 맞춤

verifier에는 Outcome Reward Models (ORM), Process Reward Models (PRM) 두 가지 유형이 있고, ORM은 오직 결과(outcome)만 평가하며, 그 이면의 과정에는 관심을 두지 않고, 반면, PRM은 결과를 도출하는 과정(즉, “reasoning”)도 함께 평가함

Search against Verifiers

Verifier를 활용한 검색은 test-time compute의 첫 번째 주요 카테고리로 일반적으로 두 가지 단계를 거침

여러 가지 reasoning 과정과 답변을 샘플링
생성된 답변을 Verifier(Reward Model)로 평가

이때 Verifier는 보통 LLM을 미세 조정하여 결과(Outcome Reward Model, ORM)나 과정(Process Reward Model, PRM)를 평가하도록 만든 모델을 사용함

Verifier를 사용하면, 질문에 답하는 LLM을 재학습하거나 미세 조정할 필요가 없다는 큰 장점이 있음

Majority Voting

가장 간단한 방법은 사실상 Reward Model이나 Verifier를 전혀 사용하지 않고, 대신 다수결 투표(majority vote)를 수행하는 방법으로 self-consistency라고도 함, 여러 모델이 답변을 생성한 뒤, 가장 많이 나온 답을 최종 답변으로선택

Best-of-N samples

Verifier를 사용하는 첫 번째 기법은 Best-of-N samples라고 하며, N개의 샘플을 생성한 다음, Verifier(Outcome Reward Model)를 사용해 각 답변을 평가함

답변 자체가 아니라, reasoning 과정을 평가하는 Process Reward Model(PRM)을 사용할 수도 있는데, 이는 각 reasoning 단계의 품질을 판단하고, 총합이 가장 높은 후보를 선택함

두 Verifier 타입 모두에서, 각 답변 후보에 대해 RM 점수를 부여하고, 가장 높은 점수의 후보를 선택할 수 있음 이를 Weighted Best-of-N samples라고 부름

Monte Carlo Tree Search

트리 검색을 더 효율적으로 만드는 유명한 기법 중 하나로 Monte Carlo Tree Search가 있으며 4가지 단계로 구성됨

Selection (미리 정해진 공식을 바탕으로 특정 leaf를 선택)

Expand (추가 노드를 생성)

Rollouts (노드를 무작위로 생성하여 끝까지 탐색)

Backprop (결과 점수를 부모 노드로 업데이트)

탐색(exploration)과 활용(exploitation) 사이의 균형을 맞춤

확장된 reasoning 단계 중 하나를 선택하고, 여러 번 Rollout하여 여러 답안을 도출

Modifying Proposal Distribution

reasoning LLMs을 만드는 두 번째 카테고리는 “Modifying Proposal Distribution”

verifier를 이용하여 올바른 reasoning 단계를 찾는 방식(output-focused)과 달리, 모델이 더 나은 reasoning 단계를 생성할 수 있도록 학습하는 방식(input-focused)

즉, completions/thoughts/tokens이 샘플링되는 분포를 조정함

프롬프트엔지니어링과 reasoning 토큰을 생성하도록 학습하는 등의 방법을 사용하며, 리즈닝을 유도하는 토큰을 생성하도록 함

Prompting

Prompt Engineering을 사용하면, 프롬프트를 수정하여 리즈닝 과정을 유도하도록 모델의 결과을 개선함

이 과정을 단순화하기 위해, “Let’s think step-by-step” - 같은 문구만 입력해도됨

다만, 이 방식에서 모델은 본질적으로 이 과정을 따르도록 학습된 것은 아닙니다. 또한 이는 고정적이고 선형적인 과정이어서, 만약 모델이 잘못된 reasoning으로 시작하면 수정 없이 그대로 진행될 가능성이 높음

STaR(Self-Taught Reasoner)

Prompting 외에도, 모델이 이러한 reasoning 단계를 생성하면 보상을 주어 “reasoning”을 학습하도록 하는 방법이 있음

일반적으로 많은 reasoning 데이터와 강화 학습을 이용해 특정 행동을 보상하며 그 방법중 논쟁이 많은 방법중의 하나로 STaR이 있음

STaR는 LLM이 자체적으로 reasoning 데이터를 생성하고, 이를 모델 미세 조정에 사용하는 방식

reasoning model 답변 생성
답이 맞으면(2a), reasoning과 답변을 트리플릿 학습 데이터(3b)에 추가

해당 데이터는 SFT에 활용됨

모델이 잘못된 답을 내놓으면(2b), “힌트”(정답)를 제공하고 이 답이 왜 맞는지 reasoning을 요청(4b)

최종 reasoning 단계도 같은 트리플릿 학습 데이터에 추가

DeepSeek-R1

reasoning 모델 분야의 큰 발표 중 하나는 DeepSeek-R1으로 OpenAI의 o1 resoning과 경쟁자인 모델임

DeepSeek은 여러 기법을 통해 reasoning을 base 모델(DeepSeek-V3-Base)에 우아하게 distill하는 데 성공함

흥미롭게도, 여기에는 Verifier가 전혀 사용되지 않았으며, reasoning 행동을 distill하기 위해 지도 학습(supervised fine-tuning)을 사용하는 대신, 강화 학습(reinforcement learning)에 크게 집함

Reasoning with DeepSeek-R1 Zero

DeepSeek-V3-Base로부터 시작하여, (시스템 프롬프트와 유사한) 아주 간단한 프롬프트를 파이프라인에서 사용여 대규모 reasoning 데이터에 대한 지도 학습 대신 오직 강화 학습(RL)만 사용해 reasoning 행동을 가능케함

명시적으로 reasoning 과정은 태그 사이에 있어야 한다고 언급하지만, 그 과정이 어떠해야 하는지는 구체적으로 지정하지 않음

Accuracy rewards – 답변이 맞는지 확인해 보상

Format rewards – **** 과 **** 태그를 사용하는지에 대한 보상

RL 알고리즘은 Group Relative Policy Optimization (GRPO)으로 핵심 아이디어는 정답 혹은 오답으로 이어진 모든 선택(토큰 세트와 reasoning 단계 모두)의 확률을 높이거나 낮추는 것

흥미롭게도, 과정이 어떠해야 하는지에 대한 예시는 주지 않고, 태그를 쓰라고만 프롬프트에 지시

모델은 스스로 길고 복잡한 reasoning 과정을 시도할수록 정답 확률이 높아진다는 사실을 학습함

DeepSeek-R1을 만들기 위해 저자들은 다섯 단계를 따름

Cold Start

DeepSeek-V3-Base를 소량의 고품질 reasoning 데이터(약 5,000 토큰)로 미세 조정(fine-tuning)하여, 가독성이 떨어지는 결과(Cold Start)를 방지

Reasoning-oriented Reinforcement Learning

DeepSeek-V3-Zero와 유사한 RL 프로세스를 통해 학습하며 대상 언어를 일관되게 유지하기 위해 또다른 보상을 추가함

Rejection Sampling

RL로 학습된 모델을 이용하여 이후 지도 학습을 위해 사용될 합성(synthetic) reasoning 데이터를 생성

Rejection Sampling(규칙 기반 보상, rule-based rewards)과 Reward Model(DeepSeek-V3-Base)을 통해 600,000개의 고품질 reasoning 샘플을 생성

DeepSeek-V3와 그 일부 학습 데이터를 사용해 200,000개의 non-reasoning 샘플을 생성

Supervised Fine-Tuning

만들어진 800,000개의 샘플로 DeepSeek-V3-Base를 지도 학습 방식으로 미세 조정

Reinforcement Learning for all Scenarios

앞선 단계를 거친 모델을 DeepSeek-R1-Zero에서 사용된 방식과 유사한 RL 기법으로 학습

다만 사람들의 선호도와 일치시키기 위해(Helpfulness, Harmlessness), 추가적인 보상 신호(reward signals)가 사용함

또한, 가독성 문제를 방지하기 위해 reasoning 과정을 요약하도록 모델에 요청함

결과적으로, DeepSeek-R1은 실제로 DeepSeek-V3-Base를 지도 학습과 강화 학습으로 미세 조정한 모델

Distilling Reasoning with DeepSeek-R1

DeepSeek-R1은 671B 파라미터를 가진 거대한 모델로 일반적인 gpu에서 구동이 어려움

DeepSeek-R1의 reasoning 품질을 Qwen-32B 같은 다른 모델로 distill하는 방법을 연구함

이 과정은 앞서 언급된 800,000개의 고품질 샘플 전체를 사용해 진행

앞서 언급했던 Process Reward Models(PRMs)과 Monte Carlo Tree Search(MCTS)를 DeepSeek 측도 시도했지만, reasoning을 구현하는 데 성공하지 못했다고 함

MCTS 경우에는 매우 큰 검색 공간 문제가 있어 노드 확장을 제한
PRMs를 사용한 Best-of-N 기법: 보상 해킹을 방지하기 위해 Reward Model을 계속 재학습해야 하는 계산 부담 문제
- Beam search with process reward models

Beam search를 통해 답변과 중간 단계를 생성할 수도 있음

Beam search를 사용하여 여러 reasoning 단계를 샘플링하고, 각 단계를 PRM이 평가하여 사용

참고 사이트

LLM agent 기초

https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-llm-agents
https://www.promptingguide.ai/research/llm-agents
- 정리가 너무 잘 되어있어 아래 링크 위주로 정리
https://tulip-phalange-a1e.notion.site/LLM-Agents-1b9c32470be2800fa672e82689018fc4
https://tulip-phalange-a1e.notion.site/Reasoning-LLMs-190c32470be2806d834ee0ad98aaa0b6