LLM | Agent란?

 

Agent를 간단하게 정의하면 LLM 시스템을 '답변기'에서 '판단 시스템'으로 바꾸는 구조라고 할 수 있다.

 

 LLM을 활용한 시스템을 접하면 대부분 RAG를 접하게 되는데

https://iambeginnerdeveloper.tistory.com/338

LLM | RAG(Retrieval-Augmented Generation)란?

RAG와 같은 문서를 검색해 답변 정확도를 높이는 방식은 직관적이고 효과적이다.

 

1. RAG의 한계

하지만 RAG를 실제 서비스에 적용해 보면 몇가지 한계가 있다.

RAG의 구조는

이와 같은데 이 구조의 핵심 특징은 다음과 같다.

- 검색은 항상 수행되며 흐름이 고정 되어 있음

- 결과가 애매해도 그대로 답변함

- 여러 단계를 거쳐야 하는 문제는 다루기 어려움

즉, RAG는 정보를 보강해 더 그럴듯한 답변을 만든다는 목적에 최적화 된 구조이다.

 

하지만 다음과 같은 문제에는 취약하다.

- 검색이 필요한지 아닌지를 판단해야 하는 경우

- 검색 결과를 비교, 검증해야 하는 경우

- 결과에 따라 다음 행동이 달라져야 하는 경우

이런 문제는 단순한 '답변 생성'을 넘어선다.

 

 

2. Agent 정의 및 구성 요소

Agent는 답변을 생성하는 구조가 아니라 상태를 보고 행동을 선택하는 구조이다.

이 개념은 LLM 이전부터 존재하던 고전적인 Agent 모델과 동일하다.

Agent는 state-현재 상황, policy-다음 행동을 선택하는 규칙, action-실제 수행하는 행동, observation-행동의 결과으로 구성되어 있다. Agent는 이 과정을 반복하며 목표를 달성한다.

 

LLM Agent는 아래 구조를 자연어 공간으로 옮긴 형태이다.

Agent 개념	LLM 기반 Agent
State	대화 맥락, 중간 결과
Policy	LLM의 추론
Action	Tool 호출
Observation	Tool 실행 결과

LLM은 지식을 말하는 모델이 아니라 다음 행동을 선택하는 정책(policy)로 사용된다. 이 순간부터 LLM은 단순한 텍스트 생성기를 벗어나게 된다.

 

 

3. RAG와 AGent의 차이

RAG에서의 검색은 항상 실행되는 고정단계로 판단의 대상이 아니다.

Agent에서의 검색은 여러 행동 중 하나로 LLM이 필요성을 판단한다. 즉, Agent에서는 다음과 같은 흐름이 가능해진다.

- 이 질문은 내 지식으로 충분 -> 바로 답변

- 이건 내부 문서 필요 -> 검색 실행

- 검색 결과가 불충분 -> 다른 도구 사용

검색 자체가 의가결정의 결과가 되는 것이다.

 

대부분 LLM Agent는 ReAct(Reasoning + Acting) 패턴을 따른다.

Thought: 지금 상태에서 무엇이 필요한가?
Action: 선택한 도구 실행
Observation: 실행 결과 확인
Thought: 다음 행동 결정

이 구조의 핵심은 다음과 같다.

- 추론이 한 번으로 끝나지 않음

- 외부 세계와 상호작용 함

- 실패하면 다시 시도할 수 있음

이런 점에서 Agent는 단일 프롬프트 호출보다 계산적으로 더 강한 모델이라고 볼 수 있다.

 

모든 RAG는 Agent의 일부가 될 수 있지만 모든 Agent는 RAG가 아니다. RAG는 Agent가 사용할 수 있는 하나의 행동이며 Agent는 행동 선택 공간 전체를 다룬다.

Agent는 특정 라이브러리나 프레임워크의 이름이 아니다. 즉, 기존의 규칙 기반 시스템이나 비전 파이프라인도 Agent 관점에서 재해석 할 수 있다. LangChaind은 Agent의 개념을 구현한 도구 중 하나이다.